Who could argue that effective requirements gathering, analysis and management are central to project success? Improvements in this competency will pay for themselves very quickly.
The processes of requirements specification and testing are intimately linked; it is a link that is central in our approach to consultancy, project support and training in these vital areas. Requirements and testing are key to any project; they are also frequently problematic.
The simple word, requirements, is often understood differently by different members of the project team and by the customers. It is usually best to start with a clarification of terms.
Requirements may be categorised by type. Each type will typically be specified in a manner peculiar to it. Testing is performed against that specification. Consequently, each type needs, to a greater or lesser extent, its own approach to testing or measurement.
One approach to categorising requirements is as follows:
Business Requirements as defined in the business case
Project Requirements affecting the project itself
User Requirements defining what the user actually needs
Technical requirements, the base for the creation of a technical design
The business case is established early in the project to fully specify the objectives of the project and its expected benefits.
The business case essentially defines the business requirements of the project.
Benefits Realisation Management is the process of assessing the extent to which expected benefits have actually been achieved. This measurement process commences as soon as the project deliverables have been accepted by the user.
Note that a project supplies products (deliverables); it does not directly supply benefits. It is necessary that the customer signs up to say that the expected benefits are derivable for the project's deliverables.
The project requirements define such elements as project cost and duration. They should be based on the business case; the business case may, for instance, be heavily dependent on a particular project end date.
Constraints may be defined for the project and for the project deliverables.
Achievement of project requirements and constraints may be assessed during an end project review.
Based on the business requirements as reflected in the business case, the user requirements are to be specified by those who will be using the project's deliverables.
Business rules and quality criteria may be captured at the same time.
There are many techniques to assist the elicitation of user requirements; there are many tools designed to assist in the recording and management of those requirements.
Testing is conducted against the user requirements specification. Something may be claimed to be a requirement, but if it is not possible to create a test case for it, then it is not a requirement.
Testing must be planned and conducted in a methodical manner in order to ensure that it is done comprehensively. There are techniques and tools to assist this process. It is important that the techniques and tools interface effectively with those used for requirements elicitation.
This level of testing is traditionally covered during user acceptance testing. For software systems it is essential that all aspects of the associated business processes are tested.
Technical requirements are those detailed requirements that will support the achievement of the user requirements.
Typically the technical requirements are divided into two categories; functional and non functional.
Functional requirements define the essential functionality of the system.
Non functional requirements attach to the functional ones in a many to many relationship and define aspects such as performance, security, look and feel, legal, etc.
Testing of technical requirements is performed against the technical requirements specification. Aspects of this level of testing will traditionally be performed during acceptance and systems testing.
Project Performance Consulting, together with partners Capiro, can offer the following support.