System Enginnering - Architecture

Systems Engineering provides Architects with great supporting processes, these include Requirements Management, Research and Design, Planning and Realization. The focus of Systems engineering is to ensure all processes in the life-cycle focus on producing the right product. This is more complex than it may initially appear, when the environment serves:

• multiple users/customers.
• users/customer that are unable to define what solution they want procure.
• users/customer that are unaware of what solutions it might be possible to procure.
• engineers that may have limited or no direct contact with the users/customers or indeed if the user or customer is not directly involved in the process.

System Engineering is a proven method for producing the right product, it is used for projects of individual and multiple-disciplines, different industrial sectors (telecoms to aerospace) and end products (telephones to battleships). System Engineering produces the right product by focussing on the underlying need, developing a solution that comprises components, potentially from different disciplines, and tracing all project activities back to the source requirements.
Requirements Management

Systems engineering requires that System requirements are developed as a separate engineering product from the user/product requirements.

User requirements are:

• Requirements expressed in the user's language.
• Immediately understood by the user with out translation to the system domain vocabulary.
• Duplication is acceptable, where it recognises that different stakeholders hold the same need.
• The user (or user representative) owns these requirements.

Product requirements are a substitute for User requirements, where a product is being developed for a market/user that does not participate in the development process, i.e. for COTS products the development needs are championed by a Marketing manager or Product development manager who would specify the Product requirements.

The User requirements product (URD) should consist of:

1. System Context
2. Capabilities needed
3. Constraints to be enforced
4. User characteristics
5. Operational environment
6. Assumptions and dependencies

System requirements are:

• An abstract view of the system, describing system functions. What the system will do, not how it will do it.
• An analysis and restatement of the real or underlying need, which is not tied to describing a design or solution.
• Traced directly to User requirements where 1 User requirement might be addressed by 1 or more System requirements.
• Highlight to users that their needs are reflected throughout the development process.
• Enable system requirements to be shared across engineering disciplines (Hardware/Software/HCI/Security/Safety/etc,...).
• Enable capabilities to be developed which can be re-used.
• Promote testing.
• Separation of User and System requirements enable management of change and impact assessments to be performed.

The System Requirements product is typically broken into multiple products on larger project, but consists of:

1. System context.
2. Functional breakdown of behaviour.
3. Performance of each function.
4. Internal interfaces.
5. Non-Functional Requirements (Safety Case, Security Requirement, HCI).
6. External interfaces (Interface Control Documents).
7. Traceability to the user requirements.

Systems level modelling can be performed using a variety of supporting techniques, DFD, State Charts, UML, Functional Hierarchies etc,.. The criteria for completing the functional model is suggested to be:

1. The function model shows how the user requirements are met (Sunny day use cases).
2. The functional model shows faults will be managed at its limits (Rain day use cases).
3. The functional model shows how the system will perform outside of normal tolerances.
4. The functional model describes how system failure.

A useful example for an emergency service Command and Control centre process is:

1. Call logging under normal conditions.
2. Call logging for a major incident, where external requests match the available resources to meet all needs.
3. Call logging for a catastrophic incident, where external requests exceed the available resources to meet all needs.
4. Call logging when the system fails and DR plans are invoked.

When all these 4 levels are considered, then the functional models behaviour has probably been expressed to a sufficient level of detail.

Architectural Research & Design

The Architectural Research and Design process consists of the following activities:

• The selection of technologies, services and components that comprise the solution.
• How each component of the solution interacts with other components and the external environment.
• A design that considers alternative solutions and selects the best fit and trade off against source requirements.
• Identify margins and System performance criteria, possibly exceeding user requirements.
  
• A requirements trace, which System and User requirement the solution satisfies.
• A design that selects solutions that can be sourced via development or procurement within schedule and budget constraints.

A number of iterations of Architectural Design may be produced in order to maximise the value to the customer, as alternate trade off's are reviewed and refined.



The Architecture Design document product consists of:

1. Overview
2. Context
3. External Systems Interfaces
   
4. Design Methods/Approaches/Patterns of Re-use
   
5. System Behaviour - The operations and interfaces exposed by the system.
6. Component Structure - The components of the system and the internal interfaces.
   
7. System Layout - The physical arrangement of component instances on Processors/Servers/Sites.
   
8. Resource/Cost Estimation.
9. Requirements Trace.

A Component Requirements Catalogue supporting the Architectural Design should detail:

1. Component Identifier.
2. Type: COTS/MOTS/Bespoke.
3. Source: Supplier.
4. Component Behaviour and Control.
5. Interfaces.
6. Layout.
7. Dependencies.
8. Information model.
9. Performance criteria.
   
10. Test Criteria.

The exact nature of the component will necessitate different requirements for Software or Hardware components.

As single component may be re-used within a single architecture or multiple architectures, the requirements for the component should be carefully analysed to identify contradictory modes of operation.

Architectural Planning

Evaluate an architectural design to ensure it optimises the benefits to the 'customer'.

The feasibility, risk and budget need to be assessed prior commissioning component development or procurement. To support this analysis the Architectural design needs to be broken down as a programme of work in a work breakdown structure and costs estimating.

The Architectural planning is joint activity to be conducted with Programme\Project Management, enabling professional staff to manage resourcing, planning, risk and change control management activities.

Value engineering is the process steering the Architectural design activity to provide the right solution. Quality Function Deployment is a tool for providing a structured process to blend requirements for multi-aspect products/systems.

Architectural planning can enable Concurrent engineering to reduce the critical path of the project, however the Concurrent engineering can increase the complexity and risk associated with delivering a project.

Component Development/Procurement

Component development addresses the stage of purchasing or commissioning work from component suppliers.

Architecture Realization

An Integration test strategy produced for Integration, Test and Verification should indicate the the Verification level and methods for critical components. An integration strategy will also produce requirements for the Integration, Test and Verification processes for the delivering the system.

Verification levels for each requirement:

• System
• Sub-system
• Component

Verification Methods:

• Functional Testing - Check behaviour, interface or performance requirements.
• Environmental Testing - Heat/Cold/Humidity/Altitude/Gravity/Etc,..
• Analysis - Simulation
• Comparison - Re-use of components already verified.
• Assessment - Inspection, Demonstration or Review