Good to see you again. In the previous lesson, you used whole-system thinking to trace how a local change can create consequences across stakeholders, interfaces, and life-cycle stages. That analysis produces an important next question: how should those insights be expressed so they can guide engineering without prematurely locking in a solution?
This lesson distinguishes six terms that are often blurred together in both project discussions and CSEP-style questions: needs, requirements, functions, behavior, architecture, and design. They are connected, but they answer different questions and belong at different levels of abstraction. By the end, you should be able to classify a statement or model artifact accurately and explain how it contributes to an MBSE model in SysML/Cameo.
A single system story, told in six different ways
Consider a proposed temperature-controlled medication cabinet used in a hospital pharmacy. The pharmacy needs medicines kept within safe storage conditions, staff need warnings before stock is compromised, maintainers need faults to be diagnosable, and the hospital needs an affordable, compliant service.
Those concerns cannot responsibly begin with “use sensor X,” “choose compressor Y,” or “write a PID controller.” Those are possible solutions, not yet the problem to be solved.
A disciplined engineering story moves through six distinct lenses:
| Lens | Central question | Medication-cabinet example |
|---|---|---|
| Need | What outcome does a stakeholder need? | Pharmacy staff need medicines to remain safe for use during storage. |
| Requirement | What must the system do or be, under stated conditions, to meet that need? | The cabinet shall maintain the storage compartment within the approved temperature range under defined operating conditions. |
| Function | What capability must be performed? | Regulate compartment temperature. |
| Behavior | How does the system act over time in response to inputs, events, and states? | On detecting an excessive temperature, the cabinet records the event, alerts staff, and attempts recovery according to its operating logic. |
| Architecture | What elements and relationships organize the system to realize required capabilities? | A thermal-control element, sensing element, alarm element, logging element, user-interface element, and power interface exchange energy, signals, and data. |
| Design | What specific realization will be built, coded, configured, or procured? | A selected sensor type, cooling technology, wiring arrangement, controller algorithm, display layout, enclosure drawing, and software implementation. |
The terms form a connected engineering argument, but they are not interchangeable. A requirement is not automatically a function; a function is not a physical component; architecture is not a fully detailed design; and a stakeholder need is not yet necessarily a verifiable technical commitment.
The following SEBoK reading establishes the most important distinction: stakeholder needs express a stakeholder perspective, while system requirements express the technical perspective needed to realize the system.
Stakeholder Needs Definition - SEBoK
Read the relevant parts of SEBoK's “Stakeholder Needs Definition” to establish the distinction between stakeholder needs and system requirements before examining functions and architecture.
In “Purpose and Definition,” read the perspective distinction. Then go to “Define and Baseline the Integrated Set of Needs,” beginning at the paragraph that starts “Needs are written in a structured...” and read the guidance and examples. Focus on the stakeholder viewpoint and on why SEBoK recommends that needs avoid the word “shall.”
Needs: the stakeholder’s desired condition
A need expresses what a stakeholder needs the system of interest to achieve, enable, avoid, or possess. It originates outside the engineering solution: from users, acquirers, maintainers, regulators, operators, suppliers, affected communities, or other stakeholders.
A well-framed need is purposeful. It communicates a desired capability, outcome, constraint, or quality without assuming an implementation.
For the medication cabinet:
The pharmacy staff need the system to preserve the usability of temperature-sensitive medicines throughout normal storage operations.
This statement deliberately leaves many things open:
- Which cooling principle should be used?
- How is temperature measured?
- Does the cabinet have one compartment or several?
- What happens during a power interruption?
- How will alerts be communicated?
Those questions matter, but answering them too early can exclude viable alternatives. A need establishes the reason the system exists and the outcome against which the realized system will ultimately be validated.
Needs are not merely vague wishes
It is tempting to equate a need with an informal preference such as “make it easy to use.” Some needs begin that way, but systems engineering develops them into an integrated, evidence-based set that includes:
- mission or business objectives;
- stakeholder expectations;
- operating conditions;
- safety, security, and regulatory constraints;
- life-cycle concerns, including maintenance and disposal;
- measures of effectiveness and success.
A need can be specific. For example, “The pharmacy needs the system to operate safely in an ambient temperature range of...” can be a legitimate stakeholder need when the operating environment is central to the mission. What makes it a need is its stakeholder-oriented purpose, not its level of numerical detail.
A helpful exam heuristic is:
If the statement primarily expresses a stakeholder’s desired outcome or concern, and does not yet make a binding engineering commitment, it is most likely a need.
Requirements: binding, verifiable obligations on the system
A requirement states something the system of interest must do or be to meet validated needs. It becomes a technical obligation against which the system can be verified. In common INCOSE practice, a requirement is written with shall.
For example:
The medication cabinet shall maintain the storage compartment temperature between and when ambient temperature is within the specified operating range.
This is no longer simply a desired outcome. It imposes a measurable obligation on the cabinet. Engineers can assess its feasibility, allocate responsibility for meeting it, select a verification method, and ultimately gather evidence that it has been met.
The distinction is not simply grammatical, although “shall” is a useful cue:
| Feature | Need | Requirement |
|---|---|---|
| Primary viewpoint | Stakeholder or user | Engineering team and developer |
| Purpose | Explain what value or outcome is needed | Define a verifiable obligation on the system |
| Typical wording | “The user needs the system to...” | “The system shall...” |
| Implementation freedom | Generally high | Constrained by the stated obligation, but should remain solution-neutral at the current level |
| Evidence | Validated against stakeholder purpose and operational concept | Verified by inspection, analysis, demonstration, or test |
Requirements include more than primary functionality. SEBoK groups them into categories such as:
- Function and performance: what the system does and how well it performs.
- Fit and operational: interfaces, operating environments, human interactions, maintenance, transport, disposal, safety, and security.
- Form: physical or observable characteristics.
- Quality: reliability, maintainability, availability, interoperability, and related qualities.
- Compliance: conformance with regulations, standards, or mandated practices.
Therefore, “requirement” is the broad category. A function is one kind of engineering concept used to reason about the capabilities needed to satisfy some requirements; it is not a synonym for every requirement.
The next SEBoK extract explains how requirements transform needs into design inputs while avoiding premature implementation commitments.
System Requirements Definition - SEBoK
SEBoK’s “System Requirements Definition” connects needs to requirements, requirements to architecture, and textual requirements to an MBSE model.
First, in “Transforming Needs to System Requirements,” read the transformation principle, followed by the developer perspective. Then scan Table 1 in “Categorizing Requirements,” especially the Function/Performance, Fit/Operational, Form, Quality, and Compliance rows. Next, in “Requirements At Levels Within the Hierarchy,” read the allocation discussion. Finally, in “Model Form of Requirements,” read the MBSE representation paragraph. Focus on the fact that requirements and architecture mature together, rather than in isolated handoffs.
“What” versus “how” is relative to the system boundary
A common rule is:
Requirements state what the system must do; design states how it will do it.
This is useful, but incomplete unless you specify the system of interest.
At the medication-cabinet level, this is typically a requirement:
The cabinet shall provide an alarm when a storage-temperature limit is exceeded.
At the alarm-subsystem level, a lower-level requirement might state:
The alarm subsystem shall generate an audible warning of at least the specified sound-pressure level at the operator location.
At an even lower level, the selected buzzer and its drive circuit may be part of the design realization.
Thus, a statement that appears to be “how” at one level may become “what” for a lower-level system element. This is why requirements definition and architecture definition proceed iteratively and recursively through the system hierarchy.
Functions: capability without committing to a component
A function is an action performed by a system or element to transform, control, transport, store, or otherwise act upon something. Functions are usually named with a verb and noun:
- sense temperature;
- regulate temperature;
- receive user command;
- display status;
- record temperature history;
- notify operator;
- supply electrical power.
A function is not the component that performs it.
| Do not confuse | With |
|---|---|
| Sense temperature | Temperature sensor |
| Regulate compartment temperature | Compressor, heater, controller, or cooling unit |
| Notify operator | Buzzer, display, mobile notification service, or indicator lamp |
| Record temperature history | Database, memory chip, paper log, or cloud service |
The distinction preserves solution flexibility. “Notify operator” may be satisfied through sound, light, text message, a building-management interface, or several methods in combination. Selecting one of those methods is an architectural and design decision informed by needs, requirements, risks, operational context, and trade studies.
This is why functional analysis is useful early: it asks what transformations and capabilities are necessary before the team decides exactly what physical or software elements will perform them.
The Benefits of Functional Architectures | Systems Engineering, Part 3
Watch MATLAB’s “The Benefits of Functional Architectures | Systems Engineering, Part 3” for a compact visual explanation of how functional, logical, and physical architectures relate.
Watch the architecture overview to see architecture framed as elements and their connections, viewed functionally, logically, or physically. Then watch functions and allocation. Focus on the input–process–output character of a function, functional decomposition, and the later allocation of functions to logical and physical components.
Function versus functional requirement
These terms are related but different:
- A function is a capability representation, such as regulate temperature.
- A functional requirement is a binding statement that requires the system to provide a capability, such as:
The cabinet shall regulate storage-compartment temperature within the specified range.
A requirement may lead to one function, several functions, or a function shared by several requirements. Conversely, a function may support several requirements. Traceability makes those relationships visible rather than assuming a simplistic one-to-one mapping.
Behavior: functions unfolding in time
A function tells us what capability exists. Behavior tells us how the system acts over time: the sequences, states, events, decisions, inputs, outputs, and interactions through which functions are performed.
For the medication cabinet, “regulate temperature” is a function. A simplified behavioral story might be:
- The cabinet is in its normal storage state.
- The sensing function samples compartment temperature.
- The control logic compares the measurement with the permitted range and any control target.
- If cooling is needed, the thermal-control function is commanded to operate.
- If a limit is exceeded for a defined condition, the system enters an alarm condition, records the event, and notifies staff.
- When the condition is resolved and reset criteria are met, the system returns to normal operation or enters a reviewed recovery state.
Notice that behavior introduces time and conditions. It helps answer questions such as:
- What event starts this operation?
- What information, material, or energy enters and leaves?
- What states can the system occupy?
- What happens when a door is left open?
- What happens after sensor failure or loss of communications?
- In what order do alarms, logging, and recovery actions occur?
In SysML, behavior is often expressed with:
- activity diagrams for flows of actions and control;
- sequence diagrams for interactions among participants over time;
- state machine diagrams for states, events, transitions, and modes.
A behavioral model is not merely a more detailed function list. A list might contain sense temperature, regulate temperature, and notify operator. An activity or state model examines how those functions coordinate in normal and off-nominal situations.
Architecture: the organized arrangement that realizes capabilities
An architecture defines the fundamental organization of a system: its elements, their relationships, the interfaces among them, and the principles by which they are organized to meet the system’s purpose.
Architecture is therefore more than a parts list. It addresses questions such as:
- What are the significant elements of the system?
- Which functions are grouped together or allocated to each element?
- What does each element exchange with the others?
- Where are the system boundaries and external interfaces?
- Which decisions shape the system’s structure and constrain later design choices?
For the medication cabinet, a logical architecture might identify these elements:
| Logical element | Primary responsibility | Key interactions |
|---|---|---|
| Thermal-control element | Maintain storage conditions | Receives control commands; affects compartment thermal state |
| Environmental-sensing element | Measure temperature and related conditions | Sends measurements to control and monitoring elements |
| Monitoring and decision element | Evaluate conditions and determine responses | Receives sensor data; commands thermal control and alarms |
| Operator-interaction element | Display status and accept authorized commands | Exchanges status, alerts, and user inputs |
| Recording element | Preserve temperature and alarm history | Receives event and measurement data |
| External power interface | Receive and condition electrical power | Interacts with facility electrical supply |
| External service interface | Support maintenance, configuration, or data retrieval | Interacts with maintainers or hospital systems |
This architecture remains relatively implementation-neutral. “Environmental-sensing element” does not yet require a particular sensor manufacturer. “Monitoring and decision element” does not yet settle whether functionality will reside in a microcontroller, programmable logic controller, embedded computer, cloud service, or several distributed elements.
Architecture can be viewed in several complementary forms:
- Functional architecture organizes functions and the flows among them.
- Logical architecture groups functions into solution-independent or relatively abstract logical elements.
- Physical architecture identifies the physical and software elements that will realize the system and their interfaces.
The boundaries between these forms are not always perfectly sharp. The important discipline is to make the current viewpoint clear and to preserve traceability among views.
Design: the realizable specification
Design develops the architecture into the information needed to realize, build, code, configure, procure, integrate, and verify the system. It makes specific choices among alternatives.
For the medication cabinet, design outputs may include:
- selected cooling and heating mechanisms;
- sensor type, accuracy, mounting location, and calibration approach;
- electronics schematics and power-protection circuitry;
- enclosure dimensions, materials, insulation, and door seals;
- controller algorithm, software interfaces, and error handling;
- display layout and alarm sound characteristics;
- manufacturing drawings, software code, interface-control details, and test procedures.
The distinction can be summarized as follows:
| Architecture | Design |
|---|---|
| Defines significant elements, responsibilities, relationships, interfaces, and organizing principles | Defines the detailed realization of those elements and relationships |
| Preserves alternative implementation choices where appropriate | Selects and specifies a particular implementation |
| Supports system-level reasoning, allocation, and trade studies | Enables construction, coding, procurement, integration, and verification |
| Answers “How should the system be organized?” | Answers “What exactly will we build or configure?” |
The supplied design-process image captures this maturation. Integrated stakeholder needs become design-input requirements; architecture and design transform those inputs into design-output specifications; those outputs guide realization of the system element. The feedback loops matter: discoveries during architecture or design can reveal that needs or requirements must be clarified or revised.
One caution is essential: architecture is not “unimportant detail,” and design is not “mere implementation.” Architecture decisions can strongly determine affordability, safety, reliability, maintainability, security, and future upgrade options. Design converts those decisions into a realizable system while resolving the technical detail that architecture intentionally leaves open.
Classifying statements: an exam-ready comparison
Use this classification method when a scenario includes ambiguous language.
| If the statement mainly... | It is most likely... | Example |
|---|---|---|
| Expresses a stakeholder outcome, expectation, concern, or value | Need | “The pharmacist needs stock losses from temperature excursions to be minimized.” |
| Imposes a measurable, binding obligation on the current system of interest | Requirement | “The cabinet shall store a time-stamped record of each temperature excursion.” |
| Names an action or transformation without naming its implementation | Function | “Record temperature excursion.” |
| Describes responses, states, timing, sequencing, or interactions | Behavior | “When an excursion persists beyond the specified duration, the system records the event and enters the alarm state.” |
| Defines elements, interfaces, responsibilities, allocations, and relationships | Architecture | “The monitoring element receives temperature data and commands the thermal-control and alarm elements.” |
| Selects concrete technologies, dimensions, algorithms, materials, or build details | Design | “The controller shall use the selected thermistor circuit and embedded control algorithm.” |
The last example is intentionally context-dependent. At the cabinet level, it is a design choice because it specifies an implementation. At the level of the controller subsystem, a more refined statement concerning its interfaces or performance may become a subsystem requirement. Always ask: What is the current system of interest?
Representing the distinctions in SysML and Cameo
SysML does not automatically solve conceptual confusion. A model can contain attractive diagrams while still mixing needs, requirements, functions, components, and design decisions at the same abstraction level. The modeling discipline comes first; the notation then helps make that discipline visible.
The MagicGrid image is useful as an orientation map. It places requirements, behavior, structure, and parametrics in parallel pillars, and it distinguishes a higher-level problem space from the developing solution space.
For an initial Cameo model of the medication cabinet, a practical separation could be:
| Model area | Main content | Useful SysML/Cameo views |
|---|---|---|
| Stakeholder context and needs | Stakeholders, operational context, stakeholder needs, measures of effectiveness | Package structure, use cases, context views; organizationally defined need stereotype or metadata |
| System requirements | Verifiable requirements and their attributes | Requirement diagram and requirement tables |
| Functional and behavioral analysis | Functions, flows, scenarios, states, failure responses | Activity, sequence, and state machine diagrams |
| Architecture | Logical and physical elements, interfaces, allocations | Block Definition Diagram and Internal Block Diagram |
| Design realization | Detailed component choices, interfaces, algorithms, drawings, software and hardware specifications | Detailed block properties, interface definitions, linked design artifacts, specialized models |
| Analysis and verification support | Constraints, budgets, measures, verification evidence | Parametric diagrams, requirement relationships, verification-related properties |
A few relationship types are especially useful:
- Use traceability to preserve why a requirement, function, or design decision exists.
- Use refinement when a model element gives a clearer or more formal expression of another concern.
- Use allocation when functions, performance budgets, or responsibilities are assigned to architectural elements.
- Use satisfaction to show that a design or structural element fulfills a requirement.
The exact stereotype profile and relationship conventions depend on the organization’s modeling method. What matters is semantic consistency. For example, do not use a block named Temperature Sensor as though it were the function Sense Temperature, and do not record a selected part number as though it were still an open stakeholder need.
A compact reasoning workflow
When you encounter a system statement, diagram, or proposed model element, classify it using these questions:
-
Whose perspective is it?
A stakeholder outcome suggests a need; an engineering commitment suggests a requirement. -
Does it bind the system?
If it says what the system shall do or be and can be verified, it is a requirement. -
Is it an action independent of the solution?
A verb–noun capability such as manage electrical power is a function. -
Does it describe change over time?
States, events, sequences, decisions, and interactions describe behavior. -
Does it organize elements and their relationships?
Elements, interfaces, allocations, and structural principles describe architecture. -
Does it commit to a concrete realization?
Selected technologies, dimensions, code, materials, algorithms, and drawings belong to design.
Use these questions as a classification aid, not as a rigid pipeline. Engineering is iterative. A behavioral model can uncover a missing requirement; an architectural trade study can expose an infeasible need; a design analysis can require a revised performance budget. The value lies in keeping each artifact’s purpose clear while maintaining traceability among them.
Key takeaways
The six concepts form a connected but distinct chain of reasoning:
- Needs express stakeholder outcomes, concerns, and value.
- Requirements make verifiable technical commitments on the system of interest.
- Functions describe the capabilities needed, independently of a chosen component.
- Behavior describes how the system performs functions through time, states, events, and interactions.
- Architecture organizes elements, responsibilities, relationships, interfaces, and allocations.
- Design specifies the concrete realization that can be built, coded, configured, procured, and verified.
The most reliable discriminator is not a single keyword. It is the statement’s purpose, viewpoint, abstraction level, and relationship to the system boundary.
Next, the course turns from technical artifacts to the people and coordination mechanisms that guide them: the distinction and interaction among technical leadership, systems management, and systems engineering activities.
Can't find a good explanation? Sign up and we'll make it for you
Sign up