Systemic Approach to Categorizing and Modeling Requirements (eBook)

Azeddine Chikh (Autor)

eBook Download: EPUB

2025
242 Seiten
Wiley-Iste (Verlag)
978-1-394-37273-7 (ISBN)

Infos

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.

Azeddine Chikh is Professor of Computer Science, Director of the Computer Science Research Laboratory and Chairman of the Doctoral Training Committee in Computer Science at the University of Tlemcen, Algeria. He is also Chairman of the National Pedagogical Committee for the Mathematics and Computer Science academic domain in Algeria.

Textauszug

2 Concept 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.
• Product or process: comprehensive solutions include both products (objects built in response to requirements) and processes (procedures for the use of built objects). Requirements can therefore define both the process and the product. In addition, other requirements establish how the product should be developed, usually for quality control purposes.
• Operational, functional or design characteristic or constraint: there are many different types of requirements. Design characteristics cover performance, usability, safety, maintainability and many other qualities.
• Unambiguous: a requirement must lend itself to a clear and unique understanding that is common to all parties concerned.
• Testable or measurable: requirements are used to test whether the design or solution is acceptable. To this end, the requirement must be quantified, thus providing a means of “measuring” the solution against it.
• Necessary for the acceptability of the product or process: this highlights the multidimensional role that requirements play. They will be used to define what needs to be designed and developed, and also to define how the solution should be tested and accepted. They influence the early stages of the development process as well as the later stages during consumer acceptance or internal quality assurance directives: requirements originating from many sources, such as, but not limited to, customers, regulators, users and internal quality procedures.

The famous IEEE 610.12-1990 standard defines a requirement as (1) a necessary condition or functionality for a user to solve a problem or achieve a goal; (2) a condition or capability that must be fulfilled or that should be present in a system or system component to satisfy a formally mandated contract, standard, specification or other documents; or (3) a documented representation of a condition or capability as in (1) or (2).

Consequently, the requirements include not only the needs of users, but also those arising from general organizational, government and industry standards. Clearly, a requirement is a set of needs expressed by the user and various other stakeholders (general organization, community, government agencies and industry standards), which must all be met. Ideally, the requirements are design independent, showing “what” the system should do, rather than “how” it should be done. However, this is not always possible in practice. That is, the meanings of “what” and “how” are different from person to person (Davis 1990).

Other synonyms of the term “requirements” that are used in the real world are needs, constraints, expectations and aspirations (Hull et al. 2017).

Robertson and Robertson (2013) define a requirement as something that the product must do to support its owner’s activity, or a quality that it must have to make it acceptable and attractive to the owner. A requirement is created, either because the type of product requires specific functions and qualities, or because the customer rightly demands that this requirement be part of the delivered product.

Laplante (2018) states that the distinction between requirements and goals is a real challenge, mainly for clients and to a lesser extent analysts. According to him, a misunderstanding between the two will have very serious consequences. In fact, on the one hand achieving the goal will be difficult to prove and, on the other hand, the goals evolve as stakeholders change their minds and define goals with behavioral requirements. Laplante proposes to consider a goal as a high-level objective of a company, an organization or a system and a requirement as a specification of how the future system ought to achieve this goal.

2.2. Statements of requirements

Van Lamsweerde (2009) distinguishes between two types of statements: “descriptive” and “prescriptive”.

Descriptive statements express the properties of the system that are valid regardless of system behavior. Such properties usually hold due to a natural law or a physical constraint. Descriptive statements are in the indicative mood.

Prescriptive statements express desirable properties about the system that may or may not hold, depending on how the system behaves. Such declarations must be implemented by the system components. These are in the subjunctive mode.

The distinction between descriptive and prescriptive statements is essential to requirements engineering. In contrast to descriptive statements, prescriptive statements may be subject to negotiation or to searching for other alternatives.

2.3. Goals

2.3.1. Nature and definition of goals

Goals capture the different objectives that the system under consideration should achieve. The fact that this role has been acknowledged by researchers in requirements engineering has led to a new research avenue on the modeling and specification of goals, and a reasoning based on these to be adopted. This research, directed toward different applications, such as requirements development and verification or conflict management, assumes many forms: informal, qualitative and formal.

Zave and Jackson define a goal as an objective that the system under consideration must achieve. Goal formulations then refer to the properties that ought to be ensured via the system (Zave and Jackson 1997). These are optative statements, in contrast to indicative, and subject-delimited statements.

Typically, the system under consideration is analyzed within its organizational, operational and technical framework. Issues are reported and opportunities are identified. High-level goals are then identified and refined to address these issues and seize opportunities. The requirements are then developed to achieve these goals. This natural practice has led requirements documentation standards to include a specific document section dedicated to the goals that the system must achieve (ISO/IEC/IEEE 2018). More specifically, for automated information systems, goals can be used to link the future software to the management context (Yue 1993).

Van Lamsweerde (2001) states that goals:

• can be formulated at different abstraction levels, ranging from high-level strategic concerns to low-level technical concerns;
• cover different types of concerns: functional concerns associated with the services...

Produkt-Details

• Erscheint lt. Verlag: 22.4.2025
• Reihe/Serie: ISTE Invoiced
• Sprache: englisch
• Themenwelt: Mathematik / Informatik ► Informatik ► Theorie / Studium
• Schlagworte: hybrid categorization • Metadata Model • software elements • Software requirements • taxonomies
• ISBN-10: 1-394-37273-6 / 1394372736
• ISBN-13: 978-1-394-37273-7 / 9781394372737