Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
| A set of requirements defines the product and a set of defects identifies where the implemented product did not met the stated need. |
In general, you should use a tool for its intended purpose. Like my Daddy used to say, "Betty, don't use the butt end of that screwdriver to hammer in the tacks -- here is the tack hammer." Sometimes, though, we are pushed to use a tool other than the one intended for the job. Maybe you have the right tool, but you can't find it or, for some reason, you don't have access to it. Or perhaps you do not have the right tool, and because you can't afford it you are forced to make do with a substitute.
First, let us look at the type of information you need to keep about a defect and then what information you need to keep about a requirement. This will provide some clues as to whether or not using a defect tracking tool for requirements is a good idea. For a defect you need to be able to:
- Identify the defect
- Document its description, severity, priority and so forth
- Identify who is responsible for fixing it
- Document what was done to fix it
- Document the root cause
- Track the resolution progress
- Report defect information
- Name and describe the requirement
- Categorize requirements by type (business objective, user requirement, functional requirement, nonfunctional requirement, business rule)
- Retain additional information about each requirement:
- Some the information needed will be the same for all requirements regardless of requirement type ("status," "priority," etc.)
- Some of the information need will be different depending on requirement type (User requirements probably need "pre-conditions," "post-conditions," and the like, whereas business objectives do not.)
- Associate a requirement with other requirements, such as:
- Each business objective is traced to one or more user requirements
- Each user requirement is traced to one or more functional requirements
- …
- Associate a requirement with other system development artifacts, such as:
- Each functional requirement is traced to the test case(s) that prove the requirement was met
- Each functional requirement is traced to the design that covers the functionality
- …
- Identify a subset of requirements (baseline) for:
- Review
- Approval
- Release
- …
- Track requirement development progress
- Assess impact of a requested change
- Manage product releases
- Report requirement information
While there are some similarities, you can see that the nature of the information you need to keep about a defect is different from the information that you need to keep about a requirement or a set of requirements. It should not be too difficult to determine why this is true. A requirement is not a defect. A set of requirements defines the product and a set of defects identifies where the implemented product did not met the stated need (or requirements). It is also important to note that the root cause of a defect may be an ambiguous requirement, a flaw in the design, typo in the code or a test that identified the wrong result.
Next, let us explore another concept that, I believe, is significant and is something I see a lot. There are three system development artifacts below. They are all related, but they are definitely not the same.
| Artifact | Description | Comment |
|---|---|---|
Request for Change |
A Request for Change is just that: a request to do something differently. This Request could be to:
|
Many organizations make the mistake of thinking that : Request = Requirement In actuality, a Request can add, modify, even delete a number of Requirements. |
Instructions for Change |
Instructions for Change describe in detail what changes need to be made to implement and approved Request. If functionality is to be added, then you will probably have the new requirements stated. However, if all you need to do is add a couple of data elements to already existing functionality, then there will probably be an instruction to just add these two data elements. |
Instructions for Change is not an industry standard term, but it describes a set of directions provided to development that articulates what to do to implement a Request that has already been approved. |
Requirements |
Requirements define a product or application. |
Without a set of Requirements (at some level) that define your product/application, it is virtually impossible to assess the potential impact of a requested change. Just think about it. If you have a stack of approved Requests for Change or a pile of Instructions for Change, neither defines your product/application, so you can conduct an impact analysis. The stack of Requests identifies what has been changed about the product/application, not what it is. Similarly, the pile of Instructions identifies what has been changed about the product/application, not what it is. |
While the purpose of each of the artifacts above is very different, organizations often do not make a clear distinction. This muddling of concepts can lead to practices that:
- Capture Requests for Change and call them Requirements.
- Capture Instructions for Change and call them Requirements.
- Capture only Requests for Change with the assumption that impact analysis will be possible .
| Question | Answer | Comment |
|---|---|---|
| Yes | ||
| No | ||
| Yes | ||
| No |
|
|
 |
Choose a tool designed to do the job. You need a tool to manage requirements and one to manage defects. It would be good if you can associate a defect with a requirement if indeed the requirement is the root cause of the defect. Look beyond your current need where you are managing defects for an existing system and now recognize that you need to capture requirements as well. Among the places you can go for help in building a business case for requirement definition and management is this webcast, Building a Business Case for Requirements Definition and Management.
This was first published in September 2008