19th Australian Conference on Software Engineering
Choosing the “Right” Prioritisation Method
Sarah Hatton
School of Computer Science and Software Engineering
The University of Western Australia
M002, 35 Stirling Highway
Crawley, Western Australia 6009
sarah@csse.uwa.edu.au
development methodology may promote prioritising
more than once, using the same technique. Once again
this can mean that only limited benefits are realised as
the technique may not be optimal in providing the
information required.
As the software development process progresses,
requirements can be added or removed and existing
requirements become better defined. This means that
the system as a whole is better defined and understood.
These changes could mean that prioritisations done
earlier are obsolete.
Some development methodologies come with a
recommended prioritisation method. For organisations
wishing to get the most out of prioritisation the
suggested technique may not be ideal for use
throughout the development.
When selecting a prioritisation method a number of
factors need to be looked at. One of the most important
of these is the stage of development a project is at. The
project stage often determines the amount of
information known to both the stakeholder and the
developer.
The stage in the project can also affect how much
detail about preference is required. In earlier stages it
is possible that only broader information may be
needed. The amount of time required to perform
prioritisation should also be considered. When
schedule is a major issue, the methods which are faster
to perform [7] may be most suitable and the level of
detail may be sacrificed.
Section 2 of this paper describes some development
methodologies and prioritisation methods are discussed
in Section 3. Sections 4 - 6 describe an analysis of
some small projects used to identify how different
prioritisation methods lend themselves to be applied at
certain stages of development.
Abstract
There are many methods available for prioritising
software requirements. Choosing the most suitable one
can often be quite difficult. A number of factors need to
be considered such as the project development
methodology being used, the amount of time available,
the amount of information known about requirements,
the stage of the project and the degree of information
about priority required. This paper examines the type
of information available at different stages in a project
and matches it to the properties of prioritisation
methods. It then recommends the usage of specific
prioritisation methods at certain stages of a project.
1. Introduction
Requirements prioritisation is a vital step in the
software development process. It needs to be done to
reduce the risk of costly software failures [1]. It has
been recognised as one of the most important decision
making activities performed in requirements
engineering [2].
Prioritisation has many benefits, such as reducing
the risk that valuable project resources will be
misdirected and helping to ensure that clients and
developers both understand what the main outcomes of
a project will be [3,4].
Even with its benefits, it has been noted that
requirements prioritisation is often not well done [5].
One of the possible reasons for this is that, the team is
not using the most suitable method for the particular
stage in the project and thus performing prioritisation
inefficiently.
With some software development methodologies
prioritisation is only performed once in the life cycle
[6]. This means that the full potential benefits to the
project may not be realised. Alternatively the
1530-0803/08 $25.00 © 2008 IEEE
DOI 10.1109/ASWEC.2008.22
517
evaluation of these methods in terms of their suitability
for certain stages in a projects lifecycle.
It is logical that as a project evolves, different
degrees of information will be required as an output
from the prioritisation process, and differing amounts
of information are available as an input to the process.
This section briefly describes some prioritisation
methods which have characteristics that may lend
themselves to use at various stages of the development
process.
2. Development Methodologies
There are various software development
methodologies currently being used in industry [8].
These range from the highly structured older style
methods, such as the Waterfall [9] model to the newer
light weight, Incremental, Evolutionary and Iterative
methodologies [8]. These types of methods include
eXtreme programming (XP) [10], Dynamic System
Development Method (DSDM) [11], Feature Driven
Development (FDD) [12], Test Driven Development
(TDD) [13], SCRUM [14] and Adaptive methods [15].
The similarity with most iterative methods is that
they provide “power to the customer” in that the
customers’ priority, where technically possible, is what
drives the order of the development. In most software
projects customers have high expectations for the
software, yet developer’s resources are limited and
they have to deliver within a constrained time frame; as
such the most essential components of software should
be delivered as early as possible [6]
Many of these development methodologies bring
with them an associated prioritisation method. For
example XP has the planning game [10] and DSDM
promotes the MoSCoW method [11]. Other methods
do not prescribe an actual prioritisation method but
indicate that it should be done. For example FDD
states that the development sequence needs to be
determined [12] and in SCRUM [13] the Product
backlog needs to be prioritised. Similarly TDD does
not describe a method for prioritising the tests [14].
Even the older style methods such as Waterfall [9],
specify a phase for requirements analysis which
includes prioritisation but again no prioritisation
method is specified.
What is often not clear is what prioritisation method
should be used and in what circumstances will one
method be more suitable than another? Can other
methods be substituted for the methods suggested in
some of these methodologies and should the same
prioritisation method be used for all iterations of a
project?
3.1. Simple Ranking
Ranking elements into a single list has long been
useful for prioritisation. For n requirements the list is
simply ranked 1…n, where the most important
requirement is ranked one and the least n. The use of
this ordinal scale gives the order of preference but no
information on the magnitude of the preference.
This method would really only be suitable when
there are a fairly small number of requirements as
psychological research suggest seven (plus or minus
two) elements is around the maximum that can be
processed at once [20].
3.2. MoSCoW
MoSCoW is an acronym commonly used to
represent four hierarchical priority groups [11, 21].
Each requirement within a group shares the same
priority. These groups are:
“MUST have”: Requirements are not negotiable;
the failure to deliver these requirements would result in
the failure of the entire project.
“SHOULD have”: Features that would be nice to
have if at all possible
“COULD have” Features that would be nice to
have if at all possible but slightly less advantageous
than the “S”
“WON'T have” (also known as “wish list”). These
requirements are not unimportant, but they will
definitely not be implemented in the current software
project. They may, at a later stage, be created.
MoSCoW is currently incorporated into the
Dynamic Systems Development Method (DSDM) [11].
3. Prioritisation Methods
3.3. AHP
The Analytic Hierarchy Process is a well known
method for aiding in the decision making process [22,
23]. It is a powerful tool for comparing alternative
design concepts and also the relative value of
components in a system. It is recognised that the full
power of AHP is demonstrated when multi-objective
decisions need to be made [24]. However, AHP is also
commonly used when only one decision factor is being
examined.
There is a large array of prioritisation methods to
choose from. Possibly the hardest decision with
regards to prioritisation is picking the method that best
suites the stage of the project and the amount of
information required.
There has been some work done comparing the
various prioritisation methods on criteria such as
difficulty, confidence, time taken, accuracy and
scalability [7, 16-19]. There seems to be a lack of
518
AHP uses pair-wise comparisons to examine a list
of objectives or alternatives [23]. It requires
components to be ranked [24], using an ordinal scale,
to show their relative importance to one another. The
scale of relative importance uses the numbers one to
nine to signify the importance of one requirement over
the other [25].
Each requirement is compared to each other one (a
pair-wise comparison). AHP is non repetitive meaning
that the user will only have to compare two
requirements once i.e. if they have compared α to β
there is no need to compare β to α as the reciprocal can
be assumed.
Once a value has been assigned for each pair-wise
comparison, and the matrix of the relative importance
of the goals has been completed, the relative value for
each option is calculated [26]. The AHP also allows a
consistency index to be calculated which indicates the
accuracy of the results of the pair-wise comparisons.
The AHP effectively transforms the information of
the original ordinal scale into a ratio scale through a
series of mathematical operations. AHP has been
described as being tedious and only realistic for small
sets of elements [27].
preference (Hundred Dollars and AHP) and others give
a hierarchical order of preference for groups of
requirements (MoSCoW).
Within the lifecycle of a project, the amount of
knowledge that both the client and the developer have
changes as the project progresses. Requirements
become more fleshed out and work on the system may
reveal other important issues. This would be true no
matter what development methodology is being used
as experience increases the knowledge about a subject.
This evolution in knowledge about a system can result
in generalised requirements being split into several
more specific requirements. The depth of
understanding, from both the developer and client, as
to what a requirement means will also change. The
effect of this is that prioritisations done at a later stage
could yield different results to those done earlier.
As requirements change and understanding and
knowledge about a system increases, it is likely that
utilising different prioritisation methods would result
in a more comprehensive reflection of a client’s
wishes. The following sections discuss an examination
of the evolution of requirements throughout a project
and describe how prioritisation methods could apply to
different project stages.
3.4. Hundred Dollar Method
5. Evaluation through application
The Hundred Dollar Method uses the concept of
giving the user $100 to spend on requirements. It is a
simple and quick method for getting a magnitude
ranking which is suitable for use on an individual, or a
group of stakeholders [25]. There are basically three
steps that make up the Hundred Dollar method.
It is difficult to examine, through practical
application, the advantages of one prioritisation
technique over another at different stages of a project.
This study examines projects performed by final year
Software Engineering and Computer Science students
for external clients. These projects are used to identify
the types of requirements changes that occur, as well as
when they occur. The types of requirements and
properties of the prioritisation methods described
above are then theoretically compared, with the aim of
identifying the prioritisation methods most suited to
certain stages of a software project.
Final year Computer Science and Software
Engineering students undertake a software project just
before they complete their degrees. The aim of this
project is to give students some real experience in
creating software to meet a clients’ needs. This study
uses some project data from students enrolled in the
relevant units at the University of Western Australia
and Murdoch University in Western Australia between
2005 and 2007. It has been shown by other researchers
[28, 29] that data gathered from students’ professional
experience projects is generally applicable to the
software industry.
Students work in a team of between five and eight
members. There is a 13 week time frame from being
1. The user is asked to assume that they have $100 to
spend
2. They are asked to allocate the $100 across the
options that they have to evaluate.
3. The distribution of money is re-evaluated. There
are usually a few options which stand out as being
higher priority. If the money is spread too evenly
then another hundred dollars is given but it must be
spent as one lot of $50 and two lots of $25.
Having money distributed over the requirements
means it effectively uses a ratio scale giving detailed
information about the magnitude of preferences.
4. Matching methods with knowledge
Each of the prioritisation methods described above,
output differing types of information. Some give an
order of preference for each individual requirement
(Simple Ranking) others give a magnitude of
519
assigned to a project to having to deliver the final
product. During this time they are required to elicit,
prioritise and deliver requirements for a client which is
either from industry or part of the university.
Students at UWA and Murdoch are free to choose
the methodology that they follow. UWA students are
required to deliver a basic Requirements Analysis
Document (RAD), a prototype and refined RAD, time
plan and a final product. At Murdoch students are also
required to deliver a RAD, project management plan,
design document and final product in the same
timeframe as UWA students.
Both sets of students fill in a timesheet each week
which details the time they spend on tasks associated
with the project. It also lists all their projects
requirements, the week they were added, removed,
altered, scrubbed or completed. The client value (using
the hundred dollar method) is also noted as is the
students estimated effort in person hours.
Information for this study was gathered by using the
groups’ timesheets and frequently meeting with
groups.
than 70% of the total requirements were identified by
week three, which is when prototyping starts. It is in
week 5 that over 90% of requirements are known and
at the end of the prototyping phase that around 98% of
requirements are identified.
Figure 1 also identifies the approximate stages of
the project with Requirements and Analysis (R&A)
taking place between weeks one and seven, Prototype
being worked on at UWA between week’s four to
seven and coding, testing and documentation taking up
the remainder of the time. These time frames are only
rough guides as some groups may start or finish stages
earlier than others.
6. Results
Using the timesheet described in the above section
as well as the monitoring of groups, the changes in the
number and type of requirements were examined.
These figures are based upon the 20 groups which have
completed the project unit, agreed to participate and
have a complete data set for the 13 weeks.
Through the examination of the requirements
changes and discussion with team members, the factors
that increased the number of requirements were
classified into three categories;
• Client Added meaning the client gave the
group a new requirement to add to the list.
• Previously Missed meaning from the
information and use cases the groups already
had, they discovered a requirement which
was not included in their list of requirements.
• Refined meaning that a single requirement
that the group had was split into multiple
requirements.
Figure 1 shows for each week, the percentage
increase in the requirements and the percentage of the
total requirements discovered. It highlights a one
hundred percent increase in requirements between
weeks one and two. It is in week two that all the
groups started recording information on requirements.
The increases in the number of requirements drop off
rapidly and then no increases are shown after week 10.
When examining the percentage of the total number
of requirements discovered it is interesting that less
Figure 1. Percentage increase in requirements and
total percentage of requirements discovered
The student projects had a fairly concise
requirements set. There was an average of 11
requirements, maximum of 25 requirements and
minimum of 6 requirements appearing in the 20
projects studied as shown in Table 1.
Table 1. Average Number of Requirements
Requirements
520
Min
6
Max
25
Ave
11
Std Dev
4.85
Additional requirements can come from a variety of
sources.
Figure 2 shows the total number of
requirements added each week and the number of these
which were previously missed. It shows that only in
week’s three to five did requirements come from this
source. Previously missed requirements make a
relatively low contribution to the total number of
requirements added in these weeks
Figure 3. Client Added and total number of
requirements added each week.
Figure 4 shows the total number of requirements
added each week and the number of these which were
added through Refinement. It shows that between
weeks three and seven requirements were refined. In
weeks five to seven Refinement accounts for the largest
number of additional requirements.
Figure 2. Previously Missed and total number
of requirements added each week.
Figure 3 shows the total number of requirements
added each week and the number of these which were
Client Added. It shows that only between weeks two
and four the client is the greatest source of new
requirements. Client Added requirements occur right
up until week 10 which is quite late in the project
lifecycle.
Figure 4. Refined and total number of
requirements added each week.
521
all the requirements to be examined together and as
such the prioritisations would need to be redone each
time a requirement is added or split.
Results also show that in the mid to late stages of
the R&A phase the majority of changes to
requirements came from the development team
themselves refining the requirements that they had.
This shows that as the amount of information they
have about requirements changes, the requirements
themselves increase in specificity. At the same time the
clients would probably have a more complete
understanding of the software which they want and
what specific components are most valuable to them.
This could mean that they would have clearer
information about the priorities of individual
requirements.
In the later stages of the project there were
relatively few additions, all of which came from the
client. Possible reasons for this include, the client
being presented with a prototype or starting to see the
project evolve, thus triggering them to think of
additional requirements.
7. Discussion
Looking at the time and reason for increases in the
number of requirements gives insights into what is
going on in the software process and thus what could
be the most effective means of performing
prioritisation at different times within the project.
Deciding when to perform prioritisation can be
quite difficult. The two options are to perform
prioritisation early in the project, or wait until
requirements are well fleshed out and understood.
There are risks associated with each of these.
Prioritisation is often performed once what is
believed to be, a concise list of requirements
developed. If the team chooses to wait until later in a
project they run the risk of misdirecting project
resources into the refinement of low value
requirements that will not be implemented. On the
other hand if a team performs an in-depth prioritisation
too early they once again may be misdirecting their
time and resources into doing the prioritisation as the
requirements are likely to quickly change thus
outdating the prioritisation. As with most things, there
needs to be a balance that maximises benefit while
minimising risk and cost.
The results from this study indicate that in the early
stages of a project, the greatest proportion of
requirements increases comes from the client deciding
to add new requirements. It is likely that this is because
they are only just thinking about what a system could
possibly do for them.
Iterative methodologies assume that the client does
not have a clear idea of exactly what they want when a
project begins, instead through seeing what is produced
and through discussions with developers they get more
of a view of what the project could really deliver for
them.
It is however likely that the client could have a clear
set of goals for a project and that these would remain
relatively stable [30]. These high level goals would not
require prioritisation with in-depth methods such as the
AHP or Hundred Dollar Method as the amount of
information known about them would be limited.
Using a technique such as the MoSCoW method to
prioritise would give the development team an
excellent starting point to determine value. MoSCoW
has been shown to take little time to do, and is easy to
understand [7] thus showing that it would be a quick
source of information about priorities. It also has the
characteristic, that since it assigns an independent
classification to each requirement, it would easily deal
with the addition of new requirements without voiding
the previous prioritisation. Methods such as AHP, the
hundred dollar method and even simple ranking need
8. Efficient Prioritisation
Through the examination of the projects described
in the previous sections, a number of factors that need
to be considered before prioritisation occurs have been
identified. These include:
•
•
•
•
•
•
•
The stability of the requirements being
examined.
The amount of information needed from the
prioritisation.
The amount of time available to do it.
The current stage of the project.
The number of requirements that need
prioritising.
The amount of information known about the
requirements by both clients and developers.
The likelihood that additional requirements
will be added.
Through the examination of these sample projects it
seems that there are certain methods which do lend
themselves to be used at various times in a project.
Early Stages of R&A: when requirements are not
specified in a great degree of detail (may be goals), the
client has a general idea for the system and what they
need out of it.
The MoSCoW method would be highly suitable. It
groups requirements into Must have, Should have,
Could have and Wont have. New requirements
522
generated by the client are easy to assign to a category
and the addition of new requirements does not affect
the rest of the prioritisation and it will not need to be
redone.
MoSCoW is easy to understand and quick to
perform, it would not take time away from other tasks.
As these requirements are often not decomposed but
are more system goals than specific requirements there
may not be a large number of them. MoSCoW is
suitable for both small and large numbers of
requirements.
MoSCoW can also lead into more detailed
prioritisation methods. Development teams could seek
further information on certain categories at a later
stage. For example, Must, Should and Could
requirements could be further investigated, while there
is no need to look at the Won’t have requirements.
This early prioritisation can ensure that project
resources are put to the best use and are not directed
into areas that won’t be developed.
Latter Stages of R&A: When requirements
analysis is basically completed and the design
specifications are being worked on. The development
team and the client would have a high degree of
knowledge about the project. It is possible that clients
could add in requirements due to what they have seen
so far.
In projects of a fairly low complexity, the
prioritisation from the previous stage should provide
sufficient information and it may not need to be
repeated. In projects which are larger and more
complex, it is possible that conflicting requirements
have been discovered during the design process which
may mean that the prioritisation from the earlier stages
is not sufficient. The Analytical Hierarchy Process,
while being complex and time consuming, is also very
effective when decisions need to be weighed up against
multiple criteria. It could prove to be highly useful if
there are conflicting requirements.
While studies have found AHP to be difficult and
labour intensive, this is possibly outweighed by its
power in situations where there are competing criteria.
At this stage of the project you would expect that client
and developers would be very familiar with the
requirements for the system being worked on. It is
therefore likely that, with guidance, they would be
more able to effectively use this method to express
their priorities for the system
Mid stages of R&A: when the client and the
development team have a greater understanding of the
system they will develop. The client is not adding new
requirements, but rather the requirements are
becoming more clearly defined and precise. This
causes some of the more generalized requirements to
be broken down into two or more separate ones.
At this stage it may be important for the
development team to have more detailed information
on preference. Working on the Must, Should and
Could have requirements they could use techniques
such as the One hundred dollar method to see the
magnitude of preference for requirements located
within the one category.
As both the team and the client have been involved
in the project for a longer period of time, it is likely
that they would be more able to easily perform this
type of prioritisation as they are more familiar with the
requirements.
The more detailed information yielded could, after
viewing technical requirements, determine the build
order of components. This helps to ensure that the
greatest value of the system is delivered to the client as
early as possible.
An alternative to using the One Hundred Dollar
method would be using Simple Ranking. The method
of ranking requirement 1-n is really only feasible on
small groups of requirements. Within the Must, Should
and Could groups the number of requirements would
be considerably smaller than if they were considered as
a whole. Possibly if the project being worked on was
fairly simple and ratio scale information was not
required the order given by the simple ranking method
would be sufficient
9. Summary of Characteristics
Table 2 shows the properties of the prioritisation
methods which affect their suitability for various stages
of software development. Methods which are most
suitable for the early stages of a project should be
quick to perform and easily deal with additional
requirements. The information that they yield does not
need to be overly detailed but it needs to give
developers a starting point so the risk of misdirecting
resources is minimized. Table 2 identifies MoSCoW as
having these properties.
In some simpler projects where it is unlikely further
prioritisation will be needed and requirements are
relatively stable, the simple ranking may be suitable. It
is relatively quick and easy to perform as long as there
is a fairly small list of requirements.
At later stages of requirements analysis more
detailed information is required. Unless difficult
decisions about conflicting requirements need to be
made prioritisation still should be performed as quickly
and easily as possible. This means that in most cases
the hundred dollar method should be used. If there are
523
multiple objectives, the use of AHP should be
considered
student project data is relatively similar to that of
industry projects [28, 29]. There are a few main
differences between student teams and industrial teams
in terms of experience, team composition and project
length.
Industrial project teams generally have more
experience than students. Some of the student teams
used for this study included members who currently
work in industry. You would expect that industrial
teams to make fewer oversights in gathering
requirements due to their experience and the inclusion
of specialist in requirements analysis. Alternatively due
to the commercial pressures and strict time constraints
placed upon industrial teams they may be more
inclined to rush requirements analysis and as such also
miss important requirements.
Student projects studied were 13weeks long, this
makes them shorter than most industrial projects. It is
likely that the stages and changes in information would
be at different times but still the findings from student
projects may still be applicable to the industrial
projects.
The main focus of this research was looking at the
evolution of requirements and the suitability of
prioritisation techniques to stages in a project. While
the stages may occur at a different time depending on
the methodology being followed, the same sort of
requirements will be available in industrial projects and
student projects alike.
$100
√
√
√
AHP
MoSCoW
Quick and easy to perform
Easy to deal with additional
requirements
Category information
Ranked Information
Ratio Scale Information
Suitable for Goals and High
Level Requirements
Suitable for more detailed
Requirements
Simple
Ranking
Table 2. Properties of Prioritisation Methods
√
√
√
√
√
√
√
√
√
10. Prioritisation & Development Methods
Prioritisation is important in many development
methodologies. The idea of selecting the method most
suitable to the stage of the project, as well as to the
type of information available and required should
apply no matter what SDLC process is being followed.
For the more structured development methodologies
such as the Waterfall Method multiple prioritizations
could easily fit in the Requirements Engineering stage.
It would just be a case of picking the most suitable
times to reprioritize. These could be identified by the
way that requirements have evolved during RE as
described in section eight.
For Iterative, Evolutionary and Light Weight
methodologies using different techniques throughout
the iterations should make the best use of the
increasing knowledge. Initially all the main goals for a
system still have to be discovered agreed upon and
ordered for development.
Using the techniques
described in section eight for the early stages of RE,
would allow the risk of misdirecting resource to be
minimized. Once the goals that will be satisfied are
decided upon prioritization can be useful in
determining what components of that goal will be
developed. Thus although the amount of time between
the different stages in requirements engineering is a lot
less in these development methods, prioritization still
has a lot to offer.
12. Conclusion
Using the same method at all stages of a project is
not the most effective use of prioritisation. Just because
a certain prioritisation method is recommended by a
development methodology does not mean it will give
the most valuable results each time it is used.
Selecting methods based of their suitability to the
stage of the project and the information required means
that the methods can effectively aid in minimizing risk
to a project and ensuring that a client receives
maximum value even when it is not feasible to
implement all of their requirements.
This study has shown that the four different
prioritisation methods discussed in this paper have
properties which lend themselves to be used at
different project stages. By using these methods when
they are most suitable developers can get the best out
of prioritisation.
11. Validity
13. Future Work
This study used final year student project to look at
the evolution of requirements. It has been shown that
It would be interesting to repeat this study looking
at the evolution in requirements seen by more
524
experienced teams. Looking at projects following
different methodologies and over different periods of
time would also provide interesting insight.
While this paper had suggested the benefits of using
different prioritisation techniques with various SDLC
methodologies it still needs to be empirically
investigated. Trialing the prioritisation techniques
described above, on projects following different SDLC
methodologies, would be useful in assessing how well
they work with the methodologies and what the real
benefits at various project stages are.
[9] P.A. Laplante and C.J. Neill, “The Demise of the
Waterfall Model is Imminent” and other Urban Myths of
Software Engineering" ACM Queue, Vol.1, No. 10, February
2004. pp. 10-15.
[10] K. Beck, Extreme Programming Explained: Embrace
Change, Addison-Wesley Professional, USA, 1999.
[11] The DSDM Consortium: “DSDM public version 4.2”
online; available www.dsdm.org last accessed 22/01/07.
[12] S. R. Palmer, and J. M. Felsing, A Practical Guide to
Feature-Driven Development, Prentice Hall PTR, 2002.
14. Acknowledgements
[13] L. Rising, and N. S. Janoff, “The Scrum Software
Development Process for Small Teams”, IEEE Software,
July/ August 2000.
Thanks to Mark Reynolds and Terry Woodings for
their assistance and guidance. This would also not have
been possible without the participation of the student
groups, their cooperation is greatly appreciated.
[14] D. Astels, Test Driven Development: A Practical Guide
Prentice Hall PTR, 2003.
15. References
J. Highsmith, Agile Software Development
Ecosystems. Addison Wesley Professional 2002.
[15]
[1] The Standish Group, "The High Cost of Chaos," from
Computerworld, "Few IS Projects Come in on Time, on
Budget," Dec. 12 1994, p. 20.
[16] A. Ahl, An Experimental Comparison of Five
Prioritisation Techniques - Investigating Ease of Use,
Accuracy, and Scalability, Master Thesis No. MSE-2005-11,
School of Engineering, Blekinge Institute of Technology
2005.
[2] A., Ngo-The, and G., Ruhe, “Decision Support in
Requirements Engineering”, in Engineering and Managing
Software Requirements, ed. Aurum, A., and Wohlin, C.,
Springer Verlag, Berlin, Germany, 2005, pp. 267-286.
[17] J. Karlsson, C. Wohlin, and B. Regnell, “An Evaluation
of Methods for Prioritising Software Requirements”,
Information and Software Technology 39(14-15), 998, pp.
939-947.
[3] I., Sommerville and P. Sawyer, Requirements
Engineering: A Good Practice Guide. John Wiley & Sons.
1997.
[18] L. Karlsson, , P. Berander, B. Regnell, and C. Wohlin,
“Simple Is Better? - An Experiment on Requirements
Prioritisation” In proc. Third Conference on Software
Engineering Research and Practice in Sweden (SERPS '03),
Lund, Sweden, 2003.
[4] M. van Genuchten, “Why is Software Late? An Empirical
Study of Reasons for Delay in Software Development”.
IEEE Transactions of Software Engineering, 1991. 17(6): pp.
582-590.
[5] A. Davis, Software Requirements: Analysis and
Specification. Second Edition ed., Englewood Cliffs, NJ,
USA: Prentice-Hall. 1993
[19] L. Karlsson, M. Höst, and B. Regnell “Evaluating the
practical use of different measurement scales in requirements
prioritisation.” In Proceedings of the 2006 ACM/IEEE
international
Symposium
on
Empirical
Software
Engineering. ISESE '06. ACM Press, New York, NY, 326335, 2006.
[6] K. Wiegers, Software Requirements, 2nd Edition,
Microsoft Press, Redmond, WA., 2003.
[7] S. Hatton, “Early Prioritisation of Goals” In Hainaut, J.L.; Rundensteiner, E.A.; Kirchberg, M.; Bertolotto, M.;
Brochhausen, M.; Chen, P.; Sisaid Cherfi, S.; Doerr, M.;
Han, H.; Hartmann, S.; Parsons, J.; Poels, G.; Rolland, C.;
Trujillo, J.; Yu, E.; Zimlanyi, E. (Eds.) Advances in
Conceptual Modeling – Foundations and Applications.
Lecture Notes in Computer Science Vol 4802 SpringerVerlag, Berlin Heidelberg New York, 2007, pp 235-244.
[20] G.A. Miller, “The Magical Number Seven, Plus or
Minus Two: Some Limits on Our Capacity for Processing
Information” The Psychological Review, vol. 63, pp. 81-97
1956.
[21] D. Tudor, and G. A. Walter, “Using an Agile Approach
in a Large, Traditional Organisation” Proceedings of AGILE
2006 Conference (AGILE’06). pp 367 -373. 2006.
[8] C.J. Neill and P.A. Laplante, “Requirements Engineering:
The State of the Practice,” IEEE Software, Vol. 20, No. 6,
November-December 2003. pp. 40-45.
525
19th International Conference on Software Engineering pp
564-565. 1997.
[22] E.H. Forman, and S. I. Gass, “The Analytic Hierarchy
Process – and Exposition” in Operations Research Vol 49
No 4 July-August 2001 pp469-486, 2001.
[28] M. Höst, B. Regnell, & C. Wohlin, Using Students as
[23] M. A. Mustafa and J. F. Al-Bahar, “Project Risk
Assessment Using the Analytic Hierarchy Process” in IEEE
Transactions on Engineering Management Vol 38 Issue 1
Feb 1991 pp 46-52. 1991.
Subjects --- A Comparative Study of Students and
Professionals in Lead-Time Impact Assessment. Empirical
Software Engineering, Vol. 5, No. 3, pp. 201-214, 2000.
[24] T. L. Saaty, The Analytic Hierarchy Process, Planning,
Priority Setting, Resource Allocation, McGraw-Hill, USA
1980.
[29] P. Berander, 2004. “Using Students as Subjects in
Requirements Prioritisation.” In Proceedings of the 2004
international Symposium on Empirical Software Engineering
(August 19 - 20, 2004). International Symposium on
Empirical Software Engineering. IEEE Computer Society,
Washington, DC, 167-176.
[25] A. M. Davis, Just Enough Requirement Management,
Where Software Development Meets Marketing Dorset House
Publishing Company Incorporated New York USA, 2005.
[30] Anton, A., Potts, C.: “The Use of Goals to Surface
Requirements for Evolving Systems”. In Proceedings of 20th
international Conference on Software Engineering (ICSE
98). 1998. Kyoto, Japan. 1998.
[26] Y. Bao, T. Wu, Y. He, and X. Ge, “An Improved AHP
method in Performance Assessment” in Fifth World
Congress on Intelligent Control and Automation pp177-180
2004.
[27] K. Ryan, and J. Karlsson, “Prioritising Software
Requirements in an Industrial Setting” in Proceedings of the
526