The practice of forming requirements in IT projects from A to Z. Part 1. Introduction

Prologue

Reading on this site articles on project management, there is often felt the pain of managers rushing out, caused by the inefficient use of resources in a project. And one of the main causes of these problems is often called the lack of quality tasks for product development. This trouble can manifest itself in different symptoms: in the form of difficulties with the delegation of abstract vague tasks, or mutual misunderstanding at meetings on solutions that only everyone has in his head, while they appear completely differently, etc. Reading about this, pictures from their own practice rush briskly in their minds. And now you are already tense and are trying to quickly move from symptoms to recipes to get rid of this headache. And what can we most often see? And then, as a rule, they are optimistic and decisive, slogans - prepare the tasks for the performers correctly, do not expect that they will quickly figure things out themselves, they will guess everything, or they will suddenly have insight. Wait! But how to do it? The authors, having raised the problem, for some reason, the search for its solution is left for the reader to work independently. But this is the most interesting and difficult.

In my article “About the quality of requirements in IT projects, frankness (from the point of view of the development team),” I tried to address these problems more specifically and told in my experience how you can transform the collected requirements for automation in an IT project so as to maximize team performance, embodying them in the target product. To raise it at the expense of well-formulated tasks for product development, covering the whole process.

Now I want to tell you how to formulate the requirements themselves, leading the Customer from his “wish-a-do,” to his happy and fruitful cohabitation with the software product, his dreams.

I Introduction

... in order to understand which of the ways you formulate requirements most suit you, you should use common sense and draw on your own experience.
Karl wigs

For whom and for what this publication is intended:
')
At the dawn of my career, I worked as a programmer, led the development team, kodil, kodil and kodil. But after 18 years, I decided to change the type of my activity, having plunged into the sphere of system analysis and project management. Since it so happened that the enterprises in which I was lucky to work did not provide for positions: analyst, project manager, product manager and other exotic at that time for me specialties, programmers had to manage the design activities of the listed specialties in one way or another. Naturally, these same activities were carried out not quite professionally, there was not enough time or fundamental knowledge for everything. In order to fill these gaps, I conscientiously sat down to study courses on the development of functional requirements, methodologies RUP, SADT, UML, etc. And after a while, I was lucky enough to get a job in one of the leading software companies in positions with a pathetic name: “Leading Customer Relationship Specialist”. The employer, knowing that I have no experience as a professional analyst, but only: desire, theoretical knowledge and extensive practical experience of the developer, gave me two books [1], [3] and “ordered” to be ready to write quality in a couple of months specification requirements for software development. From my practice as a programmer, class diagrams were the closest and dearest to me. And of course this is the first thing I tried to catch on. At the same time I tried to write Use cases for Coburn [3], it is very “sweet” that he expresses his thoughts, and I want to try to cook something similar. The variants turned out to be cumbersome and abstruse, first you had to deal with the form of these Options, and only then with the content. Working with them was awkward. More successful, in my opinion, turned out to be the specifications of requirements created for the templates peeped in RUP.

As a result of adaptation, I realized that, having studied some basic methodologies and techniques from the field of requirements management, I vaguely imagine where to start, what sequence of steps to take, what should be the optimal amount of content at each design stage. The people to whom the fruits of my work were intended received only a collection of disparate project artifacts, the use of which could not be applied effectively. And although in theory everything was transparent and understandable, in my particular project, everything was somehow wrong. The theory of systems analysis was perceived by me as an art: elegant and slender diagrams, new and creative ideas, and practice required an end result for a specific project.

Moral: a set of ingredients, even the best, and a recipe book for preparing dishes from them, does not always allow producing a quality product. In addition to knowledge, we need practical skills, experience, creativity and intuition acquired as a result.

Analyst is extremely important practical experience of participation in projects. Only he will give the opportunity to convert the knowledge gained into the skills and abilities necessary for the development of quality requirements. Over time, the specialist acquires a kind of “agility” in identifying the needs of the customer, the ability to quickly and accurately define entities and phenomena that the customer is often not able to formulate even for himself. And yet, it develops a knack for determining the surroundings of the main objects and participants in the subject area, which in one way or another exert influence on it, but remain in the shadows for an innocent eye.

One more important aspect of training in requirements management is the preparation of an analyst in the field of Personal Management. The topic of personal effectiveness of a specialist is practically not disclosed in works devoted to work with requirements. And the lack of skills of this kind greatly complicates the successful self-realization of the analyst as a professional. Project functions in different teams are not always strictly regulated, and more often blurred between project roles. Therefore, the broader the analyst’s skills in related disciplines of a project, the more chances he has to be successful in practice.

All these reflections made me sit down to write such a book, which I would like to read at the beginning of my career as a systems analyst.

The main objectives of this book are:

• Show with examples, possible variants of “technological lines” of the process of designing software products.
• Determine and structure the techniques and techniques for each stage of the development of requirements. Choose options for the use of these techniques in relation to various areas of solutions.
• Describe the managerial techniques that allow the analyst to communicate with stakeholders and effectively promote the results of their work in the project.
• Identify the key points in the process of developing the Requirements for creating software that should be emphasized.

So let's go ...

II Introduction

A large amount of requirements management literature is currently available. Most of the works can be divided into four groups:

1. Providing theoretical information describing one or another fundamental “heavy” methodology, for example: RUP or SADT. These methodologies are extremely effective and useful for large projects. But their use requires a long process of training, including training or practice in companies in which they have already been successfully applied. A classic work for analysts from this group can be considered [1], [2].
2. Presentation of the academic point of view on the processes from the area of ​​requirements management. Personally, the books [4], [5] helped me a lot.
3. Excursion to various technologies in the form of comparative reviews. In my opinion, the book [6] is the most successful work for analysts from this group, although it can also be attributed to a group of academic works. On the choice of methods for use in various projects, compactly and intelligibly described in article [9].
4. Practical ideas presented in the form of “light” methodologies, most often designed for small projects, for example: ICONIX, the Extreme Programming Process (eHtreme Programming) [7], [10], etc. Such methodologies can relatively quickly begin to be effectively used in small teams.

This publication does not pretend to either an academic work or a design methodology. Most likely, it can be positioned as a seminar that teaches some variants of the development and management of functional requirements. In my work, I will present various techniques and methodologies tested in practice.

The publication is presented in the form of narration. It does not provide definitions and explanations of the principles and fundamentals of the requirements development process, but uses references to publications where the relevant topic is fully disclosed. To understand the material presented, the reader must have an idea of ​​the System Analysis discipline.

All sections of the publication are equipped with pictures that simulate images of certain events, processes, entities (or more precisely the most important aspects for us) occurring in the real world. When disclosing material from section to section, the models are supplemented and detailed, showing the dynamics of the design process.

Also, throughout the presentation, we will, together with you, consider a very real project: “Automation of the requirements management process”.

III Preparing the landscape for the team

"Any landscape is an ideal body for expressing a certain system of thought."
Novalis

Developing requirements and documenting a project for complex products is a long process, and it is also very laborious and requires a well-coordinated work of the team. Therefore, from the very beginning it is necessary to think over and prepare the landscape (habitat) in which this process will proceed. In my opinion, providing a comfortable environment for working with project artifacts, as well as for communication between participants is one of the key aspects of its (project) successful completion.

The purpose of this work group is to prepare the conditions for high-quality and effective interaction of the project team as part of the development and implementation of the requirements for the target product.

An enterprise automation project is most often associated with multiple changes in the organization itself. Experts in the field of change management advise to go through the stages of "motivation" and "training" of employees before starting work, because change management, first of all, is the management of relationships and emotional states of people. Therefore, for the successful promotion of the project, motivation is needed not only for the development team, but also for participants representing the customer. Do not neglect this, as it is one of the most important success factors, both for the development of quality requirements and for the project as a whole.

It is worth paying special attention to the need, when working with customers, to create a constant emotional motivation for its employees, which will prompt them to show interest in everything that happens in the project. Better yet, make them compete with each other in the utility for the project. There are many methods and techniques for this, including presentations, discussions, trainings, etc.

Virtually any IT project begins with collecting information about business processes to be automated, the environment for their operation, etc. The purpose of this process is that all interested parties agree on a common interpretation of the final result of the project. Since the project participants have different levels of training in the field of working with information, the materials should be presented in a variety of (but pre-defined) forms that can be understood by different groups. In other words, with varying degrees of detail, levels of abstraction, the use of notations and other characteristics. Therefore, we will immediately divide the content of the project into at least two domains:

1. The information of the original vision from the point of view of consumers of a future product, called the “problem domain”. Based on knowledge of the real world in which there is a problem
2. Implementation information - a developer’s perspective, called the “solution area”. Based on domain knowledge of the technology in which the solution can be implemented.

Requirements, although in different proportions, are collected during the entire project and, accordingly, all this time affect the course of its implementation and the final result. In order for the final product to satisfy the needs of the customer as much as possible, and they, as we found out, can change in the process of their implementation, it is necessary to maintain a close and productive dialogue with the consumer of the final product throughout the project. To this thesis, we will constantly return to the process of presentation of the material, because it is the key. Based on the foregoing, it is very important that both domains of the project: “problem domain” and “solution domain” change simultaneously and depend on each other.

Therefore, from the very beginning in the project, it is not bad to have a “dispute platform” with information that is accessible for all participants to understand. The site should act as a “showcase” of the project and can be both virtual (for example: WEB portal) and real (for example: a room with a stand), which places key information about the content, current status and the nearest plans of the project.

The constant mutual communication of representatives of each of the points of view helps to effectively deal with the problems of incorrect assumptions by the parties:

• The problem described by the customer may not be the one in whose solution he has a real need.
• The solution described by the developers may differ from what they actually create.

Figure 3.1 shows the model of the interaction of the project team in the process of formation and use of project content (“problem area” and “solution area”).


Figure 3.1 - Project Team Interaction Process Model

At the stage of preparing the landscape of the project, begin to form lists of stakeholders. It is important not to miss anyone, from those who somehow relate to the process and (or) the result of creating a new product. Stakeholders of the project can be not only future users of the system and the project team, but also various customer officials, investors, ergonomics experts, officials of standardizing and regulatory bodies, etc. This list can be updated and refined throughout the entire project, as the requirements are formed and refined.

It is convenient to arrange the list in the form of tables in which, in addition to the name of the interested person, it is necessary to clarify his goals, to classify his competence and role in the project.
Below is an example of using tables to create a list of project stakeholders:



Another expedient step for the formation of the project landscape is the publication on its “showcase” - vocabulary (glossary), which will serve your team as an instrument for achieving consensus on the interpretation of objects and phenomena in the subject area. This will allow customers and developers to communicate in disputes in the same language. Experience shows that the use of the glossary saves a lot of time and, most importantly, nerves, as often customers and performers spend them on “everyone about his own”, arising only because of the difference in the understanding of the same term. For example, the word “Landscape” used in the title may be interpreted, depending on the application, in very different ways. But in the context of our project we will add the following definition to the Glossary:



The glossary can be replenished during the entire life cycle of a project, therefore we, in the course of the development of our project in a publication, will define terms that may cause different interpretations.

As can be seen from this chapter, it places special emphasis on the active interaction of the analyst with all project stakeholders, and more specifically, on their ongoing emotional involvement in the development of requirements.

Chinese proverb: “Tell me - and I will forget. Show me - and I will remember. Engage me - and I will learn. ”

Constantly remind yourself that the analyst creates the requirements “not for the sake of art”, but as an intermediate product used in the software development chain. Attract as many stakeholders as possible to its formation. Give the team a sense of belonging to this product. Even knowing the answers, ask questions.

Ask questions so that they can give you the answer you need, while people will take this decision as their own. As can be seen from Figure 3.1 on one side of the requirements we have

The customer, according to another team implementing the target product. Therefore, when I speak about the involvement of interested persons, I mean not only the Customer, but also architects, project managers, Timlids, because your work is intended for them as a result.

Consult with them, learn from them, be “theirs” for them. These are not just appeals, then I will share with you my observations on how this can really be done.

In the next part, we will formulate the objectives of the project, identify the participants and stakeholders, their benefits and needs and proceed to identify the common needs of the customer reference .