Join Terri Wagner for an in-depth discussion in this video Creating well-formed requirements checklists, part of Project Management Foundations: Requirements.
- [voiceover] Creating well-formed requirements checklists might not be the most exciting thing in the world, but it sure is helpful. According to IEEE, requirements must be correct, unambiguous, complete, traceable, prioritized, consistent, modifiable, verifiable and testable. Let's look at each checklist area in more detail. Correct requirements form the basis of constructing the client's request, acceptance tests and formal contracts.
Show your requirements are correct and relevant by comparing them with their source. Identifying the source of each requirement was one of the attributes we said was critical earlier. Now you'll need to choose how to verify each requirement is correct by using clear criteria. Remember, correctness is not absolute. It reflects the current level of knowledge. A requirement is unambiguous if it can be subject to only one interpretation.
You need to choose your words carefully here. Say you choose to use the word bug in your requirement document. According to the dictionary, a bug could be any small insect or a concealed microphone. Which one did you mean? Or did you mean something entirely different? If there's any chance for misunderstanding, define the word in your glossary. Let's look at an example of an ambiguous requirement from our case study. If one of your requirements stated, turbine noise must be kept to an acceptable level at all times.
That would be to ambiguous. You might rewrite that requirement to say, turbine noise must remain in the range of X to Y decibels. With X and Y being your actual measurements. By the way you might also need to consider individual turbine noise and aggregate turbine noise across the entire wind farm. Are there regulations that impact these requirements? Check the existing requirements-elicitation results and if not addressed, it's time to go on the hunt for the regulations.
Remember our metronome? Time to go back and gather the right information to incorporate into our analysis and documentation. Now let's go back to our checklist. You also want to write complete requirements. So make certain your final document includes all functional and nonfunctional requirements important to the user, and any constraints on the design options for the solution. For example, if you had a requirement that said, terminate an automatic teller machine transaction after the number of incorrect password attempts has been reached.
A good rewrite might add the requirement, maximum number of password attempts is three. You could also define who or what will set the maximum at run time. For example, you might write the requirement to say, maximum allowed is read off the card when it's first inserted by the user. Requirements are not written in isolation. They come from somewhere and are used by something else. Traceable requirements and specifications are uniquely numbered and linked to sections within each document, as well as to preceding documents.
You must be able to find and refer to requirements throughout the project life cycle. Prioritizing or ranking requirements is essential for scope management of our project. Numerous factors contribute to the prioritization effort. Requirements may be ranked by things like stability, business risk, technical risk, technical difficulty or cost. You will also want your requirements to be consistent.
Each requirement must specify something that agrees with or does not conflict with other requirements. When two requirements conflict, you must change one to agree with the other, add information on why they should be in use in different circumstances, or make one a higher priority than the other. A modifiable requirement means it must be written and structured to allow for easy changes. Remember, these changes must also be complete and consistent.
Well organized documentation will make it easier for you to make your modifications. At a minimum, you'll want a table of contents and index; a numbering system or traceability and cross-references where appropriate. It's essential that you keep your requirements up to date and current. Requirements management tools may be of assistance here. Now let's look at your last two items on the checklist, verifiable and testable.
User acceptance or product testing verifies and validates the presence of all required system functionality. User acceptance testing confirms that no additional work is required prior to delivery or migration to the production environment. Each functional and nonfunctional requirement in a requirements document must therefore be testable. This means they must be measurable and provable pieces of functionality. Testable requirements can be verified by inspection, simply by looking at characteristics of the system or its output, or by a demonstration.
For example, running one or all of the added turbines in the normal mode of operation. Or by performing a test of a similar turbine at the vendor site. As long as the units that will be at your site will not be modified from the one tested, this would be a good pre-production verification. What drives your requirements prioritization? Do you have a checklist that you use? If not, try integrating a prioritization checklist into your next project and see how it goes.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Classifying requirements
- Developing requirements
- Investigating requirements
- Documenting requirements
- Validating requirements
- Managing changing requirements