The practice of creating requirements in IT projects from A to Z. Part 1. Introductory

  • Tutorial

Prologue


When reading articles on project management on this site, the pain of managers tearing out, often caused by the inefficient use of resources in the project, is often felt. And one of the main causes of these problems is most often called precisely the lack of quality tasks for product development. This misfortune 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 their head, while they are presented in completely different ways, etc. Reading about this in his mind vividly flashed pictures from his own practice. And now you are already stressed and trying to quickly switch from symptoms to recipes for getting rid of this headache. And what can we most often see? And then, as a rule, go optimistic and decisive, slogans - prepare the tasks for the executors correctly, do not hope that they will quickly figure out everything themselves, guess everything or they will suddenly get an 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 “On the quality of requirements in IT projects, frankly (from the position of a development team)” , I tried to more specifically approach these problems and told me how I can convert the collected requirements for automation in an IT project so as to maximize team performance that translates them into the target product. To increase precisely due to the qualitatively formulated tasks for the development of a product that covers the entire process.

Now I want to tell how to formulate the requirements themselves in a quality manner, leading the Customer from his “Wishlist”, to his happy and fruitful cohabitation with the software product, his dreams.

I Introduction


... in order to understand which of the methods of formulating requirements is most suitable for you, you should be guided by common sense and rely on your own experience.
Karl Wigers

For whom and for what is this publication intended:

At the dawn of my career, I worked as a programmer, led a development team, coded, coded and coded. But after 18 years, I decided to change the type of my activity, plunging into the sphere of system analysis and project management. Since it so happened that the enterprises I was lucky to work for did not provide for positions: analyst, project manager, product manager, and other specialties exotic at that time for me, the programmers themselves had to deal with the project activities of these specializations in one way or another. Naturally, these same activities were not carried out quite professionally; everything lacked either time or fundamental knowledge. To fill these gaps, I conscientiously sat down to study courses on the development of functional requirements, RUP, SADT methodologies, UML, etc. And after a while, I was lucky enough to get a job in one of the leading software companies for positions with a pathos title: "Leading Customer Relations Specialist." The employer, knowing that I do not have experience as a professional analyst, but only: desire, a wealth of theoretical knowledge and extensive practical experience of the developer, gave me two books [1], [3] and “ordered” in a couple of months to be ready to write high-quality specification requirements for software development. From my practice as a programmer, closer and dearest to me were class diagrams. And naturally this is the first thing I tried to catch on to. At the same time I tried to write Use cases according to Coburn [3], it is very “sweet” that he expresses his thoughts, and I want to try to cook something like that. The options were cumbersome and abstruse, first it was necessary to understand the form of these Options, and only then with the content. It was inconvenient to work with them. More successful, in my opinion, were the requirements specifications created according to the patterns observed 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. People who were destined for the fruits of my work received only a set of disparate project artifacts, the use of which could not be applied effectively. And although in theory everything was transparent and clear, in my specific project, everything was somehow wrong. The system analysis theory was perceived by me as art: graceful 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 ones, and a recipe book for preparing dishes from them, do not always allow you to produce a quality product. In addition to knowledge, practical skills, experience, a creative approach and the resulting intuition are needed.

The practical experience of participating in projects is extremely important for the analyst. Only he will make it possible to transform the knowledge gained into the skills necessary for the development of quality requirements. Over time, the specialist acquires a certain “agility” in identifying the needs of the customer, the ability to quickly and accurately define entities and phenomena that the customer is often unable to formulate even for himself. And also, dexterity is developed in determining the environment of the main objects and participants of the subject area, one way or another exerting influence on it, but remaining in the shade for an inexperienced look.

Another important aspect of requirements management training is the training of an analyst in the field of Personal Management. The topic of the personal effectiveness of a specialist is practically not disclosed in works devoted to working 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, but are often blurred between project roles. Therefore, the wider the skills of the analyst in related disciplines of the project, the more chances he has of being successful in practice.

All these thoughts made me sit down to write such a book as I would like to read at the beginning of my work as a system analyst.

The main goals of this book are:

  • Show on examples the possible variants of “technological lines” of the software product design process.
  • Define and structure techniques and methods for each stage of requirements development. Choose options for using these techniques for different areas of decision.
  • Describe management techniques that allow the analyst to communicate with stakeholders and effectively promote the results of his work in the project.
  • Identify key points in the software requirements development process that you should focus on.

So let's go ...

II Introduction


A large body of literature on requirements management 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 learning process, including training or practice in companies in which they are already successfully applied. A classic work for analysts from this group can be considered [1], [2].
  2. A statement of the academic point of view on processes from the field of requirements management. Personally, books [4], [5] helped me a lot.
  3. An excursion into various technologies in the form of comparative reviews. In my opinion, the book [6], the most successful work for analysts from this group, although it can be attributed to the group of academic works. About the choice of methods for use in various projects, compactly and intelligibly described in the article [9].
  4. Practical ideas presented in the form of “easy” methodologies, most often intended for small projects, for example: ICONIX, the process of Extreme Programming (eXtreme Programming) [7], [10], etc. Such methodologies can be relatively quickly started to be effectively used in small teams.

This publication does not claim to be an academic work or a design methodology. Most likely, it can be positioned as a seminar that teaches some options for the process of developing and managing functional requirements. In my work I present various techniques and methodologies that have been tested in practice.

The publication is presented in the form of a narrative. It does not provide definitions and explanations of the principles and foundations 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 understanding of the discipline of system analysis.

All sections of the publication are equipped with pictures simulating the images of certain events, processes, entities (or rather their most important aspects for us) that occur in the real world. When disclosing material from section to section, 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 structure of thought.”
Novalis



Development of requirements and project documentation for complex products is a long process, besides it is very painstaking and requires well-coordinated team work. Therefore, from the very beginning it is necessary to think over and prepare the landscape (habitat) in which this process will occur. In my opinion, providing a comfortable environment for working with project artifacts, as well as for communicating among themselves, is one of the key aspects of its (project) successful completion.

The purpose of this group of works: 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. Specialists in the field of change management advise to go through the stages of “motivation” and “training” of employees before starting work, since change management, first of all, is the management of people's relationships and emotional states. Therefore, for successful project promotion, motivation is necessary not only for the development team, but also for participants representing the customer’s side. Do not neglect the sim, as this is one of the most important success factors, both for the development of quality requirements, and for the entire project.

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

Almost any IT project begins with the collection of information about business processes to be automated, their environment, etc. The goal of this process is for all stakeholders to agree on a common interpretation of the end result of the project. Since the project participants have a different level of training in the field of working with information, the materials should be presented in a variety of (but predefined) forms, accessible for understanding by different groups. In other words, with varying degrees of detail, level of abstraction, the use of notations and other characteristics. Therefore, we immediately divide the content of the project into at least two domains:

  1. The information of the initial vision from the point of view of consumers of the future product, called the "area of ​​problems". Based on knowledge of the real world in which the problem exists
  2. Information about the implementation - a view from the developers, called the "solution area". Based on knowledge of the technology domain in which the solution can be implemented.

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

Therefore, from the very beginning in the project, it’s nice to have a “debate platform” with information that is understandable to all participants. The site should act as a "showcase" of the project and can be either virtual (for example: a WEB portal) or real (for example: a room with a stand), placing key information about the content, current status and immediate 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 which he has a real need to solve.
  • The solution described by the developers may differ from what they actually create.

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


Figure 3.1 - model of the process of interaction of the project team

At the stage of preparing the landscape of the project, they begin to form lists of interested parties. It is important not to miss any of those who are somehow concerned with the process and (or) the result of creating a new product. Interested parties to the project can be not only future users of the system and the project team, but also various customer officials, investors, ergonomic experts, officials of standardizing and regulatory bodies, etc. This list can be updated and updated throughout the project, as the requirements are formed and specified.

Designing the list is convenient in the form of tables in which, in addition to the name of the interested person, it is necessary to clarify its goals, classify its competence and role in the project.
The following is an example of using tables to create a list of Project Stakeholders:



Another expedient step for shaping the landscape of the project is publishing on its “window” - a dictionary (glossary), which will serve your team as a tool for reaching consensus in the interpretation of objects and phenomena of the subject area. This will allow customers and developers to communicate on disputes in the “same language”. Experience has shown that using the glossary saves a ton of time, and most importantly, nerves, as customers and contractors often spend them on “each of their own” disputes that arise only because of a difference in understanding of the same term. For example, the word “Landscape” used in the title can be interpreted very differently depending on the application. But in the context of our project, we add the following definition to the Glossary:



The glossary can be updated throughout the entire life cycle of the project, therefore, as we develop our project in the publication, we will define terms that can cause a different interpretation.

As can be seen from this chapter, it places special emphasis on the active interaction of the analyst with all interested parties of the project, or rather, on their constant emotional involvement in the development of requirements.

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

Remind yourself constantly that the analyst creates the requirements “not for the sake of art,” but as an intermediate product used in the software development chain. Involve as many interested parties as possible in its formation. Give the team a sense of ownership in this product. Even knowing the answers, ask questions.

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

Customer, on the other, the team for the implementation of the target product. Therefore, when I talk about involving stakeholders, I mean not only the Customer, but also architects, project managers, Timlids, because it is your work that is intended for them in the end.

Consult with them, learn from them, be “their own” for them. These are not just calls, 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, determine the participants and stakeholders of their benefits and needs, and proceed to identify the common needs of the customer link .

About the author’s trainings on the topic: “The Practice of Forming Requirements in IT Projects” can be found on the website of the IC Tavrida LLC

List of references
1. Jacobson A., Butch G., Rambo J. - “Unified Software Development Process” (2004)
2. David A. Mark and Clement McGowan - “SADT Structural Analysis and Design Methodology”
3. Cobern - “Modern Methods for the Description of Functional requirements ”(2002)
4. Leffingwell Dean, Widrich Don -“ Principles of working with software requirements ”(2002)
5. Karl I. Wigers -“ Development of software requirements ”(2002)
6. Elizabeth Hall, Ken Jackson, Jeremy Dick - “Developing and Managing Requirements A Practical User Guide” (2005)
7. Scott Ambler - “Flexible Technologies: Extreme Programming and the Unified Development Process ”(2005)
8. Greenfield Jack, Kane Short -“ Software Development Factories ”(2007)
9. Alistair Cowburn - “Each project has its own methodology”
10. Wolfson Boris - “Flexible development methodologies”
11. Leszek A. - “Analysis of requirements and system design”
12. Freeman Eric, Freeman Elizabeth - “Design patterns” (2011)
13 Evans Eric - “Subject-Oriented Design” (2011)
14. GOST 34.602-89 “Information technology. Set of standards for automated systems. Terms of Reference for the creation of an automated system "

Also popular now: