What Is a Requirement?

Every experienced BA has his or her own understanding of what a “requirement” looks like, but the profession does not have a shared understanding. According to the International Institute of Business Analysis (IIBA™) Guide to the Business Analysis Body of Knowledge® (BABOK®), Version 2.0 Draft 2008:

A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective.

Another way to define a requirement is anything that is important enough to discuss, analyze, document, and validate. A requirement can be documented and presented as:

• A sentence (“The system shall . . .”)

• A structured sentence (as in a business rule)

• A structured text template

• A table or spreadsheet (list of stakeholders)

• A diagram (workflow)

• A model (entity relationship diagram with associated details)

• A prototype or simulation

• A graph

• Any number of other formats

The format or representation does not qualify something as a requirement; it is the intent and the stakeholder need that make it a requirement. There is debate among BAs about what qualifies as a requirement. Is a screen layout a requirement? Is a business rule a requirement? Is a test case a requirement? The business analysis profession should broaden the term requirement to include everything that BAs produce to communicate with their stakeholders to accomplish the completion of a product. Make sure that your organization, or at least your team, agrees on the definition of requirement.

BAs often create diagrams, notes, spreadsheets, scribbles, etc. that they use to analyze and think through a particular problem. These “work products” may not be presented to stakeholders, but they assist the BA in his or her work. They are analysis tools that help the analyst understand the requirements.

Categorizing Requirements

Most BAs agree that requirements need to be categorized. Categories are needed because when requirements are correct and complete, they are usually very detailed.

Most projects include a large number of these detailed requirements. When there are a large number of “things” to keep track of, organizing these “things” into logical categories allows them to be found easily and used quickly.

Case in Point

Think about how people keep track of books: fiction, non-fiction, biography, children’s, etc. When we walk into a bookstore or library looking for a particular book, the categories help us find the book for which we are searching. Some books are very easy to categorize. For example, biographies are shelved in alphabetical order by the subject of the biography (e.g., biographies about Thomas Jefferson are shelved under J). Other books are more difficult to categorize. Where would a book on World War II be shelved? It could be in history, historical fiction, biography, sociology, or American studies. Categorizing requirements presents this same challenge. Deciding on categories and placing specific requirements into these categories is as much an art as it is a science. Each person who looks at a requirement may categorize it in a different way. There may be more than one category that is applicable to a particular requirement.

Over the years of book publishing, some general guidelines have been developed for categorizing books. Libraries in the United States use the Dewey Decimal Classification^® system. Many bookstores generally follow these guidelines but make changes as appropriate for their customers, publishers, authors, and employees. Having general guidelines makes the search for books much easier.

If you owned a bookstore, even a small one, how would you categorize books? Would you use a system that makes sense to your employees, so that they could quickly shelve new stock as it arrives? Would you use a system that makes sense to your customers, so that they can quickly find the books they want? Would you use the Dewey Decimal System? What if a new book is published that doesn’t belong in any of your categories? Would you create a new category? Would you reorganize all of your categories once a month? Once a year? Never? Develop a consistent approach to categorization and communicate it to all of the stakeholders.