How To Document Business Requirements

What is requirements documenting?

Requirements documenting is a process of writing requirements which are officially adopted by corresponding stakeholders. It is used as the formalisation and confirmation for entering realisation phase and their operating in the real-world environment. Requirements documentation describes a need for a new business initiative, activity, change or project for go live stage where the requested outcome in form of a product, process, service or event must be accomplished. There are documented different types of requirements such as business requirements, system requirements, product requirements, etc. In this article, we will focus on documenting business requirements in projects.

Spoken vs. written requirements

New requirements occur in everyday business. Requirements can start off informally, as only verbally expressed desires or needs, becoming a part of discussion in various business occasions as in the meetings or the workshops. Oral requirements are not the ones that should be formally relied on in the business since they neither represent a true commitment for the business or responsible persons, nor contribute to the structure and traceability of the actions taken. Requirements need to be put in a proper written form, however, not in a form of a sticky note or remark in a notepad, but into an appropriate document with all necessary sections within. In the beginning, stakeholders may not be yet clear about what exactly they need. There can also happen that there is no applicable ground for requirements implementation, or the requirements are inadequately formulated. Some requirements can always stay in a “wishful thinking” stage. To reduce such situations, it is necessary to structure and document them properly, and to give them a formal note through the approval by the responsible parties. In this article we will describe why is necessary to properly document high-level requirements, what business requirement specification consists of and will give some guidelines on what to pay attention in requirements documenting.

Why are properly documented requirements needed?

Documented requirements represent a formal obligation for the involved parties. Properly written requirement is a basis for the requirement realisation describing, among others, all necessary tasks to be executed including the roles involved and constraints for their implementation. They give the information about as-is state and describe to-be state or solution which needs to be fulfilled. Requirements documents serve as a control point in the project and need to be regularly reviewed and checked against the set criteria before they are sent out for their approval for implementation, particularly regarding their contents and quality.

From requirement analysis to requirement documenting

After the requirements have been elicited, their refinement comes in place, usually consisting of:

1. Removal of unnecessary or non-feasible requirements
2. Detecting a need for adding more requirements to the scope
3. Requirements grouping and prioritisation according to, e.g. their importance and risk - such as Kano analysis or MoSCoW technique depicting what must, should, can, or would be done.

In the requirements “refinement” phase, requirements are analysed before entering formal documenting and approval phase. These tasks are usually executed by Business Analyst who supports the project through regular recording and updates on the requirement status, tasks, issues, managing change requests, etc.

Roles in documenting requirements

In requirements documenting, there is central role of Business Analyst as well as of Project Manager. Other roles which collaborate in the documenting are usually the project core team members, subject matter experts that are internal or external to the organisation, customers, business partners, etc. Decision about who will be involved in the documenting depends on, for example - requirement type, business decision and the organisational practice.

When to begin with requirements documenting?

Documenting requirements begins from the requirements initiation phase, where the basic information about the requirement are collected; such as the name and short description of the requirement, who are the involved stakeholders, etc. The information about the business need is collected from the parties which have a relevant stake in it, such as internal requestors within different company departments as IT, legal, marketing, operations, or external, such as customers and end-users or consumers. Business need may be expressed in a form of a “raw” requirement which will be gradually elaborated into a clear and workable requirement.

Types of Requirement Documents

For requirements documenting, there are usually used templates which contain the sections that must be covered within. Generally, business requirements are documented into a document widely-known as Business Requirements Document (BRD). If requirements are already known and agreed before beginning with the project, they can be already stated in the project statement document. Here are listed some of requirements documents which are created within a project:

1. Business Requirements Document (BRD)
2. Functional Requirements Document (FRD) as a stand-alone document, or a part of the BRD
3. Use Case Document
4. Stakeholder Analysis Document
5. Gap Analysis Document
6. Requirements Checklist
7. Test Plans and Test Cases such as User Acceptance Test (UAT)
8. Requirements Traceability Grid

Difference between Business (high-level) and Functional (low-level) Requirements

In this article, we will focus on high-level requirements (business requirements). Let us now give a short comparison between business requirements and functional requirements (low-level requirements). We can say that:

1. Business requirements (high-level) - which are described in the BRD usually respond to the question “What is required?” They deal mainly with the business and quality goals and expectations from the stakeholders and represent the support for functional requirements.

2. Functional requirements (low-level) need to respond the question “How exactly the requirement implementation must be done?” They outline technical perspective of the business requirements describing the systems and functionalities to be developed or changed and need to correspond the expectancy described in the BRD. They are stated either in a stand-alone document called Functional Requirements Document (FRD) or can be embedded into the BRD as a separate section or an addendum.

Requirements may begin at a high-level and become more low-level when more information is known. BRD is usually created by Business Analyst but can also be created by Project Manager.

The key structure of the Business Requirement Document

Since the Business Requirements Document is a formal agreement between the stakeholders for a specific product, service or process, it represents one of the most important deliverables on the project. BRD template can be tailored per case basis and along with the narrative description, addition of models and diagrams is of a great value for a better understanding. The extent of one BRD document depends on the subject matter or requirement type and it may range from a several pages to several hundred pages documents. There can be created a number of different BRDs within one project. Usually, one BRD document covers a group of requirements within one specific subject or department and it is usually listed as a project work item. BRD can be internally oriented; for requirements within the organisation, or externally, e.g. to be created between the organisation and its customer. Requirements documenting is a continuous process implemented throughout the project. The person who documents requirements, needs to be up-to-date with any amendments occurring and keep an eye on factors triggering and affecting them. General overview of the sections in the BRD is described in a graphic below:

In a nutshell, BRD must be able to answer the questions such as:

1. What is the current state?
2. What is the expected future state?
3. Why is the requirement needed?
4. Who must do it?
5. How it must be done?

Some examples of poor practices in requirements documenting

Here are listed some inappropriate practices that can happen in requirements documenting:

1. Requirements in BRD are documented in a vague way and it is not clear what must be done in practice nor what are the surrounding factors that inevitably affect its implementation.
2. Requirement document is too short or too long – BRD is over-documented or under-documented
3. There can happen that stakeholders are not informed about the agreed requirements, have not received the documentation or are not able to get hold of it.

Guidelines for documenting requirements in a good way

Appropriate requirement document layout:

1. Make sure that requirement document layout contains all necessary sections and portrays the requirements adequately
2. Apply BRD template where possible and tailor it to fit a specific purpose
3. Use proper versioning of the BRD document

Precise and clear requirement text:

1. Use short and unambiguous paragraphs and sentences with avoidance of using passive voice. Be straight to the point and avoid vagueness.
2. Use appropriate formatting - insert bullet points and numbering for groupings and listings. When using acronyms or synonyms, explain them in an appropriate section.

Reasonable extent of the documentation:

1. Do not over-document or under-document business requirement document
2. Pay attention to possible scope creep if additional requirements must be added

Use of model language and visual descriptions:

1. For better understanding, do not hesitate to insert a graphic element such as some type of UML diagram (activity diagram, use case diagram, etc.) That can assist especially when read by persons who are not experts in the requirement field.

Documentation transparency and traceability:

1. Write the requirements from the perspective of the persons or organisation whose expectations must be met
2. Establish traceability between different requirements documents and between them and other connected documents.

Regular review, availability and maintenance:

1. Regularly review requirements documents; alone or with a team who will implement the change such as for example - IT department or end-user representatives.
2. Keep the requirement documentation in a structured way – store it in an appropriate repository available to all stakeholders and keep it up-to date on a regular basis.

Conclusion

There is no doubt that creating, maintaining and handover of requirements documentation is a very comprehensive and time-consuming task involving different parties.

However, properly written requirements documents:

1. Bring the overall formality to the requirements
2. Claim the agreement between the stakeholders
3. Can be used for success metrics and they help with documentation traceability
4. Contribute to meet or advance the overall company strategy

Requirements exaggeration, omitting, misjudgement and errors are often cause of failing to meet the required expectations, whether those of the customer, or the internal business. Keeping requirement documentation within the boundaries together with the establishment of best practices can be of a tremendous help, especially once the requirement maintenance takes place.