5. Requirements Engineering, Systems Engineering and Product Architecture

Introduction and Context

A product is successful not merely because it performs a technical function, but because it satisfies a coherent set of stakeholder needs throughout its life cycle. A medical device must be safe and usable; an aircraft component must meet performance, certification, maintainability, and cost requirements; an industrial robot must integrate mechanically, electrically, computationally, and operationally. These expectations are often expressed initially in ambiguous language and then transformed into technical requirements, system functions, architecture, interfaces, and verification evidence.

Requirements engineering, systems engineering, and product architecture provide the intellectual and practical foundations for this transformation. Requirements engineering determines what a product must achieve and under what conditions. Systems engineering establishes an interdisciplinary process for translating needs into an integrated system solution. Product architecture defines how functions and responsibilities are allocated to physical and digital elements and how those elements interact.

Within Product Lifecycle Management (PLM), these activities provide the structure linking market research, design, simulation, manufacturing, service, regulatory compliance, and retirement. Their integration is especially important for complex products whose performance depends on interactions among mechanical, electrical, software, human, and organizational elements.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain the purpose, characteristics, and life cycle of engineering requirements.

2. Distinguish stakeholder, system, subsystem, interface, constraint, and derived requirements.

3. Construct a requirements traceability framework and distinguish verification from validation.

4. Apply systems engineering processes, functional decomposition, and allocation techniques.

5. Explain product architecture, modularity, interfaces, platforms, and architectural trade-offs.

6. Describe the role of MBSE and SysML in representing requirements, behavior, structure, and traceability.

7. Evaluate practical risks, governance issues, and implementation challenges in multidisciplinary development.

Requirements as the Contract for Product Development

A requirement is a necessary capability, condition, or constraint that a product, process, or service must satisfy. Requirements differ from design solutions. “The vehicle shall provide a minimum driving range of 400 km under the specified test cycle” is a requirement; “the vehicle shall use a 100 kWh battery” is generally a design decision unless the battery capacity itself is mandated.

A good requirement is unambiguous, necessary, feasible, verifiable, traceable, and sufficiently precise. It normally identifies an object, an action or property, and measurable performance or conditions. The word “shall” is commonly used for mandatory requirements, while “should” indicates a recommendation and “may” indicates permission or an option. Poorly written requirements use vague expressions such as “user-friendly,” “adequate strength,” or “rapid response” without defining measurable interpretation.

Requirements arise from several sources:

• stakeholders, customers, operators, maintainers, and communities;
• laws, standards, certification rules, and organizational policies;
• physical principles, environmental conditions, and safety obligations;
• interfaces with other products, infrastructure, and information systems;
• business objectives, cost limits, schedules, and sustainability targets.

Stakeholder requirements express expectations in the language of users or organizations. System requirements convert those expectations into measurable technical statements. Subsystem requirements are allocated to particular elements. Derived requirements emerge when analysis shows that an unstated condition is necessary to meet a higher-level requirement. For example, a requirement for autonomous braking may generate derived requirements for sensor availability, processing latency, diagnostic coverage, actuator response, and degraded-mode behavior.

Requirements are also classified as functional, performance, interface, environmental, safety, security, regulatory, operational, maintainability, and lifecycle requirements. The classification is useful for analysis but should not create artificial separation. A thermal requirement may affect performance, safety, reliability, packaging, and maintenance simultaneously.

Quality Attributes of Requirements

Requirements quality can be assessed through several questions. Is the requirement necessary? Is its meaning interpreted identically by different readers? Can compliance be demonstrated by inspection, analysis, test, or demonstration? Is it feasible within available technology, cost, schedule, and resources? Does it conflict with another requirement? Is its origin known, and can changes be propagated to affected design elements?

A requirement should generally contain a measurable threshold, a tolerance where appropriate, and the conditions under which it applies. For example: “The actuator shall reach 90 percent of commanded position within 0.25 seconds at loads between 0 and 80 percent of rated load, over an ambient temperature range of −20°C to 50°C.” This statement is more useful than “the actuator shall respond quickly.”

The Requirements Engineering Process

Requirements engineering is not a single documentation activity. It is a managed process involving elicitation, analysis, specification, validation, allocation, change control, and continual feedback.

Elicitation and Stakeholder Analysis

Elicitation identifies expectations that may be explicit, tacit, conflicting, or technically uninformed. Interviews, observation, workshops, operational scenarios, customer-journey mapping, benchmarking, field data, regulatory review, and quality-function deployment can all contribute. Direct users may emphasize usability, while maintainers emphasize access and diagnostics, and production engineers emphasize assembly and process capability.

Stakeholder analysis identifies influence, responsibility, risk exposure, and competing interests. A requirements workshop should not simply collect the loudest stakeholder’s preferences. It should expose assumptions and distinguish mandatory needs from desirable features.

Analysis, Negotiation, and Specification

The engineering team analyzes feasibility, interactions, conflicts, and risk. Trade studies may compare alternative performance levels or architectures. Requirements are then specified in a controlled repository or PLM environment, with attributes such as owner, rationale, source, priority, status, verification method, risk, and configuration baseline.

Negotiation is often unavoidable. Increasing payload may reduce range; improving stiffness may increase mass; adding redundancy may increase cost and complexity. A defensible decision records the alternatives considered, assumptions made, criteria used, and authority approving the decision.

Verification and Validation

Verification asks: “Was the product built right?” It demonstrates that a product or design output conforms to specified requirements. Validation asks: “Was the right product built?” It demonstrates that the resulting product satisfies intended use and stakeholder needs in its operational context.

Typical verification methods are inspection, analysis, test, and demonstration. Inspection may confirm dimensions or documentation. Analysis may use finite-element, thermal, reliability, or performance models. Test generates empirical evidence under controlled conditions. Demonstration shows operation through observation, often without precise instrumentation. A single requirement can require more than one method.

Validation is broader than checking individual requirements. A system may pass component tests and still fail in operation because users misunderstand the interface, maintenance is impractical, or interactions among subsystems create unacceptable behavior. Operational trials, usability studies, simulations, field evaluations, and acceptance tests support validation.

Traceability and Change Control

Requirements traceability establishes relationships among needs, requirements, architecture, design elements, analyses, tests, defects, and approvals. A forward trace links a stakeholder need to lower-level requirements and verification evidence. A backward trace shows why a design element or test exists. Bidirectional traceability supports impact analysis and auditability.

A requirements traceability matrix is a simple representation, but mature organizations use integrated digital links across requirements management, CAD, simulation, software, test management, configuration management, and service records. Traceability does not mean creating links mechanically. Each link should have a meaningful rationale and a responsible owner.

Change control assesses the technical, cost, schedule, safety, regulatory, and lifecycle consequences of a proposed change. A change-control board or equivalent governance mechanism reviews significant changes. Baselines provide controlled snapshots against which progress and compliance are measured. A requirement should not be silently edited after design work has begun; the change, reason, approval, and affected artifacts must be recorded.

Systems Engineering: From Need to Integrated System

Systems engineering is an interdisciplinary approach for defining, developing, integrating, verifying, validating, deploying, operating, maintaining, and retiring systems. Its central concern is the relationship among the whole system, its parts, its environment, and its life cycle.

The systems engineering “V-model” is a useful representation, although real projects iterate rather than follow a rigid sequence. On the left side, stakeholder needs are transformed into system requirements, architecture, and detailed designs. On the right side, components are integrated and verified at progressively higher levels, followed by system validation in the operational context. The model emphasizes that verification planning should begin when requirements are written, not after the design is complete.

A complementary view is the systems engineering life-cycle process. Activities include stakeholder needs definition, mission or operational analysis, system requirements definition, logical and physical architecture development, design realization, integration, verification, validation, operation, maintenance, and disposal. Risk management, configuration management, decision analysis, and technical planning support all stages.

Functional Decomposition

Functional decomposition breaks a system-level capability into smaller functions. For an automated warehouse vehicle, “move goods safely” may decompose into receive mission commands, localize vehicle, plan route, propel vehicle, detect obstacles, control motion, communicate status, and manage energy. Each function may be decomposed further until it can be allocated to a system element and verified.

Functional decomposition should describe what the system does before deciding how it does it. Prematurely expressing functions as components can lock the team into an early architecture. Functional analysis also identifies inputs, outputs, controls, mechanisms, states, and interactions. Scenarios and use cases reveal sequences and exceptional conditions that static function lists may overlook.

Allocation and Interfaces

Allocation maps functions and requirements to physical, software, human, or organizational elements. Some functions are allocated wholly to one element; others are distributed. Allocation should consider performance, safety, reliability, cost, technology readiness, maintainability, and future change.

Interfaces are frequently the source of integration failure. An interface includes not only physical connections but also energy, data, timing, control authority, environmental conditions, human interaction, and organizational responsibility. Interface control documents define such matters as dimensions, loads, connectors, communication protocols, units, timing, allowable error, and ownership. Interface requirements should be verified independently where appropriate.

Product Architecture and Modularity

Product architecture is the arrangement of product functions, physical or digital elements, and the relationships among them. It is the bridge between what the product must do and how the product is organized.

A product architecture can be represented through a function–component matrix, interface map, system block diagram, or formal model. A modular architecture groups functions into relatively independent modules with standardized interfaces. An integral architecture distributes functions across tightly coupled elements and may achieve high performance or compactness, but often makes change, repair, and variant development more difficult.

Modularity has several dimensions. Functional modularity separates responsibilities; physical modularity separates replaceable elements; process modularity supports independent manufacturing or assembly; and organizational modularity permits different teams or suppliers to develop elements with limited coordination. Modularity is valuable when product variety, upgrades, maintenance, or supply-chain substitution is important. It can be disadvantageous when interfaces introduce mass, cost, losses, or performance penalties.

Platform architecture uses a common set of elements, interfaces, and processes to support a family of products. A platform can reduce development effort and enable economies of scale, but excessive commonality may impose compromises on specialized products. Architectural decisions should therefore consider product families, expected change, variant complexity, lifecycle cost, and strategic control of critical technologies.

Architectural Trade-offs

Architecture involves choices rather than universally correct answers. Centralized control may simplify coordination but create a single point of failure. Distributed control may improve scalability and fault containment but increase communication and integration demands. A highly integrated assembly may reduce part count but make repair difficult. A modular assembly may simplify maintenance but increase interfaces.

Useful decision criteria include functional performance, mass, volume, manufacturability, assembly, reliability, safety, cybersecurity, maintainability, recyclability, upgradeability, cost, schedule, and supplier dependence. Weighted decision matrices can structure judgment, but the weights themselves require governance because they reflect strategic priorities.

Model-Based Systems Engineering and SysML

Model-Based Systems Engineering (MBSE) uses a shared, structured system model as a primary means of representing requirements, behavior, structure, interfaces, analysis relationships, and verification evidence. It does not mean merely converting documents into diagrams. Its value lies in maintaining semantic relationships and enabling consistent views of the same system definition.

SysML is a general-purpose modeling language derived from UML and adapted for systems engineering. Its commonly used elements include requirement diagrams, block definition diagrams, internal block diagrams, activity diagrams, state-machine diagrams, sequence diagrams, parametric diagrams, and package structures. Different tools and SysML versions vary, but the central purpose is to connect system concepts across views.

A requirement model can show requirement hierarchies, derivation, satisfaction by design elements, verification cases, and refinement. A block model represents system elements and their relationships. Activity and sequence models describe flows and interactions. State models represent behavior under modes such as startup, normal operation, degraded operation, and shutdown. Parametric models connect system properties to analytical equations, enabling performance and trade studies.

MBSE supports consistency checking, impact analysis, interface management, reuse, and communication among disciplines. It is particularly valuable where mechanical, electrical, software, control, safety, and human factors models must remain synchronized. However, a model is not automatically correct. Poor assumptions, incomplete behavior, incorrect relationships, and excessive modeling effort can produce a precise-looking but unreliable representation.

Applied Case: Architecture and Traceability for an Autonomous Inspection Vehicle

Background

The following is an illustrative case of a small autonomous vehicle intended to inspect long industrial corridors. It carries cameras and sensors, operates on uneven floors, communicates with a control station, and must return safely when faults or low energy are detected.

Situation and Problem

An initial prototype met its navigation accuracy target in laboratory tests but failed during pilot operation. It lost communication near metal structures, had insufficient battery reserve after repeated obstacle avoidance, and required excessive time for sensor replacement. The team had documented component specifications but had not established traceability from operational needs to architecture and tests.

Analysis

Stakeholder analysis identified operators, maintenance technicians, safety personnel, plant management, and the communications team. Operational scenarios included routine inspection, loss of communication, blocked route, sensor degradation, low battery, emergency stop, and recovery after restart.

The team decomposed the mission into acquire inspection data, localize, plan movement, control propulsion, detect obstacles, manage energy, communicate status, and support maintenance. A preliminary allocation assigned localization to a sensor-fusion module, movement control to a drive-control module, and energy management to a supervisory controller. Analysis revealed that localization depended on communication more than expected and that the original battery requirement did not include worst-case obstacle avoidance.

Approach and Solution

The team rewrote ambiguous requirements using measurable conditions. A system requirement specified inspection coverage under defined speed and lighting conditions. A safety requirement specified that loss of communication for a defined period would initiate a controlled stop or return procedure, depending on location and energy state. A maintainability requirement specified maximum sensor replacement time and access conditions.

A SysML model linked stakeholder needs to system requirements, functional activities, physical blocks, interfaces, and verification cases. A state model defined normal, degraded-communication, low-energy, obstacle-blocked, and emergency-stop states. A parametric energy model included propulsion, sensing, communication, and avoidance loads rather than nominal travel alone.

Architecturally, the team separated the sensor payload from the vehicle platform through a standardized mechanical and electrical interface. Communication was given two operating modes: normal high-bandwidth transmission and low-bandwidth status transmission. Critical safety behavior was retained locally rather than depending entirely on the control station.

Outcome

The revised architecture improved fault containment and permitted sensor replacement without redesigning the vehicle platform. Verification was planned at component, subsystem, and system levels, while validation used representative corridor trials. The most important improvement was not a single component but the visibility of relationships among operational scenarios, requirements, architecture, and evidence.

Learning Points

The case demonstrates that failed integration often reflects weak system definition rather than inadequate component engineering. It also shows why operational scenarios, interface requirements, degraded modes, and lifecycle needs must be addressed before detailed design becomes fixed.

Risks, Limitations, and Professional Judgement

Requirements processes can fail through ambiguity, uncontrolled growth, excessive optimism, conflicting stakeholder objectives, or over-specification of solutions. A requirement may be technically verifiable yet irrelevant to user value. Conversely, a legitimate quality such as ease of use may be difficult to quantify and require multiple validation methods.

Traceability can become a burdensome administrative exercise when every link is created without purpose. MBSE can fail when organizations purchase tools before defining modeling practices, ownership, training, and governance. Models may become outdated if engineers continue to make decisions outside the controlled environment.

Common mistakes include allocating functions before understanding behavior, ignoring abnormal modes, treating interfaces as drawings only, verifying components but not integrated behavior, accepting supplier claims without evidence, and changing requirements without assessing downstream effects. Another frequent error is confusing validation with customer acceptance alone; validation is evidence that the system works for its intended use and context.

Ethically, engineers must not suppress unfavorable test results, conceal uncertainty, or define requirements so narrowly that foreseeable hazards are excluded. Safety-critical decisions require independent review, defensible assumptions, configuration control, and compliance with applicable standards and regulations. Data used in connected products must be protected, and cybersecurity requirements should be treated as system requirements rather than late software additions. Sustainability requirements should address energy, materials, repair, upgrade, recycling, and end-of-life consequences where relevant.

Digital Integration and Emerging Practice

Modern PLM environments increasingly connect requirements, system models, CAD, simulation, software repositories, manufacturing planning, quality records, and service data. Digital threads support continuity of information across the product life cycle, while digital twins may use operational data to compare expected and actual behavior. Automated consistency checks can identify missing links, incompatible units, interface mismatches, or tests without approved requirements.

Artificial intelligence can assist with requirement classification, duplicate detection, natural-language quality checks, impact analysis, and retrieval of relevant historical evidence. Such tools should support rather than replace engineering judgement. AI-generated interpretations may miss context, reproduce bias, or create false confidence. Sensitive product data also requires controls for access, provenance, intellectual property, and model accountability.

Emerging systems are increasingly software-defined, connected, autonomous, and updateable. Consequently, architecture must address cybersecurity, data ownership, over-the-air updates, algorithm change, human oversight, and long-term compatibility. The system boundary now includes cloud services, operators, suppliers, infrastructure, and regulatory authorities. Requirements engineering must therefore include operational data and change after deployment, not only the initial physical product.

Best Practices for Engineering Organizations

A robust practice begins with explicit stakeholder goals and operational scenarios. Requirements should be measurable, prioritized, uniquely identified, owned, and linked to rationale and verification evidence. Functional decomposition should precede detailed allocation, while architecture should be evaluated against lifecycle and change objectives rather than initial performance alone.

Organizations should establish a common vocabulary, modeling conventions, interface ownership, configuration baselines, review gates, and independent verification where risk warrants it. Verification planning should begin with requirement definition, and validation should include realistic users, environments, abnormal conditions, and maintenance activities. Digital tools should be integrated through agreed semantics and workflows, supported by training and accountable data ownership.

Most importantly, engineering teams should treat requirements and architecture as living technical decisions. They must evolve through controlled learning, not through undocumented personal interpretation.

Chapter Summary

Requirements engineering transforms stakeholder needs into clear, feasible, traceable, and verifiable technical statements. Systems engineering integrates these statements with functional analysis, allocation, architecture, interfaces, risk, lifecycle thinking, verification, and validation. Product architecture determines how functions are organized into physical, software, human, and organizational elements, with modularity and platforms offering benefits that must be balanced against interface cost and performance coupling.

The systems engineering V-model emphasizes progressive definition and corresponding verification, while traceability connects needs, requirements, design, tests, defects, and operational evidence. MBSE and SysML strengthen this continuity by representing requirements, behavior, structure, and analytical relationships in an integrated model. Effective practice requires governance, change control, professional ethics, realistic validation, and attention to cybersecurity, sustainability, maintainability, and post-deployment evolution.

Key Terms

Requirement: A necessary capability, condition, or constraint that a system must satisfy.

Stakeholder requirement: An expectation expressed from the perspective of a user, customer, organization, or other interested party.

System requirement: A measurable technical statement defining what the complete system must achieve.

Derived requirement: A requirement generated through analysis of a higher-level requirement or design decision.

Functional requirement: A statement of an action or capability the system must perform.

Performance requirement: A measurable level of effectiveness, speed, accuracy, capacity, or quality.

Interface requirement: A condition governing interaction between system elements or between the system and its environment.

Traceability: The documented relationship among needs, requirements, design elements, tests, and evidence.

Verification: Demonstration that a product or design output conforms to specified requirements.

Validation: Demonstration that the product satisfies intended use and stakeholder needs.

Functional decomposition: Breaking a system capability into smaller functions and subfunctions.

Allocation: Assignment of functions or requirements to system elements.

Product architecture: The arrangement of product functions, elements, and their relationships.

Modular architecture: An architecture that separates responsibilities into relatively independent modules with defined interfaces.

Platform: A common set of elements and interfaces supporting a family of products.

MBSE: Model-Based Systems Engineering using an integrated system model as a principal engineering representation.

SysML: A modeling language for representing system requirements, structure, behavior, and analysis.

Baseline: An approved and controlled version of requirements, architecture, or product definition.

Interface control: The management and specification of interactions among system elements.

Digital thread: Connected, governed information relationships maintained across the product life cycle.

Review Questions

Short Answer Questions

1. What distinguishes a system requirement from a design solution?

2. Define verification and validation, and state the central question asked by each.

3. Why are derived requirements necessary in complex product development?

4. What is the purpose of a requirements traceability matrix?

5. State two advantages and one possible disadvantage of modular architecture.

Long Answer Questions

1. Explain the requirements engineering process from elicitation through change control.

2. Describe the systems engineering V-model and explain how it supports verification planning.

3. Discuss functional decomposition, allocation, and interface definition in multidisciplinary products.

4. Compare modular and integral product architectures using lifecycle and performance criteria.

5. Explain how MBSE and SysML can improve requirements and architecture management, including their limitations.

Analytical / Application Questions

1. A machine must increase payload capacity without increasing its overall mass. Propose a requirements and architecture analysis approach, identifying likely trade-offs and evidence needed for a decision.

2. A subsystem passes all component tests but the complete product fails during field operation. Analyze possible causes using the concepts of verification, validation, interfaces, and operational scenarios.

3. Develop a traceability and verification strategy for an autonomous inspection vehicle operating under communication loss and low-energy conditions.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes verification from validation?

A. Verification confirms user satisfaction, while validation checks material properties.

B. Verification checks conformity to specified requirements, while validation checks suitability for intended use.

C. Verification occurs only after production, while validation occurs only during concept design.

D. Verification concerns software, while validation concerns mechanical components.

Correct Answer: B. Verification checks conformity to specified requirements, while validation checks suitability for intended use.

Question 2

A requirement states that a control system shall respond 'very quickly.' What is the principal weakness of this requirement?

A. It is too strongly linked to a particular design solution.

B. It lacks a measurable and verifiable performance condition.

C. It is necessarily a derived requirement.

D. It cannot be allocated to a subsystem.

Correct Answer: B. It lacks a measurable and verifiable performance condition.

Question 3

Which relationship is most useful for assessing the impact of a proposed requirement change?

A. Linking the requirement only to its author

B. Linking the requirement to affected functions, design elements, tests, and risks

C. Linking the requirement only to the product cost estimate

D. Linking the requirement only to the manufacturing drawing

Correct Answer: B. Linking the requirement to affected functions, design elements, tests, and risks

Question 4

What is the main purpose of functional decomposition?

A. To select suppliers before defining system behavior

B. To break system capabilities into functions that can be analyzed and allocated

C. To replace all physical architecture decisions with software models

D. To eliminate the need for interface specifications

Correct Answer: B. To break system capabilities into functions that can be analyzed and allocated

Question 5

Which situation most strongly favors a modular architecture?

A. A product requires tightly coupled functions with no expected change.

B. The product must support upgrades, variants, and replacement of selected elements.

C. Every interface introduces unacceptable performance loss.

D. The product has only one function and one component.

Correct Answer: B. The product must support upgrades, variants, and replacement of selected elements.

Question 6

In the systems engineering V-model, detailed design and implementation are generally followed by:

A. Stakeholder elicitation with no technical testing

B. Progressive integration, verification, and system validation

C. Immediate product retirement

D. Removal of all requirements baselines

Correct Answer: B. Progressive integration, verification, and system validation

Question 7

Which SysML model is most appropriate for representing normal, degraded, and emergency operating modes?

A. State-machine diagram

B. Package diagram only

C. Requirement table only

D. Bill of materials

Correct Answer: A. State-machine diagram

Question 8

An autonomous vehicle stops safely when communication is lost, even though the control station is unavailable. This illustrates which architectural principle?

A. All safety functions should depend on remote control.

B. Critical behavior may need local allocation for fault containment.

C. Interfaces are unnecessary in distributed systems.

D. Validation can replace requirements analysis.

Correct Answer: B. Critical behavior may need local allocation for fault containment.

Question 9

A product passes laboratory component tests but fails when users operate it in a factory. Which explanation is most consistent with the chapter?

A. Component verification automatically proves system validation.

B. The system may have unrecognized interactions, environmental conditions, or usability problems.

C. The requirements must be correct because component tests passed.

D. The failure can only be caused by a manufacturing drawing error.

Correct Answer: B. The system may have unrecognized interactions, environmental conditions, or usability problems.

Question 10

Which practice best supports responsible use of AI in requirements engineering?

A. Accepting automatically generated requirements without review

B. Using AI for assistance while controlling provenance, confidentiality, and engineering judgement

C. Allowing AI to approve safety-critical changes independently

D. Removing human ownership of requirement decisions

Correct Answer: B. Using AI for assistance while controlling provenance, confidentiality, and engineering judgement