When products or projects are accused of poor requirements gathering, the accusation is normally false. The requirements gathered are usually solid, but risk increases with additional costs because some of the requirements are missing.

To facilitate any type of descriptive or prescriptive build-out of a process or series of activities, and to prevent omissions, use a structured approach to understanding the complete Use Story. Groups have a tendency to forget activities or events that occur less frequently, particularly activities that support planning and control. Therefore, this approach to requirements gathering provides structured support that squeezes out potential omissions. Structure solidifies requirements gathering when relying on a proven method—life-cycle analysis.

NOTE: Requirements can be gathered to understand an internal process or they can be gathered externally to help build new products and services.

Method

Therefore, the developmental support steps for requirements gathering include:

• Determine the business purpose of the process or functional area. Strongly suggest using the “Purpose is to . . . “ tool.
• Next is the first activity of the brainstorming method—List. Label the top of the flip chart with “VERB NOUN” and ask the group to identify all the activities that do or would support the business purpose created in the prior step. Enforce the listing and capture them only as Verb-Noun pairings.

Plan➠Acquire➠Operate➠Control

• Use the Plan➠Acquire➠Operate➠Control life-cycle to help stimulate thinking about what activities may be missing.
• You should find one to two planning, one to two acquiring, bunches of operating, and at least one to two controlling activities for each business process or scope of work.
• After identifying the various activities (sometimes called “sub-processes” by others), convert the verb-noun pairings into “use cases” or some form of input-process-output. Build one use case for each pairing.
• Consider assigning the SIPOC tables (a form of use case) to sub-teams. Demonstrate one in its entirety with the whole group and then break them out into two or three groups.
• For each activity, build a narrative statement that captures the purpose of the activity, why it is being performed, then:

1. Continue to identify the specific outputs or what changes as a result of having completed the activity.
2. Link the outputs with the customer or client of each; i.e., who is using each output.
3. Next, identify the inputs required to perform the activity.
4. Finally, identify the sources of the inputs.

An illustrative SIPOC chart is shown below. SIPOC stands for the Source of the input, Input(s) required to complete the activity, Process (i.e., our activity), Output resulting from the activity, and Customer or client of the output.

Summary of steps to be included in this sequence 

1. Identify the activity (i.e., process). Agree on its purpose and how the activity performed supports the purpose.
2. Detail HOW it is or should be performed.
3. List the outputs from the completed activity.
4. Link the outputs to the respective clients or customers.
5. List the inputs needed to complete the activity.
6. Identify the source(s) for each of the inputs.

Success Keys

Consequently, use a visual illustration or template to build clear definitions of “requirements”. Additionally,

• Have the group pre-build all the potential sources and customers of the process and code them so that when you build the SIPOC tables; the group can refer to the code letter/ number instead of the full name (thus substantially speeding up the method). As you discover new sources or customers, simply add them.
• Then, keep quiet (i.e., ‘shut up’) after asking questions (seek to understand rather than be understood).
• Write down participant responses immediately and fully.
• Provide visual feedback, preferably through modeling.
• Advance from activity identification to the inputs and outputs required to support the activity; then associate each with its sources and clients (SIPOC).
• Separate the WHAT from the HOW.

Simple Agenda

You may consider using the method described above with a simple agenda that could look like:

• Introduction
• Purpose of __________
• Activities (NOTE: Take each “Thing” and ask—“What do you do with this thing ?”—forcing “Verb-Noun” pairings. Test for omissions using the Plan ➺ Acquire ➺ Operate ➺ Control prompting)
• Value-Add (i.e., SIPOC)
• Walkthrough
• Wrap

Activity Flows (aka Functional Decomposition)

This approach supports building an Activity Flow diagram also known as a process flow diagram. This workshop delivers up the “verbs” or activities that should be adding value (if not, consider eliminating them).

Activity Flows can benchmark or help optimize during business process improvement efforts. Use this approach whenever you need a detailed understanding of WHAT is required to support a process. Leverage the deliverable from this workshop to build “Use Cases” or SIPOCs or process-flow diagrams (swim lanes), helping to ensure that nothing substantial or critical gets missed.

This approach applies structures around complex situations that may look overwhelming. As background material, it can help a team keep focus on the life-cycle of a product or project.

Deliverable

An Activity Flow diagram (traditionally known as Functional Decomposition) with detailed charts of the activities being performed. Consider using ProChart, Visio, or some graphical tool to help build your process flow diagram.

Participants

People performing the work. Should include management and supervisory people within a business area. Use breakout teams to expedite the SIPOC charts when finalizing the detailed requirements.

Visual Aids Used

1. Definitions for terms
2. Work life cycle prompt (Plan, Acquire, Operate, Control)
3. Illustration of your analogy down to the SIPOC (or use case)
4. If using an easel or whiteboard also consider:

• Large Post-it notes (for the gerunds or groups [aka processes])
• Smaller Post-it notes (verb/ noun pairings or activities)
• For online sessions, consider getting some documentation help. While we know you are stellar, it can get really tough plotting and listening at the same time.

Comments: HOT TIP on WHAT vs HOW—If you are uncertain whether an activity is “WHAT” they do or “HOW” they do it, ask whether it is concrete or abstract. For example, you might “conserve energy” that is abstract and scribes “WHAT” you are doing. HOW you do it is to “switch off the lights” or “dial down the thermostat”—more concrete and visual. Or, WHAT you are doing with your vehicle is “starting” but “turn the key” is HOW you are doing it. Or, you cannot see “acceleration” but you can visualize a “foot on the pedal”.

The figure below illustrates part of the deliverable and documentation. Comprehensive process identification may take a few days unless you are beginning with a narrow scope and small group of activities.

When possible, work with a meeting designer or methodologist ahead of time to understand the questions and grammatical constructs of the model that match well with the tool being used to record the model.

______

Don’t ruin your career by hosting bad meetings. Sign up for a workshop or send this to someone who should. MGRUSH workshops focus on meeting design and practice. Each person practices tools, methods, and activities every day during the week. Therefore, while some call this immersion, we call it the road to building high-value facilitation skills.

Our workshops also provide a superb way to earn up to 40 SEUs from the Scrum Alliance, 40 CDUs from IIBA, 40 Continuous Learning Points (CLPs) based on Federal Acquisition Certification Continuous Professional Learning Requirements using Training and Education activities, 40 Professional Development Units (PDUs) from SAVE International, as well as 4.0 CEUs for other professions. (See workshop and Reference Manual descriptions for details.)

Want a free 10-minute break timer? Sign up for our once-monthly newsletter HERE and receive a timer along with four other of our favorite facilitation tools, free.

Related article

• Quick Tip # 84: Using a SIPOC to Support Stakeholder Analysis (IIBA Quick Tips)