Big hardware or software systems, such as a spacecraft, have complex requirements. Requirements are a specification of what should be built, how the system should behave, or constraints on the process of building the system. Requirements engineering is the use of good engineering practices to understand the requirements before a system is built. It assumes importance because the stakeholders of the system are themselves not clear about their needs, and have divergent needs.
A complex system can have many stakeholders such as the people who commission the system, users who use one or more aspect of the system, and people who benefit from the system. It is also possible that stakeholders include members of the public who are affected by certain peculiarities of the system. Stakeholders have their own special needs. On the other hand, people who develop the system may be technically capable, but may not fully understand the viewpoint of the stakeholders. Requirements engineering is the essential capability that connects these sides.
Formally, the requirements engineering activity is divided into requirements development and requirements management. Requirements development is composed of elicitation, analysis, specification, and verification. Requirements management is the control of the whole requirements process, especially, handling any change in requirements. Some practitioners, contrastingly, just call the whole activity as requirements analysis.
Elicitation of requirements from stakeholders becomes necessary because stakeholders often do not completely specify their needs, and do not understand the implications of the new system. Stakeholders may not open up, as they could fear the impact on their current jobs. Elicitation, thus, is a careful and, possibly, a long process where empathy and subtle psychology is needed. One has to be careful that cultural differences between different stakeholders as well as the developers are bridged.
Several techniques are used to elicit requirements. Requirements could be elicited through individual interviews, group meetings, and observing people at their tasks. Techniques that can bring forth requirements include focus groups, creating prioritized lists, prototyping and comparison with other systems in operation. The requirements to elicit include the business needs of the system, the business processes of the users as they use the system, and the functional features of the system. In addition, the non-functional requirements such as response time, system availability, and ease of use need to be elicited.
The analysis step in requirements engineering forms low-level requirements that will satisfy the original high-level requirements. This includes creating conceptual models and prototypes to ascertain the completeness of the requirements. Conflicts in the needs of different stakeholders are more often found by models and prototypes than from a mere list of requirements. Desirable system characteristics such as security, flexibility, and maintainability need to be added to the requirements by the analysts.
The requirements are specified in a document for ease of understanding of all the stakeholders. In the software field, the document is called the SRS, which stands for Software Requirements Specification. The requirements are verified by key stakeholders. This is mainly via presentations and the specification document, but also sometimes with test cases that correspond to the requirements.
Requirements engineering is primarily a communication, activity rather than a technical one. It needs multi-disciplinary skills. Requirements engineering helps stakeholders and developers resolve conflicts and unites them in their goals; This leads to a robust system.
