13.4 Managing requirements
Managing requirements
For the issues discussed so far, you need a good way of managing requirements. Different techniques are used to do so, ranging from simple sheets of paper to specialized tools like Rational RequisitePro. Typically, some kind of text processor like Microsoft Word is involved in the process. Another popular way to manage requirements is to keep them in a database. This makes it easy to keep track of changes in requirements, sub-requirements, and related requirements. When using a database, you can track additional attributes of each requirement, such as groupings or level of importance.
Collecting requirements is an iterative process, just like every other part of the development lifecycle. The first step is to find external interfaces for the system. Typically, the customer has a couple of documents that describe the system in a very basic and often incomplete fashion. This document is usually good enough to be used as a starting point. If there is no such document, you need to ask the customer to write one. Systems often have more than one such document. The future users might write one, a domain expert might write another, and so forth. Needless to say, these documents often are inconsistent, but that's fine. It's your job to make sure the final list doesn't have inconsistencies. The fact that multiple documents are usually inconsistent actually works in your favor. Since two documents are different, one must obviously be wrong. If you had only one of them, an incorrect requirement might have made it to your list unquestioned. If you have multiple inconsistent documents, the discussion arises right away and you have the chance to get rid of potential problems early in the cycle.
You can use these documents to find "shall" sentences, which can be collected in a list. One standard you could use for your list is a Requirement Trace Matrix. I'll discuss different kinds of requirement lists in a little bit. For now we'll just agree on a very informal requirement list of unspecified format.
Collecting "shall" sentences is a simple and straightforward way to identify a basic list of requirements. For a more detailed list, you need to analyze the document more carefully. There is no set of rules to follow to identify further requirements that are supposed to be unique items. You should make an educated guess, plan ahead and imagine the future implementation, consult domain experts, and so forth. Wrong decisions (believe me, you'll make those at this point) can be corrected during later iterations. If you are in doubt, add a requirement to your list. It's easier to remove requirements or merge them together than to find requirements that were overlooked early on.
The result is a simple list that captures the most basic requirements and provides a rough overview of the whole system. Once this basic list is established, you can start to categorize and prioritize it. You can add headings in a Word document, or better, use attributes in a database. You might even combine the two using a tool like RequisitePro.
Once you organize your requirement list, take it back to the customer for a first review. He will either agree or disagree with the requirements you recorded. There should be no "maybes." If the customer hedges on a requirement, you should split it into multiple requirements to cover all the possibilities. You can keep the level of detail relatively low. Take notes about certain issues but leave the real description of each scenario for the use cases. (I describe those in the next chapter.) Focus on the current task! Remember that you're still collecting the requirements. You'll work out details of each requirement during later analysis.
After talking to the customer, you should revisit and correct the requirement list. Then go back to the customer with the new version to discuss it again. You should continue this loop until both parties are satisfied. When certain requirements are agreed on, you can start to analyze and work on the use cases, even if some requirements are still outstanding. If you wait until all the issues are resolved, you won't get to the next step. Keep in mind that requirements change, so only in rare cases will you have a requirement list with no unresolved issues.
There are two major differences between requirement lists and use cases. The first one is the level of detail. Use cases are far more detailed than requirement lists. The second difference is the way they are organized. Requirement lists are a very poorly organized list of typically independent items. Use cases combine requirements into scenarios. Also, use cases deal with the flow of events while requirements just capture the customer's needs from a business point of view.
Requirement lists
There are many varieties of requirement lists. They can be informal or follow strict standards.
I personally prefer to use advanced tools (as described next) to keep track of my requirements. However, every now and then I run across a consulting customer who wants to keep things simple by using regular Word documents, or something similar. In this case I create a Requirement Trace Matrix (RTM). An RTM is a regular Word table, just like this one:
| Entry # | Requirement |
| 1 | A schedule shall be maintained that monitors the movies displayed on each screen. |
| 2 | A reservation database shall be maintained. |
| 3 | Tickets shall be sold at the ticket counters as well as on the Internet. |
| 4 | The software shall allow automating events like turning lights on and off in each theater. |
| 5 | Only supervisors shall be allowed to update automated tasks. |
| 6 | A movie database shall be maintained. |
| 7 | The movie database shall allow retrieving additional information about movies from the Internet. |
| 8 | The schedule shall be based on the movie database. |
| 9 | Credit cards shall be accepted and verified online. |
These are some requirements I would specify for my movie theater example. Of course, there are more possibilities, but in this example I'll keep the list short for simplicity. This is the initial list. It's very basic and loosely organized. In the next iteration I will organize it a little better and classify each requirement:
| Entry # | Requirement | Type |
| 1 | A schedule shall be maintained that monitors the movies displayed on each screen. | SW |
| 1.1 | The schedule shall be based on the movie database. | SW |
| 2 | A reservation database shall be maintained. | SW |
| 3 | Ticket sales shall be monitored and organized. | SW |
| 3.1 | Tickets shall be sold at ticket counters and over the Internet. | SW,HW |
| 3.2 | Credit cards shall be accepted and verified online. | SW |
| 3.3.1 | The application shall continue to run while the credit card is processed, which usually takes a while. | SW,P |
| 4 | The software shall allow automating events like turning lights on and off in each theater. | SW,HW |
| 4.1 | Only supervisors shall be allowed to update automated tasks. | SW,SEC |
| 6 | A movie database shall be maintained. | SW |
| 6.1 | The movie database shall allow retrieving additional information about movies from the Internet. | SW,NTH |
This list shows more organization than the previous one because I defined sub-requirements. The requirement that the schedule should be based on the movie database is a sub-requirement of the one that defines my need for a schedule.
I also added requirement types, which will vary in every project. Make sure you document the requirement types you use. The codes in the above table are my basic set of types.
Here's what they stand for:
- SW = Software Requirement
- HW = Hardware Requirement
- P = Performance Requirement
- SEC = Security Requirement
- NTH = Nice To Have
In the next iteration I'll add even more detail and work on the requirements themselves (after talking to the customer). Since I don't have a customer around right now, I'll just assume the list above was fine, so I'll just add some more detail:
| Entry # | Requirement | Type | Importance |
| 1 | A schedule shall be maintained that monitors the movies displayed on each screen. | SW | High |
| 1.1 | The schedule shall be based on the movie database. | SW | Medium |
| 2 | A reservation database shall be maintained. | SW | High |
| 3 | Ticket sales shall be monitored and organized. | SW | High |
| 3.1 | Tickets shall be sold at ticket counters. | SW,HW | High |
| 3.2 | Tickets shall be sold over the Internet. | SW | Medium |
| 3.3 | Credit cards shall be accepted and verified online. | SW | Medium |
| 3.3.1 | The application shall continue to run while the credit card is processed, which usually takes a while. | SW,P | High |
| 4 | The software shall allow automating events like turning lights on and off in each theater. | SW,HW | Low |
| 4.1 | Only supervisors shall be allowed to update automated tasks. | SW,SEC | High |
| 6 | A movie database shall be maintained. | SW | High |
| 6.1 | The movie database shall allow retrieving additional information about movies from the Internet. | SW,NTH | Medium |
You can add as many columns as you want. I also like to add dependency information, which allows me to identify requirements that are based on other requirements but that aren't a sub-requirement of the current one. Here's how this would look:
| Entry # | Requirement | Type | Dependency |
| 1 | A schedule shall be maintained that monitors the movies displayed on each screen. | SW | 6 |
| 1.1 | The schedule shall be based on the movie database. | SW | 6 |
| 2 | A reservation database shall be maintained. | SW | |
| 3 | Ticket sales shall be monitored and organized. | SW | |
| 3.1 | Tickets shall be sold at ticket counters. | SW,HW | |
| 3.2 | Tickets shall be sold over the Internet. | SW | 3.3 |
| 3.3 | Credit cards shall be accepted and verified online. | SW | |
| 3.3.1 | The application shall continue to run while the credit card is processed, which usually takes a while. | SW,P | |
| 4 | The software shall allow automating events like turning lights on and off in each theater. | SW,HW | |
| 4.1 | Only supervisors shall be allowed to update automated tasks. | SW,SEC | |
| 6 | A movie database shall be maintained. | SW | |
| 6.1 | The movie database shall allow retrieving additional information about movies from the Internet. | SW,NTH |
In this scenario, requirement 1 depends on requirement 6. Without a movie database, the schedule couldn't be maintained. Requirement 1.1 specifies this in more detail. Of course it depends on the movie database as well. Requirement 3.2 heavily depends on requirement 3.3. Without validating credit cards online, it will be hard to sell tickets over the Web. In fact, requirement 3.3 could also be a sub-requirement of 3.2, but we don't know that at this point. Requirement 3.3 could also be needed in more places and therefore be a totally independent requirement after all.
Another idea I find very interesting is to apply a simple function-point or action-point (AP) analysis. This technique will allow you to estimate the amount of work the application will need. Doing a function-point analysis might not be possible at this time, since it's a complicated way to rate requirements and we're missing too many details. Whil Hentzen's action-point analysis (first introduced in his The 1997 Developer's Guide) seems to work a lot better. It is based on the same ideas as the function-point analysis but it is a lot simpler. The results are not as accurate but at this early stage we won't be able to get accurate results anyway. The later you are in the development cycle, the more accurate this analysis will be. All we want at this time is a rough overview. Here's the table that makes use of this technique:
| Entry # | Requirement | Type | Importance | AP |
| 1 | A schedule shall be maintained that monitors the movies displayed on each screen. | SW | High | 3 |
| 1.1 | The schedule shall be based on the movie database. | SW | Medium | 1 |
| 2 | A reservation database shall be maintained. | SW | High | 2 |
| 3 | Ticket sales shall be monitored and organized. | SW | High | 1 |
| 3.1 | Tickets shall be sold at ticket counters. | SW,HW | High | 2 |
| 3.2 | Tickets shall be sold over the Internet. | SW | Medium | 5 |
| 3.3 | Credit cards shall be accepted and verified online. | SW | Medium | 4 |
| 3.2.1 | The application shall continue to run while the credit card is processed, which usually takes a while. | SW,P | High | 5 |
| 4 | The software shall allow automating events like turning lights on and off in each theater. | SW,HW | Low | 4 |
| 4.1 | Only supervisors shall be allowed to update automated tasks. | SW,SEC | High | 2 |
| 6 | A movie database shall be maintained. | SW | High | 2 |
| 6.1 | The movie database shall allow retrieving additional information about movies from the Internet. | SW,NTH | Medium | 1 |
| 32 |
Action points monitor the complexity of each requirement. Based on statistics and experience, you can now rate the application. I assigned 32 action points in the table above. Let's say it takes me about one or two days to implement an equivalent of one action point. In this case it would take me about two months to finish the application described above. Based on these numbers, I could rate the application and make a serious offer to the customer. If you want to find out more about action-point analysis, read Whil Hentzen's Developer's Guide.
Once you are done with the requirements and move on to the use cases, you can add this information to the requirement list as well:
| Entry # | Requirement | Use Case |
| 1 | A schedule shall be maintained that monitors the movies displayed on each screen. | Display Schedule |
| 1.1 | The schedule shall be based on the movie database. | Display Schedule |
| 2 | A reservation database shall be maintained. | New Reservation |
| 3 | Ticket sales shall be monitored and organized. | Regular Ticket Sale |
| 3.1 | Tickets shall be sold at ticket counters. | Regular Ticket Sale |
| 3.2 | Tickets shall be sold over the Internet. | Web Ticket Sale |
| 3.3 | Credit cards shall be accepted and verified online. | Web Ticket Sale |
| 3.2.1 | The application shall continue to run while the credit card is processed, which usually takes a while. | Web Ticket Sale |
| 4 | The software shall allow automating events like turning lights on and off in each theater. | Schedule Tasks |
| 4.1 | Only supervisors shall be allowed to update automated tasks. | Schedule Tasks |
| 6 | A movie database shall be maintained. | Edit Movie |
| 6.1 | The movie database shall allow retrieving additional information about movies from the Internet. | Display Movie List |
This allows the developer to trace the requirements into the use cases. Whenever a requirement changes, it's relatively easy to trace those changes to the use cases. The use cases then have links to the object model, which has a link to the actual implementation. This is valuable information whenever requirements change, and as we've discussed, they change all the time.
EAN: 2147483647
Pages: 113