The requirements engineering disciplines (elicitation, documentation, validation and negotiation and management) in particular are affected by these circumstances, as the misuse of terms raises the risk of misunderstandings and misinterpretations during the development phase, leading to additional correction loops. Not only does this extend the project timeline beyond the original deadline, it also negatively impacts the image of an organization [Rupp 2014].
Previous research explores among others the use of Neuro-Linguistic-Programming (NLP) to improve communication between project members [Thomas and Georgieva 2016]. Others underline the poor quality of requirements written by non-native speakers, stating the need for requirements reviews and suggesting the use of spellcheckers to improve requirements’ quality [Garnier and Saint-Dizier 2016]. Still, besides the definition of a project glossary containing terms and their meaning used within a specific project [Rupp 2014], there is a lack of tools to support the teams in the definition of a common language. This challenge remains even if teams are formed by native speakers only.
Within this setting, it is a specific challenge for the requirements engineer to specify the correct process verb expressing the expected functionality of the system, as cultural and linguistic differences increase the misuse of those process verbs. Looking at the academic world might support requirements engineering in finding further means which are crucial for improving the quality of requirements. In particular, the concept of verb’s valency, which focuses on the syntax of a sentence originating from its verb, appears to be interesting from a requirements engineering point of view. For this reason, this article looks at valency and how it might support and improve verbal and written communication of requirements.
The concept of valency also applies to nouns, adjectives and adverbs. This article focuses on verb's valency only. In this article the term valency is a synonym for verb's valency.
First of all, this article introduces the approach of valency (Note: Considering the vast amount of research on valency it is important to state that this article can only give a basic definition of valency and focuses on its core statement rather than on details and differences among different research). Based on the understanding of this linguistic approach, recommendations for the use of valency to improve requirements’ quality will be provided. This is done by introducing the valency of two common process verbs. Last but not least, the benefits as well as limitations of using valency within requirements engineering will be outlined.
Beyond linguistic theory
What is verb's valency?
In science, there are various approaches to describing what a verb’s valency actually is. Good introductions and summaries are provided - among others - by [Ágel / Fischer 2010], [Welke 2011] and [Eisenberg 2013]. However, the most popular approach is linked with the name Lucien Tesnière (1893-1954). His approach is based on the following comparison. A verb is like an
"atom with a particular number of hooks that can - according to the number of hooks - attract a varying number of actants, which it [the verb] keeps in its dependence. The number of hooks that a verb possesses, and consequently the number of actants that it governs, constitutes what we call the valency of a verb" [Ágel / Fischer 2010] (Note: Translation of Tesnièr's original statement in French by Ágel / Fischer 2010).
Hence, Tesnière considers the verb as the driver of a sentence. According to his valency approach, each verb requires a certain number of actants in a sentence which cannot be omitted [Tesnière 1980]. The following two sentences give an example for that:
(1) The requirements engineer writes.
(2) The requirements engineer writes the specification.
In our opinion Tesnière's definition applies to requirements as follows: Looking at a functional requirement written in natural language (see example (3) below), one can describe it as a sentence which describes a capability which a system shall offer to a user. Examples are the verbs - or to name a more generic term - the processes “to print”, “to display” and “to delete”. First of all, valency provides linguistic background information on two basic style rules which are promoted by the IREB [CPRE FL 2017]. When writing requirements the following rules should be considered:
- short sentences and paragraphs
- formulate only one requirement per sentence (i.e. one verb per sentence).
The valency of a verb ensures that a requirement is an actual sentence (3), rather than just a headword (4).
(3) The system shall print the shift schedule.
(4) print shift schedule
Moreover, valency is an explanation of why it is important to "formulate only one requirement per sentence". Each verb has its own valency. If a requirement contains two verbs, actants might be forgotten easily as the requirement suggests a completeness which it is actually missing.
(5) The system shall display and print the shift schedule.
This requirement contains the verbs to display and to print. There is no grammar mistake in that requirement. The valency of both verbs suggests questions such as
- When should the system display the shift schedule?
- When should the system print the shift schedule?
Note: Within this article wh-question words will be used as a means to detect missing information of a requirement. An overview on wh-question words is provided by [Eisenberg 2013].
As both answers might be completely different it is recommended to write two different requirements. One requirement containing two verbs and their actants will most likely result in an unclear requirement which is hard to read.
There is one more aspect of Tesnier's valency approach which will be mentioned briefly. Example (3) already implies that a sentence, and accordingly a requirement, is grammatically correct even if it is missing information. Example (3) contains a subject and an object as otherwise the requirement would be incorrect as shown in example (6):
(6) *The system shall print.
This applies to the verb to display as well as shown in (7):
(7) *The system shall display.
Information which is obligatory is often implicitly stated by native speakers. More challenging is information which can be eliminated freely from a sentence (Note: Research also suggests that the meaning of a verb influences its arguments [Eisenberg 2013]). Therefore, the requirement is grammatically correct but might be missing essential content. The difference between obligatory and optional information in a requirement can be seen in (6), (7) and in the following examples:
(8) The system shall display the shift schedule.
(9) As soon as the administrator has set a time frame and only if the schedule status is confirmed, the system shall display the shift schedule.
(8) and (9) are grammatically correct. However, (9) contains more information than (8). When it comes to eliciting and documenting requirements, or rather all necessary information based on a process, valency is a linguistic means which helps to document a requirement with regard to its content completely.
Verbs’ valency in a requirements engineering context
Now that the concept of valency has been introduced briefly, the focus of the following chapter will be on the question of how valency can be used in a requirements engineering context. Therefore, the valency approach will be applied to two common process verbs: to print and to display.
Valency of to print
During a workshop stakeholders might discuss the following requirements:
(10) The system shall print the shift schedule.
(11) As soon as the administrator has confirmed the monthly shift schedule, the system shall print the monthly shift schedule five times at the colour printer.
Both requirement examples contain the verb to print. Both requirements are grammatically correct. However, the second requirement contains much more detailed information on the printing process. Reviewing the first requirement may not result in detecting the missing information and hence in rewriting the requirement. It needs a tool to improve the first requirement. There might be people who have a very good feeling for language and will improve the requirement without knowing that they are actually using a tool. A conscious, goal-oriented review can be based on valency.
The requirement The system shall print the monthly shift schedule does not contain the information when, where and how often the monthly shift schedule should be printed. If the answers to these questions are not important within the project’s context, they would not have to be documented. However, to be able to decide consciously whether we need that piece of information one needs to be aware of the fact that there is actually more information to that requirement. Not stating the answers to the wh-questions might result in a reader who may be a developer, tester etc. answering the questions unconsciously him- or herself. Their answers become part of the system to be developed as they include the answers unconsciously in their work. In the end, one possible scenario would be a system that contains functions or test cases which nobody explicitly asked for. Within the context of the example (10) that could mean that the monthly shift schedule could be printed once on the first Sunday of a month - as this is the information the developer has added implicitly to this requirement. Meaning the shift schedule could never be printed up to date and could not be stuck to the five notice boards around the office. This information has been added explicitly to (11).
Valency of to display
The second example might seem very simple. Nevertheless, it proves the importance of valency and of a conscious review of requirements. Imagine software which allows you to post news. Over time there are a high number of news items in your software. Searching for a certain news item is a bit tricky as the system does not display the headline of the news which would be a big help. The system displays the ID of the news item and the first 30 characters of the actual content. So a small change request is written explaining the above mentioned background, as well as the following requirement:
(12) The system shall display the headline of the news.
The stakeholders think implicitly that obviously the system shall display the headline after the ID and before the content. However, this essential information has not been written down. The according requirement reads as follows:
(13) The system shall display the headline of the news after the ID.
When a developer reads this requirements s/he might add the headline after the content rather than as implicitly expected after the ID.
Valency is a tool which could have improved the quality of that requirement right from the beginning. I. e. due to the verb's valency the necessary wh-questions are raised in order to write requirements completely or to review requirements. The valency of the verb to display suggests answering the question where. The answer would have been after the ID. Discussions and complaints would have been prevented: what was written down was developed, even though it meant something different.
Conclusion and summary of how to work with valency in requirements engineering
To sum up, in this article valency has been introduced to make finding a common language in a team less of a gamble. Valency could be applied in requirements engineering as follows:
- The concept of valency should be on the mind of a requirements engineer when eliciting requirements during a workshop and writing requirements. It helps to address all information concerning the requirement and helps to phrase requirements such that they are more complete and more readable.
For example: While stakeholders are discussing the requirement The system shall print the shift schedule, one could easily mention the question words when, where and how often and encourage the stakeholders to discuss the answers to those questions. The requirements engineer could easily prepare moderation cards with the appropriate question words. Pinning them to a board might help the stakeholders to find the answers in the given context.
- There are various supporting techniques for a review [CPRE FL 2017]. This article suggests adding a valency to this list. Reviewing written requirements needs orientation and a focus. This focus is given by a valency.
For example: A written reminder as simple as to print - who - what - when - where and how often helps in performing a goal-oriented review. This written reminder could also be a checklist containing common or essential verbs and its wh-question words. An input for a checklist might be given by the signpost below.
The examples above show that valency can support the requirements engineer to reach a more specific, natural language requirement not just accidentally, but by means of a guideline. Therefore, whenever high quality requirements are one of the goals, next to the set of rules and the requirements template, valency is another helpful component of natural language requirements engineering methods. Keeping in mind that these days quite often people with various cultural backgrounds are working as a team, valency might also help to address the different language skills of team members.
Knowledge on linguistic theory fits nicely in the profile of a requirements engineer. Even if this article does not go into the details of valency, it points out that the structure of a sentence and accordingly of a requirement cannot be reduced to subject - verb - object.
Last but not least, we would like to suggest two ideas which might help requirements engineering to profit even more from valency:
-
Looking at valency from a requirements engineering point of view should also result in a valency dictionary containing process verbs. There are already a number of general valency dictionaries. However, they do not contain verbs which are of interest for e.g. software development. Therefore, based on our requirements experience we set up our own "requirements-valency dictionary" with regard to typical verbs used in software requirements specifications and the required actants for each verb, to help phrase detailed requirements.
-
Moreover, looking at tool-based review approaches for requirements, this article should have pointed out that such approaches have to consider valency as otherwise important information for a requirement might be omitted. I.e. the valency can be used as a rule set for a natural language analyzer tool.
References
- [Ágel / Fischer 2010] Ágel, Vilmos / Fischer, Klaus: Dependency Grammar and Valency Theory. In: Heine, Bernd / Narrog, Heiko (Hrsg.): The Oxford Handbook of Linguistic Analysis. New York etc., 2010.
- [CPRE FL 2017] IREB: IREB Certified Professional for Requirements Engineering. Foundation Level. Syllabus. ireb.org/content/downloads/2-syllabus-foundation-level/ireb_cpre_syllabus_fl_en_v222.pdf, 2017.
- [Eisenberg 2013] Eisenberg, Peter: Der Satz. Grundriss der deutschen Grammatik: Band 2. J. B. Metzler, 2013.
- [Garnier and Saint-Dizier 2016] Garnier, Marie and Saint-Dizier, Patrick: Improving the Use of English in Requirements. re-magazine.ireb.org/articles/improving-the-use-of-englis-in-requirements, 2016.
- [Rupp 2014] Rupp, Chris & die SOPHISTen: Requirements-Engineering und -Management
- [TenSix Consulting 2011] Ten Six: Five Challenges For International Projects. tensix.com/2011/11/five-challenges-for-international-projects, 2011.
- [Tesnière 1980] Tesnière, Lucien: Grundzüge der strukturalen Syntax. Hg. und übers. von Ulrich Engel. Stuttgart: Klett-Cotta, 1980.
- [Thomas and Georgieva 2016] Thomas, Corinne and Georgieva, Albena: NLP for Requirements Engineers, Part 1. re-magazine.ireb.org/issues/2016-1-seeking-new-perspectives/nlp-for-requirements-engineers-part-1, 2016.
- [Welke 2011] Welke, Klaus: Valenzgrammatik des Deutschen. Eine Einführung. Berlin, New Aus der Praxis von klassisch bis agil 6. aktualisierte und erweiterte Auflage. Carl Hanser Verlag München, 2014. York: de Gruyter, 2011.
## Picture Credits
Motive *Discuss it*: "Zusammenspiel Treffen Konzept" / ©iStockphoto.com / Author: ALotOfPeople
Motive *Signpost*: "Questions and answers signpost" / ©iStockphoto.com / Author: RTimages
Before working for SOPHIST, Kristina has lived and worked abroad in an intercultural environment. Due to her linguistic studies she is comfortable working with communication models, semantics and syntax. She has developed an excellent feeling for languages based on theory and experience. As consultant and trainer, she benefits from this feeling in the field of elicitation, documentation and management of natural language requirements.
Andreas is consultant and trainer at SOPHIST GmbH and is specialized in object-oriented and linguistic methods in requirements engineering. His assignments include methods of linguistic analysis as well as of conceptual models. Moreover, Andreas deals with the generation of acceptance criteria and test cases in the context of requirements engineering. He also occupies the position of controller of the innovation projects at SOPHIST and is engaged in the training of new employees.
Born and raised in France where she completed her studies in IT Project Management, Margaux worked two years as consultant in Project Management, both in France and in Germany. Through the different projects she worked in, she noticed the critical importance of good requirements engineering practices and thus chose to specialize in this domain. Over the last two years, she worked as a consultant and trainer in Requirements Engineering in Germany, making it her mission to support her clients to create and improve their RE processes. Now back in France, she wishes to put her experiences to the service of local companies.