Developing a System for Organizing Requirements

There are many factors to consider when designing a requirements categorization system. You must balance these factors to create the best system for your organization. Understanding why you are documenting requirements will help you decide how to best categorize them. Think about the following questions:

Should requirements be separated by type? Business vs. functional? This is a great question and one that initially seems very obvious. The business requirements (business needs that are independent of technology) may be listed separately from functional requirements (behaviors of software), but for some requirements components this results in repeated information (i.e., description of a piece of business data listed in the data model and with screens where it is used).

In what order will the requirements be gathered? This is the least useful approach to organizing requirements even though it may initially appear to be the easiest. Unfortunately, requirements are often not elicited or gathered in a logical order. Business stake-holders don’t always talk about their needs in a straightforward, linear fashion. In addition, the iterative nature of requirements development means that the BA will often be presented with unrelated requirements and then have to figure out where to “put” them. Imagine if a publisher delivered a large box of books to your bookstore that were not in any particular order. Simply placing them on the shelf as they come in will not be useful when a customer is looking for a particular book.

Who will review each requirement? A BA’s most important job is to clearly communicate with stakeholders. Often, several stakeholders will be reviewing the requirements document and it would be most efficient for the BA to present the requirements in an order that will make reviewing as easy as possible. Is a stakeholder from accounts payable who only needs to review a few key financial requirements required to read the entire package and search only for the items in which he or she is interested? On the other hand, do many of the requirements that affect accounts payable also affect other stakeholders?

How is each requirement used? This consideration is important when the requirements relate to software development. Most developers are not anxious to read volumes of business requirements. They want to know exactly what you want the software to do. They also prefer the requirements to be separated by the technology needed. For example: put all data elements together to assist the database designer, or list all users together to make the security access design easier (see the section on core requirements components later in this chapter). Are the developers on-site or offshore? How often will you be communicating with them? These factors will also play into your decision.

How are the requirements related to each other? Tracing requirements to each other is a very important technique to ensure completeness and decrease change management time. There are very few requirements that are not related to at least one other requirement. These relationships between requirements make their presentation more complex. This aspect of requirements argues for a unique name or number for every requirement.

These unique identifiers are invaluable for tracing (see the section on traceability matrices later in this chapter). This is one of the many areas where a requirements management tool is very beneficial.

Should the same requirement be presented in different ways for different stakeholders? Ideally, the answer to this question is no. It is not efficient to repackage the same information in multiple ways. However, a BA’s most important job is to clearly communicate with stakeholders. If a requirement is clear to one stakeholder in a graphical format and clear to another stakeholder in a sentence, then it may have to be presented in multiple versions. If this is necessary (make sure that it is absolutely necessary), then both versions must be kept up to date when there are changes.

Which requirements are reusable? Many requirements are reusable on future projects, and it may be helpful to document them together. Business requirements that are technology independent can be reused on future projects and as such should be kept together in a format that allows other analysts to access them. Data requirements are reusable and most easily referenced when they are documented in the same format, in the same place. This is another area where a requirements management tool is very helpful.

If your organization does not have a consistent categorization schema—implement one. Create one, try it, and revise as you learn. Any system is better than none. Most projects have a large enough number of requirements to justify categorizing them into groups. These groupings make the requirements easier to document, double check, and review.