Types of software requirements

If you work as a Business Analyst, you know that understanding software requirements is an important part of your job. One thing to understand about software requirements is that there are many different types of requirements, and understanding those differences can help you write better software requirements specifications.

Two of my favorite documents related to the process of gathering software requirements are (a) the IIBA Business Analyst Body of Knowledge and (b) the book Mastering the Requirements Process by Robertson and Robertson. Both of those documents break software requirements down into several categories, and I'll share those categories here.

Types of software requirements

In short, software requirements are typically broken down into two major categories:

1. Functional requirements
2. Non-functional requirements

Non-functional software requirements are then broken down into several sub-categories, like this:

1. Reliability
2. Performance
3. Look and Feel
4. Operational (or Operability)
5. Security
6. Compatibility
7. Maintainability
8. Transferability

Functional requirements describe the behavior and capabilities of a software system, and the information the system will manage. Functional requirements are typically described in a series of "the system will" or "the system shall" statements.

Non-functional requirements are all the other requirements that don't describe the behavior of the system, but are still important. For instance, a Look and Feel requirement might state that "The system shall use the corporate colors and logo", or something similar (hopefully a little more detailed than that). A Performance requirement might state that "The system shall handle a simulated user load of 1,000 users", and so on.

Functional and non-functional requirements

I can write more about functional and non-functional requirements if people are interested, but at this point I thought I'd just share these categories of software requirements. I highly recommend breaking your software requirements specifications down into these categories, because it will help organize your thinking, as well as the thinking of the project sponsors and domain experts you'll be working with.

For more information on my software requirements services, please see my Boulder, Colorado Business Analyst consultant page.