How do we implement the requirement analysis?

What does the planning process look like?

The requirement analysis is included in the planning process, which, in turn, should be as follows:

1. A project vision that describes the final product to be created.
2. A general action plan or idea that sets out what needs to be done to achieve our goals.
3. List of basic tasks that determine the stages of work on the project.
4. Time planning, in which we define what and when should be delivered.
5. Detailed planning of individual tasks created during stage three.

The requirement analysis covers the first three points of the planning process.

Project vision

At this stage, we should ask ourselves some basic questions:

1. What do we want to do?

For sure, at this point, we are already aware of what we are striving for, and the project idea has long been presented and thought through, but it is worth thinking about it deeper. Perhaps, we will discover new issues that are worth explaining. The following issues may be helpful here:

• What problem should this project solve?
• Who will be its end user?
• Are we creating an interface for users? Is its creation planned in the future? Has the type of interface we create (desktop or mobile) been determine? Do we care about RWD?
• Are there any similar applications? What are their pros and cons?
• Have any initial designs or mockups about the project been created yet?
• Will the project depend on any external applications? Do they have or do we know their limitations?
• Do we know anything about the expected performance and the level of security?

2. What are the requirements?

Now, the time has come to establish a list of requirements set for the project. In addition to functional requirements, we specify those not related to functionalities: usability, responsiveness, speed, performance, and security.

Let us check if each of the requirements meets the following criteria:

• is complete — we have its full picture,
• is correct — truthful and expected,
• is feasible — feasible and other requirements do not negate it,
• is necessary — it is needed for the system to operate or is required by the customer,
• is unambiguous — legible and impossible to misinterpret,
• is verifiable — after implementation, through observation and testing, it is possible to determine whether this requirement has been met or not.

3. What is the final goal?

It is worth creating a simple visualization of the project’s operation here. Nothing helps to fully understand the idea of the project like drawing a basic flow or simply writing on the board in points what is to happen in turn. In the case of an application with a user interface, the ideal situation is to have even the simplest mockups.

4. What are the priorities?

Just like when building a house, IT projects should start from scratch at the beginning and then turn to what you need most. At the beginning, therefore, on the basis of the list of requirements, it is necessary to specify a list of all possible functions that a given project will perform and then agree on which of them have the highest priority and are to be carried out as soon as possible and which are of the “nice-to-have” type.

The result of the entire project visualization stage should be a general picture of how the project should work whether through mockups or the drawn flow of activities. We should also receive a list of all possible functions that a given project is to fulfill and also know what priority each of them has.

Project visualization is a key moment during the requirement analysis. It helps in thoroughly understanding the essence of the problem, and the better the materials illustrating the problem, the more efficient the next stages of planning.

Action plan

At this stage, we already determine how we imagine the operation of the project as a whole. It is good to have a few ideas for implementation, think and discuss each of them, and highlight their weaknesses and strengths. It is also worth drawing a chosen idea in detail here, if not all.

This stage is also time to consider purely technological issues not only in what language or framework will the project be written but also what additional tools will we need, for example, do we decide to use the AWS stack or maybe something else. If we are hesitating between some technologies or have no idea what to use, then it is worth shifting such a decision in time and delegating to a research task. Certainly, we can only do this if further planning is not blocked by such research. Otherwise, we can safely attach them to the tasks in the sprint.

Main tasks

Once we have established the project plan, we proceed to define the main tasks, which will then be discussed in detail and broken down into smaller tasks by the development team when planning a new sprint. It is important to describe each task as accurately as possible.

Summary

As mentioned earlier, the requirement analysis process will vary depending on the complexity of the project. There are easier and more difficult problems, and there are also those that have already been solved by someone and are completely new ones that you need to stop for longer. Regardless, there are some important tips to keep in mind:

• Communication. This is the most important component of every project life cycle; everything should be clearly defined and explained.
• Quickly understand the problem. It is great to have project documentation written, but let us remember that it is as concise as possible and does not take a thousand pages. Each member of the development team should have access to it and should be able to quickly understand the project vision.
• Simplicity above all. Let us try to make what we plan as simple as possible, choose simpler solutions that can be easily developed in the future, or give them up when the need arises.
• You are not going to need it. Considering that in programming we are guided by the YAGNI principle, here, we have it at the back of the head and do not accelerate too much.
• Changes. Let us not be afraid of them; sooner or later every project needs them. In addition, let us not delude ourselves that what we plan today will work forever. At the same time, we should not treat changes as something bad and undesirable. Changes should be synonymous with improvement, and this is what we want: that the project is the best.
• Time. Let us not let planning take too long and drag on forever. If we have a problem that blocks us, then let us look for solutions outside or choose the easiest option.

The above aspects are always worth remembering when analyzing the requirements, and then it will run smoothly and will be the basis of a well-planned project.

Read more:

• What is the best project management approach to software development?
• Codest’s good practices for building software. Our approach to customer journey
• A quick guide to building and developing your own marketplace. What is worth to know?