For the rest of this chapter, we are going to focus our energies on developing a list of specific requirements that describe the problem we are trying to solve. You should recall that a requirement describes one thing the software does (either functional or non-functional), but not how it does it. But is that all there is to develop a set of good requirements?

Clearly, the answer is no.

Preliminary Documentation

Since requirements allow us to communicate the needs of each of the actors associated with a system, it becomes very important that we 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.
It’s important to go through this process, however, because it helps us better understand the system we need to build. It also allows us to better relate with our client and to the users of the system because we use their language. Further, by using their language, we build rapport and trust, and we allow the client and users to see themselves in the system we are developing; to feel as if they are part of the design process.

Why might we want the user or client to feel as if 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 each and every one of them to ensure that they describe our system completely, and in such a way that we will be able to 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 amount of time it would take one developer 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. In fact, interacting with the client on a regular basis will prove beneficial in the long run, because it will allow us to identify any issues with our understanding of the problem prior to implementing anything.

Review Questions