The SOPHIST Set of REgulations for Requirements Psychotherapy

6
115
Chris Rupp, Ellen Wolf
The SOPHIST Set of REgulations
Psychotherapy for Requirements
Wenn Anforderungen von Menschen formuliert werden, finden
bewusst und unbewusst Transformationen statt, die zu
unvollstndigen, verzerrten oder sogar falschen Informationen
fhren.
Mittels SOPHIST-REgelwerk, das auf dem Therapieansatz
Neurolinguistisches Programmieren (NLP) basiert, knnen Sie
Lcken und Verflschungen in Ihren Anforderungen
systematisch aufdecken und gezielt beheben.
Therapieren Sie Ihre Anforderungen Schritt fr Schritt
diese Regeln helfen Ihnen dabei, wirklich das zu verstehen,
was Ihr Gegenber will.
When people formulate requirements, consciously and uncon-
sciously transformations happen, leading to incomplete, distorted
or even erroneous information.
Applying the SOPHIST Set of REgulations, based on the
therapeutic approach Neuro-linguistic Programming (NLP), en-
ables you to systematically detect and remove gaps and dis-
tortions in your requirements.
Treat your requirements step by step these rules help you
to really understand what the person you are talking to wants.
117 116
6 The SOPHIST Set of REgulations 6 The SOPHIST Set of REgulations
In psychotherapy, building upon several of Chomskys theses, a model of human commu-
nication and mode of expression has been developed and fne-tuned. Te 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 efectively be learned and applied
by anybody and which was based on the premise that the therapist gains a deep understand-
ing of the reality the patient perceives. In order to achieve this, the therapist has to fnd 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 fgure 6.1) happens.
Reality
Personal perception Personal knowledge
Perception Expression of knowledge
Defects?
Defects?
Linguistic expression
of knowledge
Figure 6.1: Transformation as possible destroyer of information
Starting point (left side in fgure 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 docu-
ment. 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 pro-
foundly understand why reality has been falsified or distorted in the requirements, you can
fathom the real requirements with specific questions in mind.
Software systems,
product, application,
business process etc. Limited personal perception leads to
perceptional transformation.
Linguistic expression of personal knowledge
leads to representational transformation.
6.1 About the Phenomenon of Transformation
Linguistic Effects
Requirements are formulated by many diferent stakeholders
people with varying levels of prior knowledge, social background and
experience. Tis diversity is refected in the requirements
and harbors the danger of loss of information, incom-
pleteness 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?
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.
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 defciencies of natural
language.
You are familiar with these fundamentals or consider them too theoretical? No
problem. Skip directly to the descriptions of the frst 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 fnd a
lot of tips and tricks from our project experience that will help you apply the SOPHIST Set
of REgulations.
6.2 The Roots
Neuro-linguistic Programming
Te SOPHIST Set of REgulations is fundamentally based upon the meta-model of language
provided by the therapeutic approach neuro-linguistic programming (NLP) [Bandler75],
[Bandler94]. Te rules of NLP help therapists to make people aware of their inherent intui-
tion 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 efects 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)
The meta-model
of language
If you are a connois-
seur of NLP or a
theory dodger, you
may go directly to
section 6.3.
This is the model of the model language,
i.e. it describes the model of language.
119 118
Transformation processes result from our human nature. Every human beings perception is
infuenced by their social character, their prior knowledge and their experiences. Psychologists
call this the personal reality. Te 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 diferent way. He sees the clear structure of the work with introduction, body and
conclusion, easing the readers understanding. He does not notice the appealing illustrations
at all. Both librarians have thus diferent images (as psychologists say: models) of the same
bookthe same reality.
Yet, how can it be that librarian A solely concentrates on illustrations and layout whereas li-
brarian B mainly notices the thematic structure? Tis 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.
Interestingly, transformation can be found at another spot in the process from reality to
requirements. Tat is where personal knowledge is expressed in natural language (referred
to as knowledge representation in fgure 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.
As we have seen, there are two kinds of transformation processes:
Perceptional transformations occur since every person perceives reality in a difer-
ent way and creates an individual image of it.
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 diference
whether the librarian describes the book being divided into introduction, body, and conclu-
sion or whether he calls the structure very practical.
Every person can
only grasp a
fraction of the
whole reality.
Every person
assumes a certain
basic knowledge in
others.
Focusing
Simplification
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 transforma-
tions may be reversed.
Perceptional transformation (reality personal perception) cannot be undone as a persons
individual image cannot be easily infuenced. Yet, this may change if the experiences and so-
cial structures of a person change. Regardless of this, each person can always only grasp a part
of reality.
To compensate for perceptional transformations, the requirements engineer always has to
question several stakeholders on the same subject.
Te diferent 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 wellprovided the requirements engineer knows the
diferent 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 specifc
or, more often, several transformations to apply on the deep structure. In this way, the surface
structure develops.
A sentence (a surface structure) is thus a diferent form of the original (the deep structure)
in a persons 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 stakeholders personal reality,
the requirements engineer has to identify the deep structure of the respective
surface structure.
Even if you would like
to sometimes:
do not treat your
stakeholders.
I. e. recognizing
and questioning
linguistic effects
This is the original;
it is what the person
had in mind before
expressing it in
language.
This is the transformed version of the original; it is what
the person stated when expressing their mind in language.
121 120
Te fact that people stick to certain rules in the construction of surface structures made
Chomsky assume that peoples behavior in the creation of linguistic expression is driven by
rules. A possible (and plausible) set of rules was frst presented in Chomskys aforementioned
transformational-generative grammar.
Similar to Chomskys approach, we can defne rules in system analysis as well, enabling a sys-
tematic discovery of transformations in requirements written in prose and in the customers
statements. Te requirements engineer wants to understand a part of the authors 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 fnd by targeted questioning the
deep structure of what the author tried to express.
6.2.2 Categories of Representational Transformation
Based on linguistic fndings, Bandler and Grinder distinguish in NLP between three prin-
cipal types of remodeling: deletion, generalization and distortion. Tis classifcation may
perhaps appear not to be disjunctive . It has, however, been tried and tested in practice and
been found useful.
In fgure 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.
GENERALIZATION is an indicator
for erroneous generalizations.

Figure 6.2: Classifcation of linguistic efects
Reminder:
Neuro-linguistic
Programming
Linguistic effects
cannot always be
strictly assigned to
only one category.
In the following, we will describe the categories of transformation according to Bandler and
Grinder. Tese defnitions are of purely linguistic nature, but can be applied to linguistic
efects in the context of requirements as well.
Deletion
Te process of deletion reduces the information overload we are con-
fronted 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 flter 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].
Tis 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: Tere are overdue fnes to be paid by customers exceed-
ing the loan periods. A listener not familiar with the deleted information, however, could
understand librarian As statement in a totally diferent 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.
Te 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).
123 122
Generalization is the process by which elements or pieces of a persons 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 ft
into the shelves and therefore have been stored in another place. Tese folios are tagged with
an ID starting with FOL. Te librarian accidentally forgot this exception.
Distortion
Distortion is the process when reality is rearranged or even falsifed, 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, infuencing ones
own perception or, although in most cases unconsciously, the receivers perception.
Te 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 ft into an already existing image of a situation.
Tis 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. Te librarian
distorts the fact, as he considers the blocking as being self-evident and therefore expresses it
in a simplifed way. However, it may be possible that the process consists of several complex
process steps.
6.3 How to Deal with Linguistic Effects
Each of the transformation categories mentioned (deletion, generalization and distortion)
results in certain so-called linguistic defects. Every efect may lead to low-quality require-
ments, yet not in all cases to a defect as well.
Whether a linguistic efect is a problem and should be corrected, depends on
many constraints. Te level of detail you are writing requirements on is surely
an important factor.
Linguistic efects on the level of goals or rather generic requirements
(e.g. specifcation level 0 and 1, see chapter 3 From the Idea to the
Specifcation) are common and even not always preventable on
those levels of detail.
However, as there will be readers who will deal with your specifcation
only on these levels, it is necessary that information important for these readers will not be
destroyed by efects.
As a consequence, you should stick to certain rules even on specifcation 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 defned in there.
Express processes via main verbs.
If you write very detailed requirements (from specifcation level 2 on), which moreover are to
become part of a contract for an external assignment, linguistic efects 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 efects. It is now your task to discover
and correct these efects, provided the missing or distorted information is signifcant.
Tis is why we recommend applying the rules of the SOPHIST Set of REgulations basically
from specifcation level 2 on. From this level on you write more detailed requirements which
refne requirements from levels 0 and 1.
Like to calculate, to
print, to export, to
transfer...
Grammatically correct
125 124
No matter what specifcation level you are writing requirements on, there is one basic rule
you should always adhere to:
For each specifcation level, there is one refnement 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
specifcation level, as not every main verb is a main verb suitable for that
specifcation level.
On specifcation level 1, for instance, the use cases for the library system are defned, one
of which is dealing with customer management. Using a main verb, we name this use case
manage customer. Te main verb to manage is fairly suitable on specifcation level 1.
However, from specifcation level 2 on, we never use the main verb to manage as is to far
too vague for the more detailed levels. Terefore, we need to refne 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 efects 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 efects in requirements you have
already documented? Ten we recommend applying the SOPHIST Set of REgulations
analytically .
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.
Basically, however, it should not be your goal to hone all requirements to a degree where they
are free from all efects. 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 projects success.
Our experience shows that linguistic efects occur in difering frequency. Tis is why it is
important and advisable to concentrate in the frst place on the group of perilous persistent
ofenders.
Combine the Set of REgulations with the analytic methods from
Chapter 10 Validation Methods for Requirements.
Also apply the re-
quirements template
introduced in Chapter
7 Templates.
Proceed risk-
driven
E.g. from
specification level 2
on
You will find a ranking
of these in
section 6.8.
6.4 The Application of the SOPHIST Set of
REgulationsRequirements Laid on the Couch
Based on the theses of the linguist Noam Chomsky and the meta model of lan-
guage, 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 specifcations can be detected
in a defned and systematic manner (analytical quality assurance). Know-
ing 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, difer-
ent linguistic efects 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:
Step 1: Identify linguistic efects in requirements from signal words.
Step 2: Analyze lost or distorted information with means of targeted
questioning.
Step 3: Remedy linguistic defciencies or errors in content by rearranging the
requirements using the answers given in order to eliminate efects.
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
defned.
E.g. also semi-for-
mal notations like
diagrams, tables or
figures including
natural language
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 .
Find signal word
Incorporate answers
Ask questions on the
signal word
127 126
Probably you know this, too: You are told by a colleague that there is some great compila-
tion 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 fnd yourself frustrated and do not know how to best apply these, in fact, simple rules.
Surely, you ask yourself the following questions: Which specifc 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?
Figure 6.3: Te process of applying the SOPHIST Set of REgulations
In the end, you probably will not be able to avoid all pitfalls of natural language. Tere 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 fgure
6.3.
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 frst place, check the single words (parts) of a requirements sen-
tence in order to complete it step by step with signifcant, yet deleted informa-
tion. Specifc words in your requirement sentence are the signal words you
have to pay attention to. Each and every signal word points to a specifc se-
mantic efect. 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.
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 picturethe big picture your requirements describe.
Take advantage of the information already given in the requirement sentence.
Is for example the specifcation of a certain system functionality or attribute
missing, so that the analyzed requirement sentence does not ft 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.
Te 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 refne the requirement sentence. In this case, particularly a disciplined ap-
proach, processing requirement sentence by requirement sentence, is of utmost importance.
Otherwise you may fnd 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 refned requirements, but to not yet analyze
them in detail directly. You should continue the analysis of the primarily explored require-
ments frst. Subsequently, analyze the new requirements.
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
refects 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
fgure 6.2.
If data is saved af-
ter a successful plau-
sibility check, the
negative case must
also be specified.
If something is green
in color, then it suf-
ficient to call it
green.
If the signal word to
save occurs, you have
to ask the typical W-
questions for
to save.
In interviews or
when writing re-
quirements, always
stick to the
thread.
3. Check the
overall picture
1. Check the parts
of the sentence.
2. Check the
sentence.
129 128
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 Checking the Processes
If a process is described in a requirement with a process verb, additional infor-
mation for this process verb has to be described as well.
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 com-
plete 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 specifed.
When checking process verbs, your main focus is on the functionality described in a require-
ment. Te 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.
Step 1: Check for active voice
A linguistic efect, 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.
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.
Rule #1: Write every requirement in active voice.
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). Tus, the requirement gains in information and the
process verb is detailed by stating who performs the process resp. has to possess a certain
characteristic.
Verb, but also nominalizations or
light-verb constructions
Functionality process or activity
Who is to
perform the process resp.
to possess the attribute?
Autonomous system action
Interface requirement
User interaction
For instance, in the requirement Te 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:
Te library user shall enter the user password at a terminal of the library system.
Tis 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.
Tis may be, for instance, providing an input option for the user password: Te 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 efects blurring the actually
demanded functionality can be easier identifed if the functionality within the requirement
is described by a main verb.
Vaguely formulated process verbs blur the functionality actually demanded.
Question the actually demanded functionality and express it using a good
main verb.
Rule #2: Express processes using good main verbs.
For example, if you question the vague phrasing indicate
comprehensive information in the requirement In a
search for a certain library item, the library system shall in-
dicate the librarian comprehensive information on the library
item found, you will probably fnd 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 .
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
What
functionality is really demand-
ed? What is the MAIN
VERB?
Not all main verbs
are good main verbs
on all specification
levels, like to manage
or to validate.
This will be covered with rule #6.
Subsequently, define the main verb in your list of
process verbs (see chapter 7 Templates).
131 130
After including the answers to the questions, the improved (yet still far from perfect) require-
ment 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 descrip-
tion. Te process to check does call for the description of a verifable result, e.g. to save
data or to display error message. Terefore, 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 afected by linguistic efects to an extent that the process to be specifed 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
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 lin-
guistic analysis, all nominalizations are identifed and analyzed.
From specification
level 2 on, please do
not use main verbs
like to check, to
manage or
to cancel.
This will be cov-
ered with rule #17.
A process (which often may last for a long
time) is distorted to a (one-time) event.
Look out for signal words like reservation, registration
(and also requirements engineering).
Nominalizations can blur a whole process.
Analyze each nominalization and check whether the process is described in
a suffcient manner somewhere else within the requirements specifcation.
If this is not the case, you have to deal with the nominalization by:
Writing one or more requirements, each with a good main verb OR
Creating a new glossary entry.
Rule #3: Clear nominalizations
If you analyze the requirement Te system shall allow for
archiving. , for instance, you will fnd that the noun
archiving is a nominalization. Tus, you have to ques-
tion the stakeholders genuine intention. Te 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:
Te 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 notifcation to the customer who reserved the item. the words return and
notifcation are both nominalizations which have to be analyzed.
If all information needed to answer the question is already written down in the requirements
specifcation, the above requirement may remain almost unchanged. Only if the nominaliza-
tions return and notifcation blur processes which are not entirely specifed or defned
yet, the missing information has to be added to the specifcation.
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 customers 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 specifed in the requirements specifcation. If
not, you have to add these requirements. In accordance to rule #2, you frst 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 specifed yet, this means the introduction of a new use case return
library item as well.
Basically, it is not our goal to avoid or prohibit all nominalizations in requirements.
Resolving a nominali-
zation most often
results in several
additional
requirements.
Questioning a
nominalization often
uncovers a completely
deleted use case.
Play it safe: Always try to resolve nominalizations and to express the process obfus-
cated by the nominalization using main verbs. Be sure only to use nominalizations if
Using the nominalization is justifed by the professional context,
Te term is defned in a place accessible to all people involved,
Te defnition of the nominalization leaves no space for interpretations.
Is the
noun a nominalization? Which
exact process is meant by it?
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?
133 132
Among others, nominalizations are sometimes used to describe an object involved in the
process rather than the process itself. If you have defned the nominalized term unambigu-
ously, 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 notifcation, as the notifcation 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 append-
ing 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 diferent things
that should be distinguished from each other, like an object associated with a process and the
process itself.
Light-verb constructions
Often, a systems 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.
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.
Rule #4: Analyze light-verb constructions.
Te strong connection between verb and noun in
light-verb constructions causes the actual process
to fade into the background completely. It be-
comes only visible if the light-verb construction
is analyzed and the functionalities essential for the
process are described using main verbs.
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 specifed 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. Tus, in the requirement
Statistics should be put at the librarians disposal. the light-verb construction to put at
ones disposal could include the processes to create, to display, to print, to import
and many others.
E.g. the notification E.g. the notification process
Look out for signal
words like to put at
ones disposal, to
bring to an end or
to be in operation.
Is the
process described by a light-verb
construction? Which specific process is
meant by it?
What exactly does
to experience a
change mean?
What exactly does to put at ones dis-
posal mean?
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. Tis
means, for example, taking a deeper look at the functionality by letting the requiring person
answer the fve W-questions (see rule #6).
Te question In what form must the statistics be provided?, for example, could reveal that sta-
tistics have to be provided in electronic form as well as printed on paper. Moreover, the source of
the statistics needs to be defned. An improved requirement could read like this: Te library sys-
tem 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 identifed the functionality demanded within a requirement and trans-
formed 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. Diferent functionalities
expressed by main verbs, however, usually need diferent additional information. At least for
analyzing this additional information, you should create several requirement sentences to
cover those diferent functionalities.
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 formu-
late for each identifed process verb one requirement sentence containing
exactly one main verb.
Rule #5: Write exactly one requirement sentence for
each process verb.
If you, for example, split up the requirement Te 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:
Te library system shall provide the librarian with the possibility
to enter data of a new customer.
Right! This is a nom-
inalization which has
to be analyzed more
deeply in
accordance to
rule #3.
Reminder: A requirement can consist of one or
more requirement sentences.
How many
process verbs does the
requirement contain?
Or stakeholders
simply describe pro-
cesses they do not
really know.
135 134
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. Te
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 efects 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 customers 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 efect-ridden requirement is the following: Te user shall be able to
search. Tis 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 specifed 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 fnd that the original requirement has to be refned by several
detailed requirements which replace it.

The four steps for checking the process
Lets put it in a nutshell. Along the steps depicted in fgure 6.4 you have phrased your
requirement(s) in active voice. All functionalities to be specifed have been described us-
ing main verbs, and all open questions regarding the process verb have been answered and
integrated into the requirements.
Figure 6.4: Te four steps for checking processes
Separate
requirements
Analyze the
process verb
Phrase in
active voice
Find the
demanded
functionality
Write every require-
ment in active voice!
Express vague process verbs
using main verbs!
Write exactly one re-
quirement (sentence) for
each main verb!
Analyze missing information
on process verbs!
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.
Analyze the requirements process verb using the typical W-questions. In
case you fnd yourself unable to answer all W-questions with the informa-
tion provided in the requirement, then information has been deleted.
If the missing information is relevant, add it to the requirement.
Rule #6: Analyze missing information on the process verb
In order to correct linguistic efects in requirements, the requirements engineer poses targeted
questions on all aspects of the process verb. Te answers to these questions provide informa-
tion necessary to eliminate a defect. In our experience, at least the following questions should
be discussed and answered in the requirement:
Method:
How is the functionality executed (not in
terms of technology, but in its professional
context)?
Frequency:
How often is the functionality ex-
ecuted?
Time/Logic:
When resp. under which conditions is the functional-
ity executed?
Object:
On or using who or what is the
functionality executed?
By means of these questions you can determine whether the process verb is sufciently speci-
fed or whether the requirement has to be completed by further information.
Advantages:
Requirements can be
better prioritized,
ranked and under-
stood.
Disadvantages:
Pieces of informa-
tion belonging to-
gether are scat-
tered around
several require-
ments and are
harder to manage.
What?
(To) whom?
How?
When?
How often?
For what?
How often?
With which criteria?
When?
Clear light-verb constructions!
Clear nominalized
processes!
137 136
However, we are only half way to the perfect requirement.
6.5.2 Checking Characteristics
Similar to the descriptions of processes, characteristics have to be described unam-
biguously and completely as well.
Te 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 sufcient.
Tere is further information that has to be added to the characteristic. Te 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 fnd missing or distorted information.
When checking adjectives, your main focus is on the characteristic of the system described in
a requirement. Te 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.
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).
Question the adjective or the adverb with the typical W-questions. In case
you fnd 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.
Rule #7: Analyze missing information
on the adjective or adverb.
In the requirement Te library system shall be intuitively
operable. , for instance, you should question the charac-
teristic intuitively operable. Te linguistic efects have to be
analyzed in more detail. Relevant information has then to be added to the requirement.
Like big, important, understand-
able, quick
Look out for sig-
nal words like
quickly, high-per-
formance, big,
low
For whom
or what is the demanded
characteristic? When resp. under
which conditions?...
For whom shall the library system be intuitively oper-
able? What exactly shall be intuitively operable?
An improved requirement (though still far from being free of efects) could read like this:
Te user interface of the library system shall be intuitively operable for the librarian.
Often, we fnd non-functional aspects in functional requirements. Tose are described
by adjectives which either come as attribute of a noun or are modifying verbs (adverbs).

To uncover non-functional aspects in functional requirements, extract those from the func-
tional requirements, so you can analyze them separately.
If you apply rules #1 to #6 to the requirement Quick printing of the library card is neces-
sary , 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.
Te claim for quick printing indicates that the printing process shall be completed in a
certain amount of time. In a frst step, we can derive the following non-functional require-
ments from this: Te 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 efects.
Tis rule says that adjectives or adverbs in requirements frequently describe comparatives or
superlatives . Yet, comparatives and superlatives always require a concretely specifed point of
reference as additional information. Te comparison faster, for example, needs information
on how much faster than what something has to be or how fast exactly it has to be.
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.
Rule #8: Formulate comparisons and superlatives in a way that
they can be measured or tested.
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 re-
quirement can be tested afterwards.
E.g. to transmit something quickly
E.g. a quick transmission
Look out for signal words like
fastest, biggest, lowest.
In many cases, it makes sense already to deal with the
measuring accuracy.
Referring
to resp. in comparison with whom
or what? How can fulfillment resp.
deviation be measured?
Look out for signal words like
better, faster, easier.
Like here, yesterday,
differently.

139 138
In the requirement Te 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.

Based on the answers to the question, the improved requirement could read like this:
Te library system shall be designed in a way that it meets the guidelines for data security
of standard X.
Te difculty of correcting incomplete comparatives and superlatives can vary. In the above
example, the point of reference can be added through a slight modifcation of the require-
ment. In our next example requirement, on the other hand, the phrase intuitively operable
is hardly measurable, if at all: Te user interface of the library system shall be intuitively
operable for the librarian. Tis requirement would need elaborate rephrasing, with the
introduction of new, measurable criteria. In a frst step, however, we need to question the
desire behind a stakeholders phrase intuitively operable.
Tis stakeholder surely had some very specifc things in mind when writing this requirement
. Te 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: Te library system
shall be designed in a way that the librarian can complete each lending process within 5
clicks.
It is defnitely worthwhile to explore this and to replace such efect-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 require-
ments. In project reality, we often experience diferent variants. Tere are projects where both
kinds of requirements are strictly separatedwhich poses the question whether it is really
possible to test all requirements independently during acceptance. In other projects, however,
the emerging specifcations contain requirements which include functional as well as non-
functional aspects. Similar to many other aspects of life, we should strike the right balance.
Secure in relation to what resp. secure from whom?
What makes customer data secure?
By which criteria can secure be tested within acceptance?
It can be helpful to
question characteris-
tics in a paradox way,
e.g.: How does a sys-
tem have to be de-
signed to be NOT
intuitively
operable?
Separate non-functional aspects from functional requirements if at least
one of the following conditions is fulflled:
The non-functional aspect can be tested independently OR
The non-functional aspect is generally needed as a non-functional
constraint for several functionalities.
Rule #9: Formulate separate requirements for
non-functional aspects.
Te decision whether functional and non-functional aspects
should be separated from each other is not always easy.
An example: Te requirement Te library system shall
save the new customer data entered within a maximum
duration of one second should be left unchanged, if the
allowed time is only valid for the specifed functionality, which is
the saving of new customer data. Extracting the allowed time and writing an own require-
ment 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. Te master data of
new library items, for example, or changes of customer data have to fulfll this requirement as
well. If this is the case, create a separate requirement: Te 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 fgure 6.5, you have uncovered missing informa-
tion in the descriptions of characteristics. In doing so, you have analyzed non-functional
aspects (attributes) and transformed qualifed statements into measurable requirements.
Separate non-
functional
aspects
Analyze
characteristics
Figure 6.5: Te two steps for checking characteristics
Can the
characteristic be tested in-
dependently? Is it demand-
ed globally?
Analyze missing
information on
characteristics!
Formulate comparisons and superlatives in a
way that they can be measured and tested!
Formulate separate re-
quirements for indepen-
dently testable and/or
globally valid
non-functional aspects.
Intuitively operable in relation to what?
What makes a user interface intuitively operable?
Which yardstick can be applied during acceptance?
141 140
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 specifed. It is important, however,
that the issues are grouped correctly (see transformation efect generalization in
section 6.2.2).
Signal words that indicate a generalization of knowledge are numerals or quantifers 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 quantifers
With requirements, you specify functionalities or characteristics which should be valid for a
defned amount of objects. In natural language, we are using numerals or quantifers to do
this. In a requirement, a statement is then made on the behavior or the characteristics of this
set of objects.
Te requirement Te 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 quantifers is that possibly the specifed behav-
ior or characteristic does not apply to all objects of the set described. Often, the set contains
elements that are exceptional cases for which the specifed behavior would be wrong. It is
your task as requirements engineer to uncover such exceptional cases by targeted questioning
of the numerals and quantifers 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.
E.g. save customers name, save customers ad-
dress can be comprised with save customers
registration data.
Look for signal words like all,
every, always, never, ...
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 quantifers used in the requirement.
If you fnd that the set has been grouped erroneously, you have to:
Narrow the set of objectsif only a part of the whole set is concerned,
OR
Broaden the set of objectsif there are further objects concerned.
Probably there will be also exceptions you have to specify additionally.
Rule #10: Question the numerals and quantifers used.
In the requirement Te library system shall pro-
vide each library user with the ability to edit all
customer data., you should question the quanti-
fers each library user and all customer data.
If your questioning reveals that there are exceptions, then these have to be specifed. Further-
more, you have to change the original requirement: Te 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 quantifers for
the specifed behavior or characteristic. Missing statements on this imply that the specifed
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.
For each behavior and each characteristic demanded, the set of objects this
specifed behavior or characteristic applies to has to be explicitly
described.
Check whether the requirements can be completed with numerals or quan-
tifers. 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
quantifer to the requirements .
Rule #11: Clarify missing numerals and quantifers
Is the de-
manded behavior or characteristic
really valid for all objects of the set?
Or are there any exceptions?
Does really every customer have to
be able to edit the customer data?
Does really every customer have to be able to edit
all customer data ever stored within the system?
143 142
Te example requirement Te library system shall
provide the user with the ability to archive the
stored data via tape backup. contains, for in-
stance, no explicit numerals or quantifers. Tere-
fore, 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 quantifers
have to be specifcally questioned and, if necessary, added to the requirement.
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?
Te 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. Te demanded scope should probably be cleared
prior to commissioning of the systemat 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 quantifers to be used to a number of clearly defned ones.
For the above example requirement, the analysis could lead to this improved requirement:
Te 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 fnd nouns in requirements that
describe actors or objects in such a vague way that there is more information needed to
specify them unambiguously.
Te 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 require-
ment applies.
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.
If a noun describes set of objects that cannot be exactly defned, informa-
tion has been deleted from the original sentence.
Question unclear formulated nouns and fnd out for which objects or actors
exactly this requirement should be valid. Afterwards, add the deleted infor-
mation to the requirement.
Rule #12: Question vague nouns
For instance, the librarian states: Te data has to be graphi-
cally displayed to the user. In this requirement, at least the
nouns data and user have to be analyzed in more detail.
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.
Tis 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.
Moreover, the adverb graphically has to be described more precisely. In many cases, such
questions lead to a refnement of requirements; i.e., for instance, when the answers reveal that
the diferent statistic data require diferent graphical representations.
The two steps for checking amounts and frequencies
Now, you will be done soon. After having gone through the steps depicted in fgure 6.6,
you identifed and eliminated the linguistic efects concerning amounts and frequencies.
To achieve this, you checked numerals and quantifers, as well as vague nouns to fnd out
whether objects or actors were grouped correctly.
Check
numerals
and quantifiers
Analyze
nouns
Figure 6.6: Te two steps for checking amounts and frequencies
Now, you are only a few steps away from the nearly perfect requirement.
To which users exactly?
Which data exactly?
What exactly does graphically mean?
Which data of library items exactly?
Question missing numerals
and quantifiers!
Analyze missing informa-
tion regarding nouns!
Assure the correctness
of the used numerals
and quantifiers!
To which
objects exactly should the de-
manded behavior resp. the charac-
teristic apply?
Who/what
exactly? Which part of the
set?
145 144
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 fulfll the
requirement and which means are to be used to achieve this. Tis applies particularly
for complex operational processes, the so-called business logic.
Step 1: Check what is possible and what is impossible
We often experience that requirements only specify the results of complex cal-
culations, for example: With each radar update, the fight plan route shall be
calculated anew. Often, it is simply not sufcient to claim that certain results should be
obtained; the specifcation 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

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 (specifcation 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).
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 identifed business logic to the
requirement.
Rule #13: Clarify what is possible and what is impossible
If a requirement contains terms that express that something
should be possible resp. impossible, you can, in most
cases, rephrase these requirements as a construction
that says that something prevents resp. renders it pos-
sible that something else is possible resp. impossible.
In a stakeholders requirement, however, it is often only
the latter part of the sentence that is expressed. Te frst
part of the sentence (the justifcation) then stays unanswered.
If this is the case, the condition that makes the demanded behavior possible or impossible
in the frst place has been deleted. Tis is why you should always check whether all relevant
preconditions and persistent conditions are documented.
Oops, how is a pro-
grammer, who is not
accidentally an ex-
pert in the field of
flight security, sup-
posed to know how
this is to be
calculated?
Look out for signal words like can,
may, it is (not) possible, it is be-
yond possibility.
Analyze the business
logic, not the techni-
cal solution!
If you question what
is possible resp.
what is not possible,
you will find forgot-
ten preconditions.
Lets 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?
Te 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 users 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 customers dunning history, the library system shall
display the error message overdue items to the librarian.
Te 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 fulfll this claim as well. Te 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 customers parents
present, the library system shall display the error message Customer younger than 18 to
the librarian.
Tis statement is already a bit clearer; it still contains efects, however. Te additional infor-
mation 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 confrm the presence of a written consent
by the customers parents.
The step for checking what is possible and what is impossible
After having applied the step depicted in fgure 6.7, you have added the missing busi-
ness logic to the requirement (if necessary) and have cleared the requirement of the worst
linguistic defects.
Question the
possible/
impossible
Figure 6.7: One step for checking what is possible and what is impossible
What makes this
impossible?
Where does the sys-
tem get the required
information from?
Through who or what
will this be
prevented?
Which business logic
is it driven by?
Analyze the business logic
underlying the requirement!
Analyze required
preconditions!
What makes the behavior
possible/impossible?
Which business logic is it driven by?
Which precondition has to be fulfilled?
The linguist calls
these modal opera-
tors of possibility.
147 146
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
Te only subordinate clauses relevant for requirements are logical and temporal
conditional clauses (comp. Chapter 7 Templates).
Subordinate clauses containing reasons, intentions or consequences should be eliminated
from the actual requirements and noted as a comment. Tey are superfuous for the actual
system description and only lead to irritations, in the worst case even to misunderstandings.
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 clauses 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.
Rule #14: Extract irrelevant information.
Te following example from our library system shows a require-
ment of a kind that we fnd in specifcations all too often: As
it makes the creation of library item statistics easier for the
librarian, the library system shall ofer a wizard.
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 im-
plemented, it does not contain a demanded functionality of the system. Tis is why this
subordinate clause should be converted into a comment.
Te above requirement would then read: Te library system shall provide the librarian
with the ability to create library item statistics with the help of a wizard. Te remaining
subordinate clause, which only contains the reason for the requirement, is added as comment
to the respective requirement: Comment: Tis makes the creation of library item statistics
easier for the librarian.
Look out for sig-
nal words like
as, because,
for the purpose
of, due to
Which
relevance has the information in
the subordinate clause?
This is the logical reason for the requirementbut it is
irrelevant information for the system description
If you fnd, however, that the subordinate clause contains something of importance for the
systems 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.
Eliminate or shorten all parts of the sentence that can be taken away with-
out loss of meaning:
Redundant information
Flowery phrases and expressions
Rule #15: Avoid redundant information.
Tere are many requirements which you can condense without loss of information. Te
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 func-
tionality to the user.
The two steps for checking the sentence
Congratulations. After having gone through the steps depicted in fgure 6.8, you now have
not only recognized and eliminated all semantic efects in your requirements, but also freed
your requirements from ballast.

Figure 6.8: Te two steps for checking the sentence
Is there
anything doubled or expressed
with set phrases?
Small in size --> small
Yellow of color --> yellow
A true fact --> a fact
Check
subordinate
clauses
Remove
redundant
information
Clarify the relevance of
subordinate clauses!
Check for redundant information
and void or flowery expressions!
149 148
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 specifcation.
Step 1: Analyze exceptions to the usual behavior
To describe a systems 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 con-
straints or marginal conditions under which that would not be possible.
Unfortunately, in reality systems are dependent on external infuences; data or events, for
example, that are expected for further processing may fail to come. Describe the systems
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 .
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.
Te requirement Te 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?
Look out for signal
words like
must, shall,
should, it is
necessary that...
Apply this searching
method especially to
freely formulated
requirements.
Is the
system always able to guarantee
the demanded behavior?
What happens if it cannot?
Which exceptions are possible?
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.
Rule #16: Analyze exceptions to the usual behavior
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 prob-
ably rather expect it to show a defned behavior. Potential problems, for example, should be
displayed to the user during data transmission via user interface. Tis way, the user can restart
the data transmission. After having answered the questions, the behavior in exceptional cases
can be specifed 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.
Te description of a systems exception behavior is often neglected. A full defnition of a
systems behavior in exceptional cases can be as elaborate as defning the systems behavior in
normal cases. Tis is likely to be underestimated.
Terefore, take these eforts into account from an early stage. Very often we experience in
project reality that the defnition of a systems 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.
Step 2: Analyze incompletely specifed conditions
Similar to the specifcation of exceptions (see previous rule) which describes the systems
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.
fulflled. It is important to also describe what should happen if the condition is not fulflled.
In our experience, however, the latter information is often neglected in system specifcations.
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 ques-
tion concerning the system behavior in case a library item was reserved remains unanswered.
Specify possible ex-
ceptions immediately
when eliciting the
user requirement
(from specification
level 2 on).
Look out for signal
words like if...
then, in case...
then, should ...
<infinitive> or
dependent of.
Each conditional behavior needs at least as well the description of what
should happen if the condition is not fulflled.
Clarify the systems behavior in case (or cases) the condition is not fulflled:
Specify an additional requirement for each condition that has not been
described yet OR
Expand the original requirement by the missing cases.
Rule #17: Analyze incomplete conditional structures.
The linguist calls these modal operators of necessity.
What is the desired
system behavior in
case the library item
is reserved?
151 150
In our library system, settling the question of the system behavior in
case of a reserved library item would only lead to an ex-
pansion if the demanded system behavior had not been
described yet. If this is the case , the system behavior
expected if the condition is not fulflled has to be
described, for instance by writing an additional re-
quirement: If the library item is reserved, the library
system shall display an error message to the librarian.
As an alternative, you could also expand the original requirement:
After the library system has checked the library items 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 Li-
brary 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 (fulflled/not fulflled resp. reserved/not reserved).
Often, you have to distinguish exactly between diferent cases. As an example, let us check a
requirement from the library system: After the library system has identifed 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.
Tere are several questions that have to be answered on this requirement and then described
in the requirements document. Analyzing these diferent possible cases can lead to highly
complex requirements. How complex requirements may become can be seen if we add condi-
tions to the above requirement: If a library users dunning history shows more than fve
overdue library items, the library system shall destroy this library users library card. and
Te library system shall display a warning message to the librarian if there is a damaged
return on the library users record.
Conditional requirements can become extremely complex. Using natural language to express
such complexity then results in confusing, interlaced requirements. Tere are more appropri-
ate means you can employ, for example decision tables.
Tese 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.
Write separate requirements if there are many cases that need to be distinguished.
Otherwise, simply expand the original requirement.
What is the desired system behavior in
case the library user has borrowed at
least 24 library items without returning
one?
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).
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. Tey are assumed to be known or the stakeholders shy away
from writing down things they consider banal or commonplace. We call this
muscle memory.
However, these implicit assumptions have to be made explicit at some
point (Quality criterion Completeness, see Chapter 1 In Medias
RE). Tis 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.
However, if there is only a tiny bit of information hinting towards an implicit assumption,
you will be able to discover it using the SOPHIST Set of REgulations. To support you in
doing this, we have summarized our experience towards discovering implicit assumptions
into one further, fairly simple rule:
Requirements frequently contain a statement (in most cases only stated
incidentally) which has to be trueotherwise the basic requirement cannot
be fulflled. Such statements are then your signal words indicating implicit
assumptions, e.g.
Descriptions of temporal or logical sequences
Nouns which are more precisely described by a reference word
Analyze implicit assumptions by applying the following steps:
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.
Write one or more additional requirements for each functionality that has
not yet been described.
Rule #18: Analyze implicit assumptions.
I.e. the stakeholders are not any longer actively
conscious of the profound knowledge they have.
The only thing that
can help you now:
Creating views in
the use-case ap-
proach
Appropriate elici-
tation techniques
Logic common
sense
How is
the system expected to act in
case the condition is not fulfilled?
Are there any other cases?
Look out for signal
words like If, In
case, After, As
soon as, When ...
Look out for signal
words like entered cus-
tomer data, displayed
view, computed capital
value...
153 152
As an example of how to apply this rule we will have a look at the
following requirement from the library system: After the
library system has saved the entered registration data of a
new library user, the library system shall print a library
card.
Te core functionality of the requirement Printing
library card only makes sense if we assume that the library
system has saved the entered registration data.
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: Te library system shall save the registration
data of a new library user . Of course, this additional requirement has to be deeply analyzed
regarding semantic efects afterwards. Ideally, you start with rule #1.
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 fnd that the reference
word entered in front registration data indicates that there has to be a functionality for
entering registration data. If you fnd that this functionality has not been already specifed by
at least one requirement, information has been deleted: Te 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.
Figure 6.9: Te three steps for checking the overall picture
If you continue this systematic approach requirement by requirement, you will step by step
get to a complete specifcation document of high quality.
Is there already a
requirement that de-
scribes that regis-
tration data can be
entered?
Analysis of
exceptional
behavior
Analysis
of conditions
Analysis
of implicit
assumptions
6.8 Application of the SOPHIST Set of REgulations
Te 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.
Often, requirements templates are applied additionally. Tose 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 efects at diferent 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 require-
ments engineer immediately checks every statement made by the interview
stakeholder for linguistic efects. He or she directly asks for the missing infor-
mation considered important. In this ways, the information needed is elicited
very efciently within the interview, as knowledge gaps are immediately uncov-
ered. If the requirements engineer is experienced in this feld, 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. Te interviewed person will only realize that the discussion will
get to the point very quickly. Te documentation of natural-language require-
ments 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 efects 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.
Categorize semantic effects Find signal words
Ask questions Remove semantic defects
Steckt in
der Anforderung eine implizite
Annahme? Ist diese Aussage bereits
irgendwo in der Spezifikation
beschrieben?
Analyze exceptions to
the usual behavior!
Analyze all
possible cases!
Analyze statements that have to be
true for the requirement to make sense!
Paper doesnt blush,
so you can practice
this technique on writ-
ten requirements.
Is there already a requirement that says that registration data has to be saved?
This, of course, needs
some practice. Yet, it
is very effective.
155 154
Of course, even requirements engineers are not immune to the unwanted defects of focusing
and simplifcationspreparation is necessary. If using the method for the frst 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 ofenders.
Te 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 require-
ment does not need a logical or technical condition, you do not have to construct an artifcial
condition or analyze diferent possible cases.
As soon you feel confdent enough in the application of the rules with high priority, pull out
some more from your box of tricks.
And at last, if you want to (or have to) be an expert, apply the remaining rules to your
requirements.
However, despite being an expert, you should never mutate into a perfectionist. Do not strive
without any refection towards requirements absolutely freed from all defects, but always
consider your projects 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 efort and high costs. Perfectionism thus quickly turns into luxury most projects
cannot aford.
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.
If you are experienced in the application of the most important rules of the SOPH-
IST 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.
Follow the principle:
appropriate over
perfect!
In our experience, the following rules of the SOPHIST Set of REgulations should be
considered the most important:
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 #1
Rule #2,#3 or #4
Rule #6
Rule #10 and #12
Rule #17
Rule #16
Rule #18
Rule #8
156
6 The SOPHIST Set of REgulations
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 specifcation level.
I know the most important signal words and am aware which signal
words indicate which questions.
I understand the diferent points of view (parts of a sentence, sen-
tence, 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.

The SOPHIST Set of REgulations for Requirements Psychotherapy

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The SOPHIST Set of REgulations for Requirements Psychotherapy

Uploaded by

Copyright:

Available Formats

6

You might also like