2. Requirements Engineering and Systems Architecture

Introduction and Context

Mechanical systems rarely fail because a designer cannot draw a component or calculate a stress. They more often fail because the system was designed to solve the wrong problem, because an important stakeholder need was overlooked, or because interactions among subsystems were misunderstood. Requirements engineering and systems architecture address these risks by establishing a disciplined path from an initial need to a coherent, verifiable system design.

In mechanical engineering, the system may be a machine tool, autonomous vehicle, industrial robot, thermal-management unit, medical device, aircraft subsystem, or production line. Such systems combine structure, mechanisms, materials, sensors, actuators, software, energy sources, operators, and maintenance processes. Their performance is therefore determined not only by individual component quality but also by how components are allocated, connected, controlled, and operated.

Requirements engineering converts stakeholder expectations into precise, traceable, and testable statements. Systems architecture then organizes the required functions into an arrangement of physical and logical elements, defines interfaces, and provides the framework within which detailed design decisions are made. Together, these activities create the foundation for later work in concept generation, modelling, optimization, reliability, manufacturing, verification, and lifecycle management.

Learning Objectives

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

1. Explain the purpose and scope of requirements engineering in mechanical systems design.

2. Distinguish stakeholder needs, system requirements, specifications, constraints, assumptions, and acceptance criteria.

3. Transform ambiguous needs into measurable and verifiable requirements.

4. Apply functional decomposition and allocate functions to system elements.

5. Define physical, energy, information, material, and human interfaces.

6. Construct a requirements traceability structure and use it for change and verification management.

7. Compare architectural alternatives using structured trade-off methods.

8. Describe the principal activities of a systems-engineering process.

9. Evaluate risks, ethical issues, digital tools, and emerging practices in requirements and architecture work.

10. Apply these methods to a multidisciplinary mechanical-system design problem.

From Stakeholder Need to Engineering Requirement

A stakeholder need expresses a desired outcome in the language of a user, customer, regulator, operator, maintainer, or business decision-maker. For example, a customer may state that a lifting device must be “safe, compact, easy to maintain, and fast.” These statements are valuable because they reveal priorities, but they are not yet suitable for engineering verification. Terms such as safe, compact, and easy are context-dependent and can lead different designers to different interpretations.

A requirement is a necessary, stated capability or condition that a system must satisfy. A well-formed requirement identifies what is required without prematurely prescribing how it must be achieved. For example, “The lifting device shall raise a 500 kg payload through a vertical stroke of 2 m within 20 s” is more useful than “The device shall use a high-power actuator.” The first statement defines an outcome; the second specifies a solution before alternatives have been considered.

Requirements exist at several levels. Stakeholder or mission requirements describe the overall purpose. System requirements translate these into measurable performance, environmental, safety, physical, operational, and lifecycle conditions. Subsystem and component requirements allocate portions of the system requirement to particular elements. Verification requirements define how compliance will be demonstrated. This hierarchy prevents detailed design decisions from becoming disconnected from the original purpose.

A requirement should generally be:

• necessary, because removing it would impair an essential stakeholder objective;
• unambiguous, so that competent readers reach the same interpretation;
• singular, expressing one principal obligation rather than several unrelated obligations;
• measurable or objectively assessable;
• feasible within the available technology, resources, schedule, and risk tolerance;
• traceable to a source and to downstream design and verification evidence; and
• consistent with other requirements.

The distinction between a requirement and a preference is important. A requirement is mandatory, whereas a preference expresses a desirable characteristic that may be traded against cost, mass, schedule, or other objectives. The distinction should be recorded explicitly because treating every preference as an absolute constraint can produce an unnecessarily expensive or technically inferior design.

Terminology Used in Requirements Work

A constraint limits the solution space without necessarily describing a desired performance outcome. Examples include an available installation envelope, a legal emission limit, a specified material prohibition, or compatibility with an existing power supply. An assumption is a proposition accepted temporarily because information is incomplete. Assumptions must be recorded, assigned an owner, and validated when evidence becomes available. An interface requirement defines an interaction between system elements or between the system and its environment. An acceptance criterion states the evidence needed for a customer or authority to accept the delivered system.

Requirements may also be classified by subject. Functional requirements state what the system shall do. Performance requirements quantify how well it shall do it. Physical requirements address dimensions, mass, materials, or configuration. Environmental requirements concern temperature, humidity, vibration, dust, corrosion, radiation, or altitude. Operational requirements describe modes, duty cycles, users, and procedures. Safety, reliability, maintainability, human-factors, cybersecurity, regulatory, and lifecycle requirements address conditions that extend beyond basic function.

Elicitation, Analysis, and Specification

Requirements engineering begins with elicitation. Relevant stakeholders may include the purchaser, end user, operator, maintenance technician, manufacturing engineer, safety authority, supplier, service organization, and persons affected by the system even if they do not operate it directly. Each group sees different risks and benefits. Operators understand workflow and usability; maintainers understand access and fault isolation; manufacturers understand process capability; regulators understand compliance obligations.

Useful elicitation methods include interviews, observation of current operations, workshops, document analysis, benchmarking, scenario development, interface analysis, and examination of failure data from existing equipment. Observation is especially valuable because stated procedures often differ from actual practice. A maintenance technician may reveal that a “simple” inspection requires removing three guards, while a production operator may identify a delay caused by frequent manual resets.

Elicited statements must be analyzed before they are entered into a formal specification. Conflicts should be exposed rather than silently resolved. For example, a marketing request for minimum mass may conflict with a safety requirement for impact resistance. A requirement review asks whether each statement has a source, a rationale, a priority, a verification method, and measurable thresholds.

A useful requirement pattern is:

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

For example: “The positioning stage shall locate the payload within ±0.05 mm over a 300 mm travel range at ambient temperatures from 10°C to 35°C.” The statement identifies the subject, action, operating condition, and measurable performance.

Words such as “approximately,” “adequate,” “user-friendly,” “minimal,” “rapid,” and “where possible” should be avoided unless they are accompanied by an agreed interpretation. Compound requirements should be divided. “The system shall be lightweight, inexpensive, quiet, and easy to service” contains at least four distinct requirements and probably requires separate rationale and verification methods.

The specification should distinguish mandatory language from informative material. In formal engineering practice, “shall” normally indicates an obligation, “should” indicates a recommendation, and “may” indicates permission or possibility. A specification also benefits from identifiers, revision history, rationale, source, owner, priority, verification method, and status. Digital requirements tools can store these attributes and expose conflicts, omissions, and changes.

Functional Decomposition: From Purpose to System Behaviour

Once the principal requirements are understood, the designer asks what the system must do rather than what parts it should contain. Functional analysis represents the system as transformations of inputs into outputs. Inputs may include energy, material, information, and human commands; outputs may include useful work, transported material, heat, noise, data, and rejected waste.

The top-level function describes the system mission, such as “position a payload,” “convert fluid energy into controlled rotary motion,” or “remove heat from an enclosure.” This function is then decomposed into subordinate functions. A payload-positioning system might need to receive a command, support the payload, generate motion, guide the motion, measure position, control acceleration, stop safely, and communicate status. Functional decomposition should continue until functions can be allocated to physical or logical elements without excessive ambiguity.

The functional view should not be confused with the physical view. “Measure position” is a function; an encoder is one possible solution. Maintaining this separation encourages alternative concepts and prevents premature commitment. It also makes it easier to identify missing functions. A physical assembly may appear complete while lacking fault detection, energy isolation, calibration, or safe shutdown functions.

Several representations are useful. A functional block diagram shows transformations and flows. A functional flow block diagram emphasizes sequence and control. State-transition models describe behaviour in modes such as idle, startup, operation, fault, emergency stop, and maintenance. Use-case or operational-scenario models describe interactions with users and external systems. For complex projects, these models can be linked in a model-based systems-engineering environment.

Functional decomposition must consider abnormal as well as nominal operation. If a sensor fails, if power is lost, if an operator releases a control, or if a load exceeds the expected value, what shall the system do? Safety-related functions such as limiting motion, dissipating stored energy, preventing unintended restart, and providing warnings must be represented explicitly.

Systems Architecture and Allocation of Responsibility

Systems architecture is the arrangement of system elements, their relationships, and the principles governing their design and evolution. It provides a bridge between requirements and detailed engineering. Architecture is not merely a drawing of components. It expresses decisions about boundaries, allocation of functions, interfaces, information flows, energy paths, control authority, modularity, redundancy, and lifecycle responsibilities.

A useful architecture has at least three complementary views. The functional architecture describes what the system does and how functions interact. The logical architecture identifies logical elements such as motion-control, energy-management, sensing, and safety-monitoring units. The physical architecture maps these logical elements to actual hardware, software, human roles, and external services. A physical architecture might include a frame, actuator, gearbox, controller, sensor set, guarding, power converter, operator interface, and maintenance provisions.

Allocation is the decision about which element performs each function. A function may be allocated to one element, shared among several, or retained as a system-level responsibility. Allocation decisions should consider performance, safety, reliability, manufacturability, maintainability, cost, mass, energy use, technology maturity, and organizational capability. For example, a braking function may be allocated partly to software control and partly to a mechanically independent brake. Such allocation can improve fault tolerance but increases complexity and interface requirements.

Architectural boundaries deserve particular attention. A boundary determines what is inside the system of interest and what is external. If a power supply is treated as external, its voltage stability, connector, fault behaviour, and maintenance responsibilities must still be represented as external-interface requirements. Poorly defined boundaries are a common source of “orphan” requirements—obligations for which no design authority accepts responsibility.

Interfaces as Designed Elements

An interface is a point or condition of interaction between elements. Mechanical interfaces include mounting patterns, clearances, fits, loads, stiffness, thermal contact, and allowable misalignment. Electrical interfaces include voltage, current, grounding, protection, and connector characteristics. Information interfaces include data formats, timing, protocols, accuracy, and failure signalling. Fluid and thermal interfaces include pressure, flow, temperature, leakage, and heat-transfer conditions. Human interfaces include controls, displays, access, force, reach, visibility, training, and warning conventions.

Interfaces should be specified as carefully as components. A shaft and coupling may each satisfy their individual strength requirements but fail because of incompatible tolerances or excessive angular misalignment. Similarly, a sensor may have adequate accuracy in isolation but become unsuitable when sampling latency causes unstable control behaviour. Interface control documents, connection diagrams, data dictionaries, and tolerance budgets help make these interactions explicit.

Traceability, Verification, and Change Control

Traceability is the ability to follow a requirement from its origin through analysis, architecture, design, implementation, verification, validation, and operational evidence. A simple bidirectional chain is:

Stakeholder need → system requirement → allocated requirement → design element → verification case → result.

Forward traceability confirms that every need has been addressed. Backward traceability confirms that every design feature and test has a legitimate purpose. A requirements traceability matrix is a practical tool, although a matrix alone does not guarantee quality. The underlying links must be meaningful and maintained as the design evolves.

Verification asks, “Was the system built according to the specified requirements?” Validation asks, “Does the delivered system satisfy the intended stakeholder need in its actual context?” A system can pass verification and still fail validation if the original requirement was incomplete or poorly understood. Verification methods commonly include inspection, analysis, demonstration, and test. Inspection may confirm dimensions or workmanship; analysis may establish strength through a validated model; demonstration may show an operating sequence; test may measure performance under controlled conditions.

Each requirement should have a planned verification method, conditions, instrumentation, tolerances, and pass/fail criteria. “Test for safety” is not an adequate verification statement. A stronger definition might identify the operating mode, fault condition, load, environmental range, response time, and allowable outcome. Verification planning early in the lifecycle exposes requirements that are difficult, expensive, or impossible to assess objectively.

Requirements change because stakeholders learn more, technology changes, regulations evolve, or analysis reveals infeasibility. Change control should not suppress legitimate learning; it should ensure that changes are evaluated systematically. A change request should record the proposed modification, reason, affected requirements, interfaces, risks, cost, schedule, verification impact, and approval authority. Configuration management preserves the identity and status of approved baselines.

Trade-Off Studies and Architectural Decision-Making

Architecture rarely produces a single obviously correct solution. Engineers must compare alternatives under competing objectives. A trade-off study defines the decision, establishes evaluation criteria, develops credible alternatives, estimates performance and risk, and documents the rationale for selection.

Criteria may include mass, cost, efficiency, stiffness, response time, reliability, maintainability, safety, noise, manufacturability, supply risk, environmental impact, and technology readiness. Criteria should be linked to requirements rather than selected merely because they are easy to calculate. Weighting can represent relative importance, but weights should be examined for bias and sensitivity. A weighted decision matrix is useful for screening, not for disguising uncertain judgments as precise mathematics.

Quantitative models can support the study. A simplified lifecycle-cost model may include acquisition, energy, maintenance, downtime, consumables, and disposal. A risk-informed comparison may use probability and consequence categories, while recognizing that numerical risk estimates are uncertain. Sensitivity analysis asks whether a small change in an assumption reverses the decision. If it does, the design team should seek better information or preserve flexibility rather than claim unwarranted certainty.

A sound trade study documents rejected alternatives and the reasons for rejection. This record supports review, prevents repeated debate, and makes assumptions visible. It also helps future engineers understand whether a decision was driven by performance, safety, schedule, supply chain, or an organizational constraint.

The Systems-Engineering Process in Mechanical Design

A systems-engineering process is iterative rather than strictly linear. It usually begins with mission or stakeholder analysis, followed by requirements definition, functional analysis, concept development, architecture synthesis, trade studies, detailed design, integration, verification, validation, operation, and retirement. Information flows backward as well as forward. Test results may reveal that a requirement must be clarified; a manufacturing constraint may require architectural revision; a field failure may expose an omitted maintenance function.

At each stage, technical reviews provide decision gates. A requirements review examines completeness and testability. A system or architecture review examines functional allocation, interfaces, risks, and feasibility. A preliminary design review assesses whether the selected architecture can meet requirements. A critical design review examines design maturity before manufacturing or release. The names and formalities vary among organizations, but the underlying purpose is controlled evidence-based progression.

For mechanical systems, systems engineering must remain connected to engineering analysis. Structural, thermal, kinematic, dynamic, fluid, control, materials, manufacturing, reliability, and human-factors analyses provide evidence for requirements and architecture decisions. The systems engineer does not replace specialists; rather, the role integrates their models and makes interactions visible.

Applied Case: Architecture of an Automated Pallet-Positioning Module

Background

The following is an illustrative case developed for educational purposes. A manufacturer intends to add an automated pallet-positioning module to an existing assembly line. Pallets weighing up to 600 kg must be moved 1.2 m laterally, aligned with an assembly fixture, and released without interrupting adjacent operations.

Situation and Problem

The initial customer statement is: “The new unit must be compact, fast, reliable, safe, and compatible with the current line.” The existing statement is insufficient for design because it does not define alignment accuracy, cycle time, duty cycle, installation limits, operator interaction, or fault behaviour. The module must also interface with an existing programmable controller and floor-mounted structure.

Analysis of Needs and Requirements

Stakeholder interviews identify the following measurable needs: the pallet shall be positioned within ±1 mm; a complete movement and confirmation cycle shall not exceed 12 s; the unit shall operate for two shifts per day; routine lubrication and inspection shall be possible without removing the pallet conveyor; and loss of power shall not cause uncontrolled pallet motion. The maintenance group additionally requires access to wear components from one side because the rear of the module is against a wall.

These needs are converted into system requirements. Examples include:

• The module shall move a 600 kg pallet over a horizontal travel of 1.2 m.
• The module shall achieve final positional accuracy of ±1 mm under the defined payload and temperature conditions.
• The module shall complete the positioning cycle within 12 s, excluding upstream pallet-release delays.
• The module shall provide a positive stopped state and shall prevent unintended motion following loss of control power.
• The module shall permit scheduled inspection and replacement of designated wear components from the operator side.
• The module shall exchange position, cycle-status, fault, and reset information with the line controller through the approved interface.

Each requirement receives an identifier, source, rationale, priority, verification method, and owner. The boundary is defined to include the positioning mechanism, drive, sensors, guarding, local safety functions, and operator interface, but not the existing line controller or plant electrical distribution. External interfaces are nevertheless specified.

Functional and Architectural Analysis

The top-level function is “position pallet for assembly.” Decomposition produces the functions receive pallet, support load, generate lateral motion, guide motion, measure position, control motion, detect obstruction, stop safely, confirm alignment, communicate status, and enable maintenance isolation.

Two architectures are considered. Alternative A uses a ball-screw drive with servo motor and linear guideways. Alternative B uses a rack-and-pinion drive with geared motor and absolute position sensing. Alternative A offers high positioning precision and straightforward closed-loop control but requires protection from contamination and careful lubrication. Alternative B provides longer travel capability and tolerance to some contamination, but backlash management and mechanical alignment are more demanding.

The trade study weights accuracy, cycle time, maintainability, safety, contamination tolerance, cost, and integration risk. The ball-screw concept performs strongly on accuracy and control but requires a sealed enclosure and side-access lubrication arrangement. The rack-and-pinion concept is attractive for robustness and cost but requires additional measures to achieve the alignment requirement. The team selects the ball-screw architecture, not because it is universally superior, but because the specified accuracy and available travel dominate the decision.

Safety analysis identifies a crush hazard between the moving pallet and the fixed fixture. The architecture therefore includes guarded access, an interlocked gate, presence detection in the hazard zone, a safety-rated stop path, mechanical holding capability, and a controlled restart procedure. The safety function is not left solely to application software. Mechanical, electrical, and control measures are allocated with explicit assumptions about fault behaviour.

Verification and Outcome

Verification is planned concurrently with design. Travel and load capacity are tested using calibrated loads. Position accuracy is measured across the travel range and representative temperature conditions. Cycle time is demonstrated over repeated cycles. Power-loss behaviour is tested from defined operating states. Maintenance access is inspected using the actual tooling and prescribed procedure. Controller communication is verified using interface test cases, while integrated trials validate the module in the assembly-line context.

The case illustrates that architecture is a reasoned response to requirements, not simply a choice of mechanism. It also shows why safety, maintenance, integration, and verification must be addressed before detailed component sizing is complete.

Challenges, Risks, and Common Errors

A frequent error is writing solutions as requirements. Statements such as “the system shall use an aluminium frame” may be justified as constraints, but if they are merely early design preferences they can prevent better alternatives. Another error is accepting vague adjectives without thresholds. Ambiguity creates inconsistent interpretations and disputes late in the project.

Incomplete stakeholder representation produces requirements that optimize performance for one group while imposing unacceptable burdens on another. A design that minimizes mass but cannot be repaired within the production window may fail economically. Similarly, a system that performs well in laboratory tests may be unsuitable for real operators because access, visibility, noise, or training needs were ignored.

Requirements can also be over-specified. Excessive detail at the system level restricts innovation and creates unnecessary verification effort. The appropriate level of detail depends on risk, contractual responsibility, safety, and the maturity of the design. Requirements should define necessary outcomes and interfaces while leaving legitimate solution freedom.

Interface instability is another major risk. Late changes to connectors, mounting dimensions, communication timing, or thermal limits can force redesign across several subsystems. Interface ownership, early mock-ups, tolerance analysis, and integration tests reduce this risk.

Traceability can become a bureaucratic exercise if links are created without rationale or if obsolete requirements remain active. A smaller set of high-quality, maintained relationships is more useful than a large unreviewed database. Finally, numerical scoring in trade studies can create false objectivity. Uncertainty, sensitivity, and expert judgement should be visible in the decision record.

Professional, Ethical, and Regulatory Considerations

Engineers have a professional duty to protect people, property, and the environment. Requirements engineering supports this duty by making safety obligations explicit and by preventing schedule or cost pressure from silently weakening essential controls. Safety requirements should be derived from hazard identification, risk assessment, applicable standards, and the intended operating context. Compliance with a standard is important, but compliance alone does not absolve the engineer from considering reasonably foreseeable misuse.

Ethical practice also requires honest representation of uncertainty. A model result should not be presented as measured performance, and a preliminary assumption should not be treated as a validated fact. Requirements baselines, test evidence, deviations, and residual risks should be communicated transparently to authorized decision-makers.

Regulatory obligations may address machinery guarding, pressure systems, lifting equipment, electromagnetic compatibility, environmental emissions, accessibility, or product liability, depending on jurisdiction and application. The relevant legal and standards framework must be identified early. Where automated or connected systems are involved, access control, secure updates, event logging, and protection of operational data become part of responsible architecture.

Digital Engineering and Emerging Practice

Requirements-management platforms can provide version control, approval workflows, impact analysis, and links to models, drawings, simulations, tests, and nonconformance records. Model-based systems engineering extends this idea by representing requirements, functions, states, interfaces, and physical elements in an integrated model. Digital twins and simulation environments can support early validation of dynamic behaviour, thermal performance, energy consumption, and operator interaction.

Artificial intelligence can assist with classifying stakeholder statements, detecting duplicate requirements, suggesting traceability links, and identifying inconsistent terminology. Such tools must remain under engineering governance. Generated suggestions require human review because models may miss safety implications, misinterpret context, or reproduce biased assumptions. Sensitive project information should also be protected when external digital services are used.

Emerging practice emphasizes lifecycle architecture, circularity, maintainability, modular upgrades, and resilience of supply chains. Requirements increasingly include energy efficiency, material recovery, carbon impact, software updateability, data integrity, and end-of-life disassembly. These concerns expand the system boundary beyond the initial product delivery and reinforce the importance of architecture decisions made early in the design process.

Best Practices for Engineering Teams

A disciplined team should establish the system boundary, stakeholder map, terminology, assumptions, and decision authority at the beginning. It should maintain a controlled requirements baseline, write measurable statements, record rationale and verification method, and review requirements with both technical and operational stakeholders.

Functional decomposition should precede detailed solution selection where practical. Architecture should be expressed through multiple views, with interfaces treated as first-class design objects. Trade studies should compare credible alternatives using requirement-linked criteria and sensitivity analysis. Safety, maintenance, manufacturing, and verification representatives should participate before the architecture is frozen.

Finally, the team should expect iteration. Requirements engineering is not a one-time paperwork activity; it is an evidence-based learning process. The objective is not to eliminate all change but to make change visible, reasoned, affordable, and traceable.

Chapter Summary

Requirements engineering transforms stakeholder needs into clear, feasible, prioritized, and verifiable obligations. High-quality requirements are necessary, unambiguous, singular, measurable, traceable, and consistent. Elicitation must include users, operators, maintainers, manufacturers, regulators, and other affected stakeholders. Functional decomposition identifies system behaviour independently of particular hardware, while architecture organizes functions into logical and physical elements and defines their interfaces.

Traceability links needs to requirements, design elements, verification cases, and evidence. Verification determines whether specified requirements have been met; validation determines whether the delivered system satisfies the intended need in context. Trade-off studies provide a structured basis for decisions involving competing performance, cost, safety, lifecycle, and technical factors. Systems engineering integrates these activities iteratively throughout the lifecycle. Digital tools, model-based engineering, simulation, and carefully governed AI can improve consistency and insight, but professional judgement and ethical responsibility remain essential.

Key Terms

Stakeholder need: A desired outcome or condition expressed by a person or organization affected by the system.

Requirement: A necessary, stated capability or condition that the system must satisfy.

Specification: A controlled document or data set defining requirements and associated information.

Constraint: A limitation that restricts allowable solutions.

Assumption: A proposition accepted temporarily pending confirmation by evidence.

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

Performance requirement: A measurable statement of how well the system must perform.

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

Acceptance criterion: An objective condition used to determine whether a deliverable is acceptable.

Functional decomposition: The division of a system mission into progressively smaller functions.

Systems architecture: The organized arrangement of system elements, relationships, boundaries, and governing principles.

Logical architecture: The allocation of functions to conceptual or logical elements before final physical implementation.

Physical architecture: The arrangement of actual hardware, software, human, and external elements.

Interface control document: A controlled description of the characteristics and responsibilities at an interface.

Traceability: The ability to follow a requirement through its source, design allocation, verification, and evidence.

Verification: The process of determining whether specified requirements have been satisfied.

Validation: The process of determining whether the delivered system fulfills its intended purpose in context.

Trade study: A structured comparison of alternatives against defined criteria.

Configuration management: Control of approved system descriptions, changes, versions, and status.

Model-based systems engineering: The use of integrated formal models to represent requirements, functions, interfaces, and system elements.

Review Questions

Short Answer Questions

1. Why is a stakeholder statement such as “the machine shall be safe and compact” insufficient as a system requirement?

2. Distinguish a requirement, a constraint, and an assumption.

3. What is the difference between functional architecture and physical architecture?

4. Define forward and backward traceability.

5. Differentiate verification from validation.

Long Answer Questions

1. Explain the complete process of converting stakeholder needs into a controlled system specification.

2. Discuss functional decomposition and explain why it should normally be separated from premature selection of physical components.

3. Describe the major views of systems architecture and explain how allocation decisions influence mechanical-system performance and lifecycle cost.

4. Explain how interface requirements, verification planning, and configuration management contribute to successful system integration.

5. Discuss the role of trade studies in architecture selection, including criteria, weighting, uncertainty, and sensitivity analysis.

Analytical / Application Questions

1. A customer requests a robotic fixture that is “fast, accurate, low-cost, and easy to maintain.” Convert this statement into at least six measurable system requirements and identify an appropriate verification method for each.

2. Two concepts for a mobile lifting platform are available: a hydraulic actuator system with high force density and an electromechanical screw drive with simpler control. Develop a trade-study framework that considers performance, safety, energy use, maintenance, environmental conditions, and lifecycle cost.

3. For an automated packaging machine, construct a functional decomposition for receiving a product, orienting it, placing it in a carton, confirming placement, and responding to faults. Identify at least four critical interfaces and explain how each should be specified.

22. Multiple Choice Questions with Answers

Question 1

Which statement is the best example of a well-formed system requirement?

A. The machine shall be compact and user-friendly.

B. The machine shall use a high-power servo motor.

C. The positioning stage shall locate the payload within ±0.05 mm over 300 mm travel at 10°C to 35°C.

D. The machine should operate quickly whenever possible.

Correct Answer: C. The positioning stage shall locate the payload within ±0.05 mm over 300 mm travel at 10°C to 35°C.

Question 2

What is the principal purpose of functional decomposition?

A. To select a preferred supplier before defining system behaviour.

B. To divide the system mission into functions that can be analyzed and allocated.

C. To replace verification testing with a physical drawing.

D. To specify the final material of every component.

Correct Answer: B. To divide the system mission into functions that can be analyzed and allocated.

Question 3

Which statement correctly distinguishes verification from validation?

A. Verification concerns cost, while validation concerns mass.

B. Verification asks whether requirements were met; validation asks whether the system fulfills its intended purpose.

C. Verification occurs only after production, while validation occurs only before design.

D. Verification applies to components, while validation never applies to complete systems.

Correct Answer: B. Verification asks whether requirements were met; validation asks whether the system fulfills its intended purpose.

Question 4

A sensor and controller each meet their individual specifications, but control becomes unstable because of communication delay. This most directly demonstrates the importance of:

A. Stakeholder mapping.

B. Interface analysis.

C. Material selection.

D. Configuration naming.

Correct Answer: B. Interface analysis.

Question 5

Which item is most appropriately treated as a constraint?

A. The system shall position a load within ±1 mm.

B. The operator shall receive a fault indication within 2 s.

C. The assembly shall fit within an existing 1.5 m installation envelope.

D. The system shall operate for eight hours per shift.

Correct Answer: C. The assembly shall fit within an existing 1.5 m installation envelope.

Question 6

In a requirements traceability chain, which relationship provides backward traceability?

A. A stakeholder need linked to a system requirement.

B. A design feature linked to an approved requirement.

C. A requirement linked to a stakeholder interview.

D. A test result linked only to a supplier invoice.

Correct Answer: B. A design feature linked to an approved requirement.

Question 7

Why should safety functions not automatically be allocated solely to application software?

A. Software cannot contain any requirements.

B. Independent mechanical or hardware measures may be needed to control faults and unintended motion.

C. Mechanical systems do not require safety analysis.

D. Software is always more expensive than mechanical hardware.

Correct Answer: B. Independent mechanical or hardware measures may be needed to control faults and unintended motion.

Question 8

A trade study is most useful when it:

A. Makes an early preferred concept appear mathematically certain.

B. Compares credible alternatives against requirement-linked criteria and records assumptions.

C. Eliminates all qualitative engineering judgement.

D. Considers only acquisition cost.

Correct Answer: B. Compares credible alternatives against requirement-linked criteria and records assumptions.

Question 9

Which practice best reduces the risk of late integration failure?

A. Delay interface definition until detailed drawings are complete.

B. Treat interfaces as designed elements and verify their characteristics early.

C. Allow each subsystem team to define interfaces independently without coordination.

D. Replace all interface requirements with general performance goals.

Correct Answer: B. Treat interfaces as designed elements and verify their characteristics early.

Question 10

An AI tool identifies duplicate requirements in a project database. What is the appropriate engineering response?

A. Accept all suggested changes automatically.

B. Delete every similar requirement without stakeholder review.

C. Use the suggestions as input to a controlled human review and approval process.

D. Permit the tool to establish safety requirements without engineering governance.

Correct Answer: C. Use the suggestions as input to a controlled human review and approval process.