Course table of contents
1.
2.
3.
4.
5.
6.
7. < —
8. - -
9.
—
Sometimes it seems that the task for the developer is simply obvious! But do not rely too much on common sense in setting the problem. For any, even the simplest task, discrepancies are possible, because people tend to live in a world of their own illusions. For example, in the Republic of Cuba, it is believed that the walls should be bright and variegated, and even if the customer asks to paint the walls white, workers can add color spots, because "it's more beautiful this way." The same goes for development.
Such a document as requirements helps to overcome the “wall of misunderstanding”. The presence of requirements allows you to create the same idea of what needs to be done in the product, what exactly should be the feature.
How requirements are built
When formulating development requirements, you need to understand for which user we are developing the product. This is where User Persona comes in handy (we've already talked about them here ). User Persona is the so-called Actor in the system, and for each actor we define a set of rules and capabilities.
For example, the following actors can be defined in a web forum application:
- The administrator can do everything, literally everything - including assigning roles (persons) to other users.
- A regular user can only leave messages.
- The moderator can leave messages, delete other people's messages, ban regular users.
In the case of the taxi-calling application, which we periodically recall during our course, the persons can be a passenger, a taxi driver and an operator.
To formulate an adequate requirement, you need to draw up a document that we call Feature Description. And for this you need to answer the following questions:
- What for? What's the purpose? What are the business benefits?
- Why? What are the risks? What will we lose if we don't? What happens if we do?
- What? What problem do we want to solve? For whom?
- How? Functional requirements and use case (sequence of actions).
It is also necessary to provide for the presence of a vocabulary of terms of the subject area. This is especially true for specific acronyms. For example, the developer may not know all the process names and specifics of the steel industry or cooking.
Finally, the document needs to make a section “Approvals”, in which, on the one hand, the customers of the feature (stakeholders, customers, product manager) agree that the description matches what they want from the product. On the other hand, developers (team leaders, architects) will confirm that the task description in the requirements is clear and complete. Thus, all participants in the development process must say: “Yes, we understand the document, now it can be done”.
Auxiliary metrics
When working with requirements, auxiliary metrics help to achieve accurate execution of the task, as well as reduce the time spent on checking compliance.
- Definition of Done is a short description of how to know if a feature is working.
- Non-functional requirements - requirements for technical parameters such as UI responsiveness, backend load, CPU and RAM limitations. This is a very important point, because if you do not voice the requirements, you can get a monster - built-in photoshop instead of just choosing the color of the car.
- Security requirements - encryption, storage of personal data, etc.
- Corner Case - testing edge cases. What happens if the product price is 0? How many taxi cars can a person order at the same time?
- — , . , , , , — Visa, MasterCard, , .
- . , , , , . , , . , .
- . , “ ”, “ ”.
Functional and non-functional requirements, use cases
Let's dwell a little on functional and non-functional requirements.
The functional requirements explain what needs to be done, they list the actions of the application as a reaction to the actions of the Actor. These requirements are implemented in the listed Use Scenarios.
Non-functional requirements capture the conditions under which the solution must remain effective, or the qualities that the solution must possess. The most common examples of non-functional requirements are:
- scalability,
- reliability, minimum downtime,
- support methods.
Use cases are also used to describe the requirements. This is the main element of our document, which we prepare when generating a feature request. Scripts should provide a complete step-by-step flow of what a user can do with your application.
Custom scripts usually contain the following sections:
Section: Context
Answers the question: Which component? What is the condition?
Example: The user is not authorized.
Section: Actor
Answers the question: What person?
Example: Regular user.
Section: Preconditions
Answers the question: What are the features?
Example: There is an invitation to receive a VIP-status.
Section:Purpose
Answers the question: What does the user intend to do / get?
Example: Log in.
Section: Main scenario
Answers the question: What actions need to be taken to achieve the result?
Example: Enter your username and password, press the "enter" button.
Section: Bad Scripts
Answers the question: What can go wrong, a list of errors, including the text of error messages for the user.
Example: The button is not pressed, the language does not change, the connection cannot be established via the https protocol, and so on ...
Section: Layouts
Answers the question: Possible layouts or prototypes of UI design.
Example: Draw in Figma or Sketch.
In a simplified form, custom scripts might look like this:
To uncover
. ( e-mail) ( ). , , : « » « . »
How is Feature Description read?
Each category of users can gather useful information for themselves from the requirements. And so it is very important to keep in mind that the requirements will be read by different people:
- Developers - It is important for them to know why the feature is needed, what issue it solves. In order not to waste time on corrections later, developers need to provide a complete list of all scenarios, as well as pay attention to Corner cases. If you inform the developer in time about what we will add later, for example, payments with a MIR card, he will be able to foresee this possibility at the architecture level. Thus, costs can be significantly reduced by avoiding rework.
- , QA — , . Corner Cases. , — , .. ( , , ) . , . .
- DevOps Datacenter Operations— , , , . DevOps , , , .
- — , , . , , .
If you write development requirements, be sure to ask the question - who is your user, what he does (or can do), in what conditions he is. Create a diagram of his behavior, it will help describe all aspects of the requirements.
When drawing up a document, you need to be as short as possible and not leave incomprehensible places. Requirements will span multiple pages anyway. It needs to be read by many people, and it needs to be readable.
Follow a simple rule: start with the main thing and only then add details. In addition, you need to get feedback from QA, Developers, DevOps and other stakeholders. Most likely, the Feature Description will acquire new details after communication with the stakeholders.
Try to think of non-obvious scenarios. It is advisable to immediately determine what your application should do in emergency situations. Think about what external components are affecting your feature. And when everything is ready, once again ask the question: "What else can you test besides the steps described in the custom scripts?"
Conclusion
In the next article, we'll talk about the business plan and pricing for the new product.
In the meantime, share in the comments your experience of working with the requirements, both from the side of the manager and the executor. Tell us, was there an example in your practice when a functional customer wanted one thing, but in the end it turned out completely different due to misunderstanding?
→ Video recording of all lectures of the course is available on YouTube
Lecture on the roadmap and requirements for development: