SWDI
Software Requirements, Design and Implementation
Linked Knowledge Nuggets: arrow_forward "8 quick wins for a clean requirements analysis"
personAuthor: Process Fellows
Use a clear requirements template, define ownership, maintain traceability, differentiate between functional and non-functional requirements, apply quality checklists, involve stakeholders early, and ensure version control. And yes – always think: Can I test/ verify this?
personAuthor: Manuel Schmidt, Alexander Feulner
How is modern requirements engineering implemented in practice, and what role does artificial intelligence play across the entire lifecycle—from creation and analysis to the quality assurance of requirements?
Together with our partner Innovigate, the developer of the Tracelane tool, we illustrate this with a practical demonstration. Tracelane is a modern requirements management tool with an intelligent AI assistant that creates, analyzes, evaluates, and provides concrete suggestions for improvement.
school
Webinar recording and slides
arrow_forward "Designing for maintainability from day one"
personAuthor: Process Fellows
Think maintenance when architecting. Clear structures, good naming, minimal duplication, and comments that explain why (not what). Maintainability isn’t added later — it’s built in.
arrow_forward "Requirements are not just for engineers"
personAuthor: Process Fellows
Involve testers, safety experts, UX and product managers in the review. Each brings a unique perspective — and helps uncover hidden assumptions.
arrow_forward "The role of the architect"
personAuthor: Process Fellows
Not a bureaucrat, but a facilitator. Someone who translates goals into structures, moderates conflicts, aligns toolchains, and keeps the big picture stable across sprints and handovers. By the way, this is true for product related architects as well for process architects.
# PROCESS PURPOSE
The purpose is to have a structured and analyzed set of software requirements and a software architectural design available, that software detailed design exists, and (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) are constructed based on the detailed design.
# PROCESS OUTCOMES
O1
The software requirements are specified, analyzed, structured and prioritized
O2
A software architecture design is specified that identifies the components of the software and describes their interfaces and the dynamic interactions between the (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.)
O3
A detailed design is specified for each (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.)
O4 (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) are developed according to the software detailed design
Specify, analyze and structure functional and non-functional software requirements according to defined characteristics for requirements. Prioritize software requirements according to (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) schedule. Note 1: Software requirements can be structured, e.g., by categorizing, grouping, sorting, and prioritizing according to the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) context.
Linked Knowledge Nuggets: arrow_forward "How do I bring levels to my requirement chaos?"
personAuthor: Timo Karasch
First, our processes constantly ask us to specify requirements. Then we have to bother with quite a lot of documents and specifications. Even the relevant literature cannot explain to me in an understandable way what the difference between all these requirements is supposed to be. And finally, an assessor comes and evaluates my specification as insufficient.
This is the end of it! In this webinar we want to bring levels into our requirements chaos. Using simple examples, we will show the different types of requirements and learn a few helpful methods for working with requirements.
school
Webinar recording and slides
arrow_forward "INCOSE Guide to writing requirements v4 - Summary Sheet"
personAuthor: Process Fellows
The INCOSE Guide to Writing Requirements is a comprehensive resource developed by the Requirements Working Group (RWG) of the International Council on Systems Engineering (INCOSE). It provides best practices and structured guidance for writing high-quality requirements in systems engineering. The guide contains
Characteristics of "good" requirements
Writing rules
Boilerplates / templates
Quality aspects for requirement sets
Common pitfalls when specifying requirements
The guide is available for free for INCOSE members, there is a small fee for non-members. The linked summary sheet is available for free for everybody.
school
External link to pdf file published at INCOSE website
arrow_forward "What is the difference between a model, view and a diagram in (system) architecture?"
personAuthor: Process Fellows
In model-based development, it's essential to distinguish between the concepts of "model", "view", and "diagram", as each serves a specific purpose.
A "model" is an abstraction of reality. It represents the complete system description, but only in terms of the essential elements that are relevant to the modeling context. Irrelevant details are deliberately excluded to maintain clarity and focus. The model is considered "complete" not because it includes every possible detail, but because it captures all significant influencing factors necessary for understanding and analysis within its intended scope. Remark: This definition is applicable as well for the various disciplines, e.g. in case a model is used to define a software architecture. If needed, different modelling techniques (e.g. SysML versus UML) might be used for different disciplines.
A "view" focuses on a particular aspect of the model, such as its structure or behavior. Views are tailored to the needs of specific stakeholders, which means that certain details may be intentionally omitted. However, a view never contains more information than the model itself—it is always a subset or projection of the model. The model remains the authoritative source of truth, while views help stakeholders concentrate on what matters most to them.
A "diagram" is a visual representation of a model with respect to a specific view. It helps communicate the model’s content in a clear and accessible way. Multiple types of diagrams can be used to illustrate different views, depending on the aspect being analyzed and the audience’s needs.
BP2
Specify and analyze software architectural design. (
O2 )
Specify and analyze the software architecture including components and their interfaces. Specify static and dynamic views of software architectural components. Determine and document resource consumption objectives.
Linked Knowledge Nuggets: arrow_forward "Analysis of an architectural design"
personAuthor: Process Fellows
The analysis of an architectural design is a substantive examination of the quality of an architecture.
It should never depend on the background knowledge or experience of a single person.
For this reason, the analysis must involve a (interdisciplinary) team of experts, be based on predefined criteria and the analysis method should be documented in a comprehensible manner.
Examples of analysis criteria can be found in the Automotive Spice Guideline, but please do not hesitate to define additional criteria that are appropriate to the task and the environment!
BP3
Specify software detailed design. (
O3 )
Specify the static and the dynamic aspects of the detailed design for each (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.), including their interfaces, relationships and interactions between relevant (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.).
BP4
Develop software units. (
O4 )
Develop and document (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) according to the software detailed design.
# OUTPUT INFORMATION ITEMS
15-51
Analysis result (
O1, O2 )
Identification of the object under analysis.
The analysis criteria used, e.g.:
selection criteria or prioritization scheme used
decision criteria
quality criteria
The analysis results, e.g.:
what was decided/selected
reason for the selection
assumptions made
potential negative impact
Aspects of the analysis may include
correctness
understandability
verifiability
feasibility
validity
Used by these processes:
CSVV Cybersecurity Verification and Validation
PCOM Partner and Collaboration Management
REEL Requirements Elicitation
SWDI Software Requirements, Design and Implementation
SYRD System Requirements and Design
17-00
Requirement (
O1 )
An expectation of functions and capabilities (e.g., non- (Functional requirement = A statement that identifies what a product or process must accomplish to produce required behavior and/or results.)), or one of its interfaces
from a black-box perspective
that is verifiable, does not imply a design or implementation decision, is unambiguous, and does not introduce contradictions to other requirements.
A requirements statement that implies, or represents, a design or implementation decision is called “Design Constraint”.
Examples for requirements aspects at the system level are thermal characteristics such as
heat dissipation
dimensions
weight
materials
Examples of aspects related to requirements about system interfaces are
connectors
cables
housing
Examples for requirements at the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) level are
lifetime and mission profile, lifetime robustness
maximum price
storage and transportation requirements
functional behavior of analog or digital circuits and logic
quiescent current, voltage impulse responsiveness to crank, start-stop, drop-out, load dump
temperature, maximum (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) heat dissipation
power consumption depending on the operating state such as sleep-mode, start-up, reset conditions
frequencies, modulation, signal delays, filters, control loops
power-up and power-down sequences, accuracy and precision of signal acquisition or signal processing time
computing resources such as memory space and CPU clock tolerances
maximum abrasive wear and shearing forces for e.g., pins or soldering joints
requirements resulting from lessons learned
safety related requirements derived from the technical safety concept
Used by these processes:
CSVV Cybersecurity Verification and Validation
REEL Requirements Elicitation
SWDI Software Requirements, Design and Implementation
SYRD System Requirements and Design
17-54
Requirement attribute (
O1 )
Meta-attributes that support structuring and definition of (Release = A physical product delivered to a customer, including a defined set of functionalities and properties.) scopes of requirements.
Can be realized by means of tools.
Note: usage of requirements attributes may further support analysis of requirements.
Used by these processes:
REEL Requirements Elicitation
SWDI Software Requirements, Design and Implementation
SYRD System Requirements and Design
04-04
Software architecture (
O2 )
A justifying rationale for the chosen architecture.
Individual functional and non-functional behavior of the (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.)
Settings for (Application parameter = An application parameter is a software variable containing data that can be changed at the system or software levels; they influence the system’s or software behavior and properties. The notion of application parameter is expressed in two ways:
The specification (including variable names, the domain value range, technical data types, default values, physical unit (if applicable), the corresponding memory maps, respectively).
The actual quantitative data value it receives by means of data application.
Application parameters are not requirements. They are a technical implementation solution for configurability-oriented requirements.) (being a technical implementation solution for configurability-oriented requirements)
Technical characteristics of interfaces for relationships between (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.) such as:
Synchronization of Processes and (Task = A definition, but not the execution, of a coherent and set of atomic actions.)
Programming language call
APIs
Specifications of SW libraries
Method definitions in an object- oriented class definitions or UML/SysML interface classes
Callback functions, “hooks”
Dynamics of (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.) and software states such as:
intercommunication (processes, (Task = A definition, but not the execution, of a coherent and set of atomic actions.), threads) and priority
time slices and cycle time
interrupts with their priorities
interactions between (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.)
Explanatory annotations, e.g, with natural language, for single elements or entire diagrams/models.
Used by these processes:
SWDI Software Requirements, Design and Implementation
04-05
Software detailed design (
O3 )
Elements of a software detailed design:
Control flow definition
Format of input/output data
Algorithms
Defined data structures
Justified global variables
Explanatory annotations, e.g, with natural language, for single elements or entire diagrams/models
Examples for expression languages, depending on the complexity or criticality of a (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.):
natural language or informal languages
semi-formal languages (e.g, UML, SysML)
formal languages (e.g, model-based approach)
Used by these processes:
SWDI Software Requirements, Design and Implementation
11-05
Software unit (
O4 )
Can be
a representation of a (Software element = Refers to software component or software unit) at the lowest level in a conceptual model, which is decided not to be further subdivided and that is a part of a (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.), or
a representation of a (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) under (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) such as commented source code, auto-code, an object file, a library, an executable, or an executable model as input to (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.)
Used by these processes:
SWDI Software Requirements, Design and Implementation
SWDI
Software Requirements, Design and Implementation
