Project Management

The QRD (Qualifying Requirements Document)

From the Pro*Blog Blog
Covering all things Pro: problems, products, progress, projects, process, programs, professions, proposals, provisioning, and more! Analysis and commentary on yesterday and today, and prognostications, prophesies, and projections for the future.

About this Blog


Recent Posts

Agile versus Waterfall in Software Projects

Collective Knowledge

Last Responsible Moments

Donald Rumsfeld and Project Management

Kaizen or Kaikaku?

Every project needs requirements, and requirements need to be documented.  Many projects use a BRD, a Business Requirements Document.  Others use SRS, System Requirements Specification.  Some may use other document names, tools, and/or templates.  So what’s a QRD?

First, let’s make one thing clear - the QRD is just another name for a requirements document.   However, the QRD originates in a different manner than a typical requirements document, and that's why it has a different name.   The QRD is usually prepared by the project team, the people doing the work.   Let’s look at a few scenarios where a QRD might be appropriate. 

In some organizations, business users don’t have time to prepare a formal Requirements Document.  They gain support of upper management, who direct the PM or the PMO to do it.   At this point, you should consider a QRD.  Make sure to call it a QRD to distinguish it from the normal requirements building process.  

Many times, a QRD is based on a white-board JAD session with one or more key business folks, like a Product Owner or SME.   They might draw a process diagram, write down formulas, do high-level design, or even write pseudo-code.  Then, the representatives on the project team who attended the meeting use their meeting notes to prepare requirements, adding in other aspects to the project based on their expert knowledge.   Examples of expert knowledge include data management, infrastructure, technical specifications, security, compliance, legal, and other external interfaces and dependencies. 

The QRD is passed back to the business for their review and approval.  Like other requirements documents, this process could be iterative; the major difference is that the QRD is being driven by the Project Team (or PMO).  You need to be aware that the QRD may be automatically approved since the same people who say that they don’t have time to prepare the requirements document might also not have time to review the QRD.  Oh well, at least you'll have their sign-offs.  

However, if this project is important to the business, they should probably be able to find the time to review their requirements.   If a face-to-face meeting would have better acceptance, do the meeting instead of e-mailing a document.   If the origin of the QRD was a JAD session, then I recommend that the review of the QRD be done in a joint session as well.

In summary, a QRD is a different type of requirements document that is available to the PM and PMO.  The usual case is when the business doesn’t have time for a formal requirements gathering process, and ideas are strewn across a white board in a JRP or JAD session.   The Project Team or PMO prepares the QRD, which essentially says, “This is what we think you told us that you want” People with agile experience may relate to the QRD more easily than traditional project staff.  However, the QRD is not an agile process – it’s more like an ad-hoc process. 

Posted on: September 03, 2015 01:03 PM | Permalink

Comments (1)

Please login or join to subscribe to this item
I like and appreciate the idea of QRD as a different type of requirements document.

Please Login/Register to leave a comment.


"More than any time in history mankind faces a crossroads. One path leads to despair and utter hopelessness, the other to total extinction. Let us pray that we have the wisdom to choose correctly."

- Woody Allen