System approach to requirements management

Epigraph: A camel is a horse made according to all customer requirements.

If you have ever participated in Internet projects - of any complexity and in any role - you probably know that defining the goals and boundaries of a future system is the foundation for solving any project problem. Collecting, analyzing and managing requirements is the part of the project in which the team’s experience and methodology play a decisive role: the cost of error in this area is very high.
')
There are experienced and well-coordinated teams in Russia, but there is still no uniform, transparent and easy-to-use methodology for managing requirements. Even in one organization, from project to project, the tools and methods of managing requirements, the role of participants in the process change, and, as a result, our organizations lack “maturity” - a guarantee of repeatability of project procedures with consistently high quality of output results.


Before any organizer of a “workshop” or project office in an Internet company, there is a temptation to use fairly clear and well-developed requirements management methodologies borrowed from software engineering. However, in practice there are frequent situations when these methodologies turn out to be excessively complex and do not take into account the specific features of Internet projects. Indeed, besides very similar to the development of software assembly and implementation in Internet projects, there is also design, and design, and analytics. Of course, in one form or another, all this is also present in the construction of software systems, but still there are many nuances: one thing is to build a clear and definite system for the operator, and quite another is to create a site for an arbitrary set of completely heterogeneous users.

In addition, not all development studios have system analysis expertise required to use software engineering tools (for example, IBM Rational family), and, as a rule, for customer representatives, these tools are simply incomprehensible, so there’s no effective joint work (for example, SCRUM) with this approach can not be speech.

In fact, the majority of custom-made Internet projects are done “in the old manner” - with writing a fast-aging TK, its lengthy and painful coordination, fantastically sophisticated ways of making changes to the team during the late stages of implementation, and, as a result, with poorly predictable results and complete lack of risk management.

Since the need for a convenient and relatively universal methodology for managing requirements for Internet systems was long overdue, three strategically important tasks need to be addressed at the current time:

1. Develop and practice a convenient, transparent and easy-to-use requirements management methodology;
2. To teach customers and contractors to work on this methodology, explaining how an approach with conscious requirements management is attractive for business;
3. With a successful solution of tasks 1 and 2 - to fix the methodology as an industry standard.

In the company ADV / web engineering co. For several years, practical research has been carried out on various tools and methods for managing requirements, and by now we have a clear understanding of how to most effectively manage requirements in the custom development of Internet systems.

The methodology is based on a systematic approach that considers the entire description of future functionality as a single system of concepts, divided into two large clusters: a cluster of business requirements and a cluster of functionality. At the same time, the overall goals, objectives and mission of the project, described in universal terms understood by both marketers and engineers, are at the foundation of the entire requirements management system.

Deeper levels of detail, while remaining in a single system, do not mix with each other by language and description formats, which allows business users to focus on business goals and semantic limitations of the system, and designers and developers - on how to achieve these goals with the stated limitations. With this approach, the role of the system analyst is very important, whose expertise helps to connect the two clusters among themselves without disturbing the integrity of the system.

A more detailed description of the methodology will be discussed in the next articles of the cycle, as well as at the master class “ Requirements Management ”, which beeos will conduct at the RIC on July 28-29.

Task 1) seems to us to be solved, and we proceed to the solution of task 2) - to bring the methodology to the public and gradually “fine-tune” it as a more universal tool at the industry level.