Where Do Requirements Come From?
/In a perfect world, all stakeholders would be able to completely articulate what they need, making life much easier for analysts. In reality however, they aren’t always in a position to provide information on what their requirements are. This is because they don’t always know what to request for.
Where do requirements come from?
How can stakeholders request for a feature, if they do not know whether it will deliver any benefits to them or not? If they know nothing of similar features or capabilities, they will be unable to visualize the benefits or use of such features.
Studying similar systems and their functionalities can go a long way to ensure that typical requirements, from similar deployments in other organizations, are captured. During a recent project, the stakeholders had no idea what would work for them. The project team had to build the system from scratch based on the sponsor's vision. Stakeholders were subsequently called in to verify the requirements and provide suggestions for improvement. The requirements in this case, did not all come from the system users.
This case was peculiar because: 1) The company had lost significant revenue and had launched the project as a potential solution. The management team was a 100% behind the project and had decided to completely overhaul the existing system. 2) The project sponsor had a vision for the system and would not compromise on what he wanted. It was this vision that the team worked with. 3) The current way of doing things was flawed, and as such, there seemed to be no point in spending time understanding how they currently got their work done (as-is process analysis). The existing system was convoluted, messy and ineffective. 4) The users had never worked with a central system and had no clear idea of the capabilities or features that would best suit them.
With these peculiarities in mind, majority of the requirements were elicited without the users. The project was driven by the sponsor’s vision and not user requirements though their opinion was sought and they were carried along. The point is, requirements don’t always come from users. The analyst in some cases, may be required to suggest requirements, explain their benefits and solicit acceptance of the new system.
That being said, where else do requirements come from?
In general, requirements may arise from the need to solve a problem, respond to pressure or exploit an opportunity. Here are some specific sources of requirements that analysts should be aware of:
Government Regulation: Regulatory standards imposed by Government may require that certain requirements be implemented. For example, HIPAA in the U.S and the Data Protection Directive require that organizations adhere to certain laws throughout the life of data; these laws have to be taken into consideration when business data is managed both onshore and offshore. In a similar vein, when Government introduces or alters VAT rates, the accounting systems of organizations need to be modified to accommodate the new rates.
Industry Standards: These have an impact on requirements since they affect the performance of products. For example, standards are what ensure that you can take money out of any ATM, no matter where you are in the world. Also, car manufacturers must meet certain standards of safety and performance to stay competitive. Industry standards may also necessitate the need to implement certain requirements above others.
Competitive Pressure: Features of competing products often define the minimal functional requirements below which a new product would not be competitive. Requirements may be generated when competitors raise the bar. For example, when the first bank implemented cash machines, other high street banks had to follow suit. Information Systems Projects are often initiated as part of an organization's strategy to promote its competitiveness.
Market Research: Research focusing on the buying habits of users, market pricing, consumer preferences and product distribution can unveil new requirements that need to be fulfilled.
Requirements aren't always visible or lying down waiting to be extracted. There's always a discovery phase in which the analyst has to do some background research, talk to users and explore relevant information from multiple sources. Knowing when and where these requirements lie is a critical part of delivering complete, practical and innovative solutions.
