EXPERT RESPONSE
  |
|
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
For a set of requirements you need to be able to:
- 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: - Provide an enhancement
- Fix a defect
This Request may or may not be honored. |
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
.
With all this said, ask yourself a few questions to help determine if using a defect tracking tool for requirements is a smart thing to do.
| Question |
Answer |
Comment |
| Do you own a defect tracking tool now? |
Yes |
<next question> |
| No | Definitely do not buy a defect tracking tool to manage requirements when there are a number of requirements management tools intended for the purpose of managing requirements. Evaluate several tools before purchasing one. |
| Can your company afford a requirements tool? |
Yes | There are a number of requirements management tools to select from. Evaluate several tools before purchasing one. |
| No |
If you already have a defect tracking tool and cannot afford a requirements tool, then determine:
- How you will organize defects and requirements in the same tool.
- What mechanism you will use to categorize requirements by type (business objective, user requirement, functional requirement, nonfunctional requirement, business rule).
- What information you will need to capture about each requirement ("name," "description," "status," "priority," and so forth).
- What information you will need to capture about requirements of a particular requirement type ("pre-conditions," "post-conditions," etc.).
- How you will associate a requirement with other requirements. If there is no linking or trace mechanism, you may need a user-defined attribute that indicates the trace to/from another requirement.
- How you will associate a requirement with other system development artifacts. If there is no linking or trace mechanism, you may need a user-defined attribute that indicates the trace to other system development artifacts (test cases, design, and so forth).
- How you will identify a subset of requirements (baseline) for:
- Review
- Approval
- Release
- …
- How you will track requirement development progress.
- How you will assess impact of a requested change.
- How you will manage product releases.
- How you will report requirement information.
As you can see, this is not the ideal way to go because you will be trying to use a defect tracking tool for a purpose that is not its intended use and for which it may not have appropriate supporting mechanisms. |
|
|
 |
Summary
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.
|
