In the previous post we looked at some of the tools and techniques for collecting requirements in a project. Let us look at the remaining ones – 6 items on the left side of the mind map below.
Decision making as a team
These are used when many alternatives are available on a particular requirement and you need to decide on one based on inputs from collective intelligence of stakeholders. These are also called collaborative decision making techniques.
The main advantage of this method is – when individuals make decision they are influenced by their liking, risk taking appetite and abilities, whereas when a group takes decision it is more practical and not influenced by individuals characteristics.
(click on the image to open in a new window)
Figure: Some of the techniques of collecting requirements
Dean is at a stage of requirement collection where he has about 3 different data transfer mechanisms ideated by stakeholders. He needs to find a consensus on one of them and move on. He gets hold of the stakeholders and runs through each of these data transfer mechanism, their advantages and disadvantages, costs and benefits.
The group will arrive at a decision based on one of the following ways –
Unanimity
…where everyone in the group decides on any one of the alternatives.
Majority
…is when more than 50% of the participants will vote in favor of any one of the ideas.
Plurality
…is when the option with largest number of votes is selected, even if a majority (more than 50%) is not achieved.
Dictatorship
…one of the participant stakeholders decides about which alternative to go with. No questions asked. If head of the organization was to express ‘strong view’ in favor of one of the alternatives, others in the group may not feel like going against it.
What is the difference between majority and plurality?
It is quite simple. Dean had 3 alternatives. Alternative#1 got 25% votes, alternative#2 got 40% and alternative#3 got 35%. Although there is no clear majority and none of them got more than 50% votes, alternative#2 wins because it has the most number of votes. This is the decision by plurality.
Understanding requirements using questionnaires and surveys
These are predefined set of questions targeted for a broader audience. This method is useful in scenarios where –
- decision is required in quick time
- statistical analysis is sufficient to arrive at a conclusion
In our example, Dean decided to find out the best time for data replication across servers and for backup with central server. He prepared surveys for different groups of stakeholders, each of which is designed to unfold the pattern of slack time around the way hospitals work.
When he got the surveys results he found that 9pm to 11pm is a slot with least amount of work was happening and could be a better slot for automated data replication across servers and data backup.
Observing people in action
This is another very useful requirement collection mechanism. This is typically employed when the target stakeholders cannot communicate the requirements clearly, or the system is complex and needs to be studied while people are using it.
In this method you just observe people working with the system and record requirements. Sometimes you could be a ‘participant observer‘ and understand the requirements by actually doing things.
Creating prototypes
This method is employed when requirements are not clearly thought out by the customer and/or the system being created is unique and has not been done before.
A simple working model with basic functionality is created and shown to stakeholders to analyze and experiment. Based on their inputs it is further developed. This process of iterative development is stopped when the requirements are understood in sufficient details, a way is figured out to test the system once it is developed. Once prototyping reaches its conclusion, team would move to the design phase.
Prototyping uses ‘progressive elaboration’ way to unearth unknowns in the envisioned system.
Benchmarking
This indicates the practice of comparing another project of similar type and nature from the past to the current one to identify processes or practices, or even to find better ways to do things.
Context diagrams
These are visual representation of the system, its interaction with external systems and users. This helps identify any missing business scenarios for which requirements were not written.
Document analysis
This is about studying existing available documents and identifying requirements. Documents such as legal requirements, system use cases, design documents, proposals, current process flows, issue logs, user documentation and so on are used for this analysis.
There you go!
We covered all the tools needed for collecting requirements in a project. It is pretty likely that you might have already used some of these in your job with or without knowing what are they called. You may want to look at few other tools and techniques that could help next time you collect requirements. Which ones do you feel you would want to give a shot? Let me know in Comments.
Now that we have understood all about collecting requirements, the next step is to understand how to define Scope from these requirements. By the way, you know that there is product scope and project scope, right? We look at them in this next post.
