We have all seen the proverbial tree swing story graphic. Twelve independent framed images representing twelve different outcomes of the same business requirements. While amusing, this is reality for many organizations and has a significant impact on project outcomes. According to the Info-Tech Research Group “70% of projects fail due to poor requirements.”
Unfortunately, awareness will not provide quality business requirements. You must plan for it. Eliciting and clearly documenting requirements is a skill set. Like any other tool, your ability to effectively use this has a significant impact on the results. Whether you are embarking on an enterprise deployment, or a small cross-functional expansion, the basics need to be covered.
Business Requirements Gathering Process
Business requirements gathering is necessary to create a shared vision within your business. The importance of engaging, eliciting, and prioritizing requirements with all impacted stakeholders is critical. Requirements gathering is most effective with a robust process and a strong Business Analyst. The framework below illustrates a comprehensive requirements gathering approach consisting of a Requirements Gathering Process (Elicit, Analyze, Validate) and a Requirements Governance Process (Plan, Monitor, Communicate and Manage).
The standard approach to gathering requirements includes three core activities: Elicit, Analyze, and Validate.
Elicit Phase
One of the common traps is selecting a technological solution before fully examining the business need first. Prepare your elicitation approach. Identify your stakeholders and elicitation tools such as BPM, SIPOCs, brainstorming sessions, interviews or focus groups. Put in place an elicitation process with a top-down approach, starting with senior management. Take advantage of generating a transformational change by reinventing a process instead of fixing small deficiencies in the current one.
Conduct the elicitation process to identify the business processes the application will need to support and identify the “as is” process and how to improve upon it. A strong elicitor will have a blend of industry knowledge, core analytical thinking, and proficiency in BA tools. Who did you bring into the elicitation? Did you bring in the right people? Participants, at minimum, should include customers, end users, business analysts, system analysts, testers, and business sponsor(s). Avoid focusing on just the functional requirements. Make sure you examine all regulatory, business, user, functional, non-functional, and transition requirements as well.
Confirm the understanding of each requirement using active listening skills, and revise as needed.
According to Info-Tech Research Group requirements should be:
Verifiable – Stated in a way that can be easily tested
Unambiguous – Free of subjective terms and can only be interpreted in one way
Complete – Contains all relevant information
Achievable – Possible to accomplish with budgetary and technological constraints
Traceable – Trackable from inception through to testing
Unitary – Addresses only one thing and cannot be decomposed into multiple requirements
Agnostic – Does not pre-suppose a specific vendor or product
Analyze Phase
This phase defines the solution scope. Ensure you organize and prioritize the features based on importance, effort, and resource considerations. Also, verify they address the original business goals. Using the right tools to analyze the information such as flowcharts, context-level data flow diagrams, use case diagrams and scenarios, swim lane activity process flows, and process models, can help represent a meaningful, easy-to-understand business requirements document.
Organize requirements to eliminate duplicates and identify relationships and dependencies. Creating specific and clear requirements is the end goal. Prioritize requirements using established organizational core values as weighed measures or simply use the MoSCoW (must-haves, should-haves, could-haves, and will not have at this time) prioritization method. Finally, verify all information is captured as it was intended with your subject matter experts.
Validate Phase
Validate the complete business requirements package with the stakeholders. This approval process provides a final opportunity for the voice of the customer to confirm and verify the package represents all their prioritized business needs. It mobilizes stakeholder commitment and minimizes future change requests. In this phase, all requirements are translated into technical requirements. For traceability, all requirements should have a requirements traceability matrix that link back to test cases.
All testing opportunities should be allocated to the proper team and test scenarios. Identify who will do the testing and at what stage (Functional, UAT, System Integration, Performance, Penetration). Requirements should be verified by domain SMEs to ensure that the analyzed requirements continue to meet their needs.
Obtain final approval via signature sign-off. Use the sign-off process as one last opportunity to manage expectations, obtain commitment from stakeholders, and minimize change requests. The complete business requirement package should include:
Project summary and background
Operating model
Business process model
Use cases
Requirements elicitation techniques
Prioritized requirements
Assumptions and constraints
Signature page
Requirements Governance Process
The Requirements Governance Process lays the foundation for how requirements will be gathered, managed, and communicated. The four key components of the Governance Process are Plan, Monitor, Manage and Communicate.
Plan
Setup a structured playbook that outlines a repeatable and scalable process for all requirement gathering efforts across your organization. The playbook should provide guidance on how to Elicit, Analyze and Validate requirements.
Monitor
Avoid one-off, autonomous processes that do not capture agreed upon, organizational KPIs. Follow up in regular intervals (every 6 months to 1 year) to check on the effectiveness of the requirements gathering process (average number of reworks, number of change requests, user adoption rate, etc.) to gauge if the playbook is having a measurable effect in the organization.
Manage
Know that some requirements may change and evolve as the team learns more about a solution, or as the business changes. Do not let sidebar or one-off conversations surface new requirements without the team recognizing and raising them as such. Continuous management of the requirements is necessary.
Communicate
Make sure you have a change control process that is visible and communicated to all key stakeholders. As a result, any new learning and team discovery can be captured, discussed, mitigated, re-estimated and approved.
Requirements Management is Important
Effective requirements gathering and management is critical to achieve your organization’s desired business outcomes. This requires a skilled Business Analyst, clearly defined processes, and appropriate tools. The process must involve input from all key stakeholders, resulting in clearly aligned expectations. Use these requirements to test the final solution. Clearly defined requirements serve as a checkpoint to validate the most important question: “Did we accomplish what we set out to do and will it deliver the anticipated outcomes?”
Comments