2013 gumz webinar_requirements_quality_project_auditors

Project Auditors LLC

Requirements Quality

•  Webinar given on January 24, 2013 to PMI Requirements Community of Practice by Joy Gumz, Project Auditors LLC

This copyrighted material is the property of Project Auditors, LLC, and may not be reproduced without written permission.

1



Agenda •  Introductions •  The challenge to create quality requirements •  What does quality mean? •  Ways to increase requirements quality •  Summary •  Q & A

2




3



What does quality mean? •  Do it right the first time

DIRTFT

•  % rework <= target max % •  Setting a standard and meeting it •  Potential savings

–  Lower percentage of rework –  Fewer changes –  Lower costs of external failure

4



What does quality in requirements mean?

•  Requirements rework <= target maximum % •  Processes to collect and manage

requirement follow organizational guidelines –  Consistent use of templates, models and tools

•  Requirements meet criteria at individual level and for the requirements set

•  Requirements reuse % > 0

5

Project Auditors LLC Why is the process of capturing and managing

requirements critical?


Source: Applications Executive Council Survey, April 2004 . Orange Park, Fla.

6


Cost of poor requirements

•  2004 Study by the State of Indiana Dept of Transportation –  “The study also found that the dominant

category of reasons for change orders is‘errors and omissions’, a finding which is suggestive of possible shortcomings in current design practices.”

–  2001: $17M cost overruns…..2004: $60M –  INDOT was average compared to other states


7

Source: An Analysis of Cost Overruns and Time Delays of INDOT Projects, 2004


Cost of poor requirements


Relative cost to correct a requirements defect depending on when it was caught

Source: Grady, Robert B. 1999. “An Economic Release Decision Model: Insights into Software Project Management.” In Proceedings of the Applications of Software Measurement Conference. Orange Park, Fla.

8




9


Requirements Documents

•  Business Requirements Document •  Statement of Work •  Specifications


•  User scenarios –  A storyboard is one type

•  Use cases •  User stories

10


Requirements Documents

•  Business Requirements Document •  Statement of Work •  Specifications •  Storyboards •  User scenarios •  Use cases •  User stories


TIP 1 Choose the right document for the job - User storyboards, user scenarios or use cases for new development

- Use user stories for incremental software releases

11

Source: IBM Innovate Conference, 2010


Use visualization tools

•  Storyboards •  Building Information Modeling

–  Use 4th Dimension: time to help visualize potential problems during construction and/or maintenance. 5th Dimension: cost. 6D: as built.

•  Software tools –  Bentley, Autocad, Inventor, Blueprintsys.com


TIP 2: Help user visualize the end product by using storyboarding and/or simulation and visualization tools

12

Project Auditors LLC NASA study on written requirements

quality

1. Define the characteristics that should be exhibited by a Business Requirements Document

2. Identify what could be measured 3. Develop indicators of quality 4. Develop a tool to perform the measurements 5. Analyze the BRD documents in light of the

reports generated by the tool 6. Identify underlying problems and 7. Develop recommended practices to preclude the

problems Source: NASA Writing Requirements Guidelines, 2005

13 This copyrighted material is the property of Project Auditors, LLC, and may not be reproduced without written permission.


Desirable Characteristics of Individual Requirements

Unambiguous – Only one possible interpretation

Characteristics of the Collection

Correct – accurately describes functionality

required

Testable – can be verified through test or

inspection

No design impact – states what is required but not how to build it

Achievable – is practical within the

constraints

Traceable – must be traceable to and from source & ultimately to

a business need.

Complete – includes all the requirements and does not need further

amplification

Consistent – requirements may not

conflict

Logically grouped – essential for managing

and, if needed, modifying

Prioritized TIP 3: Keep these criteria in mind (e.g. checklist) when documenting requirements.

Quality attributes



Written requirements

•  Indicators of strength and weakness –  Individual Requirements

•  Imperatives (shall, must, will, should) •  Continuances (below, as follows, listed) •  Directives (figure, table, for example) •  Weak Phrases

–  adequate, as a minimum, as applicable, easy, as appropriate, but not limited to, capability of, effective, if practical, normal

•  Options Phrases (can, may, optionally)

Source: NASA Writing Requirements Guidelines, 2005



Using Tables and Charts

•  Identify each table and chart by a unique identifier.

•  List each table and chart in the table of contents by title, unique identifier and page number.

•  Identify the purpose of the table or chart in the text immediately preceding it.

•  Explain each aspect or element of the table or chart (columns, rows, symbols, blanks, etc.) from right to left then top to bottom.


Source: NASA Writing Requirements Guidelines, 2005

16

Project Auditors LLC Tool for Analyzing Written

Requirements •  Based on NASA’s ARM Tool

–  http://www.solutionthree.com/sift-requirements-tool/

–  More on NASA’s guidelines •  http://www.projectauditors.com/Papers/writing_requirements_guidelines_NASA.pdf

•  These LINKS Are Case Sensitive


ARM = Automated Requirements Management

TIP 5: Use tool to analyze written requirements for quality related metrics

TIP 4: Improve written requirements and specs by using NASA guidelines

17


Requirements Guidelines

•  Terms & Definitions •  Requirements collection •  Management of changes •  Approval process •  Templates •  Tools •  Quality checklists


TIP 6 Create organizational guidelines that cover these topics

18


Why do requirements change? •  Reasons for changes related to design

–  Design error –  Design omission –  Conflicting design information –  Late engineering change –  Field condition: reasonable for designer to check –  Field condition: unreasonable for designer to check –  Change required for constructability / operability


TIP 7: Log reason for changes to requirements, perform root cause analysis and implement corrective action

19

Project Auditors LLC Can you verify requirements to

improve quality? Useful process BUT “You can not inspect in quality.” Edward Deming

You can validate them as you go through the project to make sure 1)  requirements have not changed or 2)  something new has not come up


Project Auditors LLC Summary: Guidelines to promote a high level of quality in requirements

•  Use simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the enterprise

•  Follow organizational guidelines that describe the collection techniques and the types of requirements to be collected that will be used consistently across projects

- If no guidelines exist, the business analyst must select an appropriate set of techniques

•  Produce a consistent set of models and templates to document the requirements

•  Document dependencies and interrelationships among requirements.

•  Use tools that promote better understanding of product such as visualization and simulation

•  Perform root cause analysis of changes to requirements and make corrective actions




Contact information

Name: Joy Gumz, CPA, CISA, PMP

Email: [email protected]

Phone: +1.949.452.0578

http://www.projectauditors.com

22

2013 gumz webinar_requirements_quality_project_auditors

Business

property of project

project auditors llcthis

quality requirements

quality mean

written permission

agenda introductions