Writing Better Requirements The Key to a Successful Project

(1)

Writing Better Requirements

The Key to a Successful Project

Kimberly Roberts

Senior Application Engineer

kimberly_

(2)

Objectives

ä

ä Learn how good requirements definition can_{Learn how good requirements definition can}

benefit your organization. benefit your organization.

ä

ä Learn what the differences are betweenLearn what the differences are between

User Requirements, System Requirements User Requirements, System Requirements and Architectural Design Requirements

and Architectural Design Requirements

ä

ä Explore the anatomy of a requirement andExplore the anatomy of a requirement and

characteristics of a good requirement characteristics of a good requirement

(3)

Why projects fail

ä

ä Incomplete requirements - 13.1%_{Incomplete requirements - 13.1%}

ä

ä Lack of user involvement - 12.4%Lack of user involvement - 12.4%

ä

ä Lack of resources - 10.6%Lack of resources - 10.6%

ä

ä Unrealistic expectations - 9.9%_{Unrealistic expectations - 9.9%}

ä

ä Lack of executive support - 9.3%Lack of executive support - 9.3%

ä

ä Changing reqs/specs - 8.7%Changing reqs/specs - 8.7%

ä

ä Lack of planning - 8.1%_{Lack of planning - 8.1%}

ä

ä Didn’t need it any longer - 7.5%_{Didn’t need it any longer - 7.5%}

Sources: Standish Group Sources: Standish Group

Scientific American Scientific American

(4)

Why projects succeed

ä

ä User involvement - 15.9%_{User involvement - 15.9%}

ä

ä Management support - 13.9%Management support - 13.9%

ä

ä Clear statement of reqs - 13.0%Clear statement of reqs - 13.0%

ä

ä Proper planning - 9.6%_{Proper planning - 9.6%}

ä

ä Realistic expectations - 8.2%Realistic expectations - 8.2%

ä

ä Smaller milestones - 7.7%Smaller milestones - 7.7%

ä

ä Competent staff - 7.2%_{Competent staff - 7.2%}

ä

ä Ownership - 5.3%_{Ownership - 5.3%}

Sources: Standish Group Sources: Standish Group

Scientific American Scientific American

(5)

And the question is…...

How do we make a project

successful?

(6)

Write Better Requirements….

It’s a

It’s a HIGH LEVERAGEHIGH LEVERAGE activity!! activity!! Requirements allow you to

Requirements allow you to IMPROVEIMPROVE

Quality with

(7)

Requirements are how we

communicate

Requirements are how we

communicate

Developers Developers Customer Customer Users

Users ManufacturersManufacturers

Designers

Management

(8)

What are Requirements?

(They are the “To-Do” List of the Project Team)

What are Requirements?

(They are the “To-Do” List of the Project Team)

ä

ä List of WHAT_{List of}WHAT the Users need_{the Users need}

ä

ä List of WHATList of WHAT the System must do to the System must do to

Satisfy their needs Satisfy their needs

ä

ä List of _{List of}WHAT_WHAT components must be built_{components must be built}

ä

ä List of WHATList of WHAT each component must each component must DODO,,

and

and HOWHOW they will they will INTERACTINTERACT

Requirements define the quality

of the system

(9)

When are Good Requirements

Essential?

When are Good Requirements

Essential?

ä

ä If you are building anything intended for someone else’s use_{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 systems that do more than one thing} ä

ä If you are building anything that will be used more than_{If you are building anything that will be used more than} once

once ä

ä If you are building something that interacts with other_{If you are building something that interacts with other} systems

systems ä

ä If you are building a system that requires a specified level of_{If you are building a system that requires a specified level of} performance

performance ä

ä If you are building anything that involves payment or other_{If you are building anything that involves payment or other} consideration (in other words, a

consideration (in other words, a contractcontract))

Good requirements can make a difference Good requirements can make a difference

(10)

Requirements Ensure You Build

the Right Project the Right Way

Requirements Ensure You Build

the Right Project the Right Way

Architectural Architectural design design System System requirements requirements User User requirements requirements Component Component development development Component Component tests tests Integration Integration tests tests System System tests tests Acceptance Acceptance tests tests Verification Verification Validation DEFINITION DEFINITION INTEGRATION INTEGRATIONVALIDATIONVALIDATION

(11)

Basic Types of Requirements

ä T Y P E S O F D O C U M E N T S

ä _{User or Business Needs} Requirements

ä System or Functional Requirements

ä _{Architectural Design}

ä “Element” Requirements

(Software & Hardware)

ä Interface Definition Requirements ä T Y P E S O F R E Q U I R E M E N T S ä _Functional Requirements ä Non-Functional Requirements ä _Constraints ä Design Guidelines

(12)

Document Definitions

ä 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

ä User/Business Needs Requirements

(13)

Key Number 1 :

Know where we are going.

Capture user requirements to

understand what user problems

your product will solve.

USER/BUSINESS NEEDS

REQUIREMENTS

(14)

If we don’t know where we’re

going….

ä

ä we never get there._{we never get there.}

ä

ä we think we’re there but in reality we arewe think we’re there but in reality we are

not. not.

ä

ä we finally get there but it takes a long time_{we finally get there but it takes a long time}

to arrive. to arrive.

We have the time to do it over and over again

but we never have the time to do it right the

(15)

How do we know where

we’re going?

The different types of users tell us!

Corporate executives Customer Marketing Testers End users Maintainers

(16)

Good user requirements are

essential!

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:_{Generated by:}

ä

äBusiness Analysis_{Business Analysis} ä

ä Generated From:Generated From:

ä

ä_{User Requests}_{User Requests}

ä

äBusiness Rules_{Business Rules} View By:View By:

• • PriorityPriority • • ImportanceImportance • • AcceptableAcceptable •

• YouYou Choose Choose

Corp Corp Business Business Rules Rules End End User User Rqmts Rqmts RFP RFP Contract Contract

(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

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

“What do WE need to know to “What do WE need to know to

build this?” build this?” SYSTEM/FUNCTIONAL SYSTEM/FUNCTIONAL REQUIREMENTS REQUIREMENTS

(21)

What Makes Up a System?

ä

ä Descriptive Elements_{Descriptive Elements} ä

ä _{Functional or Behavioral}_{Functional or Behavioral} Breakdown Breakdown ä ä Performance_Performance ä ä Interfaces_Interfaces ä

ä _{Non-Functional Requirements}_{Non-Functional Requirements} ä

ä Traceability to User_{Traceability to User} Requirements

Requirements

Components of System Requirements:

Key requirements Key requirements in here in here Use attributes Use attributes

The core of the system The core of the system requirements document requirements document

Often a large part of a Often a large part of a document required for document required for content to “make sense” content to “make sense”

(22)

System Requirements Document

l

l Defines a model of the system to be built - not the system_{Defines a model of the system to be built - not the system} l

l Defines some mixture of functionality, behavior, performance, and_{Defines some mixture of functionality, behavior, performance, and}

systems constraints systems constraints

l

l It’s a model, not a complete system definition_{It’s a model, not a complete system definition} l

l Organized by functionality or logical layout_{Organized by functionality or logical layout} l

l As implementation free as possible_{As implementation free as possible} l

l Every statement verifiable, with level and nature of test as attributes_{Every statement verifiable, with level and nature of test as attributes} l

l Defines professional constraints -- e.g. from different disciplines,_{Defines professional constraints -- e.g. from different disciplines,}

working environment, induced environment, safety, etc. working environment, induced environment, safety, etc.

l

l _{Owned by systems engineers, viewable to everyone including}_{Owned by systems engineers, viewable to everyone including}

customers and designers customers and designers

(23)

Different Attributes Between

User and System Requirements

Different Attributes Between

User and System Requirements

ä

ä _{Users are responsible for prioritizing a user requirement}_{Users are responsible for prioritizing a user requirement} ä

ä Developers for costing the requirement_{Developers for costing the requirement} ä

ä In the end, the user representative should decide whether_{In the end, the user representative should decide whether} cost is worth the result

cost is worth the result

User Requirements Priority Cost System Requirements Implement? User Responsibility

User Responsibility Developer Responsibility_{Developer Responsibility} High Yes Medium

Medium Yes Medium High Yes Low Low No High Medium No High

(24)

Key Number 3 :

Know What to Build and Implement

Decomposition to detailed Decomposition to detailed design and design and subsystem components subsystem components ARCHITECTURAL ARCHITECTURAL DESIGN DESIGN REQUIREMENTS REQUIREMENTS

(25)

What Makes up the Design?

ä

ä Descriptive Elements_{Descriptive Elements} ä

ä _{Component Behavior/Control}_{Component Behavior/Control} ä

ä Component Functionality_{Component Functionality} ä

ä Component Interfaces_{Component Interfaces} ä

ä Component Layout_{Component Layout} ä

ä _{Dependencies & Resources}_{Dependencies & Resources} ä

ä Test Criteria_{Test Criteria} ä

ä Traceability to System_{Traceability to System} Requirements

Requirements

Components of Architectural Design:

Key requirements Key requirements often in here often in here

Make use of attributes Make use of attributes

The core of the system The core of the system component design component design System or component System or component level constraints level constraints

(26)

Architectural Design Document

l

l Defines WHAT is to be built, how it behaves, how it is laid out_{Defines WHAT is to be built, how it behaves, how it is laid out} l

l Defines key components, interfaces, control structures & external_{Defines key components, interfaces, control structures & external}

systems systems

l

l Detailed enough for optimization, partitioning to contractors, and_{Detailed enough for optimization, partitioning to contractors, and}

definition of configuration item structure definition of configuration item structure

l

l _{Basis for all milestones}_{Basis for all milestones} l

l States what the system/component IS, not just its functionality_{States what the system/component IS, not just its functionality} l

l _{Every statement verifiable and ready for integration tests with}_{Every statement verifiable and ready for integration tests with}

attributes to track states and methods of verification attributes to track states and methods of verification

l

l _{Created by designers, owned by developers, viewable by all}_{Created by designers, owned by developers, viewable by all} l

(27)

Design versus System Level

Requirements

Design versus System Level

Requirements

Supply

Power CabinHeat

System Requirements System Requirements

Architectural Design Architectural Design Gas Driven

Generator ElectricalHeater

Functional Functional definition of two definition of two functions and functions and an interface an interface 10 kW 10 kW 600 volts 18 Amp 600 volts 18 Amp 400 Hertz 400 Hertz Equivalent Equivalent interface interface definition in definition in design phase design phase

(28)

Key Number 4 :

Take Command

The Anatomy of a The Anatomy of a Better Requirement….. Better Requirement….. WRITE BETTER WRITE BETTER REQUIREMENTS! REQUIREMENTS!

(29)

Typical Requirement Problems

ä

ä Inappropriate Level_{Inappropriate Level}

ä

ä Poor DefinitionPoor Definition

ä

ä Lack of Structure and ControlLack of Structure and Control

ä

ä Undefined Ownership_{Undefined Ownership}

ä

ä No TraceabilityNo Traceability

ä

(30)

What is a Requirement?

ä

ä Must form a complete sentence (not a bullet list of_{Must form a complete sentence (not a bullet list of}

buzz words, list of acronyms, or “sound bites”)

buzz words, list of acronyms, or “sound bites”)

ä

ä States a subject and predicate where the subject is a_{States a subject and predicate where the subject is a}

user

ä

ä Consistent use of the “to be” verb:_{Consistent use of the “to be” verb:}

ä

ä shall_shall,_, will_will or_or must_must to show mandatory nature_{to show mandatory nature} ä

ä should_should or _ormay_may to show optionality_{to show optionality}

ä

ä _{Has end result}_{Has end result}

ä

(31)

Types of Requirements

ä

ä Functional Requirements_{Functional Requirements}

u

u Capability that the system must performCapability that the system must perform

ä

ä Non-Functional RequirementsNon-Functional Requirements

u

u Conditions that must be met that are not explicitConditions that must be met that are not explicit

capabilities

capabilities (ie(ie: the system must run with 32M of RAM): the system must run with 32M of RAM)

ä

(32)

Characteristics of Good

Requirements

ä

ä Clear_Clear Avoid confusionAvoid confusion ä

ä _Brief_Brief Short and simple_{Short and simple} ä

ä Verifiable_Verifiable Testable and verifiableTestable and verifiable ä

ä Traceable_Traceable Uniquely identified and can be trackedUniquely identified and can be tracked

ä

ä Priority_Priority Emphasize important requirementsEmphasize important requirements ä

ä Source_Source Who requires it?Who requires it? ä

ä Urgency_Urgency When?When? ä

ä _Identity_Identity Requirements must be uniquely identifiableRequirements must be uniquely identifiable ä

ä Comments_Comments Clarification recorded when neededClarification recorded when needed ä

ä _{Query/Response}_{Query/Response} All can benefit from discussionsAll can benefit from discussions Each Individual Requirement Should Be:

Each Individual Requirement Should Be:

Each Requirement Should Be Annotated with Attributes:

(33)

Characteristics of Good

Documents

ä

ä Complete_Complete Are all requirements expressed?Are all requirements expressed? ä

ä _Balanced_Balanced Are requirements at a consistent level of detail?Are requirements at a consistent level of detail? ä

ä Modular_Modular Can system be changed without unforeseen side effects?Can system be changed without unforeseen side effects? ä

ä Correct_Correct Are user needs correctly expressed?Are user needs correctly expressed? ä

ä Consistent_Consistent No contradictions exist between requirements?No contradictions exist between requirements? ä

ä _Realistic_Realistic Can we really build it?Can we really build it? ä

ä Role/State/Mode_{Role/State/Mode} Are requirements associated with user roles/system states?Are requirements associated with user roles/system states? ä

ä Type Inclusive_{Type Inclusive} Functional, Non-Functional, Constraints, GuidelinesFunctional, Non-Functional, Constraints, Guidelines Each Collection of Requirements Should Be:

(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_{Track the Source and Status of your}

Requirements with Attributes Requirements with Attributes

ä

ä Record the source (when created, rationale, original text)_{Record the source (when created, rationale, original text)}

ä

ä Record urgency (mandatory, useful, optional, luxury)_{Record urgency (mandatory, useful, optional, luxury)}

ä

ä Record acceptance (proposed, reviewed, accepted, rejected)_{Record acceptance (proposed, reviewed, accepted, rejected)}

ä

ä Identify verification method (test, demonstration, inspection,Identify verification method (test, demonstration, inspection, simulation, analysis)

simulation, analysis)

ä

ä Identify constraints (safety, performance, reliability,_{Identify constraints (safety, performance, reliability,}

corporate standards, business rules)

ä

ä Record discussion (comments, action items, proposed_{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

(37)

The keys to writing better requirements

lead to successful projects!

User Requirements Better Requirements System Requirements Architectural Design

www.