Lecture 3 – Requirements Analysis

Design & Innovation Fundamentals

Lecture 3 – Requirements Analysis Design Process  Expression of need  Engineer translates need into a definition of problem, including statement of desired outcome  Engineer then synthesises a solution Methodologies Compared  Staged Design: o Consider a number of solutions o Complete only initial or system design for each o Compare designs against criteria o Select best solution to proceed to detailed design and implementation o Less expensive design process, quicker decision, used with functionally independent modules (Large Scale)  Prototyping: o Consider one possible solution o Complete detailed design o Implement solution: evaluate against criteria: (performance, cost, reliability, maintainability) o Repeat process until satisfactory solution obtained o Used where it is cheaper to prove by prototype and where there are functionally depended modules (Small Scale) Present Proposal as a Story

Core Design Requirements  At the start of a project, it is important to specify those parameters and properties that:

o Define the particular concept o Influence the product structure o Determine the overall embodiment of the product

Problem Domain vs Solution Domain

Developing the Stakeholder Requirements Specification

What are ‘Requirements’?  The stated life-cycle customer needs and objectives for the system, and they relate to how well the system will work in its intended environment.  Requirements are the primary focus in the systems engineering process o Transform these requirements into designs o Develop these designs within the constraints  Limitations imposed by external interfaces,  Project support,  Technology  Life cycle support systems

o Design must be validated that is meets both the requirements and constraints

Developing Requirements

Requirements Analysis -1  The purpose of Stakeholder Requirements is to: o Refine customer objectives and requirements o Define initial performance objectives and refine them into requirements o Identify and define constraints that limit solutions o Define functional and performance requirements based on customer provided measures of effectiveness  Stakeholder Requirements Analysis should result in a clear understanding of: o Functions o Performance o Interfaces o Other requirements and constraints Where are Requirements Used?  Because requirements define: o What the stakeholders need o A description of the proposed system o What the system must do in order to satisfy these needs  Requirements form the basis for:

o o o o o

Project planning Risk management Acceptance testing Trade-off Change control

Customer Needs vs Requirements  Should translate customer wants into a problem statement that reflects true needs. o Needs analysis o Wants normally exceed true needs  Needs Statement / Problem Statement: o Written in a language of the customer (non-technical) o Complete: should cover all aspects of design o Specific: should contain sufficient information to allow specification to be produced  Requirements are the designer’s detailed breakdown of what the Product Concept should do and achieve to meet these needs without providing a solution.  Explicit Requirements – stated by the customer  Implicit Requirements – have to be drawn out from the customer Kepner Tregoe Approach

Stakeholder Requirements Analysis Organising Requirements  Importance of Requirements o Demand- must be met by design o Wishes- should be incorporated if possible o Prioritise the requirements based on weighted score  Clarity of Requirements o Quantity: all data involving numbers and magnitude o Quality: all data involving permissible variations or special requirements

Expressing Requirements  Functional and Non-functional  Group according to know Product Concept sub-systems  Structured – Objective Tree  Traceable to either a customer need or necessary and sufficient for product concept  Structured documentation o Shows incomplete or inconsistent requirements o Communicates clearly to design team Uses of Stakeholder Requirements Analysis  Get customer agreement – basis of contract  Discover customer “build to” or “existing system” requirements  Sets out criteria for validating that the design meets its intended objectives  Acts as a filter to remove designs that are: o Heading for failure o Overly ambitious o Have conflicting objectives  Fully dimension and cost subsequent development  Describes the tests to which the design will be submitted during verification  Communicate requirements to the development process downstream

Types of Requirements – System Engineering Model  Customer Requirements: 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.  Functional Requirements: the necessary task, action or activity that must be accomplished. Functional requirements (what has to be done) will be used as the top level functions for functional analysis.  Performance requirements: the extent to which a mission or 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 and technical manuals.  Derived Requirements: those that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.  Allocated requirements: on that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Simple Rules for Validating Requirements Attributes of Good Requirements  Achievable – a solution is technically achievable at costs considered affordable



     

Verifiable – no defined by words such as excessive, sufficient, resistant, etc. the expected performance and functional utility must be expressed in a manner that allows verification to be objective, preferably quantitative. Unambiguous – must have one possible meaning Complete – contain all mission profiles, operational and maintenance concepts, utilization environments and constraints. Abstract – expressed in terms of need, not solution. Consistent – no conflicts with other requirements Appropriate detail – Traceable – either directly expressed by the customer or a customer need developed during the requirements analysis.

Checklist for Poor Requirements  Incomplete lists ending with “etc.,” “and/or,” and “TBD.”  Vague words and phrases such as “generally,” “normally,” “to the greatest extent,” and “where practicable.”  Imprecise verbs such as “supported,” “handled,” “processed,” or “rejected.”  Implied certainty, flagged by words such as “always,” “never,” “all,” or “every.”  Passive voice, such as “the counter is set.” (By whom or what?)  Every pronoun, particularly “it” or “its.”  Comparatives, such as “earliest,” “latest,” “highest.” Words ending in “or” or “est” should be suspect.  Words and phrases that cannot be quantified, such as flexible, modular, efficient, better, faster. Use of Shall, Should and Will  Mandatory requirements use the word “shall.”  Trade-off requirements use the word “should,” e.g. the car’s accessories should cost about 10% of…  The word “will” is used to express declaration of intent on the part of the contracting agency, to express future tense, and for statements of fact.