Software development is based on requirements — users' expectations of future functionality. Requirements differ greatly in substance, composition, form, and quality. It is therefore very important to name and use different kinds of requirements correctly.
In ALM we distinguish three main requirement levels:
| Customer, user, or representative level |
Primary requirements - Issues, Requests, change requests, and wants. These are unstructured, incomplete, and even contradictory requirements that reach the team from various sources. Such requirements are often written in free text or recorded in the User Story format. The essential difference between primary requirements and the others is that they contain both requirements for functionality and changes to functionality. In other words, a set of primary requirements makes it extremely difficult to obtain a complete description of the functionality of the whole system. |
| Analysis, design, and modeling level |
Business requirements and system requirements (functional and non-functional, NFRs) that describe business processes and the requirements for developing the software system as a consistent whole. These requirements are of the highest quality, because they are prepared by specially trained people. System requirements can be divided into use cases, NFRs, UML models, user interface mockups, and so on. The documentation formats usually applied are: BRD (business requirements document), business case, SRS (system requirements specification), a technical specification (TS), and so on. |
| Level of developers, testers, and technical writers | Tasks for implementing requirements (in full, in parts, or as entire documents) are called Enhancements. An Enhancement records what must be implemented, or which changes to make to a previously implemented requirement, when and by whom, and so on. Testers also use Enhancements to verify that requirements have been implemented. |
It is also important to distinguish the type of a requirement from the format in which it is documented. For example, a technical specification (TS) contains many requirements of different types plus general information. Use Cases can be written in the format proposed by Alistair Cockburn, in the format proposed in the OpenUP process (Rational Unified Process), and in several other popular variants. You need to decide for yourself how to document requirements effectively on your projects.
Depending on the complexity of the domain, the complexity of the system, and the Assignee's qualifications, the requirement levels described above may overlap. For example, a development team can also work effectively with primary requirements.
Modern ways to discover and collect primary requirements are given below.