Recent Articles

What's Good About Clojure?

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 ...

Tips for Setting Up Your First Business Website

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 ...

What's Good about LISP?

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 ...

Open Source Tools for Developers: Why They Matter

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 Interview with Norbert Cartagena

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

Introduction

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 Requirements Engineering.

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 engineering as:

...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 systems, 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 definition:

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 misrepresented.

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:

Functional Requirements - describe system features or things the system must do.
Non-Functional Requirements - describe properties the system must have (e.g. performance, availability, accessibility).
Constraints - limits the development in some way. Such as, defining an operating system the system must run on, or defining which programming language must be used to implement the system.

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, inconsistency, and 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 requests!

Requirements are 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.

Implementation Bias

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 quick fix.

The Knowing-Doing Gap

The importance of requirements is well-known to software developers - but they continue to build systems without paying proper attention to requirements. Why do they do this? This is another example of the Knowing-Doing Gap in software development (for further discussion on this, see my article Practising Best Practises in Your Software Development Process). I am going to suggest a reason for this later in the article; in the meantime let's continue with our discussion of requirements engineering.

Dimensions of Requirements Engineering

As software developers, we know that developing good quality software that is robust and meets all the stakeholders' expectations is both difficult and error prone. Any assistance in the form of a process framework to help minimise the risk is therefore of immense value. The main activities in Requirements Engineering fall into one of the following categories:

Eliciting requirements (gathering requirements from stakeholders)
Modelling and analysing requirements (checking for consistency and completeness)
Communicating requirements (writing down descriptive requirements for developers)
Agreeing requirements with stakeholders
Evolving requirements

Of these, the greatest value lies in taking time to understand the customers' needs. Only then can precise statements about requirements be written down, used as the basis for design and development, and tested against. The last activity in the list, 'evolving requirements', is an acknowledgement that requirements change. This can be due to omissions and misunderstandings on the part of the project team or the stakeholders, or it could simply be the result of a change in some circumstances, external to the project, that nevertheless have an impact. For example, a particular feature may no longer be needed in the software if a reusable solution has been found elsewhere.

A recent seminar on Requirements Engineering organised by the Institution of Engineering and Technology's Systems Engineering Network took an interesting approach in determining the essence of RE by attempting to answer 6 key questions:

Who should be involved?
What do they want?
Where (in what context) could it work?
Why do they want it?
How will we know?
When should we build it?

In the terminology of requirements engineering, these basic questions are answered by the following activities. Deciding who should be involved is called stakeholder analysis, and determining what they want is the purpose of goal modelling. Identifying the context in which the solution could work is known as scenario modelling, and the reasons behind the requirements (and the solution) are given by rationale analysis. We can only know whether we have met the requirements if they are testable or verifiable, an important consideration when laying down the acceptance criteria. Knowing when to build the system, or when to satisfy particular requirements, is an issue of triage and prioritisation. (Triage is a technique for sorting tasks or cases into (ostensibly) three categories depending on their urgency. According to Wikipedia, it has been largely attributed to Dominique Jean Larrey, a famous French surgeon in Napoleon's army, who needed to quickly evaluate the level of urgency of medical attention needed by battle-wounded soldiers.)

As a corollary to these questions, we should also ask "With what requirements tools?" For example, what tools will we use for scenario modelling, and how will we maintain the set of requirements as they change over time? Can we trace how requirements have changed, so that we can assess how they impacted the project and learn from our experiences? There are various offerings in the market place to help with this task. UML is the most widely used modelling language in the world, and there are many software applications in the marketplace to support its use. It can be applied to a variety of business and engineering applications, from traditional systems engineering to business process modelling. SysML - Systems engineering modelling for the real world - an introduction to SysML for systems professionals. SysML is a new systems engineering modelling language, covering a variety of applications, including modelling constraints and architectural frameworks such as MODAF.

We should not underestimate the utility of use cases, which not only capture typical interactions with the system, but also help to demonstrate how the use of the system fits into the user's work patterns.

Requirements in Agile Projects

Increasingly, software developers (and even their managers) are recognising that changing requirements are inevitable. A waterfall approach to software development, in which requirements cannot be revised while the project is running, is simply unrealistic. In fact, the early efforts of a project, when presented to the customer, usually help to elicit further requirements. This suggests that keeping the customer well informed of the progress of the project, and providing regular updates and demos will help to keep the project on track. This approach is advocated by agile programming practices, which have emerged in recent years.

However it remains a challenge to deal with changing requirements, and it requires some cooperation in the form of 'give and take' between the project development team and their customers, so that new requirements can be taken into account and priorities of the existing requirements adjusted accordingly. This can be difficult from a contractual point of view, so a good customer relationship is very important.

Conclusion

We have seen that requirements engineering adopts a multi-disciplinary view that considers requirements not only in terms of software components specification but also in terms of activities for their elicitation, representation and agreement, carried out within an organisational and social context. To this end, research contributions are being made from fields as diverse as human-computer interaction, computer-supported cooperative work, linguistics, occupational sociology, and both cognitive- and organisational psychology.

So should you care about Requirements Engineering? It depends. In my opinion, Requirements Engineering is currently more of a research area than a prescribed methodology. So if you are an academic with an interest in software development, then yes, you should care about requirements engineering. Those of us who want only to build working systems may not be interested in the field of requirements engineering as such, but should be interested in the recommended practises and processes that emerge from that field. Perhaps, a better question would have been "Should you care about the capture and maintenance of requirements?", to which the resounding answer is "Yes, absolutely!"

Adil Hameed & Simon White