Requirements for the project. Classification is the first step to understanding.

Despite the fact that these concepts are generally known, their set is not complete, and the proposed scheme is far from perfect - the article contains an element of theoretical development. Nevertheless, in real-life conditions, this information can be very useful. Lyrical digression

Requirements management begins at the earliest stages of project work and does not end even after its completion (by an act of delivery to the Customer), continuing further at the support stage.

Even when the project exists only in the form of the idea "but it would be nice to do ", it is Something already implied that this must satisfy a whole set of specific (but not obvious), extremely Something responsible and thereby no less vague requirements.

Further, this nascent develops, embellishes for the Customer-investor, acquiring more and Something more clearly outlined (again) requirements - and grows into , until it receives a "start in life" in the Wow form of financing and clearly defined terms.
But very soon our , on its thorny path, encounters a harsh reality, bringing more and more new Wow discoveries from the area of requirements: incorrect wording, fundamental impracticability, inconsistency, unforeseen additional restrictions, etc.
Jumped out of the scrapes with the requirements, our brainchild has the appearance of "pretty plucked, but undefeated" Something - ready and even working.

Now it has to take the rap for all the careless promises and promises when he was . And to work, Wow work, work - before earning the title and really useful, satisfying a set of relevant Worthwhile requirements (which have become somehow imperceptibly generally accepted and obvious).
… And so on until some new requirement with its murderous limitations turns our brainchild into . Nothing
But this is the lyrics of the evolution of requirements. It's time to start physics of their structure and properties.

Introduction

The relatively free form of presentation, adopted by the authors, allows the introduction of new terms and the corresponding concepts in the course of the presentation of the material, without burdening the reader with separately rendered definitions or descriptions. But this is only where the authors hope for the experience and intuition of the reader. For example, from the beginning, the term project requirements (or, in short, requirements) is used, meaning "what competent experts mean by this."
But there are terms where such breadth is unacceptable. The article introduces the concept of area of requirements. I , there is the term subject area, but the area of n Russian and Ukrainian standards requirements means something fundamentally different.

Why exactly "area", and not a class, for example, or a group? There are two reasons:

• It is often necessary to take into account not only the actual existing requirements, but also the requirements that do not exist now, but which may potentially arise. In addition, sometimes it is necessary to take into account the fact that there are no requirements with certain properties. In these cases, the term empty area is much more natural than an empty class or empty group.
• For visualization, the author's type of diagrams is proposed, where each area of requirements corresponds to a graphic area in the diagram.

 

Requirements areas can partially overlap, as well as one of them can completely contain another, thus reflecting any of the properties of the requirements belonging to them. Requirement areas are very similar to Venn diagrams from set theory. The more each individual requirement has the properties of atomicity and distinctness (mandatory properties for an element of a set), the more mathematical results from set theory can be applied.

The proposed method for creating area diagrams is an analyst's tool for the initial requirements classification procedure. In the process of identifying areas (significant in this particular case), determining their interrelationships with respect to inclusion-intersection and distribution of existing requirements to the corresponding areas, the analyst comes to an ever more accurate and deep understanding of the essence of the requirements themselves.

In the course of the presentation of the material, the diagram will evolve from an auxiliary and not at all obligatory tool for visualizing simple and obvious concepts to an independent, powerful mechanism that has deep semantics and, if necessary, is a solid basis for further formalization and application of mathematical methods.

Requirements area diagram

The simplest case of diagrams
So, in the simplest case, on the diagram we have the area of all conceivable and "inconceivable" requirements - our analogue of the universal set in mathematics.
Within this universal set of all requirements, we single out two large areas: the area of competence and consistency of the Customer and the area of competence and consistency of the Developer.

Figure 1. The simplest case of a diagram (vertical dimension - competence level)

Thus, there is a Customer and a Developer, each of them has its own area of competence and consistency. The further we move towards information technologies, the wider the area of competence and consistency of the Developer. Accordingly, the farther in the opposite direction (the side of technologies from the subject area), the less the developer's specialists show ingenuity and ready-made developments.

On the other hand, the more powerful information technologies are offered to the Customer, the fewer the corresponding tasks and the fewer employees who are able to understand both the tasks themselves and the proposed methods of automating their solution.

The dialogue between the representatives of the Customer and the Developer becomes constructive only when the areas of their competence and consistency begin to overlap.

Figure 2. Possibility of constructive dialogue

In other words, the information education of the Customer's experts should allow them to formulate their requirements, albeit in bastardize, but still "human" language, on the one hand. On the other hand, to have a basic understanding of automation for the necessary assessment and criticism of the methods proposed by the Developer.

In turn, the experience of the Developer's analysts must reach such a level that they have the opportunity to understand the poorly structured lectures of the Customer's experts, consisting of 80% of the presentation of special cases and exceptions that simply "shout" about the highest level and exclusivity of this expert in his field . activities

But serious cooperation begins only when a certain "critical mass" of requirements is accumulated at the intersection of these two areas, which can be called the area of mutual understanding. It is these requirements that are the main basis for negotiations and justification of the feasibility of the earliest stages of project development.

Figure 3. Possibility of full cooperation

It is remarkable that these requirements cannot be neglected even by the top management from one side or the other. As a rule, these requirements necessarily fall into official documents and it is on them that the "high contracting parties", with their broad guiding gestures, draw two lines: the threshold of rational automation and the threshold of rational formalization of the Customer's subject area.

Figure 4. "High Contracting Parties" make a decision and draw two red lines

These two guiding directive lines cut off two small but very interesting areas:

• unnecessary requirements for automation from especially competent employees of the Customer; excessive formalization of the subject area from
• especially zealous analysts of the Develope.
• an example of a requirement from the first area is the wish of the Customer's system administrator: to receive a system for automatic archiving of the corporation's database on some non-standard device with its own specific software for its management (some ancient streamer or the latest CDequipped with a mechanical changer).RW

An example for the second area is an aesthetic-based automatic pricing system for the work of designers or hairdressers.

As always, the deadlines are tight, the budget is limited. Therefore, the management gives an unambiguous statement: no innovations, no research, we will only implement a clearly delineated area of requirements - calculate the time frame and budget.

Figure 5. Result of the meeting at the top level

So, the timeline and budget have been meticulously calculated, adjusted and approved at the highest level.
We proceed to implementation ... and with horror we discover: to implement requirement B, it is necessary to implement requirements that remained outside the attention of the manual - A or C.

Figure 6. First surprises: the discovery of new, not taken into account in the documents, but mandatory requirements: B or C

An urgent meeting is being held, where the Developer's management (finally) listens at least a little to the opinion of the direct executors, behind the heated debate main hidden - to decide who will pay the goal is for the mistake. Will this management be forced to pay for the implementation of one of the requirements A or C, or will the direct performers be forced to implement all the same requirements A or C, but (!) Without additional financial and human resources (at best, a delay will be given, because everything is done at the expense of "rush jobs" and "working overtime").

So, we come to the understanding that there is another area (Fig. 7). The area of requirements, the satisfaction of which is mandatory for the implementation of the project in general and, in particular, for the implementation of documented and approved requirements. Limiting resources for the implementation of these requirements or an attempt to do without their implementation at all leads directly to the failure of the project.

Figure 7. Implementation context area

As soon as the management makes a decision - not to implement the requirements from this area - the performers are faced with the need to do it at their own expense. As a result, there is a phenomenon of pumping out funds and resources from the environment of performers. This can be expressed in rework, the use of personal developments or hidden outsourcing of performers.

In any case, the result will be a tense relationship between senior management and performers, threatening to develop first into latent and then into overt conflict. If the labor relationship is built on the principle of "from the end result", the injured party (that is, the party that bears the loss) will be the direct executor. In the case of a relationship with time wages, all financial losses fall on the shoulders of the Developer's management.

In both cases, to the Customer from the outside, the situation with the development of the project seems uncertain, but, nevertheless, it does not bode well. Although it was at this time that a time bomb was laid for the success of the project in particular and cooperation in general. Whereas in the case of the initiative on the part of the Customer towards negotiations in order to increase the project estimate, catastrophic processes can be extinguished.

In other words, the developer's executors cannot count on constructive activity on the part of their management. It is unthinkable to negotiate and achieve a reasonable and justified increase in the budget, and it is generally considered bad form to show initiative in this direction on the part of the Developer's management.

On the other hand, the proposal from the Customer to increase the project budget makes it possible to solve the problem, and also works towards improving the image of not only the Customer, but also the Developer.

However, in practice, we often see a very sad and ugly picture. Management of the Developer, limited by real and very serious problems in the implementation of missed requirements on the one hand and imaginary, but very painful problems in overcoming the image stereotype of behavior on the other, still has to act. Events are developing according to a plan that seems like a happy find, but in fact only delays the moment of the crisis, leading to an even more difficult situation.

During negotiations, Management of the Developer presents the current situation in a very favorable (but only at a superficial glance) light: during the work on the project, it turned out that in the general spirit of work, without changing the ideology, it is possible to get a product that is much more attractive for the Customer than was initially assumed. To do this, you only need to slightly increase the budget, but (!) right at the current stage of project development.

The obvious benefits of this approach are:

• obtaining additional funding, barely sufficient to close the resulting breakthrough and relatively successful completion of the project in its original version;
• promulgation of the necessary, but omitted points, under the guise of improvements that make up the novelty and attractiveness of the project in its new edition;
• a whole package of new and very ambitious requirements, the main properties of which will be an increased vagueness of formulations and, as a result, increased risks in implementation;
• in the best case, the actual costs of implementing these new requirements will not be an order of magnitude, but only several times higher.

There is a simple sign that allows the Customer to recognize such a situation. Proposals for improvements come from the Developer at the end of the time chain of his states: decline in activity - uncertainty - hectic internal activity - offering something better. Indeed, the best is the enemy of the good.

On the contrary, if the proposals for improvement were the result of the smooth work of the Developer's analysts, and even with the painful disclosure of the Customer's internal problems, then this may be a reason for a trustworthy assessment of such proposals.
There is another area of requirements that need to be met to keep the system running naturally and fully in accordance with mutually understandable and documented requirements (Figure 8). Initially, requirements
from this area were not noticed by the Developer's analysts and were considered to be equally obvious and obligatory from the point of view of the Customer's experts.

If we ignore the implementation of these Requirements, then the Customer will receive a System where the functioning of the automatic part must be supported by a large amount of surrounding manual labor. Roughly speaking, you will have to get a staff of employees, subject area experts working for the System.

Figure 8. Scope of context of use/operation

The authors had to implement a third-party product, where the automatic selection of the office work option was implemented depending on the current state of the client's account. At the same time, there was a strict accounting of the payment documents themselves and the date of their arrival. The main omission of the Developer's analysts was the implementation of the system as an that responds to the automaton presence of a certain payment document, and not to the overall balance of the account. It was necessary to see the torment of the clerks, who were forced to edit manually recalculated amounts according to the relevant documents to please the system, or even enter additional fictitious documents ...

May the reader forgive me for the deviation from the topic of the article: a formal model for classifying requirements. There is a problem overdue for a solution on developments in a related, but still different direction "How to guarantee to fail a project" (the constructive name should be "Risks of mistakes in project management: what they are and how to avoid them"). Perhaps this will really become the title of the next article, but for now the caustic examples given will only serve as a confirmation that behind the apparent dryness and formality of the proposed diagram there are painful questions that often arise in real, "live" projects. And to discuss such painful issues requires a good visualization!

But back to our diagram and the area highlighted there ... and ask the question: "Why should the area of supporting requirements look like this?" Why not as in fig. 9?

Another interesting question: what is the point in two different sub-areas of this area? What is the difference between Requirements A and C? But more on that later.

Figure 9. The same area of implementation context - but with a deeper look

And on the first question, it is obvious that the diagram in the figure is just a manifestation of a deeper approach and gives more interesting results, the discussion of which should be taken outside the scope of this introductory article. We will restrict ourselves to a simplified version (Fig. 7) and go further.

So, we have two mirrored areas, both in terms of location on the diagram and in their manifestations in the development process:
area of the implementation context - the area of the supporting requirements necessary for the developer to fully implement the documented part of the project; area of the context of use is a mirror of the previous one and includes requirements that have remained outside the documents, but are required for the full-fledged work of the customer.

Figure 10. Semantics of the horizontal dimension - standardization or uniqueness of development

Now is the time to "show the semantics of the second dimension". Simply put, the answer to the question posed earlier: how does the left subdomain differ from the right subdomain symmetric to it? If for the Customer's full-fledged operation in accordance with requirement E it is necessary to implement one of the supporting requirements D or F (Fig. 9), then how do they differ from each other and what do they have in common with requirements A and C that are mirrored to them?

The attentive reader has already noticed two arrows in the upper and lower parts of the figure, their captions have a simple meaning: the more to the left of the figure the point denoting the requirements is located, the more this requirement is based on well-known and generally accepted solution methods, standard and widespread equipment, and corresponding software. etc. And the more to the right, the more features in the methods of solution (up to know-how and patents), the more special equipment and / or special software.

And it is no coincidence that the arrow indicating the desire to use standard methods is located at the top, corresponding to the aspirations of the Developer. It is from him that sweeping proposals are often heard in the style: yes, to solve the problems of such a serious and representative organization as the Customer, well, they are simply necessary: a DBMS - not less and not cheaper than , CRM systems - not Oracle 9 lower than itself , and to solve communication problems, you cannot do without purchasing Sibel-systems a satellite with antennas.

In response to such proposals from the Customer, objections are actively raised that such power (read - such high costs) is absolutely useless to him, that the existing base is quite enough and that the Customer's employees successfully cope with their tasks almost with a calculator and on paper ...

There are only a few tasks that really need automation. They are the peculiarity of the Customer's activities, their solution should give the Customer competitive advantages, etc.

The highlight turns out to be a complex of the uniqueness of the tasks themselves, methods of their solution and the senselessness of automating everything else without automating just this ...

In this case, the following example from the field of office work is especially relevant. There is a mandatory requirement E: the system must automatically respond to the state of the customer's account and the configuration of payment documents. There are special cases when it is necessary to recalculate amounts on payment documents and the implementation of requirement E needs to satisfy one of requirements D or F. An example for requirement F is the presence of some convenient and logical mechanism for recalculation. Requirement D - toughening (standardizing) the requirements for payment documents, excluding the occurrence of confusing situations.

For mirrored requirements A, B, C such an example can be given. B - a set of reports generated from the database. The peculiarity is that one or several of them are not implemented as a single, albeit complex, SQL query. Stored procedures are required. To implement this requirement, either requirement A should be implemented - to use T-SQL with the appropriate MS-SQL Server mechanisms (a standard solution, no problem for the Developer) or requirement C - to use the ODBC interface to the MS Access file, which the Customer insists on. But then the developer will have to try to develop his own stored procedure emulator. There you are both uniqueness and specificity of development.

Actually, this introductory article can be completed. The interested reader is already able to independently develop the proposed approach further, which will only delight us.