To hit pay dirt

We know that IT system development is not only about the offer of automation services based on the requirements of the customer or consumers, but it’s about development business strategy, about business development.

For example, you have a shop, and when you created a web-site you have received a new market. If you are working in an international company which work with delivery shipments and you have created new technology about exchanges of shipment dates for your client, a big international company, you get a new market too, your business had gone to the next level because of the new technology. The new technology may give you possibility for work faster, with high quality and with new clients. And all of these examples about development both strategies: IT Strategy and Business strategy.

So, we need successful business analysis, including requirements gathering for this process as one of the main it part.

In the Business Analysis for Practitioners: A Practice Guide by PMI [1] the term Business Analysis is defined as “the application of knowledge, skills, tools, and techniques to:

• Determine problems and identify business needs; 
• Identify and recommend viable solutions for meeting those needs; 
• Elicit, document, and manage stakeholder requirements in order to meet business and project objectives; 
• Facilitate the successful implementation of the product, service, or end result of the program or project.”   

All of you know how many projects have fails, and these failures being attributed to requirements gathering, it’s almost 70% of all project failures [2].

How could we realize the right Business Analysis (or discovered requirements) and get the set of the right requirements?

It’s very important to see in the right direction (Figure). For determine problems and identify business needs we have to see around us, to find obvious things, and we have to use some set of rules.

Figure – Discover requirements

For my opinion, there are three most important set of rules.

The first set is about right questions when you try to discover problems and formulate requirements [1]. It is like a 5W1H (Five Ws and One How) method. Answers on these questions are considered basic in information gathering.  Therefore, in the business analysis we have also five Why. Here are some typical questions with why:

1. Why is it the problem?
2. Why is this situation happen?
3. Why do you have this process?
4. Why any alternatives are not work?
5. Why the solution of this problem is so important?

In addition, of course, you have to remember to choose the right person as an interviewee.

The second set is about requirements management [3]:

1. Planning how we could get the right requirements. Plan must include questions, on which you try to find answers (first set of rules), methods and instruments for work with them, list of sources, time, responsibilities, plan for integration, plan for quality assurance.
2. Team work (Collaboration&Buy-In). All team member must be in the loop. You need gathering and work with all ideas no matter how crazy they can be. And you try to get support the decision from all team members. 
3. Integration Management (work with changes). It's very important when you continue working, making changes and go-back iterations. It makes your result much better and clarify requirements.
4. Quality Management (quality assurance). When you have a mistake in the requierements, it will be  cost up to 100 times in the future than it is to correct a defect early on while a requirement.

And the third set is about result analysis [4]:

1. Be sceptic and always ask questions with “Why”.
2. I mean especially very useful in the result analysis the McKinsey technic called MECE (mutually exclusive, collectively exhaustive). When you think in this way, you can find your gaps in the requirements and you can prevent duplicates too.
3. Working with hypothesis: define, generate and test them.

In conclusion, to formulate the right requirements is a very complexity task, and there are a lot of information about different methods and tools. Above rules could be fundament in your requirements gathering.

References:

1. Business Analysis for Practitioners: A Practice Guide, Project Management Institute, 2015, p.  
2. Beginning at the End – Requirements Gathering Lessons from a Flowchart Junkie Cari Stieglitz, PMP, Project Manager, Faithful+Gould, Originally published as a part of the 2012 PMI Global Congress Proceedings – Vancouver, Canada
3. Requirements Management 101 four fundamentals that everyone should know. Jama.Inc, www.jamasoftware.com | 1.800.679.3058
4. Ethan M. Rasiel The McKinsy Way, Copyright 1999 Ethan M. Rasiel. Click here for Terms of Use, 188 p.