Requirements are fundamental to any business project. Business requirements define what should be delivered in order to achieve the project objective. Documenting business requirements clearly and concisely helps ensure the result fulfills stakeholders’ needs.
While good requirements are paramount, the process used to draft those requirements can be just as important. A sound process can result in fewer unclear or incorrect requirements. For example, consider the experiences of a Fortune 500 company, which has a business requirements process in place that is continually improved to enable successful project deliveries.
Before 2012, the company had not designated a standard template for business requirement documentation (BRD). Various business and technology groups used their own templates with different formats and content. Document authors defined and reviewed requirements during numerous meetings, though they generally made updates offline based on the discussions.
Afterward, stakeholders sometimes received large documents and were assigned to complete individual reviews and instructed to provide their approval by an assigned due date. Often, stakeholders did not have the time to review the entire document, so they would provide oral approval during meetings in an effort to meet the project due date.
Requirement issues that surfaced later resulted in frequent change requests and stakeholder dissatisfaction. In addition, when different teams collaborated on new projects, they were sometimes required to familiarize themselves with a different BRD template or a distinct process for defining requirements and approvals. This resulted in confusion and frustration between technology teams.
In 2012, the company implemented a standard BRD template. The company introduced new processes, including a process for BRD review and approval (known as “scoring”), and a method to indicate when an application or team was affected by a business requirement (known as “claiming”). The company designed the BRD template with grouped columns to improve usability.
For example, while defining requirements, team members can group template columns at the highest level so they can focus only on the information needed to define requirements. They can ungroup columns later to expose information needed for scoring
and claiming.
The first major initiative to pilot the template included at least 30 technology stakeholders. These project stakeholders were trained on the scoring and claiming process. Scoring a requirement is the process of reviewing and approving requirements individually. In this case, “requirements” also include assumptions, dependencies, constraints, risks, and business rules, as indicated by the record type entered for the row. Approving, or passing, a requirement indicates that the requirement is clear, concise, testable, well written, and understood. If questions or issues need to be addressed to clarify a requirement, it is failed and requires further attention. All project stakeholders must agree to pass each requirement, and all requirements must pass for the team to approve the BRD.
Scoring is most effective when all stakeholders are present for a joint review meeting. In some cases, it may be possible to facilitate multiple, smaller-group meetings if the requirements can be easily divided, such as by feature (a distinguishing characteristic that can be used to group the requirements). Alternatively, teams can handle scoring partially offline.
The pilot team chose this approach and divided stakeholders into logical subteams. The stakeholder subteams recorded their pass/fail votes and provided the updates to the analyst offline. The analyst consolidated the pass/fail updates into the master BRD. Then, stakeholders had a meeting to review only the requirements failed by any one stakeholder. The team adopted a best practice focused on requirements that needed clarifications or updates; they could be updated live and projected so everyone could view and approve the changes in real time.
Achieving the correct set of business requirements is important for the success of any technology project.
Claiming a requirement indicates who will be assigned to take action to satisfy the requirement, such as software development, hardware installation, configuration, or special testing. Requirements may be claimed by business and/or technology teams. Claiming does not imply the requirement can or will be met within the scope of the project, nor does it imply that it is understood how the requirement will be delivered.
Claiming only indicates an action will be required by the claiming team. Requirements may be claimed by more than one application or team, but generally must be claimed by at least one technology team. There may be legitimate exceptions if the business requirement is specific to an action required only of a business group, such as providing end-user training.
As a result of lessons learned during the pilot project, the company documented guidelines for business analysts to conduct audits of the BRD after scoring and claiming to ensure all requirements were approved and claimed by at least one technology team. Analysts can quickly complete audits by using filters.
Additional audits may be recommended, based on the specific project objectives and relationship between affected applications. For example, because the pilot project included requirements claimed by a back-end application and a user interface application, analysts conducted an audit to ensure the user interface would claim every requirement claimed by the back-end application. It was assumed that the back-end application’s only purpose was to provide data to be used in some way by the user interface. When the initial audit was conducted by filtering on the requirements claimed by the back-end application, a large number of requirements had not been claimed by the user interface.
The team viewed the findings as future change requests, or defects, which were simply avoided. Conversely, the requirements were then filtered on those claimed by the user interface, but not claimed by the back-end application. The filtered list was reviewed to validate if data retrieval was needed, and if so, the back-end application claim for the requirement was updated.
After using the new standard BRD template and gaining experience and familiarity with the scoring and claiming processes, other project teams and the overall technology and business organizations acknowledged the value and benefits. When asked for feedback about the scoring and claiming process, one business user commented, “I like that it gets the technology teams to participate and show ownership for satisfying the requirements.” Technology teams appreciate that the business owner is present to address any questions.
In the last two years, new challenges have presented themselves while undertaking several large initiatives. When a large number of business requirements are defined, scoring and claiming can require a significant number of large group meetings. As a result, the scoring and claiming processes have been modified since the initial launch to improve efficiency, while preserving the benefit of creating quality requirements.
The approach has been altered to divide scoring and claiming sessions for review by feature or other logical grouping. This allows smaller groups to focus on specific sets of requirements more efficiently. In addition, requirements are now “pre-claimed” prior to scoring and claiming meetings. The business analyst and solution design lead now collaborate to update the pre-claim assignments.
This allows affected teams to simply validate and approve the pre-claimed assignments during the scoring and claiming meetings. These process modifications have significantly reduced the meeting time required for the project teams overall, while preserving the quality and benefits of the scoring and claiming processes. The company will continue to evaluate and improve the processes to make them more efficient.
Achieving the correct set of business requirements is important for the success of any technology project. The standard BRD template and related processes implemented at the company have not only helped projects develop and validate requirements, but have also improved working relationships among cross-functional teams.
The attention and rigor to review requirements during the approval (scoring) process has resulted in fewer issues from unclear or incorrect requirements. Furthermore, issues with missed requirements no longer occur, thanks to the claiming process, which ensures
at least one technology team claims each requirement. Scoring and claiming process improvements have reduced the time and duration required to complete business requirements, allowing projects to move forward more quickly and with better results.
