Having categorized and prioritized our requirements, we’re getting closer to building a development plan. However, there are a few things we still need to do. First, we need to review our existing requirements to determine if any depend on another. That is, we need to review each requirement and then consider if implementing it depends on some other requirement being completed first.

Consider the list of activities to the right that you might need to complete before you arrive in class. Assuming you have to complete all these activities, which would you logically do first?

Would it make sense to put on socks before showering or to put on your shoes before your socks? Does it matter if you put on a shirt before or after pants?

The reality is that some of these activities logically need to occur before others. You could probably develop several different logical timelines that would allow you to complete each in a way that makes sense.

In the same way, we need to consider each of our requirements and the logical order in which they need to be implemented. This will be a much bigger job than we’ve just done with our list of morning activities, but it is an essential step toward creating a development plan for our project.

To develop a list of dependencies, we need to have a good sense of our requirements and how each fits within the order of things. Sometimes it helps to draw by hand a requirements tree like the one on the following page (assuming you don’t have too many requirements). If you have a lot of requirements, however, it might make sense to use some flowchart software.

Referring to the requirements tree below, you can see that requirement 9 depends on requirement 7, which depends on requirement 4, which depends on requirement 2, which depends on requirement 1. This means the implementation of requirement 9 must be delayed until requirements 7, 4, 2, and 1 are done.

When does it make sense for a requirement to depend on another? A must can only depend on a must. A should can depend on a must or a should. A could can depend on a must, should, or could. A won’t can’t depend on anything. Why?

Of course, this requirements tree seems too good to be true, because as you travel from the top of the tree (requirement 1) to its base, the requirement numbers grow logically and satisfyingly (i.e., lower numbers at the top, larger numbers at the bottom). In reality, your current list of requirements won’t likely quite have this structure. For planning purposes, however, it will be necessary for you to build this structure into them.

How do we do this? We do this by renumbering our requirements so that those with no dependencies are listed first, and those with many dependencies are listed last.

Specifically:

1. Sort your requirements based on their categorizations, with musts followed by shoulds, then coulds, and finally won’ts.
2. Within each category, sort the requirements by their priorizations in ascending order (i.e. 10s first, then 20s, and so on).
3. Create a requirement ID for each requirement, numbering the first with 1, all the way to N (where N is the total number or requirements). Requirement ID 1 should be a must, with priority 10 and no dependencies. If this is not the case, you’ve likely done something wrong.
4. Review each requirement, and identify its primary set of dependencies. A primary dependency is the last requirement that needs to be completed before you can implement the current requirement you are reviewing. In the case of our requirements tree, the primary requirements are listed to the left of the page. Note that you can have more than one primary requirement (as is the case for requirement 9 which depends on both requirement 7 and requirement 5).
5. When step 4 is complete, you need to verify that the following rule (rule 1) is met:

If it is not met, you will need to carefully renumber the requirement IDs so that this is true. Why do we do this?

Our job, however, doesn’t end here. Since we want to ensure our requirements have a logical flow, we also need to review their categorizations and priorities.

Why do we do this? Let me answer your question with two questions.

• Does it make sense for a must requirement to depend on a should or a could requirement?
• Does it make sense for a priority 10 requirement to depend on a priority 50 requirement?

The answer to both of these questions is no. Can you explain why?

Dependencies And Categories

Categories provide us with a sense of understanding about what parts of the system’s functionality are most important to our client. If a must depends on a could (for example), it suggests that we haven’t understood the client’s needs.

Recall that musts are essential to the minimum viable product, while a could is “really nice to have”. If a must depends on a could, it suggests that something essential to the base functionality of the system can’t be implemented until after we build this nice-to-have piece of functionality. That doesn’t make sense.

The general rule (rule 2) is as follows:

To make better sense of this, review the tables below that illustrate whether or not one category can depend on another.

To read the table, fill in the blanks with the row heading and column heading to form a question. The intersection of that row and column will give you the answer.

You’ll notice that the won’t row is empty. Why is that?

Dependencies And Priorities

Similarly, we need to consider how our dependencies affect our prioritizations.

Recall that the priorities give an idea of what needs to be developed first, so it only makes sense that higher-priority requirements can’t depend on lower-priority requirements.

Again, we have a simple rule and a table that describes whether or not a requirement of a particular priority can depend on another prioritized requirement. The table is read in the same way, with row headings and column headings being used to fill in the blanks of the same question, and the cell at the intersection of the row and column providing the answer.

We read this table in the same way as the previous table. That is, we ask:

For example, a 40 cannot depend on a 50, but a 30 can depend on a 20.

However, what do we do if our prioritizations or categorizations don’t align with our dependencies? What do we do, for example, if we find a must requirement that depends on a should? Or if we find a priority 20 requirement that depends on a 50?

The answer is simple in theory, but sometimes cumbersome in practice. Specifically, we need to renumber our requirements to flow logically and satisfy rules 1 through 3.

Review Questions