📜 ⬆️ ⬇️

Management of requirements for IT projects

Good afternoon, dear habroskoobschestvo!

I have long been a reader of this wonderful resource and now, finally, I decided to try my hand. I noticed that the topic of project management at Habré is covered quite widely in the corresponding blog, but I couldn’t find anything about managing the requirements. Well, it's time to fill this gap!

image
')

Introduction


In the conditions of the modern economy, the one who produces more with less costs wins. Cost reduction is possible both with the use of cheaper raw materials and materials, cheap labor, process optimization, and their automation. Automation does not lead to a one hundred percent reduction in costs, but allows you to process more information with less cost.

The main tool for automation of activities are information systems. An information system is a set of information, mathematical, linguistic, technical software and other software, as well as personnel for the operational preparation of information for decision makers.



EISs are supplied in a boxed version, which offers standard solutions for automating tasks, and they allow you to create the necessary set of functions yourself in the design mode. In addition, many corporate systems developers offer customization services for packaged solutions to the needs of a particular enterprise — customization services.

Corporate systems are a product of intellectual labor, which allows them to be easily replicated and transmitted through communication channels without large material costs, in contrast to products of material production. Information products have a much greater ability to adapt to the desired specific production, in connection with which there is the task of obtaining initial information for the development or adaptation of an information system.

The development of a large and complex system cannot be completed in one approach - an iteration. This may be due to both the great complexity of the system itself and the complexity of its adaptation. However, it is possible to reduce the amount of work for developers by reusing code from one project to another. In order to identify the possibility of code reuse, it is necessary to find the requirements that this code implements. Such requirements are very often found in products that automate the same subject area in different organizations, for example, accounting or workflow. The task of reusing requirements is one of the tasks solved by management requirements.

Requirements management, requirements development and requirements definition are the cornerstones of the success of any IT project.

According to a study conducted by IBM in the field of IT, 60% of the time spent by software development organizations is as a result of an inefficient approach to managing requirements. In organizations that do not have sufficient business analysis capabilities, projects are three times more likely to fail than to succeed. With proper identification and management of requirements, project overspending can be reduced by 20% by reducing the number of inaccurate, incomplete, and missed requirements.

Requirements Management


Before you manage the requirements, we will understand what is a requirement and what is requirements management and why it is needed.

Requirements Management is a process that includes identifying, identifying, documenting, analyzing, tracking, prioritizing requirements, reaching agreement on requirements and then managing changes and notifying stakeholders. Requirements management is a continuous process throughout the product life cycle.

A requirement is any condition that a system or software being developed must meet. The requirement may be the possibility that the system should have and the limitation that the system should satisfy.

According to the IEEE Software Engineering Terms Glossary, which is a generally accepted international standard glossary, the requirement is:
  1. Conditions or opportunities the user needs to solve problems or achieve goals;
  2. The conditions or capabilities that a system or system components must have in order to fulfill a contract or meet standards, specifications or other formal documents;
  3. Documented presentation of the conditions or possibilities for paragraphs 1 and 2.

In accordance with the ISO / IEC 29148 design standard, a requirement is a statement that identifies the operational, functional parameters, characteristics, or limitations of a product or process design that is unambiguously, verifiable, and measurable. Required for acceptance of a product or process (customer or internal quality assurance guidelines)
The ITILv3 glossary also defines such a concept as a set of requirements - a document containing all the requirements for a product, as well as a new or modified IT service.

The requirement must have the following characteristics:
  1. Unity - a requirement describes one and only one thing.
  2. Completion - the requirement is fully defined in one place and all the necessary information is present.
  3. Consistency - the requirement does not contradict other requirements and fully complies with the documentation.
  4. Atomicity - the requirement can not be divided into smaller ones.
  5. Traceability is a requirement that fully or partially meets business needs as stated by stakeholders and documented.
  6. Relevance - the requirement has not become obsolete over time.
  7. Feasibility - the requirement can be implemented within the project.
  8. Ambiguity - the requirement is defined without resorting to technical jargon, acronyms and other hidden wording. It expresses objects and facts, not subjective opinions. One and only one interpretation of it is possible. The definition does not contain fuzzy phrases, the use of negative and compound statements is prohibited.
  9. Obligation - a requirement is a characteristic determined by an interested person, the absence of which leads to an inferiority of the decision that cannot be ignored. An optional requirement is a contradiction of the very concept of a requirement.
  10. Verifiability - the implementation of the requirement can be verified.

In accordance with ITILv3, all requirements in the project can be divided into the following groups:
  1. Functional (Functional) - implement the business function itself.
  2. Management (Manageability) - requirements for affordable and secure services; relate to system layout, administration, and security.
  3. Ergonomic (Usability) - to the convenience of the end users.
  4. Architectural (Architectural) - requirements for system architecture.
  5. Interfaces - to the relationships between existing applications and software and the new application.
  6. Service Level (Service Level) - describe the behavior of the service, the quality of its output data and other qualitative aspects measured by the customer.

Common requirements management software


Currently, requirements management systems such as IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner and Borland Caliber RM are widely used.

I will give brief translations of the main functionality of the above systems, taken from the manufacturers' sites.

IBM Rational Requisite Pro

Rational software provides best practices for identifying and managing requirements that save time and money by helping you accomplish the following tasks:

Rational RequisitePro helps project teams manage requirements, create high-quality use cases, expand tracking capabilities, improve collaboration, reduce the need for rework, and improve quality.

IBM Rational / Telelogic DOORS

IBM Rational / Telelogic DOORS is a family of solutions for managing requirements and creating complex high-tech products (aircraft, shipbuilding, trains, rockets, cars, etc.).

DOORS was originally developed only as a means of managing requirements in the software development process. However, the ideas embodied in DOORS were successful and at the moment the system is used even in campaigns that are not related to software development, but are forced to control a large amount of interrelated information, for example, when developing engineering systems.

The following information can be obtained from Telelogic DOORS:

Borland Caliber RM

Borland Caliber RM is a corporate requirements management system that facilitates collaboration, which allows development teams to approach project milestones on time and with planned costs. Borland Caliber RM also helps development teams ensure that the application being developed satisfies the wishes of the end users by continually gathering wishes at all stages of the life cycle from analysts, developers, testers and other project stakeholders.

Borland Caliber RM has the following features:

Other software


Behind the scenes were also well-known requirements management systems, such as:


New approach to requirements management


As can be understood from the above review of software for managing requirements, it is all based on one principle - a person, and in this case, the analyst, enters a requirement into the system, looks to see if there is already such a requirement in the system. If the requirement in one or another formulation is already present in the system, then it does not enter it anew, but marks it as a duplicate. Due to the fact that the search for similar requirements manually is a difficult and time-consuming task, which requires the constant participation of the analyst, it is in the first place to automate the requirements management process.

To realize the ability to search and reuse requirements, a methodology for identifying requirements presented in natural language text is necessary. Then, by presenting the requirement not only as text, but also a combination of some concepts or linguistic variables, it will be possible not only to search for similar requirements, but also to use artifacts re-created during the implementation of the requirement. In this case, artifacts should not be understood only as the source code that implements the requirement, but also the life cycle that it passed, i.e. the code can not always be reused because of the specifics of the tasks, but you can get advice from its developers. When developing several products for one subject area, this becomes an urgent task. For example, when an electronic document management system is adapted at several enterprises, a situation often arises that different enterprises pass through the same routes during the life cycle and the functionality that implements these routines can be reused, even without full copying.

Suppose that the following requirements describe the document routes in enterprises A and B, respectively:
A - {A, B, C, D, E}
B - {F, B, C, D, E}

Here you can see that F and A are documents, and B, C, D, E are their routes.

By calculating the Hamming distance between these two requirements, we obtain a unit, since they are different only in one position and, therefore, when implementing requirement B, attention should be paid to requirement A and its implementation. Naturally, the decision on reuse is already taken by the developer or another decision maker, but it is already good when there are options where you can peep the implementation.

Thank you all for your attention, waiting for comments.

Source: https://habr.com/ru/post/114571/


All Articles