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
Requirements engineering, Requirements elicitation process, Case study.
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.
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
find 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 fits 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 Unified 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
Nakatani T., Hori S., Tsuda M., Inoki M., Katamine K. and Hashimoto M. (2009).
In Proceedings of the 4th International Conference on Software and Data Technologies, pages 145-150
DOI: 10.5220/0002244001450150
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 final section, we con-
clude with the expectations and possible problems of
the PRINCE model.
The requirements process during software develop-
ment has been extensively researched in numerous
Lehman proposed the laws of program evolu-
tion (Lehman, 1978; Lehman, 1996). The first 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 first law is appli-
cable during the development process.
Nakamura analyzed project managers’ efforts in
dealing with specification changes (Nakamura, 2005).
There are differences between new market projects
and established market projects. The number of spec-
ification 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 clarified 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
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 classified
the project requirements and showed requirements
changes in the development process. In their article,
the specifications 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 undefined 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.
Figure 1 shows the PRINCE model. The model repre-
sents a requirements elicitation process with the ratio
of requirements maturation versus the project sched-
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 defined 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
be written
. The ratio of requirements matura-
tion R
is defined by the accumulated requirements on
the j th day as
Here, N is the sum of the number of requirements
elicited throughout the project. Hence, R
is equal to
0% and R
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 Unified 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.
The early stage The later stageThe middle 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 fit 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 Unified 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 satisfied 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 defined 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 benefit for the next project.
We selected a five-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
Cumulative elapsed days (days)
External Design
(The early stage)
Internal Design
(The middle stage)
(The later stage)
0 20 40 60 80 100 120 140 160
TT_C Sys_M Inst.Support
DB OES_C Others
Ratio of requirements maturation
Figure 2: Requirements maturation ratio observed from a physical component view.
Cumulative elapsed days (days)
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)
(The later stage)
Ratio of requirements maturation
Figure 3: The requirements maturation rate of quality characteristics.
ICSOFT 2009 - 4th International Conference on Software and Data Technologies
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 defined 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 specifications of the external
interfaces. These cooperating companies shared a
common goal of completing the project within the
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 specifi-
cation. Furthermore, the developer can access a
stakeholder who understands the specific 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
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 efficiency
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
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 specifications
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
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 specifications and the actual
product. It caused reconsideration of the qual-
ity requirements: reliability, maintainability, and
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
specific project.
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.
Anton, A. I. (1996). Goal-based requirements analysis. In
Proc. of the Second International Conference on Re-
quirements Engineering (ICRE’96), pages 136–144.
Aoyama, K., Ugai, T., Yamada, S., and Obata, A. (2007).
Extraction of viewpoints for eliciting customer’s re-
quirements based on analysis of specification 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
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–
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-
fied 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,
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