EN 
DE Requirements Engineering and Management – What can I do?
Author: Thomas Batt, MicroConsult GmbH
Contribution – Embedded Software Engineering Congress 2017
Capturing and managing requirements is a key to successful projects. Whether in a traditional or agile process environment, professional requirements engineering and management for embedded and real-time systems shortens your project timelines and saves on development and maintenance costs. Take on this challenge!
The checklist underlying this article was created based on my professional experience and the execution of numerous seminars and coaching sessions on requirements engineering and management (see below). PDF, Image 1).
This checklist is designed to show you what you can introduce, implement, and optimize regarding requirements in your company. It is also a treasure trove of valuable practical tips.
The following article addresses each item on the checklist in turn and explains the background. Important for understanding: Where the term "system" is used, it can be replaced by other domains such as embedded software or hardware.
The Requirements Engineering and Management Checklist, along with the associated documentation, is available for download at [1].
Requirements Engineering – Identifying, documenting, and managing requirements
Separate requirements (WHAT) from implementation (HOW).
Distinguish between requirements, both conceptually, in writing, and organizationally. Requirements refer to the WHAT, and implementation to HOW. Only in a few justifiable cases do requirements not include a HOW.
Identify and represent the requirement context
Define the system to be required against its context in order to identify the external interfaces and thus the associated requirements.
(see. PDF, Image 2)
For a context view, the use-case diagram from UML (Unified Modeling Language) or SysML (Systems Modeling Language) is suitable as a graphical notation [5].
Capture requirements in textual form
The basis for everything else in development and testing are the requirements. You should capture these in textual form and, if necessary, supplement them with other forms of representation such as graphics and diagrams. To date (2017), no alternative notation method has been invented that can completely replace textual requirements capture.
Apply requirement templates
Use requirement templates [8] to achieve a very high level of requirement quality when writing the requirements.
Requirement template for autonomous system activity:
[When?] [Under what condition?] MUST | SHOULD THE SYSTEM
.
Request template for interactive system activity:
[When?] [Under what condition?] MUST | SHOULD THE SYSTEM OFFER THE OPPORTUNITY, .
Requirement template for potential system activity:
[When?] [Under what condition?] THE SYSTEM MUST | SHOULD BE CAPABLE,
.
Use natural language methods
To further improve the quality of the requirements, apply the natural language method [8] in addition to the requirement templates. This allows you to reverse the deletions, generalizations, and distortions that occur during the expression of knowledge.
Define and consider the required quality characteristics
Each requirement must meet the following quality characteristics: complete, correct, understandable, necessary, consistent, traceable, feasible, classified as binding, testable and [optional] atomic.
Product, project, and platform requirements differentiate
Be aware of these requirement categories:
Product requirements:
Requirements that describe the performance characteristics, capabilities, and properties of the product currently being developed.
Project requirements:
Requirements from project management, such as timelines, costs, scope of delivery and logistics
Platform requirements:
Requirements that are always valid for multiple products or for this product group -> Reusability of requirements
Differentiate between functional, non-functional, and assurance
Be aware of these types of requirements:
Functional requirements:
Externally visible/observable functionalities
Non-functional requirements:
Qualities, quality characteristics of individual functional requirements or of the entire system
Assurances as requirements:
Standards, norms, processes, technical assurances, project requirements
Define and record quality requirements
Describe not only functional requirements, but also their qualities and the qualities of the entire system.
Quantifying (abstract) quality characteristics
Quantify abstract quality attributes such as reusability. "The embedded software must be reusable." -> "The embedded software must be reusable to level 4." You only need to specify the different levels once. This clarifies what the embedded software must meet.
For specific quality characteristics, such as the power consumption of a system, you can directly set the value with a unit.
Make (abstract) quality characteristics testable / verifiable
In the grade specification described above, you and the test team also describe the testability / verifiability for fulfilling the (abstract) quality characteristic.
For specific quality characteristics, such as the power consumption of a system, testability/verifiability is usually clear.
Deriving valid requirements from standards
Standards and norms do not always directly contain the requirements for the product. Rather, the texts often allow for a certain degree of interpretation. Therefore, it is all the more important that you derive the specific requirement texts from the standards and norms applicable to your products and coordinate these with the consulting services of the certifying organizations before implementation.
Maintain the requirements glossary as part of the project glossary.
If you use nouns, verbs, adjectives, or abbreviations in your requirements documents that are not familiar to stakeholders, you must explain these terms in a glossary. Maintain a single glossary for the entire project instead of several different ones to avoid redundancy and inconsistency.
Process, procedure, method
Establish requirements at all development levels
Implement requirements engineering and management not only for customer and system requirements, but for all development domains, e.g., subsystems, hardware, embedded software, software, design, etc.
(see. PDF, Image 3)
Define workflows, activities, artifacts, and roles
Whether you live traditional [3] or agile [4] processes, define clear workflows with precisely named activities, their incoming and outgoing artifacts, and their responsible roles.
Creating understanding and commitment to requirements
Especially when introducing requirements engineering and management in pilot projects, it is important to establish a shared understanding and a high level of motivation, knowledge, and agreement among all participants. Involve skeptics selectively, for example, in engineering meetings.
Analyze the current state of existing products
Based on the experience gained with the predecessor products, you derive requirements for the new product.
Identify and analyze stakeholders
Stakeholders are individuals and institutions that have a legitimate interest in the new product. Not only the product manager should carefully consider potential stakeholders, but also those responsible for requirements at subsequent development levels.
Select and document stakeholders
Select individual representatives from the identified stakeholder groups and document your selection.
Conduct stakeholder interviews
Schedule interviews with the selected stakeholder representatives and ask them about the requirements topics you have prepared. Learn and practice interview techniques. Knowledge of NLP (Neuro-Linguistic Programming) will be helpful in this regard [7].
Deriving requirements from interview results
Derive specific requirements from the interview results.
Coordinate requirements with client/stakeholders
In the next iteration, coordinate the requirements derived from the interview results with the stakeholders.
Analyze and model requirements
As part of the analysis, model the requirements. This will reveal inconsistencies and incompleteness, and lead to a better understanding of the subject matter. In addition to the context view, you will develop functional requirement views, interactive and generic behavioral views. For the notation, refer again to UML / SysML [5]. To uncover further requirements, conduct a failure analysis based on the resulting views.
Simulate and execute requirements
With the help of tools and appropriate preparation, you execute the requirements model and thus simulate the requirements. You then use the simulation results to improve the quality of the requirements.
Check the feasibility of the requirements
One quality criterion for requirements is their feasibility. If even a subject matter expert cannot assess the feasibility, you must commission a feasibility study. This will determine the feasibility.
Create a prototype (disposable or evolutionary).
The prototype created by the prototyping team provides concrete information about the feasibility of the requirement. Discard the disposable prototype; incorporate the evolutionary prototype into the product. Agree on the type of prototype before creating it and document the result in writing. Note that a disposable prototype must never evolve into an evolutionary prototype!
QA: Conducting Reviews
Conduct reviews of the textual and modeled requirements with selected stakeholders. Use the review results to improve the quality of the requirements.
QA: Execute functional and quality scenarios
Functional scenarios: Analyze typical and atypical functional processes against the system's interfaces using "paper and pencil" or with the aid of a tool such as UML/SysML notation [5]. This analysis is based on your current understanding of the system. Check the consistency and completeness of the requirements for the processes. As a secondary benefit, you can also use these functional scenarios as test scenarios against the external interfaces (system test).
Quality scenarios: Analyze which realistic and concrete scenarios arise for (abstract) quality characteristics of the system. For example, the abstract quality characteristic of portability in embedded software results in several dimensions: portability related to hardware, operating system, communication, and middleware. For all relevant dimensions, develop realistic scenarios, e.g., hardware porting from microcontroller A to microcontroller B, and include these as requirements.
Ensure consistency between requirements and implementation
Continuously compare the implementation with the requirements. If errors occur, correct the requirements. If requirements change, check the implementation. At the very latest by the end of the project, the system should exactly reflect the implementation of the requirements – no more and no less.
Develop acceptance criteria/test cases for each requirement.
The test team equips each requirement with at least one test case. The separation of tasks between the testers (four-eyes principle) has a positive impact on the quality of the requirements. By subsequently executing the test case, the tester demonstrates that the requirement is implemented in the system. No requirement exists without a test case. Conversely, any requirement without a test case is invalid.
Establish continuous, proactive risk management
Throughout the project, the project management team maintains a risk tracking document in which project participants enter the identified risks.
(see. PDF, Image 4)
To avoid stating the probability of occurrence P and the extent of damage S based on gut feeling, you must define concrete values and units for P and S.
Establish a change process for requirements
During development, requirements change frequently for a variety of reasons, new ones are added, and existing ones are removed. You should define a process in which a team evaluates the consequences of the change (impact analysis) and makes a final decision. If the decision is against the change, you should save the requirement for the next product.
Learning from mistakes
Make sure you don't make the same mistakes (in requirements gathering) multiple times – Lessons learned.
Continuously improve processes, procedures, methods, and tools
Every new project offers the opportunity to continuously improve the process and everything that goes with it. Note down the areas for improvement during the project (project log) and adapt the process before the next project..
Requirements Management – Managing, tracking, and linking requirements
Reuse requirements
Especially in companies that develop the same or similar products repeatedly, reusing requirements is advantageous. One approach is the minimal platform concept: separating the requirements common to all products as platform requirements and referencing them in the individual product requirement set. An alternative is the maximal platform concept. The maximal platform contains all requirements for all products. For new products, you reference the corresponding valid and versioned requirements.
Parameterize requirements
Even in the context of requirement reuse, you can populate requirement text with variables and units whose values you can adjust individually for each product in their parameter lists, e.g., the maximum power consumption P.max in the Wadden Sea.
Define requirement properties (attributes).
Equip your requirements with properties that are actually useful to you. Sometimes less is more. Besides a unique ID (e.g., REQ-EMB-SW_000001) for identification and referencing, each requirement should also have a status (e.g., in progress / released / implemented / tested). You must maintain all properties; otherwise, they are useless.
(see. PDF, Image 5a and 5b)
Establish a versioning of requirements
The version as a property of the requirement allows you to track its development and evolve requirements further in the future.
Establish baselining/releases for requirements
At a defined point in the project timeline, you document the current maturity of the requirements for further implementation.
Establish bidirectional traceability across all development stages
In standards applicable to safety-critical systems, bidirectional traceability (linking) between requirements, through implementation, and up to the test case is usually required. Achieving this across different development domains and their various tools is the main challenge – tool integration, standards such as ReqIF [5] and STEP [7].
Provide templates for artifacts
Provide templates for the artifacts in your process. This ensures that the same artifact types (e.g., requirements specifications) always look the same, thus improving understanding. The predefined content prevents you from overlooking any points that need addressing. Standards already exist for many artifact types.
Requirements Management Tools
Text verse. Evaluate Application/Product Life Cycle (A/PLM) tools
Basically, when choosing tools, you have to decide between purely text-based or database-oriented tools. The complexity of your products will continue to increase. The more requirements and other artifacts you have to manage, the better database-oriented tools will support you.
Select tool based on requirements
There is no single "best" tool on the market. At best, there is the tool that best meets your specific needs and requirements. When selecting a tool, remember the following order: first the person, then the method, and then the tool! Tool selection should not be a company policy decision.
Integrate, test, and train on the tool
Integrate and test the selected tool before the project begins. To counteract potential user rejection, users should receive training before using the tool.
Establish this tool in daily work
Establish the tool across multiple departments. A continuous learning and improvement process should be implemented here as well.
Summary
For each checklist item, you need to weigh the associated benefits against the implementation effort. The best items for you are those with high benefits and low implementation effort.
Referenced and further links
[1] MicroConsult Download for this article – complete and up-to-date
- Requirements engineering and management for embedded systems
- Functional safety (safety) of electronics and their software implementation according to ISO 61508 and ISO 26262
- Security: Security of embedded systems in the context of functional safety
- Usability: Developing user-friendly products
- SysML: System analysis and system design with the Systems Modeling Language
- UML Practical Workshop: Practical Application for Embedded and Real-Time Software Development
[3] V-model
[4] Agile Manifesto
[5] Object Management Group (OMG)
[6] STEP (Standard for the Exchange of Product Model Data) ISO 10303
[7] Neuro-Linguistic Programming
[8] Technical literature: Requirements Engineering and Management
SOPHIST GmbH, HANSER Verlag, Print ISBN: 978-3-446-43893-4, E-Book ISBN: 978-3-446-44313-6
Author:
Thomas Batt, Dipl.-Ing. (FH), is a native of Freiburg. After training as a radio and television technician, he studied communications engineering in Offenburg. Since 1994, he has worked continuously in various industries and roles in the field of embedded/real-time system development. In 1999, Thomas Batt joined MicroConsult GmbH. There, as a certified trainer and coach, he is currently responsible for the areas of systems/software engineering for embedded/real-time systems, as well as development process consulting.
Requirements – MicroConsult Training & Coaching
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 requirements/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Requirements – Expertise
Valuable expertise in the field of requirements/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
