Developing Good Requirements

For the rest of this chapter, we will focus on developing a list of specific requirements that describe the problem we are trying to solve.

Recall that a requirement describes one thing the software must do or one condition the software must satisfy. Requirements may be functional or non-functional, but they should describe what is needed rather than how it should be built.

However, writing a good list of requirements requires more than simply writing down features.

A strong set of requirements should be clear, organized, measurable, and grounded in the language and needs of the people connected to the system.

Before Writing Requirements

Because requirements help us communicate what a system needs to do, they must be easy to understand.

This means we need to avoid vague language, unclear assumptions, and words that may mean different things to different people.

Before developing a full list of requirements, it can be helpful to create some preliminary documentation.

This may include:

• A list of actors who will interact with the system;
• A description of each user type and their permissions;
• Any external systems the software may need to interact with;
• Assumptions being made about those external systems;
• Definitions of non-standard terms; and
• Definitions of client-specific, user-specific, or domain-specific language.

For example, the word “member” may mean one thing to a community organization and something different to a gym, library, or professional association. Similarly, words like “case,” “record,” “client,” “participant,” or “service” may have specific meanings depending on the organization.

If we do not define these terms clearly, we may misunderstand the problem.

Learning the Client’s Language

You do not need perfect definitions at the beginning of a project.

In fact, you probably will not have them.

Requirements are developed through conversation, clarification, and revision. As you work with a client or users, your understanding of the problem will improve. You may discover new terms, refine old definitions, or realize that different users use the same word in different ways.

This is normal.

Building a shared vocabulary is part of the design process.

Using the client’s language matters because it helps us understand the problem from their perspective. It also helps build trust. When clients and users see their own words reflected in the design process, they are more likely to feel heard, respected, and included.

This is especially important in community-engaged software design.

We are not simply building software for people.

We are learning how to design software with them.

Why Shared Understanding Matters

A list of requirements is only useful if everyone understands what the requirements mean.

Consider the requirement:

The system must allow staff to update client records.

At first glance, this may seem clear.

But several questions remain:

• Who counts as staff?
• What is a client record?
• What parts of the record can be updated?
• Are some fields restricted?
• Should updates be tracked?
• Can records be deleted?
• Who is allowed to see the changes?

Without shared definitions, a requirement that appears simple may hide several important design decisions.

This is why preliminary documentation is not extra work. It is part of understanding the problem.

Putting Requirements to Use

Once we have a draft list of requirements, our work is not finished.

We need to evaluate each requirement carefully to determine whether it is useful, clear, and ready to guide design and development.

In CIS3750, we will do this through several stages.

Stage 1: Make Each Requirement Specific and Measurable

A requirement should describe one thing the system must do or satisfy.

It should be specific enough that another person can understand what is expected. It should also be measurable enough that the team can determine whether the requirement has been met.

A vague requirement such as:

The system should be easy to use.

may express an important goal, but it is difficult to test.

A stronger version might describe what “easy to use” means in context. For example:

A first-time user should be able to submit a volunteer application without assistance.

This version is more specific and easier to evaluate.

Stage 2: Determine Relative Importance

Not every requirement has the same level of importance.

Some requirements are essential. Without them, the system cannot solve the problem.

Others may be helpful but less urgent.

Determining importance usually requires discussion with the client or users. As designers, we may have opinions about what matters, but the client and users often have knowledge that we do not.

This stage helps ensure that the team focuses attention on the most important needs first.

Stage 3: Prioritize Requirements

After discussing importance, we need to organize requirements into a useful priority structure.

Prioritization helps teams make decisions when time, resources, or technical capacity are limited.

In this course, we will use prioritization to help decide what must be completed first, what should be completed next, and what may need to be delayed or excluded.

Good prioritization makes development more realistic.

It also helps teams communicate honestly with clients about what can be delivered.

Stage 4: Identify Dependencies

Some requirements depend on others.

For example, a user cannot reset a password if the system does not already support account creation. A report cannot summarize data if the system does not first collect that data.

Identifying dependencies helps us understand the logical order in which requirements should be addressed.

This stage is especially important when planning development work. A requirement may be highly important, but it may not be possible to complete it until another requirement has been finished.

Stage 5: Estimate Development Time

Finally, we need to estimate how long each requirement may take to implement.

In CIS3750, we will estimate the amount of time one developer would need to complete each requirement.

These estimates will not be perfect.

That is okay.

The purpose is not to predict the future with complete accuracy. The purpose is to support planning, identify overly large requirements, and help the team understand whether the proposed scope is realistic.

If a requirement seems too large to estimate, it may need to be broken into smaller requirements.

Requirements Improve Through Revision

Developing good requirements takes time, patience, and repeated conversation.

Your first draft will not be perfect.

You may discover missing details. You may realize that two requirements overlap. You may find that one requirement is actually several requirements combined. You may learn that the client uses a term differently than you expected.

This is part of the process.

The goal is not to produce a perfect list immediately.

The goal is to improve the list over time so that it more accurately reflects the problem, the people involved, and the system that needs to be designed.

Regular communication with the client is essential. It allows misunderstandings to be identified early, before significant time is spent building the wrong thing.

In software design, correcting a misunderstanding during requirements development is far easier than correcting it after implementation.

Good requirements help teams move from uncertainty toward clarity.

They do not eliminate every challenge, but they give us a stronger foundation for thoughtful, organized, and responsible design.