Requirements Analysis Process in the Norwegian Submarine Projects

Transcription

1 Requirements Analysis Process in the Norwegian Submarine Projects Terje Fossnes, ESEP Chief Engineer; Naval Systems, Submarines Gdynia,

2 Principle phases of a submarine project

3 Submarine / System Acquisition Process; The Vee-model Validation Stakeholder Requirements (KD) System Requirements Specification(s) Lower-level Systems Specifications Detailed Design Documentation and Detailed Interface Specifications Validation (OPEVAL) Verification of System Requirements Components Specifications Drawings & Parts Armed Forces & Submarine Flotilla System Acquisition Project Team System Acquisition Project Team Submarine / System Contractor(s) Parts Manufacturing & Supply Identification Information Submarine Build & Equipment and Parts Supply OPEVAL and In-Service Operational Use Submarine Into Service Acceptance Sea Trials Whole Boat Build Acceptance ; based on Harbour and Sea Trials Major Systems Pre-Installation Verification Major Systems Verification, Integration, and Setting to Work Lower-level Systems Integration, and Setting to Work Equipment Assembly, Installation and Inspections Integration & Verification

4 Stakeholder Needs & Requirements Definition Process Purpose: to create the operational requirements for a system that can provide the services needed by users and other stakeholders in a defined environment.

5 Stakeholder Needs & Requirements Definition Process; Structure Level 1 Higher enabling objective Level 2 Enabling objective Enabling objective... Level 3 Supporting objective Supporting objective... Level 4 Operational requirement Operational requirement... Level 5 Supporting operational requirement Supporting operational requirement

6 System Requirements Definition Process Purpose: to transform the Stakeholder Needs & Requirements into System Requirements that: Build a representation of a future system that will meet stakeholder requirements Do not imply any specific implementation Identify what characteristics the system is to possess and how well the performance shall be

7 from Stakeholder Requirements to System Requirements The focus of the analysis is to: a) Identify and clarify the functions and/or capabilities b) Define the performance of the needed functions c) Outline the time- and event-based relationships of the functions d) Identify any constraints on the functionality or the architecture The template System Requirements Specification is based on DI-IPSC-81431A System/Subsystem Specification (SSS) i.a.w. MIL-STD-461.

8 Requirements Analysis Process; MOTS versus Bespoke Design Tailored MOTS Requirements Enhanced MOTS Requirements Major Change No Tailoring Pure MOTs Minor Change Increasing Design Tailoring Bespoke Design Fully tailored specification & design Smart Buyer Designer Smart Specifier Consequential design change, Cost & Risk Profile

9 <Requirement Number> <Requirement Name> Requirement: Verification Method: System Requirements Definition Process; Structure of a Requirement The requirement text; containing: The agent shall or should what, how well, under which conditions. The sole selected verification method from the established pool. Establishes the method for the verification activity of this requirement. Verification Class: Verification Requirement: Acceptance Criterion: The sole selected verification class from the established pool. Establishes the milestone (time) when the purchaser will verify the requirement, or when to evaluate or assess the result of a formerly performed verification activity. The verification requirement text contains key information about potential prerequisites, how and under which condition(s) the purchaser will verify that the requirement is fulfilled. Text describing the purchaser s condition for the contractor s successful fulfilment of the requirement text based on the correct performance of, or results from, the verification requirement when verified according to the verification method.

10 Additions in the Request for Offer (RFO) Requirement Category: Evaluation Weight: A (for shall requirements) or B (for should requirements) 1 to 3 (for shall requirements), 10 to 4 (for should requirements) Evaluation weight: The weight of the requirement indicates both 1. how the successful candidate shall describe his fulfilment of the requirement in the offer, as well as 2. how important the project considers the requirement to be as part of a potential contract. (E.g., A1 requires less documentation than A3; B10 is prioritized higher than B4.)

11 Hidden attributes of generating a good Requirement Why is this Requirement necessary? Risk faced by NOT requiring this? Why this specific performance? (Why not more / less?) Consistent with System s Objectives and Users Needs An Appropriate and Necessary Requirement Singular Specific Complete Not in conflict with other requirements Precisely defined Unambiguous Can be fulfilled within affordable cost and time Verifiable within affordable cost and time

12 and An Appropriate and Necessary Requirement Verification Method (principally how) Verification Class (when [milestone] to verify) a good Requirement is supplemented with information about how to verify its fulfillment Verification Requirement (in what specific manner to verify) Acceptance Criterion (what has to be met)

13 Verification Methods Choose the most cost-effective mix of simulations, physical and analytic approaches. Avoid unnecessary redundancy in the verification activities. Only the following verification methods and only one of them shall be identified for each requirement. Analysis (of calculations or simulations) Certification (i.a.w. regulations) Demonstration (of a given conclusion) Inspection (of attributes or documentation) Sampling (select a few from many) Similarity (of analogous elements or systems) Test (to obtain quantitative data)

14 Verification Classes Choose the optimal time (milestone) for assessing if the requirement is fulfilled; and In which environment the verification is best performed. The formal verification is performed as early as possible. Only the verification classes below and only one of them shall be identified for each requirement. Factory Acceptance Test (FAT) Qualification Acceptance Test (QAT) Harbour Acceptance Test (HAT) Sea Acceptance Test (SAT) Performance Acceptance Test (PAT) Site Acceptance Test (SiAT)

15 Verification Requirement Contains relevant verification actions to be performed; and Under which conditions; Tools needed (e.g.: test bench, simulator, launcher, special devices); The configuration of the system under verification. This helps ascertain that the requirement is verifiable. Historically the most usual causes for a requirement not to be verifiable are: 1. No clear specification of correct functional behaviour, conditions and states. 2. Lack of precision in the ranges of acceptable quantities. 3. Use of ambiguous terms.

16 Acceptance Criterion The acceptance criterion relates to the requirement text, when The verification method and class are applied; and The description in the verification requirement is followed. Requirements have their own unique properties that will influence the way the acceptance criterion is formulated: Functional: behaviour related acceptance criterion; Performance and non-functional: quantified with tolerances or limits. The obtained result is recorded as either compliant or non-compliant.

17 Evaluation of responses During the evaluation of the candidates responses to the requirements in the RFO, the following aspects will be assessed by the project team: Compliance to the requirement and the evaluation weight. Based on the candidate s statement of compliance (i.e. fully compliant, partly compliant, or non-compliant), and how the subject matter experts in the project team understand the candidate s supporting description of how and/or why compliance is met. Confidence in the description of the intended / proposed solution as stated in the offer.

18 Requirements Management

19 from a designer s perspective

20 Thank you!