6 requirements engineering and management the sophist set of regulations

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 unvollständigen, verzerrten oder sogar falschen Informationen führen.

■ Mittels SOPHIST-REgelwerk, das auf dem Therapieansatz „Neurolinguistisches Programmieren (NLP)“ basiert, können Sie Lücken und Verfälschungen in Ihren Anforderungen systematisch aufdecken und gezielt beheben.

■ Therapieren Sie Ihre Anforderungen Schritt für Schritt — diese Regeln helfen Ihnen dabei, wirklich das zu verstehen, was Ihr Gegenüber 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.

117116

6 The SOPHIST Set of REgulations 6 The SOPHIST Set of REgulations

In psychotherapy, building upon several of Chomsky’s theses, a model of human commu-nication and mode of expression has been developed and fine-tuned. The psychologist and professor for linguistics John Grinder and computer scientist and Gestalt therapist Richard Bandler played a substantial role in this process. In the mid-seventies of the twentieth century, it was their goal to develop a form of therapy which could effectively be learned and applied by anybody and which was based on the premise that the therapist gains a deep understand-ing of the reality the patient perceives. In order to achieve this, the therapist has to find out what exactly the client means by his statements.

6.2.1 Transformation Processes

Every analyst is confronted with requirements which describe an existing system or one which is to be developed. When people describe a system , i.e. formulate natural-language requirements, a transformation process (as shown in figure 6.1) happens.

��

��

��

��

��

Figure 6.1: Transformation as possible destroyer of information

Starting point (left side in figure 6.1) is the reality to be described; the system which the stakeholders actually require. On the right side, however, we see the system as it has been described; those requirements which the system analyst gets to see in the requirements 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 different stakeholders— people with varying levels of prior knowledge, social background and experience. This diversity is reflected in the requirements and harbors the danger of loss of information, 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 deficiencies of natural language.

You are familiar with these fundamentals or consider them too theoretical? No problem. Skip directly to the descriptions of the first rules of the SOPHIST Set of REgulations (see section 6.3), which we have successfully applied along with our

customers in a great number of projects. To make the rules easily applicable for you in your daily work, we have focused on providing many examples. Moreover, you will find a lot of tips and tricks from our project experience that will help you apply the SOPHIST Set of REgulations.

6.2 The Roots— Neuro-linguistic Programming

The SOPHIST Set of REgulations is fundamentally based upon the meta-model of language provided by the therapeutic approach neuro-linguistic programming (NLP) [Bandler75], [Bandler94]. The rules of NLP help therapists to make people aware of their inherent 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 effects in natural-language requirements. One of the forerunners in the development of approaches based on natural language was the linguist Noam Chomsky [Chomsky65], who researched important fundamental linguistic concepts and described these in his transformational-generative grammar (see article at .sophist.de)

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.

119118


Transformation processes result from our human nature. Every human being‘s perception is influenced by their social character, their prior knowledge and their experiences. Psychologists call this the “personal reality“. The personal reality has impact on the personal perception of reality, so every person has their own idea of reality.

For example: we show the same library item, a book, to librarian A and librarian B. Librarian A instantly captures the attractive layout with graphics that harmonize with the textual body and loosen up the overall picture. Librarian B, on the other hand, perceives the same book in a totally different way. He sees the clear structure of the work with introduction, body and conclusion, easing the reader‘s understanding. He does not notice the appealing illustrations at all. Both librarians have thus different images (as psychologists say: models) of the same book—the same reality.

Yet, how can it be that librarian A solely concentrates on illustrations and layout whereas li-brarian B mainly notices the thematic structure? This phenomenon is what psychologists call perceptional transformation. Each person unconsciously applies such transformations in perceiving reality, depending on their personal reality.

We can draw an important insight for systems analysis from this: the total knowledge about reality is always “distributed across several minds“ as every person

only perceives a fraction of the actual reality.

As a consequence, it is not enough to question only one librarian for a complete image of the reality.

Interestingly, transformation can be found at another spot in the process from reality to requirements. That is where personal knowledge is expressed in natural language (referred to as “knowledge representation“ in figure 6.1). If you question librarian B on the structure, he might say “very practical“, although he means the detailed structure with introduction, body and conclusion. He therefore transforms his personal knowledge while expressing it in natural language.

In the same way a person writing requirements or a person being questioned in an interview transforms their knowledge in formulating requirements.

As we have seen, there are two kinds of transformation processes:

Perceptional transformations occur since every person perceives reality in a differ-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 difference 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 person‘s individual image cannot be easily influenced. 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.

The different experiences and opinions resulting from questioning several persons do not only prevent perceptional transformations, but also enrich every project. Emerging synergies can lead to an overall better system to be constructed.

Representational transformations (personal knowledge linguistic expression), on the other hand, can fortunately be undone very well—provided the requirements engineer knows the different kinds of transformations and their consequences exactly.

To eliminate transformations in knowledge representation, the requirements engineer can make use of the SOPHIST Set of REgulations.

Representational transformations are also subject to research in linguistics. Linguists assume that in their mind, every human being builds a complete linguistic representation of their perception, which is called the deep structure . If the human then starts to talk or write, they take a series of decisions concerning the form of the information to be expressed, thus creating the related surface structure . From a set of transformations, they choose one specific or, more often, several transformations to apply on the deep structure. In this way, the surface structure develops.

A sentence (a surface structure) is thus a different form of the “original“ (the deep structure) in a person‘s mind. However, the surface structure may lack certain parts, or parts of it may be distorted. From this assumption, the (linguistic) goal of requirements analysis is derived:

In order to achieve a complete and unchanged image of a stakeholder‘s personal reality, the requirements engineer has to identify the deep structure of the respective

surface structure.

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.

121120


The fact that people stick to certain rules in the construction of surface structures made Chomsky assume that people‘s behavior in the creation of linguistic expression is driven by rules. A possible (and plausible) set of rules was first presented in Chomsky‘s aforementioned transformational-generative grammar.

Similar to Chomsky‘s approach, we can define rules in system analysis as well, enabling a sys-tematic discovery of transformations in requirements written in prose and in the customer‘s statements. The requirements engineer wants to understand a part of the author‘s personal reality, but only knows their linguistic surface structures. If the requirements engineer is then able to determine the transformations applied, he or she may find by targeted questioning the deep structure of what the author tried to express.

6.2.2 Categories of Representational Transformation

Based on linguistic findings, Bandler and Grinder distinguish in NLP between three prin-cipal “types of remodeling“: deletion, generalization and distortion. This classification may perhaps appear not to be disjunctive . It has, however, been tried and tested in practice and been found useful.

In figure 6.2, these three categories are represented with graphical symbols. In the following sections, we will use these symbols to assign the respective type of remodeling to each rule of the SOPHIST Set of REgulations.

DELETION is an indicator for incomplete information. DISTORTION is an indicator for

statements falsifying reality.

GENERALIZATION is an indicator for erroneous generalizations.

Figure 6.2: Classification of linguistic effects

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. These definitions are of purely linguistic nature, but can be applied to linguistic effects in the context of requirements as well.

Deletion

The 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 filter out the general vocal background noise within a room, so that only the voice of our interlocutor reaches us consciously (selective perception).

Deletion is a process by which we selectively pay attention to certain dimensions of our experience and exclude others. Deletion reduces the world to proportions which we feel capable of handling [Bandler94].

This reduction may be useful in some cases; in requirements for a software system, however, important information can be destroyed by it. For example, one librarian may say: “At the end of each month, the accounts are debited with the incurring fees.“ Another librarian, familiar with the working processes within the library, will probably be able to reconstruct the deleted parts of this statement: “There are overdue fines to be paid by customers exceed-ing the loan periods.“ A listener not familiar with the deleted information, however, could understand librarian A‘s statement in a totally different way.

Generalization

Generalization is a process in which a singular experience (parts of a personal model) is transferred to similar or related issues and therefore taken as universal.

The human ability to generalize experiences is a process which can be crucial to survive. An example of such a generalization is the painful encounter with a hot stove from which a child generalizes correctly that all hot stoves are dangerous and not only the one the child burned itself on. A less correct generalization would be the fundamental fear of touching stoves (i. e. also cold ones) or the assumption that one could only burn oneself on this particular one. What remains is the knowledge that touching any hot stove will lead to unwanted burns; hopefully also caution towards all stoves (as they may be hot).

123122


Generalization is the process by which elements or pieces of a person‘s model become detached from their original experience and come to represent the entire category of which the experience is an example [Bandler94].

Generalization is helpful and makes sense in the context of systems analysis as well. However, one thing is very important: you have to group the issues to be generalized very carefully, so that the system behavior or attribute to be described matches your grouping.

Too strong generalization leads to global requirements for the system which probably are only correct and suitable for a part of the system. Exceptions and error cases often become lost. For example, the librarian could state that the IDs of all books belonging to the art section start with ART. However, the art section also includes folios which due to their oversize do not fit into the shelves and therefore have been stored in another place. These folios are tagged with an ID starting with FOL. The librarian accidentally forgot this exception.

Distortion

Distortion is the process when reality is rearranged or even falsified, leading to a distorted picture of an aspect of reality in the receiving person.

Distortion happens when a situation is described in expressions not suitable for that situation. In this way, the situation is embellished or obfuscated, influencing one‘s own perception or, although in most cases unconsciously, the receiver‘s perception. The phenomenon of distortion makes it easier for a human being to integrate new information into their personal worldview. Many a detail is changed a bit if necessary

to fit into an already existing image of a situation.

This is why we often change a piece of information or our perception in a way that feels right to us. Each distortion is able to destroy a lot of information and is therefore implicitly a deletion as well.

Distortion is the process which allows us to make shifts in our experience of sensory data [Bandler94].

Distortions are a hard nut to crack for every requirements engineer as often he will not be able to decide whether a statement has been worded correctly, whether it has been distorted or whether the requirements engineer himself will be distorting it by his own perception. For example, a librarian states that there shall be a blocking with every reservation. The librarian distorts the fact, as he considers the “blocking“ as being self-evident and therefore expresses it in a simplified way. However, it may be possible that the process consists of several complex process steps.

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 effect may lead to low-quality require-ments, yet not in all cases to a defect as well.

Whether a linguistic effect is a problem and should be corrected, depends on many constraints. The level of detail you are writing requirements on is surely an important factor.

Linguistic effects on the level of goals or rather generic requirements (e.g. specification level 0 and 1, see chapter 3 “From the Idea to the Specification“) are common and even not always preventable on those levels of detail.

However, as there will be readers who will deal with your specification only on these levels, it is necessary that information important for these readers will not be destroyed by effects.

As a consequence, you should stick to certain rules even on specification levels 0 and 1:

■ Always write your requirements in complete sentences.

■ Always use active voice (see rule 1 in section 6.4.1).

■ Use consistent terminology and avoid synonyms or homonyms.

■ If you already have a glossary (see chapter 8 “Documenting Requirements“ and chapter 7 “Templates“), use the terms defined in there.

■ Express processes via main verbs.

If you write very detailed requirements (from specification level 2 on), which moreover are to become part of a contract for an external assignment, linguistic effects are far more harmful and therefore should be analyzed and, if possible, eliminated. Even if your requirements are syntactically well-formed , they may contain linguistic effects. It is now your task to discover and correct these effects, provided the missing or distorted information is significant.

This is why we recommend applying the rules of the SOPHIST Set of REgulations basically from specification level 2 on. From this level on you write more detailed requirements which refine requirements from levels 0 and 1.

Like to calculate, to print, to export, to

transfer...

Grammatically correct

125124


No matter what specification level you are writing requirements on, there is one basic rule you should always adhere to:

For each specification level, there is one refinement of the basic rule stated above (“Express processes via main verbs“) to be obeyed always:

■ Always use only main verbs which are “good“ main verbs for the respective specification level, as not every main verb is a main verb suitable for that specification level.

On specification level 1, for instance, the use cases for the library system are defined, one of which is dealing with customer management. Using a main verb, we name this use case “manage customer“. The main verb “to manage“ is fairly suitable on specification level 1. However, from specification level 2 on, we never use the main verb “to manage“ as is to far too vague for the more detailed levels. Therefore, we need to refine the main verb “to manage“ by more detailed main verbs like “to enter“, “to save“, “to display“, which are suitable for level 2.

If you want to avoid the occurrence of linguistic effects from the beginning on, use the SOPHIST Set of REgulations constructively during the elicitation process and while writing your requirements. Do you want to track down effects in requirements you have already documented? Then we recommend applying the SOPHIST Set of REgulations analytically .

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 effects. Concentrate on the information you require for the further process. Investigate in particular those parts where missing or erroneous information represents the highest risk for your project‘s success.

Our experience shows that linguistic effects occur in differing frequency. This is why it is important and advisable to concentrate in the first place on the group of perilous persistent offenders.

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 REgulations—Requirements 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 specifications can be detected in a defined 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, differ-ent linguistic effects can be selectively tracked down in a requirement. Needless to say that although the rules in this chapter solely refer to requirements, they can be also applied to all expressions in natural language, both oral and written.

Applying a single rule from the SOPHIST Set of REgulations is remarkably simple:

■ Step 1: Identify linguistic effects in requirements from signal words.

■ Step 2: Analyze lost or distorted information with means of targeted questioning.

■ Step 3: Remedy linguistic deficiencies or errors in content by rearranging the requirements using the answers given in order to eliminate effects.

Principally, the SOPHIST Set of REgulations is a compilation of rules. In our daily work, however, we often consider it challenging to deal with such a bulk of rules if there is no order defined.

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

127126


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 find yourself frustrated and do not know how to best apply these, in fact, simple rules.

Surely, you ask yourself the following questions: Which specific steps should I take? With which rule do I start, and do I really need all of them? In which order should I apply which rules with what priority?

Figure 6.3: The process of applying the SOPHIST Set of REgulations

In the end, you probably will not be able to avoid all pitfalls of natural language. There is no one and only guideline valid in all situations. Nevertheless, there is a pattern that has proven itself during the application of the rules in several projects. You can see this process in figure 6.3.

Our project experience shows that when checking a requirement you should always proceed from the smallest (the parts of the sentence) to the biggest (the overall picture). Basically, you go through the following steps requirement sentence by requirement sentence:

■ 1. In the first place, check the single words (parts) of a requirements sen-tence in order to complete it step by step with significant, yet deleted informa-tion. Specific words in your requirement sentence are the signal words you have to pay attention to. Each and every signal word points to a specific se-mantic effect. It is also the signal word that tells you which rule to apply.

■ 2. Afterwards, check the whole requirement sentence in order to get rid of unnecessary parts and to reduce it to its essentials. Information irrelevant for the system or meaningless expressions only bloat your sentence and make it unclear. Such sentence parts can be either separated from the requirement and added as commentary or removed without loss of information.

■ 3. At last, check how the requirement sentence integrates into the overall picture to be described. With this control mechanism, you can step by step complete your overall picture—the big picture your requirements describe. Take advantage of the information already given in the requirement sentence. Is for example the specification of a certain system functionality or attribute missing, so that the analyzed requirement sentence does not fit properly into the overall picture? Here as well certain signal words will help you detect even those functionalities or processes almost entirely deleted from the overall picture.

The process described does sound fairly easy. Unfortunately, however, requirements analysis is anything but trivial. Especially when applying the process constructively, you should keep in mind that even when analyzing sentence parts you often not only enrich the analyzed requirement sentence with missing information, but also encounter additional requirements or will have to refine the requirement sentence. In this case, particularly a disciplined ap-proach, processing requirement sentence by requirement sentence, is of utmost importance. Otherwise you may find yourself shipwrecked quickly and will drown in the (partially huge) waves of new requirements or even new processes.

We recommend here to write down the new or refined requirements, but to not yet analyze them in detail directly. You should continue the analysis of the primarily explored require-ments first. 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 reflects the order you should adhere to when applying them. For those readers who are familiar with NLP we have marked each rule that can be reasonably assigned to one of the transformation categories according to Bandler and Grinder with the respective symbol from figure 6.2.

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.

129128


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 specified.

When checking process verbs, your main focus is on the functionality described in a require-ment. The signal word you have to identify is therefore the process verb, in other terms: a verb (or a form derived from the verb) describing a process.

Step 1: Check for active voice

A linguistic effect, namely the deletion of the actor, can be prevented if requirements are formulated in active voice. If a requirement is expressed in passive voice, however, it has to be transformed into active voice.

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“). Thus, the requirement gains in information and the

process verb is detailed by stating who performs the process resp. has to possess a certain characteristic.

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 “The user password shall be entered at a terminal of the library system“ , which is written in passive voice, it is unclear who it is to enter the password. However, if you write in active voice, you have to nominate an actor or party responsible: “The library user shall enter the user password at a terminal of the library system.“

This statement is already a bit clearer, but will not be a requirement for a system for a long time yet. Here, there is solely a call for user action (and you will hardly want to test your user during acceptance). Now derive the requirement for the system, i.e. the functionality the system has to provide in order to enable the user to make the entry.

This may be, for instance, providing an input option for the user password: “The library system shall provide the library user with the possibility to enter a user password at a terminal of the library system.“

Step 2: Identify the demanded functionality

Now that the requirement is written in active voice, linguistic effects blurring the actually demanded functionality can be easier identified if the functionality within the requirement is described by a main verb.

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 find that that the system functionality actually demanded is “to display“. By rephrasing with the main verb “to display“, it quickly becomes clear that more information has to be explored in order to describe the main verb completely. When rephrasing the requirement, you have to answer at least the question what exactly shall be displayed .

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“).

131130


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. The process “to check“ does call for the description of a verifiable result, e.g. “to save data“ or “to display error message“. Therefore, the requirement has to be rephrased: “After the librarian has initiated the saving process for a new customer, and if the age of the newly entered customer is greater than or equal to 18 years, the library system shall save the data of the newly entered customer.“

As a consequence of rephrasing the requirement, you have to make a precise distinction of cases. You have to describe in detail which behavior the system shall exhibit in case of a certain condition or combination of conditions. Of course you will now have to describe the other possible cases of the above requirement as well.

However, it is not always this easy to reveal the palpable functionality demanded. Some requirements are affected by linguistic effects to an extent that the process to be specified is totally obfuscated. It is then up to the requirements engineer to identify the palpable process and state it precisely. Typically, processes can also be found in the form of “nominalizations“ or “light-verb constructions“.

Nominalizations

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 identified 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 sufficient manner somewhere else within the requirements specification. 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 “The system shall allow for archiving.“ , for instance, you will find that the noun “archiving“ is a nominalization. Thus, you have to ques-tion the stakeholder‘s genuine intention. The process to be covered by that requirement will, expressed as main verb, probably be “to archive“. An improved requirement, answering the question about “What is to be archived?“, could then be the following:

“The library system shall archive the data of library items which have been sorted out.“

In the example requirement “At the return of a reserved library item, the library system shall send a notification to the customer who reserved the item.“ the words “return“ and “notification“ are both nominalizations which have to be analyzed.

If all information needed to answer the question is already written down in the requirements specification, the above requirement may remain almost unchanged. Only if the nominaliza-tions “return“ and “notification“ blur processes which are not entirely specified or defined yet, the missing information has to be added to the specification.

If a nominalization distorts a (possibly complex) process, the process usually has to be described with all steps included by a set of suitable requirements, as well for the expected standard behavior as for the behavior in exceptional cases. In the above requirement, the “return“ of a library item could possibly consist of the following steps: “choose library item“, “change status of the library item“, “refresh customer‘s number of library items borrowed“ ...

To describe this process, a number of requirements is needed. In the next step, you have to check whether these requirements are already specified in the requirements specification. If not, you have to add these requirements. In accordance to rule #2, you first have to identify the main verb for each nominalization blurring a functionality (like “to choose“, “to change“, “to refresh“) and then to analyze it in detail (see Rule #6). If for the library system the “return of a library item“ is not specified yet, this means the introduction of a new use case “return library item“ as well.

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 justified by the professional context, ■ The term is defined in a place accessible to all people involved, ■ The definition of the nominalization leaves no space for interpretations.

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“?

133132


Among others, nominalizations are sometimes used to describe an object involved in the process rather than the process itself. If you have defined the nominalized term 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 “notification“, as the “notification“ in the context of our above example requirement would represent an object to be sent.

If you use nominalizations in your requirements to name processes, we recommend 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 different things that should be distinguished from each other, like an object associated with a process and the process itself.

Light-verb constructions

Often, a system‘s functionalities are described by so-called “light-verb constructions“. Light-verb constructions are combinations of verbs which are lacking substance (to do, to be able, to have, to be etc.) and qualifying nouns.

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.

The 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 specified main verb “to change“. An improved requirement could read like this: “After the library user has borrowed a library item, the library system shall change the status of the library item to the status “borrowed“.

We have listed resolving light-verb constructions as a separate rule within the SOPHIST Set of REgulations, as we have experienced that they may, similar to nominalizations, blur not only one or several functionalities, but even a complete use case. Thus, in the requirement “Statistics should be put at the librarian‘s disposal.“ the light-verb construction “to put at one‘s disposal“ could include the processes “to create“, “to display“, “to print“, “to import“ and many others.

E.g. the “notification“E.g. the “notification process“

Look out for signal words like “to put at one‘s 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 one‘s 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. This means, for example, taking a deeper look at the functionality by letting the requiring person answer the five W-questions (see rule #6).

The question “In what form must the statistics be provided?“, for example, could reveal that sta-tistics have to be provided in electronic form as well as printed on paper. Moreover, the source of the statistics needs to be defined. An improved requirement could read like this: “The library 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 identified 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. Different functionalities expressed by main verbs, however, usually need different additional information. At least for analyzing this additional information, you should create several requirement sentences to cover those different functionalities.

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 identified 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 “The library system shall provide the librarian with the possibility to enter and save data of a new customer.“ , the result will be the following separate requirement sentences:

“The 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.

135134


For example, you would have to question the main verb “to display“ in the requirement “Customers who are not authorized are displayed by the system.“

Some question can be more or less answered with information given in the requirement. The answer to the question “What is to be displayed?“, for instance, will probably be: “a message on non-authorized customers“. On the other hand, several questions remain unanswered: “To whom will be displayed?”, “How will be displayed?“, “When will be displayed?“, “How often will be displayed?“. Here we have linguistic effects which call for a deeper analysis. If the deleted information is of relevance, you need to complete the requirement with this information.

After having incorporated the answers to the questions into our requirement, its improved version could read like this: “After the library system has checked the customer‘s library card and if the customer is not authorized to borrow the library item, the library system shall display to the librarian the error message “Customer not authorized“.“

Another example of an effect-ridden requirement is the following: “The user shall be able to search.” This requirement as well leaves a lot of questions around the main verb “to search“ unanswered. Yet, the requirement has to answer them. What can be searched? How often can be searched? With which criteria can be searched? When resp. under which conditions can be searched?

Correcting the incompletely specified process verb can lead to laborious rephrasing of the requirement. Often, the answers to the questions result in additional requirements. Another possible result is that you find that the original requirement has to be refined by several detailed requirements which replace it.

The four steps for checking the process

Let‘s put it in a nutshell. Along the steps depicted in figure 6.4 you have phrased your requirement(s) in active voice. All functionalities to be specified have been described us-ing main verbs, and all open questions regarding the process verb have been answered and integrated into the requirements.

Figure 6.4: The four steps for checking processes

��

��

��

��

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 requirement‘s process verb using the typical W-questions. In case you find 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 effects in requirements, the requirements engineer poses targeted questions on all aspects of the process verb. The 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 sufficiently speci-fied 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!

137136


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.

The characteristics of a system refer to the description of non-functional aspects of the system to be described. In requirements, characteristics are mainly described with adjectives and adverbs. For the description of system characteristics, however,

only an adjective or adverb will not be sufficient.

There is further information that has to be added to the characteristic. The adjective “secure“, for example, needs the information what has to be secured, who or what it has to be secured against, who secures and how this has to be done. Here as well it is your natural feeling for language which helps you find missing or distorted information.

When checking adjectives, your main focus is on the characteristic of the system described in a requirement. The signal word you have to identify is an adjective or an adverb, which is a word describing a characteristic or a condition in further detail.

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 find yourself unable to answer all W-questions with the information provided in the requirement, then information has been deleted.

If the missing information is relevant, add it to the requirement.

Rule #7: Analyze missing information on the adjective or adverb.

In the requirement “The library system shall be intuitively operable.“ , for instance, you should question the charac-

teristic ”intuitively operable“. The linguistic effects 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 effects) could read like this: “The user interface of the library system shall be intuitively operable for the librarian.“

Often, we find non-functional aspects in functional requirements. Those are described by adjectives which either come as attribute of a noun or are modifying verbs (adverbs).

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“.

The claim for “quick printing“ indicates that the printing process shall be completed in a certain amount of time. In a first step, we can derive the following non-functional require-ments from this: “The library system shall complete the printing process of the library card quickly.“ Obviously, this does not answer the question on the palpable time behavior of the printing process: “What exactly does “quickly” mean?“ We have formulated a separate rule for the analysis of this kind of linguistic effects.

This rule says that adjectives or adverbs in requirements frequently describe comparatives or superlatives . Yet, comparatives and superlatives always require a concretely specified point of reference as additional information. The comparison “faster“, for example, needs information on how much faster than what something has to be or how fast exactly it has to be.

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.

139138


In the requirement “The library system shall manage the user data securely“ , for instance, you have to analyze the point of reference of “securely “ and add the information gained to an improved requirement.

Based on the answers to the question, the improved requirement could read like this: “The library system shall be designed in a way that it meets the guidelines for data security of standard X.“

The difficulty of correcting incomplete comparatives and superlatives can vary. In the above example, the point of reference can be added through a slight modification of the require-ment. In our next example requirement, on the other hand, the phrase “intuitively operable“ is hardly measurable, if at all: “The user interface of the library system shall be intuitively operable for the librarian.“ This requirement would need elaborate rephrasing, with the introduction of new, measurable criteria. In a first step, however, we need to question the desire behind a stakeholder‘s phrase “intuitively operable“.

This stakeholder surely had some very specific things in mind when writing this requirement . The desire behind such a formulation could be, for example, a wish for a help system that can be consulted during user interaction, containing several levels of detail with information on possible input values, reactions and exceptional conditions of the action. However, it could also mean a request for menu navigation, an interactive tutorial, speech recognition, multiple-language navigation or conformity to established user-interface standards. It may also be that the desire underlying this requirement is as simple as this: “The library system shall be designed in a way that the librarian can complete each lending process within ‚5 clicks‘.“

It is definitely worthwhile to explore this and to replace such effect-ridden requirements with more detailed ones.

Step 2: Check for possible separation of non-functional requirements

Not negligible, yet often neglected is the separation of functional and non-functional require-ments. In project reality, we often experience different variants. There are projects where both kinds of requirements are strictly separated—which poses the question whether it is really possible to test all requirements independently during acceptance. In other projects, however, the emerging specifications contain requirements which include functional as well as 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 fulfilled:

■ The non-functional aspect can be tested independently OR

■ The non-functional aspect is generally needed as a non-functional constraint for several functionalities.

Rule #9: Formulate separate requirements for non-functional aspects.

The decision whether functional and non-functional aspects should be separated from each other is not always easy. An example: The requirement “The 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 specified 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. The master data of new library items, for example, or changes of customer data have to fulfill this requirement as well. If this is the case, create a separate requirement: “The library system shall complete each saving process within a maximum duration of one second“.

The two steps for checking characteristics

Let us recap. Applying the steps depicted in figure 6.5, you have uncovered missing informa-tion in the descriptions of characteristics. In doing so, you have analyzed non-functional aspects (attributes) and transformed qualified statements into measurable requirements.

��

��

Figure 6.5: The 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?

141140


6.5.3 Checking Amounts and Frequencies

In order to avoid redundancies, you will not write a requirement that is basically the same several times for each smallest unit. It is better to describe a behavior or a characteristic only once and to assign this description to a group of issues that should be valid for the behavior or characteristic you specified. It is important, however, that the issues are grouped correctly (see transformation effect “generalization“ in section 6.2.2).

Signal words that indicate a generalization of knowledge are numerals or quantifiers as well as nouns grouping the actors or objects. Checking amounts and frequencies does not aim towards avoiding generalizations. Is it rather about questioning whether a stakeholder has grouped several issues or facts in the right way.

Step 1: Check numerals and quantifiers

With requirements, you specify functionalities or characteristics which should be valid for a defined amount of objects. In natural language, we are using numerals or quantifiers to do this. In a requirement, a statement is then made on the behavior or the characteristics of this set of objects.

The requirement “The library system shall enable each library user to borrow each library item.“ would, in fact, lead to the assumption that also minor library users were allowed to borrow items which are prohibited to them in accordance to the Children and Young Persons Act. Furthermore, there could be library items which are only display copies, but not intended to be lent. Surely the library administration would object to such copies possibly being lent to all library users. Here, the librarian generalized in a wrong way.

As you see, the danger in using numerals and quantifiers is that possibly the specified 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 specified behavior would be wrong. It is your task as requirements engineer to uncover such exceptional cases by targeted questioning of the numerals and quantifiers used.

Be careful to question numerals and quantifiers very purposefully. If you ask “Really all“, “really each...“ with every requirement, your

stakeholders will probably quickly lose their patience.

E.g. “save customer‘s name“, “save customer‘s ad-dress“ can be comprised with “save customer‘s 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 quantifiers used in the requirement.

If you find that the set has been grouped erroneously, you have to:

■ Narrow the set of objects—if only a part of the whole set is concerned, OR

■ Broaden the set of objects—if there are further objects concerned.

■ Probably there will be also exceptions you have to specify additionally.

Rule #10: Question the numerals and quantifiers used.

In the requirement “The library system shall pro-vide each library user with the ability to edit all customer data.“, you should question the quanti-fiers “each library user“ and “all customer data“.

If your questioning reveals that there are exceptions, then these have to be specified. Further-more, you have to change the original requirement: ”The library system provide each library user with the ability to change the registration data stored about him.”

You should also check sentences which do not state any explicit numerals or quantifiers for the specified behavior or characteristic. Missing statements on this imply that the specified behavior will always apply to all possibly relevant objects. Of course, this assumption can be true. As a requirements engineer, however, you run the risk of overlooking exceptions.

For each behavior and each characteristic demanded, the set of objects this specified behavior or characteristic applies to has to be explicitly described.

Check whether the requirements can be completed with numerals or quan-tifiers. If this is the case, you have to check for which objects exactly the requirements should be valid. If necessary, add the respective numeral or quantifier to the requirements .

Rule #11: Clarify missing numerals and quantifiers

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?

143142


The example requirement “The 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 quantifiers. There-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 quantifiers have to be specifically 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?

The scope of implementing the above requirement ranges from a trivial backup software for 1,000 Euros, which lets the librarian copy the data on tape, to a fully automated robotic backup station for several million Euros. The demanded scope should probably be cleared prior to commissioning of the system—at least if you do not expect your customer or his developing department to be clairvoyant.

To ensure unambiguity and to facilitate the creation of requirements, it is advisable to limit the set of numerals and quantifiers to be used to a number of clearly defined ones.

For the above example requirement, the analysis could lead to this improved requirement: “The system shall provide each librarian with the ability to backup all customer and item data stored within the library system on tape at any time.”

Step 2: Check incompleteness in nouns

Within a requirement, nouns represent actors as well as objects for which a certain behavior or characteristic is demanded. Oftentimes, however, we find nouns in requirements that describe actors or objects in such a vague way that there is more information needed to specify them unambiguously.

The term “values” could, for example, encompass all data values that are in any form stored in and can be input into the system. However, a requirement usually only applies to a part of these “values”. For a full explanation, it has to be stated exactly to which “values” this 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 defined, informa-tion has been deleted from the original sentence.

Question unclear formulated nouns and find out for which objects or actors exactly this requirement should be valid. Afterwards, add the deleted infor-mation to the requirement.

Rule #12: Question vague nouns

For instance, the librarian states: “The 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.”

This rephrasing does, of course, presume that there is another requirement, which describes the process “calculation of the library item statistics” in a detailed manner and that really all statistically calculated data of library items can be displayed graphically.

Moreover, the adverb ”graphically“ has to be described more precisely. In many cases, such questions lead to a refinement of requirements; i.e., for instance, when the answers reveal that the different statistic data require different graphical representations.

The two steps for checking amounts and frequencies

Now, you will be done soon. After having gone through the steps depicted in figure 6.6, you identified and eliminated the linguistic effects concerning amounts and frequencies. To achieve this, you checked numerals and quantifiers, as well as vague nouns to find out whether objects or actors were grouped correctly.

��

��

��

Figure 6.6: The 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?

145144


6.5.4 Checking Terms that Describe Possibilities

In many cases it is not only necessary to simply request a system functionality through a requirement, but also to describe the way in which the system should fulfill the requirement and which means are to be used to achieve this. This applies particularly for complex operational processes, the so-called business logic.

Step 1: Check what is possible and what is impossible

We often experience that requirements only specify the results of complex cal-culations, for example: “With each radar update, the flight plan route shall be calculated anew”. Often, it is simply not sufficient to claim that certain results should be obtained; the specification then has to contain the details on the business logic behind the way to certain results as well. Signal words which indicate deleted business logic are terms that express that something should be possible or impossible

Alway s keep in mind that the description of the business logic (which inevitably leads to the question “How?”) is not to be equated with the description of implementation details. Especially when writing business-driven requirements (specification level 2 and 3), details of implementation (like employing a certain database) should not be described – except for when they are explicitly requested (e.g. for maintenance reasons).

Statements that only claim that a certain behavior should be possible or impossible delete the related business logic.

Analyze what it is that makes the demanded behavior or characteristic possible or impossible and add the identified business logic to the requirement.

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 stakeholder’s requirement, however, it is often only the latter part of the sentence that is expressed. The first

part of the sentence (the justification) then stays unanswered.

If this is the case, the condition that makes the demanded behavior possible or impossible in the first place has been deleted. This is why you should always check whether all relevant preconditions and persistent conditions are documented.

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.

Let’s have a look at an example requirement for the library system: “A library user who has at least two overdue library items should not be lent any further book”. To implement this requirement, the system needs to access the information on the overdue items of a library user. Yet, where does this information come from?

The answers to these questions may, if not documented yet, result in further requirements. It is only through these requirements that the precondition for the above requirement is expressed, which is managing each library user’s dunning history: “As soon as the deadline for returning a library item is reached, the library system shall increment the number of overdue library items in the dunning history of the library user who has borrowed that item by 1.” Based on this function description, it now becomes clearer how the system can get the information on the number of overdue items during the lending process: “After the librarian has initiated the lending process of a library item for a library user AND in the case that there are at least two overdue items in this customer’s dunning history, the library system shall display the error message “overdue items” to the librarian.”

The requirement “It shall not be possible that a new library user who is younger than 18 and cannot present a written consent by their parents is registered” should be completed by the information on how the system should fulfill this claim as well. The stakeholder has for sure very precise ideas about how the registration of a new customer should be regulated. An improved requirement could therefore be: “After the librarian has initiated the saving process of new customer data AND in the case that the newly entered customer is under 18 years of age AND in the case that there is no written consent by the new customer’s parents present, the library system shall display the error message “Customer younger than 18” to the librarian”.

This statement is already a bit clearer; it still contains effects, however. The 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 confirm the presence of a written consent by the customer’s parents.”

The step for checking what is possible and what is impossible

After having applied the step depicted in figure 6.7, you have added the missing busi-ness logic to the requirement (if necessary) and have cleared the requirement of the worst linguistic defects.

��

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”.

147146


6.6 Checking the Sentence

After having checked the single parts of the sentence, we now turn to whole requirement sentences.

Step 1: Extract irrelevant subordinate clauses

The only subordinate clauses relevant for requirements are logical and temporal conditional clauses (comp. Chapter 7 “Templates”).

Subordinate clauses containing reasons, intentions or consequences should be eliminated from the actual requirements and noted as a comment. They are superfluous for the actual system description and only lead to irritations, in the worst case even to misunderstandings.

Subordinate clauses which only contain information unnecessary for the system development have a negative impact on the readability and make the actually demanded system requirement fade into the background.

Analyze a subordinate clause’s information content. If the information is irrelevant for the system description, then:

■ Extract the subordinate clause from the requirement AND

■ Write it as a “comment” to the requirement.

Rule #14: Extract irrelevant information.

The following example from our library system shows a require-ment of a kind that we find in specifications all too often: “As it makes the creation of library item statistics easier for the librarian, the library system shall offer a wizard.”

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. This is why this subordinate clause should be converted into a comment.

The above requirement would then read: “The library system shall provide the librarian with the ability to create library item statistics with the help of a wizard.” The remaining subordinate clause, which only contains the reason for the requirement, is added as comment to the respective requirement: “Comment: This makes the creation of library item statistics easier for the librarian.”

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 requirement—but it is irrelevant information for the system description

If you find, however, that the subordinate clause contains something of importance for the system’s context, that information has to be documented as a separate requirement.

Step 2: Eliminate redundant information

Often, we do not realize that we write sentences which contain redundant information. For verbal communication between people, this often makes sense or is amusing; requirements, however, can become unnecessarily complex.

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.

There are many requirements which you can condense without loss of information. The requirements for the library system: “In the case that the library system interoperates together with the ordering server, the functioning of the library system shall persist for the user with the same functionality.” can be condensed using this phrasing: “As long as the library system interoperates with the ordering server, the library system shall guarantee unrestricted func-tionality to the user.”

The two steps for checking the sentence

Congratulations. After having gone through the steps depicted in figure 6.8, you now have not only recognized and eliminated all semantic effects in your requirements, but also freed your requirements from ballast.

Figure 6.8: The two steps for checking the sentence

Is there anything doubled or expressed

with set phrases?

Small in size --> smallYellow of color --> yellowA true fact --> a fact

��

��

��

Clarify the relevance of subordinate clauses!

Check for redundant information and void or flowery expressions!

149148


6.7 Checking the Big Picture

Now it is time to climb a step up and to have a look not only at the single sentence, but on its integration in the overall specification.

Step 1: Analyze exceptions to the usual behavior

To describe a system’s functionality in full, the requirements have to describe the desired usual behavior as well as the behavior in exceptional cases (in case

the latter are possible). When writing a requirement, you should always ask yourself whether the system will always be able to guarantee the desired behavior or whether there are con-straints or marginal conditions under which that would not be possible.

Unfortunately, in reality systems are dependent on external influences; data or events, for example, that are expected for further processing may fail to come. Describe the system’s behavior for the exceptional cases it cannot handle on its own. Requirements of this kind often contain terms which express that something has to be necessary .

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.

The requirement “The library system shall send orders for new library items directly to the dispatching system.” calls for a behavior which regards the normal case where data has to be transferred to a neighboring

system. However, certain questions regarding possible exceptional cases remain unanswered. What happens if the

connection to the dispatching system cannot be established and therefore data cannot be sent? What happens if an error occurs during the data transmission?

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 defined behavior. Potential problems, for example, should be displayed to the user during data transmission via user interface. This way, the user can restart the data transmission. After having answered the questions, the behavior in exceptional cases can be specified for the requirement: “If the library system cannot establish a connection to the dispatching system due to technical reasons, the library system shall display the error message “Connection cannot be established” to the librarian”.

The description of a system’s exception behavior is often neglected. A full definition of a system’s behavior in exceptional cases can be as elaborate as defining the system’s behavior in normal cases. This is likely to be underestimated.

Therefore, take these efforts into account from an early stage. Very often we experience in project reality that the definition of a system’s behavior in exceptional cases is only touched on or even omitted due to a tight schedule. In the worst case, this results in system which shows an unpredictable behavior when facing even minimal environmental disturbances.

Step 2: Analyze incompletely specified conditions

Similar to the specification of exceptions (see previous rule) which describes the system’s behavior in situations where it cannot assure the desired functionality, all (possibly complex) conditional structures of the “normal behavior” have to be described as well.

Requirements containing conditions describe the behavior in case the condition is valid resp. fulfilled. It is important to also describe what should happen if the condition is not fulfilled. In our experience, however, the latter information is often neglected in system specifications.

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 fulfilled.

Clarify the system’s behavior in case (or cases) the condition is not fulfilled:

■ Specify an additional requirement for each condition that has not been described yet OR

■ Expand the original requirement by the missing cases.

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?

151150


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 fulfilled 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 item’s availability AND if the library item is not reserved, the library system shall provide the librarian with the possibility to continue the lending process.”

■ “If the library item is reserved, the library system shall display the error message “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 (fulfilled/not fulfilled resp. reserved/not reserved).

Often, you have to distinguish exactly between different cases. As an example, let us check a requirement from the library system: “After the library system has identified the library user AND if this library user has one overdue item at the most OR if this library user has less than 24 library items still borrowed at the time of the lending process, the library system shall provide the librarian with the possibility to enter the library item to be lent.”

There are several questions that have to be answered on this requirement and then described in the requirements document. Analyzing these different possible cases can lead to highly complex requirements. How complex requirements may become can be seen if we add condi-tions to the above requirement: “If a library user’s dunning history shows more than five overdue library items, the library system shall destroy this library user’s library card.” and “The library system shall display a warning message to the librarian if there is a “damaged return” on the library user’s record.”

Conditional requirements can become extremely complex. Using natural language to express such complexity then results in confusing, interlaced requirements. There are more appropri-ate means you can employ, for example decision tables.

These can help depicting complex conditional structures in a clear way. When checking completeness, they are usually the best means to discover variants of actions or conditions that have not been described yet.

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. They are assumed to be known or the stakeholders shy away from writing down things they consider banal or commonplace. We call this muscle memory.

However, these implicit assumptions have to be made explicit at some point (Quality criterion “Completeness”, see Chapter 1 “In Medias RE”). This is at the latest when the requirements are implemented—otherwise the appropriate functioning of the system is endangered.

Implicit assumptions (presuppositions) are deleted statements that have to be true for other statements (requirements) to make sense.

Basically, all rules described help you discover certain implicit assumptions, for example by analyzing nominalizations or amounts and frequencies. Yet, if whole aspects or parts of a system are deleted or forgotten, implicit assumptions are very hard to discover. In our project reality, we therefore often encounter certain limits.

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 true—otherwise the basic requirement cannot be fulfilled. 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 so on as”, “When” ...

Look out for signal words like “entered cus-tomer data”, “displayed view”, “computed capital

value”...

153152


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”.

The 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: “The library system shall save the registration data of a new library user” . Of course, this additional requirement has to be deeply analyzed regarding semantic effects afterwards. Ideally, you start with rule #1.

Another indicator for implicit assumptions are nouns which are detailed by a reference word. If we have a look at the above example requirement, we will quickly find that the reference word “entered” in front “registration data” indicates that there has to be a functionality for entering registration data. If you find that this functionality has not been already specified by at least one requirement, information has been deleted: “The library system shall provide the librarian with the ability to enter registration data for a new library user.”

The three steps for checking the overall picture at one glance

A high-quality requirement has now helped you to discover and track down even completely deleted information like exceptional behavior, forgotten temporal or logical conditions and even implicit assumptions.

Figure 6.9: The 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 specification document of high quality.

Is there already a requirement that de-scribes that regis-tration data can be entered?

��

��

��

��

6.8 Application of the SOPHIST Set of REgulations

The SOPHIST Set of REgulations provides you with a toolbox you can use to systematically analyze requirements. We have already applied it in many industry projects settled in various domains.

Often, requirements templates are applied additionally. Those provide clear instructions on how exactly to formulate a requirement sentence (see Chapter 7 “Templates”). By doing this, several steps of the SOPHIST Set of REgulations (like rule #1, active voice) can be omitted.

You can look for effects at different points of time (See Chapter 7 “Templates”, Chapter 4 “Validation Methods for Requirements” and Chapter 11 “Quality Metrics”):

■ Directly in an interview (which we call “constructively”): here, the require-ments engineer immediately checks every statement made by the interview stakeholder for linguistic effects. He or she directly asks for the missing infor-mation considered important. In this ways, the information needed is elicited very efficiently within the interview, as knowledge gaps are immediately uncov-ered. If the requirements engineer is experienced in this field, the interviewed person will not even be aware that his or her statements are systematically analyzed and questioned in a targeted manner, using methods originated in psychotherapy. The interviewed person will only realize that the discussion will get to the point very quickly. The documentation of natural-language 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 effects in a constructive way.

■ If requirements in written form already exist, then these are checked using the linguistic rules. Omissions, unclear aspects etc. can thus be questioned. Here, the Set of REgulations serves as means of analytic quality assurance.

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 doesn’t 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.

155154


Of course, even requirements engineers are not immune to the unwanted defects of focusing and simplifications—preparation is necessary. If using the method for the first time, it is advisable to analyze requirements already documented. After a certain time of practice, the psychotherapeutical approaches of the SOPHIST Set of REgulations will be integrated into your mind to an extent that allows you to directly analyze and question statements of a stakeholder while interviewing him.

In the beginning, you should only apply some of the most important rules that allow you to concentrate on the group of perilous persistent offenders.

The best way to memorize these rules of the SOPHIST Set of REgulations is to write them down on a piece of paper, together with their related questions. Hang this paper at your workspace at eye level and take a conscious look at it every day.

Do not try to force the use of each rule on every requirement. If, for instance, your require-ment does not need a logical or technical condition, you do not have to construct an artificial condition or analyze different possible cases.

As soon you feel confident enough in the application of the rules with high priority, pull out some more from your box of tricks.

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 reflection towards requirements absolutely freed from all defects, but always consider your project’s constraints. In terms of quality, theory and practice are often miles away from each other. Quality in the analysis and documentation of requirements is tied to a lot of effort and high costs. Perfectionism thus quickly turns into luxury most projects cannot afford.

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 specification level.

I know the most important signal words and am aware which signal words indicate which questions.

I understand the different points of view (parts of a sentence, 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.

6 requirements engineering and management the sophist set of regulations

Documents

requirements step

real requirements

naturallanguage requirements

requirements document

perceptional transformation

system analyst

existing system

starting point