IT project requirements management

Good afternoon, dear habrosociety!

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 on Habré is covered quite widely in the corresponding blog, but nothing was found about managing requirements. Well, it's time to fill this gap!



In today's economy, the winner is the one who produces more with less. 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 automating activities is information systems. An information system is a combination of information, mathematical, linguistic, technical software and other software, as well as personnel for the operational preparation of information for decision makers.

CIS are delivered both in a boxed version, which offers standard solutions for automating tasks, and allow you to create the necessary set of functions yourself in design mode. In addition, many corporate systems developers offer services for adapting boxed 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 via communication channels without large material costs, unlike products of material production. Information products have a much greater opportunity to adapt to the required specific production, and therefore the task is to obtain the source information for the development or adaptation of the information system.

The development of a large and complex system cannot be completed in one approach - 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 implement this code. 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 the requirements management.

Managing requirements, developing requirements and defining requirements are the cornerstones of the success of any IT project.

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

Requirements management

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

Requirements management - a process that includes identification, identification, documentation, analysis, tracking, prioritization of requirements, reaching agreement on requirements and then managing changes and notifying interested parties. Requirement management is a continuous process throughout the entire product life cycle.

A requirement is any condition that a developed system or software must meet. A requirement may be the capability that the system must possess and the constraint that the system must satisfy.

In accordance with the IEEE Glossary of Software Engineering Terms, which is the generally accepted international standard glossary, the requirement is:
  1. The conditions or capabilities necessary for the user 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 satisfy standards, specifications, or other formal documents;
  3. A documented presentation of the conditions or possibilities for paragraphs 1 and 2.

In accordance with ISO / IEC 29148, the requirement development standard, a requirement is a statement that identifies the operational, functional parameters, characteristics, or limitations of a product or process design that is unambiguous, verifiable, and measurable. It is necessary for the acceptance of a product or process (by the consumer or by an internal guiding principle of quality assurance)
. Also, the ITILv3 glossary defines such a concept as a set of requirements - a document containing all requirements for a product, as well as for a new or changed IT service.

A requirement must have the following characteristics:
  1. Unity - a requirement describes one and only one thing.
  2. Completeness - 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 is fully consistent with the documentation.
  4. Atomicity - a requirement cannot be divided into smaller ones.
  5. Traceability - the requirement fully or partially corresponds to business needs as stated by interested parties and documented.
  6. Relevance - the requirement has not become obsolete over time.
  7. Feasibility - a requirement can be implemented as part of a project.
  8. Unambiguity - the requirement is defined without resorting to technical jargon, acronyms and other hidden formulations. It expresses objects and facts, not subjective opinions. One and only one interpretation is possible. The definition does not contain fuzzy phrases, the use of negative and compound statements is prohibited.
  9. Obligation - the requirement is a characteristic defined by the interested person, the absence of which leads to an inferiority of the decision, which cannot be ignored. An optional requirement is a contradiction to the very concept of a requirement.
  10. Verifiability - The feasibility of a 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 hosting, administration, and security.
  3. Ergonomic (Usability) - to the convenience of end users.
  4. Architectural (Architectural) - requirements for system architecture.
  5. Interactions (Interface) - to the relationship between existing applications and software and a 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 Requirement 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 functional capabilities of the above systems, taken from manufacturers' websites.

IBM Rational Requisite Pro

Rational software provides best practices for defining and managing requirements that save time and money by helping you solve the following problems:
  • Reducing the volume of improvements and accelerating market entry through joint work with interested parties.
  • Increase in labor productivity due to control over changes in requirements and their management.
  • Minimizing costs and risks by assessing the impact of ongoing changes.
  • Demonstration of compliance through full traceability of requirements.

Rational RequisitePro helps project teams manage requirements, create high-quality usage scenarios, expand tracking capabilities, improve collaboration, reduce the need for improvements, and improve quality.
  • Reduces complexity with detailed traceable views that show the relationship between parent and child elements.
  • Reduces project-related risks by showing requirements that may be affected by changes in requirements of a lower or higher level.
  • Facilitates the collaboration of geographically distributed workgroups through the use of a fully functional, scalable Web-based interface and discussion chains.
  • Provides collection and analysis of requirements information with the ability to fine tune attributes and filtering.
  • It increases productivity by allowing you to track changes by comparing project versions with the initial characteristics described using XML.
  • Ensures project results are consistent with their objectives and business goals through integration with IBM Rational software development and release tools.

IBM Rational / Telelogic DOORS

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

Initially, DOORS was developed only as a means of managing requirements in the software development process. However, the ideas embodied in DOORS turned out to be 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 interconnected information, for example, when developing engineering systems.

The following information can be obtained from Telelogic DOORS:
  • The status of the performance of work for each requirement separately, as well as for a group of requirements.
  • Status of work on the entire project.
  • Responsible person for each requirement or group of requirements.
  • Change history requirements.
  • Resources that will be required to implement the requirement before it is implemented in the project.
  • The relationship between customer requirements, terms of reference, verification, testing programs and project management tasks.
  • The class, model, or drawing in which a particular requirement is implemented.

Borland caliber rm

Borland Caliber RM is a corporate requirements management system that facilitates collaboration, allowing development teams to approach project milestones on time and with planned costs. Borland Caliber RM also helps development teams make sure that the developed application meets the wishes of end users by continuously collecting wishes at all stages of the life cycle from analysts, developers, testers and other interested parties to the project.

Borland Caliber RM has the following features:
  • Centralized repository of requirements for all projects developed by an IT company.
  • Adaptability - Caliber RM can be configured for use in any project, which increases the efficiency of the requirements management process.
  • Requirement Traceability - The open architecture of Caliber RM allows you to associate requirements with other artifacts at all stages of the software product life cycle.
  • Support for a large number of clients - Caliber RM integrates perfectly with development systems such as Microsoft Visual Studio, Eclipse on the Windows platform.
  • Integration with other Borland products to support the full software product life cycle.

Other software

Quite well-known requirements management systems, such as:
  • Sybase powerdesigner
  • OpenSource Requirements Management Tool
  • RequirementsWin and others

A new approach to requirements management

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

To realize the ability to search and reuse requirements, a methodology for identifying requirements represented by natural language text is required. Then, presenting the requirement not only as a text, but also a combination of some concepts or linguistic variables, it will become possible not only to search for similar requirements, but also to use artifacts re-created in the process of 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 due to 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 instance,

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

Here we see that under F and A there are referring to documents, and B, C, D, E - their routes.

Having calculated the Hamming distance between these two requirements, we get a unit, since they are different in only one position and, therefore, when implementing requirement B, it is worth paying attention to requirement A and its implementation. Naturally, the decision on reuse is already made by the developer or another person making the decision, but it’s already good when there are options where you can peek at the implementation.

Thank you all for your attention, I'm waiting for comments.

Also popular now: