What are business requirements and how to (not) deal with them
The beginning of any project is the idea of the customer or product owner, formulated in the form of business requirements, technical specifications or notes on a napkin. How wonderful the development process would be if the important details were worked out already at this stage!
Unfortunately, these most important details are often left out. Instead, we get contradictory and confusing descriptions, leading to the opposite of the intended result. Along the way, a collection of funny (and sometimes not so funny) pearls is formed, which are later taken away into memes or become part of a team sticker pack.
About me
My name is Evgeniy Bondarchuk, I am the head of the development team at Magnit. Today I would like to discuss the problem of communication between business and IT in terms of setting and understanding business requirements, and also propose solutions that have already helped in a number of projects. Go?
Disclaimer: what is described below was collected from different companies and projects, so any similarities should be considered coincidences only.
The cause of the problems, or Lyricists vs Physicists
One of the most popular conflicts in human history could not help but reach IT. The customer wants something, but cannot explain what exactly. The development tries to understand the customer’s wishes, but in the end it understands the wrong thing, does the wrong thing, and generally “you don’t understand, this is different.” Somewhere nearby there is a sad manager wandering around who is trying to help everyone, but in the end he receives his share of rays of goodness and positivity from both sides and, with the wildest burnout, goes to treat his nerves in the nearest house with yellow walls.
In fact, each side is right in some way. But how then can we formulate clear requirements if everyone has a different vision of the project?
Solution
Speak the same language as the customer
Better yet, create a common glossary with the correct names of objects, and then the tables on the front will remain tables, without turning into mysterious boxes (for you) and incomprehensible grids (for the customer).
Create a business requirements template
Collect wishes for the format and structure of requirements from everyone involved in the development process: system analysts, developers, QA, maintenance, RP.
Discuss the proposals received from the team with the customer, think over the mandatory and additional ingredients of an ideal business requirement.
Together with the customer, create a template for business requirements so that it is convenient for the customer to fill it out, and for you to read and understand what is written.
Define Project Goals
Make sure that you correctly understand the “pain” that needs to be solved, and the customer – what exactly he will get as a result. You can explain it even with cats and dogs, the main thing is that you find mutual understanding. And then a glossary will help (I hope you already use it?).
Just please do not follow the advice in the Simple Sabotage brochure and create meetings for the sake of meetings and commissions to resolve issues that could be resolved in a couple of minutes.
Say “No!” technical implementation in business requirements
Yes, customers come from different technical backgrounds, but if you have a hammer in your hands, then everything starts to seem like nails. And if a person has worked in Bitrix for a long time, he will often not be able to offer anything other than Bitrix, imposing restrictions of a third-party system on the product that you ultimately plan to make. A real example from experience – they may be asked to “Download the entire Internet into Excel.”
Record key project performance indicators
If the business requirements do not contain an unambiguous way to measure the results of the project implementation, then most likely you have big problems: the customer does not know how to evaluate the resulting product, and the team does not understand the real benefits of the project.
Add mandatory indicators to the business requirements template, rob, stealbut the criteria for the effectiveness of the project must be recorded.
Involve the customer in the entire software development cycle
It would seem that this is a classic of flexible methodologies, but often the active activity of the customer ends with the phrase: “Here are your business requirements.” By the time of the MVP or demo, it can be difficult to agree on something. This is especially noticeable on long projects, where during development a large part of the composition can change – both on the customer side and on the development side.
The best battle is the one that hasn’t started, so you can lay out straws in advance and clarify everything on the shore.
Chef's secrets, or what should be in business requirements
Let's try to formulate the main sections of business requirements:
Information about the customer (name and function)
Modified system (if any)
Priority of the project or improvement
Desired project release date
Brief description of the project goal
How does it work now?
Description of the current business process
What systems are involved in the business process?
What information is used in the business process?
What information is transferred as part of a business process?
What information is obtained as part of the business process?
What are the current business process challenges?
How should it work? (description of desired improvements without technical details)
Use Cases, including negative ones
Current performance indicators (metrics)
Expected performance indicators (metrics)
Additional Stakeholders
Who might be affected by the improvements?
Who should be informed about planned improvements?
What additional functions need to be involved in analysis and development?
Limitations and risks
Conflict with the interests of other company functions and systems
Legislative risks
Etc., risk management is a separate topic, but the more we learn at the stage of business requirements, the fewer possible problems we will have later
Example of bad business requirements
Make it work. Yesterday.
Another example
Happy end*
To conclude, I would like to say that this article does not set itself the goal of coming up with a “silver bullet” that will solve all the problems of interaction between the customer and development, but perhaps will help to establish communications and structure approaches to working with business requirements.
*No customers, managers or developers were harmed during the writing of this article)
