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. 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: SE Process Inputs (4.1)

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 doesn’t. • 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. 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 Requirements Analysis (4.2)

7. 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) Integrated Product Teams

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 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: Size, power, weight, etc. Range precision, data rates, etc. GFE, COTS, NDI Directed standards 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 Requirements Analysis Outputs (4.3)

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