Software requirements engineering involves eliciting, documenting and managing requirements for IT projects. Nowadays, software and other IT projects tend to exhibit a high degree of complexity and involve the participation of stakeholders from many different departments who will typically have different requirements and expectations vis-à-vis the project. Requirements engineering (requirements management) is used to minimise the complexity and keep a clear view of the project’s intended outcome so as to guarantee the project’s ultimate success.
Requirements management and requirements development
The goal of requirements management is to achieve a mutual understanding between the customer and the supplier of the new product. The result comes in the form of a sort of agreement that is continuously revised and verified. Requirements management thus forms the basis of requirements engineering. The second subdiscipline is requirements development, which involves systematic compilation and definition of the requirements by the requirements engineer. The process traditionally includes the four steps of elicitation, analysis, specification and validation (see Fig. 1). Different techniques can be applied in all four of these phases.
Fig.1: Requirements management
Practical example: Requirements development and requirements analysis
A service company would like to develop a new version of its main software. Several different elicitation techniques are used as part of the requirements development process. • Field observation: Different users of the software are observed during their daily work. This is to establish, for example, how they organise their work and the associated documents, how long they take to perform each work step, which activities each employee handles on his own, for which activities he calls for support from colleagues, and so on. • Workshops: Together with stakeholders from different departments who all use the system, workshops are held and the future usage of the system is discussed along with future processes. Existing, real-world processes are elicited along with the desires of the different users vis-à-vis the new system. • Use case method: This is applied here in order to depict processes. One essential task in the field of requirements analysis involves analysis of which of the three levels (business, system or technology) certain requirements are associated with. Such categorisation is important since the stakeholders themselves will not consider it in many cases. Any commingling is problematic since there are different persons in charge of the three levels, different stakeholders are affected and the context is also different in each case (see Fig. 2).
Fig. 2: Levels
Practical example: Requirements analysis and management - usage of prototypes
An industrial company is developing a new solution to support its core process. The system will provide support to a number of different players along the added value chain. Consolidating the diverse expectations and coming to a solid decision is far from straightforward. In this case, the requirements are systematically elicited, analysed and specified. A prototype is developed on this basis for validation purposes. The stakeholders then provide feedback in response to the prototype. This approach makes it possible to significantly improve the quality of the requirements. Modelling of graphical user interfaces (GUIs) as prototypes has proven to be an effective approach in other projects too. What is important here is for the provisional nature of the GUI prototype to be obvious so the stakeholders do not feel a need to criticise the details, but focus on the essential elements.
It is a general rule that the better an organisation handles requirements management, the more readily it will take further development steps to tackle more complex projects. The next two blog posts will examine two such steps: outsourcing development activities and conversion to business-driven IT.