Requirements

Abstract

A requirement identifies an attribute, a capacity, a characteristic or a quality that a system should exhibit in order to have value for the users and customers. This chapter defines what is a requirement and presents the different types of requirements (functional requirement, non-functional requirement, user requirement, system requirement). The chapter ends with a discussion of several concepts related to requirements, such as functionality, use cases, service and feature.

Appendices

Further Reading

A characterisation about what is a requirement can be found in any book about requirements engineering or even software engineering. Sommerville (2010, Chap. 4) discusses the various types of requirements and presents illustrative examples. Robertson and Robertson (2006, Chaps. 4 and 5) discusses functional and non-functional requirements and also present various examples of those types of requirements. Pohl (2010, Chap. 2) defines the term ‘requirement’ and characterises the different types of requirements. Chemuturi (2012, Chap. 2) provides an interesting classification of requirements, based for example on functionality considerations, product construction considerations, or source of requirements.

In addition to the two classification schemes for functional requirements discussed in the chapter, there are other alternatives. The ISO/IEC 9126 standard is focused on quality, proposing quality attributes, divided in six main characteristics, for evaluating software products: functionality, reliability, usability, efficiency, maintainability, and portability. There are equally other proposals suggested by several authors, for example, Boehm et al. (1978); Roman (1985); Grady and Caswell (1987); Jureta et al. (2006); Meyer (2013), which demonstrates the lack of a consensus in the software engineering community with respect to this question.

The area of healthcare is heavily regulated, so the development of eHealth (healthcare practice supported by electronic processes and communication) must account for conventional health law. Purtova et al. (2015) presents an integrated approach to legal requirements engineering in the context of eHealth, bringing together a methodology for mapping existing legal and regulatory landscape and the strategies to interface the identified rules into design of the eHealth technology and processes. Bernsen and Dybkjær (2009) address how to develop and evaluate multimodal systems which are usable by people.

Exercises

Exercise 3.1 (Naveda and Seidman 2006, pp. 39–40) Which is the type of elements appropriate to be included in a requirements document?

• 1. design restrictions

• 2. product delivery constraints

• 3. functionalities to make available

• 4. performance characteristics

Exercise 3.2 (Naveda and Seidman 2006, pp. 33–34) Which is the type of requirements that should be included in a requirements document?

• 1. functional requirements

• 2. maintenance requirements

• 3. project requirements

• 4. performance requirements

Exercise 3.3 (Naveda and Seidman 2006, pp. 41–42) Which is the element that must be included in a requirements document?

• 1. acceptance/validation procedures

• 2. delivery plans

• 3. quality attributes

• 4. activities to guarantee the quality

Exercise 3.4 (Naveda and Seidman 2006, pp. 57–58) Which of the following arguments is the most solid/strong to justify the specification of the non-functional requirements of a system?

• 1. The non-functional requirements should only be considered in development contexts subject to tight restrictions (resources, budget, or deadlines).

• 2. The non-functional requirements are only external characteristics of the system and can be obtained later.

• 3. If a functionality is present in the system, the non-functional requirements determine how usable and useful it is.

• 4. The non-functional requirements take less time to specify than the functional requirements.

Exercise 3.5 Consider the following requirement:

• The system should be easy to use for trained persons.

 

• 1. Classify this requirement with respect to its type.

• 2. Is this requirement verifiable? Justify.

• 3. Rewrite the requirement so that it becomes measurable.

Exercise 3.6: Ghezzi et al. (1991, pp. 18–36) indicate the following qualities as being the most important for software products and processes: (1) correction, (2) reliability, (3) robustness, (4) performance, (5) facility of utilisation, (6) verifiability, (7) maintainability, (8) reparability, (9) evolvability, (10) reusability, (11) portability, (12) comprehensibility, (13) interoperability, (14) productivity, (15) actuality, (16) visibility.

• 1. Define each one of those 15 qualities in a succinct but rigorous way.

• 2. Classify each quality according to the three categories of non-functional requirements suggested by Sommerville (2010).

• 3. Classify each quality according to the eight types of non-functional requirements proposed by Robertson and Robertson (2006).

• 4. Bass et al. (1998, p. 76) divide the quality attributes of a software systems in two groups: (1) those that are observable in execution time and (2) those that are not observable in execution time. Based on that division, classify the 15 qualities among those two groups.

Exercise 3.7: Classify the following non-functional requirements according to the classification scheme proposed by Robertson and Robertson (2006):

• R1: The product shall be easy to use for persons that do not dominate the English language.

• R2: The product shall follow the new orthographic agreement for the Portuguese language.

• R3: The product shall be available 24/7/365.

• R4: The product shall be able to register 50,000 items per hour.

• R5: The product shall present the money values in the currency chosen by the users.

• R6: The product shall fit in a trouser pocket.

 

Exercise 3.8: The following text was obtained from a client that considers it as a good description of what is needed:

• (a) The project consists in a database to store historical information about the performance of the athletes of a given club. (b) Users will be able to know which were the original training sessions and (c) to compare them with the sessions actually performed. (d) The system will be easy to use to all coaches and (e) it will be accessible from all the workstations in the club. (f) The system will be developed in Java and (g) must have an acceptable reliability. (h) The system will produce at the end of each month updated information about all the athletes for the main coach. (i) The screen will show tables with the planned sessions versus. the sessions that were not initiated or completed, and (j) will estimate the date for concluding the project. (k) The system must be operating satisfactorily by December 2019 and (l) will be produced by the IT department, (m) under coordination of the engineering department. (n) The software must run in PCs and smartphones.

Classify the sentences (a) to (n) according to the following types: (i) User requirements, (ii) System requirements, (iii) Design elements, (iv) Plans, (v) Context information, (vi) Irrelevant details.