“If you don’t know where you are going, any road will get you there” – this quote by Lewis Carrol has survived decades because it remains apt and surprisingly conveys the value of requirements gathering for software development pretty well. In other words, you should understand what you want to get in the end and why you actually need it.
In nearly every case, spending time for collecting requirements helps you receive a far superior product with less sticking points and frustration.
Here are some more benefits of well-worked project requirements:
- less project chaos;
- higher satisfaction rate from stakeholders, developers, users;
- minimized miss-communication and unused features;
- faster delivery of the final product; and
- reduced development rework.
Different people have different notions about what is a requirement in software development, so let’s make sure we’re all on the same page.
A Guide to the Business Analysis Body of Knowledge (BABOK Guide) says that requirement is a usable representation of a need.
It is a functionality that a future product must have to meet customer demand or project objective.
A good product requirement should align views between the development team and the customer as well as contain all the actionable information to do great design and development.
Now when we have a shared understanding of the term, let’s find out what mistakes may prevent you from gathering requirements and building a successful product. These tips are based on our experience and will be interesting for both project managers and clients who strive to build a hot red product.
Don’t Repeat These 5 Pitfalls During Requirements Gathering For Your Next Software Project
Pitfall 1: Thinking that requirements are the responsibility of the development team only.
Here in MindK, we became convinced from first-hand experience that only by involving different parts in the process enables collection of the most precise requirements for your future product.
For that reason, holding a Requirements Workshop with our customers is one of the best requirement gathering techniques we use to put the process on the right track.
The requirement gathering session typically involves a Sales Manager, Business Analyst, Tech Lead and Project Manager from our side, and key stakeholders from the customer’s side.
There are usually several sessions needed to make the process run smoothly and accurately (and I will explain why below).
Engaging customers and stakeholders in the process helps fill in the gap between what is expected and what’s delivered.
According to EBD Consulting, workshops can reduce the overall defects by 20 – 50%, narrow down the scope creep from 80% to 10% and save time and effort by 5-15% over the project life cycle.
The presence of a Business Analyst and Tech Lead adds valuable insight into technical aspects, and helps uncover the business processes.
Pitfall 2: Believing that requirements gathering is a single short-time event
One single session is not enough to capture meaningful requirements and create a true understanding of what the real users need. You will likely require a series of interviews with stakeholders at all levels, end users or their representatives.
Requirements gathering is an iterative and incremental activity.
It also requires certain preparation from our side — before the workshop Business Analyst investigates the information about the client, their domain area, and business needs. It helps us to ask the “right” requirements gathering questions to the “right” people.
All types of projects, big or small, Agile or Waterfall involve some sort of requirements gathering. The Waterfall project needs a problem completely understood and documented. Such projects have a separate Discovery and Specification phase, only after which the development starts. It includes documenting requirements and writing a detailed specification document which should be kept up to date throughout the project as change occurs.
For an Agile project, a broad-brush understanding of the problem is enough for a start. Requirements are elicited and added to a product backlog in the form of user stories. It is enough to prepare “ready to implement” requirements for Sprint 1, while all other features can stay in the backlog and wait until next release grooming sessions.
We successfully practice a hybrid approach. Due to the complexity and big project scope, the customer (often) requires a detailed, structural documentation and, at the same time, wants to keep track of the progress and be able to influence the deliverables.
At first, we gather requirements deep enough to get the project scope, budget and timeline defined. Then we break down the project into releases and create a detailed specification for each release. After the release based demo is completed and the functionality is accepted by the customer, the next release-related features can be thoroughly discussed, and described in the specification document (including all the enhancements and improvements defined by the customer after a previous release based demo).
Pitfall 3: Assuming requirements are just technical specifications
First of all, a requirement should embody a solution to a business challenge.
Understanding the root need of the product is one of the most important tasks during the requirements gathering flow.
Therefore, the core question that runs throughout the whole process is “WHY”.
This is an excellent way to avoid assumptions. The detailed responses to incremental questions each time shed more light on the true cause of the requirement.
In view of this, there is a key thing each side should be ready to undertake — it is talking. It happens that the client may not touch on some business processes or not completely explain them, as they are self-evident and obvious for them. Our purpose is to reveal each and every process detail to build a broad picture of the future system.
There is an amazing and simple technique called 5 Whys, a part of the Toyota Production System.
The one thing you should remember when using it during business requirements gathering is – ask the right people. It is essential to have access to all groups of stakeholders who influence or are influenced by the future software product, as they can provide you with the most valuable information.
Involving different groups in the process may contain hidden dangers like conflicts in priorities and views. In order to overcome such a challenge try to build a comfort zone with all the parties and help them become involved in discussion. Business Analyst should also play as a facilitator of the meeting, cut out conflicts and help parties switch from a confrontation to meaningful dialogue.
In addition to workshops and interviewing, we use other requirements gathering techniques like wireframes, UI mockups, various diagrams (activity, sequence, use cases etc.), decision matrices, etc. They help stakeholders visualize the problem and the future solution. Forbes states, by the way, that 65% of the population are visual learners.
It should be noted that the above mentioned are not stand-alone requirement gathering techniques, but represent great supportive tools to communicate the requirements with a client under the conditions of improved transparency and unambiguity.
They are able to highlight the areas which were overlooked and provide valuable insights. You might be surprised how quickly the stakeholders may see that some of their features are not necessary or vice versa.
Pitfall 4: Forgetting about non-functional requirements
Traditionally when discussing requirements, the client has both needs and wants. After cost estimate the customer might ask to cut scope. And there is always a risk to cut the “wrong” requirements that may result in the bad or incomplete scope.
That’s exactly why understanding the difference between functional and non-functional requirements is helpful both for the client and the development team.
Functional requirements refer to certain needs to be implemented in a product. They specify what the system should or should not do. In other words, these features allow the system to function as it is intended — if the functional requirements are not met, the product won’t work.
Non-functional requirements demonstrate how the system will work and are responsible for the quality of the functions developed. The reason why they should be taken into account is usability (as they directly affect the user experience).
The better that non-functional requirements are defined and executed, the easier it is to use the system.
A functional requirement may often have a corresponding non-functional requirement.
For example, loading a system’s web page after clicking on a button is a functional requirement. Specifying how fast it must load is a related non-functional requirement that directly affects user experience.
Pitfall 5: Unclear requirements with no success criteria
Practice proves that the more detailed the requirement is, the more accurate the estimate is and the greater chances of meeting it.
No requirement is complete without a transparent explanation of what is needed to finish it. You have likely heard about SMART (specific, measurable, attainable, relevant, and traceable) which can also be applied to requirements:
Specific: unambiguous, with consistent terminology, simple and detailed.
Measurable: possess measurements to assess the progress and determine whether you’ve met it.
Attainable: realistic, otherwise you can set yourself up to fail.
Relevant: the requirement aligns with the project goal and other requirements.
Traceable: it is possible to trace the requirement from conception to design, implementation and testing. The reason the requirement is included matters for verifying the implementation of each requirement and for easier modifications.
When you make sure you have SMART requirements, check whether they have a Definition of Ready (DoR). It allows the team to reject the requirements that don’t have clearly defined acceptance criteria.
A widely recognized set of criteria, or a checklist, to judge the quality of a requirement is an INVEST model.
INVESTing time and effort in a good requirement helps to deepen its understanding and reduce time spent on coding and testing.
As you can see, software requirements gathering is crucial for the success of the product, so making mistakes here may come at a high cost. Nevertheless, the return rate for well-done requirements gathering is always greater than the cost.
The requirements gathering methodology is aimed at understanding what the customer wants. No, even – what the customer really wants! We may deliver the best and most user-friendly product, but if the right requirements weren’t detected from the start (and thus, the product doesn’t solve the business problem), we may still fail.
That is why the requirements require full transparency for all the parties involved (customer, product owner, development team) and be free of ambiguities (all the stakeholders should understand requirements in the same way).
In case you have a cool idea in mind, our team has a perfect expertise and experience to help you identify the requirements and build a stunning product. All you need is just drop us a line. It is that easy.