System Requirements Analysis – SEBOK (34)

The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements. (ISO/IEC 2008)

Activities of the process

Major activities and tasks during this process include

1. Analyze the stakeholder requirements to check completeness of expected services and operational scenarios (glossary), conditions, operational modes, and constraints.

2. Define the system requirements and their rationale.

3. Classify the system requirements using suggested classifications (see examples above).

4. Incorporate the derived requirements (coming from architecture and design) into the system requirements baseline.

5. Establish the upward traceability with the stakeholder needs and requirements.

6. Establish bi-directional traceability between requirements at adjacent levels of the system hierarchy.

7. Verify the quality and completeness of each system requirement and the consistency of the set of system requirements.

8. Validate the content and relevance of each system requirement against the set of stakeholder requirements.

9. Identify potential risks (or threats and hazards) that could be generated by the system requirements.

10. Synthesize, record, and manage the system requirements and potential associated risks.

11. Upon approval of the requirements, establish and control baselines along with the other system definition elements in conjunction with established configuration management practices.

Checking and Correctness of System Requirements

System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics which can be used to check system requirements, such as standard peer review techniques and comparison of each requirement against the set of requirements characteristics listed in Table 2 and Table 3 of the "Presentation and Quality of Requirements" section (above). Requirements can be further validated using the requirements elicitation and rationale capture described in section "Methods and Modeling Techniques" (below).

Requirements Elicitation and Prototyping

Requirements elicitation requires user involvement and can be effective in gaining stakeholder involvement and buy-in. Quality Function Deployment (QFD) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.

QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included so that all aspects of user needs are accounted for and prioritized.

Early prototyping can help the users and developers interactively identify functional and operational requirements and user interface constraints. This enables realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the users' understanding of the requirements and increases the probability of satisfying their actual needs.

Capturing Requirements Rationale

One powerful and cost-effective technique to translate stakeholder requirements to system requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in a requirements database. (Hull, Jackson, and Dick 2010).

Presentation and Quality of Requirements

Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about syntax of requirements statements, wording (exclusions, representation of concepts, etc.), characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to (INCOSE 2010, Section 4.2.2.2) and (ISO/IEC 2011).

There are several characteristics of both requirements and sets of requirements that are used to aid the development of the requirements and to verify the implementation of requirements into the solution.

Characteristics of Individual Requirements. (SEBoK Original)

Necessary: The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist which cannot be fulfilled by other capabilities of the product or process.

Implementation Free: The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met.

Unambiguous: The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand.

Consistent: The requirement is free of conflicts with other requirements.

Complete: The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the stakeholders' needs.

Singular: The requirement statement includes only one requirement with no use of conjunctions. Feasible: The requirement is technically achievable and fits within system constraints (e.g., cost, schedule, technical, lethal, regulatory).

Traceable: The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or other source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specification or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation.

Verifiable: The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.

Characteristics of a Set of Requirements. (SEBoK Original)

Complete The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set contains no to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable time frame for TBx items, determined by risks and dependencies.

Consistent: The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicate. The same term is used for the same item in all requirements.

Affordable: The complete set of requirements can be satisfied by a solution that is obtainable/feasible within life cycle constraints (e.g. cost, schedule, technical, legal, regulatory).

Bounded: The set of requirements maintains the identified scope for the intended solution without increasing beyond what is needed to satisfy user needs.

System Requirement

Statement that expresses an expected characteristic or a constraint using a semantic code (such as natural language, mathematical, arithmetic, geometrical expression). A system requirement is feasible, objective, and verifiable.

Rationale Argument that provides the justification for the selection of an engineering element.

Scenario A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service.

Risk An event having a probability of occurrence and gravity degree on its consequence onto the system mission or on other characteristics (used for technical risk in engineering). A risk is the combination of vulnerability and of a danger or a threat.

System Requirements – SEBOK (33)

System requirements are all of the requirements at the “system level” that have been properly translated from the list of stakeholders' requirements. System requirements form the basis of system architecture and design, verification, validation, and stakeholder acceptance. System requirements play major roles in the engineering activities

• as the essential inputs of the system architecture and design activities;

• as reference for the system validation activities; and

• as a communication means, between the various technical staff that interact within the project.

Definition and Purpose of Requirements

A requirement is a statement that identifies a product or process operational, functional, or design characteristic or constraint which is unambiguous, testable or measurable and necessary for product or process acceptability. (ISO/IEC 2007)

To avoid confusion in the multitude of terms around requirements, consider the following classifications:

• Process role or state: The role the requirement plays in the definition process; for instance, its position in the system block: translated, derived, satisfied; or its state of agreement: proposed, approved, cancelled.

• Level of abstraction: The level within the definition process for the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.

• Type of requirement: The nature of the requirement itself; for instance functional, performance, constraint, etc.

Requirements Management

Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, and artifacts of the system. It includes ensuring an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule.

There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. Requirements management is also closely tied to configuration management for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.

Assessment Types for a System Requirement. (SEBoK Original)

Direct Assignment The system requirement from the higher level is directly assigned to a system or a system element for a lower level (for example, the color used to paint visible parts of the product).

Indirect Assignment (Simply Decomposed) The system requirement is distributed across several systems or system elements, and the sum or a more complex calculation for distribution is equal to the requirement of higher level (for example, a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.

Indirect Assignment (Modeled and Decomposed) The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique, and the resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, a radar detection requirement may be analyzed; lower-level parameters for output power, beam size, frequencies, etc. will then be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.

Derived Requirement (from Design) Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.

Classification of System Requirements

Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods used.

Functional Requirements Describe qualitatively the system functions or tasks to be performed in operation.

Performance Requirements Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task.

Usability Requirements Define quality in use such as measurable effectiveness, efficiency, and satisfaction criteria.

Interface Requirements Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.

Operational Requirements Define operational conditions or properties under which the system is required to operate or exist. This type of requirement includes human factors and ergonomics, availability, maintainability, reliability, security.

Modes and/or States Requirements Define the various operational modes of the system in use and events conducting to transitions of modes.

Adaptability Requirements Define potential extension, growth, or scalability during the lift of the system.

Physical Constraints Define constraints on weight, volume, and dimension applicable on system elements that compose the system.

Design Constraints Define the limits on the options open to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).

Environmental Conditions Define the environmental conditions to be encountered by the system in its different operational modes. Should be addressed the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environment (e.g. motion, shock, noise, electromagnetism, thermal, etc.), threats societal environment (e.g. legal, political, economic, social, business, etc.).

Logistical Requirements Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.

Policies and Regulations Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).

Cost and Schedule Constraints Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.

Architecture Definition – SEBOK (30)

System Architecture

Within the SE community, notions of architecture seem to have been heavily influenced by ISO/IEC 15288 (2008), which even today presents a somewhat implicit view of architecture, conflating it with design as part of a single system life cycle process called “architectural design”. Although there are diverse viewpoints on architecture, the different perspectives have much in common. We consider systems engineering to cover all aspects of the creation of a system, including system architecture. The majority of interpretations of system architecture are based on the fairly intangible notion of structure – i.e. relationships between elements.

Some authors limit the types of structure considered to be architectural; say, for example, restricting themselves to functional and physical structure. Recent practice has extended consideration to include temporal and other dimensions of structure within specified architectural frameworks (DoDAF (DoD 2010) and MODAF (MOD 2010)).

While architectural concepts are very useful and widely used in SE, there is a lack of consistency across communities of practice with potential for confusion. An attempt to develop and apply a systematic approach to characterizing architecture belief systems in systems engineering has been described by the INCOSE UK Architecture Working Group. (Wilkinson et al.2010, Wilkinson 2010).

System Design

In industrial practices, the term “design” is often used to mean both "architecture" and "design" as defined in the SEBoK. In the recent past, professionals used the term "design" when they dealt with simpler technological products - ones that do not include several different and interconnected technological components such as hardware, software, operators, services, etc. In the development of new multi-technology products and services, professionals have recognized the usefulness of the notion of "system" in dealing with complexity.

The trend today is to consider system architecture and design as different sets of activities; attempts are made to define separate concurrent processes, but they are strongly intertwined:

• System design includes activities to conceive a system that answers an intended purpose, using principles and concepts; it includes assessments and decisions to select elements that compose the system, fit the architecture of the system, and comply traded-off system requirements.

• System design is the complete set of detailed models, properties or characteristics described into a form suitable for implementation.

• System architecture is more abstract, conceptualization-oriented, global, and focused on mission success and on high level structure in (sub)systems.

The purpose of system design is to make the link between the system architecture and the implementation of technological system elements that compose the physical architecture of the system. These related processes are presented together in the present version of the SEBoK, though effort has been made to distinguish between the corresponding activities.

Transition from System Requirements to Physical Architecture

The aim of the approach is to progress from system requirements (representing the problem from a supplier/designer point of view, as independent of technology as possible) to an intermediate model of logical architecture (glossary), then to allocate the elements of the logical architecture to system elements of candidate physical architectures.

Design decisions and technological solutions are selected according to performance criteria and non-functional requirements such as operational conditions and life cycle constraints (e.g., environmental conditions, maintenance constraints, realization constraints, etc.). Creating intermediate models such as logical architecture models enables facilitation of the validation of functional, behavioral, temporal properties of the system against system requirements which have no major technological influence, and changing during the life of the system the physical interfaces or the technological layer without completely questioning the logical functioning of the system.

Iterations between Logical and Physical Architecture definition

Architecture and design activities require spending several iterations from logical architecture models definitions to physical architecture models definitions and vice versa, until both logical and physical architecture models are exhaustive and consistent. The first architecture and design activity is the creation of a logical architecture model based on nominal scenarios (of functions). Physical architecture is used to determine main system elements that could perform system functions and to organize them into a physical architecture model.

A second logical architecture iteration can take into account allocations of functions to system elements and derived functions coming from physical solution choices. It also supplements the initial logical architecture model by introducing other scenarios, failure analyses, and every operational requirement not taken before. Derived functions must, in their turn, be allocated to system elements. This, in turn, affects the physical architecture models.

Additional architecture and design iterations can produce an exhaustive and consistent logical and physical solution. During system design, technological choices can potentially lead to new functions, new input/output and control flows, and new physical interfaces. These new elements can conduct to creation of new system requirements, called “derived requirements”.

Concept of Interface

The concept of interface is one of the most important to consider when defining the architecture of a system. The fundamental aspect of an interface is functional and is defined as inputs and outputs of functions. As functions are performed by physical elements (system elements), inputs/outputs of functions are also carried by physical elements; these are called physical interfaces. Consequentially, both functional and physical aspects are considered in the notion of interface. A detailed analysis of an interface shows the function “send,” located in one system element, the function “receive,” located in the other one, and the function “carry,” performed by the physical interface which supports the input/output flow.