Besides the small introduction, subscribers and consulting clients within this management domain have access to:
Capture a clear understanding of the target needs for the requirements process.
Develop best practices for conducting and structuring elicitation of business requirements.
Standardize frameworks for analysis and validation of business requirements.
Formalize change control and governance processes for requirements gathering.
Workshops offer an easy way to accelerate your project. If you are unable to do the project yourself, and a Guided Implementation isn't enough, we offer low-cost delivery of our project workshops. We take you through every phase of your project and ensure that you have a roadmap in place to complete your project successfully.
Create a clear understanding of the target needs for the requirements gathering process.
A comprehensive review of the current state for requirements gathering across people, processes, and technology.
Identification of major challenges (and opportunity areas) that should be improved via the requirements gathering optimization project.
1.1 Understand current state and document existing requirement process steps.
1.2 Identify stakeholder, process, outcome, and training challenges.
1.3 Conduct target state analysis.
1.4 Establish requirements gathering metrics.
1.5 Identify project levels 1/2/3/4.
1.6 Match control points to project levels 1/2/3/4.
1.7 Conduct project scoping and identify stakeholders.
Requirements Gathering Maturity Assessment
Project Level Selection Tool
Requirements Gathering Documentation Tool
Create best practices for conducting and structuring elicitation of business requirements.
A repeatable framework for initial elicitation of requirements.
Prescribed, project-specific elicitation techniques.
2.1 Understand elicitation techniques and which ones to use.
2.2 Document and confirm elicitation techniques.
2.3 Create a requirements gathering elicitation plan for your project.
2.4 Build the operating model for your project.
2.5 Define SIPOC-MC for your selected project.
2.6 Practice using interviews with business stakeholders to build use case models.
2.7 Practice using table-top testing with business stakeholders to build use case models.
Project Elicitation Schedule
Project Operating Model
Project SIPOC-MC Sub-Processes
Project Use Cases
Build a standardized framework for analysis and validation of business requirements.
Policies for requirements categorization, prioritization, and validation.
Improved project value as a result of better prioritization using the MOSCOW model.
3.1 Categorize gathered requirements for use.
3.2 Consolidate similar requirements and eliminate redundancies.
3.3 Practice prioritizing requirements.
3.4 Build the business process model for the project.
3.5 Rightsize the requirements documentation template.
3.6 Present the business requirements document to business stakeholders.
3.7 Identify testing opportunities.
Requirements Gathering Documentation Tool
Requirements Gathering Testing Checklist
Create formalized change control processes for requirements gathering.
Reduced interjections and rework – strengthened formal evaluation and control of change requests to project requirements.
4.1 Review existing CR process.
4.2 Review change control process best practices and optimization opportunities.
4.3 Build guidelines for escalating changes.
4.4 Confirm your requirements gathering process for project levels 1/2/3/4.
Requirements Traceability Matrix
Requirements Gathering Communication Tracking Template
Establish governance structures and ongoing oversight for business requirements gathering.
Consistent governance and oversight of the requirements gathering process, resulting in fewer “wild west” scenarios.
Better repeatability for the new requirements gathering process, resulting in less wasted time and effort at the outset of projects.
5.1 Define RACI for the requirements gathering process.
5.2 Define the requirements gathering steering committee purpose.
5.3 Define RACI for requirements gathering steering committee.
5.4 Define the agenda and cadence for the requirements gathering steering committee.
5.5 Identify and analyze stakeholders for communication plan.
5.6 Create communication management plan.
5.7 Build the action plan.
Requirements Gathering Action Plan
Back to basics: great products are built on great requirements.
A strong process for business requirements gathering is essential for application project success. However, most organizations do not take a strategic approach to optimizing how they conduct business analysis and requirements definition.
"Robust business requirements are the basis of a successful project. Without requirements that correctly articulate the underlying needs of your business stakeholders, projects will fail to deliver value and involve significant rework. In fact, an Info-Tech study found that of projects that fail over two-thirds fail due to poorly defined business requirements.
Despite the importance of good business requirements to project success, many organizations struggle to define a consistent and repeatable process for requirements gathering. This results in wasted time and effort from both IT and the business, and generates requirements that are incomplete and of dubious value. Additionally, many business analysts lack the competencies and analytical techniques needed to properly execute the requirements gathering process.
This research will help you get requirements gathering right by developing a set of standard operating procedures across requirements elicitation, analysis, and validation. It will also help you identify and fine-tune the business analyst competencies necessary to make requirements gathering a success."
– Ben Dickie, Director, Enterprise Applications, Info-Tech Research Group
A business requirement is a statement that clearly outlines the functional capability that the business needs from a system or application. There are several attributes to look at in requirements:
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
Consistent
Does not conflict with other requirements
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
Doesn’t pre-suppose a specific vendor or product
In some situations, an insight will reveal new requirements. This requirement will not follow all of the attributes listed above and that’s okay. If a new insight changes the direction of the project, re-evaluate the scope of the project.
Depending on the scope of the project, certain attributes will carry more weight than others. Weigh the value of each attribute before elicitation and adjust as required. For example, verifiable will be a less-valued attribute when developing a client-facing website with no established measuring method/software.
Proper requirements gathering is critical for delivering business value from IT projects, but it remains an elusive and perplexing task for most organizations. You need to have a strategy for end-to-end requirements gathering, or your projects will consistently fail to meet business expectations.
50% of project rework is attributable to problems with requirements. (Info-Tech Research Group)
45% of delivered features are utilized by end users. (The Standish Group)
78% of IT professionals believe the business is “usually” or “always” out of sync with project requirements. (Blueprint Software Systems)
45% of IT professionals admit to being “fuzzy” about the details of a project’s business objectives. (Blueprint Software Systems)
Requirements gathering is truly an organization-spanning issue, and it falls directly on the IT directors who oversee projects to put prudent SOPs in place for managing the requirements gathering process. Despite its importance, the majority of organizations have challenges with requirements gathering.
What happens when requirements are no longer effective?
PMBOK’s Five Phase Project Lifecycle
Initiate – Plan: Requirements Gathering Lives Here – Execute – Control – Close
Inaccurate requirements is the 2nd most common cause of project failure (Project Management Institute ‒ Smartsheet).
Requirements gathering is a critical stage of project planning.
Depending on whether you take an Agile or Waterfall project management approach, it can be extended into the initiate and execute phases of the project lifecycle.
Organizations that had high satisfaction with requirements gathering were more likely to be highly satisfied with the other areas of IT. In fact, 72% of organizations that had high satisfaction with requirements gathering were also highly satisfied with the availability of IT capacity to complete projects.
Note: High satisfaction was classified as organizations with a score greater or equal to 8. Not high satisfaction was every other organization that scored below 8 on the area questions.
N=395 organizations from Info-Tech’s CIO Business Vision diagnostic
The challenges that afflict requirements gathering are multifaceted and often systemic in nature. There isn’t a single cure that will fix all of your requirements gathering problems, but an awareness of frequently encountered challenges will give you a basis for where to consider establishing better SOPs. Commonly encountered challenges include:
70% of projects fail due to poor requirements. (Info-Tech Research Group)
Root Causes of Poor Requirements Gathering:
Outcomes of Poor Requirements Gathering:
Info-Tech Insight
Requirements gathering is the number one failure point for most development or procurement projects that don’t deliver value. This has been and continues to be the case as most organizations still don't get requirements gathering right. Overcoming organizational cynicism can be a major obstacle when it is time to optimize the requirements gathering process.
You can reduce the amount of wasted work by making sure you have clear business goals. In fact, you could see an improvement of as much as 50% by going from a low level of satisfaction with clarity of business goals (<2) to a high level of satisfaction (≥5).
Likewise, you could see an improvement of as much as 43% by going from a low level of satisfaction with analysis of requirements (less than 2) to a high level of satisfaction (greater than or equal to 5).
Note: Waste is measured by the amount of cancelled projects; suboptimal assignment of resources; analyzing, fixing, and re-deploying; inefficiency, and unassigned resources.
N=200 teams from the Project Portfolio Management diagnostic
Good intentions and hard work aren’t enough to make a project successful. As you proceed with a project, step back and assess the critical success factors. Make sure that the important inputs and critical activities of requirements gathering are supporting, not inhibiting, project success.
Creating a unified SOP guide for requirements elicitation, analysis, and validation is a critical step for requirements optimization; it gives your BAs a common frame of reference for conducting requirements gathering.
Info-Tech Insight
Having a standardized approach to requirements management is critical, and SOPs should be the responsibility of a group. The SOP guide should cover all of the major bases of requirements management. In addition to providing a walk-through of the process, an SOP also clarifies requirements governance.
Info-Tech’s Requirements Gathering Framework is a comprehensive approach to requirements management that can be scaled to any size of project or organization. This framework has been extensively road-tested with our clients to ensure that it balances the needs of IT and business stakeholders to give a holistic, end-to-end approach for requirements gathering. It covers the foundational issues (elicitation, analysis, and validation) and prescribes techniques for planning, monitoring, communicating, and managing the requirements gathering process.
When creating the process for requirements gathering, think about how it will be executed by your BAs, and what the composition of your BA team should look like. A strong BA needs to serve as an effective translator, being able to speak the language of both the business and IT.
What are some core competencies of a good BA?
Throughout this blueprint, look for the “BA Insight” box to learn how steps in the requirements gathering process relate to the skills needed by BAs to facilitate the process effectively.
Government
Info-Tech Research Group Workshop
The Client
The organization was a local government responsible for providing services to approximately 600,000 citizens in the southern US. Its IT department is tasked with deploying applications and systems (such as HRIS) that support the various initiatives and mandate of the local government.
The Requirements Gathering Challenge
The IT department recognized that a strong requirements gathering process was essential to delivering value to its stakeholders. However, there was no codified process in place – each BA unilaterally decided how they would conduct requirements gathering at the start of each project. IT recognized that to enhance both the effectiveness and efficiency of requirements gathering, it needed to put in place a strong, prescriptive set of SOPs.
The Improvement
Working with a team from Info-Tech, the IT leadership and BA team conducted a workshop to develop a new set of SOPs that provided clear guidance for each stage of the requirements process: elicitation, analysis, and validation. As a result, business satisfaction and value alignment increased.
The Requirements Gathering SOP and BA Playbook offers a codified set of SOPs for requirements gathering gave BAs a clear playbook.
“Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.”
“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”
“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”
“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”
Diagnostics and consistent frameworks used throughout all four options
1. Build the Target State for Requirements Gathering | 2. Define the Elicitation Process | 3. Analyze and Validate Requirements | 4. Create a Requirements Governance Action Plan | |
---|---|---|---|---|
Best-Practice Toolkit |
1.1 Understand the Benefits of Requirements Optimization 1.2 Determine Your Target State for Requirements Gathering |
2.1 Determine Elicitation Techniques 2.2 Structure Elicitation Output |
3.1 Create Analysis Framework 3.2 Validate Business Requirements |
4.1 Create Control Processes for Requirements Changes 4.2 Build Requirements Governance and Communication Plan |
Guided Implementations |
|
|
|
|
Onsite Workshop | Module 1: Define the Current and Target State | Module 2: Define the Elicitation Process | Module 3: Analyze and Validate Requirements | Module 4: Governance and Continuous Improvement Process |
Phase 1 Results: Clear understanding of target needs for the requirements process. | Phase 2 Results: Best practices for conducting and structuring elicitation. | Phase 3 Results: Standardized frameworks for analysis and validation of business requirements. | Phase 4 Results: Formalized change control and governance processes for requirements. |
Contact your account representative or email Workshops@InfoTech.com for more information.
Workshop Day 1 | Workshop Day 2 | Workshop Day 3 | Workshop Day 4 | Workshop Day 5 | |
---|---|---|---|---|---|
Activities |
Define Current State and Target State for Requirements Gathering
|
Define the Elicitation Process
|
Analyze and Validate Requirements
|
Establish Change Control Processes
|
Establish Ongoing Governance for Requirements Gathering
|
Deliverables |
|
|
|
|
|
Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.
Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.
Proposed Time to Completion: 2 weeks
Start with an analyst kick off call:
Then complete these activities…
With these tools & templates:
Requirements Gathering SOP and BA Playbook
Review findings with analyst:
Then complete these activities…
With these tools & templates:
Phase 1 Results & Insights:
Clear understanding of target needs for the requirements process.
1.1 Understand the Benefits of Requirements Optimization
1.2 Determine Your Target State for Requirements Gathering
2.1 Determine Elicitation Techniques
2.2 Structure Elicitation Output
3.1 Create Analysis Framework
3.2 Validate Business Requirements
4.1 Create Control Processes for Requirements Changes
4.2 Build Requirements Governance and Communication Plan
Optimizing requirements management is not something that can be done in isolation, and it’s not necessarily going to be easy. Improving your requirements will translate into better value delivery, but it takes real commitment from IT and its business partners.
There are four “pillars of commitment” that will be necessary to succeed with requirements optimization:
When gathering business requirements, it’s critical not to assume that layering on technology to a process will automatically solve your problems.
Proper requirements gathering views projects holistically (i.e. not just as an attempt to deploy an application or technology, but as an endeavor to enable new or re-engineered business processes). Neglecting to see requirements gathering in the context of business process enablement leads to failure.
Info-Tech’s Requirements Gathering Framework is a comprehensive approach to requirements management that can be scaled to any size of project or organization. This framework has been extensively road-tested with our clients to ensure that it balances the needs of IT and business stakeholders to give a holistic, end-to-end approach for requirements gathering. It covers both the foundational issues (elicitation, analysis, and validation) as well as prescribing techniques for planning, monitoring, communicating, and managing the requirements gathering process.
Identify the challenges you’re experiencing with requirements gathering, and identify objectives.
Creating a unified SOP guide for requirements elicitation, analysis, and validation is a critical step for requirements optimization; it gives your BAs a common frame of reference for conducting requirements gathering.
Info-Tech Insight
Having a standardized approach to requirements management is critical, and SOPs should be the responsibility of a group. The SOP guide should cover all of the major bases of requirements management. In addition to providing a walk-through of the process, an SOP also clarifies requirements governance.
Info-Tech’s Requirements Gathering SOP and BA Playbook template forms the basis of this blueprint. It’s a structured document that you can fill out with defined procedures for how requirements should be gathered at your organization.
Info-Tech’s Requirements Gathering SOP and BA Playbook template provides a number of sections that you can populate to provide direction for requirements gathering practitioners. Sections provided include: Organizational Context Governance Procedures Resourcing Model Technology Strategy Knowledge Management Elicitation SOPs Analysis SOPs Validation SOPs.
The template has been pre-populated with an example of requirements management procedures. Feel free to customize it to fit your specific needs.
Download the Requirements Gathering SOP and BA Playbook template.
1.1 Understand the Benefits of Requirements Optimization
1.2 Determine Your Target State for Requirements Gathering
2.1 Determine Elicitation Techniques
2.2 Structure Elicitation Output
3.1 Create Analysis Framework
3.2 Validate Business Requirements
4.1 Create Control Processes for Requirements Changes
4.2 Build Requirements Governance and Communication Plan
Establishing an overarching plan for requirements governance is the first step in building an SOP. You must also decide who will actually execute the requirements gathering processes, and what technology they will use to accomplish this. Planning for governance, resourcing, and technology is something that should be done repeatedly and at a higher strategic level than the more sequential steps of elicitation, analysis, and validation.
Visualize how you want requirements to be gathered in your organization. Do not let elements of the current process restrict your thinking.
For example:
Refrain from only making small changes to improve the existing process. Think about the optimal way to structure the requirements gathering process.
Verifiable – It is stated in a way that can be tested.
Unambiguous – It is free of subjective terms and can only be interpreted in one way.
Complete – It contains all relevant information.
Consistent – It does not conflict with other requirements.
Achievable – It is possible to accomplish given the budgetary and technological constraints.
Traceable – It can tracked from inception to testing.
Unitary – It addresses only one thing and cannot be decomposed into multiple requirements.
Accurate – It is based on proven facts and correct information.
Other Considerations:
Organizations can also track a requirement owner, rationale, priority level (must have vs. nice to have), and current status (approved, tested, etc.).
Info-Tech Insight
Requirements must be solution agnostic – they should focus on the underlying need rather than the technology required to satisfy the need as it can be really easy to fall into the technology solution trap.
Use the Requirements Gathering Maturity Assessment tool to help assess the maturity of your requirements gathering function in your organization, and identify the gaps between the current state and the target state. This will help focus your organization's efforts in closing the gaps that represent high-value opportunities.
Complete the Requirements Gathering Maturity Assessment tool to define your target state, and identify the gaps in your current state.
You need to ensure your requirements gathering procedures are having the desired effect and adjust course when necessary. Establishing an upfront list of key performance indicators that will be benchmarked and tracked is a crucial step.
Document the output from this exercise in section 2.2 of the Requirements Gathering SOP and BA Playbook.
A business process model (BPM) is a simplified depiction of a complex process. These visual representations allow all types of stakeholders to quickly understand a process, how it affects them, and enables more effective decision making. Consider these areas for your model:
Stakeholder Analysis
Elicitation Techniques
Documentation
Validation & Traceability
Managing Requirements
Supporting Tools
It’s important to determine the project levels up front, as each project level will have a specific degree of elicitation, analysis, and validation that will need to be completed. That being said, not all organizations will have four levels.
The Project Level Selection Tool will classify your projects into four levels, enabling you to evaluate the risk and complexity of a particular project and match it with an appropriate requirements gathering process.
Project Level Input
Project Level Selection
Define the project levels to determine the appropriate requirements gathering process for each.
Document the output from this exercise in section 2.3 of the Requirements Gathering SOP and BA Playbook.
Category | Level 4 | Level 3 | Level 2 | Level 1 |
---|---|---|---|---|
Scope of Change | Full system update | Full system update | Multiple modules | Minor change |
Expected Duration | 12 months + | 6 months + | 3-6 months | 0-3 months |
Impact | Enterprise-wide, globally dispersed | Enterprise-wide | Department-wide | Low users/single division |
Budget | $1,000,000+ | $500,000-1,000,000 | $100,000-500,000 | $0-100,000 |
Services Affected | Mission critical, revenue impacting | Mission critical, revenue impacting | Pervasive but not mission critical | Isolated, non-essential |
Confidentiality | Yes | Yes | No | No |
The tool is comprised of six questions, each of which is linked to at least one type of project risk.
Using the answers provided, the tool will calculate a level for each risk category. Overall project level is a weighted average of the individual risk levels, based on the importance weighting of each type of risk set by the project manager.
This tool is an excerpt from Info-Tech’s exhaustive Project Level Assessment Tool.
Brainstorm the ideal target business process flows for your requirements gathering process (by project level).
Document the output from this exercise in section 2.4 of the Requirements Gathering SOP and BA Playbook.
Having an SOP is important, but it should be the basis for training the people who will actually execute the requirements gathering process. Your BA team is critical for requirements gathering – they need to know the SOPs in detail, and you need to have a plan for recruiting those with an excellent skill set.
The ideal candidates for requirements gathering are technically savvy analysts (but not necessarily computer science majors) from the business who are already fluent with the business’ language and cognizant of the day-to-day challenges that take place. Organizationally, these BAs should be in a group that bridges IT and the business (such as an RGCOE or PMO) and be specialists rather than generalists in the requirements management space.
A BA resourcing strategy is included in the SOP. Customize it to suit your needs.
"Make sure your people understand the business they are trying to provide the solution for as well if not better than the business folks themselves." – Ken Piddington, CIO, MRE Consulting
If you don’t have a trained group of in-house BAs who can execute your requirements gathering process, consider sourcing the talent from internal candidates or calling for qualified applicants. Our Business Requirements Analyst job description template can help you quickly get the word out.
Info-Tech Deliverable
Download the Business Requirements Analyst job description template.
Industry Government
Source Info-Tech Workshop
A mid-sized US municipality was challenged with managing stakeholder expectations for projects, including the collection and analysis of business requirements.
The lack of a consistent approach to requirements gathering was causing the IT department to lose credibility with department level executives, impacting the ability of the team to engage project stakeholders in defining project needs.
The City contracted Info-Tech to help build an SOP to govern and train all BAs on a consistent requirements gathering process.
The teams first set about establishing a consistent approach to defining project levels, defining six questions to be asked for each project. This framework would be used to assess the complexity, risk, and scope of each project, thereby defining the appropriate level of rigor and documentation required for each initiative.
Once the project levels were defined, the team established a formalized set of steps, tools, and artifacts to be created for each phase of the project. These tools helped the team present a consistent approach to each project to the stakeholders, helping improve credibility and engagement for eliciting requirements.
Choose a level of control that facilitates success without slowing progress.
No control | Right-sized control | Over-engineered control |
---|---|---|
Final deliverable may not satisfy business or user requirements. | Control points and communication are set at appropriate stage-gates to allow for deliverables to be evaluated and assessed before proceeding to the next phase. | Excessive controls can result in too much time spent on stage-gates and approvals, which creates delays in the schedule and causes milestones to be missed. |
Info-Tech Insight
Throughout the requirements gathering process, you need checks and balances to ensure that the projects are going according to plan. Now that we know our stakeholder, elicitation, and prioritization processes, we will set up the control points for each project level.
Determine how you want to receive and distribute messages to stakeholders.
Communication Milestones | Audience | Artifact | Final Goal |
---|---|---|---|
Project Initiation | Project Sponsor | Project Charter | Communicate Goals and Scope of Project |
Elicitation Scheduling | Selected Stakeholders (SMEs, Power Users) | Proposed Solution | Schedule Elicitation Sessions |
Elicitation Follow-Up | Selected Stakeholders | Elicitation Notes | Confirm Accuracy of Notes |
First Pass Validation | Selected Stakeholders | Consolidated Requirements | Validate Aggregated Requirements |
Second Pass Validation | Selected Stakeholders | Prioritized Requirements | Validate Requirements Priority |
Eliminated Requirements | Affected Stakeholders | Out of Scope Requirements | Affected Stakeholders Understand Impact of Eliminated Requirements |
Solution Selection | High Authority/Expertise Stakeholders | Modeled Solutions | Select Solution |
Selected Solution | High Authority/Expertise Stakeholders and Project Sponsor | Requirements Package | Communicate Solution |
Requirements Sign-Off | Project Sponsor | Requirements Package | Obtain Sign-Off |
# – Control Point: A decision requiring specific approval or sign-off from defined stakeholders involved with the project. Control points result in accepted or rejected deliverables/documents.
A – Plan Approval: This control point requires a review of the requirements gathering plan, stakeholders, and elicitation techniques.
B – Requirements Validation: This control point requires a review of the requirements documentation that indicates project and product requirements.
C – Prioritization Sign-Off: This requires sign-off from the business and/or user groups. This might be sign-off to approve a document, prioritization, or confirm that testing is complete.
D – IT or Peer Sign-Off: This requires sign-off from IT to approve technical requirements or confirm that IT is ready to accept a change.
Define all of the key control points, required documentation, and involved stakeholders.
Document the output from this exercise in section 6.1 of the Requirements Gathering SOP and BA Playbook.
Before commencing requirements gathering, it’s critical that your practitioners have a clear understanding of the initial business case and rationale for the project that they’re supporting. This is vital for providing the business context that elicitation activities must be geared towards.
During requirements gathering, BAs should steer clear of solutions and focus on capturing requirements. Focus on traceable, hierarchical, and testable requirements. Focusing on solution design means you are out of requirements mode.
Constraints come in many forms (i.e. financial, regulatory, and technological). Identifying these constraints prior to entering requirements gathering enables you to remain alert; you can separate what is possible from what is impossible, and set stakeholder expectations accordingly.
Stakeholder management is a critical aspect of the BA’s role. Part of the BA’s responsibility is prioritizing solutions and demonstrating to stakeholders the level of effort required and the value attained.
Begin the requirements gathering process by conducting some initial scoping on why we are doing the project, the goals, and the constraints.
Before you can dive into most elicitation techniques, you need to know who you’re going to speak with – not all stakeholders hold the same value.
There are two broad categories of stakeholders:
Customers: Those who ask for a system/project/change but do not necessarily use it. These are typically executive sponsors, project managers, or interested stakeholders. They are customers in the sense that they may provide the funding or budget for a project, and may have requests for features and functionality, but they won’t have to use it in their own workflows.
Users: Those who may not ask for a system but must use it in their routine workflows. These are your end users, those who will actually interact with the system. Users don’t necessarily have to be people – they can also be other systems that will require inputs or outputs from the proposed solution. Understand their needs to best drive more granular functional requirements.
"The people you need to make happy at the end of the day are the people who are going to help you identify and prioritize requirements." – Director of IT, Municipal Utilities Provider
Need a hand with stakeholder identification? Leverage Info-Tech’s Stakeholder Planning Tool to catalog and prioritize the stakeholders your BAs will need to contact during the elicitation phase.
Practice the process for identifying and analyzing key stakeholders for requirements gathering.
Use the Requirements Gathering Communication Tracking Template for structuring and managing ongoing communications among key requirements gathering implementation stakeholders.
Use the Stakeholder Power Map tab to:
Use the Communication Management Plan tab to:
Recording and analyzing requirements needs some kind of tool, but don’t overinvest in a dedicated suite if you can manage with a more inexpensive solution (such as Word, Excel, and/or Visio). Top-tier solutions may be necessary for an enterprise ERP deployment, but you can use a low-cost solution for low-level productivity application.
Your SOP guide should specify the technology platform that your analysts are expected to use for initial elicitation as well as analysis and validation. You don’t want them to use Word if you’ve invested in a full-out IBM RM solution.
Dedicated requirements management suites are a great (although pricey) way to have full control over recording, analysis, and hierarchical categorization of requirements. Consider some of the major vendors in the space if Word, Excel, and Visio aren’t suitable for you.
Industry Consulting
Source Jama Software
ArcherPoint is a leading Microsoft Partner responsible for providing business solutions to its clients. Its varied customer base now requires a more sophisticated requirements gathering software.
Its process was centered around emailing Word documents, creating versions, and merging issues. ArcherPoint recognized the need to enhance effectiveness, efficiency, and accuracy of requirements gathering through a prescriptive set of elicitation procedures.
The IT department at ArcherPoint recognized that a strong requirements gathering process was essential to delivering value to stakeholders. It needed more scalable and flexible requirements gathering software to enhance requirements traceability. The company implemented SaaS solutions that included traceability and seamless integration features.
These features reduced the incidences of repetition, allowed for tracing of requirements relationships, and ultimately led to an exhaustive understanding of stakeholders’ needs.
Projects are now vetted upon an understanding of the business client’s needs with a thorough requirements gathering collection and analysis.
A deeper understanding of the business needs also allows ArcherPoint to better understand the roles and responsibilities of stakeholders. This allows for the implementation of structures and policies which makes the requirements gathering process rigorous.
Solution options or preferences are not requirements. Be sure to identify these quickly to avoid being forced into untimely discussions and sub-optimal solution decisions.
Solution Requirements: Describe the characteristics of a solution that meet business requirements and stakeholder requirements. They are frequently divided into sub-categories, particularly when the requirements describe a software solution:
Functional Requirements
Non-Functional Requirements
Remember that solution requirements are distinct from solution specifications; in time, specifications will be developed from the requirements. Don’t get ahead of the process.
An analyst will facilitate a discussion to assess the maturity of your requirements gathering process and identify any gaps in the current state.
Speak to an analyst to discuss and determine key metrics for measuring the effectiveness of your requirements gathering processes.
An analyst will facilitate a discussion to determine the ideal target business process flow for your requirements gathering.
An analyst will assist you with determining the appropriate requirements gathering approach for different project levels. The discussion will highlight key control points and define stakeholders who will be involved in each one.
An analyst will facilitate a discussion to highlight the scope of the requirements gathering optimization project as well as identify and analyze key stakeholders in the process.
Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.
Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.
Proposed Time to Completion: 2 weeks
Start with an analyst kick off call:
Then complete these activities…
Review findings with analyst:
Then complete these activities…
With these tools & templates:
1.1 Understand the Benefits of Requirements Optimization
1.2 Determine Your Target State for Requirements Gathering
2.1 Determine Elicitation Techniques
2.2 Structure Elicitation Output
3.1 Create Analysis Framework
3.2 Validate Business Requirements
4.1 Create Control Processes for Requirements Changes
4.2 Build Requirements Governance and Communication Plan
The elicitation phase is where the BAs actually meet with project stakeholders and uncover the requirements for the application. Major tasks within this phase include stakeholder identification, selecting elicitation techniques, and conducting the elicitation sessions. This phase involves the most information gathering and therefore requires a significant amount of time to be done properly.
A mediocre requirements practitioner takes an order taker approach to elicitation: they elicit requirements by showing up to a meeting with the stakeholder and asking, “What do you want?” This approach frequently results in gaps in requirements, as most stakeholders cannot free-form spit out an accurate inventory of their needs.
A strong requirements practitioner first decides on an elicitation framework – a mechanism to anchor the discussion about the business requirements. Info-Tech recommends using business process modelling (BPM) as the most effective framework. The BA can now work through several key questions:
The second key element to elicitation is using the right blend of elicitation techniques: the tactical approach used to actually collect the requirements. Interviews are the most popular means, but focus groups, JAD sessions, and observational techniques can often yield better results – faster. This section will touch on BPM/BPI as an elicitation framework, then do deep dive on different elicitation techniques.
Stakeholders must be identified, and elicitation frameworks and techniques selected. Each technique requires different preparation. For example, brainstorming requires ground rules; focus groups require invitations, specific focus areas, and meeting rooms (perhaps even cameras). Look at each of these techniques and discuss how you would prepare.
A good elicitor has the following underlying competencies: analytical thinking, problem solving, behavioral characteristics, business knowledge, communication skills, interaction skills, and proficiency in BA tools. In both group and individual elicitation techniques, interpersonal proficiency and strong facilitation is a must. A good BA has an intuitive sense of how to manage the flow of conversations, keep them results-oriented, and prevent stakeholder tangents or gripe sessions.
How you document will depend on the technique you use. For example, recording and transcribing a focus group is probably a good idea, but you still need to analyze the results and determine the actual requirements. Use cases demand a software tool – without one, they become cumbersome and unwieldy. Consider how you would document the results before you choose the technique. Some analysts prefer to use solutions like OneNote or Evernote for capturing the raw initial notes, others prefer pen and paper: it’s what works best for the BA at hand.
Review the documentation with your stakeholder and confirm the understanding of each requirement via active listening skills. Revise requirements as necessary. Circulating the initial notes of a requirements interview or focus group is a great practice to get into – it ensures jargon and acronyms are correctly captured, and that nothing has been lost in the initial translation.
BPMs can take multiple forms, but they are created as visual process flows that depict a series of events. They can be customized at the discretion of the requirements gathering team (swim lanes, legends, etc.) based on the level of detail needed from the input.
BPMs can be used as the basis for further process improvement or re-engineering efforts for IT and applications projects. When the requirements gathering process owner needs to validate whether or not a specific step involved in the process is necessary, BPM provides the necessary breakdown.
Different individuals absorb information in a variety of ways. Visual representations of a process or set of steps tend to be well received by a large sub-set of individuals, making BPMs an effective analysis technique.
This related Info-Tech blueprint provides an extremely thorough overview of how to leverage BPM and process improvement approaches.
Build a Sales Report | |
---|---|
|
|
|
|
|
|
|
|
Source: iSixSigma
Look at an example for a claims process, and focus on the Record Claim task (event).
Task | Input | Output | Risks | Opportunities | Condition | Sample Requirements |
---|---|---|---|---|---|---|
Record Claim | Customer Email | Case Record |
|
|
|
Business:
Non-Functional:
Functional:
|
Conducting elicitation typically takes the greatest part of the requirements management process. During elicitation, the designated BA(s) should be reviewing documentation, and conducting individual and group sessions with key stakeholders.
Elicitation is an iterative process – requirements should be refined in successive steps. If you need more information in the analysis phases, don’t be afraid to go back and conduct more elicitation.
Document any changes to the elicitation techniques in section 4.0 of the Requirements Gathering SOP and BA Playbook.
Technique | Description | Assessment and Best Practices | Stakeholder Effort | BA Effort |
---|---|---|---|---|
Structured One-on-One Interview | In a structured one-on-one interview, the BA has a fixed list of questions to ask the stakeholder and follows up where necessary. | Structured interviews provide the opportunity to quickly home in on areas of concern that were identified during process mapping or group elicitation techniques. They should be employed with purpose, i.e. to receive specific stakeholder feedback on proposed requirements or to help identify systemic constraints. Generally speaking, they should be 30 minutes or less. | Low | Medium |
Unstructured One-on-One Interview | In an unstructured one-on-one interview, the BA allows the conversation to flow free form. The BA may have broad themes to touch on but does not run down a specific question list. | Unstructured interviews are most useful for initial elicitation, when brainstorming a draft list of potential requirements is paramount. Unstructured interviews work best with senior stakeholders (sponsors or power users), since they can be time consuming if they’re applied to a large sample size. It’s important for BAs not to stifle open dialogue and allow the participants to speak openly. They should be 60 minutes or less. | Medium | Low |
Interviews should be used with high-value targets. Those who receive one-on-one face time can help generate good requirements, as well as allow effective communication around requirements at a later point (i.e. during the analysis and validation phases).
Use a clear interview approach to guide the preparation, facilitation styles, participants, and interview schedules you manage for a specific project.
Depending on your stakeholder audience and interview objectives, apply one or more of the following approaches to interviews.
Fosters direct engagement
IT is able to hear directly from stakeholders about what they are looking to do with a solution and the level of functionality that they expect from it.
Offers greater detail
With interviews, a greater degree of insight can be gained by leveraging information that wouldn’t be collected through traditional surveys. Face-to-face interactions provide thorough answers and context that helps inform requirements.
Removes ambiguity
Face-to-face interactions allow opportunities for follow-up around ambiguous answers. Clarify what stakeholders are looking for and expect in a project.
Enables stakeholder management
Interviews are a direct line of communication with a project stakeholder. They provide input and insight, and help to maintain alignment, plan next steps, and increase awareness within the IT organization.
Consider stakeholder types and characteristics, in conjunction with the best way to maximize time, when selecting which of the three interview structures to leverage during the elicitation phase of requirements gathering.
Review the following questions to determine what interview structure you should utilize. If you answer the question with “Yes,” then follow the corresponding recommendations for the interview elements.
Question | Structure Type | Facilitation Technique | # of Participants |
---|---|---|---|
Do you have to interview multiple participants at once because of time constraints? | Semi-structured | Discussion | 1+ |
Does the business or stakeholders want you to ask specific questions? | Structured | Q&A | 1 |
Have you already tried an unsuccessful survey to gather information? | Semi-structured | Discussion | 1+ |
Are you utilizing interviews to understand the area? | Unstructured | Discussion | 1+ |
Do you need to gather requirements for an immediate project? | Structured | Q&A | 1+ |
Interviews should be used with high-value targets. Those who receive one-on-one face time can help generate good requirements and allow for effective communication around requirements during the analysis and validation stages.
Interviews generally follow the same workflow regardless of which structure you select. You must manage the process to ensure that the interview runs smoothly and results in an effective gathering requirements process.
The interview process may grind to a halt due to challenging situations. Below are common scenarios and corresponding troubleshooting techniques to get your interview back on track.
Scenario | Technique |
---|---|
Quiet interviewee | Begin all interviews by asking courteous and welcoming questions. This technique will warm the interviewee up and make them feel more comfortable. Ask prompting questions during periods of silence in the interview. Take note of the answers provided by the interviewee in your interview guide, along with observations and impact statements that occur throughout the duration of the interview process. |
Disgruntled interviewee | Avoid creating a hostile environment by eliminating the interviewee’s perception that you are choosing to focus on issues that the interviewee feels will not be resolved. Ask questions to contextualize the issue. For example, ask why they feel a particular way about the issue, and determine whether they have valid concerns that you can resolve. |
Interviewee has issues articulating their answer | Encourage the interviewee to use a whiteboard or pen and paper to kick start their thought process. Make sure you book a room with these resources readily available. |
Technique | Description | Assessment and Best Practices | Stakeholder Effort | BA Effort |
---|---|---|---|---|
Casual Observation | The process of observing stakeholders performing tasks where the stakeholders are unaware they are being observed. | Capture true behavior through observation of stakeholders performing tasks without informing them they are being observed. This information can be valuable for mapping business process; however, it is difficult to isolate the core business activities from unnecessary actions. | Low | Medium |
Formal Observation | The process of observing stakeholders performing tasks where the stakeholders are aware they are being observed. | Formal observation allows BAs to isolate and study the core activities in a business process because the stakeholder is aware they are being observed. Stakeholders may become distrusting of the BA and modify their behavior if they feel their job responsibilities or job security are at risk | Low | Medium |
Info-Tech Insight
Observing stakeholders does not uncover any information about the target state. Be sure to use contextual observation in conjunction with other techniques to discover the target state.
Technique | Description | Assessment and Best Practices | Stakeholder Effort | BA Effort |
---|---|---|---|---|
Closed-Response Survey | A survey that has fixed responses for each answer. A Likert-scale (or similar measures) can be used to have respondents evaluate and prioritize possible requirements. | Closed response surveys can be sent to large groups and used to quickly gauge user interest in different functional areas. They are easy for users to fill out and don’t require a high investment of time. However, their main deficit is that they are likely to miss novel requirements not listed. As such, closed response surveys are best used after initial elicitation or brainstorming to validate feature groups. | Low | Medium |
Open-Response Survey | A survey that has open-ended response fields. Questions are fixed, but respondents are free to populate the field in their own words. Open-response surveys take longer to fill out than closed, but can garner deeper insights. | Open-response surveys are a useful supplement (and occasionally replacement) for group elicitation techniques, like focus groups, when you need to receive an initial list of requirements from a broad cross-section of stakeholders. Their primary shortcoming is the analyst can’t immediately follow up on interesting points. However, they are particularly useful for reaching stakeholders who are unavailable for individual one-on-ones or group meetings. | Low | Medium |
Info-Tech Insight
Surveys can be useful mechanisms for initial drafting of raw requirements (open-response) and gauging user interest in proposed requirements or feature sets (closed-response). However, they should not be the sole focus of your elicitation program due to lack of interactivity and two-way dialogue with the BA.
What are surveys?
Surveys take a sample population’s written responses for data collection. Survey respondents can identify themselves or choose to remain anonymous. Anonymity removes the fear of repercussions for giving critical responses to sensitive topics.
Who needs to be involved?
Participants of a survey include the survey writer, respondent(s), and results compiler. There is a moderate amount of work that comes from both the writer and compiler, with little work involved on the end of the respondent.
What are the benefits?
The main benefit of surveys is their ability to reach large population groups and segments without requiring personal interaction, thus saving money. Surveys are also very responsive and can be created and modified rapidly to address needs as they arise on an on-going basis.
Surveys are most valuable when completed early in the requirements gathering stage.
Intake and Scoping → Requirements Gathering → Solution Design → Development/ Procurement → Implementation/ Deployment
When a project is announced, develop surveys to gauge what users consider must-have, should-have, and could-have requirements.
Use surveys to profile the demand for specific requirements.
It is often difficult to determine if requirements are must haves or should haves. Surveys are a strong method to assist in narrowing down a wide range of requirements.
Are surveys worth the time and effort? Most of the time.
Surveys can generate insights. However, there are potential barriers:
Surveys should only be done if the above barriers can easily be overcome.
Scenario
There is an unclear picture of the business needs and functional requirements for a solution.
Survey Approach
Use open-ended questions to allow respondents to propose requirements they see as necessary.
Sample questions
What to do with your results
Take a step back
If you are using surveys to elicit a large number of requirements, there is probably a lack of clear scope and vision. Focus on scope clarification. Joint development sessions are a great technique for defining your scope with SMEs.
Moving ahead
Proper survey design determines how valuable the responses will be. Review survey principles released by the University of Wisconsin-Madison.
Provide context
Include enough detail to contextualize questions to the employee’s job duties.
Where necessary:
Give clear instructions
When introducing a question identify if it should be answered by giving one answer, multiple answers, or a ranking of answers.
Avoid IT jargon
Ensure the survey’s language is easily understood.
When surveying colleagues from the business use their own terms, not IT’s.
E.g. laptops vs. hardware
Saying “laptops” is more detailed and is a universal term.
Use ranges
Recommended:
In a month your Outlook fails:
Not Recommended:
Your Outlook fails:
Keep surveys short
Improve responses and maintain stakeholder interest by only including relevant questions that have corresponding actions.
Recommended: Keep surveys to ten or less prompts.
Scenario
There is a large list of requirements and the business is unsure of which ones to further pursue.
Survey Approach
Use closed-ended questions to give degrees of importance and rank requirements.
Sample questions
What to do with your results
Determine which requirements to further explore
Avoid simply aggregating average importance and using the highest average as the number-one priority. Group the highest average importance requirements to be further explored with other elicitation techniques.
Moving ahead
The group of highly important requirements needs to be further explored during interviews, joint development sessions, and rapid development sessions.
Scenario
The business wanted a closer look into a specific process to determine if the project could be improved to better address process issues.
Survey Approach
Use open-ended questions to allow employees to articulate very specific details of a process.
Sample questions
What to do with your results
Set up prototyping
Prototype a portion with the new requirement to see if it meets the user’s needs. Joint application development and rapid development sessions pair developers and users together to collaboratively build a solution.
Next steps
Free online surveys offer quick survey templates but may lack customization. Paid options include customizable features. Studies show that most participants find web-based surveys more appealing, as web surveys tend to have a higher rate of completion.
Potential Services (Not a comprehensive list)
SurveyMonkey – free and paid options
Good Forms – free options
Ideal for:
Paper surveys offer complete customizability. However, paper surveys take longer to distribute and record, and are also more expensive to administer.
Ideal for:
Internally-developed surveys can be distributed via the intranet or email. Internal surveys offer the most customization. Cost is the creator’s time, but cost can be saved on distribution versus paper and paid online surveys.
Ideal for:
Technique | Description | Assessment and Best Practices | Stakeholder Effort | BA Effort |
---|---|---|---|---|
Focus Group | Focus groups are sessions held between a small group (typically ten individuals or less) and an experienced facilitator who leads the conversation in a productive direction. | Focus groups are highly effective for initial requirements brainstorming. The best practice is to structure them in a cross-functional manner to ensure multiple viewpoints are represented, and the conversation doesn’t become dominated by one particular individual. Facilitators must be wary of groupthink in these meetings (i.e. the tendency to converge on a single POV). | Medium | Medium |
Workshop | Workshops are larger sessions (typically ten people or more) that are led by a facilitator, and are dependent on targeted exercises. Workshops may be occasionally decomposed into smaller group sessions. | Workshops are highly versatile: they can be used for initial brainstorming, requirement prioritization, constraint identification, and business process mapping. Typically, the facilitator will use exercises or activities (such as whiteboarding, sticky note prioritization, role-playing, etc.) to get participants to share and evaluate sets of requirements. The main downside to workshops is a high time commitment from both stakeholders and the BA. | Medium | High |
Info-Tech Insight
Group elicitation techniques are most useful for gathering a wide spectrum of requirements from a broad group of stakeholders. Individual or observational techniques are typically needed for further follow-up and in-depth analysis with critical power users or sponsors.
There are two specific types of group interviews that can be utilized to elicit requirements: focus groups and workshops. Understand each type’s strengths and weaknesses to determine which is better to use in certain situations.
Focus Groups | Workshops | |
---|---|---|
Description |
|
|
Strengths |
|
|
Weaknesses |
|
|
Facilitation Guidance |
|
|
Technique | Description | Assessment and Best Practices | Stakeholder Effort | BA Effort |
---|---|---|---|---|
Solution Mapping Session | A one-on-one session to outline business processes. BPM methods are used to write possible target states for the solution on a whiteboard and to engineer requirements based on steps in the model. | Solution mapping should be done with technically savvy stakeholders with a firm understanding of BPM methodologies and nomenclature. Generally, this type of elicitation method should be done with stakeholders who participated in tier one elicitation techniques who can assist with reverse-engineering business models into requirement lists. | Medium | Medium |
Joint Requirements Review Session | This elicitation method is sometimes used as a last step prior to moving to formal requirements analysis. During the review session, the rough list of requirements is vetted and confirmed with stakeholders. | A one-on-one (or small group) requirements review session gives your BAs the opportunity to ensure that what was recorded/transcribed during previous one-on-ones (or group elicitation sessions) is materially accurate and representative of the intent of the stakeholder. This elicitation step allows you to do a preliminary clean up of the requirements list before entering the formal analysis phase. | Low | Low |
Info-Tech Insight
Solution mapping and joint requirements review sessions are more advanced elicitation techniques that should be employed after preliminary techniques have been utilized. They should be reserved for technically sophisticated, high-value stakeholders.
Technique | Description | Assessment and Best Practices | Stakeholder Effort | BA Effort |
---|---|---|---|---|
Interactive White- boarding | A group session where either a) requirements are converted to BPM diagrams and process flows, or b) these flows are reverse engineered to distil requirement sets. | While the focus of workshops and focus groups is more on direct requirements elicitation, interactive whiteboarding sessions are used to assist with creating initial solution maps (or reverse engineering proposed solutions into requirements). By bringing stakeholders into the process, the BA benefits from a greater depth of experience and access to SMEs. | Medium | Medium |
Joint Application Development (JAD) | JAD sessions pair end-user teams together with developers (and BA facilitators) to collect requirements and begin mapping and developing prototypes directly on the spot. | JAD sessions fit well with organizations that use Agile processes. They are particularly useful when the overall project scope is ambiguous; they can be used for project scoping, requirements definition, and initial prototyping. JAD techniques are heavily dependent on having SMEs in the room – they should preference knowledge power users over the “rank and file.” | High | High |
Info-Tech Insight
Interactive whiteboarding should be heavily BPM-centric, creating models that link requirements to specific workflow activities. Joint development sessions are time-consuming but create greater cohesion and understanding between BAs, developers, and SMEs.
Technique | Description | Assessment and Best Practices | Stakeholder Effort | BA Effort |
---|---|---|---|---|
Rapid Application Development | A form of prototyping, RAD sessions are akin to joint development sessions but with greater emphasis on back-and-forth mock-ups of the proposed solution. | RAD sessions are highly iterative – requirements are gathered in sessions, developers create prototypes offline, and the results are validated by stakeholders in the next meeting. This approach should only be employed in highly Agile-centric environments. | High | High |
For more information specific to using the Agile development methodology, refer to the project blueprint Implement Agile Practices That Work.
The role of the BA differs with an Agile approach to requirements gathering. A traditional BA is a subset of the Agile BA, who typically serves as product owner. Agile BAs have elevated responsibilities that include bridging communication between stakeholders and developers, prioritizing and detailing the requirements, and testing solutions.
Use the following slides to gain a thorough understanding of both JAD and rapid development sessions (RDS) to decide which fits your project best.
Joint Application Development | Rapid Development Sessions | |
---|---|---|
Description | JAD pairs end users and developers with a facilitator to collect requirements and begin solution mapping to create an initial prototype. | RDS is an advanced approach to JAD. After an initial meeting, prototypes are developed and validated by stakeholders. Improvements are suggested by stakeholders and another prototype is created. This process is iterated until a complete solution is created. |
Who is involved? | End users, SMEs, developers, and a facilitator (you). | |
Who should use this technique? | JAD is best employed in an Agile organization. Agile organizations can take advantage of the high amount of collaboration involved. RDS requires a more Agile organization that can effectively and efficiently handle impromptu meetings to improve iterations. | |
Time/effort versus value | JAD is a time/effort-intensive activity, requiring different parties at the same time. However, the value is well worth it. JAD provides clarity for the project’s scope, justifies the requirements gathered, and could result in an initial prototype. | RDS is even more time/effort intensive than JAD. While it is more resource intensive, the reward is a more quickly developed full solution that is more customized with fewer bugs. |
Projects that use JAD should not expect dramatically quicker solution development. JAD is a thorough look at the elicitation process to make sure that the right requirements are found for the final solution’s needs. If done well, JAD eliminates rework.
Employees vary in their project engagement. Certain employees leverage JAD because they care about the solution. Others are asked for their expertise (SMEs) or because they perform the process often and understand it well.
JAD’s thorough process guarantees that requirements gathering is done well.
Projects that use RDS can either expect quicker or slower requirements gathering depending on the quality of iteration. If each iteration solves a requirement issue, then one can expect that the solution will be developed fairly rapidly. If the iterations fail to meet requirements the process will be quite lengthy.
Employees doing RDS are typically very engaged in the project and play a large role in helping to create the solution.
RDS success is tied to the organization’s ability to collaborate. Strong collaboration will lead to:
Poor collaboration will lead to RDS losing its full value.
JAD is best employed in an Agile organization for application development and selection. This technique best serves relatively complicated, large-scale projects that require rapid or sequential iterations on a prototype or solution as a part of requirements gathering elicitation. JAD effectuates each step in the elicitation process well, from initial elicitation to narrowing down requirements.
Most requirement gathering professionals will use their experience with project type standards to establish key requirements. Avoid only relying on standards when tackling a new project type. Apply JAD’s structured approach to a new project type to be thorough during the elicitation phase.
While JAD is an overarching requirements elicitation technique, it should not be the only one used. Combine the strengths of other elicitation techniques for the best results.
RDS is best utilized when one, but preferably both, of the below criteria is met.
RDS’ strengths lie in being able to tailor-make certain aspects of the solution. If the solution is too large, tailor-made sections are impossible as multiple user groups have different needs or there is insufficient resources. When a project is small to medium sized, developers can take the time to custom make sections for a specific user group.
RDS requires developers spending a large amount of time with users, leaving less time for development. Having developers at the ready to take on users’ improvement maintains the effectiveness of RDS. If the same developer who speaks to users develops the entire iteration, the process would be slowed down dramatically, losing effectiveness.
JAD relies on unstructured conversations to clarify scope, gain insights, and discuss prototyping. However, a structure must exist to guarantee that all topics are discussed and meetings are not wasted.
JAD often involves visually illustrating how high-level concepts connect as well as prototypes. Use solution mapping and interactive whiteboarding to help users and participants better understand the solution.
Having a group development session provides all the benefits of focus groups while reducing time spent in the typically time-intensive JAD process.
1. Prepare for the meeting
Email all parties a meeting overview of topics that will be discussed.
2. Discussion
3. Wrap-up
4. Follow-up
JAD provides a detail-oriented view into the elicitation process. As a facilitator, take detailed notes to maximize the outputs of JAD.
1. Prepare for the meeting
2. Hold the discussion
3. Wrap-up
4. Follow-up
RDS is best done in quick succession. Keep in constant contact with both employees and developers to maintain positive momentum from a successful iteration improvement.
JAD/RDS are both collaborative activities, and as with all group activities, issues are bound to arise. Be proactive and resolve issues using the following guidelines.
Scenario | Technique |
---|---|
Employee and developer visions for the solution don’t match up | Focus on what both solutions have in common first to dissolve any tension. Next, understand the reason why both parties have differences. Was it a difference in assumptions? Difference in what is a requirement? Once the answer has been determined, work on bridging the gaps. If there is no resolution, appoint a credible authority (or yourself) to become the final decision maker. |
Employee has difficulty understanding the technical aspect of the developer’s solution | Translate the developer’s technical terms into a language that the employee understands. Encourage the employee to ask questions to further their understanding. |
Employee was told that their requirement or proposed solution is not feasible | Have a high-level member of the development team explain how the requirement/solution is not feasible. If it’s possible, tell the employee that the requirement can be done in a future release and keep them updated. |
Technique | Description | Assessment and Best Practices | Stakeholder Effort | BA Effort |
---|---|---|---|---|
Legacy System Manuals | The process of reviewing documentation and manuals associated with legacy systems to identify constraints and exact requirements for reuse. | Reviewing legacy systems and accompanying documentation is an excellent way to gain a preliminary understanding of the requirements for the upcoming application. Be careful not to overly rely on requirements from legacy systems; if legacy systems have a feature set up one way, this does not mean it should be set up the same way on the upcoming application. If an upcoming application must interact with other systems, it is ideal to understand the integration points early. | None | High |
Historical Projects | The process of reviewing documentation from historical projects to extract reusable requirements. | Previous project documentation can be a great source of information and historical lessons learned. Unfortunately, historical projects may not be well documented. Historical mining can save a great deal of time; however, the fact that it was done historically does not mean that it was done properly. | None | High |
Info-Tech Insight
Document mining is a laborious process, and as the term “mining” suggests the yield will vary. Regardless of the outcome, document mining must be performed and should be viewed as an investment in the requirements gathering process.
Technique | Description | Assessment and Best Practices | Stakeholder Effort | BA Effort |
---|---|---|---|---|
Rules | The process of extracting business logic from pre-existing business rules (e.g. explicit or implied workflows). | Stakeholders may not be fully aware of all of the business rules or the underlying rationale for the rules. Unfortunately, business rule documents can be lengthy and the number of rules relevant to the project will vary. | None | High |
Glossary | The process of extracting terminology and definitions from glossaries. | Terminology and definitions do not directly lead to the generation of requirements. However, reviewing glossaries will allow BAs to better understand domain SMEs and interpret their requirements. | None | High |
Policy | The process of extracting business logic from business policy documents (e.g. security policy and acceptable use). | Stakeholders may not be fully aware of the different policies or the underlying rationale for why they were created. Going directly to the source is an excellent way to identify constraints and requirements. Unfortunately, policies can be lengthy and the number of items relevant to the project will vary. | None | High |
Info-Tech Insight
Document mining should be the first type of elicitation activity that is conducted because it allows the BA to become familiar with organizational terminology and processes. As a result, the stakeholder facing elicitation sessions will be more productive.
1. Glossary
Extract terminology and definitions from glossaries. A glossary is an excellent source to understand the terminology that SMEs will use.
2. Policy
Pull business logic from policy documents (e.g. security policy and acceptable use). Policies generally have mandatory requirements for projects, such as standard compliance requirements.
3. Rules
Review and reuse business logic that comes from pre-existing rules (e.g. explicit or implied workflows). Like policies, rules often have mandatory requirements or at least will require significant change for something to no longer be a requirement.
4. Legacy System
Review documents and manuals of legacy systems, and identify reusable constraints and requirements. Benefits include:
Remember to not use all of the basic requirements of a legacy system. Always strive to find a better, more productive solution.
5. Historical Projects
Review documents from historical projects to extract reusable requirements. Lessons learned from the company’s previous projects are more applicable than case studies. While historical projects can be of great use, consider that previous projects may not be well documented.
Project managers frequently state that aligning projects to the business goals is a key objective of effective project management; however, it is rarely carried out throughout the project itself. This gap is often due to a lack of understanding around how to create true alignment between individual projects and the business needs.
Extract business wants and needs from official statements and reports (e.g. press releases, yearly reports). Statements and reports outline where the organization wants to go which helps to unearth relevant project requirements.
Documented requirements should always align with the scope of the project and the business objectives. Refer back frequently to your set of gathered requirements to check if they are properly aligned and ensure the project is not veering away from the original scope and business objectives.
The largest problem with documentation review is that requirements gathering professionals do it for the sake of saying they did it. As a result, projects often go off course due to not aligning to business objectives following the review sessions.
There is a time and place for each technique. Don’t become too reliant on the same ones. Diversify your approach based on the elicitation goal.
This table shows the relative strengths and weaknesses of each elicitation technique compared against the five basic elicitation scenarios.
A typical project will encounter most of the elicitation scenarios. Therefore, it is important to utilize a healthy mix of techniques to optimize effectiveness.
Very Strong = Very Effective
Strong = Effective
Medium = Somewhat Effective
Weak = Minimally Effective
Very Weak = Not Effective
Record the approved elicitation methods and best practices for each technique in the SOP.
Identify which techniques should be utilized with the different stakeholder classes.
Segment the different techniques based by project complexity level.
Use the following chart to record the approved techniques.
Stakeholder | L1 Projects | L2 Projects | L3 Projects | L4 Projects |
---|---|---|---|---|
Senior Management | Structured Interviews | |||
Project Sponsor | Unstructured Interviews | |||
SME (Business) | Focus Groups | Unstructured Interviews | ||
Functional Manager | Focus Groups | Structured Interviews | ||
End Users | Surveys; Focus Groups; Follow-Up Interviews; Observational Techniques |
Document the output from this exercise in section 4.0 of the Requirements Gathering SOP and BA Playbook.
Open lines of communication with stakeholders and keep them involved in the requirements gathering process; confirm the initial elicitation before proceeding.
Confirming the notes from the elicitation session with stakeholders will result in three benefits:
This is the Confirm stage of the Confirm, Verify, Approve process.
“Are these notes accurate and complete?”
An analyst will walk you through the different elicitation techniques including observations, document reviews, surveys, focus groups, and interviews, and highlight the level of effort required for each.
An analyst will facilitate the discussion to determine which techniques should be utilized with the different stakeholder classes.
1.1 Understand the Benefits of Requirements Optimization
1.2 Determine Your Target State for Requirements Gathering
2.1 Determine Elicitation Techniques
2.2 Structure Elicitation Output
3.1 Create Analysis Framework
3.2 Validate Business Requirements
4.1 Create Control Processes for Requirements Changes
4.2 Build Requirements Governance and Communication Plan
Unstructured notes for each requirement are difficult to manage and create ambiguity. Using solution-oriented formats during elicitation sessions ensures that the content can be digested by IT and business users.
This table shows common solution-oriented formats for recording requirements. Determine which formats the development team and BAs are comfortable using and create a list of acceptable formats to use in projects.
Format | Description | Examples |
---|---|---|
Behavior Diagrams | These diagrams describe what must happen in the system. | Business Process Models, Swim Lane Diagram, Use Case Diagram |
Interaction Diagrams | These diagrams describe the flow and control of data within a system. | Sequence Diagrams, Entity Diagrams |
Stories | These text-based representations take the perspective of a user and describe the activities and benefits of a process. | Scenarios, User Stories |
Info-Tech Insight
Business process modeling is an excellent way to visually represent intricate processes for both IT and business users. For complex projects with high business significance, business process modeling is the best way to capture requirements and create transformational gains.
Define Use Cases for Each Stakeholder
Define Applications for Each Use Case
Consider the following guidelines:
Use cases can conflict with each other. In certain situations, specific requirements of these use cases may clash with one another even though they are functionally sound. Evaluate use-case requirements and determine how they satisfy the overall business need.
Use cases are not necessarily isolated; they can be nested. Certain functionalities are dependent on the results of another action, often in a hierarchical fashion. By mapping out the expected workflows, BAs can determine the most appropriate way to implement.
Use cases can be functionally implemented in many ways. There could be multiple ways to accomplish the same use case. Each of these needs to be documented so that functional testing and user documentation can be based on them.
Log Into Account | ← Depends on (Nested) | Ordering Products Online |
---|---|---|
Enter username and password | Complete order form | |
Verify user is a real person | Process order | |
Send user forgotten password message | Check user’s account | |
Send order confirmation to user |
Inspector: Log into system → Search for case → Identify recipient → Determine letter type → Print letter
Admin: Receive letter from inspector → Package and mail letter
Citizen: Receive letter from inspector
What are they?
User stories describe what requirement a user wants in the solution and why they want it. The end goal of a user story is to create a simple description of a requirement for developers.
When to use them
User stories should always be used in requirements gathering. User stories should be collected throughout the elicitation process. Try to recapture user stories as new project information is released to capture any changes in end-customer needs.
What’s the benefit?
User stories help capture target users, customers, and stakeholders. They also create a “face” for individual user requirements by providing user context. This detail enables IT leaders to associate goals and end objectives with each persona.
Takeaway
To better understand the characteristics driving user requirements, begin to map objectives to separate user personas that represent each of the project stakeholders.
Are user stories worth the time and effort?
Absolutely.
A user’s wants and needs serve as a constant reminder to developers. Developers can use this information to focus on how a solution needs to accomplish a goal instead of only focusing on what goals need to be completed.
Instructions
As a | I want to | So that | Size | Priority |
---|---|---|---|---|
Developer | Learn network and system constraints | The churn between Operations and I will be reduced. | 1 point | Low |
Team member |
Increase the number of demonstrations | I can achieve greater alignment with business stakeholders. | 3 points | High |
Product owner | Implement a user story prioritization technique | I can delegate stories in my product backlog to multiple Agile teams. | 3 points | Medium |
Keep your user stories short and impactful to ensure that they retain their impact.
As a [stakeholder title], I want to [one requirement] so that [reason for wanting that requirement].
Use this template for all user stories. Other formats will undermine the point of a user story. Multiple requirements from a single user must be made into multiple stories and given to the appropriate developer. User stories should fit onto a sticky note or small card.
As an: | I want to: | So that: | |
---|---|---|---|
✓ | Administrator | Integrate with Excel | File transfer won’t possibly lose information |
X | Administrator | Integrate with Excel and Word | File transfer won’t possibly lose information |
While the difference between the two may be small, it would still undermine the effectiveness of a user story. Different developers may work on the integration of Excel or Word and may not receive this user story.
Size is an estimate of how many resources must be dedicated to accomplish the want. Assign a size to each user story to help determine resource allocation.
Based on how important the requirement is to project success, assign each user story a rating of high, medium, or low. The priority given will dictate which requirements are completed first.
Example:
Scope: Design software to simplify financial reporting
User Story | Estimated Size | Priority |
---|---|---|
As an administrator, I want to integrate with Excel so that file transfer won’t possibly lose information. | Low | High |
As an administrator, I want to simplify graph construction so that I can more easily display information for stakeholders. | High | Medium |
Combine both size and priority to decide resource allocation. Low-size, high-priority tasks should always be done first.
When collecting user stories, many will be centered around the same requirement. Group similar user stories together to show the need for that requirement’s inclusion in the solution.
Even if it isn’t a must-have requirement, if the number of similar user stories is high enough, it would become the most important should-have requirement.
As an | I want | So that |
---|---|---|
Administrator | To be able to create bar graphs | Information can be more easily illustrated |
Accountant | To be able to make pie charts | Budget information can be visually represented |
Both user stories are about creating charts and would be developed similarly.
As an | I want | So that |
---|---|---|
Administrator | The program to auto-save | Information won’t be lost during power outages |
Accountant | To be able to save to SharePoint | My colleagues can easily view and edit my work |
While both stories are about saving documents, the development of each feature is vastly different.
User profiles are a way of grouping users based on a significant shared details (e.g. in the finance department, website user).
Go beyond the user profile
When creating the profile, consider more than the group’s name. Ask yourself the following questions:
For example, if a user profile has low expertise but interacts and depends heavily on the program, a more thorough tutorial of the FAQ section is needed.
Profiles put developers in user’s shoes
Grouping users together helps developers put a face to the name. Developers can then more easily empathize with users and develop an end solution that is directly catered to their needs.
Work in groups to run through the following story-sizing activities.
Planning Poker: This approach uses the Delphi method where members estimate the size of each user story by revealing numbered cards. These estimates are then discussed and agreed upon as a group.
Team Sort: This approach can assist in expediting estimation when you are handling numerous user stories.
Use the product backlog to capture expected work and create a roadmap for the project by showing what requirements need to be delivered.
How is the product owner involved?
How do I create a product backlog?
What are the approaches to generate my backlog?
Epics and Themes
As you begin to take on larger projects, it may be advantageous to organize and group your user stories to simplify your release plan:
To avoid confusion, the pilot product backlog will be solely composed of user stories.
Example:
Theme: Increase user exposure to corporate services through mobile devices | |
---|---|
Epic: Access corporate services through a mobile application | Epic: Access corporate services through mobile website |
User Story: As a user, I want to find the closest office so that I can minimize travel time As a user, I want to find the closest office so that I can minimize travel time | User Story: As a user, I want to submit a complaint so that I can improve company processes |
Overview
Leverage Info-Tech’s Scrum Documentation Template, using the Backlog and Planning tab, to help walk you through this activity.
Instructions
Examples:
As a citizen, I want to know about road construction so that I can save time when driving. Business Value: High
As a customer, I want to find the nearest government office so that I can register for benefits. Business Value: Medium
As a voter, I want to know what each candidate believes in so that I can make an informed decision. Business Value: High
2.2.1 Build use-case models
An analyst will assist in demonstrating how to use elicitation techniques to build use-case models. The analyst will walk you through the table testing to visually map out and design process flows for each use case.
Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.
Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.
Start with an analyst kick off call:
Then complete these activities…
With these tools & templates:
Review findings with analyst:
Then complete these activities…
With these tools & templates:
Phase 3 Results & Insights:
1.1 Understand the Benefits of Requirements Optimization
1.2 Determine Your Target State for Requirements Gathering
2.1 Determine Elicitation Techniques
2.2 Structure Elicitation Output
3.1 Create Analysis Framework
3.2 Validate Business Requirements
4.1 Create Control Processes for Requirements Changes
4.2 Build Requirements Governance and Communication Plan
The analysis phase is where requirements are compiled, categorized, and prioritized to make managing large volumes easier. Many organizations prematurely celebrate being finished the elicitation phase and do not perform adequate diligence in this phase; however, the analysis phase is crucial for a smooth transition into validation and application development or procurement.
Eliciting requirements is an important step in the process, but turning endless pages of notes into something meaningful to all stakeholders is the major challenge.
Begin the analysis phase by categorizing requirements to make locating, reconciling, and managing them much easier. There are often complex relationships and dependencies among requirements that do not get noted or emphasized to the development team and as a result get overlooked.
Typically, requirements are classified as functional and non-functional at the high level. Functional requirements specify WHAT the system or component needs to do and non-functional requirements explain HOW the system must behave.
Examples
Functional Requirement: The application must produce a sales report at the end of the month.
Non-Functional Requirement: The report must be available within one minute after midnight (EST) of the last day of the month. The report will be available for five years after the report is produced. All numbers in the report will be displayed to two decimal places.
Further sub-categorization of requirements is necessary to realize the full benefit of categorization. Proficient BAs will even work backwards from the categories to drive the elicitation sessions. The categories used will depend on the type of project, but for categorizing non-functional requirements, the Volere Requirements Resources has created an exhaustive list of sub-categories.
Requirements Category | Elements |
Example |
---|---|---|
Look & Feel | Appearance, Style |
User Experience |
Usability & Humanity | Ease of Use, Personalization, Internationalization, Learning, Understandability, Accessibility | Language Support |
Performance | Speed, Latency, Safety, Precision, Reliability, Availability, Robustness, Capacity, Scalability, Longevity | Bandwidth |
Operational & Environmental | Expected Physical Environment, Interfacing With Adjacent Systems, Productization, Release | Heating and Cooling |
Maintainability & Support | Maintenance, Supportability, Adaptability | Warranty SLAs |
Security |
Access, Integrity, Privacy, Audit, Immunity | Intrusion Prevention |
Cultural & Political | Global Differentiation | Different Statutory Holidays |
Legal | Compliance, Standards | Hosting Regulations |
Complete – Expressed a whole idea or statement.
Correct – Technically and legally possible.
Clear – Unambiguous and not confusing.
Verifiable – It can be determined that the system meets the requirement.
Necessary – Should support one of the project goals.
Feasible – Can be accomplished within cost and schedule.
Prioritized – Tracked according to business need levels.
Consistent – Not in conflict with other requirements.
Traceable – Uniquely identified and tracked.
Modular – Can be changed without excessive impact.
Design-independent – Does not pose specific solutions on design.
Document any changes to the requirements categories in section 5.1 of the Requirements Gathering SOP and BA Playbook.
After elicitation, it is very common for an organization to end up with redundant, complementary, and conflicting requirements. Consolidation will make managing a large volume of requirements much easier.
Redundant Requirements | Owner | Priority | |
---|---|---|---|
1. | The application shall feed employee information into the payroll system. | Payroll | High |
2. | The application shall feed employee information into the payroll system. | HR | Low |
Result | The application shall feed employee information into the payroll system. | Payroll & HR | High |
Complementary Requirements | Owner | Priority | |
---|---|---|---|
1. | The application shall export reports in XLS and PDF format. | Marketing | High |
2. | The application shall export reports in CSV and PDF format. | Finance | High |
Result | The application shall export reports in XLS, CSV, and PDF format. | Marketing & Finance | High |
Info-Tech Insight
When collapsing redundant or complementary requirements, it is imperative that the ownership and priority metadata be preserved for future reference. Avoid consolidating complementary requirements with drastically different priority levels.
Conflicting requirements are unavoidable; identify and resolve them as early as possible to minimize rework and grief.
Conflicting requirements occur when stakeholders have requirements that either partially or fully contradict one another, and as a result, it is not possible or practical to implement all of the requirements.
Steps to Resolving Conflict:
Info-Tech Insight
Resolve conflicts whenever possible during the elicitation phase by using cross-functional workshops to facilitate discussions that address and settle conflicts in the room.
Review the outputs from the last exercise and ensure that the list is mutually exclusive by consolidating similar requirements and eliminating redundancies.
Prioritization is the process of ranking each requirement based on its importance to project success. Hold a separate meeting for the domain SMEs, implementation SMEs, project managers, and project sponsors to prioritize the requirements list. At the conclusion of the meeting, each requirement should be assigned a priority level. The implementation SMEs will use these priority levels to ensure efforts are targeted towards the proper requirements as well as to plan features available on each release. Use the MoSCoW Model of Prioritization to effectively order requirements.
The MoSCoW Model of Prioritization
The MoSCoW model was introduced by Dai Clegg of Oracle UK in 1994 (Source: ProductPlan).
Effective Prioritization Criteria
Criteria |
Description |
---|---|
Regulatory & Legal Compliance | These requirements will be considered mandatory. |
Policy Compliance | Unless an internal policy can be altered or an exception can be made, these requirements will be considered mandatory. |
Business Value Significance | Give a higher priority to high-value requirements. |
Business Risk | Any requirement with the potential to jeopardize the entire project should be given a high priority and implemented early. |
Likelihood of Success | Especially in proof-of-concept projects, it is recommended that requirements have good odds. |
Implementation Complexity | Give a higher priority to low implementation difficulty requirements. |
Alignment With Strategy | Give a higher priority to requirements that enable the corporate strategy. |
Urgency | Prioritize requirements based on time sensitivity. |
Dependencies | A requirement on its own may be low priority, but if it supports a high-priority requirement, then its priority must match it. |
Info-Tech Insight
It is easier to prioritize requirements if they have already been collapsed, resolved, and rewritten. There is no point in prioritizing every requirement that is elicited up front when some of them will eventually be eliminated.
Use the Requirements Gathering Documentation Tool to identify and track stakeholder involvement, elicitation techniques, and scheduling, as well as to track categorization and prioritization of requirements.
Using the output from the MoSCoW model, prioritize the requirements according to those you must have, should have, could have, and won’t have.
3.1.1 Create functional requirements categories
An analyst will facilitate the discussion to brainstorm and determine criteria for requirements categories.
3.1.2 Consolidate similar requirements and eliminate redundancies
An analyst will facilitate a session to review the requirements categories to ensure the list is mutually exclusive by consolidating similar requirements and eliminating redundancies.
3.1.3 Prioritize requirements
An analyst will facilitate the discussion on how to prioritize requirements according to the MoSCoW prioritization framework. The analyst will also walk you through the exercise of determining dependencies for each requirement.
1.1 Understand the Benefits of Requirements Optimization
1.2 Determine Your Target State for Requirements Gathering
2.1 Determine Elicitation Techniques
2.2 Structure Elicitation Output
3.1 Create Analysis Framework
3.2 Validate Business Requirements
4.1 Create Control Processes for Requirements Changes
4.2 Build Requirements Governance and Communication Plan
This step involves the following participants:
Outcomes of this step
The validation phase involves translating the requirements, modeling the solutions, allocating features across the phased deployment plan, preparing the requirements package, and getting requirement sign-off. This is the last step in the Info-Tech Requirements Gathering Framework.
Before going for final sign-off, ensure that you have pulled together all of the relevant documentation.
The requirements package is a compilation of all of the business analysis and requirements gathering that occurred. The document will be distributed among major stakeholders for review and sign-off.
Some may argue that the biggest challenge in the validation phase is getting the stakeholders to sign off on the requirements package; however, the real challenge is getting them to actually read it. Often, stakeholders sign the requirements document without fully understanding the scope of the application, details of deployment, and how it affects them.
Remember, this document is not for the BAs; it’s for the stakeholders. Make the package with the stakeholders in mind. Create multiple versions of the requirements package where the length and level of technical details is tailored to the audience. Consider creating a supplementary PowerPoint version of the requirements package to present to senior management.
Contents of Requirements Package:
"Sit down with your stakeholders, read them the document line by line, and have them paraphrase it back to you so you’re on the same page." – Anonymous City Manager of IT Project Planning Info-Tech Interview
The BRD captures the original business objectives and high-level business requirements for the system/process. The system requirements document (SRD) captures the more detailed functional and technical requirements.
The Business Requirements Document Template can be used to record the functional, quality, and usability requirements into formats that are easily consumable for future analysis, architectural and design activities, and most importantly in a format that is understandable by all business partners.
The BRD is designed to take the reader from a high-level understanding of the business processes down to the detailed automation requirements. It should capture the following:
Build the required documentation for requirements gathering.
Document the output from this exercise in section 6 of the Requirements Gathering SOP and BA Playbook.
Practice presenting the requirements document to business stakeholders.
Example:
Typical Requirements Gathering Validation Meeting Agenda | |
---|---|
Project overview | 5 minutes |
Project operating model | 10 minutes |
Prioritized requirements list | 5 minutes |
Business process model | 30 minutes |
Implementation considerations | 5 minutes |
Practice translating business requirements into system requirements.
Download the Requirements Gathering Testing Checklist template.
Identify how to test the effectiveness of different requirements.
Keep the stakeholders involved in the process in between elicitation and sign-off to ensure that nothing gets lost in transition.
After an organization’s requirements have been aggregated, categorized, and consolidated, the business requirements package will begin to take shape. However, there is still a great deal of work to complete. Prior to proceeding with the process, requirements should be verified by domain SMEs to ensure that the analyzed requirements continue to meet their needs. This step is often overlooked because it is laborious and can create additional work; however, the workload associated with verification is much less than the eventual rework stemming from poor requirements.
All errors in the requirements gathering process eventually surface; it is only a matter of time. Control when these errors appear and minimize costs by soliciting feedback from stakeholders early and often.
This is the Verify stage of the Confirm, Verify, Approve process.
“Do these requirements still meet your needs?”
Use the sign-off process as one last opportunity to manage expectations, obtain commitment from the stakeholders, and minimize change requests.
Development or procurement of the application cannot begin until the requirements package has been approved by all of the key stakeholders. This will be the third time that the stakeholders are asked to review the requirements; however, this will be the first time that the stakeholders are asked to sign off on them.
It is important that the stakeholders understand the significance of their signatures. This is their last opportunity to see exactly what the solution will look like and to make change requests. Ensure that the stakeholders also recognize which requirements were omitted from the solution that may affect them.
The sign-off process needs to mean something to the stakeholders. Once a signature is given, that stakeholder must be accountable for it and should not be able to make change requests. Note that there are some requests from senior stakeholders that can’t be refused; use discretion when declining requests.
This is the Approve stage of the Confirm, Verify, Approve process.
"Once requirements are signed off, stay firm on them!" – Anonymous Hospital Business Systems Analyst Info-Tech Interview
3.2.1; 3.2.2 Rightsize the BRD and present it to business stakeholders
An analyst will facilitate the discussion to gather the required documentation for building the BRD. The analyst will also assist with practicing the presenting of each section of the document to business stakeholders.
3.2.3; 3.2.4 Translate business requirements into technical requirements and identify testing opportunities
An analyst will facilitate the session to practice translating business requirements into testing requirements and assist in determining how to test the effectiveness of different requirements.
Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.
Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.
Proposed Time to Completion: 3 weeks
Start with an analyst kick off call:
Then complete these activities…
With these tools & templates:
Review findings with analyst:
Then complete these activities…
With these tools & templates:
Requirements Gathering Communication Tracking Template
1.1 Understand the Benefits of Requirements Optimization
1.2 Determine Your Target State for Requirements Gathering
2.1 Determine Elicitation Techniques
2.2 Structure Elicitation Output
3.1 Create Analysis Framework
3.2 Validate Business Requirements
4.1 Create Control Processes for Requirements Changes
4.2 Build Requirements Governance and Communication Plan
Although the manage, communicate, and test requirements section chronologically falls as the last section of this blueprint, that does not imply that this section is to be performed only at the end. These tasks are meant to be completed iteratively throughout the project to support the core requirements gathering tasks.
Once the stakeholders sign off on the requirements document, any changes need to be tracked and managed. To do that, you need a change control process.
Thoroughly validating requirements should reduce the amount of change requests you receive. However, eliminating all changes is unavoidable.
The BAs, sponsor, and stakeholders should have agreed upon a clearly defined scope for the project during the planning phase, but there will almost always be requests for change as the project progresses. Even a high number of small changes can negatively impact the project schedule and budget.
To avoid scope creep, route all changes, including small ones, through a formal change control process that will be adapted depending on the level of project and impact of the change.
Document any changes from this exercise in section 7.1 of the Requirements Gathering SOP and BA Playbook.
Determine how changes will be escalated for level 1/2/3/4 projects.
Document any changes from this exercise in section 7.2 of the Requirements Gathering SOP and BA Playbook.
Impact Category | Final Decision Rests With Project Manager If: | Escalate to Steering Committee If: | Escalate to Change Control Board If: | Escalate to Sponsor If: |
---|---|---|---|---|
Scope |
|
|
||
Budget |
|
|
|
|
Schedule |
|
|
|
|
Requirements |
|
|
Impact Category | Final Decision Rests With Project Manager If: | Escalate to Steering Committee If: | Escalate to Sponsor If: |
---|---|---|---|
Scope |
|
| |
Budget |
|
| |
Schedule |
|
| |
Requirements |
|
|
Info-Tech Deliverable
Take advantage of Info-Tech’s Requirements Traceability Matrix to track requirements from inception through to testing.
Review the requirements gathering process and control levels for project levels 1/2/3/4 and add as much detail as possible to each process.
Document the output from this exercise in section 2.4 of the Requirements Gathering SOP and BA Playbook.
Understand who is responsible, accountable, consulted, and informed for key elements of the requirements gathering process for project levels 1/2/3/4.
Project Requestor | Project Sponsor | Customers | Suppliers | Subject Matter Experts | Vendors | Executives | Project Management | IT Management | Developer/ Business Analyst | Network Services | Support | |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Intake Form | A | C | C | I | R | |||||||
High-Level Business Case | R | A | C | C | C | C | I | I | C | |||
Project Classification | I | I | C | I | R | A | R | |||||
Project Approval | R | R | I | I | I | I | I | I | A | I | I | |
Project Charter | R | C | R | R | C | R | I | A | I | R | C | C |
Develop BRD | R | I | R | C | C | C | R | A | C | C | ||
Sign-Off on BRD/ Project Charter | R | A | R | R | R | R | ||||||
Develop System Requirements | C | C | C | R | I | C | A | R | R | |||
Sign-Off on SRD | R | R | R | I | A | R | R | |||||
Testing/Validation | A | I | R | C | R | C | R | I | R | R | ||
Change Requests | R | R | C | C | A | I | R | C | ||||
Sign-Off on Change Request | R | A | R | R | R | R | ||||||
Final Acceptance | R | A | R | I | I | I | I | R | R | R | I | I |
4.1.1; 4.1.2 Develop a change control process and guidelines for escalating changes
An analyst will facilitate the discussion on how to improve upon your organization’s change control processes and how changes will be escalated to ensure effective tracking and management of changes.
4.1.3 Confirm your requirements gathering process
With the group, an analyst will review the requirements gathering process and control levels for the different project levels.
4.1.4 Define the RACI for the requirements gathering process
An analyst will facilitate a whiteboard exercise to understand who is responsible, accountable, informed, and consulted for key elements of the requirements gathering process.
1.1 Understand the Benefits of Requirements Optimization
1.2 Determine Your Target State for Requirements Gathering
2.1 Determine Elicitation Techniques
2.2 Structure Elicitation Output
3.1 Create Analysis Framework
3.2 Validate Business Requirements
4.1 Create Control Processes for Requirements Changes
4.2 Build Requirements Governance and Communication Plan
Requirements Governance Responsibilities
1. Provide oversight and review of SOPs pertaining to requirements elicitation, analysis, and validation.
2. Establish corporate policies with respect to requirements gathering SOP training and education of analysts.
3. Prioritize efforts for requirements optimization.
4. Determine and track metrics that will be used to gauge the success (or failure) of requirements optimization efforts and make process and policy changes as needed.
Use a power map to determine which governance model best fits your organization.
This exercise will help to define the purpose statement for the applicable requirements gathering governance team.
Example:
The requirements gathering governance team oversees the procedures that are employed by BAs and other requirements gathering practitioners for [insert company name]. Members of the team are appointed by [insert role] and are accountable to [typically the chair of the committee].
Day-to-day operations of the requirements gathering team are expected to be at the practitioner (i.e. BA) level. The team is not responsible for conducting elicitation on its own, although members of the team may be involved from a project perspective.
Document the output from this exercise in section 3.1 of the Requirements Gathering SOP and BA Playbook.
Industry Not-for-Profit
Source Info-Tech Workshop
This organization is a not-for-profit benefits provider that offers dental coverage to more than 1.5 million people across three states.
With a wide ranging application portfolio that includes in-house, custom developed applications as well as commercial off-the-shelf solutions, the company had no consistent method of gathering requirements.
The organization contracted Info-Tech to help build an SOP to put in place a rigorous and efficient methodology for requirements elicitation, analysis, and validation.
One of the key realizations in the workshop was the need for governance and oversight over the requirements gathering process. As a result, the organization developed a Requirements Management Steering Committee to provide strategic oversight and governance over requirements gathering processes.
The Requirements Management Steering Committee introduced accountability and oversight into the procedures that are employed by BAs. The Committee’s mandate included:
R – Responsible
The one responsible for getting the job done.
A – Accountable
Only one person can be accountable for each task.
C – Consulted
Involvement through input of knowledge and information.
I – Informed
Receiving information about process execution and quality.
Build the participation list and authority matrix for the requirements gathering governance team.
Document any changes from this exercise in section 3.1 of the Requirements Gathering SOP and BA Playbook.
Define your governance team procedures, cadence, and agenda.
Meeting call to order | [Committee Chair] | [Time] |
---|---|---|
Roll call | [Committee Chair] | [Time] |
Review of SOPs | ||
A. Requirements gathering dashboard review | [Presenters, department] | [Time] |
B. Review targets | [Presenters, department] | [Time] |
C. Policy Review | [Presenters, department] | [Time] |
Document any changes from this exercise in section 3.1 of the Requirements Gathering SOP and BA Playbook.
A successful communication plan involves making the initiative visible and creating staff awareness around it. Educate the organization on how the requirements gathering process will differ.
People can be adverse to change and may be unreceptive to being told they must “comply” to new policies and procedures. Demonstrate the value in requirements gathering and show how it will assist people in their day-to-day activities.
By demonstrating how an improved requirements gathering process will impact staff directly, you create a deeper level of understanding across lines-of-business, and ultimately a higher level of acceptance for new processes, rules, and guidelines.
Stakeholder:
Key Stakeholder:
User Group Representatives:
Unwilling – Individuals who are unwilling to change may need additional encouragement. For these individuals, you’ll need to reframe the situation and emphasize how the change will benefit them specifically.
Unable – All involved requirements gathering will need some form of training on the process, committee roles, and responsibilities. Be sure to have training and support available for employees who need it and communicate this to staff.
Unaware – Until people understand exactly what is going on, they will not be able to conform to the process. Communicate change regularly at the appropriate detail to encourage stakeholder support.
Info-Tech Insight
Resisters who have influence present a high risk to the implementation as they may encourage others to resist as well. Know where and why each stakeholder is likely to resist to mitigate risk. A detailed plan will ensure you have the needed documentation and communications to successfully manage stakeholder resistance.
Identify the impact and level of resistance of all stakeholders to come up with the right communication plan.
Use a power map to plot key stakeholders according to influence and involvement.
Use a power map to plot key stakeholders according to influence and involvement.
High Risk:
Stakeholders with high influence who are not as involved in the project or are heavily impacted by the project are less likely to give feedback throughout the project lifecycle and need to be engaged. They are not as involved but have the ability to impact project success, so stay one step ahead.
Do not limit your engagement to kick-off and close – you need to continue seeking input and support at all stages of the project.
Mid Risk:
Key players have high influence, but they are also more involved with the project or impacted by its outcomes and are thus easier to engage.
Stakeholders who are heavily impacted by project outcomes will be essential to your organizational change management strategy. Do not wait until implementation to engage them in preparing the organization to accept the project – make them change champions.
Low Risk:
Stakeholders with low influence who are not impacted by the project do not pose as great of a risk, but you need to keep them consistently informed of the project and involve them at the appropriate control points to collect feedback and approval.
Leaders of successful change spend considerable time developing a powerful change message: a compelling narrative that articulates the desired end state and makes the change concrete and meaningful to staff. They create the change vision with staff to build ownership and commitment.
The change message should:
The five elements of communicating the reason for the change:
COMMUNICATING THE CHANGE
What is the change?
Why are we doing it?
How are we going to go about it?
How long will it take us?
What will the role be for each department and individual?
Build the communications management plan around your stakeholders’ needs.
Sample communications plan: Status reports
Vehicle | Audience | Purpose | Frequency | Owner | Distribution | Level of Detail |
---|---|---|---|---|---|---|
Sample communications plan: Status reports
Vehicle | Audience | Purpose | Frequency | Owner | Distribution | Level of Detail |
---|---|---|---|---|---|---|
Status Report | Sponsor | Project progress and deliverable status | Weekly | Project Manager |
Details for
|
|
Status Report | Line of Business VP | Project progress | Monthly | Project Manager |
High Level for
|
Build a high-level timeline for the implementation.
Major KPIs typically used for benchmarking include:
Revisit the requirements gathering metrics selected in the planning phase and recalculate them after requirements gathering optimization has been attempted.
4.2.1; 4.2.2; 4.2.3 – Build a requirements gathering steering committee
The analyst will facilitate the discussion to define the purpose statement of the steering committee, build the participation list and authority matrix for its members, and define the procedures and agenda.
4.2.4 Identify and analyze stakeholders
An analyst will facilitate the discussion on how to identify the impact and level of resistance of all stakeholders to come up with the communication plan.
4.2.5 Create a communications management plan
An analyst will assist the team in building the communications management plan based on the stakeholders’ needs that were outlined in the stakeholder analysis exercise.
4.2.6 Build a requirements gathering implementation timeline
An analyst will facilitate a session to brainstorm and document any action items and build a high-level timeline for implementation.
Note: This research also incorporates extensive insights and feedback from our advisory service and related research projects.
“10 Ways Requirements Can Sabotage Your Projects Right From the Start.” Blueprint Software Systems, 2012. Web.
“BPM Definition.” BPMInstitute.org, n.d. Web.
“Capturing the Value of Project Management.” PMI’s Pulse of the Profession, 2015. Web.
Eby, Kate. “Demystifying the 5 Phases of Project Management.” Smartsheet, 29 May 2019. Web.
“Product Management: MoSCoW Prioritization.” ProductPlan, n.d. Web.
“Projects Delivered on Time & on Budget Result in Larger Market Opportunities.” Jama Software, 2015. Web.
“SIPOC Table.” iSixSigma, n.d. Web.
“Survey Principles.” University of Wisconsin-Madison, n.d. Web.
“The Standish Group 2015 Chaos Report.” The Standish Group, 2015. Web.