A Method for Analyzing the Context of Stakeholders and their

Requirements

Takako Nakatani and Yuko Koiso

Graduate School of Business Sciences, University of Tsukuba, 3-29-1, Otsukba, Bunkyo-ku,112-0012 Tokyo, Japan

Keywords:

Requirements Elicitation, Environmental Factors, Social Relations, Stakeholder Analysis.

Abstract:

Requirements of software are sometimes added and changed throughout the development phases. In this paper,

we introduce a method to analyze environmental factors that sometimes cause changes in requirements. The

scope of the i* framework, for example, does not focus on environmental factors, but on the intentional actors

and their dependencies. To date, the various environmental factors are not analyzed well. Furthermore, some of

the environmental factors have relationships with stakeholders and thus change the intentions of stakeholders

through these social relations. We consider these relationships as one of the providers of and a mechanism that

forces changes in requirements. Before we proceed to prove the role of this mechanism through an application

to a real project, we ﬁrst deﬁne four social relations that connect an environmental factor and a stakeholder,

and introduce an analysis method of the context. The effectiveness of the method is shown through several

examples and discussed from the view of the possibility of the prediction of requirements changes.

1 INTRODUCTION

Requirements volatility produces various negative ef-

fects on the software development process: reduc-

tion of performance (Zowghi and Nurmuliani, 2002)

and increase of costs to the project. Ebert and Man

focused on the problems that cause requirements

volatility (Ebert and D., 2005). Also, the risks in-

volved in requirements volatility have been discussed

by Williams et al (Williams et al., 2006).

Multiples of methods have been introduced to pre-

vent requirements changes. For example, analyzing

goals to be achieved helps analysts clarify operations

as requirements and conﬂicts between goals (van

Lamsweerde, 2004; Damas et al., 2006). When we

have analyzed a business in the early requirements

analysis phase, we understand the world more pre-

cisely. Yu, et al. developed the i* framework to

clarify dependencies among stakeholders in a strate-

gic dependency model and analyze goals achieved by

the stakeholders themselves with a strategic rationale

model (Yu and Mylopoulos, 1998). Yu and his col-

leagues also integrated the models and a process mod-

eling method in order to develop a business modeling

technique (Yu et al., 2011). The integration leads an-

alysts to elicit more stable requirements.

In general, the process of requirements elici-

tation originates from listing important stakehold-

ers. Alexander and Robertson deﬁned an onion

model (Alexander and Robertson, 2004; Robertson

and Robertson, 2005). In the onion model, each stake-

holder is categorized within the zones of the model.

Each zone represents how each stakeholder relates to

the developing product with regard to the distance be-

tween the stakeholder and the product. The onion

model is effective to cover important stakeholders

with whom requirements analysts interview and elicit

their requirements from.

Why cannot these methods prevent requirements

changes? One of the answers is that requirements

are volatile; and basically, we cannot prevent them

from changes. However, there may be another an-

swer. These methods are focused on issues in the pro-

cess of development, communication between users

and developers, the quality of documents, personal

capabilities, and so on (Bano et al., 2012). We con-

sider that the scope of the methods may be too nar-

row to deal with requirements changes. This does not

mean that we have to explore other stakeholders, but

more precisely, analyze the context of related stake-

holders (Pohl, 2010). Faily et al. deﬁned the con-

text as the environment of operation of users (Faily

and Flechais, 2009). The context of personal require-

ments should be analyzed in some sort of system:

learning and training applications, entertainment and

games, etc. (Sutcliffe et al., 2005). It is also important

357

Nakatani T. and Koiso Y..

A Method for Analyzing the Context of Stakeholders and their Requirements.

DOI: 10.5220/0005096903570362

In Proceedings of the 9th International Conference on Software Engineering and Applications (ICSOFT-EA-2014), pages 357-362

ISBN: 978-989-758-036-9

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

to analyze the context of business information sys-

tems where competitive advantage which is a goal of

most companies and cooperation with other compa-

nies are important. If these competitive and/or coop-

erative relationships between companies are changed,

the decisions of stakeholders must be affected. As a

result, their requirements are changed. We can de-

ﬁne the context of business information systems as

being the environment of operations, and that it is not

limited solely to the user, but also to business peo-

ple and/or organizations. Thus, the context affects the

decisions of stakeholders. When the changes in re-

quirements caused by changes in the context of busi-

ness information systems are observed, they may have

been classiﬁed into missing requirements, functional

enhancement, or product strategy (Nurmuliani et al.,

2004).

The context consists of environmental fac-

tors (MacAulay, 1996; Sommerville and Sawyer,

1997; Kotonya and Sommerville, 1998) and relations

between them and stakeholders. Candidates of envi-

ronmental factors are competitors, cooperative orga-

nizations, the natural environment, etc. Though there

are various factors, we regard the principles of these

factors to be but a few. We have challenged ourselves

to clarify the basic concepts of the environmental fac-

tors, and further, set them inside the scope of analysis

in order to analyze the variability of requirements.

We term “relation” between the environmental

factors and stakeholders as “social relation”, since a

change caused in the environment which is the society

surrounding the stakeholders, propagates to a stake-

holder via the relation, and further, affects his/her

intention within their various organizations. Stake-

holders may not be able to control or manage such

changes, but we have conﬁdence that if analysts take

into consideration the context of the decisions of

stakeholders, they must be able to analyze the pos-

sible changes within the context and, predict them.

There is a method developed to analyze dependen-

cies between stakeholders. The i* framework (Yu and

Mylopoulos, 1998) consists of two models: the strate-

gic dependency model (SD model) and the strategic

rationale model (SR model). The SD model con-

tains dependency relations between intentional actors

within the analyzing world. The intentional actors are

the stakeholders of the developing system. There are

four types of dependency between actors: task, re-

source, goal, and soft goal. The actors within the

scope of the i* framework already hold intentions in

deciding the requirements of the developing system

when the analysis starts. Hence, the environmental

factors that affect the intentions of the actors had been

set outside the scope of the i* framework.

The purpose of this paper is to introduce an anal-

ysis method to deﬁne social relations in order to pre-

dict requirements changes. We extend the SD model

to introduce social relations. In order to introduce

the social relations, we adopt Fiske’s human rela-

tions (Fiske, 1992). When the method is applied in the

early requirements phase, the context of stakeholders

will be visualized. We expect such visualization to be

effective in understanding the context of each stake-

holder’s decisions and in evaluating the volatility of

the context and thus, his/her requirements.

This paper is organized as follows. In section 2,

we introduce the method used to analyze social rela-

tions with regard to environmental factors. In section

3, we evaluate the effectiveness of the method by ap-

plying the method to a real project and visualize the

environment of the stakeholders and the mechanism

of requirements changes. In the ﬁnal section, we con-

clude this paper.

2 ANALYSIS OF THE CONTEXT

In this section, we ﬁrst introduce four types of social

relation by adopting Fiske’s human relations. After

that, we present a process of the analysis.

2.1 Social Relations

Fiske classiﬁed human relations into four elementary

forms: communal sharing, authority ranking, equal-

ity matching, and market pricing (Fiske, 1992). The

forms can be interpreted as social relations: shar-

ing relation, ranking relation, exchanging relation,

and contracting relation, respectively (Nakatani and

Tsumaki, 2014). In order to analyze the context of in-

tentional actors, we extend the SD model by adding

medium that causes changes in the intentions of a

stakeholder and the four social relations, as propaga-

tion paths of the changes. Some examples of various

media are gifts, offerings, sharing properties, strate-

gies, rules, constraints, force, rights, etc.

The detailed deﬁnitions of social relations are as

follows:

• Sharing Relation.

Sharing relations are relations between parties

who share the common interests and/or cultures

and feel that the good things for one are also good

things for another. The parties are sometimes

competitors or rivals.

• Ranking Relation.

The upper ranking parties have privileges over the

lower ranking parties. Ranking is introduced into

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

358

societies such as militaries and corporations. Par-

ties on both sides have social responsibilities.

• Exchanging Relation.

This type of relation guarantees interdependence

and fair exchange.

• Contracting Relation.

Social contracts include tradition, rules, promises,

etc. A party who breaks the contracts receives so-

cial punishments.

2.2 Process of the Analysis

We assume that an SD model has been presented be-

fore analysts start to apply our method. The main

part of our method is to analyze four types of rela-

tions connected with the actors within the original SD

model. Such a starting point will give a hint to the an-

alysts who are the extracting parties within the context

of intentional actors in the SD model. The following

process is repeated until the effect of changes in envi-

ronmental factors on the intentional actors is consid-

ered small enough to be ignored.

1. Focus on each intentional actor within the SD

model.

2. Extract and deﬁne parties who have a social rela-

tion with the intentional actor or parties deﬁned in

the context.

If the party is already deﬁned within the world of

analysis, the relation can only be deﬁned as one

between the party and the actor.

3. Deﬁne the social relation and a medium with re-

gard to the relation.

4. Analyze the variability of parties and media.

The existence of variability implies requirements

changes.

The legend of the notation is shown in Figure 1.

Each social relation in the notation of the extended

SD model has the ﬁrst letter of each social relation.

An example of the result of the analysis is shown in

Figure 2. Analysts explore each social relation by

providing a medium for each stakeholder.

Medium

higher

lower

Sharing relation

Ranking relation

Contracting relation

Exchanging relation

Figure 1: The legend of the extended SD model.

The world of

Requirements

Analysis

Medium

The world of the context of stakeholders

Variability of actors

Figure 2: An example of the result of the analysis.

3 APPLICATION OF THE

METHOD

In order to evaluate the effectiveness of the method,

we applied it to a real project.

3.1 Overview

The project was initiated to develop a support system

of the contract of a non-life insurance (NIC) system.

Agents use the system on their tablet computers and

input the data of their customer’s contracts digitally.

The system veriﬁes the contract data when an agent

puts it into the system. After that, the policyholder

candidate who is a customer of the agent agrees to

the contract. The data is sent to the non-life insur-

ance management system on the host computer and is

registered. Once the contract data is registered, any

policyholder can refer to his/her contract and their in-

surance policy via the internet.

We can draw a before and after picture of the in-

stallation of the NIC system with SD model.

3.2 The System-as-is

Before the NIC system was installed, the agents used

personal terminals developed only for the contracts

of insurance. The terminal could check the manda-

tory items in a contract and send the data to the non-

life insurance management system that would verify

the data formally. If there were errors in the contract

data, the agent would correct the data on the physi-

cal application form under his/her customer’s agree-

ment. After the agreement, the agent would send the

physical application form to the insurance company

and the corrected digital application data to the non-

life insurance management system from his/her termi-

nal. Thus, the insurance company employed people

as veriﬁers who were in charge of the veriﬁcation of

contracts by comparing the content from the physical

application form with the content from the digitally

AMethodforAnalyzingtheContextofStakeholdersandtheirRequirements

359

registered data in the non-life insurance management

system.

Figure 3 shows the situation as the system-as-is

model with the i* framework. The intentional actors

in the system-as-is were the insurance company, the

policyholder or its candidate, the person insured, and

the agents. These actors are the stakeholders of the

system-to-be of the NIC system. Further, paper appli-

cation forms and veriﬁers are shown in the ﬁgure.

Since, the system-as-is had the two kinds of data

for a single contract, one in paper form, and the other

in the form of registered digital data in a database,

there were two parallel checking procedures in the

contracting process. One was done by terminal and

the non-life insurance management system, while the

other was done by veriﬁers. If the terminal was more

intelligent, contracts could be processed more simply

and quicker, thus allowing a reduction in the labor

cost of veriﬁers. In order to solve these problems,

the non-life insurance company decided to develop a

new system by introducing the tablet computers to the

agents. The new system will be able to verify the ap-

plication data and support the agents in making cor-

rect on site assessments with regard to their policy-

holder candidates. The stakeholders agreed to abolish

the paper medium of contracts and policy certiﬁcates.

The paper-less system was also a requirement of the

authorities of the Japanese government. Furthermore,

the company thought that the modern tablet comput-

ers might make the impression of the company better

for the policyholder candidates.

3.3 The System-to-be

Figure 4 shows the situation surrounding the NIC sys-

tem. After the installation of the NIC system, the

paper medium that was used as an application form

and a policy certiﬁcate was abolished. When the

stakeholders decided to abolish the paper medium,

the requirements analysis team gathered the opin-

ions of the authorities in charge of the new system,

MLINT(Ministry of Land, Infrastructure, Transport

and Tourism). The policyholders hence forth would

be able to review their policies of insurance at any

time via the internet. Such improvements contributed

to the following goals:

• Increasing sales and/or reduced labor costs.

• Improving customer satisfaction.

• Ensuring legal compliance.

The NIC system appeared to be completely adequate.

We can show the adequacy of the new system, that

is to say, how the system achieves the goals set forth

through the utilizing of a goal model. Because of the

limited space, we do not present the goal model in this

paper.

After the system was released, some agents re-

quired the company to output the policy certiﬁcate in

paper form. This was an unexpected change in re-

quirements. As shown in Figure 3 and Figure 4, the

SD models could not present the necessity of the re-

quirement. In order to solve this problem, we had to

extend the scope of the analysis.

Here, we apply the extended SD model to re-

analyze the problem domain. We will discuss the re-

sults in the next subsection.

3.4 Applying the Extended SD Model

Figure 5 represents the context of requirements real-

ized in the requirements elicitation phase within the

extended SD model. The dotted circle is the bound-

ary of the original SD model of the i* framework. The

original SD model is extended through the inclusion

of the social relations between an actor within the SD

model and the context of the actor. The Ministry of

Land, Infrastructure, Transport and Tourism (MLIT)

notiﬁed its branches to accept digital policies of in-

surances. According to the notiﬁcation, general con-

tractors can submit copies of insurance policies that

are submitted by subcontractors. The MLIT even ac-

cepts screen shots of the digital policies of insurance.

Following this, the MLIT starts management matter

examinations of the general contractor. This was the

reason that the non-life insurance company decided

to abolish the paper medium of policy certiﬁcates.

The colored resources in the ﬁgure are the parts cor-

responding to the change in requirements.

Subcontractor

(Policyholder or its

candidate

General

Contractor

<<digital>>

Policy of workmen's

compensation insurance

and liability insurance

Work

Non-life

insurance

management

system

<<digital>>

Policy of the

insurance

Certificate of

approval and

authorization

The scope of original

SD model of i*.

<<digital>>

Policy of workmen's

compensation insurance

and liability insurance

MLIT

accepts digital policy of

insurance and its copy or

screen shots

Municipality branch

Figure 5: The context of requirements realized within the

requirements elicitation phase.

Figure 6 represents the context of stakeholders by

taking the requirements changes into account. Ac-

tually, there were some branches that did not follow

the notiﬁcation of the MLIT. These branches did not

accept the screen shots of the digitalized insurance

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

360

Agent

Policyholder

or its

candidate

Non-life

Insurance

Company

Verifiers

Nonlife

Insurance

Management

System

The

person

insured

Legend

Intentional Actor

Resource Dependency

Softgoal dependency

Task dependency

A terminal

of the

agent

Premium

Insurance

Labor cost of

verifiers

<<paper>>

The policy

certificate

The application

data of the

contract

Electrical

application of

contract

Increasing the

number of

contracts

Explain the

insurance

directly

<<paper>>

Application

form

Compare the paper

application form with the

electrically registered

application data

The copy of the

application of the

contract

Detect errors in

the application

form

Registered

contract data

Statistical data of

insurance

contracts

Verify the content

of the application

of the contract

Corrected

application of the

contract

Figure 3: An SD model of the as-is context of a contract of non-life Insurance.

Nonlife Insurance

Contract system on a

tablet computer

Nonlife

insurance

management

system

Agent

Non-life

Insurance

Company

The

person

insured

Accept the

content of the

insurance

digitally

Insurance

Premium

<<digital>>

The policy of

the contract

Statistical data of

insurance

contracts

Corrected

application of

the contract

The application

data of the

contract

Verify the

content of the

application of

the contract

Increasing the

number of

contracts

Explain the

insurance

directly

The application

data of the

contract

Policyholder

or its

candidate

Figure 4: SD model of the expected to-be context of a contract of non-life insurance.

policies. Thus, the subcontractors who were the cus-

tomers of the agents made requests to the agents to

provide policy certiﬁcates in paper form. In order to

understand the context of the change in requirements,

we have to understand the environment with regard to

the social relations that affect the intentions of stake-

holders. The general contracts were in the context of

the requirements of subcontractors who were indirect

users of the NIC system, but the direct users of the

outcomes of the system. The origins of changes in

requirements are sometimes at a distance from stake-

holders. The new requirements are shown in Figure 6

in colored icons.

Some of the agent companies refused to intro-

duce the tablet computers, since the tablet comput-

ers would increase their costs with regard to facilities

and communication expenses. The context of these

refusals was out of the scope of the non-life insurance

company. Figure 7 shows the situation. The extended

SD model can visualize the context of the intention of

stakeholders. How does the NIC system contribute to

and increase the sales of the agent companies? Fig-

ure 4 did not mention the issue.

We analyzed the context of the actors shown in Fig-

ure 4 with an extended SD model. The missing point

was that of the variations of the parties surrounding

the actors. The agents were not only the users of the

system but also employees of the agent companies,

Non-life

insurance

management

system

General

Contractor

<<paper>>

Copied policy of

workmen's compensation

insurance and liability

insurance

Work

Certificate of

approval and

authorization

The scope of original

SD model of i*.

<<paper>>

Copied policy

certificate of

workmen's

compensation

insurance and liability

insurance

Subcontractor

(Policyholder or its

candidate

<<paper>>

Original policy

certificate of the

insurance

Municipality branch

accepts only copy of original

policy of insurance

MLIT

accepts digital policy of

insurance and its copy or

screen shots

Figure 6: The analysis of the source of changes in the con-

text of requirements.

Agent

company

Agent

NIC system on

tablet

computer

Operation

cost

The scope of original

SD model of i*.

Operation

cost

<<paper>>

Original policy

certificate

Figure 7: The context of the person in charge of the agency.

who were tasked with the pursuit of proﬁt as well as

the reduction of costs. Furthermore, there was a vari-

ation of the authorities of the Japanese government.

AMethodforAnalyzingtheContextofStakeholdersandtheirRequirements

361

If analysts can visualize such variations, they might

be able to get more precise information with regard to

these variations, and thus, deal with the requirements

changes.

4 DISCUSSION AND

CONCLUSION

In this paper, we presented an analysis method of the

context of stakeholders by extending the SD model

of the i* framework. By applying the method to

the software development project of the non-life in-

surance company, the model was able to visualize

the sources. Within this context, there were present

the sources of requirements changes that were out of

scope in the original SD model. In the case study,

we analyzed the context of stakeholders base on re-

quirements changes. Although we did not predict the

changes, we could get domain knowledge of the con-

text of the stakeholders. In order to predict changes in

requirements, analysts have to increase their knowl-

edge of the domain and the context of the stakehold-

ers. The study proved effective for those analysts. As

a result of the case study, the analysts could realize

the necessity of the analysis of the social environment

of the agents and the visualization of the context of

their requirements throughout the application of the

extended SD model. We did not compare the positive

and negative cost of the application of the method. Of

course, the analyst who applies the method to his/her

project is required more work than ever in the require-

ments analysis phase. However, we consider that the

loss cased by the unexpected requirements changes is

more expensive than the application of the method.

We will evaluate the reliability of the consideration in

our future work.

REFERENCES

Alexander, I. and Robertson, S. (2004). Understanding

project sociology by modelling stakeholders. IEEE

Software, 21(1):23–27.

Bano, M., Imtiaz, S., Ikram, N., Niazi, M., and Usman, M.

(2012). Causes of requirement change-a systematic

literature review. In Evaluation and Assessment in

Software Engineering , pages 22–31. The institute of

Engineering and Technology.

Damas, C., Lambeau, B., and van Lamsweerde, A. (2006).

Scenarios, goals, and state machines: a win-win part-

nership for model synthesis. In SIGSOFT ’06/FSE-14:

the 14th ACM SIGSOFT international symposium on

Foundations of software engineering, pages 197–207.

ACM.

Ebert, C. and D., M. J. (2005). Requirements uncertainty:

inﬂuencing factors and concrete improvements. In

The 27th International Conference on Software Engi-

neering, pages 553–560. IEEE.

Faily, S. and Flechais, I. (2009). Context-sensitive re-

quirements and risk management with iris. In The

21st IEEE International Requirements Engineering

Conference (RE’09), volume 0, pages 379–380, Los

Alamitos, CA, USA. IEEE Computer Society.

Fiske, A. P. (1992). The four elementary forms of social-

ity: Framework for a uniﬁed theory of social relations.

Psychological Review, 99(4):689–723.

Kotonya, G. and Sommerville, I. (1998). Requirements En-

gineering: Processes and Techniques. John Wiley &

Sons.

MacAulay, L. (1996). Requirements Engineering. Springer.

Nakatani, T. and Tsumaki, T. (2014). Predicting require-

ments changes by focusing on the social relations.

In The 10th Asia-Paciﬁc Conferencs on Conceptual

Modeling, pages 65–70. Australian Comupter Society.

Nurmuliani, N., Zowghi, D., and Fowell, S. (2004). Anal-

ysis of requirements volatility during software devel-

opment life cycle. In The 2004 Australian Software

Engineering Conference (ASWEC’04), pages 28–37.

Pohl, K. (2010). Requirements Engineering: Fundamen-

tals, Principles, and Techniques. Springer.

Robertson, S. and Robertson, J. (2005). Requirements-Led

Project Management. Addison-Wesley.

Sommerville, I. and Sawyer, P. (1997). Requirements

Engineering-A good practice guide. John Wikey &

Sons.

Sutcliffe, A., Feckas, S., and Sohlberg, M. M. (2005). Per-

sonal and contextual requirements engineering. In The

13th International Requirements Engineering Confer-

ence (RE’05), pages 19–30. IEEE.

van Lamsweerde, A. (2004). Goal-oriented requirements

engineering: A roundtrip from research to practice.

In The 12th International Requirements Engineering

Conference (RE’04), pages 4–7. IEEE.

Williams, B. J., Carver, J., and Vaughn, R. (2006). Change

risk assessment: Understanding risks involved in

changing software requirements. In The International

Conference on Software Engineering Research and

Practice (SERP 2006), pages 966–971.

Yu, E., Giorgini, P., Maiden, N., and Mylopoulos, J., editors

(2011). Social Modeling for Requirements Engineer-

ing. MIT Press.

Yu, E. S. K. and Mylopoulos, J. (1998). An actor depen-

dency model of organizational work –with applica-

tion to business process reengineering. In Conference

on Organizational Computing Systems (COOCS’98),

pages 258–268.

Zowghi, D. and Nurmuliani, N. (2002). A study of the im-

pact of requirements volatility on software project per-

formance. In Asia-Paciﬁc Software Engineering Con-

ference, pages 3–11. IEEE.

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

362