ALM User's Guide

Depending on project conditions, product complexity, team qualification and many other factors, you can use different schemes of working with requirements.

When implementing simple and clear requirements, it's not required to create detailed specifications of document business processes. Working with documentation takes time, especially when requirements constantly change. For one-time software products, prototypes, and MVP, preliminary design is not so valuable as speed of receiving feedback from users.

In this case, development is based on primary (custom) requirements. A customer or his representatives formulate requirements refining them with the project members. When the requirements are clear, the project team implements them and hands over a working product to customer users to receive feedback from them. Then the cycle repeats until all custom tasks are completed.

User stories is one of the common and convenient methods to write custom requirements. In short, we use the following format to write custom requirements:

Brevity is good, but success of project will depend on the quality of requirements. You need to train to write good stories. Use INVEST principles as a checklist for quality control of developed stories.

Description of functional requirements in the form of use cases should not be confused with description of custom requirements in the form of user story - these are two very different views on software requirements. A single user story may contain several use cases. User stories are not a way of structuring software requirements.

There are risks of software development based on user requirements:

• due to changes in team, qualification level and knowledge about system internals may degrade, then requirement quality will suffer, and finally product quality will suffer too;
• custom requirements are not an alternative to functional requirements since they are formulated about different parts of system as required. After several months of product development you'll receive hundreds of stories, often they conflict with each other. Thus, you won't able to understand how system or its particular function works.
• Implementation of new requirements may break product integrity and lead to loss of important functionality, as it seemed to someone that a single tick is unnecessary.

To mitigate these risks, you can use a technique of supporting requirements development.

Before implementation of the user story, during the process of implementation, or just after its completion, document important technical solutions: UI layouts, algorithms, data models, etc. On the one hand, these system requirements will be bound to the story and allow to implement it properly. On the other hand, over time you will accumulate structured system requirements for the entire product which will eliminate the aforementioned risks.

Why is it bad to write system requirements directly in the story itself? User story should be small by its nature. Completion criteria and acceptance criteria enlarge its description. System requirements in the form of layouts (and their detailed requirements), algorithms, and different models will make a story bulky and not convenient for work. Moreover, it will be impossible to find the desired system requirements, not to mention making changes in them.

Implementation of product based on sketchy and superficial representations about its functionality may lead to making quick, but short-sighted technical decisions. In rapid application development technologies (Scrum, XP) it is called a "technical debt". Rather than make it properly right away, you'll have to rework predefined system architecture often. These are additional losses of time and money.

Term "cone of uncertainty" means that the less detailed the requirements are, the more is the error in their complexity and workload estimation. More precise estimation of project budget, or budget for modification of already implemented requirements is possible only during the preliminary elaboration of requirements and analysis of modification impact on them.

Requirements driven development (RDD) assumes explicit use of design cycle which includes the following:

• primary requirements are collected and documented, inconsistencies are eliminated, required details are refined;
• documentation for business requirements and functional requirements (product requirements) is generated;
• requirements are reconciled with architects and testers for their implementability, testability and other quality criteria;
• requirements are reconciled with customer, budget is estimated and implementation (development) is planned.

After design cycle, development cycle is organized based on the generated tasks for development (enhancements):

• release or iteration plan is generated within which portions of requirements (e.g., product features) are implemented;
• technological cycle is carried out: low-level design, development, testing, documenting, etc.;
• executable code is generated which can be used by designers and the customer for acceptance of the development results.

In some cases, project may be completed after the design cycle if it's purpose was the development of software requirements.

Sometimes development based on requirements is confused with waterfall development (or development based on GOSTs). Amount of the designed requirements (increment size) can be adjusted according to the project conditions.

Requirements may be distributed between different projects and interconnected with each other:

• Common business requirements and functional requirements can be developed on the level of program, and detailed system requirements to components can be developed on the level of subprojects controlling work of different teams;
• Common requirements can be stored in the program, and subprojects can be used to develop functional and system requirements for desktop, mobile and other versions of product;
• Requirements to systems being integrated can be located in different projects and interconnected to monitor impact of requirement changes in one system on requirements in another system.