Why are requirements important?

But it doesn't mean that you should sit still and wait for the changes to 'respond' to. You should be careful and not deviate from the requirements analysis too much. It matters a lot whether you're working in Agile or in Waterfall methodology.

But in order to understand why the work with requirements is so important, it is necessary to define the notion itself. You would think: it’s a perfectly ordinary word. But it is not as ordinary as it seems.

According to the worldwide acknowledged Business Analysis Body of Knowledge a requirement is:

1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in [1] or [2].

The latest BABOK Guide defines a requirement as “a usable representation of a need.” Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled. In layman’s terms, a requirement is directly what is needed to be implemented and what we expect to get. The requirements contain the behavior, attributes, and properties of the future system. Therefore, the main task of the requirements is to ensure that they are understood by all stakeholders.

The work with the requirements involves various processes, e.g. identification, analysis, verification and, finally, management. In our company, we try to follow streamlined processes.

Types of requirements

To work efficiently with the requirements, you have to differentiate between the various types of requirements. According to the BABOK Guide, there are:

• Business requirements
• Stakeholder (user) requirements
• Solution requirements:
  • Functional requirements
  • Non-functional requirements
• Transition requirements

Let’s now have a closer look at them.

Business requirements

Business requirements are business statements of the goals, objectives, or needs which should help the organization to maximize profit, minimize expenditures, raise service to a new level, or meet the regulatory requirements. As a rule, they are dictated by those who deal with financing of the project, the buyers of the system, the manager of real users, or the marketing department.

Stakeholder requirements

Stakeholder requirements, also known as user requirements, are the requirements that should include the goals and objectives which the system will allow the users to achieve.

Solution requirements

These requirements specify the functions and qualities of a solution. They provide the appropriate level of detail to allow the development of the solution. 

Non-functional requirements

Non-functional requirements are the quality attributes, certain design or realization constraints or external interface that directly relate to the product. They act as an additional description of the functions of the product under development, which are important for stakeholders (users or developers). For example, it may be the ease of use or movement, integrity, efficiency, and fault tolerance.

Functional requirements

Functional requirements are the product features or its functions that must be designed directly for the users and their convenience. They define the functionality of the software, which the software engineers have to develop so that the users could easily perform their tasks up to the business requirements.

Transition requirements

Transition requirements describe requirements that must be in place for a certain period of time or phase. These requirements facilitate the transition from the current state to the desired future state. Transition requirements have a temporary nature, meaning they won’t be needed once the transition is complete.

So why exactly are the requirements so important?

Good, detailed requirements are one of the critical keys to project success. They allow us and the client to:

• Get a deeper understanding of the future product
• Reveal hidden and assumed requirements
• Clearly define deliverables and build only relevant functionality
• Lay out predictable project timelines so we can plan accordingly

In simple words, we (at Globaldev) know what to do and you (as the client) know what to expect.

During our work, we faced a couple of situations which will help you understand the importance of high-quality requirements. First off, it should be mentioned that “I want a Facebook and LinkedIn-like messenger” is hardly an appropriate requirement, to put it mildly.

In the beginning of the work, you’d better sort out the terms and the roles in the first place. It seems awfully obvious and redundant at first sight. However, stakeholders may give the same things different names (and most likely everyone will be right) which can result in lots of misunderstandings in future. So the practice proved it to be a good idea to create a list of terms for the client, the team, and other related parties. The same is true for the roles in the product as different types of users may sign up in different ways. For example, in one of our projects after we clearly defined 4 types of users and their rights in the requirements of a job search service lots of misunderstandings cleared up.

The role of stakeholders in requirements elicitation

The way to what extent your team is involved in the elaboration of the requirements is also of a huge importance. It is much more efficient to include the team in this process, because all the questions asked and ideas offered make it possible to write high quality requirements for the software product. For example, working on one of our projects we involved our QA engineer into the discussions on the early stage and managed to go through various scenarios and thus create high quality requirements. And you do remember that quality influences development, right?

In everyday communication with clients we lay stress on functional requirements in the first place. It’s necessary to understand clearly what goals and end result the client pursues. Everyone sees the fish in the ocean, right? The same holds true for what we do. You should pay enough attention to requirements, discussing obvious things sometimes that some people may see differently though.

How detailed should the requirements be?

Another important point is how detailed requirements should be. Every project is unique and we try to apply an individual approach to them based on their peculiarities. However, the practice proves that the more detailed the requirements are the more precise the estimate is and there are more chances to meet it. We try to be detailed when putting together the requirements and means of their implementation thus mitigating the possible risks. This approach also provides an opportunity to see the possible mistakes before the development stage saving time and money. Experience teaches that the availability of detailed requirements helps the team to estimate more accurately the time that will be spent on the implementation of certain features. And in addition, you’ll get the estimate which the team is responsible for.

Requirements elicitation in a nutshell

As Ramos Rowel and Kurts Alfeche put it: 

Requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders.

Typically, the elicitation process is divided into the following stages:

• Prepare for elicitation — Defining the desired outcomes, collecting documentation, analyzing stakeholder roles, and choosing the right elicitation techniques.
• Elicit requirements — Drawing out, exploring, and identifying information required to analyze, model, and specify requirements. Requirements elicitation isn’t a ‘phase’, it’s rather an ongoing activity that’s conducted throughout different development stages including discovery, modeling, and quality assurance. 
• Confirm elicitation results — Checking whether the information gathered during an elicitation session is accurate and consistent and meets the stakeholder’s expectations.

You start to work on requirements in the initial stages of collaboration. First, you need to agree upon them and put them all together. In our company, this phase is parallel to wireframe development. Besides using MVP development strategy here is a huge advantage. You can get more information about it in our blog.

This technology allows clients to run their business within the shortest time period and eventually add features to their product being live and making money. While working on the requirements your priority should be to help to identify the key points and the main functionality of the service required for a successful start. And in the future versions of product, you can add features that the customer "wants" and "likes".

A comparison of the requirements and the results during the development will visualize the progress and show if we achieve the objectives. On a more global scale, requirements of high quality alongside wireframes will help to visualize the end result and to what extent will it meet the goals of the project.

Conclusion

The requirements are crucial when starting a project if you want to achieve a desirable result at the finish line. They should include all the features and functions a product should have. Requirements should be comprehensible for all interested parties (customer, product owner, development team) and be free of any ambiguities (all the stakeholders should understand requirements in the same way).

But don’t worry if you do not have documented requirements.If you have a project idea or business problem to solve, our team will definitely help you elicit and develop requirements.

At Globaldev, we:

• Establish requirements documentation standards which include the combination of user story, acceptance criteria, and flow diagrams. These standards govern the structure and presentation of requirements and allow us to achieve great results across different projects.
• Offer product discovery services for custom projects. During the product discovery phase, we analyze existing documents and other materials and standardize them (according to our company’s policies). This helps us predict project timelines and budgets.
• We follow consistent processes and policies for requirements elicitation and management. It allows us to successfully develop projects following two different methodologies: Waterfall and Agile.

All these procedures enable us to build solutions, ensuring predictability and a stress-free environment.