Clojure is a relatively new language to appear on the Java Virtual Machine (JVM), although it draws on very mature roots in the form of the LISP langu ...
To attract all potential customers to your business you need a presence on the web. The problem is that if you haven't set up a website before, you p ...
LISP is a general-purpose programming language and is the second-oldest programming language still in use, but how much do you know about it? Did you ...
From a developer's point of view use of open-source tools has advantages beyond the obvious economic ones. With the open-source database MySQL in mind ...
An exclusive interview with Norbert Cartagena, the former editor-in-chief of Developer Shed Inc. and self-confessed fan of science fiction. In ...
Should You Care About Requirements Engineering?
Adil Hameed & Simon White
Recently, I (Adil) was invited to participate in a one day seminar
on the subject of Requirements Engineering. Whilst I have no direct
experience of this field, I was keen to find out more and decide what
value requirements engineering can bring to the day-to-day practises of
software engineering. I attended the seminar and this article
summarises my findings and current thoughts on the subject of
What is Requirements Engineering?
Of all the phases in the software development life cycle, requirements gathering is arguably
the most critical. In a waterfall model of software development, which
does not offer the opportunity to revise requirements during later
phases, entering the implementation phase with a set of requirements
that are poorly understood or incomplete poses a considerable risk to
the project. Correcting such errors consumes more time and becomes more
expensive the later in the project that the errors are discovered. It
is therefore not surprising that a great deal of attention has been
paid to the principle of getting the requirements right first time. As
getting things right requires a disciplined approach, the
field of requirements engineering
was borne out of this need.
The Requirements Engineering Specialist
Group (RESG) of the British Computer Society defines requirements
...a key activity in the development of software systems and is concerned with the identification of the goals of stakeholders and their elaboration into precise statements of desired services and behaviour."
Note that although this definition specifically mentions software
requirements engineering can be applied more generally to the
development of other kinds of systems. An unfortunate omission from
this definition is the maintenance of requirements as they (inevitably)
change over time. Pamela Zave provides the following alternative
Requirements engineering is the branch of software engineering concerned with real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour, and to their evolution over time and across software families.
This definition emphasizes that requirements engineering is about
solving real-world problems by forming precise statements about their
solutions. Precision is important so that it can be decided without
debate whether a particular requirement has been satisfied. Before
proceeding further, let us clarify what we mean by a requirement, as in
general, requirements are poorly understood and are often
What is a Requirement?A requirement, according to Wikipedia, is "a singular documented need of what a particular product or service should be or do". Systems may have from dozens to hundreds of requirements. A collection of requirements then defines the characteristics of the desired (required) system, but does not say how the system should implement those requirements. In other words, it imposes constraints on the delivered system that are important to the customers or other stakeholders, while leaving most design and implementation decisions to the discretion of the developer.
A golden rule of requirements writing is that all requirements must be verifiable. This means it must be possible to decide whether a requirement is satisfied without recourse to subjective opinion. If this is not the case, then the offending requirements should be altered or dropped. A common example is where the customer states that the application (or perhaps particular features, such as a database search) must be fast. When stated so plainly, this is not verifiable as one person's interpretation of 'fast' is different to anothers. Better is to make a statement such as 'Under typical usage, 90% of search requests must terminate within 10 seconds'. This puts hard numbers onto the performance requirement, and by working with a set of users to establish what 'typical usage' really means, it is possible to test whether this requirement has been satisfied.
Requirements are typically classified into three categories:
Expert users often play a key role in eliciting the requirements.
They can provide a necessary link between the user base and the
software developers, because they understand the problems of the users
and are able to identify necessary functionality of the required
system. However, the project development team should not assume that
all users are like their expert user. Most users want simplicity in the
user interface, whereas expert users sometimes ask for complex
functionality that is not needed by most users. This can extend the
duration of the project unnecessarily or lead to a user-interface that
is too complicated to use for common tasks.
Unfortunately, requirements are prone to issues of incompleteness,
conflict. It is important to manage requirements and resolve such
problems quickly, as ambiguities and inconsistencies may cost orders of
magnitude more to correct in
later stages of software development than when these same issues are
resolved in the requirements phase. A rigorous inspection of
requirements has been shown to
help deal with these issues. In fact, good practice dictates that
requirements undergo a rigorous review in
order to flush out any ambiguities, anomalies or downright impossible
notoriously difficult to pitch at an ideal level.
There is a fine balance to reach between requirements which are too
vague (for example, "must be user-friendly", or "must include the
ability to search"), and those which are so detailed that they begin to
limit the implementation options available.
When requirements are expressed in terms of the implementation, this is
known as implementation bias.
Implementation bias is generally to be avoided, because it
overconstrains the solution. In other words, it unnecessarily limits
the choices available to the developer, and may prevent the
developer from even considering the best solution to the problem. For
example, a requirement for a new version of a product to contain a
drop-down menu of choices for a particular parameter has an
implementation bias because it suggests the solution to the problem
rather than stating what the problem is. The user needs to be able to
select from a set of choices, but a drop-down menu may not be the best
solution. Perhaps a group of radio buttons or some other graphical
device is more appropriate. However, because the requirement states
that a drop-down menu is the requirement, the developer is not strictly
at liberty to choose an alternative approach. Under such circumstances,
the project manager or developer should recognise the implementation
bias and approach the customer for further clarification. The
requirement needs more understanding, rather than implementing the