Main problems when working with requirements
I wanted to title the article “mistakes when working with requirements,” but then I realized that the only mistake would be the solution don't work with requirements. If the decision to work with the requirements is made, then most likely the consequences will be not so much errorsHow many problems and difficulties. It is these problems that any organization or project team faces that I am going to write about.
Problem #1. Wrong people
From the point of view of working with requirements, the systems we develop can be divided into two large classes:
systems in which requirements “fall” from above. Requirements come from the customer, are accepted into the project along with the contract, and practically do not change during development. The products themselves usually do not contain exceptional novelty, and are similar to products that the organization has already developed previously. Projects of this kind include the development of components and systems of aircraft, spacecraft, cars, automated process control systems and the like.
systems for which requirements must be actively collected from various stakeholders. The requirements in this case are developed at the beginning of the project with fairly wide tolerances and contain only a high-level description of the system. More precise requirements are formed during development as a result of active interaction with a wide range of stakeholders. Basically, interested parties are users of the system being created. A typical representative of projects of this type are projects to create information systems and software. Although an organization may have solid experience in developing information systems, in this case it will not be possible to work “from the archive.” Each project contains a large percentage of novelty. Requirements in this case continue to come from interested parties not only during the entire development, but also after its completion, during trial operation and technical support.
Of course, this division into classes is arbitrary, and a number of other types of systems or projects can be listed, but from the point of view of working with requirements, they can one way or another be reduced to the two already mentioned types.
The development of systems, carried out on the basis of a solid foundation, many years of experience and a large number of already completed projects, often leads to the fact that the development of requirements (whether technical specifications or specifications) becomes a routine task that can be entrusted to any relatively free employee. A relatively free employee is the person who, due to lack of experience in general (just completed training) or lack of experience in this organization (recently hired), takes as an example an already existing set of requirements (TOR or specification), and rewrites it into new way At the same time he:
did not undergo special training (with mandatory practical training) on working with the requirements;
does not understand the subject area deeply enough;
poorly understands which stakeholders and how exactly he should interact;
poorly understands the requirements engineering methodology and its interaction with the processes of architectural design, verification and validation, and configuration management;
and may simply be incapable of this specific activity.
As a result, the task of analyzing and developing requirements is performed by an employee who often simply cannot perform it at a sufficiently high level of quality.
If we are talking about an information system, then at least two employees should be involved in developing the requirements:
the systems analyst, or requirements analyst, must turn user requirements into system requirements and put them into a specification. The required skills and training for this employee are approximately the same as in the previous section;
a business analyst must identify problems (pains), needs and wishes of the Customer, and turn them into user requirements. This specialist must have outstanding skills in communication, obtaining and verifying information, building relationships and resolving conflicts.
A business analyst is a person who is focused on communication, contact, receptive, has developed communication skills, knows how to ask open questions, has active listening skills, and has undergone appropriate education and training. At the same time, education and training are not enough if there is no personal inclination for activities of this kind.
Experience in implementing requirements engineering methodology and software tools for more than 15 years shows that organizations with well-trained business and systems analysts are extremely rare. The problem of lack of necessary competencies in an organization can be solved using the following approaches:
find and hire people with the necessary competencies. This is the task of the HR department;
train and develop the skills of those employees who are currently working in the organization, properly stimulating them to perform additional responsibilities;
Establish a well-documented requirements engineering process within the organization that transfers some of the knowledge needed to perform the related activities into documented procedures.
The company I work for can provide assistance in educating and training employees, as well as in developing a documented requirements engineering process. B3 Projects.
