By this point, we have developed a list of requirements, categorized them using the MuSCoW Method, and assigned each a priority.

We are getting much closer to creating a development plan.

However, there is one important question we still need to answer:

What needs to be built before something else can be built?

Not every requirement can be implemented whenever we feel like it.

Some requirements naturally depend on others.

Understanding these relationships helps us build software in a logical order and prevents us from trying to implement functionality before the pieces it relies upon exist.

Thinking About Dependencies

Before thinking about software, consider your typical morning routine.

Imagine that your morning includes the following activities:

• Shower
• Wake up
• Put on shoes
• Go to school
• Brush your teeth
• Put on pants
• Put on a shirt
• Put on socks

Could you complete these activities in any order?

Probably not.

For example:

• Putting on your shoes before your socks would not make much sense.
• Showering after putting on clean clothes would probably not be your first choice.
• Going to school before getting dressed would likely create a different set of problems.

Some activities depend on others.

Other activities are independent.

For example, you could probably put on your shirt before your pants or your pants before your shirt without affecting the final outcome.

There is more than one logical sequence, but there are also many sequences that clearly do not work.

Software development is much the same.

Dependencies In Software

Requirements often depend on one another.

For example, consider these requirements:

• A user must be able to create an account.
• A user must be able to log into the system.
• A user must be able to edit their profile.

Can a user edit their profile before an account exists?

No.

Can they log in before creating an account?

Again, no.

The account must exist before either of the other requirements can be implemented meaningfully.

This relationship is called a dependency.

A dependency exists whenever one requirement cannot reasonably be implemented until another requirement has already been completed.

Identifying these relationships is one of the first steps toward building a realistic development plan.

Visualizing Dependencies

As projects become larger, dependencies become increasingly difficult to manage mentally.

One useful approach is to create a dependency diagram or requirements tree.

A requirements tree illustrates how different requirements relate to one another.

For example:

• Requirement 9 depends on Requirement 7.
• Requirement 7 depends on Requirement 4.
• Requirement 4 depends on Requirement 2.
• Requirement 2 depends on Requirement 1.

This means Requirement 9 cannot be implemented until Requirements 7, 4, 2, and 1 have all been completed.

Sometimes a requirement depends on more than one previous requirement.

For example, a reporting feature may require both user authentication and data collection to exist before it can be implemented.

The purpose of a dependency diagram is not simply to draw arrows.

Its purpose is to help the team understand the logical structure of the system they are building.

To help you visualize your requirements, you may want to use a hierarchical chart to create a dependency diagram. Check out the video below to learn how you can do this.

Renumbering Requirements

Once dependencies have been identified, we need to organize our requirements into a logical development order.

Our original requirement numbers may simply reflect the order in which ideas were discussed with the client.

That order is rarely the best order for implementation.

Instead, we renumber the requirements so that:

• Requirements with no dependencies appear first.
• Requirements that depend on earlier work appear later.

After renumbering, the requirement IDs themselves communicate something about the development sequence.

This makes later planning activities much easier.

A Suggested Process

A practical approach is to follow these steps:

Step 1

Sort requirements by category:

• Must
• Should
• Could
• Won’t

Step 2

Within each category, sort requirements by priority:

• 10
• 20
• 30
• 40
• 50

Step 3

Assign new requirement IDs beginning with 1.

Ideally, Requirement 1 should:

• Be a Must requirement;
• Have a priority of 10; and
• Have no dependencies.

If this is not possible, it often indicates that something needs to be reconsidered.

Step 4

Review each requirement and identify its primary dependencies.

A primary dependency is the last requirement that must be completed before the current requirement can begin.

A requirement may have multiple primary dependencies.

Step 5

Verify that your numbering satisfies the dependency rules described below.

If not, adjust the numbering until it does.

Rule 1: Dependencies Must Flow Forward

The first rule is straightforward.

Rule 1: If Requirement X depends on Requirement Y, then the requirement ID of X must be greater than the requirement ID of Y.

In other words, later requirements may depend on earlier requirements.

Earlier requirements cannot depend on later ones.

This ensures that the numbering reflects a logical development sequence.

Rule 2: Categories Must Flow Logically

Dependencies must also respect the MuSCoW categories.

Consider the following question:

Should a Must requirement depend on a Could requirement?

The answer is no.

Remember:

• Must requirements define the minimum viable product.
• Could requirements describe optional enhancements.

If an essential requirement depends on optional functionality, then the optional functionality is not really optional.

Instead, it should probably be classified as a Must requirement.

This leads to our second rule.

Rule 2: Requirement X cannot depend on Requirement Y if the category of X is more important than the category of Y.

In practice, this means:

• Must requirements may depend only on Must requirements.
• Should requirements may depend on Must or Should requirements.
• Could requirements may depend on Must, Should, or Could requirements.
• Won’t requirements should not have dependencies because they are outside the scope of the project and will not be implemented.

Whenever this rule is violated, it usually suggests that one or more requirements have been categorized incorrectly.

Rule 3: Priorities Must Flow Logically

Dependencies must also respect priority.

Ask yourself:

Should a Priority 10 requirement depend on a Priority 50 requirement?

Again, the answer is no.

Priority indicates the relative order in which work should occur.

If a high-priority requirement depends on a low-priority requirement, then the priorities no longer make sense.

This leads to our final rule.

Rule 3: Requirement X cannot depend on Requirement Y if the priority of X is higher than the priority of Y.

In practice:

• Priority 10 requirements may depend only on other Priority 10 requirements.
• Priority 20 requirements may depend on Priority 10 or 20 requirements.
• Priority 30 requirements may depend on Priority 10, 20, or 30 requirements.
• Priority 40 requirements may depend on Priority 10, 20, 30, or 40 requirements.
• Priority 50 requirements may depend on any priority.

This creates a logical flow from higher-priority work toward lower-priority work.

When The Rules Don’t Work

As you review your requirements, you will almost certainly discover situations where one or more of these rules is violated.

Perhaps:

• A Must depends on a Should.
• A Priority 20 requirement depends on a Priority 50 requirement.
• A requirement depends on one that appears later in the list.

This is completely normal.

Identifying these issues is one of the reasons we perform dependency analysis.

When a rule is violated, it usually means one of three things:

• A requirement has been categorized incorrectly.
• A requirement has been prioritized incorrectly.
• The requirements need to be renumbered.

Resolving these issues creates a cleaner, more logical development plan.

Looking Ahead

Once dependencies have been identified and the requirements have been organized into a logical order, we are finally ready to begin planning development.

In the next chapter, we will use these dependencies, along with our priorities and time estimates, to build a realistic project timeline.

By this stage, our requirements have evolved from a simple list of ideas into a structured roadmap that guides the development of the entire system.