142,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Serie: ISTE Invoiced
- Sprache: Englisch
Current categorizations of software requirements are highly ambiguous and inconsistent, mainly due to the lack of a clear, common framework for defining software elements and relevant environmental factors.
This book overhauls the traditional approach by proposing an innovative systemic method for categorizing and modeling software requirements. It introduces an unprecedented frame of reference, putting an end to divergent interpretations by precisely defining software elements and environmental factors. This framework forms an indispensable basis for all the other components of this approach: a redefinition of requirements, a hybrid categorization that combines several taxonomies and scales, a metadata model used to qualify requirements, and a multi-view model that represents all possible categories of requirements.
By adopting this new approach, professionals will be able to improve the clarity, precision and relevance of their specifications, and thus optimize the success of their software projects.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 203
Veröffentlichungsjahr: 2025
Ähnliche
Table of Contents
Cover
Table of Contents
Dedication Page
Title Page
Copyright Page
Introduction
PART 1: Literature Review
1 Case Study
1.1. E-commerce
1.2. Web application for an e-book distributor
2 Concept of Requirements
2.1. Requirements
2.2. Statements of requirements
2.3. Goals
3 Existing Scales of Requirements
3.1. “User–system” scale
3.2. “System–software scale”
3.3. “Goal–design” scale
3.4. Discussion
4 Existing Taxonomies of Requirements
4.1. “Requirement-domain property-assumption-definition” taxonomy
4.2. “Faceted” taxonomy
4.3. “Behavioral requirements-non-behavioral requirements” (BNB) taxonomy
4.4. “Fundamental categories-secondary categories” (FS) taxonomy
4.5. “Functional requirements-non-functional requirements” (FNF) taxonomy
4.6. Other taxonomies
4.7. Discussion
PART 2: SMART: A Systemic Approach to Categorizing and Modeling Requirements
5 Conceptualization
5.1. A new reference framework
5.2. New requirement definition
5.3. New scales and taxonomies of requirements
5.4. New hybrid requirements categorization
6 Operationalization
6.1. New requirements metadata model
6.2. New requirements model
7 Usage
7.1. Objectives
7.2. Usage scenarios
8 Evaluation
8.1. Comparison with Somerville’s approach
8.2. Comparison with Lauesen’s approach
8.3. Comparison with Robertson’s approach
8.4. Comparison with Van Lamsweerde’s approach
8.5. Comparison with Glinz’s approach
8.6. Comparison with Meyer’s approach
Conclusion
Appendix
References
Index
Other titles from iSTE in Science
End User License Agreement
List of Tables
Chapter 4
Table 4.1. Nature-based requirements categorization
Table 4.2. Representation-based requirements categorization
Table 4.3. Satisfaction-based requirements categorization
Table 4.4. Role-based requirements categorization
Table 4.5. Examples of requirements with their categorization
Table 4.6. Fundamental categories of requirements
Table 4.7. Secondary categories of requirements
Chapter 5
Table 5.1. Matrix (quality factors–requirements subjects)
Table 5.2. Matrix (compliance factors–requirements subjects)
Table 5.3. Cross-referencing of the UA scale with the BS2 scale
Table 5.4. Cross-referencing of the UA scale with the E2 taxonomy
Table 5.5.Cross-referencing of the BS2 scale with the E2 taxonomy. GS: generi...
Table 5.6.New hybrid categorization proposed in the SMART approach. A: softwa...
Chapter 6
Table 6.1.Basic RML schema adapted to the R2F framework and the hybrid catego...
Table 6.2. New V6 requirements model
Table 6.3. New V6 requirements model – endogenous views
Table 6.4. New V6 requirements model – exogenous views
Chapter 8
Table 8.1. Comparison with Somerville’s approach
Table 8.2. Comparison with Lauesen’s approach
Table 8.3. Comparison with Robertson’s approach
Table 8.4. Comparison with Van Lamsweerde’s approach
Table 8.5. Comparison with Glinz’s approach
Table 8.6. Comparison with Meyer’s approach
List of Illustrations
Chapter 3
Figure 3.1. Phenomena of the future software, its environment and requirements
Figure 3.2. Four-variable model
Chapter 4
Figure 4.1. Categorization of “faceted” requirements
Figure 4.2. Types of non-functional requirements
Figure 4.3. Organization of the SQuaRE series of standards
Figure 4.4. Quality model for internal and external quality
Figure 4.5. Quality operation model
Chapter 5
Figure 5.1. Dimension 1: requirements subjects
Figure 5.2. Software subject
Figure 5.3. Software operation environment subject
Figure 5.4. Software development environment subject
Figure 5.5. Dimension 2: requirements factors
Figure 5.6. Quality factors
Figure 5.7. Compliance factors
Figure 5.8. “User–analyst” requirements scale
Figure 5.9. “Business–system–software” requirements scale...
Figure 5.10. “Endogenous–exogenous” requirements taxonomy
Figure 5.11. Structural categorization of endogenous requirements
Figure 5.12. Taxonomy of exogenous requirements by requirement factors categor...
Figure 5.13. Requirements taxonomy by nature
Chapter 6
Figure 6.1. Requirements qualification
Figure 6.2. Requirement structure
Figure 6.3. Requirement statement structure
Guide
Cover Page
Table of Contents
Dedication Page
Title Page
Copyright Page
Introduction
Begin Reading
Conclusion
References
Index
Other titles from iSTE in Science
Wiley End User License Agreement
Pages
ii
iii
iv
ix
x
xi
xii
xiii
1
3
4
5
6
7
8
9
10
11
12
13
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
45
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
113
114
115
116
117
118
119
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
179
180
181
182
183
184
185
186
187
188
189
190
191
192
In memory of my dear mother, Batoul, whose love and pride is with me every day.
To my dear father, Habib, whose wisdom is my greatest inspiration.
To my wife, Asma, for her unwavering support.
To my children, Mohammed, Habib, Meriem and Batoul, the true gems of my life.
May this book be a tribute to my family and all my friends.
Series EditorJean-Charles Pomerol
Systemic Approach to Categorizing and Modeling Requirements
Azeddine Chikh
First published 2025 in Great Britain and the United States by ISTE Ltd and John Wiley & Sons, Inc.
Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licenses issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the undermentioned address:
ISTE Ltd27-37 St George’s RoadLondon SW19 4EUUK
www.iste.co.uk
John Wiley & Sons, Inc.111 River StreetHoboken, NJ 07030USA
www.wiley.com
© ISTE Ltd 2025The rights of Azeddine Chikh to be identified as the author of this work have been asserted by him in accordance with the Copyright, Designs and Patents Act 1988.
Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s), contributor(s) or editor(s) and do not necessarily reflect the views of ISTE Group.
Library of Congress Control Number: 2025933056
British Library Cataloguing-in-Publication DataA CIP record for this book is available from the British LibraryISBN 978-1-83669-007-8
Introduction
The increasing technological dependency of the business sector requires that investment in technical systems, and mainly in software, meet their expectations. As software is a strategic tool for these companies, it is imperative that they function in accordance with their requirements. Consequently, the importance of software requirements has increased for these companies and has become a means to anticipate which solutions they should adopt. As such, before implementing future software programs, priority should essentially be given to interpreting and understanding the objectives, needs and preferences, and even the beliefs of these companies (customers) and end-users.
Software development involves at least as much communication as computer science, but educational curricula and project activities are often more concerned with computer science rather than communication. It is sometimes not possible to understand that requirements elicitation is mainly a challenge of human interaction that is not yet automatable (Wiegers and Beatty 2013). Problems often inherent to the difficulty of interpreting and understanding needs, and translating them into well-specified requirements, are behind the cancellation of software projects.
Requirements analysis is a critical task in software development, which first requires studying the scope of the problem, with a view to developing a better understanding of the true goals, needs and preferences of customers and end-users. Unfortunately, many software developers, sometimes well versed, still struggle to understand, specify and manage software requirements. In addition, many users either do not want to express their real needs (retention problem), or cannot do so (communication problem), or they do not know how to do it (incompetence problem).
Although requirements were partially neglected in the former era of software engineering, they have received greater attention in recent decades. Software requirements engineering has actually become its own field of knowledge with its own stakeholders and activities but also with its own concepts, techniques, tools and methods. It can be defined as a coordinated set of activities for exploring, evaluating, documenting, consolidating, revising and adapting the objectives, capabilities, qualities, constraints and assumptions that the future system (system-to-be) should comply with, relative to the problems posed by the existing system (system-as-is) and the opportunities that new technologies make possible (Van Lamsweerde 2009). Its importance mainly stems from the role played by good requirements in achieving any successful software. However, although research in the field of requirements engineering is currently very active, it is still a long way from reaching state-of-the-art maturity in software engineering. The latter has a very long history compared to the former. The dominant trend in software engineering research has been to abstract programming constructs up to the requirements level, rather than propagating requirements abstractions down to the programming level (Mylopoulos et al. 1999).
The first step that we take toward changing this situation in requirements engineering is based on carrying out a diagnosis of its main causes. We actually consider that the current categorizations of requirements, which constitute the backbone of requirements engineering, suffer greatly from ambiguity and lack of coherence. To date, according to Broy (2018), a well-defined requirements categorization is still one of the inadequately solved challenges of requirements engineering.
We believe that this inadequacy is mainly due to the absence of a reference framework for the definition of software elements and the software environment to which the requirements refer. In fact, given the enormous complexity of modern software programs, we believe that it is impossible to properly identify and categorize their requirements without a thorough understanding of the following elements:
software and its development and operation environments:
software: composed of functions, data, user interfaces and technical interfaces,
necessary development environment: consists of the human support (developers), with two types of support, software and hardware – the procedural support for its development (development activities) and the cognitive context of its development (methods, techniques, artifacts and tools),
necessary operation environment: consists of the human support (end-users), with two types of support, software and hardware – the procedural support for its operation (operation activities of the encompassing system) and the cognitive context of its operation (concepts, goals and rules);
factors that affect software as well as its development and operation environments:
quality factors such as usability, reliability, safety and portability,
compliance factors to the various technological, economic and cultural constraints.
We are thus proposing a new systemic approach to categorization and requirements modeling, named SMART (Systemic Approach to caTegorizing and Modeling Requirements), which takes into account the previous elements to provide the following:
at the conceptual level:
a new R2F (requirements reference framework) framework, which makes it possible to precisely define all aspects related to the software and to its development and operation environments; these latter constitute the subjects of requirements as well as the quality and conformity factors that affect them. This framework provides a solid and necessary foundation for all of the following elements. Our hypothesis is that these other elements cannot be established in a systematic way without a logical and common frame of reference,
a new definition of requirements based on R2F,
a new hybrid requirements categorization, combining several taxonomies and scales, based on R2F;
at the operational level:
a novel requirements metadata model, grounded in RML (requirements metadata language) (Chikh
2017
), enables the qualification of requirements using multiple predefined metadata categories,
a new multi-view requirements model for representing all possible categories of requirements.
Both of these models are based on R2F and on hybrid requirements categorization of the conceptual level.
This book has allowed us to capitalize on our long-term hybrid experience in order to share it with our readers. It thus represents the culmination of no less than 20 years of experience; on the one hand, in the academic world, through master’s and doctoral courses (courses in software engineering and information systems and more particularly in software requirements engineering), the supervision of numerous doctoral theses and research projects as well as the publishing of several research articles on requirements engineering-related topics; on the other hand, in the industrial world, through software and information systems development studies and projects, namely for national and international design offices, ranging from analysis and design to implementation and testing.
The book is intended for readers with various profiles and needs:
(1) researchers and graduate and undergraduate students in softwareengineering or related fields such as information systems, Business ProcessManagement (BPM) and Business Process Reengineering (BPR) to furtherdevelop their theoretical and practical knowledge of requirements;
(2) developers such as analysts, designers, programmers and testers to beused as a guide in their software programming projects; (3) customers andend-users to better understand and be understood by developers; and (4) allinterested readers, both novices and experienced, in order to satisfy theirscientific curiosity about software requirements. Finally, the author assumesa minimum prerequisite for reading this book, recommending that the typicalreader most likely has followed basic teachings in software engineeringand/or information systems, or worked on a real requirements project.
This book consists of two main parts. After this introduction, the first part is dedicated to a literature review and comprises the following four chapters: the first chapter presents a case study; the second chapter defines the concept of requirement as well as other underlying concepts; the third chapter presents the scales of the requirements levels; and the fourth chapter presents the requirements taxonomies. The second part is dedicated to the new SMART approach and comprises the following four chapters: the fifth chapter which is dedicated to the conceptualization of this approach by proposing a new requirements reference framework called R2F, and the new hybrid categorization that results therefrom; the sixth chapter is dedicated to operationalization of this approach by proposing a requirements metadata model and a multi-view requirements model; the seventh chapter presents how this approach can be used through different scenarios; and the eighth chapter presents the evaluation of this approach by comparing it with existing approaches. Finally, the conclusion recalls the essential contributions of SMART and opens up some perspectives.
Although one is supposed to follow the order of the eight chapters while reading the book, readers should know that they are free to read it as a whole or in part, in any order, according to their needs and preferences.
PART 1Literature Review
1Case Study
The purpose of this chapter is to present a case study relating to B2B (business to business) e-commerce (EC) applied to books that will be used as a basis for the examples presented throughout this book. The online bookstore is a realistic case, easy to understand and fairly representative of software projects. We found inspiration in the features of existing software in this area.
1.1. E-commerce
E-commerce refers to transactions carried out electronically (Turban et al. 2015). EC is a major product of digital technologies, which enables the digitalization of products, services and information. It can be complete or partial depending on the physical or digital nature of its three main activities: orders and payments, order fulfillment and customer delivery.
The main motivation behind EC is its ability to provide companies with a strategic advantage that is essential for them to be more competitive. They can integrate distant and global markets to buy and sell at better prices and thus increase their profits. They are able to accelerate time to market to acquire a competitive advantage. They can improve the internal and external supply chain, as well as strengthen collaboration.
EC is hampered by resistance to new technologies, fear of being defrauded, integration with other IT systems which can be challenging, costly execution of orders, the confidentiality problem, the issues that rather vague regulations create, lack of trust in technology and unfamiliar business partners, difficulties in justifying the initiatives of EC and the lack of skilled labor in EC.
Although the order fulfillment process varies from seller to seller and product to product, it typically includes the following steps: payment and inventory verification, preparation for delivery, contacting customers and returning defective products.
The reformulation of this process through:
simplification of the supply chain through coordination between its different stakeholders;
more accurate inventories;
integration of new information technologies (Radio-Frequency IDentification (RFID), Electronic Data Interchange (EDI), extra-nets, etc.); will enable it to be more profitable.
Among the main types of EC transactions, we find B2B, B2C (business to customer) and C2C (customer to customer).
Ignoring the laws does not make e-sellers immune to a lawsuit or an accusation that could adversely affect their relationships with customers. One of the most controversial areas of EC is in solving international legal problems. International trade organizations strive to reduce trade barriers in areas such as price regulation, customs, tax issues and regulations on product specifications.
1.2. Web application for an e-book distributor
In order to clarify the new SMART approach and make it more realistic, we look into a case study relating to B2B e-commerce. The wholesale operation of an e-distributor to retail booksellers is the main focus. This case study will serve as a basis for all the examples employed in this book.
Publishers can sell directly to booksellers if the latter are large buyers. However, they generally prefer to use intermediaries (distributors) to distribute their books to large numbers of booksellers. E-distributors collect information about hundreds of thousands of books published by different publishing houses in their catalogs. While most of them sell at fixed prices, others offer quantity discounts, negotiated prices or organize auctions.
The chosen case study refers to a project to develop a new application, called “e-lib”, for selling books online to booksellers, through a (fictitious) e-distributor named “mylib”. The latter buys scientific books from publishing houses and then resells them to retail booksellers through an online store.
Implementing the “my-lib” online shop of the book e-distributor requires the construction of its website (application showcase), where the books are sold, and its integration with other existing information systems, such as “front-end” for taking orders and “back-end” for the execution of these orders. The store relies on an infrastructure supported by:
the employees responsible for its operation;
public policy and technical standards;
marketing and advertising;
security and payment logistics;
business partners (banks, insurance companies, tax authorities, etc.).
The online store includes the most common tools, namely, an electronic catalog, which can also be personalized by booksellers and allows them to achieve efficient purchases; a search engine that helps booksellers to quickly find books in the catalog; an electronic shopping cart to store the selected books until payment; electronic auction features to liquidate surplus book stocks; a payment gateway through which payment arrangements can be made; a delivery center where delivery arrangements are made; a customer relationship management (CRM) and partner relationship management (PRM) center. The key to user-friendly navigation for booksellers on the e-distributor’s website is to provide a mental map of a potential bookseller. Purchase decision support also includes tools such as comparison agents, recommendations, trusted verification sites and social networks, such as blogs and wikis. These are used for advertising to customers and for collaboration with partners.
The “mylib” e-distributor wants to replace its existing (fictitious) Windows application, called “win-lib”, with the new web-based application “e-lib” to ensure more efficient and more profitable online sales to a wider range of customers. The content of the specifications has been intentionally enhanced in order to cover the wide variety of requirements offered by the new SMART approach.
2Concept of Requirements
The purpose of this chapter is to define the notion of requirement and the underlying concepts. Developed by eminent academics and technicians, the definitions reflect the different points of view of the two antagonistic worlds of theory and practice.
2.1. Requirements
According to Westfall (2014), requirements can be defined as the “what” of a software product. They must be determined and approved by customers, users and suppliers of a software product before building the software.
According to Hood et al. (2008), a requirement is a statement identifying a capability, a physical characteristic or a quality factor that delineates a need for a product or process for which a solution will be sought.
Somerville defines the requirements for a system (in the sense of software) as the descriptions of what it is intended to do, the services it provides and the constraints of its operation. These requirements reflect customers’ needs for a useful system, such as controlling a device, placing an order or searching for information. According to Somerville, the term “requirement” is not used harmoniously in software development projects. In some cases, it designates an abstract, high-level statement of a system service or constraint, and in others it represents a detailed formal definition of a function of the same system (Somerville 2016).
In the following, Davis (1993) explains the reason for this difference:
If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not predefined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.
The IEEE 1220-1998 standard defines a requirement as a statement that identifies an operational, functional or design characteristic or constraint of a product or process, that is unambiguous, testable or measurable, and necessary for the acceptability of the product or process by consumers or internal quality assurance guidelines.
Every requirement aspect in this definition is explained by Hull et al. (2017) as follows:
Statement: although this term rather brings forward the textual expression of a requirement, the latter can also be represented in the form of a table such as Planguage (Gilb
2005
), a diagram such as those in UML (OMG
2003
), a formal notation such as Z (Spivey
1989
), VDM (Jones
1986
), LOTOS (Paterno and Faconti
1992
), B-method (Abrial
1996
) or domain-specific notations (Chaochen et al.
1991
). The essential thing in this aspect is to have a traceable and manageable entity, identified as a requirement.
