Success based on business - Driven Requirements Engineering

During the development of new software, there are typically some high hurdles to overcome nowadays in terms of the complexity that is involved. However, business-driven software development can be combined especially with requirements engineering to easily overcome these challenges – and thus ensure a solid foundation for sustainable innovation in the company.

Practical example: business-driven requirements engineering

An industrial company is developing a new system consisting of electronics, mechanics and software. Business-driven requirements engineering is introduced in order to position the development closer to the market and reduce the time to market.

An interdisciplinary approach calls for requirements engineering

The introduction process begins by informing the project participants about the reasons for the project, the procedure and the duration. Next, a custom process is defined for the system requirements engineering with a special focus on interdisciplinary considerations. In this manner, interdisciplinary application cases are introduced based on the requirements analysis which depict and simultaneously specify the system functions. The application cases have the benefit of being understandable to all of the employees – no matter whether they are working in business or development departments. This is a major advantage since the preparatory work involves co-operation between business and technology. It is only once the individual application cases have been approved, that the different technical disciplines can create the relevant design documents such as construction drawings, electrical circuit diagrams/layouts, software documents and so on. Based on the new process and with the aid of the corresponding document templates, the requirements engineering is then performed. This represents a major step forward for the organisation, since in the past development was handled in a pragmatic manner by the technical departments and was thus technology-driven. Nevertheless, the conversion was successful. It was possible to successfully introduce the new process and have it accepted by the employees.

Overview of system requirements engineering

Fig. 1: Overview of system requirements engineering

Overview specification

Fig. 2: Overview specification

Success factors for requirements management

1.Initial time is a necessary investment and the tangible benefit will not be seen until later. In this example, just introducing the new process including creation of the templates took four months. Overall, the project lasted about ten months. 2.The employees must be convinced of the value of business-driven development. If the developers are not properly informed, they will begin the development process on their own in the customary manner – without waiting for the requirements from the business end. In order to win employees over to business-driven requirements engineering, it is important to assuage their fears of a flood of paperwork. The benefit for the engineers can be emphasised simultaneously (e.g. the test team has fewer chores since the business end now directly handles acceptance tests). Another benefit is that the requirements are cleanly formulated, and the documentation is reusable for further development efforts and also traceable for regulatory authorities. Most importantly, however, the business end must schedule the resources that are needed for business-driven requirements engineering. In the following example, too, establishing the definitive requirements takes time and attention from many stakeholders and involves a multistage process:

Practical example: business-driven development - requirements engineering with a high level of process maturity

A service company with a high level of process maturity is planning to continue developing an innovative product. An employee from the business end is in charge of overall project management. As the first step, the owner determines the functional scope with the customer and obtains a very rough estimate of the cost. After the project is launched, the business checks and prioritises the features. Next, IT is brought in to examine the feasibility and prepare another cost estimation. It becomes clear that some of the features clearly exceed the project’s budget. Based on the priorities set previously, the business decides which features should be implemented or abandoned. Then, the requirements are refined further. The business analyst is in charge of this job. He carries out workshops with the business end and systematically documents the requirements. The IT department checks the feasibility and costs again. In parallel, the business analyst is already working to define the acceptance criteria. The business analyst creates acceptance test cases right at the start of the implementation. This ensures that acceptance of the software is handled in accordance with the defined requirements. During the realisation process, it becomes clear that the implementation will require fewer resources than were allocated. The business analyst determines together with the business end what should be implemented additionally. When changes occur, too, a cost/benefit analysis is performed prior to the realisation process. After the implementation, the business analyst executes the acceptance test cases and checks whether the application corresponds to the business requirements. In this example, too, establishing the definitive requirements took time and attention from many stakeholders. This is a multistage process. In the example, project goals were first specified, followed by features, which were then refined into business processes and then further into activity diagrams and storybooks which could ultimately be used as the basis for defining the requirements. At the same time, however, the benefits of business-driven development are highlighted. In the end, the business side gets exactly what it wants – all within the specified budget. Moreover, the process is very robust. During development, an optimal response can be found for changes or deviations. Using a process of this sort, companies are ideally equipped to develop complex products with unique customer benefits. At the same time, the benefits of business-driven development are highlighted. In the end, the business gets exactly what it wanted – all within the specified budget. This allows companies to be ideally equipped to develop complex software with truly unique customer benefits.