1 Writing Better Requirements The Key to a Successful Project Kimberly Roberts Senior Application Engineer kimberly_roberts
2 Objectives Learn how good requirements definition can benefit your organization. Learn what the differences are between User Requirements, System Requirements and Architectural Design Requirements Explore the anatomy of a requirement and characteristics of a good requirement
3 Why projects fail Incomplete requirements % Lack of user involvement % Lack of resources % Unrealistic expectations - 9.9% Lack of executive support - 9.3% Changing reqs/specs - 8.7% Lack of planning - 8.1% Didn t need it any longer - 7.5% Sources: Standish Group Scientific American
4 Why projects succeed User involvement % Management support % Clear statement of reqs % Proper planning - 9.6% Realistic expectations - 8.2% Smaller milestones - 7.7% Competent staff - 7.2% Ownership - 5.3% Sources: Standish Group Scientific American
5 And the question is... How do we make a project successful?
6 Write Better Requirements. It s a HIGH LEVERAGE activity!! Requirements allow you to IMPROVE Quality with LESS effort.
7 Requirements are how we communicate Developers Management Customer Designers Users Manufacturers
8 What are Requirements? (They are the To-Do List of the Project Team) List of WHAT the Users need List of WHAT the System must do to Satisfy their needs List of WHAT components must be built List of WHAT each component must DO, and HOW they will INTERACT Requirements define the quality of the system
9 When are Good Requirements Essential? If you are building anything intended for someone else s use If you are building systems that do more than one thing If you are building anything that will be used more than once If you are building something that interacts with other systems If you are building a system that requires a specified level of performance If you are building anything that involves payment or other consideration (in other words, a contract) Good requirements can make a difference
10 Requirements Ensure You Build the Right Project the Right Way User requirements Validation Acceptance tests DEFINITION DEFINITION System requirements Architectural design Verification Verification System tests Integration tests INTEGRATION INTEGRATION VALIDATION VALIDATION Component development Component tests
11 Basic Types of Requirements TYPES OF REQUIREMENTS TYPES OF DOCUMENTS Functional Requirements User or Business Needs Requirements Non-Functional Requirements System or Functional Requirements Constraints Architectural Design Design Guidelines Element Requirements (Software & Hardware) Interface Definition Requirements
12 Document Definitions User/Business Needs Requirements What the System should do from the Users Perspective System/Functional Requirements What the System will do from the builders Perspective Component Requirements Design level list of all things that each component must do. Any Programmer/Engineer can build one from this document Interface Requirements Description of the Protocol and Physical Interface between Components of the System
13 Key Number 1 : Know where we are going. USER/BUSINESS NEEDS REQUIREMENTS Capture user requirements to understand what user problems your product will solve.
14 If we don t know where we re going. we never get there. we think we re there but in reality we are not. we finally get there but it takes a long time to arrive. We have the time to do it over and over again but we never have the time to do it right the first time!
15 How do we know where we re going? Maintainers End users Testers Customer Marketing Corporate executives The different types of users tell us!
16 Good user requirements are essential! Without good user requirements there is no clear direction for building a product. Product team members can head in different directions!
17 User Needs Generated by: Business Analysis Generated From: User Requests Business Rules Corp Business Rules End User Rqmts RFP Contract View By: Priority Importance Acceptable You Choose
18 Where do User Needs Come From?
19 Anatomy of a User Requirement The order entry clerk shall be able to complete ten customer orders in less than 2 hours This requirement identifies a real user type and an end result. It also defines the success criteria in measurable terms. The challenge is to seek out the user type, end result, and success measure in every requirement.
20 Key Number 2 : Know What We Are Doing SYSTEM/FUNCTIONAL REQUIREMENTS What do WE need to know to build this?
21 What Makes Up a System? Components of System Requirements: Key requirements in here Use attributes Descriptive Elements Functional or Behavioral Breakdown Performance Interfaces Non-Functional Requirements Traceability to User Requirements The core of the system requirements document Often a large part of a document required for content to make sense
22 System Requirements Document Defines a model of the system to be built - not the system Defines some mixture of functionality, behavior, performance, and systems constraints It s a model, not a complete system definition Organized by functionality or logical layout As implementation free as possible Every statement verifiable, with level and nature of test as attributes Defines professional constraints -- e.g. from different disciplines, working environment, induced environment, safety, etc. Owned by systems engineers, viewable to everyone including customers and designers
23 Different Attributes Between User and System Requirements User Responsibility User Requirements Priority Implement? High Yes Medium Medium Yes Medium High Yes Low Low No High Medium No High Developer Responsibility Cost System Requirements Users are responsible for prioritizing a user requirement Developers for costing the requirement In the end, the user representative should decide whether cost is worth the result
24 Key Number 3 : Know What to Build and Implement ARCHITECTURAL DESIGN REQUIREMENTS Decomposition to detailed design and subsystem components
25 What Makes up the Design? Components of Architectural Design: Key requirements often in here Make use of attributes Descriptive Elements Component Behavior/Control Component Functionality Component Interfaces Component Layout Dependencies & Resources Test Criteria Traceability to System Requirements The core of the system component design System or component level constraints
26 Architectural Design Document Defines WHAT is to be built, how it behaves, how it is laid out Defines key components, interfaces, control structures & external systems Detailed enough for optimization, partitioning to contractors, and definition of configuration item structure Basis for all milestones States what the system/component IS, not just its functionality Every statement verifiable and ready for integration tests with attributes to track states and methods of verification Created by designers, owned by developers, viewable by all Cost estimation should be well definable at this stage
27 Design versus System Level Requirements System Requirements Functional definition of two functions and an interface Supply Power 10 kw Heat Cabin Architectural Design Equivalent interface definition in design phase Gas Driven Generator 600 volts 18 Amp 400 Hertz Electrical Heater
28 Key Number 4 : Take Command WRITE BETTER REQUIREMENTS! The Anatomy of a Better Requirement..
29 Typical Requirement Problems Inappropriate Level Poor Definition Lack of Structure and Control Undefined Ownership No Traceability No Completion Criteria
30 What is a Requirement? Must form a complete sentence (not a bullet list of buzz words, list of acronyms, or sound bites ) States a subject and predicate where the subject is a user Consistent use of the to be verb: shall, will or must to show mandatory nature should or may to show optionality Has end result Contains success criteria or is testable in nature
31 Types of Requirements Functional Requirements Capability that the system must perform Non-Functional Requirements Conditions that must be met that are not explicit capabilities (ie Constraints/Guidelines ie: : the system must run with 32M of RAM)
32 Characteristics of Good Requirements Each Individual Requirement Should Be: Clear Avoid confusion Brief Short and simple Verifiable Testable and verifiable Traceable Uniquely identified and can be tracked Each Requirement Should Be Annotated with Attributes: Priority Emphasize important requirements Source Who requires it? Urgency When? Identity Requirements must be uniquely identifiable Comments Clarification recorded when needed Query/Response All can benefit from discussions
33 Characteristics of Good Documents Each Collection of Requirements Should Be: Complete Balanced Modular Correct Consistent Realistic Role/State/Mode Type Inclusive Are all requirements expressed? Are requirements at a consistent level of detail? Can system be changed without unforeseen side effects? Are user needs correctly expressed? No contradictions exist between requirements? Can we really build it? Are requirements associated with user roles/system states? Functional, Non-Functional, Constraints, Guidelines
34 Traceability Ensures Quality Without traceability products can drift away from what the user requires Requirements Quality is conformance to requirements.
35 Verifiability Ensures Quality Track the Source and Status of your Requirements with Attributes Record the source (when created, rationale, original text) Record urgency (mandatory, useful, optional, luxury) Record acceptance (proposed, reviewed, accepted, rejected) Identify verification method (test, demonstration, inspection, simulation, analysis) Identify constraints (safety, performance, reliability, corporate standards, business rules) Record discussion (comments, action items, proposed change, state of review process)
36 Analysis Now Made Simple Once this wealth of information is captured and well written, the status of a project can be easily determined: Show all high priority requirements for the pilot on the flight control subsystem: Priority = High User = Pilot Subsystem = Flight Control Show all the requirements maintenance users proposed that could effect safety and performance: User = Maintenance Status = Proposed Constraints = Safety & Performance
37 The keys to writing better requirements lead to successful projects! User Requirements System Requirements Architectural Design Better Requirements qssinc.com
Software Requirements cmsc435-1 Objectives To introduce the concepts of user and system requirements To describe functional and non-functional requirements To explain how software requirements may be organized
General Principles of Software Validation; Final Guidance for Industry and FDA Staff Document issued on: January 11, 2002 This document supersedes the draft document, "General Principles of Software Validation,
Transforming software and systems delivery White paper May 2008 Tips for writing good use cases. James Heumann, Requirements Evangelist, IBM Rational Software Page 2 Contents 2 Introduction 2 Understanding
USE-CASE 2.0 The Guide to Succeeding with Use Cases Ivar Jacobson Ian Spence Kurt Bittner December 2011 USE-CASE 2.0 The Definitive Guide About this Guide 3 How to read this Guide 3 What is Use-Case 2.0?
Eight Things Your Business Analysts Need to Know A Practical Approach to Recognizing and Improving Competencies An ESI International White Paper (877) 766-3337 www.esi-intl.com Table of Contents Abstract...3
HANDBOOK FOR ACQUIRING A RECORDS MANAGEMENT SYSTEM (RMS) THAT IS COMPATIBLE WITH THE NATIONAL INCIDENT-BASED REPORTING SYSTEM (NIBRS) May 2002 TABLE OF CONTENTS INTRODUCTION 1 1 MAKE THE NIBRS RMS DECISION
Rational Unified Process Best Practices for Software Development Teams A Rational Software Corporation White Paper Rational Unified Process Best Practices for Software Development Teams WHAT IS THE RATIONAL
The Scrum Guide The Definitive Guide to Scrum: The Rules of the Game July 2013 Developed and sustained by Ken Schwaber and Jeff Sutherland Table of Contents Purpose of the Scrum Guide... 3 Definition of
A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT David L. Parnas Computer Science Department University of Victoria Victoria BC V8W 2Y2 Canada and Computer Science and Systems Branch Naval Research Laboratory
So You Want To Be a Requirements Analyst? 1 Karl E. Wiegers Process Impact www.processimpact.com Be it explicitly or not, someone always performs the role of requirements analyst on a software project.
CMMI for Development, Version 1.3 CMMI-DEV, V1.3 CMMI Product Team Improving processes for developing better products and services November 2010 TECHNICAL REPORT CMU/SEI-2010-TR-033 ESC-TR-2010-033 Software
UML and Patterns.book Page 61 Thursday, September 16, 2004 9:48 PM Chapter 6 6 USE CASES The indispensable first step to getting the things you want out of life: decide what you want. Ben Stein Objectives
Managing digital records without an electronic record management system Crown copyright 2012 You may re-use this information (excluding logos) free of charge in any format or medium, under the terms of
Requirements Engineering Processes Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 7 Slide 1 Objectives To describe the principal requirements engineering activities and their relationships
IP ASSETS MANAGEMENT SERIES 1 Successful Technology Licensing 2 Successful Technology Licensing I. INTRODUCTION II. III. IV. PREPARATION FOR NEGOTIATION KEY TERMS CONDUCTING THE NEGOTIATION V. USING THE
Document subject to 4.1 General requirements The organization shall: a) b) establish, document, implement, maintain and improve an EnMS in accordance with the requirements of this International Standard;
1 Develop productive working relationships with colleagues Unit Summary What is the unit about? This unit is about developing working relationships with colleagues, within your own organisation and within
GAO United States General Accounting Office Executive Guide March 2004 Version 1.1 INFORMATION TECHNOLOGY INVESTMENT MANAGEMENT A Framework for Assessing and Improving Process Maturity a GAO-04-394G March
Making Smart IT Choices Understanding Value and Risk in Government IT Investments Sharon S. Dawes Theresa A. Pardo Stephanie Simon Anthony M. Cresswell Mark F. LaVigne David F. Andersen Peter A. Bloniarz
Data Modeling Windows Enterprise Support Database Services provides the following documentation about relational database design, the relational database model, and relational database software. Introduction
Operational Excellence Management System An Overview of the OEMS Contents 2 4 6 8 14 16 17 Back Cover Operational Excellence Management System Leadership Accountability Management System Process OE Expectations
An AIIM Briefing Helping you manage and use information assets. How to Develop Taxonomies to Support Navigation, Information Discovery, and Findability Produced by AIIM Training By arl Weise, RM Industry
Two Value Releases per Year How IT Can Deliver Releases with Tangible Business Value Every Six Months TABLE OF CONTENTS 0 LEGAL DISCLAIMER... 4 1 IMPROVE VALUE CHAIN AND REDUCE SG&A COSTS IN FAST CYCLES...