Systems Engineering and Requirements Definition

Introduction and Context

Advanced mechatronic products combine mechanics, electronics, embedded software, sensing, actuation, communications, and human interaction. Their performance therefore depends not only on the quality of individual components but also on how well the components work together as a system. A technically excellent motor, controller, or sensor cannot compensate for unclear system purpose, incompatible interfaces, or unverified stakeholder expectations.

Systems engineering provides a disciplined approach for defining the problem, organizing complexity, allocating responsibilities, managing interfaces, and demonstrating that the completed product satisfies its intended purpose. Requirements definition is the central activity through which stakeholder needs are transformed into statements that engineers can design, verify, validate, and manage throughout the product life cycle.

A requirement is not merely a desirable feature. It is a necessary, documented, and verifiable statement of a capability, performance level, condition, or constraint. Poor requirements create ambiguity, late design changes, unsafe behavior, cost growth, and disputes over acceptance.

Learning Objectives

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

1. Identify stakeholders and elicit, analyze, and prioritize their needs.
2. Distinguish stakeholder needs, system requirements, and lower-level technical requirements.
3. Write clear, atomic, measurable, feasible, and verifiable functional and non-functional requirements.
4. Define operating scenarios, modes, interfaces, assumptions, and constraints.
5. Construct a requirements traceability structure and verification matrix.
6. Apply qualitative risk analysis to requirements and design decisions.
7. Explain configuration control, change management, and requirements governance.
8. Evaluate requirements in a realistic mechatronic application.

1. Systems Engineering as a Life-Cycle Discipline

Systems engineering is an interdisciplinary method for enabling the realization of successful systems. It addresses the complete life cycle: concept, development, production, operation, maintenance, upgrade, retirement, and disposal. In mechatronics, this means considering physical performance together with software behavior, manufacturability, cybersecurity, safety, maintainability, energy use, human factors, and regulatory obligations.

A common life-cycle progression is:

• Mission or business need: Why is the system required?
• Stakeholder needs: What outcomes do users, operators, owners, maintainers, regulators, and communities require?
• System requirements: What must the complete system do, and under what conditions?
• Architecture: What subsystems, interfaces, and allocations will satisfy the requirements?
• Design and implementation: How will each subsystem be realized?
• Integration and verification: Does each item meet its specified requirement?
• Validation: Does the integrated system solve the stakeholder's real problem?
• Operation and evolution: How will performance, changes, failures, and retirement be managed?

The process is iterative rather than strictly linear. Discoveries during testing may reveal an incorrect assumption or an incomplete requirement. Good systems engineering makes such feedback visible and controlled instead of allowing it to appear as an unplanned failure.

A useful distinction is verification versus validation. Verification asks, “Was the product built according to its requirements?” Validation asks, “Was the right product built for its intended mission?” For example, a robot may accurately meet a programmed position tolerance (verification) but still be unsuitable because its operator interface is confusing (a validation failure).

2. Stakeholders and the Elicitation of Needs

A stakeholder is an individual, group, organization, or external system that affects, is affected by, or has an interest in the system. Typical mechatronic stakeholders include:

• customers and business owners;
• end users and operators;
• maintenance and service personnel;
• manufacturing and supply-chain teams;
• safety authorities and regulators;
• software, mechanical, electrical, and controls engineers;
• nearby workers or members of the public;
• disposal and recycling organizations; and
• connected systems, such as factory networks or cloud services.

Stakeholder needs are often expressed in informal language: “The machine should be quick,” “It must be safe,” or “The robot should be easy to maintain.” Such statements are valuable starting points but are not yet suitable system requirements. Elicitation seeks to uncover the underlying outcome, context, priority, and acceptance condition.

Elicitation methods

Interviews allow detailed exploration of goals and exceptions. Observation reveals actual work practices that users may not articulate. Workshops expose conflicts and encourage shared understanding. Prototypes and simulations help stakeholders react to concrete behavior. Document analysis identifies contractual, regulatory, legacy, and interface obligations. Surveys are useful when many users are distributed, although they provide less depth than direct observation.

Effective elicitation includes questions such as:

• What task is being performed, and what constitutes success?
• Under what environmental and operating conditions does it occur?
• What happens when the normal process fails?
• What information must the operator see or enter?
• What maintenance, cleaning, calibration, or recovery is required?
• Which performance attributes are essential, and which are preferences?
• What legal, ethical, safety, privacy, or cybersecurity concerns apply?

Elicitation should record the source of each need, its rationale, assumptions, conflicts, priority, and unresolved questions. A need without a rationale is difficult to defend when trade-offs arise.

Prioritization and conflict resolution

Resources are finite, so all needs cannot automatically receive equal priority. A simple prioritization method classifies items as essential, important, desirable, or deferred. A more formal approach scores value, risk reduction, cost, and urgency. Priorities must not be used to disregard mandatory safety or legal requirements: a regulatory obligation is a constraint, not a discretionary feature.

Conflicts are resolved by examining mission objectives, evidence, risk, life-cycle cost, and stakeholder authority. For example, a production manager may request maximum speed while a safety engineer requires increased separation distance. The solution should not be chosen by opinion alone; it should be supported by hazard analysis, performance modeling, and an agreed acceptance rationale.

3. From Needs to Requirements

A useful hierarchy is:

1. Need: An informal statement of desired value or outcome.
2. Stakeholder requirement: A structured statement of what a stakeholder expects from the system.
3. System requirement: A precise statement allocated to the complete system.
4. Subsystem or component requirement: A lower-level statement allocated to a subsystem, such as a drive, controller, or sensor.
5. Design description: The selected implementation.
6. Verification evidence: Test results, inspection records, analyses, or demonstrations showing satisfaction.

The hierarchy should preserve bidirectional traceability. Every lower-level requirement should be justified by a higher-level need or requirement, and every important stakeholder need should be addressed by one or more system requirements. Traceability does not mean that every need maps to exactly one requirement; one need may require several requirements, and one requirement may contribute to several needs.

Characteristics of a good requirement

A strong requirement is:

• Necessary: Its absence would reduce mission value, safety, compliance, or feasibility.
• Unambiguous: Competent readers interpret it in the same way.
• Complete: Relevant conditions, inputs, outputs, and limits are included.
• Consistent: It does not conflict with another approved requirement.
• Singular or atomic: It expresses one independently testable obligation.
• Feasible: It can be achieved within known technical, schedule, and resource limits.
• Traceable: Its source and downstream implementation are identifiable.
• Verifiable: A practical method exists to determine whether it is satisfied.
• Prioritized: Its relative importance is recorded.
• Necessary at its level: It is stated at the appropriate abstraction level.

Words such as “fast,” “easy,” “robust,” “user-friendly,” “adequate,” and “minimal” are not inherently forbidden, but they are inadequate unless operationally defined. “The vehicle shall be fast” could become “The vehicle shall achieve 2.0 m/s ± 0.1 m/s on a level, dry test surface at a payload of 20 kg.” The latter includes a measurable performance value and test context.

Requirement grammar

A useful pattern is:

The [system or element] shall [perform an action or possess a property] [under specified conditions] [with a measurable threshold].

Examples:

• “The manipulator shall detect a human intrusion into the restricted workspace within 100 ms.”
• “The controller shall command the gripper to open when the emergency-stop circuit is activated.”
• “The enclosure shall maintain an ingress-protection rating of at least IP54.”

Avoid combining unrelated obligations with “and.” Instead of “The system shall detect overload and stop and record an event,” create separate requirements for detection, stopping, and recording. This permits independent allocation and verification.

4. Functional and Non-Functional Requirements

Functional requirements specify what the system does: motion, sensing, computation, communication, energy management, fault response, data storage, or interaction. They describe behavior and transformations of inputs into outputs.

Non-functional requirements specify qualities, constraints, or performance characteristics. Examples include timing, accuracy, availability, safety integrity, electromagnetic compatibility, maintainability, cybersecurity, noise, environmental resistance, energy consumption, and regulatory compliance.

The distinction is useful but not absolute. A requirement for “safe stopping within 0.5 s” describes behavior and safety performance simultaneously. The important issue is that the requirement is explicit, measurable, and allocated to an appropriate verification method.

Performance requirements should define the metric, value, tolerance or limit, operating condition, and measurement method. For example, “The positioning subsystem shall achieve an absolute error no greater than 0.5 mm over the specified workspace, measured after calibration at 23 °C ± 2 °C.” The requirement is stronger than “The positioning system shall be accurate.”

Constraints and assumptions

A constraint restricts possible solutions. Examples include a specified communication protocol, maximum mass, available supply voltage, legal standard, existing mounting pattern, or mandated programming language. Constraints should be distinguished from design preferences because unnecessary constraints reduce innovation.

An assumption is a proposition treated as true for planning purposes, such as an expected ambient temperature or available network bandwidth. Assumptions must be recorded, assigned an owner, and validated. An invalid assumption can invalidate many downstream requirements.

5. Operating Scenarios, Modes, and Interfaces

Requirements are incomplete without operational context. A scenario describes actors, initial conditions, normal actions, system responses, exceptions, and final conditions. Scenarios may cover production, startup, shutdown, calibration, maintenance, transport, degraded operation, emergency response, and disposal.

A mechatronic system often has explicit modes, such as off, initialization, manual, automatic, fault, maintenance, and emergency stop. For each mode, define permitted commands, active sensors, actuator behavior, operator authority, transitions, and recovery conditions. A mode-transition table can reveal unsafe or unspecified behavior.

Interfaces are boundaries across which energy, matter, information, or control passes. Important interface categories include:

• mechanical: dimensions, loads, alignment, fastening, motion envelope;
• electrical: voltage, current, grounding, connectors, protection;
• data: protocol, message format, timing, addressing, bandwidth;
• thermal: heat generation, cooling, allowable temperature;
• human: displays, controls, alarms, accessibility, training; and
• environmental: vibration, dust, moisture, radiation, temperature.

An interface requirement should specify both sides where appropriate. “The sensor shall communicate with the controller” is weak. A better statement identifies protocol, electrical levels, message timing, failure behavior, and ownership. Interface control documents and interface control drawings provide a controlled reference for these agreements.

6. Verification, Validation, and Traceability

Each requirement should have a planned verification method. Common methods are:

• Inspection: Examination without operating the system, such as checking dimensions or labels.
• Analysis: Calculation, simulation, or modeling supported by justified assumptions.
• Demonstration: Observation of operation under defined conditions.
• Test: Controlled measurement using specified equipment and procedures.

A verification requirement should define setup, inputs, instrumentation, tolerances, pass/fail criteria, and recorded evidence. A requirement that cannot be verified is either poorly written or not actually a requirement.

A requirements verification matrix (RVM) connects requirement identifiers to source, owner, design element, verification method, procedure, status, and evidence. A simplified structure is shown below.

Traceability can be represented as a directed relationship from needs to requirements, architecture, implementation, verification, and validation. Missing links indicate risk. A requirement with no source may be gold-plating; a design element with no requirement may be unjustified; a requirement with no verification evidence is incomplete at acceptance.

7. Risk Analysis and Requirements Quality

Risk analysis should begin while requirements are being defined, not after design completion. A common qualitative model evaluates the likelihood of a hazardous or undesirable event and its consequence. If a numerical risk-priority approach is adopted, a simple risk priority number is:

Here, S is severity, O is occurrence likelihood, and D is detectability, each assigned an agreed ordinal scale. The product is not a probability and should not be interpreted as one. It is a screening index used only when the scale definitions are consistent. A high-severity hazard may require action even if its numerical score is moderate.

For safety-critical systems, structured hazard analysis is more appropriate than relying only on an RPN. Techniques include preliminary hazard analysis, failure modes and effects analysis (FMEA), fault-tree analysis, event-tree analysis, and hazard and operability studies. These methods identify unsafe states, causes, controls, detection mechanisms, and residual risk.

Requirements should express risk controls. For example, rather than merely stating “The system shall be safe,” define detection coverage, safe-state behavior, response time, reset conditions, diagnostic behavior, and protection against foreseeable misuse. Safety requirements must be consistent with applicable standards and the system's risk classification.

8. Requirements Management and Change Control

Requirements evolve because stakeholders learn, technologies change, regulations are updated, and tests reveal new information. Uncontrolled changes create configuration inconsistency. Requirements management therefore includes identification, baselining, version control, change assessment, approval, and status reporting.

A change request should state the proposed change, reason, affected requirements, interfaces, hazards, cost, schedule, verification impact, and approval authority. An impact analysis should examine both direct and indirect consequences. For example, increasing robot speed may affect motor sizing, braking distance, structural loads, guarding, software timing, battery capacity, noise, and operator training.

A baseline is an formally approved version of requirements or design that can be changed only through controlled authorization. Configuration items should have unique identifiers and revision histories. Tool support may include requirements databases, model-based systems engineering (MBSE) tools, issue trackers, version-control systems, and automated consistency checks. Tools improve visibility but do not replace engineering judgment.

9. Worked Example: Automated Inspection Cell

Consider an illustrative automated inspection cell for checking the presence and orientation of components on a conveyor. The cell contains a camera, lighting, conveyor motor, pneumatic reject actuator, programmable controller, operator panel, and safety guarding.

Background and problem

The production team wants higher inspection throughput and consistent quality. Operators currently inspect parts manually, leading to fatigue and variable judgments. Maintenance staff are concerned about access to the camera and reject mechanism. Safety personnel require protection from moving equipment.

Stakeholder needs

The customer needs reliable detection, production staff need adequate throughput, operators need understandable status information, maintainers need safe access, and the organization must comply with machinery-safety and electrical requirements.

Derived requirements

Examples of system requirements are:

• The cell shall inspect every part presented within the defined conveyor spacing.
• The vision subsystem shall classify each part as acceptable, defective, or indeterminate.
• The reject actuator shall remove a defective part without stopping the conveyor under normal operation.
• The operator panel shall display operating mode, fault state, and count of accepted and rejected parts.
• Opening a guard door shall prevent hazardous motion and shall require a defined reset procedure before restart.
• The cell shall provide access for camera cleaning without exposing personnel to hazardous motion.

These statements still require measurable limits. Suppose the target throughput is 30 parts per minute. The mean interval between parts is:

where t is the average interval in seconds and the throughput is 30 parts per minute. This does not mean that every part is exactly 2 s apart; the requirement must also define allowable spacing variation. If inspection and reject decisions require 0.4 s, the timing budget must include image acquisition, processing, communication, actuator response, and positional travel. A design margin should be justified rather than assumed.

Analysis and solution

A context analysis identifies the conveyor, operator, maintenance technician, factory information system, electrical supply, and pneumatic supply as external interfaces. A mode model distinguishes setup, automatic production, fault, and maintenance. A hazard analysis identifies crushing, unexpected restart, ejected parts, electrical energy, and pneumatic energy.

The team allocates requirements to the camera, controller, actuator, guarding, and human-machine interface. Each allocation is checked for completeness: no requirement should depend on an unassigned function, and no subsystem should introduce behavior that conflicts with system-level safety requirements.

Verification planning might use image-set testing for classification accuracy, timed tests for reject response, inspection for dimensions and labeling, and demonstration for guard-door behavior. Validation uses production trials with representative parts, operators, maintenance tasks, and realistic fault conditions.

Outcome and learning points

The principal outcome is not merely a list of specifications. It is a coherent and traceable agreement about mission, behavior, interfaces, hazards, acceptance evidence, and change authority. The example demonstrates that throughput, safety, maintainability, and usability must be considered together. Optimizing only inspection speed could produce unacceptable reject timing, inadequate guarding, or excessive maintenance burden.

10. Professional, Ethical, and Regulatory Considerations

Requirements engineers have a duty to protect users, bystanders, property, and the environment. Concealing uncertainty, weakening a safety requirement to meet a schedule, or accepting unverifiable claims is professionally unacceptable. Requirements should identify assumptions and uncertainty rather than presenting estimates as facts.

Applicable laws and standards depend on the application and jurisdiction. Typical areas include machinery safety, functional safety, electrical safety, electromagnetic compatibility, radio communications, data protection, accessibility, and environmental regulation. Standards should be identified early because they influence architecture, evidence, documentation, and competence requirements.

Connected mechatronic systems also create cybersecurity and privacy concerns. Requirements may address authentication, authorization, secure updates, event logging, network segregation, data minimization, and recovery from communication loss. Artificial intelligence used for inspection or control introduces additional requirements for data quality, performance across operating conditions, explainability where decisions affect safety or employment, human oversight, model versioning, and handling of unknown inputs. An AI classifier should not be treated as reliable merely because its average test accuracy is high; rare but hazardous errors require explicit analysis.

11. Contemporary Practices and Best Practices

Model-based systems engineering represents requirements, structure, behavior, interfaces, and verification relationships in an integrated model. It can reduce inconsistency and support impact analysis, but model quality and governance remain essential. Digital twins and simulation can test scenarios before hardware exists, provided that model assumptions are validated.

Agile and iterative development do not eliminate formal requirements. They may express requirements as user stories, acceptance criteria, interface contracts, and increment-level specifications. Safety-critical or regulated projects still require controlled baselines and objective evidence.

Recommended practices include:

1. Begin with mission outcomes rather than preferred technologies.
2. Involve operators, maintainers, safety specialists, and manufacturing personnel early.
3. Record rationale, assumptions, source, priority, and verification method.
4. Use units, tolerances, conditions, and acceptance criteria consistently.
5. Separate requirements from design solutions unless a constraint is justified.
6. Analyze abnormal, degraded, maintenance, and misuse scenarios.
7. Maintain traceability from need through evidence.
8. Review requirements for ambiguity and testability before design freeze.
9. Control changes using impact analysis and approved baselines.
10. Treat safety, security, human factors, and sustainability as system properties.

Challenges and Limitations

Requirements work is limited by incomplete stakeholder knowledge, conflicting objectives, uncertain technology, changing environments, and the difficulty of predicting human behavior. Excessive detail too early can constrain innovation, while insufficient detail can defer critical decisions until integration. Quantitative targets may create false precision when measurement uncertainty or operating variation is ignored. Traceability tools can also produce an appearance of rigor if links are created mechanically without meaningful rationale.

Systems engineering is therefore not a substitute for experimentation, domain expertise, communication, or ethical judgment. Its value lies in making decisions, assumptions, interfaces, and evidence explicit enough to support responsible engineering.

Chapter Summary

Systems engineering organizes the development of complex mechatronic products across their life cycle. Requirements definition transforms stakeholder needs into necessary, feasible, unambiguous, measurable, traceable, and verifiable statements. Functional requirements describe system behavior, while non-functional requirements describe qualities and constraints such as safety, timing, reliability, maintainability, and cybersecurity.

Effective requirements depend on stakeholder elicitation, operational scenarios, mode definitions, interface specifications, assumptions, and constraints. Verification demonstrates compliance with requirements; validation demonstrates that the system fulfills its intended purpose. Traceability links needs, requirements, architecture, implementation, verification, and validation evidence.

Risk analysis should begin during requirements definition and should address hazards, failure modes, unsafe states, and controls. Requirements management provides identification, baselines, configuration control, change assessment, and approval. In professional practice, safety, security, ethics, regulation, human factors, and sustainability must be treated as system-level concerns rather than afterthoughts.

Key Terms

Stakeholder: A person, organization, or system that affects or is affected by the system.

Systems engineering: An interdisciplinary life-cycle approach for realizing successful systems.

Need: An informal statement of desired value or outcome.

Requirement: A necessary, documented, and verifiable obligation or constraint.

Functional requirement: A statement of what the system shall do.

Non-functional requirement: A statement of a quality, performance attribute, or constraint.

Constraint: A restriction on possible solutions.

Assumption: A proposition treated as true for planning or analysis.

Scenario: A structured description of system behavior in a situation.

Mode: A defined operating state with permitted behavior and transitions.

Interface: A boundary across which energy, matter, information, or control passes.

Verification: Determining whether the system meets specified requirements.

Validation: Determining whether the system fulfills its intended purpose.

Traceability: The ability to follow relationships among needs, requirements, design, and evidence.

RVM: Requirements verification matrix linking requirements to verification evidence.

Baseline: An approved configuration controlled through formal change procedures.

FMEA: Failure modes and effects analysis.

Risk priority number: An ordinal screening index often calculated as severity × occurrence × detectability.

Configuration management: Controlled identification, revision, and authorization of system items.

Model-based systems engineering: Use of integrated models to represent system structure, behavior, interfaces, and relationships.

Review Questions

Short Answer Questions

1. Distinguish verification from validation in a mechatronic project.
2. List four characteristics of a high-quality requirement.
3. Why should assumptions be recorded and assigned an owner?
4. Name four common requirements verification methods.
5. What is the purpose of bidirectional traceability?

Long Answer Questions

1. Explain how stakeholder needs are elicited, analyzed, prioritized, and transformed into system requirements.
2. Compare functional requirements, non-functional requirements, constraints, and assumptions using mechatronic examples.
3. Describe how operating modes and scenarios help reveal incomplete or unsafe requirements.
4. Explain the role of interfaces and interface control documents in an integrated mechatronic system.
5. Discuss how requirements management controls changes throughout the system life cycle.

Analytical / Application Questions

1. Rewrite the statement “The robot shall be safe and easy to use” as at least three measurable requirements, and identify an appropriate verification method for each.
2. A proposed increase in conveyor speed affects motor torque, braking, vision timing, guarding, noise, and operator training. Construct an impact-analysis plan identifying stakeholders, affected requirements, risks, and evidence needed before approval.
3. For an autonomous mobile robot operating near people, develop a short scenario and identify functional, performance, interface, safety, and cybersecurity requirements that should be traced to it.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes validation from verification?

A. Validation checks whether the right system addresses the intended need; verification checks conformity to specified requirements.

B. Validation is performed only by software engineers; verification is performed only by mechanical engineers.

C. Validation checks component dimensions; verification checks stakeholder satisfaction.

D. Validation and verification are identical terms.

Correct Answer: A. Validation checks whether the right system addresses the intended need; verification checks conformity to specified requirements.

Question 2

Which requirement is most measurable and verifiable?

A. The actuator shall respond quickly.

B. The actuator shall provide adequate force.

C. The actuator shall reach 100 mm/s ± 5 mm/s under the specified load and supply voltage.

D. The actuator shall be user-friendly.

Correct Answer: C. The actuator shall reach 100 mm/s ± 5 mm/s under the specified load and supply voltage.

Question 3

Which item is an interface requirement?

A. The robot shall be reliable.

B. The sensor shall transmit a temperature message over CAN every 100 ms.

C. The product shall be commercially successful.

D. The operator shall be satisfied.

Correct Answer: B. The sensor shall transmit a temperature message over CAN every 100 ms.

Question 4

What is the principal purpose of a requirements verification matrix?

A. To select the cheapest component automatically.

B. To connect requirements with verification methods and objective evidence.

C. To replace all engineering drawings.

D. To calculate motor power.

Correct Answer: B. To connect requirements with verification methods and objective evidence.

Question 5

A system processes 30 parts per minute at uniform spacing. What is the mean interval between parts?

A. 0.5 s

B. 1 s

C. 2 s

D. 30 s

Correct Answer: C. 2 s

Question 6

In the ordinal expression RPN = S × O × D, what do the symbols represent?

A. Speed, output, and distance

B. Severity, occurrence, and detectability

C. Safety, operation, and design

D. System, order, and dependency

Correct Answer: B. Severity, occurrence, and detectability

Question 7

Which statement about a requirement baseline is correct?

A. It is an approved configuration controlled through formal change procedures.

B. It is an informal list that cannot be revised.

C. It contains only test results and no requirements.

D. It eliminates the need for stakeholder review.

Correct Answer: A. It is an approved configuration controlled through formal change procedures.

Question 8

Which example is a constraint rather than a desired system function?

A. The system shall detect an obstruction.

B. The system shall display an alarm.

C. The controller shall use the existing CAN interface.

D. The system shall record fault events.

Correct Answer: C. The controller shall use the existing CAN interface.

Question 9

Why is a high-severity hazard not necessarily acceptable merely because its RPN is low?

A. RPN is a physical measurement in newtons.

B. Ordinal scores are screening tools, and severe hazards may require action independently of the product score.

C. RPN can only be used for software defects.

D. Low RPN always means the hazard has been eliminated.

Correct Answer: B. Ordinal scores are screening tools, and severe hazards may require action independently of the product score.

Question 10

Which practice best supports responsible use of AI in a safety-relevant inspection system?

A. Accepting a model solely because its average accuracy is high.

B. Removing human oversight to improve throughput.

C. Defining performance across operating conditions and analyzing rare hazardous errors.

D. Changing the model without recording its version.

Correct Answer: C. Defining performance across operating conditions and analyzing rare hazardous errors.