The practice of forming requirements for IT projects from A to Z. Part 2. Objectives and Needs

IV DETERMINING THE GOALS OF THE PROJECT

The goal does not have to be achieved. Sometimes it's just the direction to move on.

Bruce Lee.

One of the main features of a system that distinguishes it from disparate components is the subordination of the entire organization of the system — some goal. The project work of the team is also a kind of system and, accordingly, should be “led by” some goal. Therefore, having established communications between the project participants, we will begin to define the goals that we want to achieve as a result of the creation of a new product.



The purpose of this work group is to identify the main tasks that the groups of stakeholders involved in the project set for themselves.



Now, in the literature there is a whole bunch of methods for determining and formulating goals. There is even such a direction - goal-setting, teaching the rules of setting goals.

')

The quotation given at the beginning of this section, in my opinion, shows the role of goals in a software development project as well as possible. From my practice, the goals formulated at the project initiation stage are extremely rarely returned. The formulation of goals in this context is rather a declarative step of proclaiming slogans, raising the team spirit and giving the team a start to jointly discuss their immediate future. In order to prevent a critical assessment of their statements by experts on goal setting, I’ll just make a reservation that in the future we will form requirements detailing our goals. These requirements will be consistent with all the principles of SMART technology. SMART is a method for evaluating the effectiveness of goal setting on five criteria (concreteness, measurability, attainability, result orientation, time constraints).



From the point of view of the project manager, properly formulated goals should allow:

1. Identify the product that the team must produce during the project, and the benefits that the customer must receive as a result of its completion;
2. Determine the criteria for the success of the project as a whole, in terms of the main stakeholders, including not only the customer, but also the project team.

Therefore, the goal of the analyst at this stage is to provide the team and the customer with exactly this information.



Defining goals, it is important to consider two important points:

1. The customer is most often unable to formulate goals independently;
2. The goals in the project for different representatives of the customer, contractors and performers are different, and sometimes contradictory.

Therefore, firstly: you must help the customer representatives to formulate the goals they want to achieve as a result of the implementation of the target product. Secondly: when formulating customer goals, you must consider your own strategic development goals that you want to achieve as a result of the work. For example, this may be an attempt to lay in the functionality of the developed system - characteristics that are not essential for the customer, but are of interest for you to bring to the market, the developed target product.



Once again, I’ll draw your special attention to the fact that when formulating the project goals, you should try to put in your own (implementation teams) strategic interests that you want to achieve as a result of your activities in the project.



But in determining the goals of the customer, together with his representatives, the analyst must first of all use the concept of benefits that the owner will receive from using each considered function of the target system. Therefore, when the customer asks you to realize some kind of opportunity, teach him to immediately think about what profit he will get from this. So you can, at the initial stage, remove some of the excessive requirements and save time at the stage of determining the boundaries of the project, but more on that later.



Figure 4.1 shows the process of forming the goals of creating an information system.







Figure 4.1 - model of the formation of goals



Rejecting the general goals of the requirements development process, we will try to identify the main tasks that the “Requirements Management” training system we are designed to meet to meet the customer’s needs. Since in the training project I perform the function of analyst and imitate the activity of the customer, I will give “our joint” reflections on the formulation of each goal.



First of all, you should refer to the available sources that describe the problems and solutions of the automated domain. According to SWEBOK (Software Engineering Body of Knowledge), the Requirement Process requirements analysis consists of the following main components:

• Requirements Elicitation,
• Requirements Analysis (Analysis of requirements in the narrow sense),
• Requirements Specification,
• Requirements Validation.

So we need to cover this entire workflow. And it is desirable to carry them out, as we found out in the previous chapter, adhering to a single style, using a single “habitat” for all processes and participants in a project.



So, the first process that we will perform when developing requirements is the collection of information about the tasks, goals and problems of the customer, which he is going to solve with the help of the created (target) product. Based on these wishes, some customer needs (user requirements) will be formulated, suitable for further work on their implementation.



Add the term to the glossary:







We must fix this information and necessarily provide for discussion to all interested persons of the project, with the possibility of their addition and modification. Where does the first goal of our system come from:



1. To fix the list of user needs that they wish to satisfy with the help of the target product.



Based on the customer-approved requirements for automation (domain of problems), we will form specifications of requirements for the product being developed (solution domain) using well-known techniques, which will be described below. Since most of the software development process is built around the requirements specifications, the following is the goal of our system:



2. To fix the list of functional and system requirements for the product being developed. Add a small clarification: including fixing the coverage of the wishes of users (problem area) with system requirements (solution area).



We agree on the term requirements in the Glossary:







Requirement specifications will become in our system a framework linking all parts of the project from the customer’s needs (since they are clearly related to the specifications) to the implemented functions in the target product. For this, on the basis of specifications, we will expose tasks to the performers for design, development, testing, deployment, pilot implementation, etc. Developers in the code will indicate a link to the task. According to the task, you can find out the requirements, etc. in the reverse direction to the needs of the user. Based on the above postulates, we formulate the following goal:



3. Based on the specification of requirements, assign tasks to performers aimed at their implementation in the final product.



Since the fact of the assignment, in fact, performs the promotion of the product functionality to the planned characteristics, we need to record in the system all actions taken by the executors, according to the tasks. Thus, we will be able in the context of time and each individual requirement to track the increment in the functionality of the target product. Therefore, the following goal can be formulated as follows:



4. Record the fact of the assignments by the performers.



Practically in each project, in the course of its implementation, there are changes and clarification of requirements. This is a separate section in the discipline "Requirements Analysis" and we cannot fail to mention this process in our project, and therefore another goal:



5. Manage requirements changes.



Now, when we have dealt with the main goals, we will proceed to formulating the needs of the customer, which will satisfy their goals.

V WE CONSIDER THE CUSTOMER'S NEEDS

Of all the possible ways to improve the software development process, the greatest advantage lies in the formulation of requirements.

Karl wigs

The discipline "System Analysis", to deal with complexity, proposes to use such basic techniques as abstraction and decomposition, which make it possible to lay out the requirements by presentation levels. Following these principles, at the heart of the pyramid of analysis are the Goals, for example, described in the previous section. Rising up, we lay them out into smaller elements, collecting the wishes of the customer to the functionality of the product being developed.



The purpose of this group of works: to collect the most complete and accurate information about the needs of the customer, which they want to satisfy with the help of the target product.



When collecting customer needs, you need to remember: if potential users of the system state to you some wishes that we cannot associate with any of the goals, then you should check with the customer whether it is necessary to automate this need, or reconsider the goals.



Another important caveat: do not try to describe the needs of users in terms of a software product; this is a bad practice. Avoid such expressions as “menu selection”, “pushing a button”, “entering a field”, etc., and use for example: “choice of option”, “process execution”, “determination of value”, etc. .







Figure 5.1 - model of the process of formalization of customer needs



In the future, we will expand and detail this model (see Fig. 5.1), moving from section to section in the process of forming specific requirements.

1. WE TAKE USER STORIES TO DETERMINE THE CUSTOMER'S NEEDS

In my opinion, from the very beginning of the project, it is very convenient to use the method of describing “User stories”. This technique is well described in the flexible programming techniques of Scrum, KANBAN [10]. Its essence lies in the fact that the team, together with the owners of the processes, makes up small, in one or two sentences, business process scenarios to be automated. For each User story (eng. User Story) is determined by the goal that should be achieved as a result of its implementation. If the goal is difficult to formulate, you should think about the appropriateness of using this scenario in the overall process.



It is important to realize that the formation of User stories implies the direct involvement of future consumers of the product being developed in the process of its creation, making them co-authors (or accomplices in the event of failure). And this fact must be used, by reporting to the customer, the need to share responsibility for the quality of the product being created.



User stories are conveniently written on stickers pasted on the board, to which the entire project team has constant access. This site is usually used for holding rallies - joint discussion of the stages of the implementation of the automation process of the announced business scenarios. Making your user stories on a sticker ensures that it doesn’t get too big.



During the passage of the User’s life cycle history: formation, discussion, implementation, testing, etc., stickers with their descriptions are pasted onto different “tracks” corresponding to the development stage. Thus, in small projects, using the described technique, they control not only the content of the top-level project, but also the process of its implementation. I would recommend using this approach in large projects that use professional requirements management tools. This method is not only practical, but also of great psychological importance, affecting the team spirit of the project. An example of a User story is shown in Figure 5.1.







Fig. 5.1. User story



User stories can also be effectively used for acceptance testing.



Based on the goals identified above, we will begin to collect and publish user stories (Functional Requirements).



So, we need to develop a software product that will support the following business processes:



US01. Describe a user story on a sticker. Formulate the purpose of the process.

Objective: To record the business process to be automated in an accessible form for discussion.



“US01” —in this example, is a User History identifier, consisting of a prefix indicating the type of project artifact (User Story) and its sequence number. Add the term to the glossary:







As a rule, the style of presentation and the content of users of their wishes to the product being developed, to put it mildly, is not perfect. Even showing these wishes to other team members, we are confronted with their misunderstanding of the essence of the problem. Therefore, it is advisable to discuss each user story with interested participants and try to formulate it clearly and in monosyllables. Write it like this:



US02. Discuss a user story with project members. If necessary, make changes.

Objective: To familiarize the project team with the business process scenario. Reconcile it.



For further use of the User History, we need to fix it in the system. For example, by associating a User Story with the relevant requirements, we will be able to trace its implementation in the final product through the chain: User History → Requirement created by it → Tasks set up on demand, etc. We formulate:



US03. Post to the system agreed user stories.

Purpose: To record in the system a list of approved Business requirements for their recording and processing.



Since User stories are formulated by the author or a group of authors and represent their view on the problems that are within their area of ​​interest, we need to capture these “stakeholders” in our system. For the development of any project it is very important to determine the circle of people one way or another interested in obtaining the target product. Based on this data, we will coordinate requirements, define user roles, etc.



US04. Based on user stories, identify key project stakeholders.

Objective: Record the list of project participants and stakeholders in the system.



A user story does not give us a reason to immediately start writing the program code, since this is just a certain view of the processes, in fact - a declaration or outline. First, they will need clarification, specification, development of algorithms that clearly regulate the execution of processes, modeling the structure of objects of the domain, etc. Therefore, having finished the process of fixing the main User stories, we proceed to the modeling of the processes and objects that implement them. Along the way, we define their connections and information flows. We formulate it like this:



US05. Based on User stories, determine the main functional requirements for the system being developed.

Objective: To record in the system a list of business processes to be automated.



After determining the full functionality of the product being developed, it often comes to the realization that it is not realistic to realize this entire list in a timely manner, with available resources. And then, it is necessary to divide the functions into: vital for maintaining the process and the functions that are needed, but for now you can do without them. Squeezing these reflections in one sentence, we fix:



US06. Based on the prepared list of automated processes, determine their priority and priority.

Objective: To determine the current project boundaries.



When all the processes, classes, storages and other objects of the developed requirements are designed, it is necessary to “string” all this information onto a single rod connecting the elements: in notations, document descriptions, and other artifacts. This core is usually the specification of requirements. They are recorded in the form of structured data, have a unique identifier, to which all the above artifacts refer. We write down the following User story:



US07. Based on the processes identified for automation, formulate specifications requirements for their implementation in the product. Register requirements in the system, correlate with User stories.

Objective: Register in the system: content, conceptual content of the project content, formulating the essence of automated services that provide the basis for product development, testing and transfer to operation.



When we develop specifications, we get a complete list of low-level system requirements with a detailed description of their implementation. Based on this list, we will be able to submit tasks or chains of tasks for contractors for design, development, testing, deployment, pilot implementation, etc. When setting the task on demand, its status in the system can automatically change. Thus, in the list of specifications, we will be able to see which requirements have already been taken into work, and which are still waiting in the queue. And since the specifications are associated with User stories, we will be able to track their status along the chain.



US08 Based on the requirements specification, create tasks for executors. During the execution of tasks change the status of the requirements.

Objective: Based on the requirement, to ensure the implementation of the project in the target product.



The task set for the performer is made available to him in the system. Since the task is set on demand, the performer can get acquainted with its specification, as well as the specifications of all related requirements.



After completing the work, the contractor fixes a report on the implementation, “closing” his tasks. Closing a task chain on demand automatically initiates a change in its state.



US09. To fix the fact of the assignment by the performer. Change the status of the request.

Purpose: Based on the fact that the task has been completed by the executor, to ensure the updating of the project implementation process.



Often, after the development of the first prototypes of the target product, users who have become familiar with its work attend an “epiphany”. They are beginning to clearly understand that they did not want “this” or not quite “this”. There is a need to make changes to the requirements. Despite its seeming simplicity, this is a very painstaking process, requiring changes across all project artifacts. Sometimes, it is necessary to make changes from the very beginning (fixing of the User’s history) and further along all the stages, forming the requirement.



US10. Make changes to the specification requirements for implementation in the product. Change the status of the request. Sync with user history as needed.

Objective: To change the content of the content providing the basis for product development, testing and transfer to operation.



Since the process of managing Requirements is associated with constant monitoring of the degree of their fulfillment, it is necessary to have a handy tool that allows you to select arrays of requirements for different sections of their properties, including current states.



US11. Provide a complete or limited list of requirements with the current state.

Objective: To obtain data on the current state of the development process of the target product of the project.



During the promotion of the project, we can: add new User stories; lay out the approved stories, detailing them in the group directly involved in its implementation.

2. WE USE A VISUALIZATION OF REQUIREMENTS TO DISCUSS THEM WITH THE CUSTOMER

Another effective method of the System Analysis discipline is modeling. Eric Evans in the book [13] positions the model as: “the language spoken by all members of the development team, and can also ... communicate with subject matter experts without a translator”. Therefore, the better we select a set of models for interaction with the customer and members of the project team, the closer and more productive our cooperation will be and, accordingly, the more fully and efficiently we will be able to meet their needs.



For clarity, you can display user stories in the form of models that represent a set of related functions - scenarios on business communication diagrams. Unlike canonical diagrams, here you can display objects of different types in a relatively free form, thereby adding clarity.



We will define the model, since this is one of the key design elements:







An example of a user story generation model is shown in Figure 5.2.







Fig. 5.2. The scenario of the formation of user history



In the figure we clearly see the processes, their sequence and place of execution, as well as resources.



Using such drawings, it is easier for customers to represent the subject area and discuss requirements for the product being developed. But, transmitting to the interested persons charts of this type, should be accompanied by an oral, and better written, description. For example, for the presentation above the chart, you can use the following text:



In the central part of the figure, the business scenario “Forming a User Story” is depicted. The script consists of four processes mapped in the sequence in which they should be executed. In the lower part, the performers of the processes are depicted, the dotted line indicates their impact, and the inscription defines the role. The upper part of the diagram shows the locations of the processes, and the lines indicate the data flows that pass through them.

3. SUMMARIZE THE PROCESS OF DETERMINING THE NEEDS OF THE CUSTOMER

User stories, on the one hand, are an excellent mechanism for identifying user requirements, and on the other hand, they can be positioned as the main tool for customer influence on software development. Speaking User stories with project stakeholders in disputes encourages people to “play” many times in their minds different scenarios of their work, and not only those that are currently used, but also those that they would like to embody in the future.



In flexible design methodologies - User history is used as a quick way to document customer requirements, without the need to develop extensive formalized documents and subsequently spend resources on maintaining them. But such an approach can be successfully used only for small or uncomplicated projects that are not related to the “twisted” business processes that are not planned to be developed and supported.



I propose to use User stories as the first step in the process of collecting and formalizing customer needs to obtain a complete list of business tasks that can be automated by creating a software product. Further, these needs should be detailed and transformed into functions of the target system.



In the next part we will identify the functions of the system and define the boundaries of the project link