Requirements Document – Types of Requirements Documents & What They Mean

Follow

Email

In my previous post I discussed different types of software requirements and how they are used. I covered five different types of requirements.

In this post, I will walk you through the different types of requirements document and what they mean.

Before I jump into it, I gotta tell you – there are numerous types of “requirements document” out there, we’re just going to cover the most popular ones in this post! Okay, let us get going…

Types of Requirements Document

The most common types of software requirements documents are the following. I’ve listed them in the order in which they’re usually created during a project:

1. Business requirements Document (BRD)
   • BRD outlines “Business Requirements” – i.e. high-level business goals of the organization building the product, or the customer who commissioned the project.
   • BRD is usually provided as a single page document containing high-level bullets.
2. Market Requirements Document (MRD)
   • MRD outlines “Market Requirements” – i.e. one-level deeper than BRs, but still at high-level. The focus is on market needs.
   • It is often also referred to as Marketing Requirements Document (notice the extra “ing”). But this is frowned upon by the “experts” and they will send Guido after you! Trust me, he is scary. 🙂
   • MRDs are usually provided as a prioritized bulleted list or table, and are usually less than 5 pages long.
3. Functional Requirements Document (FRD)
   • FRD outlines “Functional Requirements”, i.e. functionality of the software in detail.
   • Depending on the product being built, FRDs can be anywhere from ~10 pages to several hundred pages.
   • Even several thousand pages are not unheard of – for very complex, very long projects. Like the ones by the government and such.
4. Product Requirements Document (PRD)
   
   • PRD contains all the requirements for a “product” being built.
   • PRDs usually include the same content as FRDs – but also contain “Non-Functional Requirements” I discussed in my previous post on types of software requirements.
5. User Interface Requirements Document (UIRD), Interface Requirements Document
   • These documents outline the UI requirements for the software.
   • These usually contain mockups, wireframes, and even production-quality UI prototypes.
6. Technical Requirements Document (TRD), Design Requirements Document, Engineering Requirements Document, Development Requirements Document
   • The documents are written by engineering teams and contain technical requirements – such as design, architecture, etc – to achieve the requirements outlined in the documents outlined above.

The following are other popular types of requirements documents. These are not really new types of documents. Rather, they usually refer to one or more of the documents defined above – but in a specific context.

1. Software Requirements Document, Software Requirements Specification (SRS), System Requirements Document, Application Requirements Document
   • These terms usually refer to FRD or PRD for a specific software, system or IT project.
2. Project Requirements Document, IT Requirements Document
   
   • These terms usually refer to PRD – but for a specific project or IT initiative.
3. Customer Requirements Document, Client Requirements Document
   • These terms usually refer to PRD – but for a specific customer or client.

Who Writes Requirements Documents?

Now that we’ve covered different types of requirements documents – let us take a look at who writes these documents.

Okay, there you have it – all you ever wanted to know about the different types requirements documents. And then some!

FYI: Accompa Requirements Management Software can help you automatically create different types of requirements documents listed above. This can save you a lot of time compared to manually creating them. Check out product tour or request free trial.

Follow

Email

Michael Shrivathsan

I'm your author, Michael Shrivathsan, an expert in requirements management with successful experience at several innovative companies in Silicon Valley, USA over the past two decades. I'm also a USPTO patent recipient. For my day job, I'm the VP of Product Management at Accompa, we make the popular requirements management software.

More Posts - Twitter - LinkedIn