Chapter 8

Requirements Elicitation Workshops and Discovery Sessions

In This Chapter:

Structured facilitated requirements workshops, which are formal sessions involving multiple groups, such as end-users, subject matter experts, the project manager, and business and IT representatives, are common. Their goal is to elicit requirements from the group of multiskilled and diverse participants. The output of the session may be text, graphical, or matrix documentation. Workshops can be used to elicit, specify, refine, quality-check, and reach closure on business requirements.

Resolving Requirement Conflicts

The requirements workshop is most effective when the multiple business areas are undergoing change and are cross-functional in nature. In this case, it is important to understand and resolve conflicts and inconsistencies among diverse perspectives. Meeting with key stakeholders in the same room and hearing different perspectives ensures requirements are complete, and therefore improves requirements quality. Resolving requirements conflicts early in the project is essential to reducing requirements defects that have the potential to adversely impact the success of the project during solution delivery. See Figure 8-1, which depicts the relationship between project conflict and progress.

Requirements workshops facilitate understanding what the project is really trying to accomplish from a business perspective, because the key business stakeholders are in the room contributing. When conflict emerges, remember that conflict can often be positive when handled well, as the participants mutually determine the tradeoffs that must be made. The workshop process contributes to resolving disconnects and clarifying the scope of requirements that can realistically be accomplished within the time and cost constraints in early stages of the project. In addition, workshop sessions facilitate discussion on whether the project objectives are technically feasible, since both business and IT subject matter experts are present. From the perspective of a business analyst, the strengths and weaknesses of facilitated workshop sessions are those shown in Table 8-1.

Figure 8-1—Relationship between Project Conflict and Progress

Requirements workshops and collaborative discovery sessions are generally any type of meeting through which end-users are highly involved in creating or influencing the direction of the solution design and development. Many product development methodologies and improvement approaches use team-based approaches, from informal discovery sessions, to joint design sessions, to formal workshops involving key project participants to understand requirements. Facilitated elicitation workshops are designed to increase the collaboration between the business and technical teams, and are described below.

Table 8-1—Benefits versus Disadvantages of Elicitation Workshop Sessions

Formal Requirements Elicitation Workshops

Formal requirements elicitation workshops are structured meetings in which a carefully selected group of stakeholders and content experts works together to define, create, refine, and reach closure on deliverables (such as models and documents) that represent business requirements for a new/changed business system. Successful workshops encourage teamwork, communication, decision-making, and mutual understanding of the business requirements.

Workshops are also an effective way to bring together customers, users, and solution suppliers to improve the quality of the product without sacrificing time to delivery. These sessions tend to commit users to the requirements definition process and promote their sense of ownership of the deliverables and, ultimately, of the new solution.¹ Workshops typically start at a broad level, identifying the scope of the requirements, then move on to establishing high-level business functions or processes, and then go into detailed business scenarios.

For projects using iterative development techniques, initial workshops focus on high-risk and high-value requirements, and immediately get started on development of the first increment of the solution. In addition, smaller, informal discovery sessions are used. This approach reduces the risk of trying to identify all the requirement at the beginning of the project. It must be noted, however, that enough high-level requirements definition must be completed to be able to establish the initial release plan.

Business Process Improvement Workshops

A business process improvement session is a type of formal requirements elicitation workshop during which an analysis of existing business processes is conducted with the goal of implementing process improvements. The business process is analyzed using techniques described in Six Sigma, which is a highly structured program for improving business processes, or any method that systemically looks at process inputs, process steps, and outputs to model the current state.

Typically a “cards on the wall” approach is used, mapping the current business process for all to see. The group then looks for opportunities to improve the process by better aligning it with the current environment and customer needs. The process is then changed, and the performance of the process is measured and continually tuned to bring performance within identified tolerances. Business process improvement is also referred to as business process reengineering, process quality management, and continuous process improvement.

Agile Requirements Elicitation Workshops

Agile methods minimize the risk of requirements defects caused by inadequate stakeholder participation by working daily with the customer and delivering small increments of functionality, and gaining requirements feedback after each increment. Agile development teams do not typically conduct large, formal requirements workshops; agile teams prefer to operate in smaller working group sessions. However, a formal workshop may be needed to document the scope of the requirements and to determine the number and sequence of the increments.

The tools used for initial modeling sessions can vary by proponent and vendor, but generally the tools are aligned to the Unified Modeling Language (UML™), a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system, creating use cases that either graphically or in a text format document the interaction between the user and the new or modified system. The business analyst’s role in agile requirements discovery sessions can vary from facilitating the group to getting out of their way; however, the business analyst is always re-examining the business case to make sure the project investment remains sound.

eXtreme Programming (XP) Agile Methodology

eXtreme Programming (XP) is a code-centric agile methodology of project activity and the most prominent of the agile methods. Requirement elicitation sessions involve users writing stories that capture the features needed by the business community on index cards. This approach acknowledges that ongoing changes to requirements are inevitable, natural, and even desirable, and being able to adapt to changing requirements is better than attempting to define all requirements at the beginning of the project.

Scrum Agile Methodology

Scrum is an agile method that focuses on a collaborative team effort between product champions and IT development teams. The schedule is driven by a prioritized feature list that directs development activities in an iterative fashion. Iterations are referred to as sprints, indicating the speed with which iterations of the solution are built. A feature is defined as a user-facing component of the solution that adds value to the business; therefore, the feature list is prioritized based on business value.

Rapid Application Design Workshops

Rapid application design (RAD) standards are drawn from the principles of incremental development emphasizing constant feedback from customers to facilitate capturing requirements and quickly turning them into working components of the solution. The focus is on delivering value and keeping communication open. The goal is to minimize the time between concept and implementation. RAD relies extensively on user involvement, joint application design workshops, prototyping, and the use of CASE (computer-aided systems engineering and application development) tools. RAD often uses highly structured working sessions that may involve team-based analysis, design, and development.

Joint Application Development Workshops

Joint application development (JAD) is a solution development process that brings together developers and end-users to cooperatively develop requirements. The goal is to reduce project delays associated with talking with each user individually and then attempting to pull together a vision of how to develop a satisfactory solution.

Rules for Elicitation Workshops

Key rules for formal elicitation workshops and more informal discovery sessions are:

Make a decision on the type of session that is appropriate for the project life cycle selected, the organizational culture and standards, project characteristics, and team composition. However, if the project is large, complex, and high risk, consider enlisting the help of a professional facilitator who is trained and well-versed in conducting requirements elicitation workshops and capturing the workshop results.

Be clear on what the session will deliver. Ensure that IT requirements are considered when planning the elicitation session to reduce errors in translation during analysis and design activities. Common topics for workshop discussions include:

Events. In software product development, an event is defined as something that causes a change in the environment that the proposed business solution must respond too. Examples include:

– Time: Jobs need to be kicked off at midnight; payroll executes every other Friday

– Requests: People request cash from an ATM; user presses “Submit” on an enterprise portal; a satellite receives a transmission from mission control

Actors. An actor is a system or person that interacts with the proposed business solution. Examples include:

– People: Soldiers interacting with equipment; the public requesting information from an agency enterprise portal; senior executives requesting financial analytical reports

– Systems: An interface to dependent systems such as payroll pulling active employees from the human resource system or an online payment acceptance system requesting and receiving a credit card authorization

A process for gathering requirements. Either a business process flow or a structured development process (covered in the previous section).

Tips for Successful Workshops

Create a plan to address known project challenges that have prevented project success in the past. Discovery sessions are not typically used for general training to address gaps in skill set. However, if the team needs training on subjects as diverse as conflict management or on a specific modeling technique that will be used in the session, find a way to address this need. Develop a training module that is part of the agenda or is a prerequisite to attendance at the session. Prerequisite training is not intended to create a barrier to participation, but to address the challenges unique to the requirements elicitation process. Create a plan for each of these skill-gap barriers to effective team interaction:

Technical tools, e.g., use cases, CRC cards, CASE tools

Team or skill development issues, e.g., facilitation skills, brainstorming, communication skills, cross-cultural communication awareness, consensus decision-making

Requirements elicitation training. Business analysts do not simply write down what customers articulate. Requirements meetings need to probe, often using powerful modeling tools that capture all the users and events that interact in the business process undergoing change. Business analysts must uncover what is not said and what is only implied, i.e. requirements that are derived as a result of what was said.

The session is led by a trained facilitator, assisted by a scribe whose role is to document the workshop results. Participants include:

Users: Individuals who are authorized to speak for their business or mission domain and who can make binding decisions for the project

Developers: Key individuals responsible for design, construction, or test of the solution and who can provide high-level architecture answers that speak to the technical feasibility of implementing requirements

Subject matter experts: Process or technology experts who are able to provide immediate process, economic, or technical feasibility assessments to resolve meeting conflicts or roadblocks

Senior managers: Individuals with the authority to commit organizational funds and make real-time binding vision and direction decisions or tradeoffs

Limit the meeting to key project participants. If project participants cannot be limited, either the project scope or the meeting agenda is not right sized.

Tailoring Requirements Elicitation Workshops

Discovery sessions are necessary and valuable for virtually any initiative size. However, they can be quite expensive. The business analyst scales the session activities to the project needs. Table 8-2 shows workshop variances scaled to the project profile.

Table 8-2—Workshop Sessions Scaled to Project Size, Risk, Complexity