requirements definition and management using cradle · hardware configuration items (hwci),...

1

Requirements Definition and Management

Using Cradle

November 2014

3SL

2

1 Introduction This white paper describes Requirements Definition and Management activities for system/product development and modification projects using Cradle to manage the project requirements. The Requirement Definition and Management activities are grouped into eight stages as shown in the following figure.

The ‘AND’ nodes (circles with embedded AND symbol inside) in the above diagram indicate that some of the stages between the two ‘AND’ nodes can be performed in parallel. For example, Stage 3, 4, and 5 can be worked in parallel.

The Iterate nodes (circles with embedded I symbol inside) in the above diagram indicates that all stages between the two Iterate nodes are repeated for each level in the system architecture hierarchy. Level 1 in the hierarchy identifies the system entity. Each entity in levels greater than 1 is identified as a ‘system element’ (i.e., child component parts of a parent entity in the hierarchy). At the bottom level of the system hierarchy, the system elements represent Hardware Configuration Items (HWCI), Computer Software Configuration Items (CSCI), and Humans.

Stages 2 through 7 are repeated for each system element for which system requirements are to be developed. The details of the eight stages are presented in section 2, along with Sample Cradle work-products.

Section 3 contains a matrix that shows the traceability between these eight stages and similar technical process activities described in the INCOSE Systems Engineering Handbook (v.3.2.2). This traceability table shows that the Requirement Definition and Management activities described in this paper are compliant with the INCOSE Handbook and ISO/IEC 15288:2008.

System Element System Element System Element

System

System Element System Element System Element

System Element

Level 1

Level 2

Level 3

3

After reading the white paper, one should have a better understanding of the value of using a systems engineering tool, such as Cradle, for all requirement definition and management.

2 Requirements Definition and Management Activities

This section provides a description of the requirements definition and management activities divided into different stages.

Stage 1 - Define Concept of Operations & Stakeholder Requirements: The activities in this stage are performed at project start-up to define the project scope, prepare a concept of operations document (ConOps), and then develop the set of stakeholder requirements and publish in a Stakeholder Requirements Document (SRD).

Stage 2 - Define System/System Element Context: The activities in this stage will develop a System Context Diagram for a primary system element to identify all external entities that must interact with the system element and the required external interfaces. These external interfaces must be identified prior to beginning stages 3 through 7.

Stage 3 - Define System Elements: The activities in this stage are for defining physical

characteristics for the specified system element and then derive the appropriate system requirements for that element, then break-down the system element into its component parts (one level down the hierarchy), and identify a draft set of physical characteristics for each subordinate element.

Stage 4 - Define Functional Behavior: Identify system functions and their inputs and outputs that satisfy the system element functional requirements identified in the previous design cycle. These functions, when integrated together, describe the desired behavior the system must exhibit. In stage 5, the functions must be allocated to specific system elements (i.e., the things that must perform the functions).

Stage 5 - Allocate Functions to System/System Elements: In this stage, the functions and I/O (identified in stage 4) are assigned to different system elements and interfaces. This is known as functional allocation. The behavior of the specific system elements is specified.

Stage 6 - System Requirements Analysis & Verification Planning: In this stage, the system requirements derived in stages 3-5 are analyzed for clarity, completeness, consistency, and traceability to stakeholder/system requirements at the end of the previous design cycle. Also, verification planning activities should be performed for the newly created system requirements, and then establish a requirements baseline.

Stage 7 - Generate Documentation for System/System Elements: Generate deliverable documents and data packages to be used in support of each project review.

Stage 8 – System Verification & Validation (V&V) Traceability: Capture the status of each V&V activity in the database with traceability back to the impacted requirement and operational scenarios. The traceability identifies those requirements with links to design solutions that may need to be modified.

The details of these stages are presented in the following sub-section.

4

2.1 Stage 1- Define Concept of Operations & Stakeholder Requirements

The purpose of Stage 1 is to define the requirements for a system that can provide the services needed by users and other stakeholders in a defined environment. Successful projects depend on meeting the needs and requirements of the stakeholder/customer. The activities associated with this stage are as follows:

• Activity 1.1 – Define Project Scope. Clearly define and document the scope of the project. Create a top-level System Breakdown Structure (SBS) item for the project, and capture the project purpose, planned schedule, and expected Stakeholders.

o Gather project related source material and capture in the Cradle database using a

specific item type (e.g., REF DOC). The created items should be cross reference linked to the top-level SBS item for the System being developed.

o Interview the identified stakeholders and capture stakeholder needs, goals, and objectives. Link each Need, Goal, Objective item to the top-level SBS item.

o Identify the product life-cycle phases (e.g., Production, Operation, Disposal) for

which stakeholder requirements are to be defined.

• Activity 1.2 - Define Use Cases. Develop Use Cases for each applicable life-cycle phase. A Use Case is a mission. For example, you can define a use case for the operational phase.

5

• Activity 1.3 – Develop Concept of Operations. Create the Concept of Operations document (ConOps) based on the use cases / missions previously defined.

o Define one or more Operational Scenarios to accomplish each identified Use Case / Mission.

o Operational scenarios are process/activity flows describing how a system will be used, manufactured, tested, deployed, or operated throughout the product’s life-cycle. A typical scenario is a stimulus-response flow of activities/operations with I/O. These scenarios are from the viewpoint of the end-use stakeholders, not the product developers.

o A Process Flow Diagram (PFD) can be used to describe an operational scenario.

Establish traceability between a specific use case and the set of operational scenarios modeled by PFDs. Link the Operational Scenario to the Use Case.

6

o Multiple scenarios are usually required to understand the operational activities and

I/O associated with the accomplishment of each Mission/Use Case. o Link Use Case Specification items to the top-level SBS for traceability purposes.

• Activity 1.4 - Create Stakeholder Requirements. Define requirements that identify the intended operational services to be provided by the system and the interaction the system will have with its operational environment.

o Utilize the needs, goals, and objectives and the different operations identified during development of the operational scenarios to acquire the knowledge needed to develop specific stakeholder requirements. Once a new database item is created for the proposed requirement, enter the ‘shall statement’, a brief rationale, and then cross reference link it to the source material (i.e., need or scenario operation).

o If a source document is provided that contains useful information, such as

stakeholder requirements or test cases, you can use Cradle’s Document Loader to parse the contents of the document into individual pieces of information that are automatically loaded into the Cradle data repository as individual items of information.

o If one of the created items has multiple ‘shall’ statements that were captured from the original source document, the Cradle ‘split’ command can be used to automatically create new child items containing single shall statements.

o Use Cradle’s Conformance Checker to verify the use of good and bad phrases in the requirement statements.

o Create a Stakeholder Requirements Document and review with the customer to ensure that it is valid, meets the customer needs, and i s clearly understood by all stakeholders.

7

o The stakeholder requirements and the associated operational scenarios will be the basis for the system developer to derive system level design requirements during Stages 2 – 6. These design requirements are known as System Requirements.

• Activity 1.5 – Plan System Validation. Plan for system validation activities performed during integration and test by developing Validation Objectivities to be used to validate that the system fulfills the stakeholder’s needs as documented in the Stakeholder Requirements. Each Validation Objective identifies the validation methods, facilities, equipment, and resources needed to accomplish the validation activity, and should be linked to the Stakeholder Requirement being validated.

• Activity 1.6 – Design Constraints. Identify and capture design constraints in the data repository.

• Activity 1.7 – Capture Glossary Items. Include a common glossary item type so project members can collect a list of terms and acronyms that can be included in published documents.

2.2 Stage 2- Define System/System Element Context

A System Context Diagram in systems engineering is a diagram that defines the boundary between the system, or a system element, and the external entities that interact with the system. The high-level information exchanged between the system and the external entities is also shown on the diagram. The diagram is a high level, black box, view of the proposed system with its required external I/O.

Activity 2.1 – Create Context Diagram. Using the information developed in the previous stage(s), create a system operational context diagram using the Cradle Physical Architectural Diagram (PAD). The purpose of this diagram is to define the top-level external interfaces for the system or one of the system elements. o Draw the proposed black box system/system element as a rounded corner rectangle in

the center of the diagram. o Draw the external environment entities as rectangles around the proposed

system/system element symbol. o Draw the external interfaces between the proposed system/system element and the

entities outside the system boundary using annotated arrows. The I/O on the operational scenarios provides a good starting point to identifying the candidate external interfaces.

8

o Link the context diagram to the primary SBS item for which the current stage 2

through 7 cycle is being performed. This traceability is being established so reviewers/users can go to the SBS item and follow the cross references to all of the related information. During subsequent stages, additional relevant information will be linked to this item.

Activity 2.2 – Identify External Interfaces. Since this context diagram was constructed for

the system itself, not a lower-level system element (i.e., component part), and interfacing information must be cross referenced linked to an Interface Stakeholder Requirement that justifies the existence of the interface. In other words, the interfaces shown on the context diagram should all trace back to the Interface Stakeholder Requirements. In the following Cradle query view, some of the interface items have been traced to an Interface Stakeholder Requirement.

SBS for which Requirements being Defined in current Stage 2 – 7 Cycle

System Element Context Diagram

9

o As the interfaces are used in various design solutions in other stages of the systems

engineering process, a Cradle traceability view can be generated to support impact analyses as needed.

o Stage 2 is repeated for each level of the system structure hierarchy. When creating a

context diagram for a subordinate system element, the source material will be the allocated System Requirements derived during the previous cycle.

2.3 Stage 3- Define System Elements

A system is composed of a set of interacting system elements, each of which can be implemented to fulfill its respective system requirements. A system element has structure (how it is built) and behavior (what it does). An example of a system element is a hardware configuration item (CI), software CI, or human operator, where they all perform work.

10

When defining a system element, it is important to separate the structure definition from the functional behavior definition. If the desired behavior is developed independently from a predefined physical structure, then alternative component parts can be evaluated with the desired behavior mapped onto each alternative, so they each exhibit the desired behavior. A trade-off analysis can then be performed to pick the best solution. The mapping of functional behavior (described in stage 4) onto a system element structure (defined in this stage) is known as functional allocation and is illustrated in the following figure.

The purpose of this stage is to define the desired physical characteristics for the specified system element and then derive the appropriate System Requirements for that element. Next, break-down the system element into its component parts (one level down the hierarchy) and then identify a draft set of physical characteristics. By going one level deeper it helps identify missing information or inconsistent system element physical characteristics.

The activities in this stage are as follows:

Activity 3.1 – Analyze System Element Source Information. o Using source information developed during stage 1, or developed during stages 3 – 7

of the previous design cycle, perform analyses and trade studies to identify any mistakes in the material. If mistakes are found, document via ISSUE item type and link to the item in question.

o Create a System Element (equipment specification item) for the primary System Element SBS item and link them together.

System Element System Element

System

System Structure DescriptionFunctional Behavior Description

Mapped onto(allocation)

what it doeshow it is built

Data

ANDFunction 1 Function 2

Function 3

Function 4

Data

System Element“child”

System Element“child”

System Element (primary for this

design cycle)

Primary “System Element” for which Requirements are being defined during current design cycle

Always go one level deeper in hierarchy and identify candidate draft Child “System Elements”. During the next cycle each Child Element becomes the primary and the process is repeated until we get down to hardware or software CIs.

Defined physical characteristics

Derived System Requirements

(nonfunctional)

11

o Create an item in the database for any trade studies to be performed, and link the

item to the applicable SBS item so that this information will be known and available during project reviews.

Activity 3.2 – Define Non-Functional System Requirements. The purpose of this activity is to

specify the desired physical characteristics for the specified system element an then derive the appropriate System Requirements for that element. The following figure shows example non-functional requirements that are assigned to the primary system element.

Activity 3.3 – Define Candidate Subordinate System Elements. An example primary system

element and its candidate subordinate system elements to be analyzed in the current design cycle are presented in the following figure. By going one level deeper in the system architecture hierarchy, it helps the developers identify missing information or inconsistent system element physical characteristics.

12

2.4 Stage 4 - Define Functional Behavior

In order to develop and/or validate the primary System Element’s functional and performance requirements, a common technique used by systems engineers is to construct functional behavior models. These behavior models are developed to identify the functions the System Element must perform. The models are developed from the viewpoint of the system developer, NOT the stakeholder.

A behavior model consists of three things:

Functions, which accept inputs and transform them to outputs. Functions are executed by the System Elements

inputs and outputs, of various types

control operators, which conditionally define the execution order of functions

Some engineers choose to develop functional models after they have developed a textual requirements document, while many others follow the process described in the activities of stage 4. What is the best practice? Which comes first?

The activities for this stage are presented assuming models are developed first. However, if your project has a well defined set of functions that need to be implemented in a new system, then skip the model development activity, and import your functions list into Cradle and continue with the other activities.

Activity 4.1 – Develop Functional Model for the Primary System Element: o Using the source requirements from the previous Design Cycle, define the needed

functions and I/O as illustrated in the following figure.

Data


Function 3

Function 4

Data


(functional, Performance, and Interface)

Data


Function 3

Function 4

Data

Chicken or the Egg ? Write Requirements first then develop Functional Model, or develop Functional Model First per the process described in this paper?

13

o The two most commonly used functional modeling notations are the enhanced

Functional Flow Block Diagram (eFFBD) and the UML/SysML Activity Diagram. For this example the eFFBD was used. See following example.

Activity 4.2 – Create Functional Requirements and Link to Functions:

o Link each function to an applicable existing requirement (Stakeholder or System), or create and link a new derived System Requirement to the function. A traceability table (shown below) can be used to verify that each function is linked to one or more requirements. The team must review the data in the table to ensure proper traceability exists.

Stage 1

Needs, Operational Scenarios, Stakeholder Requirements

OR

Stage 4

(previous design cycle)

Derived Functional, Performance, and Interface

System Requirements

Cradle Project Repository


(functional, Performance, and Interface)

Data


Function 3

Function 4

Data

Use the source requirements to

help derive functional model

establish traceability back

to source requirements

14

Activity 4.3 – Establish Traceability to Source Requirements: All derived requirements must trace to a valid source requirement (system or stakeholder). If a source can’t be identified, determine if the derived requirement should be removed. If it is determined that the derived requirement is valid, then determine if the source material needs to be modified to account for the missing source requirement. An example of a backward traceability report is shown below.

Activity 4.4 - Create and Link Interface Requirements to Data Definitions: o The logical I/O in the functional models helps derive/validate interfaces between

System Elements in stage 5 and is used to help create interface requirements. Cradle automatically creates the following kinds of function I/O tables to provide easy visibility of interfacing information that needs to be linked to an appropriate interface requirement. The second table below shows an example of where the users created and linked new interface requirements.

15

Activity 4.5 – Decompose Functions: o In stage 3, once the primary System Element for the current design cycle is

decomposed into its component parts (one level down the hierarchy), each top-level function defined in the first part of stage 4 should be evaluated to see if they must be decomposed into sub-functions that can be uniquely allocated to one of the component parts. The actual allocation process takes place in stage 5. The following figure illustrates the concept.

Activity 4.6 – Establish Flow-Down of Functional Requirements & Linked to Functions:

o Whenever a function is decomposed, the requirement linked to the parent function must be evaluated to determine whether it can flow down unchanged to the sub-function, or whether it must also be decomposed.

2.5 Stage 5 - Allocate Functions to System/System Elements

In this stage, the functions and I/O (identified in stage 4) are assigned to different system elements and physical interfaces. In the following figure the 3 kinds of System Requirements (Functional, Non-Functional, and Interface) are linked directly and/or indirectly to the System

Data


Function 3

Function 4

Data

Data

Sub-Functionof Function 4

Sub-FunctionOf Function 4

Data


System Element

Function 4 decomposed

into two Sub-Functions

allocateallocate

allocate

ANDFunction 2

Function 3

Function 4

Data

Sub-Functionof Function 4

Sub-FunctionOf Function 4

Data

Functional System Requirement


Satisfy

Satisfy

Derived Req


Satisfy

16

Element that is to satisfy the requirement.

The activities for this stage are as follows:

Activity 5.1 – Allocate Functions to System Elements o Each top-level function defined in stage 4 should be allocated the primary System

Element for the current design cycle. This provides a list of the required functions to be performed by the System Element. The functions are linked to the System Element with the ‘allocate’ cross reference link type.

o Each leaf-level function defined in stage 4 should be allocated to one of the primary System Element’s subordinate elements.

o An example of function to system element allocation traceability is shown in the following figure.

o An example of the System Elements to Allocated Functions to Assigned

Requirements traceability is show in the following figure.


System

INTERFACEDerived

Nonfunctional System Requirements

Derived Functional System

Requirements

Derived Interface System

Requirements

allocate

satisfy

satisfy

allocate

satisfyData


Function 3

Function 4

Data

satisfy

17

Activity 5.2 – Define Physical Interfaces between System Elements

o Identify the I/O that flows between functions allocated to different System Elements. The identified information should be allocated to a physical interface between the System Elements. The following Cradle query view enables the user to identify the I/O Data Definitions (DD) that can flow across a physical interface between system elements. In the figure below, notice that ‘Target Track Data’ flows between Sensor System and the Fire Control System, therefore mechanism physical interface should be defined to achieve this flow of information.

o A physical model of the primary system element’s subordinate elements can also be used to identify the interfaces between the system elements. The following figure shows such a model.

18

Activity 5.3 – Allocate Non-Functional Requirements to System Elements. In stage 3, the

physical characteristics for the primary System Element were identified and draft non-functional requirements developed. In this stage, these non-functional requirements are refined as necessary, and the requirements are flowed down to the system element’s subordinate elements. In the following figure, requirements R.55 and R.56 are derived from requirement R.12 and linked to subordinate system elements.

Activity 5.4 – Perform Trial Allocations. In order to get a proper design solution, you

balance between performance, complexity, risk, by performing trial allocations. This means changing the allocations and/or changing the functional model I/O flow to get a balanced design solution.

2.6 Stage 6 - System Requirements Analysis & Verification Planning

Activity 6.1 - Analyze Requirements. In this stage, the system requirements derived in stages 3-5 should be analyzed for clarity, completeness, consistency, and traceability back to stakeholder/system requirements established at the end of the previous design cycle.

Activity 6.2 - Verification Planning. Identify verification objectives to be used to verify each system requirement. Each Verification Objective should identify the methods, facilities,

19

equipment, and resources needed to accomplish the verification activity. . The Verification Objectives are linked to the System Requirement being verified.

Activity 6.3 – Requirements Baseline. Establish requirement baselines at the end of each design cycle.

2.7 Stage 7 - Generate Documentation for System/System Element

Activity 7.1 - Deliverable Document Generation. o Standardize the look and feel of the project’s documentation using Cradle’s

Document Publisher o All documents that can be generated from the Data Repository should be generated

using Document Publisher, not hand crafted.

Activity 7.2 - Generate Data Packages. Data packages should be created from the data in the project repository in support of each Project Review. These packages should be generated from the Data Repository, not hand crafted.

2.7 Stage 8 – System V&V Traceability

Capture the status of each V&V activity in the database with traceability back to the impacted requirement and operational scenarios. The traceability identifies those requirements with links to design solutions that may need to be modified.

Activity 8.1 – Verification Traceability. The purpose of the Verification Process is to confirm that the specified design requirements (i.e., System Requirements) are fulfilled by the system.

Activity 8.2 – Validation Traceability. The purpose of the Validation Process is to provide objective evidence that the services provided by a system when in use comply with stakeholders’ requirements, achieving its intended use in its intended operational environment.

3 INCOSE Systems Engineering Handbook (v.3.2.2) Traceability

This Section contains a matrix that shows the traceability between the eight stages of the Requirements Definition and Management process described in this paper and technical process activities described in the INCOSE Systems Engineering Handbook (v.3.2.2). The handbook processes are consistent with ISO/IEC 15288:2008 Life-Cycle Processes and are identified in the following figure.

20

The process activities described in this paper can be traced to material in the INCOSE handbook in sections: 4.1, 4.2, 4.3, 4.6, and 4.8. The traceability is shown in the following table.

Section No

INCOSE Handbook Activity Description Cradle - 8 Stage Requirements Definition and Management Activities

4.1 Stakeholder Requirements Definition Process The purpose of this process is to define the requirements for a system that can provide the services needed by users and

other stakeholders in a defined environment. It identifies stakeholders, or stakeholder classes, involved with the system throughout its life cycle, and their needs, expectations, and desires. It analyzes and transforms these into a common set of stakeholder requirements that express the intended interaction the system will have with its operational environment and that are the reference against which each resulting operational service is validated

4.1.2.1 Identify Users and Stakeholders Activity 1.1 – Define Project Scope

4.1.2.2 Define Needs Activity 1.1 – Define Project Scope

4.1.2.3 Capture Source Requirements Activity 1.4 - Create Stakeholder Requirements

Activity 1.6 – Design Constraints

4.1.2.4 Initialize the Requirements Database Activity 1.5 – Plan System Validation

Activity 1.7 – Capture Glossary Items

(Chapter 4)

(Chapter 6)

(Chapter 7) (Chapter 5)

Organizational Project Enabling Processes

Enterprise Environment Management

Investment Management

ResourceManagement

QualityManagement

Acquisition

Supply

AGREEMENTPROCESSES

Enterprise Environment Management

Investment Management

ResourceManagement

QualityManagement

ManagementEnterprise Environment

Management

Investment ManagementInvestment

Management

ResourceManagementResource

Management

QualityManagement

QualityManagement

Risk Management Configuration Management

Information Management

Planning Assessment Control

Decision -making Risk Management Configuration Management

Information Management

Planning Assessment Control

Decision -making Risk Management Risk Management

Configuration Management

Configuration Management

Information Management Information

PlanningPlanning AssessmentAssessment ControlControl

Decision -makingDecision - Making

Disposal

MaintenanceOperation

ValidationTransitionVerification

Requirements Analysis

Architectural DesignStakeholder

Requirements Definition

Implementation Integration

DisposalDisposal

MaintenanceOperation MaintenanceMaintenanceOperationOperation

ValidationTransitionVerification ValidationValidationTransitionTransitionVerificationVerification


Architectural DesignStakeholder

Requirements Definition



Architectural DesignArchitecturalDesign

Stakeholder Requirements

Definition

Stakeholder Requirements

Definition

Implementation IntegrationImplementationImplementation IntegrationIntegration

TECHNICAL PROCESSES

PROJECT PROCESSES

Acquisition

Supply

System Life Cycle Processes

Management


Management


Management

Process Guidelines

4.1 4.2 4.3

4.4 4.5

4.6 4.7 4.8

4.9 4.10

4.11

21

Section No


4.1.2.5 Establish the Concept of Operations Activity 1.2 - Define Use Cases

Activity 1.3 – Develop Concept of Operations

4.1.2.6 Generate the System Requirements Document Activity 7.1 - Deliverable Document Generation

4.2 Requirements Analysis Process The purpose of the Requirements Analysis Process is to transform the stakeholder, requirement‐driven view of desired services into a technical view of a required product that could deliver those services. This process builds a representation of a future 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 characteristics it is to possess and with what magnitude in order to satisfy stakeholder requirements.

4.2.2.1 Requirements Analysis Concepts Activity 6.1 - Analyze Requirements

Activity 6.2 - Verification Planning

Activity 6.3 – Requirements Baseline

4.2.2.2 Characteristics of Good Requirements Activity 6.1 - Analyze Requirements

4.2.2.3 Define Systems Capabilities and Performance Objectives Activity 2.1 – Create Context Diagram

Activity 2.2 – Identify External Interfaces

4.2.2.4 Define, Derive, and Refine Functional/Performance Requirements

Activity 4.1 – Develop Functional Model for the Primary System Element

Activity 4.5 – Decompose Functions

Activity 4.6 – Establish Flow-Down of Functional Requirements & Linked to Functions

4.2.2.5 Define Other Non‐Functional Requirements Activity 3.2 – Define Non-Functional System Requirements

22

Section No


4.2.2.6 Develop Specification Trees and Specifications Activity 3.1 – Analyze System Element Source Information

Activity 3.2 – Identify External Interfaces

Activity 3.3 – Define Candidate Subordinate System Elements

4.2.2.7 Allocate Requirements and Establish Traceability Activity 4.2 – Create Functional Requirements and Link to Functions

Activity 4.3 – Establish Traceability to Source Requirements

4.2.2.8 Generate the System Specification Activity 7.1 - Deliverable Document Generation

4.3 Architectural Design Process The purpose of the Architectural Design Process is to synthesize a solution that satisfies system requirements. This process encapsulates and defines areas of solution expressed as a set of separate problems of manageable, conceptual and, ultimately, realizable proportions. It identifies and explores one or more implementation strategies at a level of detail consistent with the system’s technical and commercial requirements and risks. From this, an architectural design solution is defined in terms of the requirements for the set of system elements from which the system is configured. The specified design requirements resulting from this process are the basis for verifying the realized system and for devising an assembly and verification strategy.

4.3.2.1 Architectural Design Concepts Activity 5.1 – Allocate Functions to System Elements

Activity 5.2 – Define Physical Interfaces between System Elements

Activity 5.3 – Allocate Non-Functional Requirements to System Elements.

Activity 4.4 - Create and Link Interface Requirements to Data Definitions

4.6 Verification Process The purpose of the Verification Process is to confirm that the specified design requirements are fulfilled by the system. This process provides the information required to effect the remedial actions that correct non‐conformances in the realized system or the processes that act on it.

Activity 8.1 – System V&V Traceability

23

Section No


4.8 Validation Process The purpose of the Validation Process is to provide objective evidence that the services provided by a system when in use comply with stakeholders’ requirements, achieving its intended use in its intended operational environment. This process performs a comparative assessment and confirms that the stakeholders’ requirements are correctly defined. Where variances are identified, these are recorded and guide corrective actions. System validation is ratified by stakeholders.

Activity 8.1 – System V&V Traceability

requirements definition and management using cradle · hardware configuration items (hwci),...

Documents