STC 2002, Track 8, 1 May 2002, Ted Byrne 1

HOW TO CREATE GOOD REQUIREMENTS & KNOW IT

Edward R. (Ted) Byrne

Software Consultant

Flatland Computer Specialties, Inc.

flatland@compuserve.com

973-822-3219

Management Board of SESC

Institute of Electrical & Electronic Engineers, Inc.

STC 2002, Track 8, 1 May 2002, Ted Byrne 2

Focus of Talk

"If you don't know how well you are doing, then you know you are not doing very well"

This is not a talk on how to create software requirements, but how to know you have created good requirements.

The goal of this talk is to give you some tips to help you be more successful.

STC 2002, Track 8, 1 May 2002, Ted Byrne 3

The Problem

The problem with doing Requirements is that it is difficult to measure their quality, so you can't get feedback.

As a result:You don't know how well you are doingYou don't know when to stop

STC 2002, Track 8, 1 May 2002, Ted Byrne 4

Steps to Create Requirements

1. You must be motivated, i.e. want to do it.

2. You must know how to do it.

3. You must create CORRECT requirements.

4. You must create COMPATIBLE requirements.

We will discuss 3 and 4.

STC 2002, Track 8, 1 May 2002, Ted Byrne 5

1: Correctness

Definition: Software Requirements tell what the system is to do, not how to do it. ‘Correct' is too broad a term to be useful.

Instead we will look at:

Agreement with the system requirements

Complete

Clear

Feasible

STC 2002, Track 8, 1 May 2002, Ted Byrne 6

Agree with System Requirements

There is really no such thing as software requirements. There are only system requirements, some of which are implemented with software in a computer.

TIP: Is there a non-trivial system, above the software? If so, Review the Software specification with the System Engineers.

STC 2002, Track 8, 1 May 2002, Ted Byrne 7

What if No System?

TIP: If there is no larger system, create “Use Cases”, or CONOPS to capture functionality.

TIP: Make sure you know who all the stake-

holders are. There are more than you think there are.

TIP: Remember that there are Requirements that the customer doesn’t tell you.

STC 2002, Track 8, 1 May 2002, Ted Byrne 8

Complete

Completeness means that nothing is missing.

TIP: Use a Requirements Development tool or the suggested format in IEEE 830, to remind you of what should be in the specification.

TIP: Wrong information is better than no information because it motivates people to correct it. So be complete by entering wrong information.

STC 2002, Track 8, 1 May 2002, Ted Byrne 9

Clear

Not ambiguous and Inter-consistent

TIP You are the worst person to determine if your specification is ambiguous. Get some one else to read and explain it.

TIP Never put the same information is two places. Instead use references, or better yet, hypertext format.

STC 2002, Track 8, 1 May 2002, Ted Byrne 10

Feasible

Vendors love a non-feasible project because they can make more money working on it.

TIP: Create a working model or simulation, if only on paper.

TIP: It never hurts to call the first version, a Feasibility model. There is no upside risk and less downside risk.

STC 2002, Track 8, 1 May 2002, Ted Byrne 11

2. Compatibility

Definition: Software Requirements must be compatible, that is interrelate within the other parts of the software development project.

Compatibility implies: Verifiable Traceable Modifiable Ranked for importance

STC 2002, Track 8, 1 May 2002, Ted Byrne 12

Verifiable

A Requirement that cannot be tested, is not a Requirement.

TIP: Take a tip from the Agile/XP/Scrum people: create requirements that are in fact the tests that an acceptable system should be able to pass.

STC 2002, Track 8, 1 May 2002, Ted Byrne 13

Traceable

Traceability is required for Change Management

TIP: Use a software tool or at least number each paragraph in the requirements specification. Then carry that number forward through the remainder of the development. Never change these numbers.

STC 2002, Track 8, 1 May 2002, Ted Byrne 14

Modifiable

“Software projects change as rapidly as any project ever conceived by the human mind.”

“Requirements change 2% per month”

T. Capers Jones

TIP: Remember software has dis-economy of scale. Design and build the system in parts (GUI, DBM, etc.)

STC 2002, Track 8, 1 May 2002, Ted Byrne 15

Continued

TIP: Because the requirements will change, design and build the system, a portion at a time: Incremental or Spiral development.

TIP: Guarantee there is some success within every budget year.

TIP: This is a big help when requirements change; It is always easier to say ‘later’ than to say ‘no’.

STC 2002, Track 8, 1 May 2002, Ted Byrne 16

Ranked for Importance

TIP: Decide what is the most important aspect of the system:

Get to market fast Ease of use Run in real time Be error-free to .999?

STC 2002, Track 8, 1 May 2002, Ted Byrne 17

Continued

TIP: Attach an importance number to every requirement, if only 1...5, or H-M-L. Build just the most important subset of requirements first.

TIP: Remember that risky requirements are, by definition, important.

STC 2002, Track 8, 1 May 2002, Ted Byrne 18

Ranked for stability

TIP: Attach a stability number to every requirement, if only 1...5, or H-M-L. Isolate the volatile parts in the system and don't spend too much time polishing them.

STC 2002, Track 8, 1 May 2002, Ted Byrne 19

Other Things to Remember

TIP: Do not put too much into the Requirements specification, i.e. Project information or Design information.

TIP: Remember that the Requirements specification will be used to size the project.

TIP: Alternatives that are almost equally good, will generate the most argument.

STC 2002, Track 8, 1 May 2002, Ted Byrne 20

Summary

If you do not know that you have good requirements, you will not have good requirements.

Make sure they are correct by following the steps here.

Make sure they are compatible by following the steps here.

STC 2002, Track 8, 1 May 2002, Ted Byrne 21

Resources

"Mastering the Requirements Process", Suzanne Robertson & James Robertson, Addison-Wesley 1999, ISBN 0-201-36046-2

“Estimating Software Costs”, T. Capers Jones, McGraw-Hill 1998, ISBN 0-07-913094-1.

“Software Engineering Body of Knowledge”, IEEE Press.

STC 2002, Track 8, 1 May 2002, Ted Byrne 22

Standards Resources

IEEE/EIA 12207.0 “Industry Implementation of International Standard ISO/IEC 12207”

IEEE Std 1220 “Application and Management of the Systems Engineering Process”

IEEE Std 830 “Recommended Practice for Software Requirements Specifications”

IEEE Std 1362 “Concept of Operations Document”

IEEE Std 1540 “Risk Management”

IEEE Std 1012 “Software Verification and Validation”

IEEE Std 730 “Software Quality Assurance Plans”

IEEE Std 828 “Software Configuration Management Plans”