“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 enough, 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.
Nearly 39% of projects fail because of faulty requirements gathering processes. It’s almost impossible to create a product that works as defined, meets its goals, and satisfies end-users when you don’t have strong requirements to push from. That’s why the importance of requirements gathering in a project should not be underestimated.
Here at MindK we’ve been developing software solutions for years and can say with certainty that in nearly every case, spending time collecting requirements helps you receive a far superior product with fewer sticking points and frustration. Among other benefits of well-worked project requirements is less project chaos, faster delivery of the final product, and reduced development rework.
But how should project requirements be collected to ensure successful project delivery? There are several simple truths we follow when starting on projects at MindK.
#1. Close collaboration between the client and the development team is a must
Do not consider the requirements gathering process the sole responsibility of the development team. The client role in the process is mission-critical, so, the client should be ready to participate in collecting requirements along with the project team.
At MindK, we became convinced from first-hand experience that only involving different parties in the process enables collection of the most precise requirements for your future product. For that reason, holding a requirements workshop (also called a requirements gathering session) 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. The presence of a Business Analyst and Tech Lead adds valuable insight into technical aspects, and helps uncover the business processes.
Everyone should keep in mind that great software products are the result of a well-implemented architecture based on requirements gained from cooperation between the development team and clients. Such a collaboration, in turn, is possible only when all participants know exactly what they need to achieve, as well as understand and respect each other. When a project turns up the heat, it’s easy to forget that everyone involved has the same goal – to develop a successful software product that is valuable to the business.
It’s key to understand that the client, as well as the project team, has both rights and responsibilities on the project. They are well described in the book Practical Techniques for Gathering and Managing Requirements by Karl Wiegers. The rights and responsibilities of the client there are formed into two documents Requirements Bill of Rights and Requirements Bill of Responsibilities for Software Customers.
The client should expect Business Analysts to speak their language and learn about their business and objectives. At the same time, the client should be ready to spend the time to provide requirements and clarify them, as well as promptly communicate changes to the product’s requirements.
Sure, these Requirements Bills are not a silver bullet. If you are involved in a software development project as a client and feel that your rights are being violated, discuss this with the Project Manager or Business Analyst. It’s possible that you’ll need to make some changes to the rights and responsibilities so that all parties accept the concept of further cooperation.
#2. Consider requirements gathering an iterative process
One single requirement gathering session is not enough to capture meaningful requirements and create a true understanding of what real users need. You will likely require a series of interviews with stakeholders at all levels, end-users or their representatives. Process of requirement gathering is an iterative and incremental activity.
All types of projects, regardless of the software development methodology or SDLC model involve some sort of requirements gathering. The Waterfall project, for example, needs a problem completely understood and documented. Waterfall projects have a separate Discovery and Specification phase, only after which the development starts. It includes documenting requirements and writing a detailed requirement gathering document or 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. For initial requirements gathering it is enough to prepare ‘ready to implement’ requirements for Sprint 1, while all other features can stay in the backlog and wait until the next release grooming sessions.
At MindK we sometimes practice a hybrid approach. In some cases, due to the complexity and big project scope, the customer requires 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).
#3. Gathering requirements for a software project is multilevel
Quite often clients think that requirements are just technical specifications. It’s not completely true. 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.
Software requirements consist of three levels: business requirements, user requirements, and system requirements. Business requirements are formed by the client and describe the business goals that the company wants to achieve and form the framework of the entire project. All other features and requirements must meet business requirements. However, business requirements do not provide developers with enough information to create a product.
The next level of requirements are user requirements that are determined with the help of those who directly or indirectly interact with the product — end-users. End-users are able to describe the required functionality as well as the expected product’s quality characteristics. System requirements are the building blocks used to create a software solution in practice (can be functional or non-functional).
Source: velvetech.com
It happens from time to time that clients who provided the business requirements, try to speak on behalf of users, but usually they don’t completely understand all the challenges to accurately describe user needs. Moreover, it happens that clients don’t want to spend time communicating with a Business Analyst who collects, analyzes, and documents requirements — they believe that the analyst or developers are able to determine exactly what the users need themselves.
To eliminate all the mentioned challenges in requirement gathering, at MindK we try to follow two principles: involve key people from the customers’ side and ask the right questions to 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. There could be a situation when the client may not touch on some business processes or not fully explain them, as they seem to be self-evident and obvious for them. Our purpose, however, 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 basis of Toyota’s scientific approach is to ask “why” five times whenever we find a problem. It helps to get to the root cause of the problem and the solution becomes clear.
Source: easyretro.io
However, involving different groups in the process may contain hidden pitfalls like conflicts in priorities and views. In order to overcome such a challenge we try to build a comfort zone with all the parties and help them become involved in discussion. The Business Analyst from our side plays the role of a meeting facilitator, cutting out conflicts and helping 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 and so on), decision matrices, and the like. They all help stakeholders visualize the problem and the future solution which is very helpful. Given the fact that 65% of the population are visual learners, it’s indeed useful.
Sure, wireframes, mockups and others 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 can highlight the areas which were overlooked and provide valuable insights. Sometimes we are surprised how quickly the stakeholders may see that some of their features are not necessary or vice versa.
#4. Non-functional requirements are no less important
Traditionally when discussing requirements, the client has both needs and wants. After the cost estimation 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 we pay great attention to non-functional requirements during the requirements elicitation process.
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 it directly affects the user experience). The better 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.
#5. Good requirements – better product
But what does it mean – good requirements? From our practice, the more detailed the requirements are, the more accurate the estimates are and the higher chances of meeting them. No requirement is complete without a transparent explanation of what is needed to finish it- success criteria.
To achieve good requirements, we first make sure that are our requirements are SMART (specific, measurable, attainable, relevant, and traceable):
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.
Source: linkedin.com
In addition we create Definition of Ready (DoR) to meet all the requirements. It allows the team to reject the requirements that don’t have clearly defined acceptance criteria.
Another set of criteria, or a checklist, we use to judge the quality of a requirement is an INVEST model. INVESTing time and effort in a good requirement helps to understand it better and reduce time spent on coding and testing.
As you can see, software requirements gathering is crucial for product success, 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, it’s — 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 from all the parties involved (customer, Product Owner, development team) and be ambiguities-free (all the stakeholders should understand requirements in the same way).
In case you have a cool idea in mind, our team has the 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.
