What are we looking at?
For requirements analysis to be reliable, exactly what do we have to look at?
Requirements analysis isn’t just listening to the user’s wishes. It is a systematic, multi-dimensional process, and for its output to be reliable and precise we have to examine several things together. Each can be tested with a few questions.
1. Who are the stakeholders?
Identifying stakeholders is one of the first steps: end users, managers, customers, technical support, legal and policy overseers. We have to ask who is most affected by the system, who affects the project’s success or failure, and what each group’s main concern is.
2. Functional and non-functional needs
Functional needs are what the system must do, such as sending a message, placing an order and producing reports. Non-functional needs concern how it performs: response speed, information security, ease of use. The questions here: what must the system do, what quality of performance do users expect, and what are the organisation’s limits and standards.
3. What environment is the system in?
The external environment shapes many design decisions: governing laws and regulations, existing technical infrastructure, interaction with other systems, and users with different levels of knowledge. So ask which systems must interact with this one, whether there are hardware or internet limits, and what language and culture the system must fit.
4. Time and resources
Without understanding the limits, requirements can’t be analysed properly. When must the project be delivered? What human and financial resources are available? Does the development team have a particular technology restriction?
5. Life cycle and future change
The analysis must also allow for future change. May users grow in number? In what phases will the system run? How much can it be expanded or upgraded later?
6. How are needs gathered?
The way we gather needs strongly affects the precision of the analysis: interviews, questionnaires, direct observation, analysing documents and building a prototype. For each project we have to see which is best, whether validation is needed, and how involved users will be in the analysis.
In sum
I think requirements analysis isn’t just documenting wishes; it is the art of asking the right questions, of the right people, at the right time.