Requirement Documents, Oh the Inefficiencies!

Requirement Documents, Oh the Inefficiencies!

Requirements DocumentsI’ve written a fair number of requirement documents in my business analyst lifetime, and I’m still not sure what took longer – gathering and documenting the requirements, or trying to get the business to read and approve them.

Let me know if this sounds familiar…

You spend weeks, maybe months, eliciting requirements, reviewing requirements, and documenting requirements in a nicely formatted word document with the title Business Requirements Document (or something similar) slapped on the front. You are proud of the work you have done, the diagrams you have drawn, the requirements you have logically ordered and laid out for your stakeholders to read – and you’re sure that you have made it down right simple for anybody to just open it up and review it.

You happily click send on the email, sure that your stakeholders will read it and send back their input within the requested time frame—after all, who wants to risk the project deadline, right?

Problem is, usually stakeholders don’t have the time, or the space, to review a long—and let’s be honest—often boring, requirements document.  Your priority as the BA to get the requirements document reviewed and approved is unfortunately often not their priority—and it’s extremely hard to make it so. Or even when you do get their input, what you receive is often not as meaningful as you were hoping—I remember on more than one occasion receiving a requirements document back with fewer comments about the requirements themselves than about the spelling or grammar style I chose to write it in.

In today’s projects, where the dynamics of the solution is constantly shifting, the complexities increasing, and our stakeholders’ attention spans are ever so quickly decreasing (whose isn’t really?)—the inefficiencies of using a document to record, manage, review, and gain stakeholder approval for requirements needs to be questioned.

If it’s not, projects will continue to be negatively impacted by:

  • Incomplete and inaccurate sets of requirements
  • Delayed implementation schedules
  • Lack of stakeholder engagement
  • High levels of change requests during the test phase
  • Lack of user adoption once the solution is implemented
  • High levels of rework resulting from requirement misunderstandings 

And, I’m sure you can probably name a few more that affect you as well.

We need to start acknowledging, and managing, the fact that stakeholders simply don’t have the time, or the desire, to read the stodgy documents we tend to throw at them in projects. We also need to acknowledge that much like the projects we are working on, requirements also need to be able to easily adjust and pivot with the changing dynamics of a project landscape.  Business objectives can change, stakeholder needs can change, the market can change, the priorities of what we are building can change—and with those changes, the requirements need to change as well.

As business analysts, we need to be able to effectively manage them. Assessing change requests can be one of the largest challenges any project manager or business analyst faces on a project—and attempting to do it from within a large document, can make it all that much more worse. In fact, doing so poses a risk to the entire project.  How can you tell what the impact of a change request will be when the traceability and context of a requirement is spread confusingly throughout a document? Wouldn’t it be easier to just see all those impacts in one place? And really that is just one small example of how managing requirements within a document can be so inefficient.

So what’s the answer?

Well, at Enfocus Solutions, we think: enough with managing the documents, time to start focusing on managing the data instead.

To effectively manage requirements means that as business analysts, we need to stop spending our time on managing the document the requirements are in, and instead focus on managing the requirements themselves.

We need a better way to:

  • Review requirements with stakeholders and receive meaningful feedback to ensure the accuracy and completeness of their requirements as we move through the project.
  • Establish a visible and accessible location to document the requirements for a project.
  • Control the changes made to the requirements once initial approval has been achieved, and control the resulting versions of requirements that result.
  • Effectively communicate changes to requirements to the right stakeholders throughout the lifetime of a project.
  • Capture the context and traceability of the requirements we define—where they came from, why they are being developed, and what value they will ultimately deliver.

So what does managing data instead of documents look like?

Instead of documents, and the multiple versions that usually result…

Use a requirements management tool to establish your single source of documenting, reviewing, validating, and managing requirements throughout the lifetime of your project.

Instead of gathering stakeholder feedback in isolation of one another…

Establish transparency and generate conversation with and amongst your stakeholders using a tool that allows you to capture stakeholder comments and needs in one location on the requirements themselves, keeping the conversation visible and accessible to everyone else on the project.

Instead of validating and approving requirements all at once, after you’ve completed the document…

Validate and gain stakeholder approval as you go—eliminating the need for stakeholders to navigate their own way through a large requirements document, and enabling them to easily navigate their way to only the requirements that impact them.

Instead of limiting the participation of your project team by making them wait for a completed and approved requirements document….

Enable collaboration with them by providing visibility and access to the validated requirements as you go through the project. If you start to review with your stakeholders as you go, then developers and testers can start to work in parallel with you too. Keeping your team actively involved in the conversation from the start, is just as important as keeping your business stakeholders involved.

Instead of wanting to pull your hair out trying to manage changes to requirements after review and approval…

Manage the change requests through a defined process built into your requirements management tool, so you can easily assess the impact each change will make and control the changes that are included in each release.

And the list can really go on.

Documenting requirements is an important part of any successful project, but at the end of the day if we are spending our time and energy on managing the vehicle we are communicating them instead of the requirements themselves, there is a large risk that requirements will be overlooked, be incomplete, and ultimately not clearly define what it is the business needs to be successful.

Once the shift starts to move away from building and managing the documents that hold the requirements themselves, and more towards managing the data within them, then the opportunity for improved collaboration, requirements quality, requirements development, testing, and ultimately, project success is what results.


  1. Totally agree, it is a requirement for RDM (RE) tools: “item-orientation, not document-orientation” (

  2. How it is different from Agile where we focus on one part or story at a time.

  3. Actually, I am lucky because in my job, I write the requirement, ask for validation as I go ahead implimenting and developping through other team. Finally, i verify the requirement and process to complete the job.

  4. @Dusko, yes! We are focusing more and more on this concept of “idea management.”

    @Sumit, it’s not! We highly suggest implementing agile best practices. Agile goes nicely with managing data, not documents.

    @Bassem, sounds ideal!

  5. If the stakeholders don’t have time or find it boring to verify/validate the requirements, the problem is on a whole other level.

    There isn’t a tool that solves that problem for you. Although the problems you distinguish sound familair, the main problem lies in the acceptation of Requirements engineering as a tool for excecuting succesful business and IT projects. This article is a perfect example of a mismatch between the problem and the provided solution (using your tool).

    Instead of focussing on tools, focus on behavioural aspects of change management,commitment and engagement in general.

  6. @Joeri, I agree you can’t just focus on the tool. At Enfocus Solutions, we understand it takes a lot to actually get people involved. Managing data is just one aspect of the project out of many. A tool is not the magic solution, but it helps tremendously.

  7. Hi I agree with the problem that you describe, but a requirements management tool doesn’t solve this problem. Since the stakeholder doesn’t have a time to review the requirements and to want to spend a time to learn a new tool. The mangers want the designer will focus on the design and will not waste time on requirements management. I use requirements reviews to align with the stakeholders. These reviews can be done by personal meeting or within a group meeting. The requirements management tool is mainly use by system engineer and s.w. engineer. The main benefit for system engineer to use this tool is to perform impact analysis, creating reports that can indicate on which subsystem there are missing report, database for design system test and integration plan.

  8. I’ve been there myself and cannot agree more on how frustrating and pointless managing the requirement documents is.

  9. It works best in my experience when the Requirements Document (when required as a CDRL or at a milestone review) is seen as an organized output of the tool rather than the guidance artifact itself. It’s a snapshot of the requirements at their current baseline, but the official requirements are in the tool, not in Word or Excel.


Submit a Comment

Your email address will not be published. Required fields are marked *