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 of them 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 of these activities, which would you logically do first?

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

The reality is that some of these activities logically need to occur before others. In fact, you could probably develop several different logical timelines that would allow you to complete each of these activities 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 what 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 really good sense of all of our requirements and how each one 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 on the next page, 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 that implementation of requirement 8 must be delayed until requirements 7, 4, 2, and 1 are done.

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 in size in a very logical and satisfying manner. In reality, it’s very likely that your list of requirements won’t quite have this structure. For planning purposes, however, it’s going to 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 of the categories, 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 make sure that 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 those requirements that are absolutely essential to the minimum viable product, and a could is really nice to have. If a must depends on a could, it suggests that something that is 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, simply fill in the blanks with the row heading and the 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 provide us with 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 manner, with the 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 our categorizations don’t align with our dependencies? That is, what do we do 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 so that they flow logically and satisfy rules 1 through 3.

Review Questions