Requirements Engineering for Software and Systems

Phillip A. Laplante, Mohamad H. Kassab, Mohamad Kassab

• Publisher: Auerbach Publications
• Year: 2022
• Print ISBN: 9780367654528
• eBook ISBN: 9781000593815
• Edition: 4
• Topic: Computer Science
• Subtopic: Information Technology
• Index: Computer Science

Solid requirements engineering has increasingly been recognized as the key to improved, on-time, and on-budget delivery of software and systems projects. New software tools are emerging that are empowering practicing engineers to improve their requirements engineering habits. However, these tools are not usually easy to use without significant training.

Requirements Engineering for Software and Systems, Fourth Edition is intended to provide a comprehensive treatment of the theoretical and practical aspects of discovering, analyzing, modeling, validating, testing, and writing requirements for systems of all kinds, with an intentional focus on software-intensive systems. It brings into play a variety of formal methods, social models, and modern requirements writing techniques to be useful to practicing engineers. The book is intended for professional software engineers, systems engineers, and senior and graduate students of software or systems engineering.

Since the first edition, there have been made many changes and improvements to this textbook. Feedback from instructors, students, and corporate users was used to correct, expand, and improve the materials. The fourth edition features two newly added chapters: "On Non-Functional Requirements" and "Requirements Engineering: Road Map to the Future." The latter provides a discussion on the relationship between requirements engineering and such emerging and disruptive technologies as Internet of Things, Cloud Computing, Blockchain, Artificial Intelligence, and Affective Computing.

All chapters of the book were significantly expanded with new materials that keep the book relevant to current industrial practices. Readers will find expanded discussions on new elicitation techniques, agile approaches (e.g., Kanpan, SAFe, and DEVOps), requirements tools, requirements representation, risk management approaches, and functional size measurement methods. The fourth edition also has significant additions of vignettes, exercises, and references. Another new feature is scannable QR codes linked to sites containing updates, tools, videos, and discussion forums to keep readers current with the dynamic field of requirements engineering.

Chapter 1 Introduction to Requirements Engineering

DOI: 10.1201/9781003129509-1

Motivation

Very early in the drive to industrialize software development, Royce (1975) pointed out the following truths:

There are four kinds of problems that arise when one fails to do adequate requirements analysis: top-down design is impossible; testing is impossible; the user is frozen out; management is not in control. Although these problems are lumped under various headings to simplify the discussion, they are all variations of one theme—poor management. Good project management of software procurement is impossible without some form of explicit (validated) and governing requirements.

Even though the top-down design approach has been largely replaced by object-oriented design, these truths still apply today.

A great deal of research has verified that devoting systematic effort to requirements engineering can greatly reduce the amount of rework needed later in the life of the software or software-intensive product and can cost-effectively improve various qualities of the system. Too often systems engineers forego sufficient requirements engineering activity either because they do not understand how to do requirements engineering properly, or because there is a rush to start coding (in the case of a software product). Clearly, these eventualities are undesirable, and it is a goal of this book to help engineers understand the correct principles and practices of requirements engineering.

What Is Requirements Engineering?

There are many ways to portray the discipline of requirements engineering depending on the viewpoint of the definer. For example, a bridge is a complex system but has a relatively small number of patterns of design that can be used (e.g., suspension, trussed, cable-stayed). Bridges also have specific conventions and applicable regulations in terms of load requirements, materials that are used, and the construction techniques employed. So, when speaking with a customer (e.g., the state department of transportation) about the requirements for a bridge, much of its functionality can be captured succinctly:

The bridge shall replace the existing span across the Brandywine River at Creek Road in Chadds Ford, Pennsylvania, and shall be a cantilever bridge of steel construction. It shall support two lanes of traffic in each direction and handle a minimum capacity of 100 vehicles per hour in each direction.

Of course, there is a lot of information missing from this “specification” (e.g., weight restrictions), but it substantially describes what this bridge is to do and the design choices available to achieve these requirements are relatively simple.

Other kinds of systems, such as biomechanical or nanotechnology systems with highly specialized domain language, have seemingly exotic requirements and constraints. Still, other complex systems have so many kinds of behaviors that need to be embodied (even word processing software can support thousands of functions) that the specification of said systems becomes very challenging indeed.

Since the authors are primarily software engineers, we refer to that discipline for a convenient, more-or-less universal definition for requirements engineering that is due to Pamela Zave:

Requirements engineering is the branch of software engineering concerned with the 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 behavior, and to their evolution over time and across software families. (Zave 1997)

But we wish to generalize the notion of requirements engineering to include any system, whether it be software only, hardware only, or hardware and software (and many complex systems are a combination of hardware and software), so we rewrite Zave’s definition as follows:

Requirements engineering is the branch of engineering concerned with the real-world goals for, functions of, and constraints on systems. It is also concerned with the relationship of these factors to precise specifications of system behavior and to their evolution over time and across families of related systems.

The changes we have made to Zave’s definition are in bold. We refer to this modified definition when we speak of “requirements engineering” throughout this text. Though some may argue that the term “Requirements Engineering” is a misnomer, the term “engineering” serves as a reminder that RE is an important part of software/system development that is concerned with anchoring development to solve a real-world problem. We will explore all the ramifications of this definition and the activities involved in great detail as we move forward.

You Probably Don’t Do Enough Requirements Engineering

Research suggests that requirements engineering is not done well by the industry. For example, in a global survey of more than 3,000 practicing engineers (over 250 respondents), 37% responded that requirements engineering practices in their companies were less than satisfactory (Kassab et al. 2014). In a more recent survey (Kassab and Laplante 2022), the number has slightly decreased to 30%.

Stay Updated: For the up-to-date data from the RE state of practice survey.

https://phil.laplante.io/requirements/updates/survey.php

Another study of corporate IT projects performed by IAG Consulting found that of the companies surveyed, fully two-thirds of the respondents classified their projects as likely failures. The most frequently cited reason for failure by respondents was poor requirements gathering techniques (Kanaracus 2008). In a third study of seven embedded systems engineering companies in Europe, Sikora et al. (2012) found similar results; in particular, they concluded that “existing requirements engineering methods are insufficient for handling requirements for complex embedded systems.”

One potential reason for inadequate requirements engineering is suggested by Wnuk et al. (2011) who observed that companies seem to have difficulty in scaling up requirements engineering practices in terms of activity scope and the structure of requirements artifacts. In their survey, Sikora et al. (2012) found another possible reason for the apparent inadequacy in industrial requirements engineering. They found that practitioners desire “requirements specifications that are properly integrated into the overall systems architecture but are solution-free with regard to the specified function or component itself.” Survey respondents noted that existing method support is inadequate in supporting this goal. It seems, then, that requirements engineering has a long way to go in meeting the needs of practitioners.

The lack of proper requirements engineering practices is even more widespread in small businesses (Kassab 2021)—even though proper requirements engineering practices can mean the difference between survival or failure. We will return back to the discussion on requirements engineering in small businesses in Chapter 12.

What Are Requirements?

Part of the challenge in requirements engineering has to do with an understanding of what a “requirement” really is. Requirements can range from high-level, abstract statements, and back-of-the-napkin sketches to formal (mathematically rigorous) specifications. These varying representation forms occur because stakeholders have needs at different levels and hence depend on different abstraction representations. Stakeholders also have varying abilities to make and read these representations (e.g., a business customer vs. a design engineer), leading to diverse quality in the requirements. We will discuss the nature of stakeholders and their needs and capabilities in the next chapter.

Requirements vs. Features vs. Goals

A fundamental challenge for the requirements engineer is recognizing that customers often confuse requirements, features, and goals (and engineers sometimes do too).

While Goals are high-level objectives of a business, organization, or system, a requirement specifies how a goal should be accomplished by a proposed system. On the other hand, a feature is a set of logically related requirements that allows the user to satisfy the goal.

So, to the users of a “Smart home system,” one goal is to automate that which does not need human interaction, to free the occupants to enjoy themselves with other activities. This goal can be satisfied by implementing some features. One of these features could be by providing automated water purification to the system. Then, there will be a set of specific requirements to describe the water purification mechanism (see Appendix A). So, the requirements tend to be more granular than a feature and tend to be written with the implementation in mind.

To treat a goal as a requirement is to invite trouble because the achievement of the goal will be difficult to prove. In addition, goals evolve as stakeholders change their minds and refine and operationalize goals into behavioral requirements.

Requirements Classifications

There are many schemes available to classify requirements. We will discuss two popular schemes: Requirements Level Classification and Requirements Specifications Types.

Requirements Level Classification

To deal with the diversity in requirements types, Sommerville (2005) suggests organizing them into three levels of abstraction:

• User requirements
• System requirements
• Design specifications

User requirements are abstract statements written in natural language with accompanying informal diagrams. They specify what services (user functionality) the system is expected to provide and any constraints. Collected user requirements often appear as a “concept of operations” (Conops) document. In many situations, user stories can play the role of user requirements.

System requirements are detailed descriptions of the services and constraints. System requirements are sometimes referred to as functional specifications or technical annexes (a term that is rarely used). These requirements are derived from analysis of the user requirements, and they should be structured and precise. The requirements are collected in a systems requirements specification (SRS) document. Use cases can play the role of system requirement in many situations.

Finally, ...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Table of Contents
• Preface
• Acknowledgments
• Authors
• 1 Introduction to Requirements Engineering
• 2 Preparing for Requirements Elicitation
• 3 Requirements Elicitation
• 4 Writing the Requirements Document
• 5 On Nonfunctional Requirements
• 6 Requirements Validations and Verifications
• 7 Formal Methods
• 8 Requirements Specification and Agile Methodologies
• 9 Tool Support for Requirements Engineering
• 10 Requirements Management
• 11 Value Engineering of Requirements
• 12 Requirements Engineering: A Road Map to the Future
• Appendix A: Software Requirements Specification for a Smart Home
• Appendix B: Software Requirements for a Wastewater Pumping Station Wet-Well Control System
• Appendix C: Unified Modeling Language (UML)
• Appendix D: User Stories
• Appendix E: Use Cases
• Appendix F: IBM DOORS Requirements Management Tool
• Glossary
• Index