8 Requirements Engineering (RE)

R. Baskaran

 

The field of Requirements Engineering (RE) is relatively new, so it seems appropriate to begin by asking some very basic questions: What is RE all about? When is it needed? What kinds of activities are involved in doing RE? Our answers to these questions provide both a motivation and a scope for the techniques introduced in the remainder of the book. We will begin with the idea of a software-intensive system, by which we mean an inter-related set of human activities, supported by computer technology. The requirements express the purpose of such a system. They allow us to say something meaningful about ho w good a particular system is, by exposing ho w well it suits its purpose. Or, more usefully, they allow us to predict ho w well it will suit its purpose, if we design it in a particular way. The idea of human-centered design is crucial – the real goal of an engineering process is to improve human activities in some way, rather than to build some technological artifact.

 

Requirements engineering applies to the development of all software-intensive systems, but not necessarily to the development of all software, as we shall see. There are a huge range of different kinds of software-intensive system, and the practice of RE varies across this range. Our aim throughout this book is to explore both what is common and what varies across these different types of system. We will set the scene in this chapter by offering some examples of different types of system development, and indicate the role of RE in each.

 

Computer systems are designed, and anything that is designed has an intended purpose. If a computer system is unsatisfactory, it is because the system was designed without an adequate understanding of its purpose, or because we are using it for a purpose different from the intended one. Both problems can be mitigated by careful analysis of purpose throughout a system’s life. Requirements Engineering provides a framework for understanding the purpose of a system and the contexts in which it will be used. Or, put a not her way, requirements engineering bridges the gap between an initial vague recognition that there is some problem to which we can apply computer technology, and the task of building a system to address the problem.

 

In seeking to describe the purpose of a computer system, we need to look beyond the system itself, and into the human activities that it will support. For example, the purpose of a banking system is not to be found in the technology used to build such systems, but in the business activities of banks and day-to-day needs of their customers. The purpose of an online flight reservation system is not to be found in the details of the web technology used to implement it, but in the desire by passengers for more convenient ways of booking their travel, and the desire of airlines to provide competitive and profitable services.

 

Such human activities may be complex, because they generally involve many different types of people, with conflicting interests. In such situations it can be hard to decide exactly which problem should be tackled, and it can be hard to reach agreement among the stakeholders. Requirements engineering techniques offer ways of dealing with complexity, by systematically breaking down complex problems into simpler ones, so that we can understand them better.

 

For some types of software, we may already have an excellent understanding of the intended purpose, even before we start the project. For other types of software, the problem to be tackled may be simple to describe, even if the solution is not. In both these cases, requirements engineering techniques may not be needed. However, some problems look simple until we start to analyze them, and some people develop software systems thinking that they understand the purpose, but find out (eventually!) that they were wrong. So we need to first consider what type of projects need requirements engineering. We will begin with the idea of a software -intensive system, consider the importance of fitness-for-purpose, and take a closer look at complexity of purpose. This will lead us to a definition of requirements engineering.

 

To understand the scope of requirements engineering, we will consider the idea of a software – intensive system. By this we mean a lot more than just software – software on its own is useless. Software can only do things when it is run on a computer platform, using various devices to interact with the physical world. Sometimes this platform will be taken for granted.

 

For example, some software is designed to run on a ‘standard’ PC platform, meaning a particular combination of workstation, operating system, keyboard, mo use, printer and network connection. For other types of software, we may need to design specialist hardware or special configurations of hardware devices along with t he software. Either way, the hardware platform and the software together form a system, and we can refer to these software+hardware combinations as “computer systems”.

 

But we don’t mean just computer systems either – computer systems on their own are also useless. Computer systems can only do useful things when they are placed in some human context where they can support some human activity. This human context provides a purpose for the computer system. So me times this human context will be taken for granted – when computer systems are designed to be used in ‘standard’ contexts for ‘standard’ types of task. For example, web servers, email clients, word processors, and even aircraft autopilots are designed for relatively well-understood user groups, engaged in fairly routine activities.

 

Nevertheless, any new computer system will lead to some changes in the human activities that it supports. Effectively, this means the human activity system must also be (re -)designed along with the computer system. For example, if you design a new air traffic control system, yo u  must take care to design an appropriate set of roles and coordination mechanisms for the people whose work it will support. If yo u design a new web browser, yo u should consider the ways in which it will change ho w people access the web. This is because the computer and the human activities together form a system. This is what we call a software -intensive system.

 

The term ‘software-intensive system’ describes systems that incorporate hardware, software and human activities. But we chose a term that emphasizes the word ‘software’ because it is software that marks such systems as radically different from any other type of engineered system. So me of the principles we describe in this book apply to any engineering activity, whether computers and software are involved or not. But we concern ourselves with software – intensive systems because software presents so many special challenges. We will examine these challenges in more detail in chapter 3, when we look at engineering processes. In brief, the challenges arise because software is both complex and adaptable. It can be rapidly changed on- the-fly without having to manufacture replacement components. Software no w makes computer systems so compellingly useful that it is hard to find any aspects of human activity that have  not been transformed in important ways by software technology. And the design of software is frequently inseparable from the task of designing the human activities supported by that software.

 

An important observation is that the introduction of new computer technology into any human activities inevitably changes those activities, and people inevitably find ways of adapting ho w they use and exploit such technology. Thus, a cycle of continuous change is inevitable. We will return to the theme of continuous change througho ut the book.

 

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, asking them what they ‘require’ is not likely to be fruitful.‘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 the system. These people may have varied and conflicting goals.

 

‘Engineering’ suggests that RE is an engineering discipline in its own right, whereas it is really  a fragment of a larger process of engineering software-intensive systems. 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. It is true that in some projects, a great deal of care is warranted when writing specifications, especially if misunderstandings could lead to safety or security problems. However, in other projects it may be reasonable not to write detailed specifications at all. In many RE processes, it is the understanding that is gained from applying systematic analysis techniques that is important, rather than the documented specifications.

 

Despite these observations, we will use the term ‘requirements engineering’ to describe the subject matter of this book, because the term is no w well established, and because there are no better terms available. The term ‘engineering’ also has some useful connotations. Good engineering requires an understanding of the trade-offs involved in building a useful product, as perfection is rarely possible. These trade-offs also apply to the question of exactly which ‘practical problems’ one should attempt to solve – a decision that lies at the heart of requirements engineering.

 

Bear in mind that we are talking about software-intensive systems, and not just software. There are some types of software whose purpose is self-evident, and for which requirements engineering may therefore be unnecessary. Such software either does not form part of a software-intensive system, or has become such a standard component that its purpose is completely understood a priority. This is the case if a complete description of the interface between the component and its environment is available in advance, and can be treated as fixed during development of the component. If such a description is not available, then a requirements engineering activity will be needed to create one.

 

Importance of Requirements Engineering

 

One of the best-known investigations of the economics of software development was a series of studies conducted in the 1970’s by Barry Boehm. Boehm investigated the cost to fix errors in  the development of large software systems. Most of the projects followed a fairly standard sequence of phases: requirements analysis, design, coding (programming), development testing, acceptance testing and operation. Errors made in a particular phase cost more to fix the longer they are left undetected, so that, for example, a programming error that is not discovered until acceptance testing will cost ten times as much to fix than if it is found during programming. A requirements error not found until after delivery will cost a hundred times more to fix. The explanation is fairly simple – the longer a problem goes unnoticed, the more subsequent design decisions are based o n it, and hence the more work it will take to unpick them.

 

Boehm’s data invites a number of conclusions, the main one of which is that the strict sequence of phases described above (known as the waterfall model) may not be the best way to manage a large project – an iterative approach may be more suitable. We will examine this question in more detail in chapter 3. However, the conclusions concerning the relative cost of fixing errors do not necessarily depend on the order in which things are done, because the cost driver is not the length of time that an error goes undetected, but the number of other decisions that are  based on it. Errors made in understanding the requirements will always have the potential for greatest cost to fix, because so many other design decisions depend on them. Clearly, time invested in understanding the requirements early in a project can have a significant payoff.

 

Through the 1990’s, the Standish Group conducted a series of surveys of software development projects in the US, examining failure rates, and identifying critical success factors. In the initial study, in 1994, they found that only 16% of projects were successful. The survey defined a successful project as one that is completed on time and within budget, with all features and functions as originally specified. Note that this is a very strict definition of success – many projects may deliver a useful product that is a little late or over budget, say, or for which the original requirements have evolved during development. In the study, 53% of projects fell into this “challenged” category. However, the cost and schedule over runs were not small – among the challenged projects, there was an average 189% cost overrun and 222% time overrun.  Either project

 

We have characterized software-intensive systems as being embedded in the context of human activity, and it is this activity that gives them their purpose. Therefore, a study of human activities is a crucial part of requirements engineering. Througho ut this book, we will emphasize the importance of human-centered design. Rather than considering design to be geared to wards creating artifacts (machines, programs, devices, or even the ‘systems’ of systems engineering), human-centered design makes human activities the focus of the design process. The ultimate goal of all design processes is to change human activities to make them more effective, efficient, safe, enjoyable, etc. We may create new computer systems along the way, but these are only useful insofar as they support the human activities that we care about. Thus, human-centered design is not just the idea of making software more user -friendly, but represents a fundamental shift in perspective for what design is really about.

 

Requirement Elicitation Process

 

Requirement elicitation process can be depicted using the following diagram:

  • Requirements gathering – The developers discuss with the client and end users and know their expectations from the software.
  • Organizing Requirements – The develo pers prioritize and arrange the requirements in order of importance, urgency and convenience.
  • Negotiation & discussion – If requirements are ambiguous or there are some conflicts in requirements of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements may then be prioritized and reasonably compromised. The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic requirements are compromised reasonably.
  • Documentation – All formal & informal, functional and non-functional requirements are documented and made available for next phase processing.

 

Requirement Elicitation Techniques

 

Requirements Elicitation is the process to find out the requirements for an intended software system by communicating with client, end users, system users and others who have a stake in the software system development.

 

There are various ways to discover requirements Interviews

 

Interviews are strong medium to collect requirements. Organization may conduct several types

of interviews such as:

  • Structured (closed) interviews, where every single information to gather is decided in advance, they follow pattern and matter of discussion firmly.
  • Non-structured (open) interviews, where information to gather is not decided in advance, more flexible and less biased.
  • Oral interviews
  • Written interviews
  • One-to-one interviews which are held between two persons across the table.
  • Group interviews which are held between gro ups of participants. They help to unco ver any missing requirement as numerous people are involved.

 

Surveys

 

Organization may conduct surveys among various stakeholders by querying about their expectation and requirements from the upcoming system.

 

Questionnaires

 

A document with pre-defined set of objective questions and respective options is handed over to all stakeholders to answer, which are collected and compiled.

 

A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the issue might be left unattended.

 

Task analysis

 

Team of engineers and developers may analyze the operation for which the new system is required. If the client already has some software to perform certain operation, it is studied and requirements of proposed system are collected. Domain Analysis Every software falls into some domain category. The expert people in the domain c an be a great help to analyze general and specific requirements. Brainstorming An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis.

 

Prototyping

 

Observation Prototyping is building user interface without adding detail functionality for user to interpret the features of intended software product. It helps giving better idea of requirements. If there is no software installed at client’s end for developer’s reference and the client is not aware of its own requirements, the developer creates a prototype based on initially mentioned requirements. The prototype is shown to the client and the feedback is noted. The client feedback serves as an input for requirement gathering.

 

Team of experts visit the client’s organization or workplace. They observe the actual working of the existing installed systems. They observe the workflow at client’s end and ho w execution problems are dealt. The team itself draws some conclusions which aid to form requirements expected from the software.

 

Software Requirements Characteristics

 

Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.

 

A complete Software Requirement Specifications must be:

  • Clear
  • Correct
  • Consistent
  • Coherent
  • Comprehensible
  • Modifiable
  • Verifiable
  • Prioritized
  • Unambiguous
  • Traceable
  • Credible source Software  Requirements

 

We should try to understand what sort of requirements may arise in the requirement citation phase and what kinds of requirements are expected from the software system.

 

Broadly software requirements should be categorized in two categories: Functional  Requirements Requirements, which are related to functional aspect of software fall into this category. They define functions and functionality within and from the software system.   Examples –

  • Search option given to user to search from various invoices.
  • User should be able to mail any report to management.
  • Users can be divided into groups and groups can be given separate rights.
  • Should comply business rules and administrative functions.
  • Software is developed keeping downward compatibility intact. Non-Functional Requirements

 

Requirements, which are not related to functional aspect of software, fall into this category. They are implicit or expected characteristics of software, which users make assumption of. Non-functional requirements include –

  • Security
  • Logging
  • Storage
  • Configuration
  • Performance
  • Cost
  • Interoperability
  • Flexibility
  • Disaster recovery
  • Accessibility

 

Requirements are categorized logically as

  • Must Have : Software cannot be said operational without them.
  • Should have : Enhancing the functionality of software.
  • Could have : Software can still properly function with these requirements.
  • Wish list : These requirements do not map to any objectives of software.

 

While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.

  • User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is –

  • easy to operate
  • quick in response
  • effectively handling operational errors
  • providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below –

  • Content  presentation
  • Easy Navigation
  • Simple interface
  • Responsive
  • Consistent UI elements
  • Feedback mechanism
  • Default settings
  • Purposeful layout
  • Strategical use of color and texture.
  • Provide help information
  • User centric approach
  • Group based view settings.

 

Web Links

  • https://en.wikipedia.org/wiki/Requirements_engineering
  • http://www.tutorialspoint.com/software_engineering/software_requirements.htm
  • http://www.cs.toronto.edu/~sme/papers/2004/FoRE-chapter01-v7.pdf

 

Supporting & Reference Materials

  1. Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”, Fifth Edition, McGraw Hill, 2001.
  2. Pankaj Jalote, “An Integrated Approach to Software Engineering”, Second Edition, Springer Verlag, 1997.
  3. Ian Sommerville, “Software Engineering”, Sixth Edition, Addison Wesley, 2000.