Lecture 5.3: SEF Ch 4 Requirements Analysis

1
Lecture 5.3 SEF Ch 4 Requirements Analysis

• Dr. John MacCarthy
• UMBC CMSC 615
• Fall, 2006

2
Requirements Analysis (Ch. 4)

• SE Process Inputs (4.1)
• Types of Requirements
• Attributes of Good Requirements
• Requirements Analysis (4.2)
• IPTs
• Requirements Analysis Outputs (4.3)
• Summary (4.4)
• Requirements Analysis Tasks

3
SE Process Inputs (4.1)

• Inputs
• Customer Requirements
• PROJECT Constraints
• Requirements are the primary focus of the systems
  engineering process because the goal is to
  transform requirements into design (within the
  constraints)

• Customer Requirements provide answers to the
  following questions

4
Types of Requirements

• Customer (Operational) Requirement Statement of
  fact and assumptions that define the expectations
  of the system in terms of mission objectives,
  environment, constraints and measures of
  effectiveness and suitability (MOE/MOS).
  Generally focused on the user/operator and
  related to the 8 primary functions of SE.
  Provides answers to questions on previous Chart.
• Functional Requirement A task, action or
  activity that must be accomplished. One of the
  objectives of Functional Analysis is to decompose
  higher-level user functional requirements into
  lower level subfunctions that can be allocated to
  system components
• Performance Requirement The extent to which a
  mission or function must be executed. One of the
  objectives of Requirements Analysis is to
  identify performance requirements for all
  identified functions. Generally a Performance
  Requirement will be associated with one or more
  Functional Requirements.
• Design Requirement Bulid to, code to, and/or
  buy to requirement for a products as well as a
  how to execute requirement for processes.
  Expressed in technical data packages and
  technical manuals.
• Derived Requirements Requirements that are
  implied or transformed from higher-level
  requirements.
• Allocated (Decomposed) Requirement A
  requirements that is established by dividing or
  otherwise allocating a high-level requirement
  into multiple lower-level requirements (can be
  functional and/or performance).
• Interface Requirement A requirement that a
  system (or component) needs to interact with
  another system (or component), or a requirement
  on the nature of that interface.

5
Attributes of Good Requirements

• Achievable
• One must be able to build or buy something that
  can achieve the requirement
• It must be able to do it within cost/schedule
  constraints
• Verifiable
• Quantitative expression of performance
• Do not use qualitative terms like well or
  sufficient, or big
• The solution either does it or doesnt.
• Unambiguous
• one and only one meaning
• Do not use including , specifically state what
  is included
• Complete
• all information required to understand customer
  need
• addresses all mission profiles
• Expressed as a need, not a solution
• Tell what to do, not how to do it
• Expression of a required solution is a constraint
• Consistent with other requirements
• Appropriate to the level of the requirements
  hierarchy
• - e.g., no detailed component requirements in a
  system requirements document

6
Requirements Analysis (4.2)

• Purpose
• Identify/Refine customer objectives and
  requirements
• Identify/Define performance objectives and refine
  them into requirements
• Identify/Define constraints that limit solutions
• Identify/Define functional, performance, and
  interface requirements base on customer provided
  measures of effectiveness (MOEs) and environment

• Outputs/Results
• Functional Requirements
• Performance Requirements
• Interface Requirements
• Constraints
• Inputs
• Customer needs and objectives
• Missions Environments
• MOEs/MOSs/KPPs
• Output requirements from previous iteration of
  SEP
• Program requirements decisions
• Life Cycle Concept

7
Integrated Product Teams

• Membership
• Systems Engineers
• Operators (Users)
• Subject Matter Experts (SMEs)
• Developers
• Testers

• Problem
• Typically the Users needs are not clearly or
  completely expressed
• Developers generally do not understand the
  operational aspects of the system under
  development
• Customers often want to describe the system
  (solution) they think they need, rather than the
  problem to be solved (requirements)

8
Requirements Analysis Questions

• What are the reasons for the development of the
  system?
• What are customer ( user) expectations?
• Who are the users and how do they intend to use
  the product?
• What is their level of expertise?
• With what environmental characteristics must the
  system comply?
• What are existing and planned interfaces?
• What functions will the system perform (expressed
  in customer language)?
• What will be the final form of the product (e.g.,
  model, prototype, mass production)

9
Requirements Analysis Outputs (4.3)

• Requirements are typically expressed in one of
  three views.
• Operational View How the system will serve its
  users
• Operational Need Definition
• System Mission Analysis
• Operational Sequences
• Conditions/events to which the system must
  respond
• Operational constraints
• Mission performance requirements
• User/maintainer roles (defined by job tasks
  skill)
• Organizational structures that will operate,
  support and maintain the system
• Operational interfaces with other systems
• Physical View How the system is constructed
• System Configuration
• HW/SW components
• HW/SW interfaces (internal and external)
• User Characterization
• System Physical Limitations

• Functional View What the system must do
• System Functions
• System Performance
• Quantitative how well and how much
• Timeliness how quickly and how often
• Inter-functional relationships
• Functional External interfaces
• Information Exchanges (Functional I/O)
• HW SW functional relationships
• Performance Constraints
• Interface Requirements
• Unique HW/SW
• Verification Requirements

10
4.4 Summary

• Initial statement of need is seldom defined
  clearly
• It is your job to work to get one
• A significant amount of collaboration between
  various life cycle customers is needed to produce
  an acceptable requirements document
• Requirements are a statement of the problem to be
  solved
• Unconstrained and non-integrated requirements are
  seldom sufficient for designing a solution
• Trade studies are needed to support the selection
  of a balanced set of requirements
• Requirements from different customers will often
  conflict,
• Constraints will limit options
• Resources are not unlimited

11
Requirements Analysis Procedure (S4-A)

• IEEE P1220 IEEE Systems Engineering Standard
• 15 Requirements Analysis Tasks