What does the System owe us?
Or how to formulate business requirements on her behalf
Hello! My name is Sasha, I am a business/systems analyst at Kaspersky. I have been doing analysis for more than five years and during this time I have taken part in various projects – from the development of a management decision support system to the development of an ordering system. In this article I would like to share my thoughts on the topic of formulating business requirements to describe the behavior of the System.
Basic rules
First, let's look at the basic rules that I adhere to when forming business requirements.
Do not descend to the level of implementation. Each requirement captures a capability, action, or test that produces a business-significant result.
We are talking more about the user, because it is he who will be the consumer of that very result. We describe what he must do within the framework of our solution, what he can do, and what is generally inaccessible to him.
If we are talking about a system, then that’s what we should write – System. There is no need to talk about components, software interfaces and integrations. For the user there is only one component – the System itself, a kind of black box for him, which magically produces the result.
But still, in what cases do we write on behalf of the System? Let's take a look.
Performing checks
As soon as any checks or, especially, calculations appear, we must clearly understand who is performing them. And since we are still talking about business requirements, we must operate exclusively in business terms. As a result, the wording will sound something like this: “The system must perform such and such a check.” Now let's try to detail it.
First of all, we describe checks in broad strokes, without detailing to the system level. For example: “The system must check the order status: if the order is in status A or B, then the following happens.” No “if OrderStatus IN (A, B)” – the business customer most likely simply will not understand us.
The second important point is that we should always record what will happen if the check is not completed. In business requirements, it is most convenient to use the word “otherwise.” For example: “The system must check the order status: if the order is in status A or B, then the following happens, otherwise something else happens.”
And thirdly: if several conditions are simultaneously checked, we must always record all possible combinations of these conditions. If you don’t understand what should happen if condition 1 is met and condition 2 is not met, run to the customer.
Data transfer
The second major case when we should write on behalf of the System is integration. What should our System do in these cases? Everything is quite simple – we record the answers to two questions: what to do and when to do it?
First – what to do? The system must pass a set of parameters, obviously. We record this set of parameters in the requirement. For what? So that the customer clearly understands what he will receive as part of the integration with our System. And if we are talking about a data bus, then what will he find on this bus?
Second – when to do it? Here we record the conditions, or triggers, under which our System publishes data. Whether the request was received or whether the entity was updated – this must be clearly recorded, otherwise the customer’s expectations will not coincide with the realities of our System.
Interfaces
Requirements for user interfaces, in my opinion, should also be recorded in the document and agreed upon with the customer. And since the System displays them, then the wording will be appropriate.
What can the System display? First of all, a screen form, and hardly an empty one. So we write: “The system should display a form containing the following list of fields to fill out…”.
If we are talking about confirmation by the user of the completion of some action, then the logic is the same – “The system should display a confirmation form for the completion of such and such an action…”.
Separately, it is worth fixing the controls displayed on the forms – read, buttons that are available to users. In this case, for each button you need to indicate what will happen after you click on it. As an example: “The system should display a Send control whose interaction triggers something to be sent somewhere.”
What should the System not do?
After all of the above, a reasonable question arises – what to do if we want to get rid of any field or function in the System? Is it possible to write that the System should not do something?
Short answer: no.
Detailed answer: no, we write requirements exclusively in the affirmative form. And there are several reasons for this. Let's look at a couple.
The first and perhaps most important reason is that each requirement adds value and describes something new. In other words, it adds a new function, a new check or some new field to our System. Obviously, negative wording will not add anything of value.
The second reason is a potential conflict of requirements. We all understand that the System will develop over time. And a situation can always arise when functionality is required that was not previously declared, or rather, was not explicitly supported. And if such an exception is fixed in the requirements and nailed down as part of the implementation, then we get a conflict – the business expects new opportunities, and we answer that no, this is not possible. Sounds sad, doesn't it?
Well, the third reason is more funny. Our System should not do many things that you will forget to indicate in the requirements if you use negative language. The system should not brew coffee. The system should not fly into space. I think the examples are obvious.
But how can one say that the System should not do something? There are two options for you.
If we are talking about a new service or improvements to an existing one, then we simply do not write in the requirements that the System should not do something. Moreover, if the customer or someone from the development team asks to explicitly record that certain functions will not be supported in the System, then such information can be documented in the form of limitations of the solution being implemented. This will allow you to clearly understand what is not supported in the System, without clogging the requirements with negative formulations.
But what happens when some functionality is removed from the System? This is where an excellent formulation comes to the rescue, which I did not come to right away, but which I love with all my heart.
The system must eliminate…
Do you need to get rid of some fields in the interface? The system should exclude the display of such and such fields. Are there fewer checks? The system should eliminate the execution of checks A and B. Simple and elegant, in my opinion.
More such materials in my personal channel Analysts Deliver. Here I talk about the work of an analyst through the prism of my own experience.
