From problem to requirement. Decision making theory in software development

Introduction

Some time ago, I turned my attention to the artifact Product Product Concept of the RUP (Rational Unified Process) software development methodology and found that the starting point for developing a software product is identifying the problem that the product addresses.

A similar approach exists in domestic practice - so in GOST 34.601-90 it says that at the stage of forming requirements for the automated system (automated system), “ identification of problems is possible, which can be solved by means of automation ”.

In this article I want to share with readers my conclusions regarding the nature of the problem, its importance and attitude to the development of a software product.

General characteristics of the decision-making process

Like any other product created as a result of human activity, software is a tool (tool) designed to solve a certain set of tasks. Where does the need to solve something arise? Let's turn to the theory ...
')
The study of the laws of people's choice of the most optimal solution of various kinds of problems involved in such a science as decision theory .

Where does the birthplace of the decision begin?

The root cause of any activity is that a decision-making theory calls a problem - a discrepancy in the ideas of a person between what they currently have (the actual state ) and what they would like to have or achieve in the future (the desired state ).

Since the theory of decision making focuses on management activities within the organization, we will not deviate from this paradigm, but we mean that this approach is applicable to any other activity.

A person who is not only aware of the problem or wants to change something, but is also ready to make a decision on how to solve it and take specific actions aimed at changing the actual state in the direction of the desired - called an interested person or decision maker (DM).

purpose

After understanding the problem, an understanding of the goal is born - the embodiment of the desired result, the achievement of which, in the opinion of the decision maker, will lead to the resolution of the prerequisites of the problem, i.e. will align the desired and actual state.

Task

Subjected to a more detailed analysis of the goal is divided into sub-goals. Sub-goals are consistent with the stages of the process of achieving the main goal - they correlate with time, place, performers and objects of application of efforts. Thus, the goal transforms into a set of tasks . The degree of achievement of the goal and, consequently, the degree of solution of the initial problem as a whole depends on whether the whole set of tasks will be solved and whether the solved problems will be achieved.

Operation and Solution

When the list of tasks is determined, the decision maker begins to form a focused activity of the organization to achieve the goal. The purposeful activity of the complex of activities carried out by the decision maker in order to achieve the intended goal is called an operation .

The plan of the operation is gradually being finalized by the decision maker until it is decided to conduct it, during the formalization of which it is transformed into a system of private goals and tasks for the heads of departments, development programs, plans, tasks and criteria for their implementation. After this, the process of practical implementation of the decision made and communicated to the executives begins.


Figure 1. Typical process of managing an organization

Evaluation of the effectiveness of management decisions

Until the very end, the decision-making operation and all the persons involved in the resolution of the problem remain in the dark about the success or failure of the operation. Only when the activity of the participants is completed, the decision maker will make it clear whether the premise (root cause) of the problem was chosen to decide whether the objective of the operation was correctly formulated, whether this objective was divided into tasks, at that time and whether those tasks were assigned to the performers. solve and so on

When the decision is executed, and the troubleshooting operation is completed, the decision maker evaluates the result achieved. In assessing the utility and effectiveness of the solution obtained, not only the fact of the end of the operation, but also the degree of elimination of the initial problem is taken into account.

As a result of the assessment, you can come to the following conclusions:

• the problem was completely eliminated and its resolution did not cause any visible negative consequences;
• the problem is partially eliminated, but also no negative consequences are observed;
• the problem was partially eliminated and some new difficulties arose in resolving it;
• the problem has not been eliminated, and the implementation of a solution to eliminate it has given rise to new, significant problems.

The nature of software requirements

What task is the solution

It is known that there may be many solution alternatives for a problem. For example, the easiest way to optimize production is to change the business process in an organization. However, this is sometimes not enough and requires a tool that would allow to solve new problems as efficiently as possible.

If, in the process of thinking about how to solve the problem, the decision maker will come to the conclusion that the automation of the organization’s activities will contribute to the achievement of this goal, then one of the operations he develops will be the introduction of an appropriate information (automated) system.

Imagine that the manager of a certain enterprise decided to optimize work with documents. If his goal is only to reduce the time needed to agree on documents, then for this purpose it is quite enough to switch to using documents in electronic form - to establish a word for everyone and teach how to use e-mail. If the manager aims to streamline and control the processes of coordination and execution of documents, then this will require a tool to support such activities - the information system.

This banal example shows that different kinds of solutions should be used to solve different problems. It would seem, obviously! Let's not rush to conclusions ...

What is the requirement?

In accordance with the definition, the term automated system means the totality of the organization’s personnel and a set of automation equipment that implements an information technology for performing actions aimed at achieving a specific goal (see GOST 34.003-90). That is, the software used must have a set of properties that allow staff to perform actions or solve tasks aimed at achieving the goal. These properties of the software product are called requirements .

Requirement - the property of the software necessary for the user to solve the problem in achieving the goal.

Requirement Levels

If we consider the process of creating an automated information system from the point of view of management theory, then we can trace the analogy with the procedure for making management decisions described above.


Figure 2. The process of creating an automated system

Need

Similarly, the process of developing a management decision, analyzing the problem of decision-makers formulates the goal of automating the organization’s activities. To achieve the goal, the developed system must solve a certain set of technical or business problems. In the context of software development, these tasks are referred to as needs .

Function

In the framework of the implementation of actions to solve tasks aimed at achieving the stated goal, the organization’s personnel (users and other interested persons) have the right to expect a certain behavior from the software used. Behavior formulated in the user's language and describing the behavior of a software product within the framework of satisfying one or several needs is called a system function .

Software requirement

After determining the set of functions, they are detailed in specific and complete descriptions of the behavior of the program to be developed. Such descriptions constitute software requirements or software requirements (software requiremens).

Evaluating the effectiveness of a software solution

Having built a system that meets the identified software requirements, it can be argued that the system provides the required set of functions. In turn, since the functions are designed to meet one or more needs of the staff, these needs will be directly met by the received solution as a whole, and the use of the solution will allow to achieve the goal. And if the goal was chosen correctly, then it can be assumed that its achievement will solve the existing problem.

Often, when analyzing the results of the development and implementation of an automated system, the customer comes to the conclusion that the solution turned out to be ineffective or gave rise to new problems, and sometimes aggravated the existing situation.


Why is this so?

Who is to blame and what to do?

Very often in the process of collecting and analyzing the requirements are distorted or the source of these requirements (the problem of the interested person) is not detected at all.


Figure 3. Distortion requirements

Figure 3 shows an example of a process during which distortion occurs. When the decision maker realized the problem and formulated the goal of the activity to eliminate it, he communicates the list of tasks (T ₀ ) to the executors - the organization's personnel. Assume that these performers will use the software developed later, i.e. they will be its users. Each of them in his own way understands the task assigned to him and, in formulating requirements for a software product, proceeds from his assumptions (T ₁ ).

The analyst, based on interviews with potential users, formulated his own idea of ​​the tasks to be solved (T ₂ ), which he communicated to the project manager and together with him developed a solution embodied in the tasks for the developer (T ₃ ).

In the best case, as a result of the process described, a product satisfying the personnel’s requirements will be obtained; at worst, only the requirements of the analyst or project manager. This result is a consequence of the lack of understanding in the project group of the real needs of future users and stakeholders, whose work will be affected by the developed software solution.

In severe cases, the resulting product has nothing to do with customer expectations and reflects the developer’s own ideas about how users should work.

If at the initial stage of the project to identify the problem and all of the identified user requirements, as well as the proposed solutions, correlate with it (see Figure 4), we can expect that the resulting product will best meet both the needs of users and the expectations of interested parties.


Figure 4. Correlation of requirements with problem

Moreover, the understanding of the problem being solved will make it possible to manage the scale of the project qualitatively - for example, first of all, implement the functionality that solves 80% of the problem.

How to achieve this?

Problem definition

Since during the previous presentation we came to the conclusion that before developing a software product you need to decide on the problem that it has to solve, then it’s time to figure out how to fix this problem.

Many sources suggest using the form below to formulate a problem statement that needs to be resolved. The form takes into account the objectives that are expected to achieve a future solution.

Element	Description
Problem	[description of the problem]
affects	[list of parties affected by this problem]
the result of which is	[description of the impact of this problem on stakeholders and / or business activities]
Winnings from	[description of the proposed solution]
May consist of the following:	[list of main advantages provided by the decision]

The formulation and agreement on an equal understanding by all participants of a project of a problem being solved is one of the first and important steps of any program project. It is worth noting that the definition of the problem being solved can be made both for the entire project as a whole, and when new functionality is added to an existing software product.

Conclusion

If someone seemed obvious (or even trivial) the provisions outlined in this article, I’ll give statistical data that show that the problem of unsuccessful software projects is still relevant and the requirements are the main reason.

Currently, only 39% of all software projects can be considered successful in the full sense of the word. 18% of projects fail completely, and in the course of the implementation of the remaining 43% there are problems related to overspending the budget or the implementation of the wrong functionality.

In a study by Standish Group International, whose results are reflected in The CHAOS Chronicles 2013 , the key success factors for a software project are:

• Involvement of stakeholders in the project (Executive management support) - 20%;
• user involvement (15%);
• project scope management (Optimazation) - 15%.

Only after them follow such factors as the qualifications of developers, experience in project management, the use of flexible methodologists, etc.

***

All of the above confirms the axiom that software products are created for users. Orientation to the problems of stakeholders and the needs of the real (end) user is the key to the success of a software development project. Already at the initial stage of the project, the user should be involved in the work, as a result of this - the definition of the problem (problem statement) and the concept of the product (product vision) should show that the project team is clearly aware of the problem being solved, understands the needs of users and is ready to meet them.