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

Transcription

1 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:

2 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

3 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:

4 o Project planning o Risk management o Acceptance testing o Trade-off o 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

5 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

6 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.