System Design Definition

Home
Members
Schedule
Archive
Search
Discussions
Contact Information
Members data area

System Design Definition

Produced during the Definition Phase of a project System Design Definition (SDDs) define the system design for the Project’s entire scope of supply and references other SDDs where necessary.

Purpose

To define the overall architecture, type, scope and number of systems that will be developed, procured and/or modified to implement the Project.  This may include systems that are developed, modified or procured outside of the scope of the Project.

To define the solution in sufficient detail to plan the Implementation Phase.

The System Design Definitions (SDDs) are to define the delivered systems, sub-systems and equipments to be able to answer the following questions at each design review:

·       Does the system meet the requirements,

·       Can the system be implemented?

·       Is it Safe both Air Traffic Safety and personal Health and Safety?

·       Can the System be maintained and operated?

·       Is the Implementation, planned, resourced and costed?

Derivation and Source Requirements

The source documentation are the Cardinal Point Specification, Tender Responses, the SDD produced by the previous phase design / definition documentation for current and planned systems.

The system architecture is to consider and support the schedule, costs and performance constraints defined by the Cardinal Point Specification.

To develop and agree the System Design Specification the following aspects must be considered:

·       Safety Requirements,

·       System’s scope,

·       The Concept of Operations,

·       The User’s requirements,

·       Method used to develop, integrate and transition the system,

·       Constraints on time, money, quality and resource,

·       Corporate or industry standards and best practice,

·       Security constraints including constraints that may impact the long term use and deployment of the product,

·       In-service support and maintenance – Integrated Logistics Support,

·       Range of options for providing each sub-system/equipment,

·       Corporate strategies or statements of direction that may impact on the delivered system(s),

·       Industry initiatives,

·       Provision of solutions including any specialist skills that are required to develop or deploy these solutions,

·       Methods for installation, integration and transition,

·       Training needs for effected personnel.

Composition

The exact composition of the Design Definition will depend on the results.

The System Design Definition must define the overall architecture of the entire end to end facility including any interfaces to systems or equipments outside the scope of the Project.

A breakdown of the main sub-systems and equipments that as a minimum defines their:

·       A brief description,

·       Scope

·       Sizing (including number and type of sub-systems, equipments, connections, etc),

·       Scope of the requirements that the sub-system / equipment addresses (including traceability to the Cardinal Point Specification)

·       List of all interfaces (including references to Interface Control Documents),

·       Estimated safety category,

·       Performance requirements,

·       ARM requirements,

·       Location (which site and or centre)

·       Integrated Logistics Support (ILS) considerations,

·       Training Requirements,

·       Implementation and rollout,

·       System Integration, Verification and Validation.

Clear and unambiguous architecture and interdependencies between each sub-system / equipment including an overall architecture diagram.

For each sub-system a proposal for the approach to be taken, for example: bought – COTS, bought – minimum development, bought – bespoke, developed in house, contracted to third parties, based on an existing system, built from scratch and based on any specific technologies.

Criteria and justification for the key design decisions taken to develop the proposed solution.

Any constraints on the solution and/or any sub-systems/equipments.

All the Risks that may have an impact on the proposed solution including where possible the proposal’s for sensitivity to these assumptions.

All assumptions made to develop and validate the proposed architecture including where possible the proposal’s sensitivity to these assumptions.

Advantages and disadvantages for the proposed architecture.

Quality Criteria

Are all the systems and changes to existing systems necessary to implement the Project clearly and unambiguously identified?

Is the System Definition credible and viable?

Is the design achievable within the Projects constraints?

Does the proposed architecture support the:

·       Safety Requirements?

·       Cardinal Point Specifications?

·       User’s requirements?

·       policies and procedures?

Does the approach used to develop and deploy the system (sub-system/equipment) support the costs and schedule constraints?

Has an approach been selected that maximises the chance of achieving overall success for the Project?

Does the design align and support with the Tender Responses?

Is their clear and unambiguous traceability between the SDD and the Tender Responses?

Does the SDD provide sufficient information for the Critical Design Review as defined by the purpose, above?

Has the operational and support requirements/issues been addressed to ensure that the benefits have the greatest chance of being realised?

Are there any risks that are critical to the solution’s success?

Are their any opportunities missed or not considered?

Is there a need to bring in specialist skills and resources and if so has any impact being considered and mitigated?

Quality Method and Skills

The senior engineers working on the Project will develop the System Design Definition. The Project Manager and Team Leaders will review it.

The System Design Definition will be subject to a solution review as part of the Phase Review Process.

Home | Members | Schedule | Archive | Search | Discussions | Contact Information | Members data area

 (c) Safeflight.co.uk
Last updated: 07-08-2005.