Select Page

Requirements Engineering and Management Part 2: Process, Procedure, Method

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!

After defining the requirements using a Checklist in Part 1 Read below to learn how to design the process, procedure and methodology for requirements engineering and management.

Establish requirements at all development levels

Implement requirements engineering and management not only for customer and system requirements, but for all development domains, such as subsystems, hardware, embedded software, software and design.

Requirements Levels - Requirements Management

Figure 2: Requirements levels

Define workflows, activities, artifacts, and roles

Whether you prefer traditional (V-Model XT) or agile To apply processes, first 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 within companies, it is crucial to establish a shared understanding and a high level of motivation, knowledge, and agreement among all participants beforehand. If there are any skeptics, involve them proactively, for example, in engineering meetings.

Analyze the current state of existing products

Based on the experience you have gained with the predecessor products, you can 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 you have prepared. Learn and practice interview techniques. Knowledge of NLP will be beneficial here (Neuro-linguistic programming).

Deriving requirements from interview results

Then 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 uncover inconsistencies and incompleteness, leading to a better understanding of the subject matter. In addition to the contextual view, you will develop functional requirement views as well as interactive and generic behavioral views. The following notation will be helpful for this: UML / SysML. To uncover further requirements, conduct a fault analysis based on the observations made.

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 further 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 validate the project's 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 together with selected stakeholders. Use the review results to then 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, either manually or using UML/SysML notation. This analysis should be based on your current understanding of the system. Verify the consistency and completeness of the requirements for these processes. As a secondary benefit, you can also use these functional scenarios as test scenarios against the external interfaces (system testing).

Quality scenarios:
Analyze which realistic and concrete scenarios arise for the system from (abstract) quality characteristics. 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 personnel (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.

 Risk Tracking - Requirements Management

Figure 3: Risk tracking document

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. For these situations, 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.

Everything about Requirements Engineering and Management

Get in MicroConsult Seminar on Requirements Engineering and Management The necessary knowledge to develop and document high-quality requirements and corresponding acceptance criteria. The recently revised version of the seminar is based on over 10 years of practical coaching and seminar experience.

Learn more in seminar, how to assess and improve the quality of existing requirements, how to introduce, evaluate, optimize, understand and implement a requirements process in your company, and how to make informed tool decisions for managing requirements.

Read in Part 3 everything about the Managing, tracking, and linking requirements.

Part 1 This series highlights the Defining the requirements.

Further information

MicroConsult expertise in process management

MicroConsult Training & Coaching on the topic of process management

Seminar: Requirements Engineering and Requirements Management

Read more:

Part 1: Requirements – A checklist for maturity?
Part 3: Managing, tracking, and linking requirements

Featured image: Adobe Stock

MicroConsult Newsletter

With the MicroConsult newsletter, you'll stay on the pulse of the embedded world. Look forward to proven practical knowledge, real professional tips, and current events – directly from our experts for your project success.

Subscribe now!

Published by

Thomas Batt

Thomas Batt