How to Write Good Business Requirements

Write Better Requirements

Nearly "two-thirds of all IT projects fail" because of poor requirements.

This is one of the reasons why stakeholders, customers and interested parties argue over or fail to come to a consensus on the requirements or scope of a project.

In one project, requirements were being constantly rewritten, tossed out or reincorporated depending on who was in charge of the meeting.

In addition, time and budget overruns plagued the project because the parties could not agree on what each requirement really meant.

Finally, the implementation staff started resigning or asking to be transferred to other projects.

It is accurate to say that poorly written requirements can easily lead to budget or time overruns, unsatisfied stakeholders or customers and excessive staff turn-over.

As a business analyst, it is your duty to create good requirements and here are some guidelines for doing just that:

  1. Write Feasible Requirements

    Your requirement must be implementable considering the resources, capabilities, skills or knowledge available to your project. In other words, do a reality check and do not write down requirements that are impossible to achieve considering the time, money or resource pool available to your organization.

  2. Write Verifiable Business Requirements

    At the end of your project, you must be able to prove through testing, inspection, walk through or by demonstration that the requirements were implemented.

    One way to make a requirement verifiable is to rewrite or word it in such a way that you can actually test it or decompose it into smaller, more testable requirements.

  3. Write Traceable Requirements

    You must be able to follow or track all the changes in your requirements back to the original, current or final form.

    This will help you verify the origin of each requirement and ensure that they were not introduced by external parties in an unapproved fashion.

    It is even better to have a requirements traceability document that shows the originating customer, stakeholder or business need, the high-level business case or lower level system use case incorporating the requirement and the final product feature finally that meets the requirement.

  4. Write Consistent Requirements

    Have you ever participated in a meeting where you were given a business requirement that you felt contradicted another business requirement?

    That is what an inconsistent requirement looks like … a requirement that opposes, contradicts, invalidates or conflicts with another requirement making it difficult or downright impossible to achieve.

    So, here is the final word on this … don’t accept inconsistent requirements!

  5. Requirements Must Be Complete

    Each requirement that you write must be complete and comprehensive and it must not depend on another requirement to explain it or provide detailed information.

    That means that if you are still in the process of evaluating the full scope of a requirement with customers or stakeholders, you do not include it as a requirement until it is complete.

  6. Requirements Must Be Unambiguous

    Write each requirement in a way that removes doubt, confusion or misinterpretation.

    In other words, your requirements must be written in a style that leaves little doubt as to what is intended or meant.

    Each requirement must be clear and concise. It must not be vague and it should be read, understood or interpreted by every party the same way. Finally your requirements should be written in language that is free of technical jargon and in a language that the readers of the document understand.

  7. Requirements Must Be Necessary

    Include all the requirements that meet the previous rules on this post and in addition are required or mandatory for the system under observation to function as intended.

    So, a requirement is necessary when the lack or absence of it will be interpreted as a defect by stakeholders, project sponsors or customers.

To summarize this post, write business requirements that are: verifiable, clear, concise, complete, consistent, feasible and necessary.

What has been your experience when it comes to writing requirements or getting a consensus from interested parties as to what constitutes a requirement and what does not.

If You Enjoyed Reading This Post ... Subscribe To Business Analysts Boot Camp Newsletter ... It Is Free »

5 Responses to "How to Write Good Business Requirements"

  1. PRASANNA   January 11, 2012 at 12:04 PM

    I am working as a Quality Assurance (QA) Analyst and I will be promoted to a Business Analyst (B.A.) position in near future.

    But i am not good at writing skills and documentation skills and I want to improve ASAP.

    Can you help me on this?

    • HazelM   February 13, 2012 at 2:12 PM

      Have you ever had to give someone directions to where you live?

      Did the person get there or did they get lost?

      As a QA analyst, someone has written the test case and expected result ‘clearly’ for you. For example, an online test case could be worded something like this ‘on the New Applicant screen, enter the applicant’s name and address, then press the SUBMIT button.

      If there are no input errors, a confirmation message xxxx should appear, else the following error message yyy will be displayed.

      Start by documenting what you entered and the results from your testing. Use short sentences and imagine that a stranger on the street will be reading your documentation – could she understand what you meant to say?

      Another way to build up your documentation skills is to write out a recipie for boiling an egg or the procedures for washing a car. Do not miss a step in these procedures and you will be on your way to great documentation.

      • Business Analysts Training   April 3, 2012 at 8:53 AM


        Excellent advice as usual! Can you write a longer, more detailed article on “this topic” along the lines of “writing excellent test cases / results or user acceptance cases / results” from the business analyst perspective … just a longer version of what you wrote as a comment here.

        Our readers enjoy reading your post and find your advice helpful … so they want more 🙂

  2. Ravi   March 14, 2012 at 4:48 PM

    Hi Sir,

    Please Help me With this.. I have Completed Engineering in 2009..

    Presently i am Working as a Server Monitoring Engineer. But want to Pursue my Career as a Business Analyst.

    I Somewhere read about the online course.. Will it be helpful if i could take that.. Will this Experience of 2 Years count or do i have to Start from the Scratch as a fresher.

    What are the required Documents do we need to refer for this job if i dont have to do the Online Course … Please Suggest.. eagerly waiting for your Reply…

    • Business Analysts Training   April 3, 2012 at 8:25 AM

      Don’t Take The Documentation Approach To Business Analysis!

      1. Business Analysis is not about creating a document. If someone told you that or
        somehow you get that impression of business analysis, then I am sorry my friend,
        because you have seriously been misinformed.

        There is much more to business analysis than learning how to fill in a required
        document. Start from scratch and assume that you really have no idea what business
        analysis is … and you will be positioned to learn what is required to become a
        business analyst!

      2. There is no required course that will make you a business analyst but there are
        required skills, techniques, tools (not necessarily software tools) or roles & responsibilities
        that you can learn how to do or perform to become a business analyst.

        Don’t look for shortcuts, Business Analysis is a real “Body of Knowledge”, which
        means that you have a lot to learn if you want to become a successful business analyst.

        Imagine that you wanted to become an Engineer, would you start by saying something
        like: “Which Electrical Circuit Can I Repair or Which Type of Cat Engine Can I Repair
        To Become An Engineer?”

        That would be foolhardy right, because repairing a car’s engine or an electrical
        circuit does not make you an engineer because Engineers have first and foremost
        a body of knowledge and then a set of skills and finally experience in their designated

        Likewise business analysis … it has a body of knowledge and a set of skills and
        experience that is developed by putting business analysis skills and knowledge into

      3. What Software Do You Learn To Become A Business Analyst?

        This question is similar to those asked by people who start out on their quest to
        become a business analyst with words like: “What Software Do I Learn To Become A
        Business Analyst” …

        Just like their is no specific software or even a set of software programs that
        you can learn to become a business analyst, their is no specific document or set
        of documents that you can learn to become a business analyst.

        When you ask questions like: “What Software Do I Learn To Become A Business Analyst”,
        you stray off the path of business analysis into a domain reserved for Software

        Software Developers is one of those careers that is truly built upon knowledge of
        a specific Software or set of Software Programs.

        Likewise, when you ask questions like: “What Document Do I Learn To Become A Business
        Analyst”, you also stray off the path of business analysis into a domain reserved
        for “Technical Writers”!

        Technical Writers build their entire career on the knowledge of how to write specific
        documents. Questions like: “What Are The Required Documents That I Need To Learn
        To Become A Business Analyst”, define the mindset as that of a Technical Writer
        than a Business Analyst.

        So, first take the time to get the proper orientation of what a business analyst
        does and after that, you will be in a better position to become / succeed as a business


Leave a Reply

Your email address will not be published.