CMGT 580
CMGT 580 Introduction to Systems Engineering Management
Class 5
Chapter 6 Needs Analysis
Reminder where Needs Analysis fits in process
“there is a feasible approach to fulfilling the need at an affordable cost and within an acceptable level of risk”
Concept Development Stage – Needs Analysis
Originating a new system
Needs-driven example: 1960's new laws for automobiles (fuel economy, safety, pollution control)
Technology-driven new systems (space, computers)
External events (new threats, shift in customer demand, economics)
Since there‘s no preceding phase the inputs come from other sources
Applying the Systems Engineering Method
The focus of attention in this phase is on the system operational objectives and goes no deeper than the subsystem level.”
More detail on next charts
Systems Engineering Method applied to the Needs Analysis Phase
Requirements analysis -- Operations analysis
Clarifying requirements
Functional definition -- Functional analysis
Translating requirements into functions
Allocating requirements
Define interfaces
Physical definition -- Feasibility definition
Develop alternative designs
Perform trade-offs to select a preferred approach
Develop detail for the selected design
Design validation -- Needs validation
Model system environment
Verification
Operations Analysis
Detailed identification of perceived deficiencies in current systems
Obsolescence is a prevalent driving force for new systems
The output of this activity is operational objectives for new system
Functional Analysis
This is an extension of operational studies
Establish if there's a possible technical approach to a system
It's not necessary to visualize a best configuration
Feasibility Definition
Feasibility addresses functional design, physical implementation, cost, external constraints and interactions
No attempt is made to optimize the design
Feasibility can be difficult in technology-driven systems
Needs Validation
Examine the validity of the results of the previous steps
Use an operational effectiveness analysis tool (model) based on a set of scenarios
These simulations are evaluated based on criteria called Measures of Effectiveness
This effectiveness analysis determines if a system concept is feasible and satisfies the operational objectives
MOE and MOP Metrics
Measures of Effectiveness (MOE) – indicates the degree to which the whole system achieves its objectives under specified conditions
Measures of Performance (MOP) – quantitative metric of the whole system’s characteristics or performance of a particular attribute, typically a level of physical performance
Development of Operational Requirements (CONOPS)
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?
System Operational Requirements
System operational requirements are the output of the needs analysis phase
“it is essential that these requirements be clear, complete, consistent, and feasible of accomplishment”
Not stated in terms of implementation nor biased toward a particular conceptual approach
All requirements should be measurable (testable)
Types of Requirements
INCREASING
DETAIL
Customer / User Requirements
Statement of fact and assumptions that define the expectations of the system in terms of objectives, environment, constraints, and MOEs.
Functional Requirements
The necessary task, action or activity that must be accomplished
Performance Requirements
The extent to which a function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness.
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.
Types of Requirements
Derived Requirements: additional requirements, inferred from context & user needs, not always specified by customer: but needed to make system work in the real world
Statutory and Regulatory
Certification
Design Considerations
Interfaces
Allocated Requirement: the portion of the system requirement assigned to a subsystem.
Example: 100 kg system with two subsystems
Subsystem 1 allocated req’t 70 kg
Subsystem 2 allocated req’t 30 kg
Requirements Goals
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
Verification of Requirements
Inspection: Examination of items to determine whether they conform to specified requirements.
Analysis: Using established technical or math models, simulations & procedures to provide evidence that stated req’ts were met.
Demonstration: Actual operation of an item to provide evidence that the required functions were accomplished under specific scenarios.
Test: Application of scientific principles and procedures to determine the properties or functional capabilities of items.
Homework 5 due Feb 21 Reply posts due Feb 24
6.6 Assume that you have a business in garden care equipment and are planning to develop one or two models of lawn tractors to serve suburban homeowners. Consider the needs of the majority of such potential customers and write at least six operational requirements that express these needs. Remember the qualities of good requirements as you do so.
Coming up - Class 6 Feb 25
Read Chapter 7
Homework 6 Problem 7.9.a,b,d due Feb 28