Analysis
RA/ Requirements 1/9180
Requirements Analysis
Defines: s What the system is to do. s Environment in which the system will exist. s Objectives the system must satisfy. s Desired system requirements and constraints. Does not specify the solution. Freedom of choice must remain with the design teams (IPTs).
RA/ 2/9180
Input Concept
MNS Customer Req'ts
Req'ts Analysis System Level Technical Req'ts System Level Technical Req'ts
Functional Analysis & Allocation (Funct Arch)
SE "Big Picture"
Synthesis (Design Arch)
Output (Specs) Draft System Spec System Spec
WBS (System Arch) Draft Program WBS
Baseline
Review/ (Phase) ASR (CE)
System
ORD#1
Customer Req'ts change? Draft System Spec Design Arch Mgt Decisions from Tech Reviews
Functional
Program WBS Draft Contract WBS Program WBS Contract WBS
SDR (PD&RR)
Draft Performance Specs
Sub-System
ORD#2 Customer Req'ts change? System Spec Draft Perform. Specs Mgt Decisions from Tech Reviews at CI level
System Level Technical Req'ts
+
+
System Spec Performance Specs Draft Detail Specs
Allocated
PDR/CDR FCA (EMD)
Component
ORD#3 Customer Req'ts Change? System Spec Performance Specs Draft Detail Specs Mgt Decisions
System Level Technical Req'ts
+ +
Draft Extensions Program System, WBS Performance & Detail Contract Specs WBS (TDP) Extensions
Product
PCA (EMD/ PF/D&OS)
RA/ 3/9180
Systems Engineering Process Inputs
s
Customer needs/objectives/requirements
Missions Measures of Effectiveness Environments Constraints (e.g. cost, schedule) Domain Technical Architecture
s s s s
Technology Base. Output requirements from prior application of SEP. Program decision requirements. Requirements applied through specifications & standards.
RA/ 4/9180
Requirements Analysis
s
Develop System Functional & Performance Requirements
Define:
What System Must Do How Well It Must Do It Utilization Environment Design Constraints
P R O C E S S I N P U T
s
Performance Requirements Define:
Quantity - How many Quality - How Good Coverage - How Far Time Lines - When
Availability - How Often
Requirements Analysis Requirements Loop Functional Analysis/ Allocation
System Analysis and Control (Balance)
Verification
Design Loop Synthesis
s
Design Constraints Define:
Environmental Conditions or Limits Defense Against Internal or External Threats Contract, Customer or Regulatory Standards
PROCESS OUTPUT
s
Technical Architectural Analysis
Characterize baseline requirements in interface terms Identify interfaces that are critical to meeting performance and business needs
RA/ 5/9180
Requirements Analysis
In conducting Requirements Analysis, the performing activity:
assists in refining customer objectives and requirements defines initial performance objectives and refines them into requirements identifies and defines constraints that limit solutions (e.g. missions/operations, utilization environments or adverse impacts on natural and human environments, external interfaces) and defines functional and performance requirements based on customer provided measures of performance
The IPT provides the life cycle process's requirements/needs and performs these requirements analysis activities.
IEEE 1220-1998
RA/ 6/9180
Types of Requirements / 1
s
Customer Requirements
Statement of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and MOEs.
s
Functional Requirements
The necessary task, action or activity that must be accomplished.
s
Performance Requirements
The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness.
s
Design Requirements
The "build-to," "code to," and "buy to" requirements for products and "how to execute" requirements for processes expressed in technical data packages & technical manuals.
RA/ 7/9180
Types of Requirements / 2
s
Derived
Transformed from higher level requirement. Example: low fuel use requirement drives toward low weight requirement.
s
Allocated
A proportional or divided requirement from higher level requirement. Example: 100 # system with two subsystems or 70 # and 30 # respectively.
s
s
s
Quantitative Measured by numbers. Qualitative Measured by yes or no, or on and off, etc. Cost
RA/ 8/9180
Development of operational requirements
s
Requirements - Example / 1
s
s
s
s
s
s
Operational distribution or deployment: Where will the system be utilized? Mission profile or scenario: What must the system do to accomplish its objective? Performance and related parameters: What are the critical system parameters to accomplish mission? Utilization environments: What are the different environments that the various system components will be utilized in? Effectiveness requirements: Given what the system will perform, what level of effectiveness or efficiency must it operate at? Operational Life Cycle: What does the user anticipate will be the useful life for this system? Environment: What environment will the system be expected to operate in an effective manner?
RA/ 9/9180
Requirements - Example / 2
Development of supportability requirements:
s s s s s s s
s
Determine level of Openness (e.g. LRU/SRU) Levels of Maintenance determined Establishment of Repair policies Organizational responsibilities established Support criteria established Effectiveness requirements associated with support capability Defining the environment within maintenance and support activities and related transportation, handling, and storage functions Interfaces which support technology insertion
User's requirements and operational environment establish a basis for supportability requirements in system design
RA/ 10/9180
Balancing Business and Performance Goals
s
s
s
Emphasize balance of business goals (e.g., costs, common use, supportability) with technical goals (e.g., functionality, performance, interfaces). Consider cost-performance tradeoffs vs. achieving largest possible reductions in life-cycle costs. Re-evaluate stringency of requirements to consider using open standards for interfaces as performance requirements are balanced (weighed) against business requirements.
RA/ 11/9180
s
s
s
s s s
Measurable/Verifiable Not defined by words such as excessive, sufficient, resistant, etc. Unambiguous One possible meaning. Complete Contains all mission profiles, operational and maintenance concepts, utilization environments and constraints. The "why" and "what" of the need, not how to do it. Consistent with other requirements. Proper for the level of system hierarchy.
Attributes of a Well-Defined Requirement
RA/ 12/9180
Requirements Analysis Role
Problem
(Customer)
(Government Developer & Contractor)
Requirements Analyses
(WHY)
Specifications
(Contractor)
(WHAT)
(HOW)
(Contractor)
Designs
RA/ 13/9180
Background General Comments
s s
s
s
s
s
The customer / users have expertise in their product application field. The developers (government & contractor) are not necessarily competent in the operational field of the need. Typically, the need is neither clearly nor completely expressed so as to be directly usable by developers. It is unlikely that developers will be presented with a well defined problem from which they can develop the system specification. Thus, a large amount of effort is necessary to understand the problem and to analyze the need. It is imperative that customers be part of the definition team (IPT).
RA/ 14/9180
Requirements Analysis - Risk Areas
s
s
s
s
It is often easier for the customer to describe a system which solves a problem rather than to describe the problem itself. The customer may believe that a document describing only characteristics of the problem to be solved makes the developer's work more complicated. Often, because of the customer's lack of developer's knowledge, general specs are imposed to channel development efforts. The various customer mission objectives, functions, MOEs and constraints will conflict.
Trade studies will be needed to balance the requirements set with respect to cost, schedule, performance and risk.
s
Changing requirements
RA/ 15/9180
Outputs Three Views
s
Controls
Operational
How system will serve its users. Key to establishing HOW WELL and UNDER WHAT CONDITION requirements.
Inputs Transformed into Outputs Requirements Analysis Outputs
s
Functional
Enablers
Focuses on WHAT system must do to produce required operational behavior. Shows required inputs, outputs, states and transformation rules.
s
Design
Focuses on how the system is constructed. Key to establishing the physical interfaces among operators and equipment, and technology requirements.
RA/ 16/9180
Operational View Information
Documented in an Operational Concept Document:
Operational need definition. System operational analyses. Operational sequences / scenarios. Conditions / events to which system should respond. Operational constraints, including MOEs. Identified human roles.
Define by job tasks and skill requirements/constraints
Training requirements. Identification of operations required to ensure safety. Life cycle process concepts.
Include MOEs / MOPs / existing products/services
Operational interfaces with other systems.
RA/ 17/9180
Functional View Information
Documented in a Decision Data Base: Functional Requirements.
What system products/life cycle processes must do/accomplish.
Functional sequences for accomplishing system objectives. TPM criteria. Functional interface requirements.
External, higher-level, or interacting systems, platforms, humans, products.
Functional capabilities for planned evolutionary growth. Performance Requirements.
Qualitative - how well. Quantitative - how much, capacity. Timeliness or periodicity - how often.
RA/ 18/9180
Design View Information
Documented in a Decision Data Base:
Previously approved specifications / baselines. Interfaces with other systems, platforms, humans, products. Human systems engineering elements.
Safety, training, knowledge, skills, abilities. Characteristics of information displays / operator controls.
Characterization of operator & support personnel. Characterization of information displays & operator controls. System characteristics
Design, technology, & inherent human limitations. Standardized end items / NDI / reusability requirements.
Design constraints - project / enterprise / external Design capabilities & capacities for planned evolutionary growth
RA/ 19/9180
Software Growth in Aviation Systems
CUMULATIVE MILLION LOC OPERATIONAL SOFTWARE
VERY HIGH SPEED INTEGRATED CIRCUITS PROCESSORS 2ND GEN FLIGHT CONTROL INTEGRATION SENSOR / WPN FLIGHT CONTROL INTEGRATION
Light Helicopter 1 M LOC
1M
LONG-BOW APACHE (AH-64 MSIP) 150K LOC APACHE (AH-64) 116K LOC COBRA (AH-1) 10K LOC
SOA 154K LOC WIDE FOV
HELMETMOUNTED DISPLAY
.1M
.01M
AHIP (CH-58D) 50K LOC
COMANCHE INTEGRATED SIGNATURE RAH66
INTEGRATED AIRCRAFT SURVIVABILITY EQUIPMENT COCKPIT
FLY-BY-WIRE LIGHT FLIGHT CONTROLS
REDUCTION
1970s 1980s 1990s
RA/ 20/9180
Software Requirement Categories
s s s s s s s s s
Interfaces Performance Human Systems Integration Safety Failure Detection Self Test Environment Data Base Computer Resources
RA/ Requirement 21/9180
Software Goals
s s s s s s s s
Complete - covers all areas Understandable - not open to interpretation Partitioned - useful work break down structure Maintainable - can be re-written Communicable - everyone can agree Usable - designers understand what is to be done Definitive - thoroughly answers `what' to do Abstract - shows what, not how
RA/ 22/9180
Software Requirement Errors
s
Requirements errors are the most numerous, occurring about 2 to 1 over coding errors Requirements errors are most likely to squeak by tests, and so some 2/3 of requirements errors might go undetected without QA In a recent survey, 40% of the organizations stopped testing at the deadline whether or not they had performed all of their metrics
RA/ 23/9180
s
s
Software Life Cycle Considerations
Software development Requirements Analysis Design Code & Unit Test Integration & Test Validation & Documentation Operations & Maintenance Dev $ 5% 25% 10% 50% 10% 5% 22% 10-100 10% 50% 1.5-5.0 Errors Introduced 55% 30% Errors Found 18% 10% Relative Cost of Errors 1.0 1-1.5
B.Boehm, Software Engineering Economics
RA/ 24/9180
Software Requirements `Bottom Lines'
s
It is most important to be clear Every requirement must be testable
s
RA/ 25/9180
s s s s s s
s s
s
s
What are the reasons behind the system development? What are the customer expectations? Who are the users and how do they intend to use the product? What do the users expect of the product? What are their level of expertise? What environmental characteristics does the system have to comply with? What are existing and planned interfaces? What functions will the system perform, expressed in customer language? What are the constraints - hardware, software, economic, procedural - that the system must comply with? What will be the final form of the product - model, prototype, mass production?
RA/ 26/9180
Requirements Analysis Questions
Controls
Requirements Analysis 15 Tasks
1. Customer Expectations 2. Project and Enterprise Constraints 3. External Constraints 4. Operational Scenarios 5. Measures of Effectiveness (MOEs) 6. System Boundaries 7. Interfaces 8. Utilization Environments
Inputs Transformed into Outputs
Requirements Analysis
Outputs
Enablers 9. Life-Cycle Process Concepts 10. Functional Requirements 11. Performance Requirements 12. Modes of Operation 13. Technical Performance Measures 14. Design Characteristics 15. Human Systems Integration
RA/ 27/9180
Requirements Analysis Process
From: - Requirements Validation - Functional Verification - Design Verification #1: Define Customer Expectations Requirements Analysis #2: Define Project & Enterprise Constraints #4: Define Operational Scenarios #6: Define System Boundaries To: Functional Analysis #7: Define Interfaces #5: Define Measures of Effectiveness #8: Define Utilization Environments #11: Define Performance Requirements #14: Define Design Characteristics #15: Define Human Systems Integration #9: Define Life-Cycle Process Concepts To: Systems Analysis From: - Systems Analysis - Control #3: Define External Constraints
#10: Define Functional Requirements #13: Define Technical Performance Measures
#12: Define Modes of Operation
Establish Requirements Baseline Operational View Functional View To: Reqts Validation Design View
Extracted from IEEE 1220-1998
RA/ 28/9180
Customer Expectations Task 1
Enterprise defines and quantifies expectations. May come from marketing, customer order, recognized market opportunity, direct communications with customer, or requirements from a higher system s What the customer wants the system to accomplish s How well each function should be accomplished s Natural and induced environments in which the product(s) of the system operates or may be used s Constraints (e.g. funding; cost, or price objectives; schedule; technology; non-developmental and reusable items; design characteristics; hours of operation per day; on-off sequences; external interfaces; etc.)
RA/ 29/9180
Project & Enterprise Constraints - Task 2
Enterprise identifies and defines constraints impacting design solutions s Project constraints include:
Approved specifications and baselines developed from prior applications of the Systems Engineering Process Updated technical and project plans Team assignments and structure Automated tools availability or approval for use Control mechanisms Required metrics for measuring technical progress
s
Enterprise constraints include:
Management decisions from a preceding technical review Enterprise general specifications, standards or guidelines Policies and procedures Domain technologies Established life cycle process capabilities Physical, financial, and human resource allocations to the project
RA/ 30/9180
External Constraints Task 3
Enterprise identifies and defines external constraints impacting design solutions or implementation of the Systems Engineering Process activities External constraints include:
Public and international laws and regulations Technology base Domain Technical Architecture Industry, international, and other general specifications, standards, and guidelines Human-related specifications, standards, and guidelines Human availability, recruitment, and selection Competitor product capabilities
RA/ 31/9180
Operational Scenarios Task 4
Enterprise identifies and defines operational scenarios which scope the anticipated uses of system product(s) For each operational scenario, the enterprise defines:
Expected interactions with the environment and other systems Human tasks and task sequences Physical interconnections with interfacing systems, platforms, or products
RA/ 32/9180
Measures of Effectiveness (MOEs) Task 5
Enterprise defines system effectiveness measures that reflect overall customer expectations and satisfaction Key MOEs include:
Performance Safety Operability Usability Reliability Maintainability Time & cost to train Workload Human performance requirements etc.
RA/ 33/9180
System Boundaries Task 6
Enterprise defines:
Which system elements are under design control of the enterprise and which fall outside of their control and The expected interactions among system elements under design control and external and/or higher-level and interacting systems outside the system boundary (include open systems approaches)
RA/ 34/9180
Interfaces Task 7
Enterprise defines the functional and design interfaces to external and/or higher-level and interacting systems, platforms, and/or products in quantitative terms (include open systems approach) Mechanical, electrical, thermal, data, communicationprocedural, human-machine, and other interactions are included
RA/ 35/9180
Utilization Environments Task 8
Enterprise defines the environments for each operational scenario. All environmental f...