2. Fundamentals 13
2.3. Requirements Categorization based on a Formal System Model
Then, we can calculate this probability by PrΠ(∃s∈S:¬Ps) = 1−PrΠ(∀s∈S:Ps)
= 1−Πs∈SPrs(Ps)
= 1−Πs∈S(1−Prs(¬Ps))
= 1−((1−PrS1(¬PS1))·(1−PrS2(¬PS2))·(1−PrS3(¬PS3))
= 1−((1−0.01)·(1−0)·(1−0.1))
= 1−0.891 = 0.109
Thus, the requirement is not fulfilled by the set of systems S={S1, S2, S3}.
2.3. Requirements Categorization based on a Formal System Model
In this dissertation, we assess whether a categorization based on a system model is adequate1 for requirements found in practice and whether it effectively supports subse-quent development activities. To this end, we introduce in this section an approach for categorizing requirements based on the system model provided by theFocustheory [Broy, 2015, 2016]. We follow largely the presentation of Broy [2016].
Broy introduces an approach for categorizing system and software requirements with the goal to provide a sufficiently precise notion and models of adequate systems. He argues that current approaches that categorize requirements into “non-functional” and
“functional” are simplistic and not very helpful for classification. Furthermore, he argues that the challenge to characterize classes of functional and non-functional requirements depends on characterizations of the different kinds of observations made about systems captured and formalized in terms of adequate system models. To make these categories precise, he suggests to use structured views onto systems. In particular, he differentiates a number of viewpoints and levels of abstraction. One level addresses a functional view that is adequate to model functional requirements. Other level address more implementation-oriented, technical views onto systems, which then might help to address implementation-specific properties.
In essence, he distinguishes betweenbehavioral propertiesandrepresentational properties.
Behavioral properties subsume traditional functional requirements, such as “the user must be able to remove articles from the shopping basket” as well QRs that describe behavior such as“the system must react on every input within 10ms”. Representational properties include QRs that determine how a system shall be syntactically or technically represented, such as “the software must be implemented in the programming language Java”[Broy, 2015, 2016]. In the following sections, we introduce his categorization.
2.3.1. Categorization based on a System Model
For categorizing requirements, Broy follows a system-structuring and modeling-oriented approach. In particular, he uses the two following modeling frameworks:
2. Fundamentals
Syntactic Basis
Behavior
Logical Probabilistic
Syntactic interface Logical interface behavior Probabilistic interface behavior
Hierarchical data flow graph of subsystems
Subsystems and their logical interface behavior
Figure 2.8.: Overview of Behavioral Categories (Adapted from Broy [2016]).
• A system notion and a system modeling theory, supporting several fundamental system views such as theinterface view, thearchitecture view, and thestate view.
For these views, he distinguishes between (i) a logical view in terms of sets of observations and sets of instances of behavior and (ii) aprobabilistic viewin terms of probabilities of observations and instances of behaviors.
• A comprehensive system architecture, comprising a context view, a functional view, an architectural sub-system view, and a technical view including aspects of software, hardware, and mechanics as well as physical realizations.
2.3.2. Behavioral Properties: System Behavior
Behavioral views address the behavior over the interface of a system as well as the internal behavior6. There are two principal means to describe the internal behavior of systems:
state machines and architectures, both describing the system’s internal structure, state space, state transitions, the structuring into its sub-systems, their connection, relationship, and interaction. The state view is described by the states, given by the state space, which the system can take, the state transitions, and the probability that certain state transitions are taken. Figure 2.8 shows the proposed categorization for behavioral properties.
Functional Properties: Logical and Probabilistic Interface Behavior
In the functional view, the functionality of the system is specified by means of the interface behavior of the system. It is described by the interface behavior of the system and may include both logical and probabilistic views. As a result, we understand how the system cooperates with its environment exclusively considering issues of interactions.
In both these views we get the information, which interactions are possible in principle and what their probabilities are.
6Internal behavior in terms of architecture and state transitions which is hidden from the interface view by information hiding.
38
2.3. Requirements Categorization based on a Formal System Model
Behavioral Glass Box View: Logical and Probabilistic Behavior
The glass-box view addresses the internal structure and properties of systems. The glass-box view consists of two complementary views: the architectural view and the state view. They are complementary in the sense, that they describe a system’s architecture in terms of its set of sub-systems with their behavior and interaction and the system’s state space and state transitions.
• Architectural View: Structure, Logical and Probabilistic Behavior: In the architectural view, a system is decomposed into a hierarchy of sub-systems forming its components [Broy, 2010b]. The architecture describes how the compo-nents are connected and their behavior is described by the interface behaviors of the components in terms of their interactions. By the description of the behaviors of its components and the structure of the architecture the behavior of the architecture is specified from which the interface behavior of the system can be deduced. In the architectural view, we get a view onto the behavior of a system in terms of its sub-systems.
• State View: Logical and Probabilistic State Transitions: In a state view a system is described by a state machine [Vogelsang, 2015; Vogelsang et al., 2015].
The state space of the system is described and the state transition relation is specified including inputs and outputs. This yields a (probabilistic) Mealy machine extended to possibly infinite state space. The machine represents the logical state view.
2.3.3. Non-behavioral Properties: System Representation
Besides behavioral properties, there are non-behavioral properties of systems, including properties that refer to the syntactic representation of systems. For example, quality attributes such as the readability of code. A rich class of such properties is found in the technical views onto systems; for instance, this covers properties such as material or geometry.
In the behavioral categories, we describe by which modeling concept a system part is represented. For software, we may require the representation in a specific programming language or a specific coding standard, as for example the requirement “the software must be implemented in the programming language Java”. The technical view refers to a large extent to the question how a system is represented. Therefore, certain technical standards or specific devices might be suggested or even strictly required. The system model leads to a clear separation and categorization of properties into the following two categories of system properties:
Behavioral properties including probabilistic and logical behavior addressing interface, architectural, state transition, and technical views onto systems.
2. Fundamentals
Representation related properties that describe the way the system is syntactically or technically represented, described, structured, implemented, and executed (such as which programming languages are used etc.).
2.3.4. Summary of Broy’s Categorization
In summary, Broy provides a systematic requirements categorization according to three fundamental views:
Black-box Interface View In this view, the functionality of the system is specified by means of the interface and interface behavior in terms of the interaction over the system boundaries.
(Logical) Sub-system Structuring View This view contains logical and probabilis-tic properties at the level of architecture—including state views of state spaces and state transitions. This view is captured by architecture and architectural behavior or by state and state-transition behavior.
Representation View This view includes technical, physical, syntactical representa-tion, structuring, and implementation details.
For behavior, Broy further distinguishes between logical behavior in terms of sets of patterns of interaction and probabilistic behavior in terms of the probabilities for the patterns of interaction.
To demonstrate the idea, Broy further provides an estimation about the intensity of the relationship between a set of quality attributes and the proposed requirements categorization. He uses a set of quality attributes from Lochmann and Wagner [2012].
Figure 2.9 depicts this relationship; The rows represent the quality attributes and the columns the different views, separated in syntactic, logical, and probabilistic, where applicable. The intensity of the relationship is indicated by the color of the cell: from black (very strong) to white (none).
The table indicates that certain system properties are not referring to behavior directly but to aspects of representation, e.g., readability. Furthermore, there is a rich class of requirements that are mixtures of properties from several categories. According to his estimation, only a restricted set of the QRs is related to non-behavioral issues when using the proposed categorization.
40
2.3. Requirements Categorization based on a Formal System Model
Representational
Functional Suitability
Architecture State
Syntactic Logical Probabilistic Syntactic Logical Probabilistic Syntactic Logical Probabilistic
Usability Reliability
Security Safety Performance Maintainability
Reusability Releasability Executability Supportability
Interface Functional Properties
Figure 2.9.: Intensity of the relationship between quality attributes and modeling views.
The intensity of the relationship is depicted from black (very strong) to white (none) (Adapted from Broy [2016]).
“We are social creatures to the inmost center of our being. The notion that one can begin anything at all from scratch, free from the past, or unindebted to others, could not conceivably be more wrong.”
—Karl Popper
3 Chapter
Related Work
T
o set the scope of this dissertation, we discuss work related to requirements cat-egorizations, including a historical sequel. Furthermore, to get an understanding of how QRs are handled in practice, we further discuss empirical studies on QRs that analyze how practitioners deal with QRs. Related work concerning the specific topics of the chapters will be discussed in detail in each of the respective chapters.3.1. Requirement Categorizations
This dissertation is about requirements categorizations. Thus, in this section, we first provide a historical sequel to get an understanding on the reasons why there is a traditional distinction between functional and quality requirements. Then, to get an overview on requirements categorizations, we describe relevant categorizations and finally provide a critical discussion on categorizations.
3.1.1. Historical Note on Requirements Categorizations
In the early days of computer science, research was mostly concerned with handling very sparse computing and memory resources. The focus was rather on efficiently building computing machines than on designing programs. At that time, Zuse built the Z1 (in 1938), the first freely programmable computer which used Boolean logic and binary floating point numbers [Rojas, 1997]. Slowly, but steadily, the focus shifted from hardware design to also recognizing programming as a great challenge. In the early-1960s, first assembly languages were invented and subsequently, in the mid-1960, first universal