Close
Introduction
In the world of engineering there are many projects that fail for one reason or another. A large proportion of those projects fail due to problems in the early stages of systems development. The Standish Group performed research to identify:
‣ The scope of software project failures
‣ The major factors that cause software projects to fail
‣ The key ingredients that can reduce project failures.
This research found that customer or user involvement and good Requirements Engineering (RE) were amongst the biggest contributors to project success.
What is Requirements Engineering?
The requirements engineering process bridges the gap between the customer and the supplier. Here "customer" is used rather loosely to mean the people who want some system, and "supplier" is used to mean the people and organisations which will provide it. To emphasise that it must include everyone affected, the term "stakeholder" is used to cover all such people. Key roles include:
‣ Users are those who will directly use the system: their needs must be considered in
defining the system
‣ Other people affected are those who do not use the system directly, but will be influenced by it. Examples are people living near a power station, or customers of a company which introduces a new billing system.
‣ The purchaser is the part of the organisation actually paying for the system. Usually this is some sort of headquarters function. Typically purchasers will have very different requirements from users: they will be more interested in cost than convenience, or may even wish to eliminate users altogether.
The supplier should be just as concerned about the requirements as the customer. They define what it is that must be supplied. It is in everyone's interest that this is clearly defined so there is no dispute about when the supplier has met their obligations.
The 'science' of RE
Traditionally RE has been described in terms of development of a new system for a defined customer. In practice, this is the least common situation.
‣ New products don't have customers. Furthermore there is usually not a single product, but a whole product line.
‣ Nowadays the vast majority of projects are changes to existing systems, not completely new developments. Frequently the requirements for the existing system
aren't known. This can be a dangerous situation: how do you know what changes it is safe to make?
‣ It is also a fallacy that requirements are always top down, based on perceived needs. In many cases there is technology push rather than user pull. The problem is
to determine how to use the solution, not how to solve the problem.
Tools for RE
Tools are absolutely necessary on large projects. However, they are far from a panacea and there is still a long way to go before they fit seamlessly into the overall development process. Many tools assume that you are using a particular process. If you want a different process, the tool can be a hindrance not a help. Tools are often very poor at structured requirements. They typically assume that a requirement is a piece of text, possibly a hierarchical structure of text. But many don't usually support for example structured use cases or function definitions, much less statecharts or formal specifications. SysML does support most of these aspects but then training is necessary to exploit this large modelling language. Some tools are very closed: for example you can trace anything held in the tool, but not artifacts like code or other models which reside outside tool control.
