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 does (functional or non-functional), but not how it does it. But is that all there is to develop a set of good requirements?

The answer is no.

Preliminary Documentation

Since requirements allow us to communicate the needs of each of the actors associated with a system, we must ensure any requirements we develop are clear, concise, and free of ambiguity. This means that we may need to create preliminary documentation for our set of requirements that define:

• each of the actors, with specific attention paid to any external systems that our system may need to interact with (and the assumptions we are making about said systems), and to each of the different user types (e.g. administrator, basic account holder) and their system permissions,
• any non-standard terms, and
• any user, client, or domain-specific terms that are necessary to describe a requirement.

Don’t worry if you don’t have perfect definitions when you first begin the process of developing requirements; you can always work with the client or users to clarify these definitions.

Further, don’t worry if you haven’t included all of the non-standard or user/client-specific terms. As you build your requirements, you can grow this preliminary list of definitions. This process is important because it helps us better understand the system. It also allows us to better relate with our clients and users because we use their language. Further, by using their language, we build rapport and trust, allowing the client and users to see themselves in the system we are developing; and to feel they are part of the design process.

Why might we want the user or client to feel they are part of the design process?

Putting Requirements To Use

Of course, creating a list of requirements is only part of our job. To put requirements to use for us, we need to critically evaluate every one of them to ensure that they describe our system completely, and in such a way that we can build it in an organized, logical manner.

We will do this in a series of stages. Each stage is identified below and will be described in further detail in subsequent sections.

• Stage 1: Ensure that each requirement is specific and measurable.
• Stage 2: Work with our client or users to determine the relative level of importance of each of the requirements.
• Stage 3: Prioritize each of the requirements.
• Stage 4: Identify any dependencies that might exist.
• Stage 5: Estimate the time one developer would need to implement each requirement.

This clearly will take time and a great deal of patience. It also will require interaction with the client to verify that we understand the problem as they have described it to us. Interacting with the client regularly will prove beneficial in the long run, because it will allow us to identify any issues with our understanding of the problem before implementing anything.

Review Questions