Requirements Engineering is a key discipline in systems development. It is of critical importance for successful systems development. Luckily, help is available: a structured approach in 6 steps for the elicitation and management of requirements, based on recommendations by the International Requirements Engineering Board (IREB e.V.).
The Beginning of the Project
It all begins with the project order. This project order includes a project description. This description includes, among other things, a statement on the expected benefits. It also includes the business case as well as financial and teporal restrictions of the project.
Seems you’re set to go. Let’s elicit some serious requirements, and subsequently determine which of these requirements can be realized from a financial, organizational, and technical standpoint.
Requirements In The Spotlight: Completeness
Requirements concretize goals. The project order is not detailed enough to derive a list of them from it. This is why stakeholder goals have to be detailed. Stakeholders are persons, groups, and organizational units that have an interest in the system under development. They influence the requirements either directly or indirectly. But can everyone be considered a stakeholder if they pursue their goals using the system and who influence the development?
To decide you would need to know the precise system context. That requires detailing the stakeholders’ goals. If the system context is not fully defined then the requirements will also remain incomplete. A system context diagram can help with the analysis. The diagram shows which elements, including foreign systems, agents, rules, norms and standards are found in the planned system’s environment and which are relevant for our understanding of the requirements.
Stakeholders pursue goals. They have simple expectations from a system: it should help them achieve their goals. In order for the system to be successful, it should contain particular characteristics. The description of these characteristics is seen as a goal in the context of these intentions. Representing inter-relationships within goal diagrams helps us to recognize competing or dependent goals and solve goal conflicts with stakeholders.
Context – stakeholders – goals
Iterative Stabilization of Requirements
Diagrams describe various aspects of a system. If you are not making progress with one aspect, then change your perspective. In such cases it can help to develop scenarios for goals. Scenarios answer the question: how can a goal be achieved using a system? Requirements can often be derived from goals and scenarios. They can also, in turn, be described by scenarios in order to create detailed requirements. The process is highly iterative.
Simultaneous Detailing of Requirements
The more requirements come up, the more difficult it becomes to recognize connections and the more difficult it is to get a firm orientation. Derivatives, extensions, participating stakeholders, affected requirements, test cases, system architecture and much more need to be take into consideration. Given that the goal is to obtain requirements that are realizable it makes sense to detail them along with the system architecture. Class and package diagrams from UML and block definition and internal block diagrams from SysML are suitable means to express this.
Detailing requirements simultaneously
Evaluation and documentation of Requirements
The quality of the requirements needs to be evaluated and documented. Coverage, changes, variations and system partitioning are just some of the key words that a relevant in the context of the evaluation. The documentation happens in a requirements specification or a vision document for requirements specification. And once you have illuminated the different aspects with graphical tools then you probably would want to document them, right?
Evaluating and documenting requirements
So in summary, there are six steps that lead to good requirements. They partition the system and analyze the stakeholders. The stakeholders pursue goals, which requirements are derived from. Scenarios can help us to develop a better understanding and can help us come up with new ones. Besides requirements development they also model the system and the requirements that result from it. All of the above should be continually evaluated and documented.
Six steps to good requirements
Conclusion
Requirements engineering dramatically influences the success of a project. At the end of the day IREB e.V. would like to use the six steps to improve practices within requirements engineering and the business analysis. They form the foundation for a combined understanding within a project and among business partners. Communication becomes considerably more efficient when all the participants speak the same language. In this way requirements specifications begin to take form. They allow planning and the development of product tests to improve. These six steps put you on the path to success.