Chris Rupp, Ellen Wolf The SOPHIST Set of REgulations

Transcription

Chris Rupp, Ellen Wolf
6
The SOPHIST Set of REgulations—
Psychotherapy for Requirements
■■ When
Wenn people
Anforderungen
formulatevonrequirements,
Menschen formuliert
consciouslywerden,
and unconfinden
sciously
bewussttransformations
und unbewusst Transformationen
happen, leading to statt,
incomplete,
die zudistorted
or
unvollständigen,
even erroneous
verzerrten
information.
oder sogar falschen Informationen
führen.
■■ Applying the SOPHIST Set of REgulations, based on the
approach “Neuro-linguistic
Programming
(NLP)“, en■■ therapeutic
Mittels SOPHIST-REgelwerk,
das auf
dem Therapieansatz
ables
you to systematically
detect and
remove
gaps and
dis-Sie
„Neurolinguistisches
Programmieren
(NLP)“
basiert,
können
tortions
in your
requirements.in Ihren Anforderungen
Lücken und
Verfälschungen
systematisch aufdecken und gezielt beheben.
■■ Treat your requirements step by step — these rules help you
really understand
the person Schritt
you are für
talking
to wants.
■■ to
Therapieren
Sie Ihrewhat
Anforderungen
Schritt
—
diese Regeln helfen Ihnen dabei, wirklich das zu verstehen,
was Ihr Gegenüber will.
115
6 The SOPHIST Set of REgulations
6.1
About the Phenomenon of Transformation—
Linguistic Effects
Requirements are formulated by many different stakeholders—
people with varying levels of prior knowledge, social background and
experience. This diversity is reflected in the requirements
and harbors the danger of loss of information, incompleteness or ambiguity. Against this background, the
following essential questions arise with the elicitation of
requirements:
■■ What does the stakeholder really mean?
■■ How do I get to know what the author of a requirement meant
when he or she was formulating it?
The meta-model
of language
Unfortunately, the answer is not as trivial as one would want it to
be. In order to solve this problem, we combined methods from
the disciplines of linguistics, computer science, psychology
and psychotherapy into a compilation of rules, our so-called
“SOPHIST Set of REgulations“.
In psychotherapy, building upon several of Chomsky’s theses, a model of human communication and mode of expression has been developed and fine-tuned. The psychologist and
professor for linguistics John Grinder and computer scientist and Gestalt therapist Richard
Bandler played a substantial role in this process. In the mid-seventies of the twentieth century,
it was their goal to develop a form of therapy which could effectively be learned and applied
by anybody and which was based on the premise that the therapist gains a deep understanding of the reality the patient perceives. In order to achieve this, the therapist has to find out
what exactly the client means by his statements.
6.2.1
Transformation Processes
Every analyst is confronted with requirements which describe an existing system or one
which is to be developed. When people describe a system , i.e. formulate natural-language
requirements, a transformation process (as shown in figure 6.1) happens.
Limited personal perception leads to
perceptional transformation.
Linguistic expression of personal knowledge
leads to representational transformation.
Software systems,
product, application,
business process etc.
Yet, before we delve into the Set of REgulations itself, we want to introduce you to its
theoretical basis neuro-linguistic programming (NLP). We will show you in which way
knowledge is step by step transformed on its way from perception of reality to
linguistic expression, leading to the well-known deficiencies of natural
language.
If you are a connoisseur of NLP or a
theory dodger, you
may go directly to
section 6.3.
You are familiar with these fundamentals or consider them too theoretical? No
problem. Skip directly to the descriptions of the first rules of the SOPHIST Set of
REgulations (see section 6.3), which we have successfully applied along with our
customers in a great number of projects. To make the rules easily applicable for you
in your daily work, we have focused on providing many examples. Moreover, you will find a
lot of tips and tricks from our project experience that will help you apply the SOPHIST Set
of REgulations.
6.2
This is the model of the model “language“,
i.e. it describes the model of language.
The Roots—
Neuro-linguistic Programming
The SOPHIST Set of REgulations is fundamentally based upon the meta-model of language
provided by the therapeutic approach neuro-linguistic programming (NLP) [Bandler75],
[Bandler94]. The rules of NLP help therapists to make people aware of their inherent intuition as to whether a sentence is “correct“ (linguistically: well-formed) or not.
In systems development, the requirements engineer can use similar rules to systematically
recognize and correct effects in natural-language requirements. One of the forerunners in
the development of approaches based on natural language was the linguist Noam Chomsky
[Chomsky65], who researched important fundamental linguistic concepts and described
these in his transformational-generative grammar (see article at
.sophist.de)
116
Figure 6.1: Transformation as possible destroyer of information
Starting point (left side in figure 6.1) is the reality to be described; the system which the
stakeholders actually require. On the right side, however, we see the system as it has been
described; those requirements which the system analyst gets to see in the requirements document. Between starting point and end point, there can be a (more or less massive) discrepancy
which arises due to complex, mostly unconscious transformation processes.
In order to close this gap between reality and linguistic expression, it is necessary for you as a
requirements engineer to know the different possible kinds of transformation. Only if you profoundly understand why reality has been “falsified“ or distorted in the requirements, you can
fathom the real requirements with specific questions in mind.
117
Every person can
only grasp a
fraction of the
whole reality.
Transformation processes result from our human nature. Every human being‘s perception is
influenced by their social character, their prior knowledge and their experiences. Psychologists
call this the “personal reality“. The personal reality has impact on the personal perception of
reality, so every person has their own idea of reality.
For example: we show the same library item, a book, to librarian A and librarian B. Librarian
A instantly captures the attractive layout with graphics that harmonize with the textual body
and loosen up the overall picture. Librarian B, on the other hand, perceives the same book in
a totally different way. He sees the clear structure of the work with introduction, body and
conclusion, easing the reader‘s understanding. He does not notice the appealing illustrations
at all. Both librarians have thus different images (as psychologists say: models) of the same
book—the same reality.
Yet, how can it be that librarian A solely concentrates on illustrations and layout whereas librarian B mainly notices the thematic structure? This phenomenon is what psychologists call
perceptional transformation. Each person unconsciously applies such transformations in
perceiving reality, depending on their personal reality.
We can draw an important insight for systems analysis from this:
the total knowledge about reality is always “distributed across several minds“ as every person
only perceives a fraction of the actual reality.
As a consequence, it is not enough to question only one librarian for a complete image of
the reality.
Every person
assumes a certain
basic knowledge in
others.
Interestingly, transformation can be found at another spot in the process from reality to
requirements. That is where personal knowledge is expressed in natural language (referred
to as “knowledge representation“ in figure 6.1). If you question librarian B on the structure,
he might say “very practical“, although he means the detailed structure with introduction,
body and conclusion. He therefore transforms his personal knowledge while expressing it in
natural language.
In the same way a person writing requirements or a person being questioned in an interview
transforms their knowledge in formulating requirements.
Focusing
As we have seen, there are two kinds of transformation processes:
Perceptional transformations occur since every person perceives reality in a different way and creates an individual image of it.
Simplification
Representational transformations occur due to a conversion that happens as soon
as a person expresses their knowledge (this image) in natural language.
Basically, transformations are not problematic. In fact, they are sometimes even vital, as we
will see later on. However, in requirements analysis, transformations are a crucial problem
as transformation possibly means a loss of essential information. It does make a difference
whether the librarian describes the book being divided into introduction, body, and conclusion or whether he calls the structure “very practical“.
118
In system development, such nuances can have extreme impact on costs. To counter this
impact, the transformations have to be reversed, and the requirements have to be enriched
with the lost information.
Transformation processes lead to loss and distortion of information
which you have to reveal.
However, the question arises whether it is possible at all to reverse these transformations. And
if yes, what does the requirements engineer have to do? First of all: only certain transformations may be reversed.
Perceptional transformation (reality  personal perception) cannot be undone as a person‘s
individual image cannot be easily influenced. Yet, this may change if the experiences and social structures of a person change. Regardless of this, each person can always only grasp a part
of reality.
Even if you would like
to sometimes:
do not treat your
stakeholders.
To compensate for perceptional transformations, the requirements engineer always has to
question several stakeholders on the same subject.
The different experiences and opinions resulting from questioning several persons do not
only prevent perceptional transformations, but also enrich every project. Emerging synergies
can lead to an overall better system to be constructed.
Representational transformations (personal knowledge  linguistic expression), on the other
hand, can fortunately be undone very well—provided the requirements engineer knows the
different kinds of transformations and their consequences exactly.
To eliminate transformations in knowledge representation, the requirements engineer can make
use of the SOPHIST Set of REgulations.
Representational transformations are also subject to research in linguistics. Linguists assume
that in their mind, every human being builds a complete linguistic representation of their
perception, which is called the deep structure . If the human then starts to talk or write,
they take a series of decisions concerning the form of the information to be expressed, thus
creating the related surface structure . From a set of transformations, they choose one specific
or, more often, several transformations to apply on the deep structure. In this way, the surface
structure develops.
This is the “transformed“ version of the original; it is what
the person stated when expressing their mind in language.
I. e. recognizing
and questioning
linguistic effects
This is the original;
it is what the person
had in mind before
expressing it in
language.
A sentence (a surface structure) is thus a different form of the “original“ (the deep structure)
in a person‘s mind. However, the surface structure may lack certain parts, or parts of it may
be distorted. From this assumption, the (linguistic) goal of requirements analysis is derived:
In order to achieve a complete and unchanged image of a stakeholder‘s personal reality,
the requirements engineer has to identify the deep structure of the respective
surface structure.
119
Reminder:
Neuro-linguistic
Programming
Linguistic effects
cannot always be
strictly assigned to
only one category.
The fact that people stick to certain rules in the construction of surface structures made
Chomsky assume that people‘s behavior in the creation of linguistic expression is driven by
rules. A possible (and plausible) set of rules was first presented in Chomsky‘s aforementioned
transformational-generative grammar.
In the following, we will describe the categories of transformation according to Bandler and
Grinder. These definitions are of purely linguistic nature, but can be applied to linguistic
effects in the context of requirements as well.
Similar to Chomsky‘s approach, we can define rules in system analysis as well, enabling a systematic discovery of transformations in requirements written in prose and in the customer‘s
statements. The requirements engineer wants to understand a part of the author‘s personal
reality, but only knows their linguistic surface structures. If the requirements engineer is then
able to determine the transformations applied, he or she may find by targeted questioning the
deep structure of what the author tried to express.
Deletion
6.2.2
Categories of Representational Transformation
Based on linguistic findings, Bandler and Grinder distinguish in NLP between three principal “types of remodeling“: deletion, generalization and distortion. This classification may
perhaps appear not to be disjunctive . It has, however, been tried and tested in practice and
been found useful.
In figure 6.2, these three categories are represented with graphical symbols. In the following
sections, we will use these symbols to assign the respective type of remodeling to each rule of
the SOPHIST Set of REgulations.
DELETION is an indicator for
incomplete information.
DISTORTION is an indicator for
statements falsifying reality.
The process of deletion reduces the information overload we are confronted with to an amount that we can handle. If we then convey information,
we unconsciously delete those parts we assume being “self-evident“ or
known by the receiver of the information.
By means of deletion, it is for example possible for us to filter out the
general vocal background noise within a room, so that only the voice of our
interlocutor reaches us consciously (selective perception).
Deletion is a process by which we selectively pay attention to certain dimensions
of our experience and exclude others. Deletion reduces the world to proportions
which we feel capable of handling [Bandler94].
This reduction may be useful in some cases; in requirements for a software system, however,
important information can be destroyed by it. For example, one librarian may say: “At the
end of each month, the accounts are debited with the incurring fees.“ Another librarian,
familiar with the working processes within the library, will probably be able to reconstruct
the deleted parts of this statement: “There are overdue fines to be paid by customers exceeding the loan periods.“ A listener not familiar with the deleted information, however, could
understand librarian A‘s statement in a totally different way.
Generalization
Generalization is a process in which a singular experience (parts of a personal model) is
transferred to similar or related issues and therefore taken as universal.
GENERALIZATION is an indicator
for erroneous generalizations.
Figure 6.2: Classification of linguistic effects
120
The human ability to generalize experiences is a process which can be crucial to
survive. An example of such a generalization is the painful encounter with a hot
stove from which a child generalizes correctly that all hot stoves are dangerous and
not only the one the child burned itself on. A less correct generalization would be the
fundamental fear of touching stoves (i. e. also cold ones) or the assumption that one
could only burn oneself on this particular one. What remains is the knowledge that
touching any hot stove will lead to unwanted burns; hopefully also caution towards
all stoves (as they may be hot).
121
6.3
Generalization is the process by which elements or pieces of a person‘s model
become detached from their original experience and come to represent the entire
category of which the experience is an example [Bandler94].
Generalization is helpful and makes sense in the context of systems analysis as well. However,
one thing is very important: you have to group the issues to be generalized very carefully, so
that the system behavior or attribute to be described matches your grouping.
Too strong generalization leads to global requirements for the system which probably are only
correct and suitable for a part of the system. Exceptions and error cases often become lost. For
example, the librarian could state that the IDs of all books belonging to the art section start
with ART. However, the art section also includes folios which due to their oversize do not fit
into the shelves and therefore have been stored in another place. These folios are tagged with
an ID starting with FOL. The librarian accidentally forgot this exception.
Distortion
Distortion is the process when reality is rearranged or even falsified, leading to a distorted
picture of an aspect of reality in the receiving person.
Distortion happens when a situation is described in expressions not suitable for that
situation. In this way, the situation is embellished or obfuscated, influencing one‘s
own perception or, although in most cases unconsciously, the receiver‘s perception.
The phenomenon of distortion makes it easier for a human being to integrate new
information into their personal worldview. Many a detail is changed a bit if necessary
to fit into an already existing image of a situation.
This is why we often change a piece of information or our perception in a way that
feels right to us. Each distortion is able to destroy a lot of information and is therefore
implicitly a deletion as well.
Distortion is the process which allows us to make shifts
in our experience of sensory data [Bandler94].
Distortions are a hard nut to crack for every requirements engineer as often he will not be
able to decide whether a statement has been worded correctly, whether it has been distorted
or whether the requirements engineer himself will be distorting it by his own perception. For
example, a librarian states that there shall be a blocking with every reservation. The librarian
distorts the fact, as he considers the “blocking“ as being self-evident and therefore expresses it
in a simplified way. However, it may be possible that the process consists of several complex
process steps.
122
How to Deal with Linguistic Effects
Each of the transformation categories mentioned (deletion, generalization and distortion)
results in certain so-called linguistic defects. Every effect may lead to low-quality requirements, yet not in all cases to a defect as well.
Whether a linguistic effect is a problem and should be corrected, depends on
many constraints. The level of detail you are writing requirements on is surely
an important factor.
Linguistic effects on the level of goals or rather generic requirements
(e.g. specification level 0 and 1, see chapter 3 “From the Idea to the
Specification“) are common and even not always preventable on
those levels of detail.
However, as there will be readers who will deal with your specification
only on these levels, it is necessary that information important for these readers will not be
destroyed by effects.
As a consequence, you should stick to certain rules even on specification levels
0 and 1:
■■ Always write your requirements in complete sentences.
■■ Always use active voice (see rule 1 in section 6.4.1).
■■ Use consistent terminology and avoid synonyms or homonyms.
■■ If you already have a glossary (see chapter 8 “Documenting Requirements“ and
chapter 7 “Templates“), use the terms defined in there.
■■ Express processes via main verbs.
Like to calculate, to
print, to export, to
transfer...
If you write very detailed requirements (from specification level 2 on), which moreover are to
become part of a contract for an external assignment, linguistic effects are far more harmful
and therefore should be analyzed and, if possible, eliminated. Even if your requirements are
syntactically well-formed , they may contain linguistic effects. It is now your task to discover
and correct these effects, provided the missing or distorted information is significant.
Grammatically correct
This is why we recommend applying the rules of the SOPHIST Set of REgulations basically
from specification level 2 on. From this level on you write more detailed requirements which
refine requirements from levels 0 and 1.
123
No matter what specification level you are writing requirements on, there is one basic rule
you should always adhere to:
For each specification level, there is one refinement of the basic rule stated above
(“Express processes via main verbs“) to be obeyed always:
■■ Always use only main verbs which are “good“ main verbs for the respective
specification level, as not every main verb is a main verb suitable for that
specification level.
Also apply the requirements template
introduced in Chapter
7 “Templates“.
On specification level 1, for instance, the use cases for the library system are defined, one
of which is dealing with customer management. Using a main verb, we name this use case
“manage customer“. The main verb “to manage“ is fairly suitable on specification level 1.
However, from specification level 2 on, we never use the main verb “to manage“ as is to far
too vague for the more detailed levels. Therefore, we need to refine the main verb “to manage“
by more detailed main verbs like “to enter“, “to save“, “to display“, which are suitable for
level 2.
If you want to avoid the occurrence of linguistic effects from the beginning on, use the
SOPHIST Set of REgulations constructively during the elicitation process and while
writing your requirements. Do you want to track down effects in requirements you have
already documented? Then we recommend applying the SOPHIST Set of REgulations
analytically .
Combine the Set of REgulations with the analytic methods from
Chapter 10 “Validation Methods for Requirements“.
And if you want to create a foundation for decision making based on a quality statement
about your requirements, measure the formal quality of your requirements using quality
metrics (see chapter 11 “Quality Metrics“), which substantially build on the rules of the
SOPHIST Set of REgulations.
Proceed riskdriven
E.g. from
specification level 2
on
You will find a ranking
of these in
section 6.8.
124
Basically, however, it should not be your goal to hone all requirements to a degree where they
are free from all effects. Concentrate on the information you require for the further process.
Investigate in particular those parts where missing or erroneous information represents the
highest risk for your project‘s success.
Play it safe: Apply the rules of the SOPHIST Set of REgulations the more intensely,
■■ the more detailed you write requirements,
■■ the more critical your system and therefore your project is .
Our experience shows that linguistic effects occur in differing frequency. This is why it is
important and advisable to concentrate in the first place on the group of perilous persistent
offenders.
6.4
The Application of the SOPHIST Set of REgulations—Requirements Laid on the Couch
Based on the theses of the linguist Noam Chomsky and the meta model of language, also a set of rules for system analysis can be created: the SOPHIST
Set of REgulations. It is based on rules every person applies unconsciously
when expressing themselves in natural language, i. e. in speech and writing.
With the help of the SOPHIST Set of REgulations, ambiguous, incomplete
and contradictory statements in requirements specifications can be detected
in a defined and systematic manner (analytical quality assurance). Knowing the transformation processes can be also applied preventively as means
of constructive quality assurance in the elicitation and documentation of
requirements (see chapter 10 “Validation Methods for Requirements“).
The SOPHIST Set of REgulations is a technique which enables
you to detect deletions, generalizations and distortions in
requirements and therefore to discover missing and
distorted information in requirements sources.
With each rule of the SOPHIST Set of REgulations, different linguistic effects can be selectively tracked down in a requirement. Needless to say that
although the rules in this chapter solely refer to requirements, they can be also applied to all
expressions in natural language, both oral and written.
Applying a single rule from the SOPHIST Set of REgulations is remarkably simple:
E.g. also semi-formal notations like
diagrams, tables or
figures including
natural language
Find signal word
■■ Step 1: Identify linguistic effects in requirements from signal words.
■■ Step 2: Analyze lost or distorted information with means of targeted
questioning.
■■ Step 3: Remedy linguistic deficiencies or errors in content by rearranging the
requirements using the answers given in order to eliminate effects.
Ask questions on the
signal word
Incorporate answers
Principally, the SOPHIST Set of REgulations is a compilation of rules. In our daily work,
however, we often consider it challenging to deal with such a bulk of rules if there is no order
defined.
125
Probably you know this, too: You are told by a colleague that there is some great compilation of rules and best practices which will help you increase the quality of your daily work.
Euphorically, you jump at this compilation and see that all rules are easy and understandable.
With the newly gathered knowledge you start your next task full of vim and vigor. And then
you find yourself frustrated and do not know how to best apply these, in fact, simple rules.
Surely, you ask yourself the following questions: Which specific steps should I take? With
which rule do I start, and do I really need all of them? In which order should I apply which
rules with what priority?
Our project experience shows that when checking a requirement you should always proceed
from the smallest (the parts of the sentence) to the biggest (the overall picture). Basically, you
go through the following steps requirement sentence by requirement sentence:
■■ 1. In the first place, check the single words (parts) of a requirements sentence in order to complete it step by step with significant, yet deleted information. Specific words in your requirement sentence are the signal words you
have to pay attention to. Each and every signal word points to a specific semantic effect. It is also the signal word that tells you which rule to apply.
■■ 2. Afterwards, check the whole requirement sentence in order to get rid of
unnecessary parts and to reduce it to its essentials. Information irrelevant for
the system or meaningless expressions only bloat your sentence and make it
unclear. Such sentence parts can be either separated from the requirement and
added as commentary or removed without loss of information.
1. Check the parts
of the sentence.
■■ 3. At last, check how the requirement sentence integrates into the overall
picture to be described. With this control mechanism, you can step by step
complete your overall picture—the big picture your requirements describe.
Take advantage of the information already given in the requirement sentence.
Is for example the specification of a certain system functionality or attribute
missing, so that the analyzed requirement sentence does not fit properly into
the overall picture? Here as well certain signal words will help you detect even
those functionalities or processes almost entirely deleted from the overall
picture.
2. Check the
sentence.
3. Check the
overall picture
The process described does sound fairly easy. Unfortunately, however, requirements analysis
is anything but trivial. Especially when applying the process constructively, you should keep
in mind that even when analyzing sentence parts you often not only enrich the analyzed
requirement sentence with missing information, but also encounter additional requirements
or will have to refine the requirement sentence. In this case, particularly a disciplined approach, processing requirement sentence by requirement sentence, is of utmost importance.
Otherwise you may find yourself shipwrecked quickly and will drown in the (partially huge)
waves of new requirements or even new processes.
We recommend here to write down the new or refined requirements, but to not yet analyze
them in detail directly. You should continue the analysis of the primarily explored requirements first. Subsequently, analyze the new requirements.
Figure 6.3: The process of applying the SOPHIST Set of REgulations
In the end, you probably will not be able to avoid all pitfalls of natural language. There is no
one and only guideline valid in all situations. Nevertheless, there is a pattern that has proven
itself during the application of the rules in several projects. You can see this process in figure
6.3.
126
If the signal word “to
save“ occurs, you have
to ask the typical “Wquestions“ for
“to save“.
If something is “green
in color“, then it sufficient to call it
“green“.
If data is saved after a “successful plausibility check“, the
negative case must
also be specified.
In interviews or
when writing requirements, always
stick to the
thread.
In the following, all rules of the SOPHIST Set of REgulations are presented in detail and
explained using many examples. Generally, the order in which the rules are presented here
reflects the order you should adhere to when applying them. For those readers who are
familiar with NLP we have marked each rule that can be reasonably assigned to one of the
transformation categories according to Bandler and Grinder with the respective symbol from
figure 6.2.
127
6.5
Checking the Parts of the Sentence
First, we concentrate on the single parts (words) of the requirement sentence to complement
it step by step with missing information.
6.5.1
Verb, but also nominalizations or
Checking the Processes light-verb constructions
If a process is described in a requirement with a process verb, additional information for this process verb has to be described as well.
Functionality process or activity
To limit the scope of interpretation for the process verb “to print“, for example,
you have to describe who wants to print what where, when and on what.
Similarly, the main verb “to transmit“ requires at least four complements to clarify its complete meaning in terms of who transmits, what is being transmitted, from where and to where
it is being transmitted.
Your language comprehension will give you an indication of the information a process verb
must be complemented with in order to be completely specified.
When checking process verbs, your main focus is on the functionality described in a requirement. The signal word you have to identify is therefore the process verb, in other terms: a verb
(or a form derived from the verb) describing a process.
For instance, in the requirement “The user password shall be entered at a terminal of the
library system“ , which is written in passive voice, it is unclear who it is to enter the password.
However, if you write in active voice, you have to nominate an actor or party responsible:
“The library user shall enter the user password at a terminal of the library system.“
This statement is already a bit clearer, but will not be a requirement for a system for a long
time yet. Here, there is solely a call for user action (and you will hardly want to test your user
during acceptance). Now derive the requirement for the system, i.e. the functionality the
system has to provide in order to enable the user to make the entry.
This may be, for instance, providing an input option for the user password: “The library
system shall provide the library user with the possibility to enter a user password at a terminal
of the library system.“
Step 2: Identify the demanded functionality
Now that the requirement is written in active voice, linguistic effects blurring the actually
demanded functionality can be easier identified if the functionality within the requirement
is described by a main verb.
Verbs which on their own are the predicate of a sentence, e.g. “to save“,
“to display“ or “to enter“.
Auxiliary verbs, on the other hand, are verbs like “to have“, “to be“, “may“
Rule #2: Express processes using “good“ main verbs.
Step 1: Check for active voice
A linguistic effect, namely the deletion of the actor, can be prevented if requirements are
formulated in active voice. If a requirement is expressed in passive voice, however, it has to
be transformed into active voice.
Vaguely formulated process verbs blur the functionality actually demanded.
Question the actually demanded functionality and express it using a “good“
main verb.
Rule #1: Write every requirement in active voice.
Check whether the requirement is written in active voice. If it is not, the
actor, i.e. the executing person or entity, has been deleted.
Ask for the actor and add the actor to your requirement by rewriting the
requirement in the active voice.
Who is to
perform the process resp.
to possess the attribute?
Autonomous system action
Interface requirement
Especially when writing requirements it is crucial to specify
the actor as it is important whether the activity is performed
by the system, the neighboring system or the user (cf. chapter
7 “Templates“). Thus, the requirement gains in information and the
process verb is detailed by stating who performs the process resp. has to possess a certain
characteristic.
Not all main verbs
are “good“ main verbs
on all specification
levels, like “to manage“
or “to validate“.
What
For example, if you question the vague phrasing “indicate
functionality is really demandcomprehensive information“ in the requirement “In a
ed? What is the MAIN
search for a certain library item, the library system shall inVERB?
dicate the librarian comprehensive information on the library
item found“, you will probably find that that the system functionality
actually demanded is “to display“. By rephrasing with the main verb “to display“, it quickly
becomes clear that more information has to be explored in order to describe the main verb
completely. When rephrasing the requirement, you have to answer at least the question what
exactly shall be displayed .
This will be covered with rule #6.
Subsequently, define the main verb in your list of
process verbs (see chapter 7 “Templates“).
User interaction
128
129
From specification
level 2 on, please do
not use main verbs
like “to check“, “to
manage“ or
“to cancel“.
This will be covered with rule #17“.
After including the answers to the questions, the improved (yet still far from perfect) requirement could read as follows: “After the library system has completed the search for a library
item, the library system shall display all master data available for this library item for the
librarian.“
Strictly speaking, the process description “check plausibility“ in the requirement “After the
library system has completed the search for a library item, the library system shall display all
master data available for this library item for the librarian.“ iis also a vague process description. The process “to check“ does call for the description of a verifiable result, e.g. “to save
data“ or “to display error message“. Therefore, the requirement has to be rephrased: “After
the librarian has initiated the saving process for a new customer, and if the age of the newly
entered customer is greater than or equal to 18 years, the library system shall save the data of
the newly entered customer.“
As a consequence of rephrasing the requirement, you have to make a precise distinction
of cases. You have to describe in detail which behavior the system shall exhibit in case of a
certain condition or combination of conditions. Of course you will now have to describe the
other possible cases of the above requirement as well.
However, it is not always this easy to reveal the palpable functionality demanded. Some
requirements are affected by linguistic effects to an extent that the process to be specified is
totally obfuscated. It is then up to the requirements engineer to identify the palpable process
and state it precisely. Typically, processes can also be found in the form of “nominalizations“
or “light-verb constructions“.
Nominalizations
A process (which often may last for a long
time) is distorted to a (one-time) event.
Nominalizations are nouns which reduce complex processes that would be elaborate to
describe in detail to one word (one “nominalized verb“). Due to this transformation, a large
amount of important information required for the description of the process is lost. In linguistic analysis, all nominalizations are identified and analyzed.
Look out for signal words like “reservation“, “registration“
(and also “requirements engineering“).
Rule #3: Clear nominalizations
Nominalizations can blur a whole process.
Analyze each nominalization and check whether the process is described in
a sufficient manner somewhere else within the requirements specification.
If this is not the case, you have to deal with the nominalization by:
■■
■■
130
Writing one or more requirements, each with a “good“ main verb OR
Creating a new glossary entry.
If you analyze the requirement “The system shall allow for
Is the
archiving.“ , for instance, you will find that the noun
noun
a
nominalization?
Which
“archiving“ is a nominalization. Thus, you have to quesexact
process
is
meant
by
it?
tion the stakeholder‘s genuine intention. The process to
be covered by that requirement will, expressed as main
verb, probably be “to archive“. An improved requirement,
answering the question about “What is to be archived?“, could then be the following:
“The library system shall archive the data of library items which have been sorted out.“
In the example requirement “At the return of a reserved library item, the library system
shall send a notification to the customer who reserved the item.“ the words “return“ and
“notification“ are both nominalizations which have to be analyzed.
What happens during the “return“?
When and by whom is the “return“ initiated or terminated? Which error or
exceptional cases may occur within the “return of a library item“?
If all information needed to answer the question is already written down in the requirements
specification, the above requirement may remain almost unchanged. Only if the nominalizations “return“ and “notification“ blur processes which are not entirely specified or defined
yet, the missing information has to be added to the specification.
If a nominalization distorts a (possibly complex) process, the process usually has to be
described with all steps included by a set of suitable requirements, as well for the expected
standard behavior as for the behavior in exceptional cases. In the above requirement, the
“return“ of a library item could possibly consist of the following steps: “choose library item“,
“change status of the library item“, “refresh customer‘s number of library items borrowed“ ...
To describe this process, a number of requirements is needed. In the next step, you have to
check whether these requirements are already specified in the requirements specification. If
not, you have to add these requirements. In accordance to rule #2, you first have to identify
the main verb for each nominalization blurring a functionality (like “to choose“, “to change“,
“to refresh“) and then to analyze it in detail (see Rule #6). If for the library system the “return
of a library item“ is not specified yet, this means the introduction of a new use case “return
library item“ as well.
Resolving a nominalization most often
results in several
additional
requirements.
Questioning a
nominalization often
uncovers a completely
deleted use case.
Basically, it is not our goal to avoid or prohibit all nominalizations in requirements.
Play it safe: Always try to resolve nominalizations and to express the process obfuscated by the nominalization using main verbs. Be sure only to use nominalizations if
■■ Using the nominalization is justified by the professional context,
■■ The term is defined in a place accessible to all people involved,
■■ The definition of the nominalization leaves no space for interpretations.
131
Among others, nominalizations are sometimes used to describe an object involved in the
process rather than the process itself. If you have defined the nominalized term unambiguously, there is no reason not to use the term in your requirements. An example of such a case
in our library system would be the term “notification“, as the “notification“ in the context of
our above example requirement would represent an object to be sent.
If you use nominalizations in your requirements to name processes, we recommend appending the word “process“ to each of these nominalizations, thus unambiguously labeling it a
process. In doing so, you can also avoid using the same nominalized term for different things
that should be distinguished from each other, like an object associated with a process and the
process itself.
E.g. the “notification process“
Light-verb constructions
Look out for signal
words like “to put at
one‘s disposal“, “to
bring to an end“ or
“to be in operation“.
E.g. the “notification“
Often, a system‘s functionalities are described by so-called “light-verb constructions“.
Light-verb constructions are combinations of verbs which are lacking substance (to do, to be
able, to have, to be etc.) and qualifying nouns.
Rule #4: Analyze light-verb constructions.
Light-verb constructions can obfuscate a whole process.
Analyze the light-verb construction and write a new requirement for each
demanded functionality, using a “good“ main verb to describe the system
behavior.
Is the
process described by a light-verb
construction? Which specific process is
meant by it?
The strong connection between verb and noun in
light-verb constructions causes the actual process
to fade into the background completely. It becomes only visible if the light-verb construction
is analyzed and the functionalities essential for the
process are described using main verbs.
What exactly does
“to experience a
change“ mean?
In the example requirement “After a library item has been borrowed, the status of the
library item must experience a change.“, the light-verb construction “to experience a
change“ hides the incompletely specified main verb “to change“. An improved requirement
could read like this: “After the library user has borrowed a library item, the library system
shall change the status of the library item to the status “borrowed“.
We have listed resolving light-verb constructions as a separate rule within the SOPHIST Set
of REgulations, as we have experienced that they may, similar to nominalizations, blur not
only one or several functionalities, but even a complete use case. Thus, in the requirement
“Statistics should be put at the librarian‘s disposal.“ the light-verb construction “to put at
one‘s disposal“ could include the processes “to create“, “to display“, “to print“, “to import“
and many others.
Light-verb constructions are often applied if the main problem of the person requiring
something is that they do not exactly know yet what they will want and need in the future.
Our librarian knows that he will need statistics, but he is still not sure in which way this
functionality should be implemented. In this case, it is your responsibility as a requirements
engineer to support the requiring person in stating the functionality more precisely. This
means, for example, taking a deeper look at the functionality by letting the requiring person
answer the five W-questions (see rule #6).
The question “In what form must the statistics be provided?“, for example, could reveal that statistics have to be provided in electronic form as well as printed on paper. Moreover, the source of
the statistics needs to be defined. An improved requirement could read like this: “The library system shall provide the librarian with the possibility to create, view and print statistic evaluations“
Step 3: Split up into separate requirement sentences
Up to now, we have identified the functionality demanded within a requirement and transformed it into at least one main verb. Revealing the required functionality has in some cases
led to an original requirement now containing several main verbs. Different functionalities
expressed by main verbs, however, usually need different additional information. At least for
analyzing this additional information, you should create several requirement sentences to
cover those different functionalities.
Or stakeholders
simply describe processes they do not
really know.
Right! This is a nominalization which has
to be analyzed more
deeply in
accordance to
rule #3.
Reminder: A requirement can consist of one or
more requirement sentences.
Rule #5: Write exactly one requirement sentence for
each process verb.
Each process verb (main verb) is usually described completely by different
information (parts of a sentence like the subject, objects and complements).
Identify the process verbs (main verbs) within the requirement and formulate for each identified process verb one requirement sentence containing
exactly one main verb.
If you, for example, split up the requirement “The library
system shall provide the librarian with the possibility to
enter and save data of a new customer.“ , the result will be
the following separate requirement sentences:
How many
process verbs does the
requirement contain?
“The library system shall provide the librarian with the possibility
to enter data of a new customer.“
What exactly does “to put at one‘s disposal“ mean?
132
133
Advantages:
Requirements can be
better prioritized,
ranked and understood.
Disadvantages:
Pieces of information belonging together are scattered around
several requirements and are
harder to manage.
As we have split the sentence up, we now have exactly one sentence for each demanded
functionality. Each of these sentences can now be separately analyzed in a systematic way by
questioning its main verb (rule #6).
Further information on how to separate requirements can be found on our website,
www.sophist.de/en.
Step 4: Check for incompleteness in process verbs
To describe a process in a requirement unambiguously, it is necessary that all information
needed to explain the process verb (main verb) in full detail is covered by the requirement.
If there remain questions regarding the process, then this information has to be revealed and
added to the requirement.
Rule #6: Analyze missing information on the process verb
Analyze the requirement‘s process verb using the typical W-questions. In
case you find yourself unable to answer all W-questions with the information provided in the requirement, then information has been deleted.
If the missing information is relevant, add it to the requirement.
In order to correct linguistic effects in requirements, the requirements engineer poses targeted
questions on all aspects of the process verb. The answers to these questions provide information necessary to eliminate a defect. In our experience, at least the following questions should
be discussed and answered in the requirement:
Object:
On or using who or what is the
functionality executed?
Frequency:
How often is the functionality executed?
For example, you would have to question the main verb “to display“ in the requirement
“Customers who are not authorized are displayed by the system.“
Some question can be more or less answered with information given in the requirement. The
answer to the question “What is to be displayed?“, for instance, will probably be: “a message
on non-authorized customers“. On the other hand, several questions remain unanswered:
“To whom will be displayed?”, “How will be displayed?“, “When will be displayed?“, “How
often will be displayed?“. Here we have linguistic effects which call for a deeper analysis.
If the deleted information is of relevance, you need to complete the requirement with this
information.
After having incorporated the answers to the questions into our requirement, its improved
version could read like this: “After the library system has checked the customer‘s library card
and if the customer is not authorized to borrow the library item, the library system shall
display to the librarian the error message “Customer not authorized“.“
Another example of an effect-ridden requirement is the following: “The user shall be able to
search.” This requirement as well leaves a lot of questions around the main verb “to search“
unanswered. Yet, the requirement has to answer them. What can be searched? How often can
be searched? With which criteria can be searched? When resp. under which conditions can
be searched?
Correcting the incompletely specified process verb can lead to laborious rephrasing of the
requirement. Often, the answers to the questions result in additional requirements. Another
possible result is that you find that the original requirement has to be refined by several
detailed requirements which replace it.
Let‘s put it in a nutshell. Along the steps depicted in figure 6.4 you have phrased your
requirement(s) in active voice. All functionalities to be specified have been described usClear light-verb
constructions!
ing main verbs, and all open questions regarding
the process
verb have been answered and
integrated into the requirements.
Express vague process verbs
Clear
usingnominalized
main verbs!
processes!
Time/Logic:
When resp. under which conditions is the functionality executed?
By means of these questions you can determine whether the process verb is sufficiently specified or whether the requirement has to be completed by further information.
For what?
How often?
With which criteria?
When?
The four steps for checking the process
Write exactly one requirement (sentence) for
each main verb!
Method:
How is the functionality executed (not in
terms of technology, but in its professional
context)?
What?
(To) whom?
How?
When?
How often?
Write every requirement in active voice!
Analyze missing information
on process verbs!
Figure 6.4: The four steps for checking processes
134
135
However, we are only half way to the perfect requirement.
An improved requirement (though still far from being free of effects) could read like this:
“The user interface of the library system shall be intuitively operable for the librarian.“
6.5.2
Often, we find non-functional aspects in functional requirements. Those are described
by adjectives which either come as attribute of a noun or are modifying verbs (adverbs).
Checking Characteristics
Similar to the descriptions of processes, characteristics have to be described unambiguously and completely as well.
The characteristics of a system refer to the description of non-functional aspects of
the system to be described. In requirements, characteristics are mainly described
with adjectives and adverbs. For the description of system characteristics, however,
only an adjective or adverb will not be sufficient.
Like big, important, understandable, quick
Like here, yesterday,
differently.
There is further information that has to be added to the characteristic. The adjective “secure“,
for example, needs the information what has to be secured, who or what it has to be secured
against, who secures and how this has to be done. Here as well it is your natural feeling for
language which helps you find missing or distorted information.
When checking adjectives, your main focus is on the characteristic of the system described in
a requirement. The signal word you have to identify is an adjective or an adverb, which is a
word describing a characteristic or a condition in further detail.
Look out for signal words like
“quickly“, “high-performance“, “big“,
“low“
Step 1: Analyze the demanded characteristics
In order to complete a description of a characteristic within a requirement, you have to
uncover the information relevant for the characteristic and add it to the requirement (similar
to rule #6).
Rule #7: Analyze missing information
on the adjective or adverb.
Question the adjective or the adverb with the typical W-questions. In case
you find yourself unable to answer all W-questions with the information
provided in the requirement, then information has been deleted.
E.g. a “quick“ transmission
E.g. to transmit something “quickly“
To uncover non-functional aspects in functional requirements, extract those from the functional requirements, so you can analyze them separately.
If you apply rules #1 to #6 to the requirement “Quick printing of the library card is necessary“ , the result could read as follows: “After the library system has saved the registration data
of a new library user, the library system shall print the library card of the newly registered
library user quickly“.
The claim for “quick printing“ indicates that the printing process shall be completed in a
certain amount of time. In a first step, we can derive the following non-functional requirements from this: “The library system shall complete the printing process of the library card
quickly.“ Obviously, this does not answer the question on the palpable time behavior of the
printing process: “What exactly does “quickly” mean?“ We have formulated a separate rule
for the analysis of this kind of linguistic effects.
“fastest“, “biggest“, “lowest“.
“better“, “faster“, “easier“.
This rule says that adjectives or adverbs in requirements frequently describe comparatives or
superlatives . Yet, comparatives and superlatives always require a concretely specified point of
reference as additional information. The comparison “faster“, for example, needs information
on how much faster than what something has to be or how fast exactly it has to be.
Rule #8: Formulate comparisons and superlatives in a way that
they can be measured or tested.
Comparisons and superlatives always need a point of reference in order to
be fully described.
Question the point of reference of the comparison resp. the superlative and
complete the requirement with the deleted information.
If the missing information is relevant, add it to the requirement.
For whom
or what is the demanded
characteristic? When resp. under
which conditions?...
For whom shall the library system be intuitively operable? What exactly shall be intuitively operable?
In the requirement “The library system shall be intuitively
operable.“ , for instance, you should question the characteristic ”intuitively operable“. The linguistic effects have to be
analyzed in more detail. Relevant information has then to be added to the requirement.
136
Of course, any deviation from the requirement has to be
measurable and testable as well. As a consequence, the
means of measuring should be known, thus enabling
any person writing requirements to assure that a requirement can be tested afterwards.
Referring
to resp. in comparison with whom
or what? How can fulfillment resp.
deviation be measured?
In many cases, it makes sense already to deal with the
measuring accuracy.
137
In the requirement “The library system shall manage the user data securely“ , for instance,
you have to analyze the point of reference of “securely “ and add the information gained to
an improved requirement.
■■ Secure in relation to what resp. secure from whom?
■■ What makes customer data secure?
■■ By which criteria can secure be tested within acceptance?
Based on the answers to the question, the improved requirement could read like this:
“The library system shall be designed in a way that it meets the guidelines for data security
of standard X.“
The difficulty of correcting incomplete comparatives and superlatives can vary. In the above
example, the point of reference can be added through a slight modification of the requirement. In our next example requirement, on the other hand, the phrase “intuitively operable“
is hardly measurable, if at all: “The user interface of the library system shall be intuitively
operable for the librarian.“ This requirement would need elaborate rephrasing, with the
introduction of new, measurable criteria. In a first step, however, we need to question the
desire behind a stakeholder‘s phrase “intuitively operable“.
■■ Intuitively operable in relation to what?
■■ What makes a user interface intuitively operable?
■■ Which yardstick can be applied during acceptance?
It can be helpful to
question characteristics in a paradox way,
e.g.: How does a system have to be designed to be NOT
“intuitively
operable“?
This stakeholder surely had some very specific things in mind when writing this requirement
. The desire behind such a formulation could be, for example, a wish for a help system that
can be consulted during user interaction, containing several levels of detail with information
on possible input values, reactions and exceptional conditions of the action. However, it
could also mean a request for menu navigation, an interactive tutorial, speech recognition,
multiple-language navigation or conformity to established user-interface standards. It may
also be that the desire underlying this requirement is as simple as this: “The library system
shall be designed in a way that the librarian can complete each lending process within ‚5
clicks‘.“
It is definitely worthwhile to explore this and to replace such effect-ridden requirements with
more detailed ones.
Step 2: Check for possible separation of
non-functional requirements
Not negligible, yet often neglected is the separation of functional and non-functional requirements. In project reality, we often experience different variants. There are projects where both
kinds of requirements are strictly separated—which poses the question whether it is really
possible to test all requirements independently during acceptance. In other projects, however,
the emerging specifications contain requirements which include functional as well as nonfunctional aspects. Similar to many other aspects of life, we should strike the right balance.
138
Rule #9: Formulate separate requirements for
non-functional aspects.
Separate non-functional aspects from functional requirements if at least
one of the following conditions is fulfilled:
■■
■■
The non-functional aspect can be tested independently OR
The non-functional aspect is generally needed as a non-functional
constraint for several functionalities.
The decision whether functional and non-functional aspects
Can the
should be separated from each other is not always easy.
characteristic be tested inAn example: The requirement “The library system shall dependently? Is it demandsave the new customer data entered within a maximum
ed globally?
duration of one second“ should be left unchanged, if the
allowed time is only valid for the specified functionality, which is
the “saving of new customer data“. Extracting the allowed time and writing an own requirement for it would make no sense, as the allowed time could never be tested during acceptance
without executing the functionality as well.
On the other hand, during analysis of the non-functional aspect “within a maximum duration
of one second“ this allowed time could turn out to be a global constraint. The master data of
new library items, for example, or changes of customer data have to fulfill this requirement as
well. If this is the case, create a separate requirement: “The library system shall complete each
saving process within a maximum duration of one second“.
The two steps for checking characteristics
Let us recap. Applying the steps depicted in figure 6.5, you have uncovered missing information in the descriptions of characteristics. In doing so, you have analyzed non-functional
aspects (attributes) and transformed qualified statements into measurable requirements.
Formulate comparisons and superlatives in a
way that they can be measured and tested!
Analyze missing
information on
characteristics!
Formulate separate requirements for independently testable and/or
globally valid
non-functional aspects.
Figure 6.5: The two steps for checking characteristics
139
6.5.3
Checking Amounts and Frequencies
In order to avoid redundancies, you will not write a requirement that is basically
the same several times for each smallest unit. It is better to describe a behavior or a
characteristic only once and to assign this description to a group of issues that should
be valid for the behavior or characteristic you specified. It is important, however,
that the issues are grouped correctly (see transformation effect “generalization“ in
section 6.2.2).
E.g. “save customer‘s name“, “save customer‘s address“ can be comprised with “save customer‘s
registration data“.
Signal words that indicate a generalization of knowledge are numerals or quantifiers as well
as nouns grouping the actors or objects. Checking amounts and frequencies does not aim
towards avoiding generalizations. Is it rather about questioning whether a stakeholder has
grouped several issues or facts in the right way.
Step 1: Check numerals and quantifiers
With requirements, you specify functionalities or characteristics which should be valid for a
defined amount of objects. In natural language, we are using numerals or quantifiers to do
this. In a requirement, a statement is then made on the behavior or the characteristics of this
set of objects.
Look for signal words like “all“,
“every“, “always“, “never“, ...
The requirement “The library system shall enable each library user to borrow each library
item.“ would, in fact, lead to the assumption that also minor library users were allowed
to borrow items which are prohibited to them in accordance to the Children and Young
Persons Act. Furthermore, there could be library items which are only display copies, but not
intended to be lent. Surely the library administration would object to such copies possibly
being lent to all library users. Here, the librarian generalized in a wrong way.
As you see, the danger in using numerals and quantifiers is that possibly the specified behavior or characteristic does not apply to all objects of the set described. Often, the set contains
elements that are exceptional cases for which the specified behavior would be wrong. It is
your task as requirements engineer to uncover such exceptional cases by targeted questioning
of the numerals and quantifiers used.
Be careful to question numerals and quantifiers very purposefully. If you
ask “Really all“, “really each...“ with every requirement, your
stakeholders will probably quickly lose their patience.
140
Rule #10: Question the numerals and quantifiers used.
Each demanded behavior or characteristic has to be valid for really all
objects of the set described and only for the objects of the set described.
Check the numerals and quantifiers used in the requirement.
If you find that the set has been grouped erroneously, you have to:
■■
■■
■■
Narrow the set of objects—if only a part of the whole set is concerned,
OR
Broaden the set of objects—if there are further objects concerned.
Probably there will be also exceptions you have to specify additionally.
In the requirement “The library system shall provide each library user with the ability to edit all
customer data.“, you should question the quantifiers “each library user“ and “all customer data“.
Is the demanded behavior or characteristic
really valid for all objects of the set?
Or are there any exceptions?
Does really every customer have to Does really every customer have to be able to edit
be able to edit the customer data? all customer data ever stored within the system?
If your questioning reveals that there are exceptions, then these have to be specified. Furthermore, you have to change the original requirement: ”The library system provide each library
user with the ability to change the registration data stored about him.”
You should also check sentences which do not state any explicit numerals or quantifiers for
the specified behavior or characteristic. Missing statements on this imply that the specified
behavior will always apply to all possibly relevant objects. Of course, this assumption can be
true. As a requirements engineer, however, you run the risk of overlooking exceptions.
Rule #11: Clarify missing numerals and quantifiers
For each behavior and each characteristic demanded, the set of objects this
specified behavior or characteristic applies to has to be explicitly
described.
Check whether the requirements can be completed with numerals or quantifiers. If this is the case, you have to check for which objects exactly the
requirements should be valid. If necessary, add the respective numeral or
quantifier to the requirements .
141
The example requirement “The library system shall
provide the user with the ability to archive the
stored data via tape backup.” contains, for instance, no explicit numerals or quantifiers. Therefore, the interpretation of this requirement would
be that “every customer can backup all data stored
on every tape at all times”. To assure that the statements
given in this requirement are correct with regards to content, the numerals and quantifiers
have to be specifically questioned and, if necessary, added to the requirement.
To which
objects exactly should the demanded behavior resp. the characteristic apply?
Is every user entitled to start the backup? For all data ever stored?
Can the backup be performed at any time? That is, several times in parallel as well?
Use, for example,
only “all”,
“every”,
“always”, “none”...
Linguists call this
“nouns without or
with inadequate
reference index”.
Look out for signal
words like
“the user”,
“the message”,
“the data”,
“the functionality”
etc.
The scope of implementing the above requirement ranges from a trivial backup software for
1,000 Euros, which lets the librarian copy the data on tape, to a fully automated robotic
backup station for several million Euros. The demanded scope should probably be cleared
prior to commissioning of the system—at least if you do not expect your customer or his
developing department to be clairvoyant.
To ensure unambiguity and to facilitate the creation of requirements, it is advisable to limit
the set of numerals and quantifiers to be used to a number of clearly defined ones.
For the above example requirement, the analysis could lead to this improved requirement:
“The system shall provide each librarian with the ability to backup all customer and item data
stored within the library system on tape at any time.”
Step 2: Check incompleteness in nouns
Within a requirement, nouns represent actors as well as objects for which a certain behavior
or characteristic is demanded. Oftentimes, however, we find nouns in requirements that
describe actors or objects in such a vague way that there is more information needed to
specify them unambiguously.
The term “values” could, for example, encompass all data values that are in any form stored
in and can be input into the system. However, a requirement usually only applies to a part of
these “values”. For a full explanation, it has to be stated exactly to which “values” this requirement applies.
Rule #12: Question vague nouns
For instance, the librarian states: “The data has to be graphically displayed to the user.” In this requirement, at least the
nouns “data“ and “user“ have to be analyzed in more detail.
Which data exactly?
Who/what
exactly? Which part of the
set?
To which users exactly?
An analysis of these nouns could, for example, show that the “data” is meant to be “statistically
calculated data of the library items” and the actor “user” is, in fact, solely the librarian. An
improvement of the above requirement could read like this: “After the librarian has initiated
the calculation of the library item statistics, the library system shall graphically display all
statistically calculated data of the library items to the librarian.”
This rephrasing does, of course, presume that there is another requirement, which describes
the process “calculation of the library item statistics” in a detailed manner and that really all
statistically calculated data of library items can be displayed graphically.
What exactly does “graphically” mean?
Which data of library items exactly?
Moreover, the adverb ”graphically“ has to be described more precisely. In many cases, such
questions lead to a refinement of requirements; i.e., for instance, when the answers reveal that
the different statistic data require different graphical representations.
The two steps for checking amounts and frequencies
Now, you will be done soon. After having gone through the steps depicted in figure 6.6,
you identified and eliminated the linguistic effects concerning amounts and frequencies.
To achieve this, you checked numerals and quantifiers, as well as vague nouns to find out
whether objects or actors were grouped correctly.
Assure the correctness
of the used numerals
and quantifiers!
Question missing numerals
and quantifiers!
Analyze missing information regarding nouns!
If a noun describes set of objects that cannot be exactly defined, information has been deleted from the original sentence.
Question unclear formulated nouns and find out for which objects or actors
exactly this requirement should be valid. Afterwards, add the deleted information to the requirement.
142
Figure 6.6: The two steps for checking amounts and frequencies
Now, you are only a few steps away from the nearly “perfect” requirement.
143
6.5.4
Checking Terms that Describe Possibilities
In many cases it is not only necessary to simply request a system functionality through
a requirement, but also to describe the way in which the system should fulfill the
requirement and which means are to be used to achieve this. This applies particularly
for complex operational processes, the so-called business logic.
Step 1: Check what is possible and what is impossible
Oops, how is a programmer, who is not
accidentally an expert in the field of
flight security, supposed to know how
this is to be
calculated?
Analyze the business
logic, not the technical solution!
We often experience that requirements only specify the results of complex calculations, for example: “With each radar update, the flight plan route shall be
calculated anew”. Often, it is simply not sufficient to claim that certain results should be
obtained; the specification then has to contain the details on the business logic behind the
way to certain results as well. Signal words which indicate deleted business logic are terms
that express that something should be possible or impossible
Look out for signal words like “can”,
“may”, “it is (not) possible”, “it is beyond possibility”.
The linguist calls
these “modal operators of possibility”.
Alway s keep in mind that the description of the business logic (which inevitably leads to
the question “How?”) is not to be equated with the description of implementation details.
Especially when writing business-driven requirements (specification level 2 and 3), details
of implementation (like employing a certain database) should not be described – except for
when they are explicitly requested (e.g. for maintenance reasons).
Rule #13: Clarify what is possible and what is impossible
If you question what
is possible resp.
what is not possible,
you will find forgotten preconditions.
Statements that only claim that a certain behavior should be possible or
impossible delete the related business logic.
Analyze what it is that makes the demanded behavior or characteristic
possible or impossible and add the identified business logic to the
requirement.
If a requirement contains terms that express that something
should be possible resp. impossible, you can, in most
What makes the behavior
cases, rephrase these requirements as a construction
possible/impossible?
that says that “something prevents resp. renders it posWhich business logic is it driven by?
sible that something else is possible resp. impossible”.
Which precondition has to be fulfilled?
In a stakeholder’s requirement, however, it is often only
the latter part of the sentence that is expressed. The first
part of the sentence (the justification) then stays unanswered.
Let’s have a look at an example requirement for the library system: “A library user who has
at least two overdue library items should not be lent any further book”. To implement this
requirement, the system needs to access the information on the overdue items of a library
user. Yet, where does this information come from?
The answers to these questions may, if not documented yet, result in further requirements.
It is only through these requirements that the precondition for the above requirement is
expressed, which is managing each library user’s dunning history: “As soon as the deadline
for returning a library item is reached, the library system shall increment the number of
overdue library items in the dunning history of the library user who has borrowed that item
by 1.” Based on this function description, it now becomes clearer how the system can get the
information on the number of overdue items during the lending process: “After the librarian
has initiated the lending process of a library item for a library user AND in the case that there
are at least two overdue items in this customer’s dunning history, the library system shall
display the error message “overdue items” to the librarian.”
The requirement “It shall not be possible that a new library user who is younger than 18
and cannot present a written consent by their parents is registered” should be completed by
the information on how the system should fulfill this claim as well. The stakeholder has for
sure very precise ideas about how the registration of a new customer should be regulated.
An improved requirement could therefore be: “After the librarian has initiated the saving
process of new customer data AND in the case that the newly entered customer is under 18
years of age AND in the case that there is no written consent by the new customer’s parents
present, the library system shall display the error message “Customer younger than 18” to
the librarian”.
What makes this
impossible?
Where does the system get the required
information from?
Through who or what
will this be
prevented?
Which business logic
is it driven by?
This statement is already a bit clearer; it still contains effects, however. The additional information on how the library system would know that there is a written consent by the parents
present (or not) will for sure lead to a repeated application of this rule and probably to the
following requirement: “In case the newly entered customer is younger than 18, the library
system shall provide the librarian with the ability to confirm the presence of a written consent
by the customer’s parents.”
The step for checking what is possible and what is impossible
After having applied the step depicted in figure 6.7, you have added the missing business logic to the requirement (if necessary) and have cleared the requirement of the worst
linguistic defects.
Analyze the business logic
underlying the requirement!
Analyze required
preconditions!
Figure 6.7: One step for checking what is possible and what is impossible
If this is the case, the condition that makes the demanded behavior possible or impossible
in the first place has been deleted. This is why you should always check whether all relevant
preconditions and persistent conditions are documented.
144
145
6.6
Checking the Sentence
After having checked the single parts of the sentence, we now turn to whole
requirement sentences.
Step 1: Extract irrelevant subordinate clauses
The only subordinate clauses relevant for requirements are logical and temporal
conditional clauses (comp. Chapter 7 “Templates”).
“as”, “because”,
“for the purpose
of”, “due to”
Subordinate clauses containing reasons, intentions or consequences should be eliminated
from the actual requirements and noted as a comment. They are superfluous for the actual
system description and only lead to irritations, in the worst case even to misunderstandings.
Rule #14: Extract irrelevant information.
Subordinate clauses which only contain information unnecessary for the
system development have a negative impact on the readability and make
the actually demanded system requirement fade into the background.
Analyze a subordinate clause’s information content. If the information is
irrelevant for the system description, then:
■■
Extract the subordinate clause from the requirement AND
■■
Write it as a “comment” to the requirement.
Which
relevance has the information in
the subordinate clause?
The following example from our library system shows a requirement of a kind that we find in specifications all too often: “As
it makes the creation of library item statistics easier for the
librarian, the library system shall offer a wizard.”
This is the logical reason for the requirement—but it is
irrelevant information for the system description
Although the subordinate clause “As it makes... easier for the librarian” describes an issue
which can be, for example, important in deciding the way the requirement should be implemented, it does not contain a demanded functionality of the system. This is why this
subordinate clause should be converted into a comment.
The above requirement would then read: “The library system shall provide the librarian
with the ability to create library item statistics with the help of a wizard.” The remaining
subordinate clause, which only contains the reason for the requirement, is added as comment
to the respective requirement: “Comment: This makes the creation of library item statistics
easier for the librarian.”
If you find, however, that the subordinate clause contains something of importance for the
system’s context, that information has to be documented as a separate requirement.
Step 2: Eliminate redundant information
Often, we do not realize that we write sentences which contain redundant information. For
verbal communication between people, this often makes sense or is amusing; requirements,
however, can become unnecessarily complex.
Rule #15: Avoid redundant information.
Eliminate or shorten all parts of the sentence that can be taken away without loss of meaning:
■■
■■
Redundant information
Flowery phrases and expressions
Is there
anything doubled or expressed
with set phrases?
Small in size --> small
Yellow of color --> yellow
A true fact --> a fact
There are many requirements which you can condense without loss of information. The
requirements for the library system: “In the case that the library system interoperates together
with the ordering server, the functioning of the library system shall persist for the user with
the same functionality.” can be condensed using this phrasing: “As long as the library system
interoperates with the ordering server, the library system shall guarantee unrestricted functionality to the user.”
The two steps for checking the sentence
Congratulations. After having gone through the steps depicted in figure 6.8, you now have
not only recognized and eliminated all semantic effects in your requirements, but also freed
your requirements from ballast.
Clarify the relevance of
subordinate clauses!
Check for redundant information
and void or flowery expressions!
Figure 6.8: The two steps for checking the sentence
146
147
6.7
Checking the Big Picture
Now it is time to climb a step up and to have a look not only at the single
sentence, but on its integration in the overall specification.
Step 1: Analyze exceptions to the usual behavior
Look out for signal
words like
“must”, “shall”,
“should”, “it is
necessary that”...
To describe a system’s functionality in full, the requirements have to describe
the desired usual behavior as well as the behavior in exceptional cases (in case
the latter are possible). When writing a requirement, you should always ask yourself whether
the system will always be able to guarantee the desired behavior or whether there are constraints or marginal conditions under which that would not be possible.
Unfortunately, in reality systems are dependent on external influences; data or events, for
example, that are expected for further processing may fail to come. Describe the system’s
behavior for the exceptional cases it cannot handle on its own. Requirements of this kind
often contain terms which express that something has to be necessary .
The linguist calls these „modal operators of necessity“.
Apply this searching
method especially to
freely formulated
requirements.
In requirements which were formulated using our requirements template (see Chapter 7
“Templates”) and which therefore have employed such modal operators as key words for
stipulating the degree of legal obligation, your search for modal operators will of course be
successful.
Which behavior is it that the system is expected to show if the demanded functionality cannot
be provided due to systemic reasons? Shall it crash without any comment? You would probably rather expect it to show a defined behavior. Potential problems, for example, should be
displayed to the user during data transmission via user interface. This way, the user can restart
the data transmission. After having answered the questions, the behavior in exceptional cases
can be specified for the requirement: “If the library system cannot establish a connection to
the dispatching system due to technical reasons, the library system shall display the error
message “Connection cannot be established” to the librarian”.
The description of a system’s exception behavior is often neglected. A full definition of a
system’s behavior in exceptional cases can be as elaborate as defining the system’s behavior in
normal cases. This is likely to be underestimated.
Therefore, take these efforts into account from an early stage. Very often we experience in
project reality that the definition of a system’s behavior in exceptional cases is only touched
on or even omitted due to a tight schedule. In the worst case, this results in system which
shows an unpredictable behavior when facing even minimal environmental disturbances.
Specify possible exceptions immediately
when eliciting the
user requirement
(from specification
level 2 on).
Step 2: Analyze incompletely specified conditions
Similar to the specification of exceptions (see previous rule) which describes the system’s
behavior in situations where it cannot assure the desired functionality, all (possibly complex)
conditional structures of the “normal behavior” have to be described as well.
Requirements containing conditions describe the behavior in case the condition is valid resp.
fulfilled. It is important to also describe what should happen if the condition is not fulfilled.
In our experience, however, the latter information is often neglected in system specifications.
Rule #16: Analyze exceptions to the usual behavior
Look out for signal
words like “if...
then”, “in case...
“then”, “should ...
<infinitive>” or
“dependent of”.
Rule #17: Analyze incomplete conditional structures.
It is often the case that normal behavior also requires the description of
what should happen if the system cannot guarantee this behavior.
Analyze whether there are situations in which the system cannot guarantee
the normal behavior. If this is the case:
■■
Either describe the exceptional behavior in an additional requirement
OR
■■
Expand the original requirement by the exceptional behavior.
Is the
system always able to guarantee
the demanded behavior?
What happens if it cannot?
Which exceptions are possible?
The requirement “The library system shall send orders for
new library items directly to the dispatching system.”
calls for a behavior which regards the normal case
where data has to be transferred to a neighboring
system. However, certain questions regarding possible
exceptional cases remain unanswered. What happens if the
connection to the dispatching system cannot be established and
therefore data cannot be sent? What happens if an error occurs during the data transmission?
148
Each conditional behavior needs at least as well the description of what
should happen if the condition is not fulfilled.
Clarify the system’s behavior in case (or cases) the condition is not fulfilled:
■■
Specify an additional requirement for each condition that has not been
described yet OR
■■
Expand the original requirement by the missing cases.
In the library system requirement “If a library item is not reserved, the library system shall
provide the librarian with the possibility to continue the lending process.”, at least the question concerning the system behavior in case a library item was reserved remains unanswered.
What is the desired
system behavior in
case the library item
is reserved?
149
In our library system, settling the question of the system behavior in
case of a “reserved” library item would only lead to an expansion if the demanded system behavior had not been
How is
described yet. If this is the case , the system behavior
the system expected to act in
expected if the condition is not fulfilled has to be
case the condition is not fulfilled?
described, for instance by writing an additional reAre there any other cases?
quirement: “If the library item is reserved, the library
system shall display an error message to the librarian.”
Step 3: Check for implicit assumptions
Many aspects within the system to be described are so obvious to stakeholders with
domain experience that they will not communicate them during the elicitation of
requirements. Often these aspects cannot be found in other requirements sources,
e.g. documents, either. They are assumed to be known or the stakeholders shy away
from writing down things they consider banal or commonplace. We call this
muscle memory.
Write separate requirements if there are many cases that need to be distinguished.
Otherwise, simply expand the original requirement.
As an alternative, you could also expand the original requirement:
■■ “After the library system has checked the library item’s availability AND if the library
item is not reserved, the library system shall provide the librarian with the possibility to
continue the lending process.”
■■ “If the library item is reserved, the library system shall display the error message “Library item reserved” to the librarian.”
It is particularly important that you identify all possible cases and that you describe the
demanded system behavior for each and every one of those. Unfortunately, there are not
always simply two categories (fulfilled/not fulfilled resp. reserved/not reserved).
Often, you have to distinguish exactly between different cases. As an example, let us check a
requirement from the library system: “After the library system has identified the library user
AND if this library user has one overdue item at the most OR if this library user has less than
24 library items still borrowed at the time of the lending process, the library system shall
provide the librarian with the possibility to enter the library item to be lent.”
What is the desired system behavior in
case the library user has at least two
overdue items?
Or use bullet points
for the single cases
(like in the example
above).
What is the desired system behavior in
case the library user has borrowed at
least 24 library items without returning
one?
I.e. the stakeholders are not any longer actively
conscious of the profound knowledge they have.
However, these implicit assumptions have to be made explicit at some
point (Quality criterion “Completeness”, see Chapter 1 “In Medias
RE”). This is at the latest when the requirements are implemented—
otherwise the appropriate functioning of the system is endangered.
Implicit assumptions (presuppositions) are deleted statements that have to
be true for other statements (requirements) to make sense.
Basically, all rules described help you discover certain implicit assumptions,
for example by analyzing nominalizations or amounts and frequencies. Yet, if whole aspects
or parts of a system are deleted or forgotten, implicit assumptions are very hard to discover.
In our project reality, we therefore often encounter certain limits.
The only thing that
can help you now:
■■ Creating views in
However, if there is only a tiny bit of information hinting towards an implicit assumption,
the use-case apyou will be able to discover it using the SOPHIST Set of REgulations. To support you in
proach
doing this, we have summarized our experience towards discovering implicit assumptions
■■ Appropriate eliciinto one further, fairly simple rule:
tation techniques
■■ Logic common
sense
Rule #18: Analyze implicit assumptions.
There are several questions that have to be answered on this requirement and then described
in the requirements document. Analyzing these different possible cases can lead to highly
complex requirements. How complex requirements may become can be seen if we add conditions to the above requirement: “If a library user’s dunning history shows more than five
overdue library items, the library system shall destroy this library user’s library card.” and
“The library system shall display a warning message to the librarian if there is a “damaged
return” on the library user’s record.”
Requirements frequently contain a statement (in most cases only stated
incidentally) which has to be true—otherwise the basic requirement cannot
be fulfilled. Such statements are then your signal words indicating implicit
assumptions, e.g.
Conditional requirements can become extremely complex. Using natural language to express
such complexity then results in confusing, interlaced requirements. There are more appropriate means you can employ, for example decision tables.
Analyze implicit assumptions by applying the following steps:
These can help depicting complex conditional structures in a clear way. When checking
completeness, they are usually the best means to discover variants of actions or conditions
that have not been described yet.
■■
Descriptions of temporal or logical sequences
■■
Nouns which are more precisely described by a reference word
■■
■■
■■
Identify the signal word in your requirement that indicates an implicit
assumption.
Find out which functionality is referred to by that signal word.
Check whether this functionality is already described in other
requirements.
Look out for signal
words like “If”, “In
case”, “After”, “As
soon as”, “When” ...
Look out for signal
words like “entered customer data”, “displayed
view”, “computed capital
value”...
Write one or more additional requirements for each functionality that has
not yet been described.
150
151
As an example of how to apply this rule we will have a look at the
following requirement from the library system: “After the
Steckt in
library system has saved the entered registration data of a
der Anforderung eine implizite
Annahme? Ist diese Aussage bereits new library user, the library system shall print a library
card”.
irgendwo in der Spezifikation
The core functionality of the requirement “Printing
beschrieben?
library card” only makes sense if we assume that “the library
system has saved the entered registration data”.
6.8
Application of the SOPHIST Set of REgulations
The SOPHIST Set of REgulations provides you with a toolbox you can use to systematically
analyze requirements. We have already applied it in many industry projects settled in various
domains.
Categorize semantic effects
Find signal words
Ask questions
Remove semantic defects
Is there already a requirement that says that registration data has to be saved?
Exactly this functionality has to be described already in another requirement. If this is not
the case, you have uncovered an implicit assumption which has to be added as new function
description to the requirements document: “The library system shall save the registration
data of a new library user” . Of course, this additional requirement has to be deeply analyzed
regarding semantic effects afterwards. Ideally, you start with rule #1.
Is there already a
requirement that describes that registration data can be
entered?
Another indicator for implicit assumptions are nouns which are detailed by a reference word.
If we have a look at the above example requirement, we will quickly find that the reference
word “entered” in front “registration data” indicates that there has to be a functionality for
entering registration data. If you find that this functionality has not been already specified by
at least one requirement, information has been deleted: “The library system shall provide the
librarian with the ability to enter registration data for a new library user.”
The three steps for checking the overall picture at one glance
A high-quality requirement has now helped you to discover and track down even completely
deleted information like exceptional behavior, forgotten temporal or logical conditions and
even implicit assumptions.
Analyze statements that have to be
true for the requirement to make sense!
Analyze exceptions to
the usual behavior!
Analyze all
possible cases!
Figure 6.9: The three steps for checking the overall picture
Often, requirements templates are applied additionally. Those provide clear instructions on
how exactly to formulate a requirement sentence (see Chapter 7 “Templates”). By doing this,
several steps of the SOPHIST Set of REgulations (like rule #1, active voice) can be omitted.
You can look for effects at different points of time (See Chapter 7 “Templates”, Chapter 4
“Validation Methods for Requirements” and Chapter 11 “Quality Metrics”):
■■ Directly in an interview (which we call “constructively”): here, the requirements engineer immediately checks every statement made by the interview
stakeholder for linguistic effects. He or she directly asks for the missing information considered important. In this ways, the information needed is elicited
very efficiently within the interview, as knowledge gaps are immediately uncovered. If the requirements engineer is experienced in this field, the interviewed
person will not even be aware that his or her statements are systematically
analyzed and questioned in a targeted manner, using methods originated in
psychotherapy. The interviewed person will only realize that the discussion will
get to the point very quickly. The documentation of natural-language requirements is another area in which the rules can be applied constructively. An
example of this is directly specifying each functionality using a main verb or
using active voice in every requirement. Of course, it takes a certain amount of
practical experience with the questioning techniques of the SOPHIST Set of
REgulations to apply the rules for discovering semantic effects in a constructive
way.
■■ If requirements in written form already exist, then these are checked using
the linguistic rules. Omissions, unclear aspects etc. can thus be questioned.
Here, the Set of REgulations serves as means of analytic quality assurance.
This, of course, needs
some practice. Yet, it
is very effective.
Paper doesn’t blush,
so you can practice
this technique on written requirements.
If you continue this systematic approach requirement by requirement, you will step by step
get to a complete specification document of high quality.
152
153
Of course, even requirements engineers are not immune to the unwanted defects of focusing
and simplifications—preparation is necessary. If using the method for the first time, it is
advisable to analyze requirements already documented. After a certain time of practice, the
psychotherapeutical approaches of the SOPHIST Set of REgulations will be integrated into
your mind to an extent that allows you to directly analyze and question statements of a
stakeholder while interviewing him.
In the beginning, you should only apply some of the most important rules that allow you to
concentrate on the group of perilous persistent offenders.
Rule #16
If you are experienced in the application of the most important rules of the SOPHIST Set of REgulations, you must not ignore the following additional rules:
■■ Analyze exceptions to the usual behavior.
■■ Analyze implicit assumptions.
■■ Formulate comparisons and superlatives in way that they can be measured or
tested.
Rule #1
In our experience, the following rules of the SOPHIST Set of REgulations should be
considered the most important:
And at last, if you want to (or have to) be an expert, apply the remaining rules to your
requirements.
Rule #2,#3 or #4
■■
■■
■■
■■
■■
However, despite being an expert, you should never mutate into a perfectionist. Do not strive
without any reflection towards requirements absolutely freed from all defects, but always
consider your project’s constraints. In terms of quality, theory and practice are often miles
away from each other. Quality in the analysis and documentation of requirements is tied
to a lot of effort and high costs. Perfectionism thus quickly turns into luxury most projects
cannot afford.
Rule #6
Rule #10 and #12
Write every requirement in active voice.
Analyze processes and express them using main verbs.
Analyze missing information on the process verb.
Clarify amounts and frequencies.
Clarify missing conditions
Rule #17
Rule #18
Rule #8
Follow the principle:
appropriate over
perfect!
Realizing that perfect communication is impossible will truly facilitate your everyday work in
projects. Handling this fact as competently as possible is one of the crucial factors for success
in requirements engineering.
The best way to memorize these rules of the SOPHIST Set of REgulations is to write them
down on a piece of paper, together with their related questions. Hang this paper at your
workspace at eye level and take a conscious look at it every day.
Do not try to force the use of each rule on every requirement. If, for instance, your requirement does not need a logical or technical condition, you do not have to construct an artificial
condition or analyze different possible cases.
As soon you feel confident enough in the application of the rules with high priority, pull out
some more from your box of tricks.
154
155
6.9
Baa, baa, Black Sheep, Have You all the Rules?
Checklist SOPHIST Set of REgulations
I am familiar with the transformation processes that occur between
inner idea and linguistic expression.
I am able to identify the most frequent linguistic defects in
requirements.
I know which method to follow on which specification level.
I know the most important signal words and am aware which signal
words indicate which questions.
I understand the different points of view (parts of a sentence, sentence, overall picture) from which a requirement is to be assessed.
I am able to apply the SOPHIST Set of REgulations as an analytical
method for analyzing documented requirements.
I have gained enough practical experience in the application of the
SOPHIST Set of REgulations to be able to apply the most important
rules constructively during an interview with a stakeholder.
156

Chris Rupp, Ellen Wolf The SOPHIST Set of REgulations

Transcription

Similar documents

Requirements- Engineering RE-Fibel« Requirements Engineering

tenure track faculty position announcement librarian ii

Cambridge University Press Philosopher

English26 - David Crystal

Neal-Marshall Black Culture Center Library Newsletter

Library Activities - AISSMS College of Engineering

Connect the Dots

AU Herning

Culture in Second Language Teaching

Spanish I Unit Handout—Reflexive Verbs Unit Topics: Vocabulary