Requirements Engineering

In the last month’s article, we learnt what software requirements are and why they are important for software.  The need for good requirements, and the consequences of a lack of it, is most apparent in systems that are all or mostly software. Because of its importance, a discipline called ‘Requirements Engineering’ has emerged in the past few years. This is of paramount importance for the software development life cycle and eventually this act as the primary control we have to guarantee a satisfied end user. Article today, presents an overview of field of software systems requirements engineering (RE) with a focus on RE practices.

What is RE?

We will first consider a definition for RE

Thus, we see that RE, in simple words, is a set of activities concerned with identifying and communicating the purpose of a software system, and the contexts in which it will be used.  Hence, we can say that RE acts as the bridge between the needs of users, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software technologies.

Further, the term ‘Requirements’ suggests that there is someone out there doing the ‘requiring’ – a specific customer who knows what she wants. In some projects, requirements are understood to be the list of features (or functions, properties, constraints, etc.) demanded by the customer. In practice, there is rarely a single customer, but rather a diverse set of people who will be affected in one way or another by a system. These people may have varied and conflicting goals. Their goals may not be explicit, or may be hard to articulate. They may not know what they want or what is possible. Under these circumstances, identification of requirements is not an easy task. Then, term ‘Engineering’ suggests that RE is an engineering discipline in its own right, whereas it is really a fragment of a larger process of software engineering. The term ‘engineering’ also suggests that the outputs of an RE process need to be carefully engineered, where those ‘outputs’ are usually understood to be detailed specifications.

Core RE Activities

There are 5 core activities involved in RE, namely:

• Eliciting requirements
• Modelling and analysing requirements
• Communicating requirements
• Verification and Validation of requirements
• Managing requirements

Even though these activities are described independently and in a particular order, in practice, these are actually interleaved, iterative, and may span the entire software systems development life cycle. Now we will see what we have to go in each of these activities.

a. Eliciting requirements:

The elicitation of requirements is perhaps the activity most often regarded as the first step in the RE process. This is the practice of obtaining the requirements of a system from end-users, customers and other stakeholders. The practice is also sometimes referred to as requirements gathering. The term “elicitation” is preferred to “capture”, to avoid the suggestion that requirements are out there to be collected simply by asking the right questions from the right stakeholder.

There are few activities that we need to carry out for eliciting the requirements, such as identification of actors and users, user scenarios and use cases, understanding the relationships among the user scenarios, refinement of the these, identification of the non-functional requirements etc.

Requirements elicitation is perhaps a challenging task. Because, it requires a high degree of collaboration of people with different backgrounds. Thus different requirements elicitation practices are adopted, such as interviews, questionnaires, user observation, workshops, brain storming, use cases, role playing and prototyping.

Information gathered during requirements elicitation often has to be interpreted, analysed, modelled and validated before the requirements engineer can feel confident that a complete enough set of requirements of a system have been collected. Therefore, requirements elicitation is closely related to other RE activities.

b. Modelling and analysing requirements:

The requirements gathered at the elicitation can now be modeled in order to determine whether the collected requirements are unclear, incomplete, ambiguous, or contradictory. Modelling – the construction of abstract descriptions that are agreeable to interpretation – is a fundamental activity in RE.

We have the following modelling approaches which are useful in analyzing the requirements gathered.

1. Enterprise modeling – this deals with understanding of the organization in which the system is going to be placed, the business rules, regulations and procedures that will govern the operations, goals and the objectives of its constituent members, etc.
2. Data modeling – large systems, especially information systems use and generate large volumes of data/information. This information needs to be understood, manipulated and managed properly. Thus, it is important to take careful decisions about what information the system will need to represent, and how the information held by the system corresponds to the real world being represented. Data modeling particularly provides the opportunity to address these issues in RE.
3. Behavioral modeling – modelling requirements often involves modelling the dynamic or functional behavior of stakeholders and systems, both existing and required. By this we can clearly understand how the system operates, the contractions of the requirements and any of the missing requirements.
4. Domain modeling – a significant proportion of the RE process is about developing domain descriptions. A model of the domain provides an abstract description of the world in which an envisioned system will operate. Building explicit domain models provides two key advantages: they permit detailed reasoning about what is assumed about the domain, and they provide opportunities for requirements reuse within a domain.

c. Communicating requirements:

So far, we identified that RE consists of discovering and specifying he requirements. The next important activity is the facilitation of effective communication of these requirements among different stakeholders. Industry wide way of communicating requirements is to develop the requirements specification.

A software requirements specification is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. These are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional.

There are so many standards adopted by professional for SRS and the recommended approach for the specification of software requirements are described by IEEE 830-1998. This standard describes possible structures, desirable contents, and qualities of a software requirements specification.

d. Verification and Validation of requirements:

The next stage is the verification and validation of the collected requirements. By this, we ensure that all the requirements are gathered and there are no contradictions in the requirements. In other words, it is the process of establishing that the requirements and models elicited provide an accurate account of stakeholder requirements. This activity ensures that the correct requirement is passed on to the development, and that the quality of input for development is high.

Managing requirements:

Change is inevitable in the real world.  Similarly, software systems always evolve. Because the environment in which these systems operate changes and stakeholder requirements change with time. Therefore, managing change is another fundamental activity in RE.

Summary

Today we learnt that Requirements Engineering is an emerging and vital discipline in Software Engineering. This sub-discipline is concerned with determining the goals, functions, and constrains of software systems. There are five main activities in Requirements engineering: Eliciting requirements, modeling and analyzing requirements using different methods, communication of requirements, verification and validation of requirements and requirement change management. All these activities are intervened and interrelated. For each of these activities, there are industry standards, methodologies and tools, developed.

In subsequent articles, we will take an example of Requirement Engineering for a real world scenario and study how each of these activities are being practiced and learn the best practices, tools and methodologies.

References:

Requirements Engineering: A Roadmap, by Bashar Nuseibeh and Bashar Nuseibeh

Requirements Engineering, by Merlin Dorfman

Requirements Development, Verification, and Validation Exhibited in Famous Failures by A. Terry Bahill and Steven J. Henderson