Instead of stubbornly keeping yourself stuck, thinking that “Clients don't really know what they want”, how about you... give them a hand? Helping them identify and clearly articulate their needs! Especially since there are so many effective, tried-and-tested tools and techniques that grant you success when you're collecting requirements for your project.
And it sure is worth all the effort. Or, to put it this way:
It will cost you/your project a lot if you're doing it wrong.
In this respect, numbers make the most reliable proofs:
Behind the great majority of project failures, there's a lack of clarity on requirements.
Therefore, learning how to collect requirements for your project:
- instead of jumping straight to the design phase
- way before developers start defining their own scenarios for functional tests
… is crucial to the overall success of your project.
And now, here's the “arsenal” you should tap into and use to its full potential:
The most effective tools and techniques to “power” your collecting requirements process with.
What Is This Process? What Is Involved in Collecting Requirements for Your Project?
And it seems only natural to attempt to define this whole process, first things first:
Collecting requirements is the process of identifying and documenting (and managing) the stakeholder needs and requirements.
This way, you're determining and documenting all the key features and functions of the product that you're due to develop. As well as identifying all the processes that you'll need to carry out for achieving the project scope.
Speaking of which: this is the process that helps you clearly define the project's scope itself.
“And how come (so) many teams fail at it?”
Mostly because development teams don't have a good process for effectively collecting requirements set up in the first place.
And a “good process” starts with proper segmentation, into multiple key steps to take, such as:
- elicitation
- analysis
- specification
- ...
Also, another strong reason behind IT teams-clients communication failure is underrating the iterative approach to defining requirements:
A highly effective technique, since requirements are often quite “blurry” early in a project
The Facilitated Workshop: Enhance Cross-Functional Team Collaboration
The purpose behind it? There are several in fact:
- bringing different stakeholders together will help you identify and better understand their difference of opinion (if there's any)
- you'd be improving cross-team communication from the very start
- you'll be “unearthing” inherent challenges that different stakeholders face and that involved parties, by themselves, aren't even aware of
In short: conducting a facilitated workshop does what its name says, it facilitates stakeholders to identify and clearly articulate their requirements.
Interviews: One-On-One Meetings With Different Types of Stakeholders
Prepare a different set of questions, for each one of your target stakeholders, and have some one-on-one meetings.
Each of them is differently impacted by the “problem/need” that your team should come up with a solution-product for. Therefore, interviewing them all, separately, will only help you gain both:
- in-depth
- and comprehensive understanding of that specific problem/need
Leverage the Participant Observation Method
A highly effective technique used in the collecting requirements process.
And it becomes particularly useful when stakeholders are having difficulties identifying and clearly articulating their requirements.
Or when the given system/process is too complex and you need to actually observe people in action for analyzing it and understanding how it works. And what its limitations are.
In these 2 cases, it's only by observing the participant “in action” that you can properly record requirements.
In this respect, a “kindred” method that you could use during the collecting requirements for your project process is the “participant-observer” one. Where you get to actually test that system/process yourself, too.
5 Group Creativity Techniques to Explore
1. Idea mapping
“What is the scope of this process?” you might ask yourself.
By putting together all the different stakeholders' ideas into a mind map, you'll gain a bird's-eye view of them all! On how they're connected to one another, which are the best of them, what are their pros and cons?
And speaking of grouping ideas into a “mind map”, there are several types of maps that you could set up:
- archival strategies
- data transfer mechanism
- data formats
2. The nominal group method
Using this method to collect requirements inputs will save you loads of time.
Basically, you set up a group of stakeholders, ask them to share their ideas, and... submit them all to vote.
Only those scoring the most votes will be further taken into account. And this will just streamline the entire decision-making process!
3. Related ideas diagrams
Probably the best way to neatly categorizing that huge pile of ideas that you will have collected!
How does it work? You simply write down all those ideas on separate cards, then pair the similar ones together, till there's no “isolated” card left. And you end up with a diagram of ideas, nicely structured into different categories.
Starting there, you can put together your cause-and-effect diagrams.
4. Brainstorming
"What are the best ways to gather requirements?”
Brainstorming is (should be) on top of any To-Do list for a collect requirements process!
Schedule brainstorming sessions with different focus groups of stakeholders and challenge them to share their ideas. You'll end up with a whole “pile” of diversified “steamy fresh” ideas to work on.
5. Group decision making
Let's say you get several alternatives for the very same requirement. What do you do?
How do you filter the best one?
You set up a decision-making group and... ask them to give their inputs. It will be a collaborative decision-making process.
In the end, it's the requirement that they all (or the majority) agree on that will get selected.
Benchmarking
Mind you don't underrate this technique!
For, as “banal” as it may seem, it's surprisingly effective:
Compare the current project with a similar one and try to identify the best practices and key processes. And to even come up with better methods to solve certain challenges, while you compare the 2 projects.
Document Analysis: One of The Collect Requirements Process's Key Steps
Another great way to determine the requirements for your project is to analyze all the documents at hand:
- system use cases
- proposal
- legal requirements
- user documentation
- design documents
- system use cases
- …
Create Context Diagrams
Here's just one of the best answers to the following question:
“What are some basic requirements gathering tools and techniques?”
By putting together context diagrams, you're creating a visual representation of the whole system. Its interaction with users and other external systems here included!
What's the point?
By visualizing the entire system it'll be easier for you to spot all those business scenarios that you might have overlooked. Scenarios for which you haven't collected and documented any requirements yet.
Come Up With Prototypes
This technique comes in handy in your whole collect requirements process if:
- your client just can't envision and thus can't articulate the requirements
- the system/product/process you're due to put together is too new, too complex
Setting up and then providing your client with a simple working model, with basic functionality, will help him/her get a clearer picture of how it should work. And give him the chance to “taking it for a spin”, to experiment it.
Once the stakeholders have tested it, they'll be more confident to provide you with relevant inputs.The ones you'll need to actually get this new system developed.
Get a Grip on The Gherkin Syntax
Consider learning to speak Gherkin fluently in order to guarantee the success of your requirement collecting process.
The main benefit that you'll be “reaping” is a record of utterly explicit requirements. And it's the Gherkin syntax that constrains them to be so.
For instance, have a look at this example here, from Neoteric.eu, of the Gherkin syntax being used for collecting scenario-specific requirements only:
Feature: Logout from application Scenario: Given I am logged in When I click “log out” button Then I am informed about successful logout And I am redirected tologin page
See? Zero ambiguity!
Both the:
- business analyst(s)
- developers
… in your team will benefit from leveraging this language.
The first will end up with perfectly explicit requirements, while the latter will get the clear information needed for setting up functional test scenarios.
A win-win situation.
The END! Does this answer your “What is involved in collecting requirements for your project?” kind of question?
