🤠 🕋 🍔 Finger software requirements 🧑🏿‍🤝‍🧑🏻 ☮️ 🔳

A post about the basics of developing requirements - without complex diagrams, terms and tables, but with gifs.

In short, the main steps in developing requirements are:

Why do we have to do something? (Need more gold)
What do we do? (everything is like people do, but cheaper)
How do we do this? (with blockchain and datasientists, of course)
When will we do this? (yesterday, and refactor “later”)

And now in more detail.

If you ever asked to do something, it means you created requirements. They could be in the form of an oral wish, letter, technical task, task or anything else.
So the requirements are everywhere.

If, after fulfilling the request, something went wrong - it either messed up the performer,
or you set the task incorrectly.

As you know, the wrong task can be quite expensive. For example, if for half a year a team of 5 programmers developed a system that no one needed.

In this turbulent age, Agile design requirements are often neglected. But flexible methodologies do not always save you from big losses. Therefore, even if you do not have an analyst on the project, even if you are not IT at all, do not forget about common sense and take from the best practices what you need at the moment.

So what are requirements and why is it important to be able to develop them?

So, let's turn to the sources:

That is, you can talk about requirements as about future properties. How about what a product that meets development goals will be.

Where to start developing requirements? A hint is hidden in the definition: you need to start with the goal - why do we need to do anything.

1. Why?

Like “ASAP !!!!” there was no need to do something - it is important to find the time and energy to find out why this is necessary.

Because often, after clarifying the goal, the task changes or is completely eliminated.

For example, the

Customer will promptly show him all the orders that were made in the system. Let's say we tensed up and shoved a task in the middle of a sprint to display all orders for the administrator. After that, the customer asks to display in a separate window a list of all the companies whose orders he sees. They did it too. Then the customer asks to withdraw in addition all the partner companies. Okay ... After some time, we meet with the customer and see how he uploads both lists to Excel, recognizes the difference and starts phoning companies that do not have orders to remind them to place orders through our system.

If we asked the customer from the very beginning what goal he wants to achieve by looking at all the orders, we would save a lot of time and effort by immediately reporting to companies that did not place orders so far.

You can use the “Five Why” method or any other. But usually people do not resist: if you show interest in their work, a solution becomes available.

Having decided on a goal, it is necessary to clearly define it and establish criteria by which you can accurately say that the goal has been achieved.

For example, the

process of ordering materials is considered automated if> 90% of partner companies place orders through the system.

This facilitates understanding of the tasks and at the same time frees up the hands in choosing the means to achieve the goal.

And yes, do not forget to coordinate this beauty with customers. In general, do not forget to coordinate the requirements with all interested parties.

2. What?

The goal is achieved in different ways. And the second important step in developing requirements is just about choosing the path - what exactly will we do to reach the goal.

, :

. . . // .

. — , .

. . .

To think over all the options, you need to figure out - what is happening now? How the process works without your system, how do users and customers work? Even if there is no process yet, detailed information about the current state is very important. So we will understand which solution will fix the problem, and not create another one.

Each implementation option has its pros and cons, its necessary resources and its level of result. Having modeled all the options, having worked out, or at least just having spoken this information with interested parties, you will be able to make a balanced and informed choice.

3. How?

So, we understood our goal and what we will do to achieve it. It remains to figure out how we are implementing this: which pages we will show to users, in what form we will display the report for the customer, how we will receive data from another system, how we will store them and so on.

This stage is a matter of technology. And if you have successfully completed the previous two, it will be much easier.
Although the technique depends on the context, it’s useful to move along the “checklist” of Wigers and other smart people. If for you some type of requirements is not relevant right now - okay, we won’t describe it. But it’s important not to forget and test yourself.

for instance

The questionnaire should contain a file with a photo, since a photo is necessary when processing documents - this is a business requirement . And perhaps a business rule.
- , — . , .
, — , . , .
base64 . — .
, . : 10.

For each business requirement, as a rule, there are several user requirements. A user requirement is decomposed into a number of functional ones. For each functional requirement, non-functional requirements and limitations must be considered.

Also, non-functional requirements and restrictions can directly flow from both user requirements and business requirements and rules.
In this way, trees are obtained from requirements, at the top of each of which is a business requirement.

4. When?

In the “forest” of your requirements, there are likely to be any mutually exclusive and any repeating ones. Therefore, it is useful to document and present all this beauty in the form of tables and diagrams.

There are many tools here: for example, BPMN for describing business processes and UML for creating schemes of interactions between services and components.

If you manage to explain to everyone what and how you want to do with the system, using a napkin and 3 coffee stains, then you are John Wick from analytics and this is amazing.

However, as a rule, the "spot" level of detail does not allow you to see the pitfalls and think through all the possible scenarios. After all, everything seems to be clear, but I drew a little diagram - and here you have an endless challenge, and a forgotten process branch, and the shortest path to gold.
Therefore, it is useful to know what tools are available to reverse chaos.

In a schematic and structured form, the requirements must be prioritized - depending on the utility (the customer and users will tell you this) and the complexity (the development team will tell you this).

And then you can already scatter on sprints / stages of development and implementation. Well, repeat these exercises within each iteration. And you will be happy - no alterations, a satisfied customer, a happy team, a product that works and benefits, the elves play the harp on a rainbow background.

Of course, there will always be problems. There will be alterations, burnt deadlines and bugs. It will not always be possible to go through all the stages and do normal analytics, agree or even just talk with the customer, document and trace the requirements. But in any situation, understanding “how it should be” helps make the product better. Even if at the moment you are doing “how it turns out” - you are aware that you are missing out and you know the risks. And if you know the risks, then you can manage them.

I recommend reading more about requirements in the book of Wigers and Beatty: “Development of software requirements”. Although the book is not always simple, but very useful. Most other material on the topic is a retelling of these truths with varying degrees of freedom.

Thank you for your attention and good design.

Finger software requirements

1. Why?

2. What?

3. How?

4. When?

More articles: