What is a ‘Requirement’?
I believe anything that is a necessity and is essential for a certain event to take place is a requirement. In the world of business, it can be a condition that needs to be fulfilled to solve a business problem or respond to a specific business need.
The importance is that a piece of requirement should be ‘actionable’ in order to solve or trigger a certain scenario. By the term ‘actionable’, I mean something that can be implemented within a certain time frame. For instance, say a project’s goal is enabling digitalization in a certain process flow within a 6-month period. In order to achieve that, it is important to convert the goals into actionable steps and achievable tasks.
Also, it is important to validate if a certain piece of information is necessary enough to call it a requirement. Many times, clients or stakeholders are not sure if they really want a certain feature in their product and if that feature will add value to their services. As a 'Product/Development Team', it is then our responsibility to guide them through the discovery phase to realize what they really need to meet their goal.
Types of Requirements
To build a product or to solve a certain problem, we might need plenty of conditions and requirements to be fulfilled. Oftentimes, it becomes an overwhelming job to keep track and manage a variety of requirements. Moreover, organized and unequivocal requirements help shape the success factor of any project.
Thus, to make our lives easier we have classified requirements into several types and categories however these classifications can vary from organization to organization. According to BABOK (Business Analysis Body of Knowledge®), requirements can be divided into the following types:
- Stakeholder Requirements
- Solution Requirements
- Functional Requirements
- Non-Functional Requirements
- Transition Requirements
Let's understand each one of the above briefly:
Stakeholder Requirements can be problem statements from a user's, customer's or any other stakeholder's perspective. Also, these requirements focus on the 'what' of the problem rather than the 'how' and 'why'.
Solution Requirements describe how the execution of the product will be done in order to fulfill the conditions of the business stakeholders and users. Solution requirements can be further classified into two categories:
- Functional Requirements detail how the product should respond and behave. These could be the various features or functions the product must have in which would eventually be captured as a 'user story' or 'use case'.
- Non-Functional Requirements can be used to describe the various characteristics of the solution such as quality, scalability, operations, performance, etc. which in turn would help support the functional requirements.
Transition Requirements are the conditions that need to be fulfilled when a certain product or a solution is getting shifted to a different or a new phase in order to support smooth migration.
What’s Requirements Gathering?
In my opinion, the most important activity in a software development lifecycle or an agile product development environment is the requirements elicitation or requirements gathering part. This phase consists of researching and discovering the requirements for a certain product or application to be built or a business expectation to be fulfilled. Effective planning is needed in terms of process, time and management in order to achieve the desired results.
This activity is usually performed by a team comprising of various roles such as Product Owners, Technical Leads, Designers and Developers with the involvement of the clients, customers, and users.
Techniques and processes for gathering requirements:
There are various techniques, processes, and tools to capture user needs, pain points and requirements. Especially in agile methodology, this is an ongoing process. Different organizations use different approaches to gather user/client requirements and there are several tools available in the market for the same.
The foremost important step prior to gathering requirements is finding the primary sources that will help provide the required information. These sources could be stakeholders, end-users, existing documentation and research on the competitors and the market.
Although requirements gathering is an iterative process and can be done by anyone, the common methods used across organizations and business to elicit requirements are:
1. User Interviews: This is the most common and popular way of collecting information, and this can be done face to face or through any online channel. Normally this technique is used to learn how and what the user thinks about a specific product or a topic and can be conducted one-on-one or in a group format. The users could be stakeholders or end-users.
2. Brainstorming sessions: These are group sessions where people from different fields and backgrounds sit together and discuss potential solutions and ideas for a business problem. There should be a process and agenda for these sessions where the problem or objective should be explained, ideas are to be discussed and the best ones should be selected.
3. JAD: Joint Application Development (JAD) sessions are a series of meetings held in collaboration with external and internal stakeholders, developers, BAs, SAs, and other team members. These meetings outline the basic scope and objective of the project and end users state the exact need for the service or product. These meetings can usually last from 2-3 days to a week. Usually, in these meetings, the software solution is thoroughly discussed, and architectural frameworks are reviewed.
4. User Story Mapping: This activity helps organize our user stories in an organized manner so that the whole customer journey is outlined. This also helps identify any gaps in the process. It is a method to break down the product vision into actionable steps.
5. Conduct workshops: Requirement workshops are planned events that include select stakeholders to discuss, define and prioritize a clear set of desired objectives. There should be a clearly stated agenda for such an event. This activity is beneficial in getting viewpoints of different people and encourages collaboration within the group.
6. End-User Observation: The concept of user observation is to closely observe the day to day activities of an end-user to learn significant as well as minute details that help in accumulating requirements for the product/solution. This could be just silent observation or participating with the user to understand things better. One example of such type of activity is usability testing, where the primary objective is to observe and understand how the user interacts with a product or service.
7. Analysis of existing documents: Going through existing or related documents can be of great help when working on improving or enhancing the state of the product, platform or architecture. Analysis of existing information can also provide insight into what was working or not working earlier and how things can be improved and built on.
Why is it important?
The whole process of gathering requirements is to understand the nature and scope of the client's or end-users' goals and necessities. According to TechRepublic history and experience show that 50 - 60% of project failures are due to improper or inadequate requirements. This phase can be one of the biggest challenges in project management or a software development life cycle, as ineffectual or unclear requirements can result in failed projects.
Proper requirements not only help in understanding and delivering better user needs but also help build the pathway to improved solutions. Requirements in project management also sets the base for budget, schedule, cost, and operations. For all the stakeholders, end-users and other partners to have a holistic and similar view of the product or solution, it is of utmost importance that proper and meaningful requirements have been captured and analyzed. As a Product Owner, I truly think that 80 - 90% of the work is already done if the team knows and fully understands what needs to be developed and delivered to bring value to the business.
To learn more about how gathering proper requirements not only helps in understanding and delivering better user needs but also helps build the pathway to improved solutions, email our team at sales@architech.ca.
