TOWARDS A STRATEGIC REQUIREMENTS ELICITATION

A Proposal of the PRINCE Model

Takako Nakatani

, Shouzo Hori

, Michio Tsuda

, Mari Inoki

Keiichi Katamine

and Masaaki Hashimoto

Graduate School of Systems Sciences, University of Tsukuba, 3-29-1, Otsuka, Bunkyo, Tokyo, Japan

Yaskawa Information Systems Corporation, 1-2-3, Manpukuji, Asou, Kawasaki, Kanagawa, Japan

Osaka University, 1-5, Yamadaoka, Suita, Osaka, Japan

Toshiba Solutions Corporation, 3-22, Katamachi, Fuchu-shi, Tokyo, Japan

Kyushu Institute of Technology, 680-4, Kawazu, Iizuka, Fukuoka, Japan

Keywords:

Requirements engineering, Requirements elicitation process, Case study.

Abstract:

Requirements changes are sometimes pointed out as being one of the causes for project failure. Our solution

to cope with this problem is to plan and manage requirements changes strategically. This paper introduces

the PRINCE model that consists of 3+1 types of requirements elicitation processes based on the time of the

maturation of the requirements elicitation activity. To explain the model, we show a real case with quantitative

observations of a requirements elicitation process. When we are able to elaborate a strategy of requirements

elicitation with the PRINCE model, we can elicit requirements by need of the physical development, rather

than the theoretical development process model.

1 INTRODUCTION

Requirements changes are sometimes pointed out as

being one of the causes for project failure. Various

solutions exist to cope with this problem. For ex-

ample, Trawling in Volere (Robertson and Robertson,

1999) is a method for requirements elicitation without

possible omissions. Goal-oriented analysis methods

explore the “why” aspect of requirements in order to

ﬁnd alternative requirements and forecast variability

of requirements (Anton, 1996; Dardenne et al., 1993).

Even though we apply those methods, it is hard to

elicit requirements completely in the early stage of

software development. Project managers must plan a

sound development process that ﬁts the fragility of the

requirements with regard to each project situation.

There are several development process models

that cope with requirements changes. An agile de-

velopment process (Beck and et al., 2001) recom-

mends incremental development in short durations.

If the development duration is short, the project may

be free from requirements changes caused by busi-

ness environmentalchanges. The Uniﬁed Process (Ja-

cobson et al., 1999) proposes a four-stage develop-

ment. It focuses on a framework that takes measures

to meet the future requirements changes. If the re-

quirements change frequently, and they are a haz-

ard for the project, we must consider a plan for the

requirements elicitation throughout the whole devel-

opment phase. Planning the requirements elicitation

seems to be a realistic way of thinking, as opposed to

setting the requirements process in the early develop-

ment stage.

A model called the PRINCE (Pre Requirements

Intelligence Net Consideration and Evaluation) model

was developedin order to emphasize the requirements

elicitation process and/or plan the requirements pro-

cess. The PRINCE model assumes that requirements

are elicited continuously during the whole develop-

ment process. Sommerville referred to such a con-

cept as Integrated Requirements Engineering (Som-

merville, 2005).

This paper is constructed as follows. In Section 2,

we discuss related works. Section 3 provides the

145

Nakatani T., Hori S., Tsuda M., Inoki M., Katamine K. and Hashimoto M. (2009).

TOWARDS A STRATEGIC REQUIREMENTS ELICITATION - A Proposal of the PRINCE Model.

In Proceedings of the 4th International Conference on Software and Data Technologies, pages 145-150

DOI: 10.5220/0002244001450150

 SciTePress

PRINCE model and its four process types of require-

ments elicitation. In Section 4, we introduce a case

as an example project of the PRINCE model and an-

alyze the project situation by mapping in accordance

with the PRINCE model. In the ﬁnal section, we con-

clude with the expectations and possible problems of

the PRINCE model.

2 RELATED WORK

The requirements process during software develop-

ment has been extensively researched in numerous

volumes.

Lehman proposed the laws of program evolu-

tion (Lehman, 1978; Lehman, 1996). The ﬁrst law

“continuing change” said that “software systems that

solve a problem or implement a computer applica-

tion in the real world must be continually adapted

for satisfaction.” He focused on the software mainte-

nance process. We focus on a software development

process. As the development progresses, the cus-

tomers understanding of the system deepens. Hence,

the customers cannot help changing their require-

ments (Nakatani et al., 2008). The ﬁrst law is appli-

cable during the development process.

Nakamura analyzed project managers’ efforts in

dealing with speciﬁcation changes (Nakamura, 2005).

There are differences between new market projects

and established market projects. The number of spec-

iﬁcation changes per MPI (Management Performance

Index) is 0.116 and 0.01 for the new market projects

and the established market projects respectively.

Finker and his colleagues clariﬁed the handshak-

ing process between a requirementsprovider and a so-

lution provider (Fricker et al., 2007). Their research

has been done for distributed product development

and they havedevelopeda technique to enable explicit

handshaking procedures amongst stakeholders in or-

der to deal with the risk of misunderstanding require-

ments. The handshaking process is composed of three

activities: i.e. requirements communication, syn-

thesis of the problem domain information/technology

knowledge, and negotiation. They discussed imple-

mentation proposals that describe how a given re-

quirement is intended to be realized by a software

solution in order to validate the understanding of a

requirement.

Aoyama and his colleagues studied the kinds of

requirements that were changed or added after the re-

quirements analysis phase. Then, they introduced an

interview guide to clarify unstable requirements and

evaluated the guide to elicit those requirements com-

pletely before the design phase had started (Aoyama

et al., 2007). We do not think that it is possible to elicit

requirements completely in the requirements phase,

because our clients sometimes do not know their re-

quirements. Our studied case is that the engineers as-

certain requirements together with their clients during

the system development. To do this, we must manage

the requirements process according to the type of each

component and the project situation.

Arkley and his colleagues described an applica-

tion of traceability by a company. They classiﬁed

the project requirements and showed requirements

changes in the development process. In their article,

the speciﬁcations and requirements were frozen be-

fore the software design review (Arkley and Riddle,

2006). Sankar and Venkat focused on a way to control

requirements. They showed the percentage of require-

ments frozen in the development process. According

to the article, 70% of all requirements were frozen

during requirements gathering (Kousik and Raman,

2007). If most requirements could be frozen in the

early development phase, we would be happy. One

of the real problems is that many requirements some-

times remain undeﬁned until the design phase.

Houdek and Pohl studied the requirements en-

gineering process of Daimler Chrysler. They men-

tioned that 50% to 60% of requirements changes are

in the interface area (Houdek and Pohl, 2000). They

also mentioned that requirements engineering activ-

ities are heavily intertwined. Sommerville referred

to the intertwined requirements engineering process

as integrated requirements engineering (Sommerville,

2005). Our approach is to propose a process which

plans and manages requirements elicitations through-

out the project.

3 THE PRINCE MODEL

Figure 1 shows the PRINCE model. The model repre-

sents a requirements elicitation process with the ratio

of requirements maturation versus the project sched-

ule.

3.1 Ratio of Requirements Maturation

The ratio of requirements maturation represents how

much the requirements are elicited for each software

component, for example, physical software compo-

nent, subsystem, a group of these components, quality

characteristic, etc.

The ratio is deﬁned as follows. Let r

be the num-

ber of elicited requirements on project day i. Thus,

the sum of a set of elicited requirements in n days can

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

146

be written

∑

i=0

. The ratio of requirements matura-

tion R

is deﬁned by the accumulated requirements on

the j th day as

∑

i=0

Here, N is the sum of the number of requirements

elicited throughout the project. Hence, R

is equal to

0% and R

end

is equal to 100%.

3.2 Maturation Types

We can observe the matured period for each software

component. The three vertical lines in Figure 1 rep-

resent the end of the early, middle, and later devel-

opments stages respectively. The early development

stage designates an integrated stage of requirements

analysis and external design phase for water-fall pro-

cess model, or an inception phase of the Uniﬁed Pro-

cess. The middle stage designates an internal design

phase, or elaboration phase. The later stage is corre-

sponding to the phases following to the middle stage.

E_type

time

100

The early stage The later stageThe middle stage

U_type

L_type

M_type

Test

stage

Ratio of requirements maturation

Figure 1: The PRINCE model.

As shown in Figure 1, the PRINCE model con-

sists of 3+1 maturation types of requirements elicita-

tion process of software components. In the PRINCE

model, the word “component” designates a physi-

cal software component, a group of them, or a sub-

system. The types are the early stage maturation,

the middle stage maturation, the later stage matura-

tion, and the unforeseen maturation type. We named

E type, M type, L type, and U type for each type re-

spectively. The PRINCE model supports project man-

agers in planning the requirements elicitation process

strategically to ﬁt the project situation. The concept

of the model is, “elicit requirements by need for the

development.” The PRINCE model provides a plan of

requirements elicitation to obtain 100% requirements

by the end of the development. The characteristic of

each type is as follows:

• E type: The early stage maturation type

When a requirements elicitation process follows

the E type, 100% of the requirements can be

elicited by the end of the external design phase in

the waterfall process model (WF) or the inception

phase in the Uniﬁed Process (UP) and are never

changed after this phase. These requirements will

be designed and implemented after requirements

have been elicited completely.

• M type: The middle stage maturation type

A requirements elicitation process follows the

M type, when the project cannot freeze the re-

quirements until the implementation phase of the

WF or the elaboration phase of the UP has started.

• L type: The later stage maturation type

If a requirements elicitation process follows the

L type, we have to elicit requirements even in the

implementation phase. This means that incremen-

tal development is one of the recommended devel-

opment processes for the type L.

• U type: The unforeseen maturation type

This type of process cannot be planned. The un-

foreseen requirements are elicited unexpectedly

during any of the phases. When we plan the

requirements elicitation process, we must pre-

pare for unforeseen requirements. We show two

U type processes in Figure 1 as examples.

3.3 Manage the Backlogs

To manage the requirements elicitation process, we

need to watch two kinds of backlogs. One is for the

requirementsthat haveto be satisﬁed within the devel-

oping product, but are unforeseen in the early stage

of the development. This type of requirements be-

longs to the U type. The other is for the requirements

that are deﬁned to satisfy in the future product. This

type of requirements elicitation process forms like an

L type. From a business perspective, eliciting such

requirements is a beneﬁt for the next project.

4 CASE OBSERVATION

We selected a ﬁve-month project in order to ob-

serve and analyze the requirements changes process

by mapping in accordance with the PRINCE model.

4.1 The Case Overview

The target project was initiated to develop a restau-

rant service and order management system, named

RESORT. RESORT accepts orders from the hand held

terminals of staff members as well as from the table

terminals.

TOWARDS A STRATEGIC REQUIREMENTS ELICITATION - A Proposal of the PRINCE Model

147

Cumulative elapsed days (days)

External Design

(The early stage)

Internal Design

(The middle stage)

Implementation

(The later stage)

0.00

20.00

40.00

60.00

80.00

100.00

0 20 40 60 80 100 120 140 160

TT_C Sys_M Inst.Support

TT_M Cent_C OES_M

DB OES_C Others

(%)

Test

Ratio of requirements maturation

Figure 2: Requirements maturation ratio observed from a physical component view.

(%)

Cumulative elapsed days (days)

0.00

20.00

40.00

60.00

80.00

100.00

0 20 40 60 80 100 120 140 160

Functionality Reliability Usability

Efficiency Maintainability Portability

External Design

(The early stage)

Internal Design

(The middle stage)

Implementation

(The later stage)

Test

Ratio of requirements maturation

Figure 3: The requirements maturation rate of quality characteristics.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

148

The RESORT project was completed in four and a

half months, which fell within the planned schedule.

The duration of the recorded data was 117 days. As

shown in Table 1, records were kept for each develop-

ment phase, i.e. an external design phase, an internal

design phase, an implementation phase, and a testing

and debugging phase. Every phase was overlapped

with the other phases. The cumulative development

duration was 165 days. Figure 2 shows the require-

ments maturation rate versus the cumulative develop-

ment duration from a physical component view. Fig-

ure 3 represents the requirements maturation rate of

quality characteristics.

Table 1: Duration of each phase.

Exter. Inter. Imple. Testing Total

Design Design

55 40 45 25 165

4.2 Map to the PRINCE Model

We have mapped the requirements elicitation process

as observed in the case in accordance with the types in

the PRINCE model. We also interviewed the project

manager to ascertain how he managed the require-

ments elicitation process.

• E type:

There are four Components, Inst.Support, DB,

TT M, and Cent C, whose elicitation process fol-

lows the E type. They matured in the early stage

of the development shown in Figure 2.

Inst.Support was required to improve the previ-

ous system. The client clearly recognized the

problems of the previous system. Consequently,

the project was able to completely acquire the re-

quirements in the early stage of the project. The

DB was a reused component. The client also

clearly deﬁned some minor changes for the exist-

ing component. Requirements for the other com-

ponents were provided by the cooperating com-

panies in the form of speciﬁcations of the external

interfaces. These cooperating companies shared a

common goal of completing the project within the

schedule.

According to the case, E type can be applicable at

least in the following situation.

– The developer can contact a stakeholder who

recognizes the problems of the former system.

– There is a reusable component and its speciﬁ-

cation. Furthermore, the developer can access a

stakeholder who understands the speciﬁc prob-

lems to be solved.

– The developing system needs an external inter-

face provided by the cooperative organizations

and they share the goals of the project with the

developers.

• M type:

Regardless of the situation, we have to plan the

process for quality requirements as the M type or

the E type, since they easily affect the software

architecture. The process of eliciting efﬁciency

requirements followed the M type, as shown in

Figure 3. The process of reliability, maintainabil-

ity, and portability requirements did not follow

M type, because these requirements were related

to the unexpected requirements elicitation in the

later stage. We discuss the problem in the U type

explanation.

• L type:

OES C, Sys M, and TT C followed the L type.

They matured in the later stage of the develop-

ment, as shown in Figure 2. These components

were developed incrementally. OES C relates to

the external interface of products provided by sev-

eral third party companies.

The project could not get the correct speciﬁcations

in the early and the middle stages, because the

third party companies did not cooperate with the

project. Furthermore, the developers did not have

enough knowledge of the problem domain. How-

ever, during the incremental development, they

acquired the knowledge.

The other components, Sys M and TT C, are re-

lated to the user interface, and played a key role

in competing with other similar products on the

market. According to this case, we have to con-

sider the possibility of applying the L type in the

following situation.

– The developers do not have enough knowledge

of a portion of the system and need time to ac-

quire the knowledge.

– No usability specialist joins the project, and the

project expects their customers to evaluate the

UIs.

– The components mentioned above are the com-

petitive parts of the system, and the market sit-

uation is changing continuously.

• U type:

This type also appears in Figure 3. Requirements

for OES M were changed because of the incon-

sistency between the speciﬁcations and the actual

product. It caused reconsideration of the qual-

ity requirements: reliability, maintainability, and

portability.

TOWARDS A STRATEGIC REQUIREMENTS ELICITATION - A Proposal of the PRINCE Model

149

5 CONCLUSIONS

One of the purposes of this paper is to present the

PRINCE model as a method to plan the requirements

elicitation process strategically. Before planning the

requirements elicitation process, managers identify

some sort of component as, “a preparation of require-

ments elicited” after the requirements analysis phase

or the inception phase. The requirements elicitation

process can be planned for each component according

to the types in the PRINCE model. A use case, func-

tion, feature, quality characteristic or physical com-

ponent are the candidate of the unit to be observed.

Throughout the project, the manager observes and

evaluates the process of the real requirements elicita-

tion process with two kinds of backlog for compar-

isons with the planned process. If we can elaborate a

strategy of requirements elicitation with the PRINCE

model, we will be able to apply different kinds of de-

velopment processes within a single project.

The other purpose of this paper is to clarify a pro-

cess of requirements elicitation quantitatively as the

PRINCE model. The PRINCE model provides three

types of requirements elicitation process, and one un-

foreseen type. Even for the unforeseen type, if we

worry about the encounter with the U type process,

we have to prepare for accidental situations. There-

fore, it is important to plan the requirements elicita-

tion process.

The concept “eliciting requirements by need for

the development” requires the manager to plan the fu-

ture requirements elicitation according to the project

situation. Still now, we cannot point out all possible

situations for each type. We need to observe other re-

quirements elicitation processes in real projects. Ob-

servation of projects provides us with a lot of knowl-

edge to succeed in our project.

We are developing a guideline to solve prob-

lems through the observation of requirements quan-

titatively. For example, in this case, several require-

ments for the future product are included in current

requirements. We need a way to distinguish these

backlogs and the truly essential requirements for any

speciﬁc project.

ACKNOWLEDGEMENTS

This project has been supported by Joint Forum for

Strategic Software Research since 2007. We give

thanks to all the members of this project and coop-

erators. The support of the engineers was essential

for the research. They provide a lot of development

data, and give their time to answer our questions. We

thank all these engineers.

REFERENCES

Anton, A. I. (1996). Goal-based requirements analysis. In

Proc. of the Second International Conference on Re-

quirements Engineering (ICRE’96), pages 136–144.

IEEE.

Aoyama, K., Ugai, T., Yamada, S., and Obata, A. (2007).

Extraction of viewpoints for eliciting customer’s re-

quirements based on analysis of speciﬁcation change

records. APSEC, pages 33–40.

Arkley, P. and Riddle, S. (2006). Tailoring traceability in-

formation to business needs. In Proc. of the 14th

International Requirements Engineering Conference

(RE’06), pages 239–244. IEEE.

Beck, K. and et al. (2001). Manifesto for agile software

development, (url http://agilemanifesto.org/).

Dardenne, A., van Lamsweerde, A., and Fickas, S. (1993).

Goal-directed requirements acquisition. Science of

Computer Programming, 20:3–50.

Fricker, S., Gorschek, T., and Myllyperki¨o, P. (2007). Hand-

shaking between software projects and stakeholders

using implementation proposals. Requirements Engi-

neering: Foundation for Software Quality, 4542:144–

159.

Houdek, F. and Pohl, K. (2000). Analyzing requirements

engineering processes: A case study. In Proc. of

the 11th International Workshop on Database and

Expert Systems Applications (DEXA’00), pages 983–

987. IEEE.

Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Uni-

ﬁed Software Development Process. Addison-Wesley.

Kousik, S. R. and Raman, V. (2007). Total requirements

control at every stage of product development. In

Proc. of the 15th International Requirements Engi-

neering Conference, pages 337–342. IEEE.

Lehman, M. M. (1978). Laws of program evolution -rules

and tools for programming management-. In Proc.

of the Infotech State of the Art Conf., Why Software

Projects Fail?, pages 11/1–11/25. Program Press.

Lehman, M. M. (1996). Feedback in the software evolu-

tion process. Information and Software Technology,

38(11):681–686.

Nakamura, T. (2005). Analysis of project management re-

ports of 49 system integration projects. In Proc. of the

13th International Requirements Engineering Confer-

ence (RE’05), pages 485–486. IEEE.

Nakatani, T., Hori, S., Ubayashi, N., Katamine, K., and

Hashimoto, M. (2008). A case study: Requirements

elicitation processes throughout a project. In Proc.

of the 16th International Requirements Engineering

Conference (RE’08), pages 241–246. IEEE.

Robertson, S. and Robertson, J. (1999). Mastering the Re-

quirements Process. Addison-Wesley.

Sommerville, I. (2005). Integrated requirements engineer-

ing: A tutorial. In IEEE Software, pages 16–23. IEEE.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

150