A Guide to Writing Good Requirements

QA Check Points

Enterprise Program Management

November 22, 2009

Gathered By:

Wail A. Dawud; Lead Enterprise Analyst

Original Author

Ivy Hooks for Third NCOSE Symposium and Published in the Proceedings of the Third International Symposium of the INCOSE - Volume 2, 1993.

Disclaimer: the original author is the SOLE owner of this document and should credited with it. The only difference between the original documents and this document is formatting and some added clarification of certain examples and follow up analysis..

Table of Contents

1. introduction 4
2. good requirements 5
3. Common problems 6
3.1 Bad assumptions 7
3.2 writing implementation (how) instead of requirements (what) 8
3.3 describing operations instead of requirements 10
3.4 using incorrect terms 11
3.5 using incorrect sentence structure or bad grammar 13
3.6 missing requirements 16
3.7 over specifying 18
4. writing quality requirements – qa check points 20
4.1 chatacteristics of quality requirement statements 21
4.1.1 correct 22
4.1.2 feasible 23
4.1.3 necessary 24
4.1.4 priotirized 25
4.1.5 unambiguous 26
4.1.6 verifiable 27
4.1.7 Complete 28
4.1.8 Consistent 29
4.1.9 modifiable 30
4.1.10 traceable 31
5. reviewing requirements for quality 32
5.1 example #1 33
5.2 example #2 34
5.3 example #3 35
5.4 example #4 36
6. Revision History 37

1. introduction

This document will address what makes good requirements. It will cover some of the most common issues that are encountered in writing requirements. The information provided in this document will be used as training tool for analysts to help them write quality requirements. However, it should not replace the organization’s sponsored artifacts and strategies. This document can be used to bring an acceptable level of unified process among