A requirement is a capability or condition to which the system must conform and it can be defined in three main categories: functional requirements, nonfunctional requirements and constraints. Functional requirements are those things the product must do, while nonfunctional requirements (e.g., ISO9126) are the properties the product must have. A constraint is a restriction on the scope or design of the product (e.g., the system shall be developed for PC and Macintosh platforms.)
Requirements are the basis for project planning, priority setting, development & testing. Therefore an efficient and effective way of managing the requirements can reduce significantly the cost of rework.
Requirement Engineering is a systematic approach to gathering, organizing, and documenting the requirements of the system. While requirement management is a process to establish and maintain agreement between the customer and the project on the changing/modifying requirements of the system (like in Agile, managing the backlog by Product Owner ) The challenge in Requirement Engineering is to find a way to capture the need “completely” and “unambiguously” without resorting to specialist jargon, in the way that all stakeholders can understand it.
Requirement Engineering in most best practice cases follow certain steps, which can follow differently the order (e.g., in Agile):
- Kick off phase; to understand the objective, scope, stakeholders, and the business case;
- Requirements gathering (the more the best); of any type of functional, nonfunctional or constraints;
- Requirements specification (which is a quality based step); in which the templates and modules are defined and set, and the detail levels are agreed upon;
- Verification and validation, using check lists and rules to check the requirements, which is done through walkthrough or pair inspection;
- Requirements management
In order to estimate how much documentation is enough, we should remember that requirement process is context dependent. The limits that may arise by user requirements are such as:
- the domain in which a system is going to be used (the problem domain, or user requirements; what the stakeholders want to achieve through use of the system);
- the domain in which engineers use their ingenuity to solve problems (the solution domain, or system requirements; how the system will meet the stakeholder requirements);
- adopted methodology (e.g., Agile, V-model, Outsourcing);
- business, project, product, human factors
However the documentation helps to overcome most of the current difficulties which occur during communicating the requirements, due to language or interpretation barriers. To have a smooth communication we need first to settle some rules; that are useful set of agreements to specify the context of the requirement and the requirement documents to be applied during specification and reviewing. This rules help to be objective and to avoid unnecessary discussions, and shall be regarding the tracing, the format and the content and they should be based on the organizational specifications. (e.g., The INVEST mnemonic for agile software projects.).
The next step is to define which attributes are essential to identify a requirement; a minimum but necessary set of properties that individualize the specific requirements. These attributes usually evolve in the form of a card (e.g., user story card) and they can be such as a set made of : id number, type, use case, description, rationale, priority, acceptance criteria, source, and size.
In order to write the description comprehensively , it is suggested to use simple phrases containing one verb. An agreed grammatical template may be very useful in this case. (e.g., “the <stakeholder> shall be able to <capability>” or “the <product> shall be able to <action> <entity>”.)
The description must regard only the main purpose need of the requirement, in which any points to the design or implementation aspects should be avoided. While the acceptance criteria; which can be very helpful in case of nonfunctional requirements; shall be used to make the requirement measurable, and to indicate whether or not a solution can comply or fit the requirement (e.g., 90% of the customers must be able to get the correct ticket from the product in no more than 25 seconds). In other words the acceptance criteria is used to fine tune the requirements.
The last but not the least important factor in communicating the requirements is team engagement and involvement and learning through practice. Testers can join the requirement reviews as early as product backlogs and sprint backlogs reviews, participating in walkthroughs (in an Agile case), to join the discussions and receive as much information as possible, and to be able to participate much proactively in inspections during the sprint. Same hint can be applied also in traditional methods begging to involve the testers as soon as requirement specification meetings.