Requirements Process
Whilst few would disagree that requirements are important, many would wish that requirements specification can be completed in a very short amount of time. One way of overcoming this complication is to ensure that your requirements process is risk driven.
Requirements specification can range from the rigourously formal to the exceedingly informal. In a given situation it is useful to have an agreed set of criteria for assessing the optimum level of formality; this may be based on perceived risk.
The process outlined here is obviously not the only possibility. It is written as a highly simplified overview. Despite the simplicity, each step is well formed. These basic steps form essential parts of many people's approaches to requirements. It is important to appreciate that such steps, even when they are highly detailed, should not be read as a recipe; if they are, it is unlikely to be a recipe for success. The experienced requirements practitioner treats such steps as possible starting points and will instantiate the actual approach based on the specifics of the case at hand. In particular, the practitioner is likely to consider such things as risk, familiarity of the development team with the business and the client organisation, and the geographical distribution of the development team.
The Process
Start by identifying and understanding the problem.
- Problems stand between you and your objectives.
Identify the problem owner or owners.
- These are the stakeholders; get to know them. Involve them.
Define the scale of the problem.
- Scope, interfaces, impact, cost.
Clarify the objective whose achievement the problem is blocking.
- This may be an objective of the business, a business user, or both.
Define what is needed to solve the problem.
- This will form the basis of your requirements.
Requirements should define a product in a solution independent manner.
- A well-written requirement should normally permit multiple solutions.
Involve the users in determining the requirements.
- There are many techniques for eliciting the requirements.
A favourite technique is to get the user to tell you a story.
- These stories are referred to as scenarios.
The scenarios should initially be informal.
- They can be progressively formalised.
Scenarios can be supported by models with graphic representations.
- Models may be formal or informal.
Scenarios can also be supported by prototypes.
- Prototypes do not have to be constructed from software.
Requirements statements and models should be validated by the business users.
- Validation normally takes the form of a review.
The finished product should be verified.
- Acceptance testing is a minimum form of verification.
Involve the testing team from the outset.
- Some people go as far as recommending that testers define the requirements
Base project estimates on the design rather than requirements.
- Involve architects and designers from the outset.
Capiro can help you create or define an appropriate process for your environment.
See our process, '8 Steps To Requirements Success'
See also our training course, 'Requirements Engineeering: Right First Time'