Writing Business Requirements
Strategy & Software Selection Essentialsby Lynne Ward Wallace
After developing the business plan and securing capital authorization for a strategic initiative, often the next step entails moving forward with selecting the right solution to support the company's objectives. However, with a myriad of vendors and solutions from which to choose, the question often arises:
What will ensure the "best" solution is identified that fulfills the needs of the business?
The key to answering this question lies in documenting high quality business requirements in the initial project stages. The approach taken for business requirements can make or break the success of a project.
Many times we hear stories about retailers who enthusiastically embrace a vendor's software after they see the solution at a tradeshow, meet with the sales team and are shown a "canned" demo. The company is sure that the software will provide capabilities that it does not currently possess, and it will soon have competitive advantages long desired. The project leads are ready to sign the contract and attend the user conference – everyone is ready to jump in feet first.
The problem is that once the project gets started and the team begins business process mapping, the unfortunate realization that the software does not provide basic business-critical functionality comes to light. After enhancement estimates and go live delays, the project costs skyrocket to much more than the company expected, and the project is abandoned or left moving forward with lower expectations of results and benefits – essentially leaving the business with the status quo.
The benefits of properly defining requirements include reducing project changes (e.g., scope creep), reducing time to deployment, keeping costs in line with budget and improving the overall quality of the delivered solution. Developing quality business requirements is an iterative process that must be given appropriate time and focus. In this paper, we will explore how to create effective business requirements to support a project's success.
Upfront Planning as a Pre-Requisite
Even before business requirements are documented, proper plans must be made. Upfront project planning establishes an essential foundation of business knowledge and guiding principles for strategic and business decisions that will be required during the development of requirements and throughout the life of the project. Two key outputs should result from upfront planning: the Project Charter and Current State Documentation.
• The Project Charter defines the project objectives, goals, scope, project team, stakeholders and approvers. When it comes to project planning, scope definition is the most critical. Without understanding what is supposed to be delivered at the end of the project or defining the project boundaries, project success will be limited at best. The Project Charter not only properly scopes the project but also ensures that the end users agree to the scope by approving the charter.
• The company's Current State Documentation in the form of business process flows and IT architectural diagrams assists in identifying and documenting functional gaps that need to be addressed by the project.
Ensuring that these pre-requisites are completed prior to the development of the Business Requirements Document (BRD) is critical. Although planning obviously increases the timeline, it ensures that the retailer understands why they are shopping for software and what business needs they are trying to address.
The Business Requirements Document (BRD)
The BRD contains the actual business requirements and describes in detail the business solution for a project including comprehensive documentation of user needs and expectations. The objectives of the BRD include:
• Communicating what is required from the solution to stakeholders, users and executives to enable agreement between all parties.
• Describing what (not how) customer / business needs will be met by the software solution.
• Providing the basis for all subsequent project deliverables.
• Communicating to vendors what is expected to be delivered by the software solution
Business Requirements Defined
It is important to understand exactly what business requirements are and how they are used. High Level Business Requirements are software agnostic, detailed activities that must be performed in order for the system to deliver the organizational objectives of the business.
Business requirements are broken down into detailed Functional Requirements and Non-Functional Requirements along with Use Cases (also called user stories) that describe the various uses of the system step-by-step.
Functional Requirements specify what the system "shall do" or have the ability to perform; they are behaviors, features or functions the system will provide. Examples of Functional Requirements include:
— Business rules
— Transactions (e.g., sales, refunds, cancellations)
— Administrative functions
— Authorization levels
— Auditability and tracking
— Historical needs
— Legal and regulatory
Non-Functional Requirements detail criteria that define how the desired system will operate. Many times, IT architectural drawings and diagrams are provided as Non-Functional Requirements. Examples include:
— Performance (i.e., response time, speed)
— Scalability (i.e., ability to handle increasing amounts of data or users)
— Capacity (i.e., ability to increase processing while providing acceptable response times)
— Availability (i.e., ability to use the system during times it is needed to support business operations)
— Reliability (i.e., ability to consistently perform according to specifications)
— Recoverability (i.e., ability to restore back to a point of failure)
— Legal and regulatory
— Interoperability (i.e., ability for systems and devices to share and interpret data)
— Data Integrity
Use Cases are a list of steps in sequence that are performed by a user on the system. Use Cases are documented as textual representation of the way a user interacts with the system to achieve a specific business task. It is imperative that each Use Case includes all of the following components
— Actors – roles involved in the process
— Pre-requisites – steps or tasks that must occur prior to the system interaction
— Basic steps or flow – the basic steps of the process
— Alternate flows – other ways of performing the same use case
— Exception flows – events that do not typically occur or are one-off scenarios
— Desired results – the specific goal to be accomplished
By focusing on the Use Case holistically, all requirements can be fully vetted; furthermore, Use Cases can help with the creation of test cases during implementation.
To avoid additional costs and process work-arounds down the road, it is important that participation in business requirement development is all-inclusive and cross-functional.
For example, if the requirements for product attributes are collected from the merchandising and planning teams, a key requirement for royalty reporting needed by finance and accounting may be missed until it is too late. Royalty reporting is based upon contractual agreements, and failure to include this business requirement could cause penalties, the need for custom reporting, validation issues and work-around processes that are much less efficient than those in the current environment.
Preparing to Write Effective Requirements
Through our extensive experience in helping companies document business requirements for a variety of project types, Parker Avery recommends the following key elements to be included in any requirements writing effort.
1. Use an online central repository. An online repository will allow for visibility and sharing by all team members, partners, requirements tracking and change control. Not knowing that a document or tool exists or that an updated version is available makes knowledge sharing and versioning much less effective.
2. Make sure the requirements are verifiable. In other words, define the requirements so that the business owner can easily answer "yes" or "no" to validate the requirement. For example, for a requirement that states, "The system shall provide three years of sales history by day," the business owner should be able to easily confirm whether the requirement has been fulfilled.
3. Every requirement must have a unique identifier. This will provide a common reference for the team.
4. Each requirement should be categorized by functional area of the business.
5. Organize the requirements into a logical hierarchy within the functional area. For example, the functional area may be Foundational Data. The sub categories may be SKU Definition, Attribute Definition and Price Management.
6. Prioritize the requirements. Requirements should be prioritized in a way that allows easy identification of importance to the business. At a minimum High, Medium, Low can be used, but it may be helpful to include more differentiation such as: Must Have, Nice to Have, Future Phase, etc. An identifier for urgency should also be considered. Urgency helps to further understand the requirement and may help to blueprint future project phases.
7. Name the source for each requirement. This will allow quick and easy follow up for questions or clarification.
8. Assign an owner to each requirement. The owner is responsible for making decisions and providing leadership for each requirement as the project progresses.
9. Every requirement must include user, verb, end result and success criteria.
10. All requirements must list any dependencies on other requirements. As an example, if a requirement states the need to "View a list of items" then a dependency should be added to another requirement that states, "When an item is updated or changed in any way, the details must be added to a log," because the former list can not be viewed unless the latter log entry has been created. The dependencies are critical especially when there are many requirements and change is required, it must be clearly understood how a change to a given requirement impacts other requirements through its defined dependencies.
After completing the Project Charter and preparing to write requirements, the next task is actually capturing the data. Remember, each person considers the project from his or her individual perspective. In gathering what are often very diverse requirements, these different perspectives must be understood to successfully build a complete picture of what the project is intended to deliver.
In any of the approaches outlined below, it is important to first clearly articulate the basic scope of the project and keep all discussions within scope. Otherwise, end users may be tempted to describe all kinds of functionality that the project was never designed to provide. Scope expectations must be set carefully in order to avoid disappointing the business in the end. Listed below are several methods for gathering requirements:
• Stakeholder Interviews. Schedule time to talk with each individual stakeholder and ensure each person's specific views and needs are understood.
• Focus Groups or Workshops. Schedule and conduct group workshops with business owners and SMEs. This helps to understand how information flows between different divisions or departments and ensures that inputs and outputs are captured.
• Process Flow Reviews. Schedule cross-functional group reviews of the current state process flows. Walk through the whole system or process, step by step, as a user. This method helps the project team to understand how the system or service is provided and identifies the gaps that need to be resolved in the future state.
• Future State Modeling. Build a future state mock-up process model of the system or product to give users an idea of what the final product may look like. Using this model, users can address feasibility issues, and they can help identify any inconsistencies and problems.
• Industry Best Practice Research. Researching current industry best practices that may or may not be in place in the business today has been shown to be effective in identifying future state requirements. Encourage benchmarking and online research. Even for those in the company who are considered to be SMEs, it can be difficult for the users to identify future state needs if they have been using the same solution and business practices for a long time.
One or a combination of these methods can be used to gather requirements. In our experience, the best results are achieved using a combination of these methods.
Final Review and Approval
Once all requirements for every functional and technical area have been captured and documented in the BRD, review sessions with SMEs, the project team, business owners and stakeholders must be conducted. These sessions must be inclusive and holistic. A cross-functional team review will ensure the appropriate business requirements have been captured. Since requirements become the "shopping list" for a software solution, a final look at all requirements, gaps, and business needs as a whole is essential.
In addition to confirming the requirements are appropriate, these final review sessions should be used to obtain the signed agreement of key stakeholders, or representatives of key stakeholder groups, indicating that the requirements as presented and prioritized reflect their needs. This formal commitment will play an important part in ensuring that the project does not suffer from scope creep later on.
If a key stakeholder is replaced during requirements gathering, the new stakeholder should be engaged in requirements review immediately. A new stakeholder may have an entirely different perspective on the future state; as such, their perspectives must be immediately addressed so any changes can be made and expectations can be set for solution delivery.
Seeking Outside Assistance
Sometimes, it is necessary to involve an outsider to assist in requirements gathering. Considerations for utilizing a consulting partner include:
• Skills and Methodology. The necessary expertise may not exist in-house to properly gather requirements and prepare them for use in an RFP. A consulting partner will be able to share their proven process and should teach "how" to gather requirements at the same time.
• Objectivity. An objective viewpoint may be needed. The consulting partner can address any "elephants in the room" and "sacred cows" without harming existing and ongoing working relationships.
• Partnership. A value-add consulting partner listens, does not bring an agenda, becomes a strong partner and always understands that the project belongs to the company.
• Industry Leading Practices. A consulting partner has the ability to articulate opinions about industry practices that employees may be hesitant to voice. The ability to challenge longstanding traditions and assumptions in a company without repercussions can be very helpful in business transformation projects.
• Staff Augmentation. The business may be growing and the ideal internal project team may already be stretched extremely thin. Bringing in a consulting partner to provide for the backfill of critical business resources or to bring in necessary skills on an "as needed" basis can be valuable.
Developing business requirements is by no means an easy task. It is frequently either not done correctly or not done at all, often resulting in project failure or an overly-expensive solution that simply does not meet the needs of the business. Proper planning and focus is imperative, and – when done well – effective requirements documentation will greatly improve the chances of an initiative's success. The substantial benefits that can be gained from following a structured and proven approach to developing effective business requirements, as well as involving the right resources and project sponsorship, far exceed the costs associated with a system that users will not accept, unanticipated scope creep, a long and defect-ridden implementation and higher than planned costs.
If you’d like to learn more about our vision or understand how you might take advantage of this strategy, contact us at Contact@parkeravery.com or call 770.882.2205.
Download PDF Version (1.5 MB)