In my last two posts I covered What are software requirements and the Why and who of requirements.
Did you know there are many different types of software requirements? Okay, you probably did! In this post, I’ll walk you through the most common types of software requirements.
Ready to get rolling?
Different Types of Software Requirements
The most common types of software requirements are:
- Business Requirements (BR)
- These are high-level business goals of the organization building the product, or the customer who commissioned the project.
- These are usually provided as a single page of high-level bullets.
- Market Requirements (MR)
- These drill down into BRs, but still are high-level. In addition to business goals, they also outline market needs.
- These are usually provided as a prioritized bulleted list or table, and are usually less than 5 pages long.
- Functional Requirements (FR) – Use Cases
- These cover the functionality of the product in detail. Use cases are one of the best ways of documenting functional requirements.
- Depending on the product being built, FRs can run several hundred pages.
- Non-Functional Requirements (NFR)
- These are not related to the “functionality” of the product – but cover goals such as Reliability, Scalability, Security, Integration, etc.
- Many projects make the mistake of not specifying these explicitly.
- UI Requirements (UIR)
- User interface specs are not considered “requirements” in traditional requirements management theory.
- Phooey! In my opinion, UI specs are indeed requirements (what else are they?) – and in fact should be considered an integral part of requirements for any software that has a UI.
Hey, What Are “Features” Then?
As you can see, the list above does not include a popular term that is frequently used in software projects: Features. Wondering why? The reason is simple…
A “Feature” is just a group of functional requirements (FRs) that together meet a specific customer need.
There you have it – all the different types of software requirements that are fit to print! In my next post, I’ll cover the topic of Requirements Documents. Until then…
