When are your requirements ready?
Business requirements and technical specifications are an important result of the work of analysts. Therefore, a reasonable question seems to be: when should requirements be considered ready, as a quality benchmark for an analyst?
In this regard, there are discussions on the topic of completeness, consistency, feasibility, understandability for the team, consistency with stakeholders. All necessary artifacts for development, of course, must be collected and properly designed. In fact, this is a discussion about the quality of requirements: requirements are ready when they satisfy the criteria of readiness (quality criteria).
Does the concept of “readiness” exist?
From a legal point of view – and it is the strictest – there is the concept of performing work under a contract, which is confirmed by the signing of the acceptance certificate (and not the concept of readiness). This is what happens when work is performed by a contractor, for example, when preparing technical specifications or business requirements. It would seem that in this case there is also a readiness criterion, but it is normative – that is, signing by the customer (stakeholder).
However, even in such a simple case, there is a nuance of the warranty period – defects may be found in the results of the work, which the contractor must correct. that is, it seems that the work has been accepted, but needs to be completed. Is she ready?
We all know very well that work can be done poorly (from some point of view), but accepted. The work may be partially completed, but accepted (everywhere). The work may not be completed at all, but it may also be accepted (this also happens). And where is the readiness? It happens even worse – the work is done perfectly, but they are not accepted – under various pretexts.
The legal process is a perfect reflection of the Waterfall development model. What is the parallel between the legal process and the development process within a company, where there are no acceptance certificates? In fact, they exist, but in a different form. In the form of management accounting and writing off hours for work stages. For internal accounting, “readiness” is the transfer of a task to a new status, for example, on a Kanban board. Only after this can developers take a task into development and allocate their time to it. If something is wrong, then the task can be returned to the analysis stage.
Transferring a task to another status is an administrative decision that can be made by the Scrum Master, the product owner, or the developer (analyst) himself, if such functions have been delegated to them.
that is, “readiness” is an administrative decision that may have nothing to do with the quality of the result. For example, developers write code and “done.” And then it not only contains a bunch of mistakes, but it turns out that they did the wrong thing. So what is “ready”?
But this is from a formal point of view, but what about the actual one? In Agile development, for example:
Requirements do not have to be complete. Because that’s the point – we start with what we understand, then we clarify, supplement the requirements, and make a new “value increment.”
“Understandability“for the team is a speculative statement by theorists. How can it be clear if you haven’t started doing it yet? At first it seemed clear, then it turned out that there were many questions. Further more. And this is a normal Agile process. Understanding and interaction are more important than formalities. People are more important than a document.
Controversy? Something was not corrected in the previous version of the document. But people are more important, the result is more important. Yes, it’s contradictory now, but they explained, agreed and corrected it.
“The necessary artifacts have been collected“—they can be collected formally, but in fact it turns out that something is missing or there are questions. Everything is decided in the process, and not by the criterion of readiness.
We forgot about “feasibility“: the requirements must be feasible in terms of technical capabilities, time frame and budget of the project. Only in reality, both deadlines and budgets change.
Stakeholder approval – the magic words “agreed”, “approved” – isn’t this the most important criterion of “readiness”? If stakeholders have negotiating power (and they do have it – especially customers and budget owners), then at any moment they will say that they meant something else, that they were misled. They may stop working with this formalist contractor and he will not receive the next volumes of work, he will not deliver the current ones, and he will also have to answer or will still have to answer.
So what’s the bottom line with “readiness”? There is a deep philosophical meaning to the agile approach. “Readiness” for theorists is a frozen concept, divorced from life. In reality, the requirements are never ready, and development never stops either.
In Agile, people and interactions are more important than processes and tools. A working product is more important than comprehensive documentation. Cooperation with the customer is more important than agreeing on the terms of the contract. Being prepared to change is more important than sticking to the original plan.
How to make a decision?
Thus, “readiness” is a subtle concept. However, you have to make a decision for yourself – when are the requirements ready and can we proceed to delivery and acceptance?
There is a managerial answer to this: when the conditions for acceptance in the technical specifications are met for this work (for preparing requirements – in this case).
First of all, any job must have a technical specification. It may be formulated explicitly, or it may not be so explicit.
An explicit technical specification for work is a document that contains a description of what should be done and in what form the result should be presented. Even if business requirements are made, technical specifications are developed.
Absolutely right, this is called “TK on TK”. For large projects, it is necessary not only to prepare technical specifications, but before that to understand what should be in it, with what degree of detail, what methodology is used to prepare the task, and in what format the result is expected. Therefore, a technical specification is written for the development of a technical specification.
In large companies, requirements for the content and design of business requirements also exist. The process of preparing business requirements is described, a document template, methodology, approval template, and examples of requirements prepared in accordance with all the rules are provided.
In small projects or in companies at an early level of maturity, there may be no methodological documents, but there are always business practices and expectations in what form the result will be presented.
Practical recommendation
First, find out the requirements for the result, not only in form, but also in essence. Then you can decide for yourself whether the requirements are ready or not.
However, “unpreparedness” does not mean that the requirements need to be brought to the ideal – work until you’re blue in the face, especially if there are no specifics in the “TK on TK”, or the customers also don’t have an understanding of what the result should be.
The decision to be prepared is your decision, always in the face of uncertainty.
Disagreements between implied understanding result and fixed understanding – the main reason for complaints about the work of analysts and conflicts with the team. Therefore they must be allowed.
There are three options for resolution:
“Speaking” of expectations
Flexibility and willingness to make improvements ex post facto (after formal acceptance)
Diplomacy (liaison)
Flexibility and willingness to make modifications means that you can consider the requirements ready for a given point in time, for a given state, understanding the tasks, with the information currently available. Not everything is known right away – however, the requirements can be clarified during the development process. The disadvantage of this approach is the amount of work that must be completed and paid for. Your work.
Diplomacy (in this context) is the art of presenting any result as perfect – through proper work with stakeholders and their expectations.
Thus, the “readiness” of requirements is not synonymous with their quality. “Readiness” of requirements is your decision about professional responsibility, understanding of the situation, risks and willingness to resolve them.
