Comparison of (semi-) formal specification versus

informal natural language specification

Date: 02-03-2012

Course: Software Requirements Management: Quality and functionality

Coursecode: 1BM20

Project: Assignment 2

Team: Assignment_2_Group_08

Team members: Tollenaere, Y.S.B. 0596377 y.s.b.tollenaere@student.tue.nl

Correia Santos, G. 0830587 g.correia.santos@student.tue.nl

Emens, R.D. 0716250 r.d.emens@student.tue.nl

1

ABSTRACT

The determination and specification of requirements are key activities in the development of

software. Inadequate requirements can lead to system rejection, failure in delivering the software in

time, excessive maintenance, failure of the system and loss of credibility. Since requirements are an

abstract representation of the object system, the language used to describe this abstraction is of

importance. This article presents a comparison between informal and formal specification

languages. Also it is argued during which activities of a software development project a formal or

informal language should be used. A conceptual framework consisting of eight criteria is used to

assess high quality literature. The eight criteria used are (1) the degree to which the language used

can cause ambiguity, incompleteness, and inaccuracy, (2) understandability by naïve users, (3)

understandability by practicing analysts and designers, (4) modifiability and maintainability, (5) the

degree to which completeness, correctness, and consistency checks and proofs can be done, (6)

freedom of expression, (7) ease to which code can be generated and (8) the degree to which the

language can include or support other specification languages. The activities are grouped by (partly)

using phases of the waterfall model: elicitation, analysis, specification and validation & verification.

The literature study revealed that in the activities of the elicitation and analysis phase primarily an

informal language should be used. When more and more requirements are baselined and are

elaborated in more detail in the activities of the specification and validation & verification phases,

the importance of formal languages is rising. A hybrid use of formal and informal approaches is

advised to use in the corresponding activities.

2

CONTENTS

1. Introduction .................................................................................................................................... 3

2. Problem description ........................................................................................................................ 4

3. Conceptual framework ................................................................................................................... 5

4. Comparison criteria ......................................................................................................................... 6

4.1 Degree to which the language used can cause ambiguity, incompleteness and inaccuracy . 6

4.2 Understandability by naïve users ............................................................................................ 7

4.3 Understandability by practicing analysts and designers......................................................... 8

4.4 Modifiability and maintainability .......................................................................................... 10

4.5 Degree to which completeness, correctness and consistency checks and proofs can be

done 11

4.6 Freedom of expression ......................................................................................................... 12

4.7 Ease to which code can be generated .................................................................................. 13

4.8 Degree to which the language can include or support other languages .............................. 14

5. Practical cases ............................................................................................................................... 15

5.1 A formal example .................................................................................................................. 15

5.2 An informal example ............................................................................................................. 16

6. Conclusion and discussion ............................................................................................................ 17

Limitations ......................................................................................................................................... 19

Bibliography .......................................................................................................................................... 20

3

1. INTRODUCTION

The development of requirements is one of the first steps in every software development process

and may also be considered as one of the most important phases of the process. Errors made in this

phase of the process will have consequences throughout the entire process. The later they are

discovered, the higher the associated costs of repairing them will turn out to be (Jones C. , 1996a). It

is important to achieve a common understanding among the different stakeholders in the network

(Kudikyala & Vaughn, 2005). The sooner misunderstandings are identified and corrected, the better

the result will be.

In order to achieve a good requirements document for a software project different tools and

techniques are available. It is possible to use natural language to write down the requirements or

use more formal languages with a mathematical background. These different languages serve

different purposes and have related characteristics. Requirement Engineering is inherently broad,

interdisciplinary and open-ended (Cares, Franch, Perini, & Susi, 2011). The successful elicitation of

these values, however, demands an understanding of the specific problem and its context, in which

the requirements are embedded—both locally and in the wider organization. This environment is

highly complex, requiring many difficult communication interfaces to be made, particularly between

the users’ social/technical world and the analysts’ technical world (Coughlan, Lycett, & Macredie,

2003)

In this report we discuss a research which has been done to the use of formal and informal

requirement models or languages in specific phases of the requirements engineering. The easiest

example of an informal language is natural language. Examples of formal requirements language are:

Goal-oriented Requirement Language (University of Toronto, CANADA , 2012), Common Algebraic

Specification Language (CASL) (CoFi - Universitat Bremen), Z notation (Wikipedia foundation, 2013).

We will argue that in different phases of the requirement development specific types of languages

have more advantages than others. Four hypotheses are derived and languages are compared to a

set of criteria. In the end a conclusion is drawn upon the comparison and two practical cases of the

use of formal and informal requirement languages related to the comparison are provided.

The remaining of this report has the following structure. In chapter 2 the different phases of the

requirement stage will be explained and the hypothesis are presented. The conceptual framework is

described in chapter 3 and in chapter 4 the different criteria of the comparison are provided.

Chapter 5 gives two practical examples of the use of formal and informal requirement languages in

different development stages. The final chapter is devoted to the conclusion and discussion of the

results

4

2. PROBLEM DESCRIPTION

Requirements are defined during the early stages of a system development as a specification of

what should be implemented (Kotonya & Sommerville, 1998).These requirements are documented

in the requirements document, which is an official statement of the system requirements for

customers, end-users and software developers (Kotonya & Sommerville, 1998). The requirements

document/specification serves several purposes: it serves as a means of communication between

the user and the systems developer; it represents in asystematic fashion the current state of the real

world, its problems and its future requirements; it enables the systems developer to turn real world

problems into other forms which are more manageable in terms of size, complexity, human

understanding and computer processability; it serves as the basis for the design, implementation,

testing and maintenance of the target system (Tse & Pong, 1991). Example users of a requirements

document are system customers, managers, system engineers, system test engineers and system

maintenance engineers (Kotonya & Sommerville, 1998).Since the content of this document is

important in various activities and is important for several users of a requirements document, the

way in which those requirements are documented is an important topic to address.

As indicated by Nuseibeh & Easterbrook (2000), the requirements documentation research is often

on specification languages and notations, with a variety of formal, semi-formal and informal

languages. This article contributes to this research by explicitly comparing formal and informal

languages. Furthermore it is addressed in what phase of the software development project a formal

or informal language is preferred. Some researchers (see e.g. Rajlich (2006)) argue that a leading

software engineering paradigm of well-defined phases, which exist in the waterfall life cycle model,

is and should be departed to accept a paradigm that is about software evolution, iterative and agile

development. By mentioning that a specific language is preferred in a specific phase of the software

development project (which suggests that we refer to a waterfall approach), we mean that a specific

language is suitable in the activities that occur in that particular phase. The waterfall model consists

of the following phases: requirements phase, design phase, implementation phase, test phase,

installation phase and maintenance phase. The first phase consists of various activities. Although the

naming of the various activities differs in the industry (Siddiqi & Shekaran, 1996), we assume that

the requirements process contains the activities elicitation, analysis, specification and validation

(Wiegers, 2003). On top of that we add the activity verification. We expect that our analysis of

informal and formal languages will result in the following structure of the preferred use of informal

or formal languages in the activities of the phases elicitation, analysis, specification and verification

and validation:

Figure 1:

Four hypotheses regarding the best

use of formal or informal languages

in a specific phase

5

3. CONCEPTUAL FRAMEWORK

In order to compare informal and formal languages and by that approving or rejecting the stated

hypotheses, a conceptual framework is used. This framework is used to analyze selected relevant

papers from high-quality journals. Our framework consists of eight criteria to compare informal and

formal languages. The eight criteria used are:

- Degree to which the language used can cause ambiguity, incompleteness, and inaccuracy

- Understandability by naïve users

- Understandability by practicing analysts and designers

- Modifiability and maintainability

- Degree to which completeness, correctness, and consistency checks and proofs can be done

- Freedom of expression

- Ease to which code can be generated

- Degree to which the language can include or support other languages

As stated this framework is used to analyze research published in high quality journals. To this end

primarily literature of IEEE journals1 and journals that are included in the Thomson Reuters Master

Journal List2 is used. The application of the conceptual framework as well as the conclusions that

follow from this application are described in the following chapters.

1 http://ieeexplore.ieee.org/Xplore/guesthome.jsp 2 http://ip-science.thomsonreuters.com/mjl/

6

4. COMPARISON CRITERIA

The previous chapter introduced the conceptual framework used in this literature study. The

following sections discuss each criterion of the framework in terms of formal and informal

languages.

4.1 DEGREE TO WHICH THE LANGUAGE USED CAN CAUSE AMBIGUITY,

INCOMPLETENESS AND INACCURACY

According to IEEE (IEEE Standard Glossary of Software Engineering Terminology, 1990), a software

requirements document needs to be: correct, unambiguous, complete, consistent, ranked for

importance and/or stability, verifiable, modifiable and traceable. For a software project to be

successful, it is essential that the requirements of a software system reflect the user’s needs. Since

the requirements document forms the basis of a whole development process, the requirements

document must be at least correct, complete and unambiguous (Denger, Berry, & Kamsties, 2003).

An important element is the language used to define the requirements.

The use of formal language gives an analyst a more complete and comprehensive view of the system

requirements, with less number of errors and omissions in the document. Formal specification

languages have a mathematical basis and employ a formal notation to model system requirements

(Fraser, Kumar, & Vaishnavi, 1991). Furthermore formal languages provide conciseness, clarity and

precision (Fraser, Kumar, & Vaishnavi, 1991). This makes the document more precise and

unambiguous, if the language is used correctly.

Informal specification languages, on the other hand, use a combination of graphics and semiformal

textual notations to describe and specify system requirements. Given the graphical and “English-

like” nature of these languages, they provide an ideal vehicle for eliciting user requirements.

However, requirements stated in natural language have major drawbacks, namely the inherent

imprecision, i.e. the inherent ambiguity, incompleteness and inaccuracy of natural language (Denger,

Berry, & Kamsties, 2003), which are a result of the lack of rules on how to use the language as well

as the freedom of expression that inevitable leads to more freedom of interpretation. Possible

consequences are that stakeholders can have their own understanding of the requirement (Pohl,

1994) and none are aware that the others may have different understandings (Kamsties, 2001).

When these imprecise requirements are not identified before actual development is started, high

costs for rework and a delayed product release could be the result.

An important note to make here is that a vague understanding of the system is reflected in both

informal and formal languages (Pohl, 1994). But if the requirements engineer does have a proper

understanding of the system to developed, the language used does have an effect on possible

ambiguity, incompleteness and inaccuracy,

7

4.2 UNDERSTANDABILITY BY NAÏVE USERS

In the requirement elicitation phase it is important to have understanding of the requirements to be

set among the different stakeholders of the software development Including end users of the system

(Kudikyala & Vaughn, 2005). The loss of information as a result of communication errors between

stakeholders is an important risk factor in software design (Keil, Cule, Lyytinen, & Schmidt, 1998). In

most cases the end users of the system, who can be classified as naive related to software

requirements design and software design in general, are not experts on designing information

systems and know very little about software development. However, it is important that these end

users are able to effectively communicate their domain knowledge to the software engineers and

system architects. The designers must understand what the naive users mean and the naive users

must get confirmation that the designers correctly interpreted their knowledge about the design.

The question is whether the language used to do this influences the effectiveness.

Natural language seems like a logical language to use since all stakeholders (in general) speak and

understand this. Furthermore all stakeholders are able to read, write, store and transfer information

in natural language to each other with very limited technology needed. For example, no specific

modelling tools are required to communicate in natural language.

However, there is a mayor pitfall in the use of natural language which must be avoided. Most fields

have specific terminology and practices. The naive end users must be aware that in many instances,

the software requirement engineer does not possess the same amount of domain knowledge as he

does and might misinterpret terminology or practice.

Using formal languages might resolve this problem. However, it will require a language which is

known by all stakeholders. It is possible to learn a new formal language to the end user to allow

them to communicate and understand the requirements to and from the designers. Unfortunately

this is time consuming and the results are highly dependent on how well the end users are able to

learn the formal requirements language and their willingness to do this.

A third option is suggested by Kudikyala and Vaughn (2005) who presented a technique to better

understand requirements. They developed a specific mental model named the pathfinder model to

represent concepts and weighted connections among them. Using these graphs in combination with

natural language the stakeholders are able to visualize relatively easy what they mean. On the other

hand, the requirement engineers are able to map what they understand, interpreted and how this

translates to requirements. By calculating the distance between these graphs the requirements can

easily be verified to the naive end users intention.

8

4.3 UNDERSTANDABILITY BY PRACTICING ANALYSTS AND DESIGNERS

Different designers and engineers are involved in the development of software. During this they

need to communicate their requirements in an understandable and unambiguous way in order to

prevent misinterpretation or the loss of data. Abbott & Moorhead (1981) make a distinction

between requirements and specification for software. In which they give the following definitions for

both terms.

Requirement: A property needed to solve a problem or achieve an objective. Hence a quality,

capability or other characteristic which suits a system ot its intended use or environment.

Specification: A description (in a formal language to the extent practicable) of the externally

knowable features, i.e., behavioral characteristics, of a system. (Abbott & Moorhead, 1981)

p. 298

This definition is conflicting with the now more general definition of a requirement as given by the

IEEE (1990, p. 62):

1. A condition or capability needed by a user to solve a problem or to achieve an objective

2. A condition or capability that must be met or possessed by a system or system component to

satisfy a contract, standard, specification, or other formally imposed document

3. A documented representation of a condition or capability as in 1 or 2

The definition by the IEEE is essentially a combination of both requirements and specifications as

given by (Abbott & Moorhead, 1981). However, the distinction made by Abbott & Moorhead is

useful in this research. If both are considered to be requirements, it can be stated that they are

requirements serving a different purpose in the design process and should be treated differently

according to their goal. Abbott and Moorhead (1981, p. 300) indicate about their requirements:

Since the job of requirements dentition is so broad, it is to be expected that the language in

which the results are expressed must also be very flexible. That is, since the job of a requirements

document is to describe properties needed to solve a problem, it is most appropriate to describe

those properties in the language best suited to the problem.

Natural language is considered the suiting language. However all their arguments reflect on

understandability by (naive) end users, which we have already covered. Understandability by other

developers is something different and relates to the concept of specifications. In order to keep this

comparison readable we will use the word specification like Abbott and Moorhead, however note

that this is also a requirement according to our definition.

Specifications should focus on the system and how it works and communicate this to the different

designers and engineers involved. Languages describing them should contain: Formal correctness,

abstract data types, include levels of abstraction and facilitate the testing of correctness (Abbott &

Moorhead, 1981). For this there are three criteria defined by Balzer & Goldman (1981) stating

specifications must be: Understandable, testable and maintainable. Using eight principles they are

able to derive implications for specification languages. The principles are: separating functionality

9

from implantation, the language should be process orientated, it must encompasses the system on

which the software is implemented, it must encompass the environment in which it operates, it

must be a cognitive model, specifications have to be operational and the system must be tolerant

for incompleteness.

According to Balzer & Goldman (1981) these principles lead to eighteen implications: Logical data

classification and access, uniform data specification, relational data model, global model, global

data base with inference, descriptive reference, historical references, elimination of variables,

constraint capability including strong typing, nondeterministic constructs, result specification, future

reference, demons, logical aggregation, alternative constructs (contexts), analogous specification,

normal-case specification and process models (sceneries). Using these implications a language can

be tested to its ability to capture specifications. Although natural language could meet all these

implications, this might be hard for some instances. A specially designed formal (modelling) language

could overcome this.

Practitioners of the design process should and are able to learn the correct use of such a formal

modelling language which would make it usable to transfer and communicate requirements among

them. The first real (experimental) use of formal requirements engineering was done by NASA for a

comprehensive reengineering process in which they wanted to incorporate GPS navigation in their

on-board systems. At that time, not much experience with formal requirement elicitation was

available which resulted in the concept being in used in a rather late state of the project (Jones, Till,

& Wrightson, 1998).

The original reporting of this project (Di Vito & Roberts, 1996, p. 6) makes the following careful

statement about their first encounter with formal requirements engineering:

Portions of the GPS Change Request have been modelled using the language of SRI’s

Prototype Verification System. Developing the formal specifications, even with only limited

analysis conducted on them, resulted in 86 requirements issues being discovered. Experience

with the GPS effort showed that the outlook for formal methods in this requirements analysis

domain is quite promising. The approach detailed here produced specifications that

requirements analysts and others from the Shuttle community can and did learn to read and

interpret, without having to become PVS practitioners. Moreover, the mere construction of

formal specifications using this method… led to the discovery of flaws in the requirements.

There are good prospects for the continuation of the effort by Shuttle personnel.

It became clear that the use of formal languages proves to be very efficient if the designers and

engineers are all experienced in requirement elicitation and software design. They are able to

understand these languages and based on that premises should have more advantages using formal

requirement languages rather than using natural language later in the design process, after the

initial field knowledge is required from.

10

4.4 MODIFIABILITY AND MAINTAINABILITY

One product of requirements engineering (processes) is the requirements specification. As noted in

previous sections, according to the IEEE standard (IEEE, 1991) a requirement specification must be

unambiguous, complete, verifiable, consistent, modifiable, traceable and usable during operations

and maintenance. Two important aspects of this summation are modifiability and maintenance.

Goldman and Balzer (1981) identified three main activities in which the object of specification

undergoes considerable modification: formulation, development and maintenance. The specification

is created in the formulation activity, elaborated during the iterative process of design and

implementation, and maintained when the specification is changed to reflect a modified

environment. Other researchers also identified and mentioned these possible changes to the

requirements specification. Abbott and Moorhead (1981) pointed out that the contract between

specifier and implementer changes over time (which refers to maintainability). Furthermore Fraser,

Kumar and Vaishnavi (1991) highlighted the iterative nature of the requirements elicitation process

and Jones (1996) linked creating software requirements to hiking in a gradually lifting fog (which

refer to the second activity mentioned by Goldman and Balzer).

Since requirements are stated in a particular language, the language must allow that the

requirements are easily modifiable and maintainable (Fraser, Kumar, & Vaishnavi, 1991). This holds

for changes in requirements documentation like adding specifications, deleting specifications and

fixing errors, as described by Nuseibeh and Easterbrook (2000). The topic addressed in this section is

the question whether the degree of modifiability and maintainability is affected by the use of an

informal or formal language.

Formal specification languages have a mathematical (usually formal logic) basis and employ a formal

notation to model system requirements (Andrews & Gibbins (1988); Jones (1986)). The notation and

the conceptual grammar of the formal specification languages is usually complex and requires a

degree of mathematical sophistication which does not usually exist in naïve users and in most of the

practicing analysists and designers (Fraser, Kumar, & Vaishnavi, 1991). We argue that this conceptual

grammar and notation makes it harder to easily change the corresponding requirement and thus

undermine modifiability and maintainability; Van Lamsweerde (2000) for example mentioned that

formalization involves terms and predicates which may have many different meanings and therefore

result in the need to state the meaning of each term/predicate. So if a requirement (for example) is

extended with new terms or predicates, each element should be stated explicitly. Van Lamsweerde

(2000) explicitly argued that formal specifications are hard to develop and assess. This is in line with

Jones, Till and Wrightson (1998) who stated that it generally costs more to produce a precise and

formal specification of system requirements in contradiction to the production of an informal

statement. Informal languages don’t have a that rich and well defined semantic and thus have less

constraints. Since the requirements writer doesn’t have to take into account those constraints, he or

she is able to change the requirements document faster.

11

4.5 DEGREE TO WHICH COMPLETENESS, CORRECTNESS AND CONSISTENCY CHECKS

AND PROOFS CAN BE DONE

During the development of a requirements document it is important to ensure the document meets

the needs and standards set to these documents in order to ensure a successful further

development of the software project. Zowghi, Gervasi & McRae (2001, p. 133) stated the following

about this: The goal of the participants in requirements engineering is to develop a software

requirements specification(SRS) that is concise, consistent, clear to readers, complete with respect to

user needs, and ideally can be delivered on time.

Model checking is a technique to verify if a model satisfies criteria set in the definition of the

modeling language. This ensures the model of a requirement is valid and sound, which means the

requirement is defined correctly. After the individual requirements are considered to be correct it is

possible to check the entire document for completeness, correctness and consistency. In all

languages used these checks have to be performed. In all cases this can be done manually by

requirements engineers using peer reviews, e.g. internal reviews, walkthroughs or inspections

(Melo, Shull, & Travassos, 2001). When informal languages are used this is often the only possible

technique. In the case a formal language is used to describe the requirements, it is also possible to

automate a number of tests in order to determine the completeness, correctness and consistency of

the requirements. In many instances these automated checks will also be more thorough to check

interdependencies among different requirements which might result in inconsistencies. The reason

that test automation is possible when formal languages are used is the structure of formal

languages; they are precise and mathematical operators can be used to mathematical prove the

internal consistency and correctness of the specifications (Fraser, Kumar, & Vaishnavi, 1991). As

stated in the section about the degree to which the language used can cause ambiguity,

incompleteness and inaccuracy, the major disadvantage of specifying requirements only in natural

language is inherent imprecision, such as ambiguity, incompleteness and inaccuracy (Kamalrudin,

2009).

Thus in both formal and informal languages it is important to ensure that the requirements are

complete, correct and consistent. In all cases this can be done by manually checking them and using

peer reviews, often in an iterative manner. However, formal languages provide the possibilities to

allow for a large number of automated test (as a result of their design). These automated test have

the same or better results than manually checking test and less resources are required to perform

those tests.

12

4.6 FREEDOM OF EXPRESSION

When requirements engineers are eliciting requirements, a lot of sources are used. One of these

sources are stakeholders, e.g. business engineers, project managers, developers and customers. In

large scale projects it is possible that these distributed sources generating requirements result in

difficulties handling the requirements correctly. This makes interaction among stakeholders an

important success factor; especially the participation of client groups is very important in multi-sites

development (Ko, Park, Seo, & Choi, 2007). Although interaction among stakeholders is high (and

thereby contributing to the content of the requirement), all these stakeholders want to be able to

express their specific needs for the software project in the requirements document. The form these

stakeholders are describing their needs depends on their personal vocabulary, best practices,

knowledge, experience and needs. Because of this diversification in background a significant

freedom of expression is needed to allow those stakeholders to describe, communicate, read and

assess requirements. Thus freedom of expression is an important element of the language in which

the requirements are specified.

Natural language is obviously the language with the largest possibility to express what someone

thinks. Since it is the language we use most of the time in our day to day life (Pohl, 1994). Even if the

requirement document uses a natural language which is not their own first language, users are able

to translate requirements from their first spoken language to the chosen natural language. This

allows the stakeholder to express what it is expected from the system, her or his perception of the

problem, and a minimal model of the environment in which the system to build will work (Ambriola

& Gervasi, 1997). According to a research conducted by University of Trent (Luisa, Mariangela, &

Pierluigi, 2003), most available requirements documents are written in natural language or were

obtained from information collected in interviews conducted in natural language. As mentioned

before, formal languages follow specific rules, are strict and don’t allow free interpretation. This

bounds stakeholders in expressing their specific needs.

Although the stakeholder is able to describe their needs with a lot of freedom of expression when

informal languages are used, requirements freedom of ambiguity, inconsistency and contradictory

are available (Pohl, 1994). Opposite to this are the rules imposed by formal language that guarantee

the correct interpretation of the requirements defined in the document. However, this results in a

lack of freedom of expression.

13

4.7 EASE TO WHICH CODE CAN BE GENERATED

When the activities of software systems requirements engineering are finished, documents that are

amenable to implementation should have been created (Nuseibeh & Easterbrook, 2000). The

requirements (stated in a particular formal or informal language) in those documents are used to

develop a software system. The topic in this section is the ease to which code can be generated

when either an informal or formal language is used.

The software developed after the requirements engineering activities is written in a formal

programming language. As described criterion of ‘Degree to which it can cause ambiguity,

incompleteness, and inaccuracy’, using a formal language results in less ambiguity and

misconceptions. This makes it easier to cross the divide from formal specifications to formal

implementations (Andrews & Gibbins, 1988). If the requirements used in the development of the

software are only stated in informal language, it leads to repeated manual programming, which is

error prone, unsafe and time consuming (Eden, Yehudai, & Gil, 1997).

As mentioned in the section about modifiability and maintainability, formal languages have a

mathematical (usually formal logic) basis and employ a formal notation to model system

requirements (Andrews & Gibbins, 1988) (Jones C. B., 1986). Because of this richer, well defined

semantic it is possible to (partially) automatically generate code out of the requirements (Pohl,

1994). Such an translation is clearly feasible, because the specification as well as the program can be

viewed as mathematical objects (Whalen, 1999). However, if the specification cannot be guaranteed,

the code still needs verification and validation (Whalen, 1999). Since requirements stated in informal

language are subject to ambiguity (as described in previous sections), using requirements written in

informal languages will result in the need to always verify and validate the code; something you

would also do for manually generated code. Thus one should use a formal specification language if

one is using automatic code generation tools.

14

4.8 DEGREE TO WHICH THE LANGUAGE CAN INCLUDE OR SUPPORT OTHER

LANGUAGES

During the development of software requirements it might be necessary at some points to translate

requirements form one language to another. This might be necessary to communicate them to

stakeholders not familiar with a given (formal) requirements language or in order to use automated

code generation tools. This is in most cases relatively easy done by hand if the engineer is familiar

with the modelling language.

For some languages automated tools exist to translate formal requirement models to other

languages. However, not much research on this topic has been found. The Object-Process

Methodology (OPM) does provide tools to translate the formal requirement models to natural

language (Dori, 2002). This makes relative complex models easy to understand by non-specialists,

while people familiar with the modelling language are able to use the full potential of the formal

modelling language. Other languages can also support similar functions, allowing more people to

understand the formal requirements in natural language.

Translating natural language to formal requirements is mostly done by hand. This is a result of the

fact that natural language often does not provide the unambiguity needed to support automated

parsing to a formal language. There are tools feasible to support this to some extent. However, the

formal requirements generated have to be precisely checked for consistency with the original

natural language requirements. The semantics of informal languages are described using natural

language (Tse & Pong, 1991). Thus a basic language that can include or support other languages is an

informal (natural) language.

15

5. PRACTICAL CASES

In order to determine the actual use of informal and formal two cases are presented. One case is of

a requirements definition using a formal language; the other uses an informal language.

5.1 A FORMAL EXAMPLE

A practical example of the use of formal requirements specification languages is given in Bowen

(2003). In this case multiple requirement documents are generated for the Distributed Computing

Software (DCS) project which is designed at the Oxford University Computing Laboratory using the Z

language. The designs have formed the basis for manuals for each of the services. Two different

types of manual have been produced. User Manuals have been designed to describe each service

from the point of view of a client program using the service via Remote Procedure Calls (RPCs) over a

network. In addition, Implementer Manuals have been produced for some services. These describe

how the service may be implemented internally. All these documents are made in the Z language.

Z language is an abstract and formal requirements modeling language. Z was originally proposed by

Jean-Raymond Abrial in 1977 with the help of Steve Schuman and Bertrand Meyer. It was developed

further at the Programming Research Group at Oxford University, where Abrial worked in the early

1980s, having arrived at Oxford in September 1979. Z is based on the standard mathematical

notation used in axiomatic set theory, lambda calculus, and first-order predicate logic. All

expressions in Z notation are typed, thereby avoiding some of the paradoxes of naive set theory. Z

contains a standardized catalog (called the mathematical toolkit) of commonly used mathematical

functions and predicates. (Wikipedia foundation, 2013)

Both the documents in this case are part of the specification of the design and intended to be used

by designers to implement RPCs in their software. In the framework provided on software

requirement generation these documents would be used to verify and validate the requirements.

The manuals are written as complete and readable as possible while using a formal language. They

provided a clear framework for developers to correctly implement and support RPCs in their

software. This allowed RPCs to be used by different teams developing software without

compatibility problems.

The user manuals needed to provide an abstract view on the service from the outside to show how

the RPCs can be used by outside services. Internal mechanisms are highly abstracted. Using a formal

language enabled the developers to base these user manuals on previously generated documents

rather quick reducing the production time of this specific requirements document.

The implementer manuals do need to provide a detailed view on the inside of the RPCs. The

developers choose also Z language for this document rather than some form of pseudo code. The

notation did need some extensions to enable it to support recursive and iterative functions, this was

not yet supported by Z, but necessary to correctly describe the requirements. The main reason to

use Z language was too enable the documents to be verified with other documents such as the user

manuals. Z allows for easy manual verification and validation of these processes. The developers

argued using Z would in the future enable more automated coding and validation tools. In any case,

16

the Implementer Manuals have been designed to convey the design to a programmer, rather than to

aid a proof of correctness by defining its relationship with the User Manual (although this

relationship is included formally in the Implementer Manual) (Bowen, 2003).

This example shows that the use of a formal language has advantages later in the design process

when different documents have to be generated for different stakeholders, while staying consistent

and checkable. This supports the criteria of understandability by practicing analysts, maintainability

and degree to which completeness, correctness and consistency checks can be done. It also showed

the limitations in freedom of expression which needed to be addressed.

5.2 AN INFORMAL EXAMPLE

An extensive search for a case study that primarily describes the development of an informal natural

specification as well as the difficulties that were encountered during this development, has been

conducted3. However, no literature is found that primarily describes this development or these

difficulties . One of the search results is the paper by Satpathy, Harrison, Snook & Butler (2001). In

their comparative study of formal and informal specifications a problem is taken from industry and

specified in two languages: B [a model-oriented formal specification language] and UML [an informal

specification language]. The case study consisted of a hard to understand and complex TV text

module of a new generation TV. Two equally experienced subjects started in parallel and

independently produced half of either a formal specification or an informal specification. When the

first halve of both documents has been produced, they are swapped in order to minimize the effects

of experience. Comparison of the B and UML specifications yielded several conclusions. At the higher

level, the structure of the UML specification was similar to the structure of the B specification.

However, when moving to lower levels it was harder to produce the UML specification. The

‘rigorous’ nature of the initial specification is presented as the reason. It was therefore found that an

informal description was not sufficient to achieve a high level of precision. The B language, in

contrast, was less ambiguous because of the precision needed to produce the specification. With

respect to intuitive and readable structure the UML language facilitated the best specification.

This example shows, in correspondence with the previous example, that the use of a formal

language has advantages later in the design process. This is in line with literature study results

regarding the freedom of expression and the degree to which the language used can cause

ambiguity. The observation that the UML language produced a more intuitive and readable structure

may support our literature study regarding modifiability and maintainability; when an informal

specification language is used, the documents are more maintainable and modifiable. A case study

by Gehani (1982) confirms this: informal specifications are easier to read, but formal specifications

are clearer, specify operation domains precisely, define the interaction between operations, show

the incompleteness of the informal specifications and are devoid of implementation details.

3 Literature search in various databases has been conducted using combinations of terms “case”, “field study”, “case study”, “informal specification”, “natural language specification”, “informal specification”, “informal requirements”, “natural language requirements”, “informal requirements engineering” and “natural language requirements engineering”.

17

6. CONCLUSION AND DISCUSSION

In this literature study a comparison is made between informal and formal specifications language

by using a conceptual framework to assess high quality literature. The results of applying this

conceptual framework as well as the framework itself are presented in table 1 below. These results

are used to approve or reject the hypotheses stated in the problem description.

Table 1: Conceptual framework with results

The elicitation phase contains activities that are aimed at defining the system boundaries, identifying

stakeholders, formulating goals, and eliciting other relevant information (Nuseibeh & Easterbrook,

2000). These activities involve a high involvement of stakeholders, who are the people or

organisations who will be affected by the system and who have a direct or indirect influence on the

system requirements (Kotonya & Sommerville, 1998). Because of this high stakeholder involvement

understandability by naïve users is an important factor (Fraser, Kumar, & Vaishnavi, 1991).

Furthermore the documents used will undergo considerable modifications, which points out the

importance of modifiability and maintainability. Since people involved in the requirements

engineering process have various roles and different skills and knowledge, each has his or her own

understanding of the system to be build (Pohl, 1994). This highlights the need of freedom of

expression. The analysis of these criteria identified that an informal language should be used to

specify the requirements, which confirms hypothesis 1. An important note to make is that ambiguity,

incompleteness inaccuracy is important throughout the whole software development project.

During the requirements analysis the stakeholder’s needs, assumptions, and other information

identified during elicitation are melded together and further refined (Westfall, 2005). This includes

representing the requirements in various forms (e.g. prototypes and models), performing trade-off

analysis, establishing priorities, analysing feasibility and looking for missing requirements (Westfall,

2005). Since the documents used are still (and will be) modified on a regular basis, modifiability and

maintainability is important. In order to check whether conflicting requirements exist, automated

check tools could be preferable. This highlights the importance of the degree to which

18

completeness, correctness, and consistency checks can be done, which results in the need of a

formal language that minimizes ambiguity, incompleteness and inaccuracy. In our opinion it isn’t

feasible to use a formal specification language in those (analysis) activities, because of the high

investment (costs) involved in producing formal requirements (Jones, Till, & Wrightson, 1998).

Furthermore one could perform completeness, consistency and inaccuracy checks by means of

reviews. When one refined the elicitated information and requirements in more detail to formal

requirements, one could be unwilling to consider the need for change. Since it is likely that change is

needed because of the iterative nature of the elicitation, analysis, specification and validation

phases, one should start formalising the requirements when the requirements mostly agreed

upon/baselined. Since in this step the requirements are not yet baselined, one shouldn’t make more

use of formal languages during the analysis activities than used during the elicitation activities, which

rejects hypothesis 2.

After the analysis phase, activities of the specification step phase are conducted. During the

specification step the requirements are formally documented so they can be communicated to the

product stakeholders (Westfall, 2005). This can be done using a single requirement document or

using multiple documents in different forms such as: use cases, specific documents for specific

stakeholders, if the software is part of a larger system the architecture of this larger system might be

provided, external interfaces might be included (Westfall, 2005). Since this document is

communicated to the product stakeholders, understandability by naïve users is important. This

stresses the importance of informal languages. As noted before, because of the iterative nature of

the various phases, modifiability and maintainability is an important element. This criterion also

promotes an informal specification language. Kotonya & Sommerville (1998, p. 15) stated the

following about the requirements document:

“The system and software requirements are usually documented in a formal document which is used

to communicate the requirements to customers, system and software engineers and managers of the

systems engineering process.”

From this statement follows that system and software engineers also should be able to fully

understand the stated requirements, which highlights the importance of understandability by

practicing analysts and designers. Although they fully understand natural languages, formal

languages provide the rigor needed to communicate with them (designer/constructor) (Fraser,

Kumar, & Vaishnavi, 1991). Since it is impractical to define a requirements specification only in terms

of a single or textual language and the semantics of formal languages are explained via natural

language, it is argued by Tse and Pong (1991) to use a language that exists in more than one format.

We agree with those authors to use a language that is convertible from formal to informal and vice

versa at a high level of abstraction . If in the various iterations more and more requirements are

baselined and lower abstraction levels are reached that are of importance to designers, a translation

to formal representations becomes more and more important. Reasons for this are the ease to

which code can be generated, the degree to which completeness, correctness, and consistency

checks and proofs can be done and the degree to which the language used can cause ambiguity,

incompleteness, and inaccuracy. Thus one should start formalising after a significant amount of

baselined requirements is identified together with lower levels of abstractions. This combination of

19

formal and informal approaches is also identified by Fraser, Kumar and Vaishnavi (1991). This argues

for a fifty-fifty distribution of the use of informal and formal languages. Therefore hypothesis 3, that

states that formal languages should be more present, is rejected.

The fourth hypothesis is about the prominent use of formal languages in the verification and

validation phase of the requirements document. During the validation phase it is checked if the

requirements meet all the stakeholder demands. This is usually done using (formal) peer-reviews

(Westfall, 2005). The review should ensure the entire document is: complete, consistent and

modifiable. The individual requirements must be: unambiguous, concise, finite, measurable, feasible,

testable and traceable. Validating can also be done using different test cases and writing

requirements for black box testing. Since functional testing only requires knowledge of the

requirements and not of the internals of the software product, practitioners can start writing test

cases against their requirements as soon as they start writing them. The major advantage of writing

the functional test cases early in the life cycle is that it will uncover defects in the requirements.

Writing test cases early in the process may result in some rework if the requirements change, but

the cost of that rework will be more than offset by the savings resulting from finding and fixing more

requirements defects earlier (Westfall, 2005). Since the product of the specification phase activities

is discussed in the validation phase and the validation phase can result in rework of the

requirements document, the same conclusion regarding the use of formal and informal languages in

the specification phase applies for the validation phase; an hybrid use of formal and informal

languages is required. This rejects hypothesis 4.

The case of the RPCs development clearly showed designers in the validation and verification phase

of the project choosing a formal requirements language, Z language, to generate multiple

documents for different users. The use of a common language allowed them to relatively quick

generate documents for different stakeholders while providing verification and validation strength

to keep the documents consistent with each other. Providing a practical proof of hypothesis 4.

The following section presents limitations of this research.

LIMITATIONS

A Limitation of this research is that it is based on only this current state of literature. Further

research should also validate the criteria such as the automated translating to other languages.

Other criteria might show different results. Also formal and informal languages where seen as a

single entity. The results provided do not necessarily hold for all formal and informal requirement

languages.

20

BIBLIOGRAPHY

Abbott, R. J., & Moorhead, D. K. (1981, December). Software Requirements and Specifications: A

Survey of Needs and Languages. The Journal of Systems and Software, 2(4), 297-316.

Ambriola, V., & Gervasi, V. (1997). Processing Natural Language Requirements. Automated Software

Engineering, 1997. Proceedings., 12th IEEE International Conference, 36-45 .

Andrews, D., & Gibbins, P. (1988). An Introduction To Formal Methods Of Software Development.

McGraw-Hill Education.

Balzer, R., & Goldman, N. (1981). Principles of good software specification and their implications for

specification languages. National Computer conference, (pp. 393-400).

Bowen, J. (2003). Formal Specification and Documentation using Z.

Cares, C., Franch, X., Perini, A., & Susi, A. (2011). Towards interoperability of i* models using iStarML.

Computer Standards & Interfaces, 69-79.

CoFi - Universitat Bremen. (n.d.). CASL reference manual. Bremen.

Coughlan, J., Lycett, M., & Macredie, R. D. (2003). Communitcation issues in requirements

elicitation: a content analysis of stakeholder experiences. Information and Software

Technology, 525-537.

Denger, C., Berry, D. M., & Kamsties, E. (2003). Higher Quality Requirements Specifications through

Natural Language Patterns. Software: Science, Technology and Engineering, 2003. SwSTE '03.

Proceedings. IEEE International Conference on, 80-90.

Di Vito, B. L., & Roberts, L. W. (1996). Using Formal Methods to Assist in the Requirements Analysis of

the Space Shuttle GPS Change Request. Hampton, Virginia: National Aeronautics and Space

Administration.

Dori, D. (2002). Object-process methodology: a holistics systems paradigm. Berlin Heidelberg New

York: Springer-Verlag.

Eden, A. H., Yehudai, A., & Gil, J. (1997). Precise specification and automatic application of design

patterns. Proceedings of the 12th IEEE International Conference on Automated Software

Engineering, (pp. 143-152).

Fraser, M. D., Kumar, K., & Vaishnavi, V. K. (1991, MAY). Informal and Formal Requirements

Specification Languages: Bridging the Gap. IEEE TRANSACTIONS ON SOFTWARE

ENGINEERING, 17(5), 454-466.

Gehani, N. (1982). Specifications: Formal and informal - a case study. Software: Practice and

Experience, 12(5), 433-44.

21

IEEE. (1991). IEEE std. 830-1984, Guide for software requirements specifications (ANSI). In IEEE, IEEE

Software Engineering Standards Collection. New York.

IEEE StandardsBoard. (1990). IEEE Standard Glossary of Software Engineering Terminology. New

York: IEEE.

Jones, C. (1996, June). Strategies for managing requirements creep. IEEE Computer, 29(6), 92-94.

Jones, C. (1996a). Activity-based software costing. IEEE Computers, 103-104.

Jones, C. B. (1986). Systematic Software Development ·Using VDM. Prentice Hall.

Jones, S., Till, D., & Wrightson, A. M. (1998, March). Formal methods and requirements engineering:

Challenges and synergies. Journal of Systems and Software, 40(3), 263-273.

Kamalrudin, M. (2009). Automated Software Tool Support for Checking the Inconsistency of

Requirements. IEEE/ACM International Conference on Automated Software Engineering,

693- 697 .

Kamsties, E. (2001). Surfacing Ambiguity Natural Language Requirements. Ph.D. Dissertation.

Kaiserslautern, Germany: Universität Kaiserslauter.

Keil, M., Cule, P., Lyytinen, K., & Schmidt, R. (1998). A framework for identifying software project

risks. Communications of the ACM, 76 - 83 .

Ko, Y., Park, S., Seo, J., & Choi, S. (2007). Using classification techniques for informal requirements in

the requirements analysis-supporting system. Information and Software Technology, 11-12.

Kotonya, G., & Sommerville, I. (1998). Requirements engineering: processes and techniques. John

Wiley & Son Ltd.

Kudikyala, U. K., & Vaughn, R. B. (2005). Software requirement understanding using Pathfinder

networks: discovering and evaluating mental models. The Journal of Systems and Software

74, 101-109.

Luisa, M., Mariangela, F., & Pierluigi, N. I. (2003). Market research for requirements analysis using

linguistic tools. In press.

Melo, W., Shull, F., & Travassos, G. H. (2001). Software Review Guidelines. Technical Report ES-

556/01, Federal University of Rio de Janeiro, Systems Engineering and Computer Science

Department.

Nuseibeh, B., & Easterbrook, S. (2000). Requirements Engineering: A Roadmap. ICSE '00 Proceedings

of the Conference on The Future of Software Engineering (pp. 35-46). Limerick: ACM New

York.

Pohl, K. (1994). The Three Dimensions of Requirements Engineering: A framework And Its

Applications. Information Systems, 19(3), 243-258.

22

Rajlich, V. (2006). Changing the Paradigm of Software Engineering. Communications of the ACM,

49(8), 67-70.

Satpathy, M., Harrison, R., Snook, C., & Butler, M. (2001). A comparative study of formal and

informal specifications through an industrial case study. IEEE/ IFIP Workshop on Formal

Specification of Computer Based Systems (FSCBS'01).

Siddiqi, J., & Shekaran, M. (1996). Requirements Engineering: The Emerging Wisdom. IEEE Software,

13(2), 15-19.

Society, IEEE Computer. (1990). IEEE Standard Glossary of Software Engineering Terminology. New

York: IEEE.

Tse, T. H., & Pong, L. (1991). An Examination of Requirements Specification Languages. The

Computer Journal, 34(2), 143-152.

University of Toronto, CANADA . (2012, 12 13). GRL - Goal-oriented Requirement Language.

Retrieved from http://www.cs.toronto.edu/km/GRL/

Van Lamsweerde, A. (2000). Formal Specification: a Roadmap. ICSE '00 Proceedings of the

Conference on The Future of Software Engineering, (pp. 147-159). New York.

Westfall, L. (2005). Software Requirements Engineering: What, Why, Who, When, and How. World

Conference on Quality and Improvement.

Whalen, M. (1999). On the requirements of high-integrity code generation. Proceedings of the 4th

IEEE International Symposium High-Assurance Systems Engineering, (pp. 217-224).

Wiegers, K. E. (2003). Software Requirements (Second ed.). Microsoft Press.

Wikipedia foundation. (2013, Januari 26). Z notation. Retrieved from Wikipedia:

http://en.wikipedia.org/wiki/Z_notation

Zowghi, D., Gervasi, V., & McRae, A. (2001). Using Default Reasoning to Discover Inconsistencies.

Software Engineering Conference, 2001. APSEC 2001. Eighth Asia-Pacific, 133-140 .