On the quality of requirements in IT projects, to be honest (from the standpoint of the development team). Part 1

Based on my earlier article ...

Introduction

To get a medal, and even with its reverse side we find what to do.
(Georgy Alexandrov)

In the vast majority of works on requirements management, which I happened to read [1], [2], [3] and others, the authors dance around the customer, focusing the main attention of readers on how to efficiently organize work with him. And of course, the lion's share of labor is usually devoted to the issues of converting the information gathered into certain design solutions that simulate the system being developed, and also design them with special effects, bows and ruffles. Of course, this is all important and I do not want to implore the significance of these aspects of the formation of requirements, but there is also a downside. After all, further requirements should fall directly into the "shop" for the production of software. And it is there that, until the birth of the target product, they will remain the main body of laws and rules, according to which it will arise and appear to the world. This fact in itself determines the importance of how accurately the requirements should correspond to the interests of the specialists who are called upon to embody them in the final product.

Therefore, let's take a look at the quality of requirements through the eyes of a team of performers: developers, quality management specialists, project managers. After all, these people are the main consumers of the analyst’s work. And the quality and the final cost price of this product depends on how accurately the created specifications are suitable for a specific team to process them into a finished software product.

Why I took to writing this article

It is the work of an analyst in IT projects designed to show the customer - the product of his dreams.
For programmers with this task often fail.

A little bit about yourself. At the beginning of my career, I worked as a programmer, then as a head of a development team, but after 18 years, I was just not interested in coding and I decided to change my view of work, plunging into the scope of systems analysis and project management. In this field I’m already the tenth year.
')
Since I had the opportunity to work in all three of the listed guises in different software companies, I have repeatedly observed the distortions of priorities in this triumvirate. I worked in a team where there were no system analyst posts at all and his role “spread out” between programmers - “free artists”. I worked in a team where the system analyst was its leader and tortured developers with fortune-telling on various diagrams and “immersion” in irrelevant, from their point of view, details of the subject area. In my practice, there was a team whose leader was poorly aware of the content of work and analysts and developers, he was able to sell the product well, so he did not go into details of this kitchen and everyone “cooked at ease”.

What am I getting at? The software development team has a healthy conflict of interest, at a minimum, between a group of analysts, a group of developers, and project managers. And like any conflict, it can be used as an opportunity to continually improve the quality of the software development process itself.

For what and for whom this article is written

Small development teams make life difficult for individual groups of society, large ambitious teams spoil the life of all progressive humanity

The main idea of ​​this article is to draw the attention of analysts or those who actively influence them to the following aspect: "The key factor for effective software development is the correspondence of the fruits of the analyst's activities to the needs of the team that will implement them in the target product."

The purpose of the article is to help analysts (especially young ones), together with the software development team, find their ideal variant of requirements specifications, including: composition, level of detail, form, procedure for presenting information, etc.
The effect should be achieved due to the fact that team members will no longer spend time solving the essence of artifacts used in the requirements and converting them from the analyst's vanity format to the format most suitable for their own use. They no longer need to search for the necessary information "spread" on the requirements. On the contrary, the materials that will be provided to each participant, swords by step will carefully guide them in the process of carrying out their work on the project from release to release.

The topic considered in the article is especially relevant for teams that want to put the software development process on stream and build a technological line for the production of software products. Ideally, such a team should have a kind of “pipeline” - a virtual tool that transfers the results of work from stage to stage, from participant to participant, from problem domain models to solution domain models within this production line. With this approach, all the activities of the team are regulated and the work is clearly rated in terms of resource intensity. This coordinated mechanism regularly, in accordance with the plans and estimates, produces software products, like "hot cakes". It sounds like a fantasy, but I really want to believe that such commands can exist in nature.

Discussion of the "pipeline" and the software development line is in itself worthy of a separate article.

Tempting? Then we go further ...

Returning to the topic raised in this publication, we highlight the main circle of stakeholders, mentioning their needs:

1. The main consumers of requirements specifications are the developers. For them, it is important how profitable these specifications will be, in terms of quickly and accurately converting them into program code.
2. For a project manager, it is important how comfortable he can “cut” specifications for atomic tasks for the rest of the team. Atomic tasks, on the one hand, should be a clear, unambiguous task for the contractor, and on the other hand, should be a predictable measure of the use of resources for drawing up a detailed project plan.
3. For professionals who ensure the quality of the product, it is important how convenient it will be for them to form according to their requirements - test scripts, acceptance cards, etc.

With such an arrangement of accents, in the process of forming requirements, it is necessary to very clearly focus on the technologies used by the development team. Since in one article it is difficult to cover the maximum range of subject areas and applied technologies, I will consider as an example a cluster of accounting systems that use relational databases and technology platforms that allow the use of ready-made components. Components, in this case, should be understood solution templates that aggregate the functionality of popular services (for example: the list component, the form submission component for data editing, the search subsystem, the access rights differentiation subsystem, etc.). In order to make the presentation of the material more visual, I have included in it fragments of the requirements specifications of the training project: “Automation of the Requirements Management Process”.

DETERMINING THE SUITABLE VARIANT OF THE STRUCTURE OF THE DOCUMENT SPECIFICATIONS

For poor quality requirements the customer always pays. Sometimes immediately, sometimes by installments

Perhaps, after the following statements, I will have many critics, but I will take the liberty to consider the specifications of requirements, as an interface between analysts and developers. Yes, there is a “stretch” in this statement, and therefore we turn to clarify the term to the encyclopedia. "Interface - a set of possibilities, methods and methods of simultaneous operation (including through the exchange of information between them) of two common differences, that is, not linearly connected, information systems, devices or programs, defined by their characteristics, as well as connection characteristics, exchange signals etc.". Already feel the similarity?

We will accept the assumption and we will consider analysts and developers - information systems. This will allow us to identify requirements specifications as “a set of unified technical and software tools and rules (descriptions, agreements, protocols) ensuring the simultaneous interaction of two systems or ensuring the compliance of systems”. This means that the proposed structure for the presentation of specifications of requirements in this article will act as an exchange protocol, ensuring interaction between a group of analysts and developers. This will allow us to isolate the analysis and design design layer from the implementation layer of the final specifications in the target product. That, reading the text, you imagined approximately the same picture, as I will fix it in Fig.1.


Figure 1. - Integrated scheme of interaction of the IT project team

In order to discard all unnecessary artifacts developed by the analyst (they are marked as “Requirements” in the picture) and in demand at the design stage, but useless and sometimes harmful for presentation to developers, we will define the objects that should be used in our interface ( specifications). To do this, you must answer the question: what are the developers working on when creating the final product? Since the development of software based on a platform was chosen as an example, the target system can be represented as a set of components, the continuous harmonious interaction of which leads to the “effect of a running program”, as shown in Figure 2.


Figure 2. The target system component model.

Thus, in the specifications for the selected option, the instances of the elements indicated in Fig. 2 must be described in detail. 2 and how to implement them. That is, the system analyst must translate the fruits of his work (or the work of a business analyst) onto the rails used by technology developers, describing specific elements, algorithms of their behavior, etc., in terms and concepts of the chosen platform. The degree of depth of translation can vary, depending on the competence of the system analyst and the needs of the development team.

Now that we have decided on the composition of the elements of the specifications, let's find out the possible order of their presentation in the document. Since the different stages of execution depend on each other or on the result of their activity, we will establish a sequence in which they are more convenient and more rational to perform. Figure 3 shows a model of a possible process — creating software based on requirements using the technology platform described above.


Figure 3. Model version of the basic software creation process.

The figure shows a process that includes functions performed sequentially (displayed in the form of figures similar to a large arrow). The upper part shows the resource performing these functions (developer), in the lower part, elements of the target system involved in the process. Arrows indicate information flows that provide data transfer from function to function. Everything is simple and clear.

Thus, our section of the document structure must include the following sections:

1. Essence of the subject area;
2. User interface;
3. Procedures related to user interface events;
4. Auxiliary processes (triggers, post-processing, etc.);
5. Periodic tasks;
6. Report templates;
7. Access rights;

Also, if necessary, you can include sections with a description of Workflow, contextual search conditions, etc., from what the platform uses.

All other design objects developed by the analyst should, if possible, be excluded from the requirements passed to the development team in order not to disperse their attention and not to increase the volume of the document.

In the following sections, I will give examples of how the reference specification requirements in this way may look like. I will also show by examples the options for their effective use of PM and QA by specialists.