Systems Engineering Processes in Conceptual Design Phase

SENG 5130 SYSTEMS ENGINEERING PROCESSES MODULE 3

MODULE 3 Conceptual Design Phase

Objectives of this Module Concept design Preliminary system design Detail design and development Production and/or construction System operation and support Retirement and phase-out

Conceptual Design

Conceptual Design Most critical System Definition Statement of Need (1 sentence) Functional Architecture (hundreds of pages) Purpose To articulate need To analyze and document system-level requirements from the need To complete a functional design of system

Conceptual Design Domain of customer Functional design Responsibility of the customer What does the system need to do? How well?

Conceptual Design 1. Identification of stakeholder requirements 2. Feasibility analysis 3. Requirements analysis 4. System-level synthesis 5. System design review Preliminary Design Adapted from Faulconbridge and Ryan (2003).

1. Identification of Stakeholder Requirements Clearly understood and articulated Common sense? Most systems are developed without complete understanding of fundamental requirements Poor levels of user acceptance

Who are the system-level Stakeholders? The customer The users The system input providers The system output receivers The approvers The nay-say ers The reviewers, evaluators and auditors Not only local people, but governments, their agencies, organizations, markets, communities, informal networks Direct and indirect Change over time

Identification of Stakeholder Requirements Stakeholder-Requirements Document Identify Stakeholders Identify Project and Enterprise Constraints Identify External Constraints Define Need, Goals and Objectives Define Operational Scenarios Define Measures of Effectiveness Define Life-Cycle Concepts Confirm SRD Structure Scoping the System Populate SRD SRD Endorsement Traceability 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

1. Stakeholder-Requirements Document aka Operational Concept Document/Description Concept of Operations Document System Design Document User Requirements Document User Requirements All stakeholders must be involved in preparation Applications or missions Major operational characteristics Operational constraints External systems and interfaces Operational and support environment Support system

Stakeholder-Requirements Document SRD Audience: Eventual users Operators, support personnel to systems engineers & designers Test personnel Each audience provides different views Systems engineers: Translate user requirements into formal requirement statements

2. Identify Stakeholders List potential stakeholders Are there groups/clusters? Who are key stakeholders, why? Objectives/goals of each stakeholder Influence/Importance Matrix Influence: Power over a project/area to control what decisions are made, persuade others, etc. Importance: Priority to satisfy stakeholders needs. Some may have greater priority, but little influence.

Influence/Importance Matrix SH1 SH5 SH6 SH7 SH2 SH4 SH8 SH3

Conflict Analysis Matrix

Ex: Aircraft Development A large aircraft operator (ACME Air) has identified a need for a medium-sized aircraft to replace the aging platform that it currently operates over domestic routes and some short international routes. The company wants to use a systems engineering approach to ensure that the aircraft system produced is ideally suited to the role and to ensure the overall commercial viability of the project. The aircraft is to be capable from operating from any Class X airport in the world. The aircraft is to provide class-leading comfort for passengers. The aircraft is to be capable of being turned around to its next flight within 30 minutes.

2. Identify Stakeholders Ex: Aircraft System Business owners of airline Commercial requirements: fuel efficiency, passenger and freight capacity, etc. Users Air and ground crew Functional and performance requirements Marketing Make the aircraft marketable to passengers Maintainers Maintainable within time and cost constraints Accessibility, reliability, maintainability, logistics, supportability, etc.

3. Identify Project and Enterprise Constraints Provides information about the development environment for the system Begins top-down approach to system development Enterprise Constraints: Organizational policies, procedures, standards, guidelines Partnering relationships with other companies, contracting policies (e.g., aircraft operator may only buy engines from a particular manufacturer) Project Constraints: Resource allocations Quality Assurance Project progress report Metrics, tools and documentation procedures

4. Identify External Constraints Conformance to national and international laws and regulations Compliance with industry wide standards Ethical and legal considerations Requirement for interoperability

5. Define Need, Goals and Objectives The Need Statement Concise Aircraft Example: to acquire a medium-sized aircraft that can provide class-leading comfort to passengers between Class X airfields on domestic and international routes. Expand into goals and objectives Class-leading? Medium-sized? # of passengers?

6. Define Operational Scenarios Proposed by stakeholders for the system Analyze range of operational scenarios (use case) Description of general operational environment Specific operational scenarios Have to represent all stakeholder perspectives Ex: Turning an aircraft around: Air crew and ground crew Modes of operation Fighter aircraft: air-to-air combat, ground attack, naval operations, nontactical flights, etc. Aircraft: international/domestic, taxi, take-off, cruise, etc.

7. Define Measures of Effectiveness (MOE) A metric by which the customer will measure satisfaction with products of the acquisition phase Performance in each operational scenario Safety Reliability Supportability Maintainability Ease of use Time and cost to train MOEs are supported by measures of performance

8. Define Life-Cycle Concepts Guidance from stakeholders Development Production Testing Distribution Operation Support Training Disposal Systems Engineering ensures focus on life-cycle Stakeholders ensure focus on major cost drivers that impact supportability of system Trade-offs

9. Confirm SRD Structure Stakeholders agree on structure and content of SRD References are present for guidance on process, content and layout of documentation

10. Scoping the System Clear understanding of: Design constraints State-of-the-art of relevant technologies Extant methodologies and tools External interfaces E.g. air traffic control regulations System boundaries What to include/exclude in the system Context Diagram

Scoping the System Context Diagram Competing Aircraft (C) Passengers (C) Aircraft Operator (S) Aircraft manufacturers (C) Aircraft System Third party manufacturers Engines Avionics Tires Navigation Systems Communications (C) Airports (I/C) Docking Refueling Landing Systems Navigation Systems Runways Regulators (C) Noise Emissions Operating Environment (C/I) Adapted from Faulconbridge and Ryan (2003).

11. Populate SRD Even though large number of stakeholders, best for SRD is small team of customer representatives. All stakeholders should be involved Structured workshops Surveys Interviews To ensure all information is considered

12. SRD Endorsement System specification cannot be developed until SRD is complete and endorsed If incomplete inputs, then inadequate analysis and synthesis Involves key stakeholders Individual review and sign-off

13. Traceability Each requirement in SRD should be traced to at least one requirement in system specification Forward traceability Confidence for customers From system specification back to SRD Backward traceability Makes sure no creep in requirements

Class Exercise: Step 1: Identification of Stakeholder Requirements SYSTEMS: 1. Online Library for a University 2. Internet-based Travel Web Site 3. Multi-story Parking Garage 4. Hospital for a Small Community 5. Two-way Traffic System Across a River Who are the major stakeholders? Influence/Importance Matrix Conflict Analysis Matrix

Conceptual Design 1. Identification of stakeholder requirements 2. Feasibility analysis 3. Requirements analysis 4. System-level synthesis 5. System design review Preliminary Design

2. System-Feasibility Analysis Feasible System-level alternatives developed Available resources Steps: Identify possible solutions capable of satisfying need Confirm that requirements in SRD are achievable If not, likely level of achievement Evaluate potential solutions in terms of: Feasibility, performance, effectiveness, technical and project risk, etc. Recommend best possible solution Reliability and maintainability have high priority

System-Feasibility Analysis Example: Developing the Aircraft System To service the short-to-medium domestic and international routes, but no airframe to do it. Alternatives are: Leasing or buying an existing aircraft Leasing or buying and modify an existing aircraft Contracting to have a new aircraft developed Outsourcing the operation to another airline Not servicing these medium routes

Conceptual Design 1. Identification of stakeholder requirements 2. Feasibility analysis 3. Requirements analysis 4. System-level synthesis 5. System design review Preliminary Design

3. System-Requirements Analysis (What, not how) 1. Establish Requirements Framework 2. Define Functional Requirements 3. Define Performance Requirements 4. Define Verification Requirements 5. Assign Rationale 6. Perform Functional Analysis 7. Produce Draft System Specification 8. Define TPMs 9. System-Requirements Reviews 10.Other System-Level Considerations

1. Establish Requirements Framework Requirements Breakdown Structure (RBS) Different from the Work Breakdown Structure Grouped by function Provides reference and guide during development of system functional baseline

RBS for Aircraft System Faulconbridge and Ryan (2003).

2. Define Functional Requirements Identify all functions that are necessary to maintain or return the system to operational use. Focus is still on what needs to be done, not how Functional-Flow Block Diagrams (FFBD)

FFBD Example: Examples?

Define Functional Requirements Faulconbridge and Ryan (2003).

3. Define Performance Requirements How well the system is to perform each of the functional requirements For each functional requirement, a performance statement Environmental: temperature range, humidity tolerance, etc. Quality: availability requirements, reliability limits, manufacturing tolerances Support requirements: storage capacity, personnel establishment, training goals, etc. Utilization: Duty cycles, hrs of operation/day, operational days/yr

4. Define Verification Requirements For every functional requirement, a corresponding verification statement. How will the function be tested? Test plans become easier to write

5. Assign Rationale Why each requirement is necessary Logic behind each performance measure

6. Perform Functional Analysis and Allocation Analyze and allocate the functions Aim is to make sure the elements of a system-level functional architecture have sufficient depth to allow for solutions

Perform Functional Analysis and Allocation Faulconbridge and Ryan (2003).

7. Produce draft system specification RBS forms the basis for the draft system specification. The requirements are collected and analyzed Not yet synthesized into a solution

8. Define technical performance measures (TPMs) Quantitative criteria that describe system performance Reliability, Weight, Response time, Accuracy, Speed, etc. Developed early, monitored throughout system development to managing risk Identify quantitative parameter Prioritize (as viewed by customer) A 2nd list, prioritized by contractor Priority will assist in design emphasis Some TPMs move down, some move up Upper tolerance, Lower tolerance limits

8. Define technical performance measures (TPMs) TPM Characteristics: Should be relevant Should be easy to measure Performance should improve with time Measured parameter should be controllable Should be documented Should be customized for the project

8. Define technical performance measures (TPMs) Kossiakoff, Sweet, Seymour and Biemer (2011)

9. System requirements review (SRR) Conducted periodically throughout conceptual design Number of reviews depend on complexity and size of system