EN 
DE Introduction of requirements- and model-driven development
Author: Kai Gloth, Sartorius Lab Instruments
Contribution – Embedded Software Engineering Congress 2017
There are countless books and guides for every aspect of product and instrument development and the associated processes. If I search for the term on Amazon... Requirements Engineering, I was confronted with well over 2,000 results. Every aspect is covered in the standard works, classics, and new publications. For every tiny detail, there are multi-page analyses, all of which—provided they are read in detail—are intended to prepare the reader for every possible situation. This is precisely what I did. When I was tasked in 2014 with initiating the development of a new device, I questioned virtually every aspect of the development process and, with the help of books, tried to work out how these individual steps and the entire development process could be improved. My plan was, in particular, to establish requirements engineering and, as far as possible, model-driven development in all areas.
This article deals with things I didn't learn from books. It's about the problems I encountered in my daily work. Sometimes I was able to solve these problems successfully, and sometimes not at all.
The team I worked with had successfully developed the predecessors of the devices, consisted almost entirely of senior developers, and some had been with the company for several decades. From the development team's perspective, there was therefore no reason to fundamentally change the development process. The product development process in instrument development follows the V-model. However, elements of agile and iterative development processes were to be reused. The entire "V" is therefore not traversed in a single waterfall-like fashion, but rather follows an iteration over a specific period. For the sake of clarity, this article also follows the levels of the V-model and highlights the individual aspects. See Figure 1 (PDF).
User Requirements Specification – URS
The User Requirements Specification (URS) represents the requirements for the product or instrument from the user's perspective. Every stakeholder—that is, every person or group of people with an interest in the product—should be identified, considered, and prioritized. Requirements engineering is not complicated or time-consuming. In my experience, the discipline of requirements engineering consists of two sub-areas:
The first section deals with creating the metamodel, or information model. This means determining the value or properties of different pieces of information and how to proceed with them. For example, an idea pool. Each idea has only a heading and is rated using a school grading system. However, ideas do not represent product requirements; they merely support the requirements gathering process.
The second area encompasses the actual writing, review, and proofreading of requirements. In my experience, an information model should be as simple as possible and understandable for everyone, meaning it should contain as few artifacts and rules as possible. This has several advantages. Firstly, it lowers the barrier for individual team members to formulate requirements; secondly, it remains flexible enough to allow for local adjustments. User-level requirements are often used to resolve internal conflicts, particularly between the marketing, product owner, and R&D departments, but also to capture or demand every possible detail in the requirements. When requirements engineering is introduced as a discipline, it is crucial to sharpen and continuously review the understanding of the level of detail among all involved parties. The level of detail is so difficult to determine because there is often no clear yes or no answer. A detail, such as the use of a specific technology or stainless steel for a housing, may seem completely irrelevant from a user's perspective at first glance, but on closer inspection, it could also be a general prerequisite or a specific requirement from certain customers.
I recommend avoiding a dogmatic approach! What a team actually wants to achieve is a shared understanding of the requirements, without unnecessary effort on the part of both the requirement providers and the implementation team. Requirements should be formulated in a solution-neutral way. However, if there is a specific reason to formulate a concrete solution, then that is perfectly acceptable. Involve the team in actively shaping the requirements. Understanding user requirements is already the first step in the development process. Furthermore, I recommend good tools to easily capture requirements and track changes over time. Theoretically, using office tools would be possible, but I would advise against it. I have had good experiences with Team Foundation Server and Polarion.
Functional Requirements Specification – FRS
The User Requirements Specification (URS) describes the desired requirements from the stakeholders. The Functional Requirements Specification (FRS) contains the response or initial solution approach from the development team. In official German, the URS and FRS would also be referred to as specifications and requirements documents. It's important to understand that the responsibility reverses here. The stakeholder or product owner is responsible for the URS, and it must be ensured that the development team understands the requirements. The development team is responsible for the FRS. In this case, it must be ensured that the stakeholder, user, and product owner all agree to and understand the proposed solution.
In my experience, this level is ideal for getting started with a modeling language like UML. Use case and activity diagrams, in particular, provide a good platform for functionally structuring the proposed system and reaching an agreement on the functionalities to be implemented using just a few words and elements. However, over-detailing the diagrams is dangerous. The goal is to illustrate the desired functionality without going into technical details.
It is also important to understand that a functional breakdown of the system is not the same as a technical breakdown. For example, a use case diagram might describe all user management functions, including creating new users, while the technical implementation involves distributing the function across several subsystems, such as user management, the database layer, and the authentication service.
In the field of embedded systems, I recommend designing and developing functions independently of the discipline. To stick with the example of user management, I also consider fingerprint authentication as part of this group.
When using an ALM tool like Polarion or Team Foundation Server, the strength of such a tool becomes apparent for the first time. Requirements from the URS can be linked to elements of the FRS if these elements are derived from or originate from the requirements. If requirements are modified, the tree-like structure allows me to see which elements in the FRS are affected.
Design Specification – DS
The Design Specification contains the concrete documentation regarding the technical implementation. Both the URS and FRS primarily serve to agree on the "what." The DS contains the concrete "how.".
In my experience, this document is very well suited for conducting coordination, especially within large teams. I would therefore consider it a growing and constantly evolving document until change control becomes necessary within the project. I recommend limiting the majority of communication to UML or SysML and using as little written text as possible. Component, Use Case, Class, and Object Diagrams, as well as Block Definition, Internal Block, and Package Diagrams, have proven effective in practice. This interplay of different types allows for a unified view of all disciplines within coherent diagrams. Component Diagrams, for example, make it possible to show which software component controls which actuator or sensor, or which software module runs on which processor. In particular, shared documentation, independent of the technical discipline, is a significant advantage. It fosters an understanding of changes, interrelationships, and complexity on all sides, allows for better risk assessment, and provides the team's testers with a more comprehensive overview.
I recommend initially focusing solely on the documentation aspect when using UML and SysML. Often, the term "code generation" is used immediately after the keyword "UML." In my experience, this results in an insignificant, and in many cases unjustified, additional effort that a developer has to invest in creating the diagrams.
Overall, I recommend continuously reviewing the level of detail in the documentation, and especially in the diagrams. In my experience, the purpose of documentation is to simplify communication between developers, clarify general concepts, and facilitate the onboarding of external or new developers. Any level of detail beyond this is, in my opinion, not justified and, unless the application area or market demands it, also unnecessary.
I frequently observe situations where the initial draft of the documentation is excellently written, but over time, especially as project pressure increases, it drifts further and further away from the actual implementation. A code and architecture review tool like Axivion has proven to be exceptionally effective. Such a tool regularly checks the code and compares it to the documentation. Axivion uses UML as input. This allows the team to assess the quality of the implementation and documentation, fostering trust when software is audited by third parties.
For creating UML diagrams, I recommend Sparx Enterprise Architect. Connectors between ALM tools, such as Polarion or Team Foundation Server, are also available on the market.
Testing and risk management
Testing and risk management are not specifically addressed in this article. My experience in these areas is similar to other sections. In particular, the documentation using UML or SysML was a helpful input from the test team and greatly simplified their work. Furthermore, I recommend viewing the test team as an integral part of the overall team. Feedback from testers and test designers is crucial at all levels, from the initial user review (URS) to the final test design (DS), and should be continuously considered.
Risk management is also simplified with the help of well-structured documentation. Changes and their effects can be better tracked and provide important input for both risk assessment and test scope.
author
Kai Gloth currently works as an R&D Systems Engineer, managing international interdisciplinary projects and teams. He places particular emphasis on transparent development and a common technical language across different technical disciplines and stakeholders.
Software Engineering Management – our training courses & coaching sessions
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Software Engineering Management / process, project and product management.
Training & coaching on the other topics in our portfolio can be found here. here.
Software Engineering Management – Expertise
Valuable expertise in software engineering management / process, project and product management is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
