Often thought to be a tool best suited for root-cause analysis, the “5 Whys” is an iterative interrogative technique for exploring the cause-and-effect relationships affecting a particular problem. If you think of the 5 Whys process as a fact-finding mission, consider the “5 Hows” as being more solution-oriented.
These two sets of questions can also assist with eliciting the right software requirements by drilling down to identify needed and necessary functionality.
Also read: How to Choose a Software Development Methodology: 6 Approaches
Understanding How To Use the 5 Whys and 5 Hows
The trick with these techniques is to keep the questions simple and avoid influencing the answers. In almost all cases, the stakeholders or users you are speaking with will learn as much as you do.
Don’t be concerned if you need more than 5 questions to get to the answers you need; you may also be able to get there with fewer questions.
Using 5 Whys: An Example
As you might expect, the concept is simple: repeatedly ask the question, Why? until you get to the real root of the issue. As you get answers, try parroting them back in each iteration.
As an example:
- Business Analyst: Why have you requested an update to your client invoicing software application?
Stakeholder: Because it is taking too long for clients to receive invoices for work we have completed.
- Business Analyst: Why is it taking too long for clients to receive invoices for the work you have completed?
Stakeholder: Because timesheets aren’t being approved on time.
- Business Analyst: Why aren’t timesheets being approved on time?
Stakeholder: Because HR managers aren’t receiving them from employees on time.
- Business Analyst: Why aren’t HR managers receiving timesheets from employees on time?
Stakeholder: Because all timesheets are currently being entered by a single clerk in our office.
- Business Analyst: Why are all timesheets currently being entered by a single clerk in your office?
Stakeholder: Because the current method of submitting timesheets is non-standardized and a primarily manual process.
What we learned through these five questions is that we can likely improve or solve the problem being faced by our stakeholder by automating timesheet entry and approval functionality. Don’t forget that this is often a cyclical process and can be repeated as often as is necessary. Extending this example, you may want to dive deeper into how you could standardize the current processes, looking into finer details such as deadlines.
Though not detailed enough on their own, keep phrases in mind like: Why is this important? Why would this help? Why haven’t you already done this? Why is it done this way?
Using 5 Hows: An Example
Sometimes the need for 5 Hows follows 5 Whys, but not always. It can also be helpful to determine how to proceed in a given situation, or how to problem solve and find solutions to IT-related issues.
As an example:
- Business Analyst: How did the software application become unavailable?
Stakeholder: We were the victims of a malware attack.
- Business Analyst: How did you become the victim of a malware attack?
Stakeholder: We haven’t implemented any security monitoring processes or solutions.
- Business Analyst: How is it possible that you have not implemented any security monitoring processes or solutions?
Stakeholder: We haven’t had the budget approved for procuring the necessary technology.
- Business Analyst: How do you proceed with getting the budget approval for the necessary technology?
Stakeholder: We need to hire for the security manager position.
- Business Analyst: How do you hire for the security manager position?
Stakeholder: We need to discuss the impact of this recent malware attack with our executive team.
In this case, we were able to determine that the stakeholder is already aware of the issue, but they hadn’t clearly mapped the path to a solution. This may not be the end of your interrogation, but it’s delivered the first necessary answers. Don’t be afraid to start broad and vague with your 5 Hows, using future iterations as a means to determine priorities, set deadlines, define scope, or to see if smaller improvements could make a difference.
Also read: Using Swim Lane Diagrams to Improve Software Development
A Judgment-Free Process
It’s important that any facilitator asking why and how questions doesn’t make participants feel they are being judged. The goal is to dig deeper, learn more, and understand better.
Try to avoid getting frustrated. Stakeholders often don’t know exactly what they need, or what would alleviate their pain points. Show appreciation for all answers given during an interview and consider rephrasing or restating questions that may have been misunderstood.
Your job is to better understand a situation or test out your ideas for solutions. Don’t make assumptions.
The Three-Legged 5 Whys or 5 Hows
In many situations, any given request or problem may have several contributing factors. If your first interview reveals that there are additional considerations, don’t be afraid to conduct several interviews. As mentioned, these two processes should be considered iterative and therefore could also be ongoing.
Emphasizing Collaboration
Ideally, the result of your interrogation will provide the basis for an action plan. In some instances, the answers to your questions may identify that stakeholder needs can be addressed by better utilizing existing software applications or technologies, making education the only requisite response.
Ultimately, the goals of 5 Whys and 5 Hows is collaboration. Whether you are realizing a new opportunity, helping to justify a software development activity, or just trying to better understand business processes and workflows, having a better understanding will always translate into better requirements.
Read next: 10 User-Centered Software Design Mistakes to Avoid
The post Identifying Software Requirements Using 5 Whys and 5 Hows appeared first on IT Business Edge.
Source : Identifying Software Requirements Using 5 Whys and 5 Hows
