Requirements. Why is it important?
In our work we come across the notion "requirements" every day. The importance of this word has increased due to the growing popularity of agile software development methodologies. One of the points of Agile Manifesto claims that one should choose «responding to change over following a plan».
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 though. It matters a lot either 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:
- A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
- 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.
- A documented representation of a condition or capability as in [1] or [2].
So 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 the streamlined processes. You can see how we build projects from scratch here.
TYPES OF REQUIREMENTS
For working efficiently with the requirements you have to differentiate between the various types of those. Let’s have a closer look at some of them.
NON-FUNCTIONAL REQUIREMENTS
Non-functional requirements are the quality attributes, some certain design or realization constraints or external interface that directly relate to the product. They act as 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.
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.
USER REQUIREMENTS
User requirements are the requirements that should include the goals and objectives which the system will allow the users to achieve.
SOFTWARE REQUIREMENTS
Software requirements stand for high-profile requirements for the product under development that contain numerous subsystems, i.e. the system (IEEE, 1998с). ‘The system’ here stands for software or software subsystems and equipment.
THE NEXT TYPE OF REQUIREMENTS SHOULD BE CONSIDERED IN MORE DETAILS
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.
So why exactly are the requirements so important?
During our work we faced a couple of situations which will help you to understand the importance of the 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 way to what extent your team is involved into 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 the 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.
Another important point is how detailed requirements should be. Every project is unique and we try to apply individual approach to them basing 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.
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 with wireframes will help to visualize the end result and to what extent will it meet the goals of the project.
You start to work on requirements on 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 wireframes 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”.
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 function 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 cool idea and a definite goal our Dedicated Team will definitely help you to identify the requirements and write all the needed documentation.
