Modeling the Requirements Elicitation Process
Image by Sergey Nivens on Shutterstock
A New Perspective on Eliciting Requirements
The Spring 2021 Salesforce Business Analyst Summit included a session, Eliciting Requirements Using the Process Modelling and Analysis Technique. Oge Nwachukwu, a Business Analyst at Nova Scotia Community College, presented her approach to eliciting requirements from a process perspective. Oge applies process techniques to elicitation as guardrails against the risks of incomplete, unclear, or unstable requirements.
Oge cited a couple of Standish Group studies about what makes software projects succeed and fail. The top three success factors are:
User Involvement
Executive Management Support
Clear Statement of Requirements
The top three reasons for software project failure are:
Lack of User Input
Incomplete Requirements & Specifications
Changing Requirements & Specifications
Once a software project has the appropriate users involved in the discovery process, three of the four remaining factors emphasize complete, clear, and stable requirements.
Oge models the elicitation process with a logical sequence of tasks and activities for business stakeholders. Each task breaks down into subtasks, which can decompose into more detailed subtasks. The process ends up with precise steps for technical stakeholders to design a solution.
Oge listed the benefits of process-led requirements elicitation:
Facilitating problem definition and comprehension
Identifying relevant stakeholders, forms, reports, integrations with existing systems and workflows
Highlighting the relationship between technology, business, the organization goals and objectives
Ease of understanding by business and technical teams
The diagram below shows process-led requirements elicitation’s six key steps:
Each elicitation step breaks down into more detailed activities. For example, “Decompose process or step to activities/tasks” (step 2 above) consists of the activities in this diagram:
Who Does What in the Process
Modeling a requirements elicitation process should specify who or what executes each activity/task in the model. The process diagrams above show who performs an activity at the bottom of each activity box. The business analyst and stakeholders collaborate on most of them.
Oge uses the SIPOC technique to identify who provides what for an activity/task and who receives its output:
Supplier - provides activity/task Inputs
Inputs - resources provided by the Supplier
Process - tasks or activities performed to create value
Outputs - products or services from Process
Customer - receives Outputs
The SIPOC technique identifies the flow of deliverables between the solution, its users, and management. It specifies the relationship between technology and the organization, while the process model shows how the solution will help the organization achieve its objectives and goals.
Example: A Slice of the Sales Process
Let’s take some steps from a sales process and apply Oge’s process model to it. She starts with a table like this to show top-level process steps and requirements:
| Role | Step | Requirement |
|---|---|---|
| Sales Rep. | Present product and services appropriate for an opportunity | Sales rep. updates opportunity record status and notes. |
| Sales Rep. | Submit proposal | Sales rep… Drafts proposal. Requests management review. Changes proposal based on the review. Submits proposal to account once approved. |
| Sales Rep. | Negotiate contract |
The second step has four requirements, indicating that it should decompose into at least one activity per requirement.
This process diagram shows the top-level sales process steps from the table above:
“Submit proposal” (step 2) breaks down into the following activities:
The “Draft proposal” activity could decompose into more activities, including configuration, price, and quote (CPQ), which would break down into subtasks on several levels. Discovering lower-level steps makes requirements elicitation more complete.
Decomposing for Better Development
When a business analyst breaks down business processes into activities, tasks, and subtasks, the requirements come into focus with additional details. It continuously improves the definition and comprehension for the business and technical teams, delivering the essential benefits of process-led requirements elicitation.
Stakeholders supply inputs such as forms, reports, integration, and workflow definitions to the elicitation process. Requirements emerge from the process as it breaks down into activities, tasks, and subtasks. The business analyst documents the requirements as the process output, signed off by stakeholders. The technical team receives detailed requirements as the customer in this application of the SIPOC technique.
Decomposing processes, activities, tasks, and subtasks results in many specific steps. These steps give the technical team more to design and build a solution that best fits the requirements.
Modeling the requirements elicitation process paves the way to correct, complete and precise requirements.
You can watch Oge’s presentation and many more related to business analysis with an All Access Pass to the Salesforce Business Analyst Summit.