Requirements engineering includes several disciplines. Starting with requirements elicitation, documentation, testing and evaluation, up to the continuous management of requirements during implementation, requirements engineering is a complex topic with effects on the entire software project. By using established techniques, the quality of the requirements can be kept high and thus the software project can be designed in the best possible way through clear goals, scope and necessary activities in terms of quality and effort.
Gathered from theoretical knowledge from the International Requirements Engineering Board (IREB) certification and practical expertise from several years of project experience, the following factors for successful requirements engineering emerge:
Best practice approach throughout the requirements analysis process
In order to enable a structured analysis, standard templates and a standard procedure (e.g. according to IREB) serve as a good starting point. Based on experience and best practices, templates and the procedure must be individually adapted for each project. However, the chosen procedure must be followed through for the entire project in order to be able to remain structured, comprehensible and evaluable for the project.
Functional requirements without thinking about solutions
Experience shows that when the requirements are elicited, the solution is often already considered. The department likes to describe its requirements through concrete ideas of how the system should interact with the user. It is important to draw the underlying functional functionality from this without anticipating a possible solution.
Structure and structure of the documentation
Structure and structure are considered to be an essential success factor, as these are often used for the entire duration of the project. Years of experience from various requirements elicitation projects show that no standard structure can be applied to every software project. Depending on the system / project to be specified, the structure must be individually adapted and determined in an early phase of the project.
Review by the department and IT
Despite the primary importance of the requirements for the specialist area, some projects showed the need for IT to review and evaluate the technical requirements. The evaluation by IT and discussion together with the specialist department can often lead to a reduction in the complexity of the system.
Uniform language & third party readability
Due to the diverse participation of various stakeholders in software projects, which can be both internal and external, a uniform language is essential. In order not to allow ambiguities and to reduce coordination efforts through questions, the entire requirements documentation must be readable by third parties.
Holistic view for a complete requirements elicitation
In order to cover the entire scope of the system, it is necessary to use a wide variety of requirements elicitation techniques. In addition to documented externalized knowledge, the implicit knowledge of the actors and employees involved is decisive for the completeness of the survey.
Since the greatest complexity of systems is often found in interfaces, a complete requirements elicitation requires a holistic view of the environment of a system in which both connected and disconnected systems have to be identified.
Correct focus for efficient project success
Both during the requirements elicitation and during the feedback loops, priorities to the requirements can be recorded through a structured procedure, which allows a focus on the most important functionalities in the implementation phase and often already specifies the scope for a minimum viable product (MVP).
Functional scope document enables the software strategy to be changed during the analysis phase – a practical example
Brau Union Österreich AG as part of Brau Union AG is the largest Austrian brewery company. Brau Union AG, 100% owned by Heineken NV, sells a high-quality and diverse portfolio of products and services in the beverage sector. In addition to beverages, Brau Union also successfully sells and serves dispensing systems.
As part of the project, a business process analysis was carried out for the new installation, the reporting of problems and the audit of dispensing systems as well as the recording of operating data and the settlement of service orders. The business processes were collected and modeled in joint workshops. A catalog of requirements for the customer service system to be introduced was created on the basis of the requirements collected as part of the process analysis and the workshops for requirements elicitation. In addition, the current system landscape was analyzed and defined together with the collected functional and non-functional requirements in a scope document created according to ReqPOOL best practice.
With the Heineken software strategy, there was a clear preference for SAP. Despite the change in the group specification, in the last stage of the preparation of the tender documents, no additional effort was required to change the tender documents. This was possible because the tender documents were free from SAP language or solution-specific processes.
High-quality requirements engineering is the basis of a successful project. By using correct and established methods, a comprehensive survey can be ensured and possible problems and changes during the project period can be minimized at an early stage.
With the experienced IREB © standard certified consultants from ReqPOOL, you can lay the most important cornerstone of your software project and thus leverage undiscovered potentials in terms of quality and costs of your project and minimize the risks.