[SE] Types of requirement in Systems Engineering

Hi there! At beginning of any product development project we normally ask the following question:

How we should specify "exactly" what is expected before we start designing something?

To answer for this question, in my previous article named What is the role of requirements in systems engineering? , I've mentioned to the important role of requirements in systems engineering. To continue this flow, in this article we will investigate some typical requirements in Systems Engineering.

Although various types of requirements can be represented in systems engineering, however from system point of view, there are three main types :

• Business requirements: High-level statements of the goals, objectives, or needs of an organization. They usually describe opportunities or problems that pertain to the organization.
• User requirements: Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. User requirements are often situated midway between the high-level business requirements and more detailed solution requirements.
• System requirements: Usually detailed statements of capabilities, behavior, and information that the solution will need including detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate. System requirements include non-functional requirements, often called quality attributes or "ilities," such as security, usability, testability, and modifiability.

According to [2] , there are two types of systems engineering requirements:

• Top Level (L0 level) Requirements are typically outlined as general capabilities for a system and often originate from external sources, such as set of requirements documents. The first tasks of the System Engineering are to interpret Top Level Requirements in terms of technical and programmatic characteristics of the project, and derive to Level 1 requirements.
• System requirements (L1 level) are derived from Top Level requirements (L0) and describe what the system must do based on the requirements. System requirements describe specific functions necessary within a system to "satisfy" each Top Level requirement. A system requirement must map to at least one use case (see in the Figure 1).

Types of requirement in Systems Engineering

In systems engineering, system requirements are typically categorized into several types, each serving a distinct purpose. Here are the main types:

1. Functional Requirements:

• Define what the system should do. They specify the functions and behaviors the system must perform to meet user needs. Each requirement is a functional one as soon as it can be practically provided with at least one test case. Note that each functional requirement approved for implementation must be realized and successfully tested.
• Example: The powertrain system shall convert electrical energy from the battery to mechanical energy to propel the vehicle.

2. Non-Functional Requirements:

• Describe how the system performs its functions. In other words, they define the quality attributes, system constraints, and overall characteristics of the system. They usually set limitations to the range of possible technical solutions and mostly deal with topics like efficiency, reliability, usability, maintainability, portability, safety, flexibility. Non-functional requirements can be more challenging to measure and verify, often requiring specific metrics, benchmarks, or performance testing..
• Example: The powertrain system shall operate efficiently, achieving a minimum energy conversion efficiency of 90%.

3. User Requirements:

• Capture the needs and expectations of end users. They often focus on the user experience and are expressed in user-friendly language.
• Example: Drivers should be able to select different driving modes (e.g., Eco, Sport) to optimize performance based on their preferences.

4. Interface Requirements:

• Outline how the system interacts with other systems, users, and components. This includes communication protocols and data formats.
• Example: The powertrain system shall communicate with the vehicle's battery management system using a CAN bus interface, transmitting data at 500 kbps.

5. Performance Requirements:

• Define how well the system needs to perform the function. In particular, they specify the speed, response time, throughput, and efficiency of the system under various conditions.
• Example: The powertrain system shall accelerate the vehicle from 0 to 60 mph in less than 6 seconds.

6. Regulatory and Compliance Requirements:

• Ensure that the system adheres to relevant laws, standards, and regulations in the industry.
• Example: The powertrain system shall meet the emissions regulations set by the EPA, ensuring zero tailpipe emissions during operation.

7. Operational Requirements:

• Address how the system will operate in its intended environment, including maintenance, training, and support needs.
• Example: The powertrain system shall include diagnostic capabilities to monitor performance and provide alerts for maintenance needs.

8. Constraint Requirements:

• Identify limitations within which the system must operate, such as budget constraints, technological limitations, or schedule deadlines. Note: the constraints are requirements that cannot be traded off with respect to Cost, Schedule or Performance.
• Example: The weight of the powertrain components shall not exceed 250 kg to ensure vehicle performance and efficiency.

9. Traceability Requirements:

• Facilitate tracking the origin and evolution of requirements throughout the project lifecycle to ensure they are met.
• Example: All requirements related to the powertrain system shall be documented in a requirements management tool, with traceability links to design specifications and test cases.

10. Other requirements: related to human factors, reliability requirements and safety requirements

Note: according to [1], be careful with the use of the term ‘Non-Functional Requirement’. Without further explanation this may be interpreted as a Performance Requirement, but also as a Constraint. The confusion arises because neither Performance Requirements nor Constraints Requirements are functional requirements and so can be referred to being ‘Non-Functional’.

In summary, each of these types plays a critical role in the successful development and deployment of a system, helping ensure it meets stakeholder needs and operates effectively in its intended environment.

Requirement Keywords

The meaning of the following keywords is normally used in requirement documents:

• "Shall" in the text denotes a mandatory requirement. Departure from such a requirement is not permissible without formal agreement. To denote legally binding requirements, it is recommended to use “Must” for these and “Shall” for all other mandatory requirements.
• "Shall not" denotes an absolute prohibition.
• "Should" means that there may exist valid reasons in particular circumstances where the specified behavior is ignored, but the full implications must be understood and carefully weighed before choosing a different course. It is not recommended to use "Should".
• "Should not" means that there may exist valid reasons in particular circumstances where the specified behavior is acceptable, but the full implications must be understood and carefully weighed before choosing a different course. It is not recommended to use "Should".
• "May" denotes a non-binding or “nice to have” requirement (truly optional).
• "Calibratable" in the text denotes that a characteristic shall be adjustable by a parameter. Adjustment of a calibratable parameter is possible during xCU runtime. All calibratables parameters are summarized in the dataset which is related to a dedicated software release.
• "Configurable" in the text denotes that a characteristic shall be adjustable by setting of a parameter which is not necessarily calibratable. Adjustment of a configurable parameter shall be possible in the configuration of a dedicated software component. As the configuration might only be included in the software compiling process a configurable characteristic can not necessarily be changed during xCU runtime. A modification of a configurable characteristic might afford a re-run of the software compiling process. Configurable parameters are usually not visible in the dataset.

Open question:

Is there any difference in meaning between the words "Requirements" and "Specifications"?

Answers:

According to Prof. Olivier L. de Weck's opinion in [4] then his answers are:

• No, they are essentially the same.
• Yes, "requirements" are the input to the design process, while "specifications" are the output.
• Yes, "requirements" specify WHAT the product or system shall/should do; while "specifications" describe HOW the system is build and works.
• Yes, "specifications" include the requirements, but also contain other things such as blueprints, etc...
• Sometimes, I'm not sure

In my understanding after reading from many articles or books, then:

Requirements:

• Definition: Requirements are statements that describe what a system, product, or service must do or the conditions it must meet. They focus on the needs of stakeholders, including users, clients, and regulatory bodies.
• Purpose: Requirements define the scope of the project and guide the development process. They help ensure that the final product meets user expectations and regulatory standards.

Specifications:

• Definition: Specifications are detailed descriptions of how the requirements will be implemented. They provide concrete criteria and technical details necessary for design, development, and testing.
• Purpose: Specifications serve as a blueprint for developers and engineers. They translate requirements into measurable parameters, ensuring that the final product meets the specified criteria.

In conclusion, there is a difference between "requirements" and "specifications," though they are often related and sometimes used interchangeably in conversation. Requirements are about what needs to be achieved (the "what"), while specifications are about how those requirements will be realized (the "how"). Requirements often come first in the development process, and specifications follow as part of the design and implementation phases.

PS: I am looking forward to hearing any different ideas from all of you who are working in system engineering.

References

[1] Link: Systems Engineering Tidbits: Defining System Requirements Well

[2] Link: Capturing requirements by IBM

[3] Book: "Systems Engineering: Principles and Practice" by Alexander Kossiakoff and William N. Sweet.

[4] Lecture: "Fundamentals of System Engineering ", by Prof. Olivier L. de Weck.