[ad_1]
Requirements engineering is the process of understanding complex system requirements before building. It involves elicitation, analysis, specification, and verification of requirements. Multidisciplinary skills are needed to bridge cultural differences and resolve conflicts between stakeholders and developers. The final product is a robust system that satisfies all parties involved.
Large 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 requirements before a system is built. It assumes importance because the system’s stakeholders themselves are not clear about their needs and have divergent needs.
A complex system can have many stakeholders such as the people who commission the system, the users who use one or more aspects of the system, and the people who benefit from the system. It is also possible that stakeholders include members of the public who are affected by some peculiarity of the system. Stakeholders have their own special needs. On the other hand, the people developing the system may be technically capable, but may not fully understand the stakeholders’ point of view. Requirements engineering is the essential capability that connects these sides.
Formally, the activity of requirements engineering is divided into requirements development and requirements management. Requirements development consists of elicitation, analysis, specification, and verification. Requirements management is the control of the entire requirements process, in particular, the management of any changes in requirements. Some practitioners, on the contrary, call the whole business simply requirements analysis.
Requesting requirements from interested parties becomes necessary because interested parties often do not fully specify their needs and do not understand the implications of the new system. Stakeholders may not open up, as they may fear the impact on their current jobs. Thus, elicitation is a careful and, possibly, lengthy process in which empathy and subtle psychology are needed. Care must be taken that cultural differences between different stakeholders and developers are bridged.
Different techniques are used to elicit requirements. Requirements could be obtained through one-on-one interviews, team meetings and observing people on their tasks. Techniques that can surface requirements include focus groups, priority list building, prototyping, and comparisons with other systems in operation. The requirements to be elicited include the business needs of the system, the business processes of the users as they use the system, and the functional characteristics of the system. Additionally, you need to identify non-functional requirements such as response time, system availability, and ease of use.
The analysis phase in requirements engineering forms low-level requirements that will satisfy the original high-level requirements. This includes the creation of concept models and prototypes to ensure completeness of requirements. Conflicts in the needs of different stakeholders are more often detected by models and prototypes than by a simple list of requirements. Desirable system characteristics such as security, flexibility, and maintainability must be added to the analysts’ requirements.
The requirements are specified in a document to facilitate understanding by all interested parties. 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 done through presentations and specification documents, but sometimes also with test cases that match the requirements.
Requirements engineering is primarily a communications activity, rather than a technical one. It needs multidisciplinary skills. Requirements engineering helps stakeholders and developers resolve conflicts and unites them in their goals; This leads to a robust system.
[ad_2]