In this chapter, we describe how we really use KAOS to write some of the

Chapter 3 Application of KAOS by a case study

In this chapter, we describe how we really use KAOS to write some of the

requirements in this case study. At the end of this chapter, we discuss our experience

of applying formal language in the case study.

3.1 Collected Interview Data

Since the whole project contains too many details, here we focus on some

requirement in the project. Taking the functionality of dividing students into classes in

the class management subsystem for example, in order to collect the requirements of

the new YLCSAS, we invited several staffs who are responsible for class management

for interview. We invited them to describe their working process in details, the

problems of using the old YLCSAS, and their idea of how to improve the problems.

From the interview, we can put the whole requirements briefly below.

(1). divide students into classes after they complete registration

(2). re-divide students into classes after promotion (2

to 3

and 4

to 5

)

(3). divide students into classes automatically

(4). functionality of refining the students of classes

(5). limitation on the number of classes in a school

(6). limitation on the number of student in a class

(7). disperse the handicapped students in different classes

(8). create special classes for students who have talent in music, art…etc

(9). create resource classes for the students with mental retardation

After acquiring the requirements from the potential users, we apply KAOS to

them and try to write these requirement in formal manner. The detail will be

illustrated in next section.

3.2 Goal Structure

Figure 3-1 Goal structure of class management subsystem

Figure 3-1 is an AND/OR graph in KAOS which shows the refined goal structure

acquired from the requirements. The root goal named Achieve

[DivIntoClsRequestSatisfied] means the request of dividing students into classes must

be satisfied. This root goal can be accomplished through Achieve[UpgradeDirectly] or

through a combination of four goals – Achieve[StuDataRequestSatisfied], Achieve

[ClsRequestSatisfied], Achieve[DivStuIntoClsSatisfied] and Maintain[Fairness].

The left leaf of the root named Achieve[UpgradeDirectly] means the classes in

second grades and fourth grades will be upgraded directly. The right branch of the

root goal means the students have to be divided into new classes. In order to achieve it,

there are four subgoals to be satisfied. The first one is getting all students’ data which

would be valid if they have be imported from the household-registration database or

typed by the teachers. The second one is getting all classes’ data which would be valid

if the registrar has created them and set their attributes correctly. The third one is

executing the dividing process manually or automatically. The process of dividing

students into classes automatically can be separated into two parts – dividing normal

students and dividing special students. Furthermore, due to the requirement of the

resource class, the goal of dividing special students can be separated into dividing

talented students and dividing students with mental retardation further. The fourth is

maintaining Fairness which conflicts with the goal of dividing students into classes

manually.

3.3 Define Objects in the Goal Structure

In this section, we will define several objects in the goal structure in Figure 3-1

by the acquisition language proposed by KAOS, and the full version can be seen in

Appendix A .

First of all, we define the root goal Achieve[DivIntoClsRequestSatisfied] as

Figure 3-2 shows. It is an instance of SatisfactionGoal, and it concerns with four

objects – Registrar, Student, Class, and School. The formal definition of this goal

means that ”If the registrar is working in the school, the student is studying in the

school, and the class belongs to the school, then after performing the Div action the

student will become a member of the class.” However, the data of the students and the

classes might be unavailable and the fairness is not taken into consideration yet, so

this goal can be reduced into UpgradeDirectly or into the combination of four

subgoals – StuDataRequestSatisfied, ClassRequestSatisfied, DivStuIntoClsSatisfied

and Fairness.

Figure 3-2 Definition of Achieve [DivIntoClsRequestSatisfied]

The next step shown in Figure 3-3 is defining the system goal – Achieve

[UpgradeDirectly]. Its formal definition means that” If the student is the member of

the class and the grade of the class is 2 or 4, then after performing the Upgrade action

the grade of the class will be the old grade plus one and the student will still be the

member of that class.”

Figure 3-3 Definition of Achieve[UpgradeDirectly]

Figure 3-4 shows the definition of the system goal – Maintain[Fairness].

However, it is a nonoperational goal because we can not make sure whether the

teacher will sign to accept the task of leading the class. In order to make it operational,

we define the soft constraint called Maintain[EquiaLoadForTch] as Figure 3-5 shows.

This constraint is for making sure that the load of the teacher is equal, in other words,

the number of students in one class has to be closer to which in another one. Besides,

the number of special students also must be taken into consideration. In Yi-Lan

County, one special student can be weighted equally for three normal students. This

requirement is the strengthened post condition ensured by the action AutoDiv.

Figure 3-4 Definition of Maintain[Fairness]

Figure 3-5 Definition of Maintain[EuqalLoadForTch]

The action SignToAccept shown in Figure 3-6 takes the teacher and the class as

input and output the relationship Leading shown in Figure 3-7. The precondition of

the action SignToAccept is that the teacher must be working in the school and the class

must belong to this school and the student must study in this school. After performing

this action, this teacher will become the leader of the class. Besides this, the teacher

cannot be the leader of another class. The relationship Leading links the teacher and

the class which is led by the teacher. From the invariant of the relationship Leading

we can know that if one teacher leads one class and the student is the member of that

class, then the teacher will have the authority to know the student’s data.

Figure 3-6 Definition of Action SignToAccept

Figure 3-7 Definition of Relationship Leadi ng

3.4 Formal vs. Informal

The KAOS acquisition language is a formal language to provide some formal

basis for elicitation of requirements. Besides this formal language, there are other

informal ways such as using natural language and using prototype developing to

describing requirements. Although the KAOS acquisition language itself has some

advantages such as preciseness, there are some drawbacks we found in the process of

applying KAOS on the YLCSAS.

(1). Poor readability

We believe poor readability is the major problem of the formal language like

KAOS. Using mathematical symbols to define objects is good in precision,

but it is hard to read even for experienced programmers, let alone clients.

Figure 3-8 Definition of Action DivRemind

For example, Figure 3-8 shows the action DivRemind which reminds

the registrar to divide students into classes. In natural language, we can

describe this requirement easily like this – “If the student is not one of any

class member over one day, then there will be a reminder which is sent by

the system to the registrar.” In contrast, the mathematical formula such as

“ ¬ ◆

Member(stu,cls)” which also means “the student is not one of

any class member over one day” cannot be understood intuitively. The

formal language is not easy to learn. It imposes a steep learning curve to

both the requirement writers and readers.

(2). Difficulty in describing nonfunctional requirements

It is very difficult to describe nonfunctional requirements in formal language.

For example, when it comes to the requirement of friendly user interface, we

usually use prototype developing to check whether this interface is friendly

enough to the user via a usability survey. After that, the prototype user

interface can be used as a specification. Because it is easy to understand

what the designer want to say by a graphical presentation such as Figure 3-9

shows.

Figure 3-9 The user interface of the class management subsystem

(3). Sequence of Action

In the scheduling subsystem, we define the system goal Achieve

[ManageTchAskForLeave] as Figure 3-10 shows. The formal definition of

this goal means that “If there is a teacher substituting for another teacher’s

course, and this course is in the period of the leaving period. We can know

that the teacher must have asked for leave, and the registrar has found the

substitute teacher and record this substation.” However, we only know that

the registrar has performed these two actions – SearchAvailableTch and

RecordSubTch, but we cannot see the sequence of these two actions in the

expression of this goal’s definition.

Figure 3-10 Definition of Achieve[ManageTchAskForLeave]

We come to the conclusion that the KAOS methodology is good for analyzing

the requirements, but it is not easy to apply it on the real application. The figure of the

KAOS goal structure is useful to understand the general concept of the requirements.

The process of thinking over the goal structure contributes to the requirement analysis,

and expressing the requirements in formal language is good for the accuracy and

precision of specification. However, describing the requirements in formal language

such as the KAOS acquisition language is much harder than in natural language. At

least in the experience of this work, we believe most of the time, requirement

described in natural language are satisfactory for most of the time. Whenever it is no

longer satisfactory, strengthening the requirement with prototype user interface or

UML diagrams is most of the time beyond adequate in our case study.

The most important advantage of natural language is its popularity, that is to say,

everybody can understand what the sentence which is described in natural language

means. Moreover, there are still some kinds of requirements which the KAOS

acquisition language cannot describe properly. That’s why we conclude that it is not

easy to apply KAOS on the real application.