2019 IEEE 27th International Requirements Engineering Conference (RE)
An Agile Method of Representing, Organizing, and (Re)prioritizing
Requirements in a Large Enterprise
Woogon Shim
Software Engineering Lab., LG Electronics
Dept. of Software & Computer Engineering, Ajou University
Seoul, South Korea
woogon.shim@lge.com
Abstract— Agile and lean are now the mainstream tenets
of software development. This development methodology is
attracting attention because it can develop software that op-
erates quickly despite uncertain situations and limited in-
formation (requirements), and it can adaptively develop
while checking feedback both frequently and regularly. The
key is to welcome change without resistance, which is not
limited to development but also requires changes in require-
ment management. However, there is a lack of practical
guidance on how to manage changes in agile requirements
engineering. Although we need to consider all areas of re-
quirements engineering, the author has seen three key
themes: (1) How to focus on customer value and represent
it clearly for smooth communication between teams in a
large enterprise? (2) What are the requirements for organ-
izing elements that make it easy to accept changes and assess
impacts? (3) What reasonable algorithm is easy to use and
reliable to prioritize or reorder requirements based on val-
ues regularly? The author wants to suggest practical ways
to address these themes and propose a way to deal with
three themes without compromising on the essence of agile.
The author is going to do case studies with some organiza-
tions that are already using or first adopting agile software
development. The author could get the strengths and weak-
nesses in terms of collaboration promotion and change both
the acceptance and qualitative feedback on application re-
sults.
Index Terms—Agile, Lean, Just-in-time, VBSE,
Requirement representation, Requirement organization,
Requirement (re)prioritization
I.
INTRODUCTION
Change is an intrinsic characteristic of the software engineer-
ing discipline compared to other engineering disciplines [1].
This characteristic means that agile software development (ASD)
emphasizes the embrace of changes rather than resistance. On
the same horizon, Value-Based Software Engineering (VBSE)
[2] highlights that it is not sufficient to merely meet schedules,
budgets, and quality objectives; ultimately, software must create
value. Continuous Experimentation [3] emphasizes
2332-6441/19/$31.00 ©2019 IEEE
DOI 10.1109/RE.2019.00063
experimentation such as A/B testing and the data-driven deci-
sions to deliver value to the customer rapidly. Lean Software
Development [4], [5] provides comprehensive guidance for the
combination of design, development, and validation built as a
single feedback loop focused on the discovery and delivery of
value. Lean Startup [6] provides mechanisms to ensure that what
customers want gets adequately addressed by the development.
It proposes applying the scientific method and thinking to startup
businesses in the form of learning experiments.
Moreover, to handle uncertainty, agile fixes the date and re-
sources and varies the scope. The key to agile or lean is selecting
and focusing the minimum viable product (MVP) and adopting
feedback from the customer in each iteration. Behind this, we
should prioritize requirements by considering the value in paral-
lel or regularly [7]. Major studies such as the Standish Group’s
CHAOS report (www.standishgroup.com) reveal that value-ori-
ented shortfalls cause the most software project failures [8].
II.
MOTIVATION
Many companies are attempting to introduce the value of
agile, but they are often more interested in the fruits rather
than fundamental changes and following certain practices or
processes. Agile development is an empirical and evolutionary
developmental approach that can be applied and adapted in
any environment. However, studies by [9], [10], and [11] have
found that the cultural characteristics of a nation also affect
how it applies agile. These studies analyzed certain countries
based on the Hofstede model, which is a model for comparing
and analyzing the country’s cultural characteristics and show-
ing that there is a correlation between the six-dimension in-
dexes and the agile manifesto [10] and agile practices [11],
with some limitations.
East Asian countries, including South Korea, tend to be
organized homogeneously, although some companies are dis-
tributed around the world. In other words, there is a high prob-
ability that the country’s cultural characteristics may be re-
flected rather than the conflict of multiple cultures. According
to [12], South Korea is a slightly hierarchical society, consid-
ered a collectivistic society, one of the world’s most
464
uncertainty-avoiding countries, and shown to be one of the re-
straints (the green bar in Figure 1). That is, it is difficult to in-
troduce and apply agility because the Power Distance Index
(PDI) is high, and Individualism (IDV) is low. For example,
employees tend to act conservatively, depending on their or-
ganization’s hierarchy, role, and accountability, rather than
freely expressing and discussing their opinions. This may
cause daily scrum meetings to fall into a daily reporting form
or interfere with cooperation among related departments. In
other words, South Korea's representative "ppalli ppalli" cul-
ture, which means fast-paced lifecycle [13] can nicely suit
with agile, but it should be introduced as tailored agile rather
than pure agile in consideration of national cultural character-
istics.
Fig. 1.
Country comparison between East Asia and the United States
(Hofstede Insights)
In particular, the company to which the author belongs is
a large-scale consumer electronics manufacturing company
with both scale-driven and manufacturer-specific characteris-
tics. First, as the organization grows in size, more detailed
functional organizations are created, and the interests become
more complex. Therefore, requirements must be created and
managed so that all related departments can easily understand
each other and communicate [14]. The formal specification or
model is not very attractive for agile development because it is
costly for all of the organization's practitioners to learn. As can
be seen in Figure 2, the requirements were gathered from vari-
ous functional departments. The level of content created by
each department varies widely; preserving the current organi-
zational form; there is no individual or organization has the
role and responsibility of Scrum's Product Owner. Therefore,
it is difficult to evaluate, prioritize, and make choices that
must go through the consensus of relevant organizations.
465
Fig. 2.
Various requirement channels
Second, Asian companies are generally more interested in
asking How rather than Why or What. As a fast follower, they
have developed quickly over a relatively short period, so they
do not need to care about why or what. There is a severe lack
of interest in value, so the activity of deriving and evaluating
requirements on a value basis is not well established.
Third, only SW development organizations work in agile.
In other words, the company develops a product in a water-ag-
ile-fall manner. As the nature of the embedded products, the
whole development schedule is driven by HW. Since the com-
pany has to deliver the end product to its customers, it has to
be equipped with the perfect quality function before launch. In
addition, all requirements are often specified as MUST
HAVE.
Although my company mainly applies agile to the devel-
opment of new products or services, we still face the same
problem because the overall organizational and collaborative
nature of the features remains the same.
III.
PROBLEM
The author believes that successfully implementing agile
development will require that the preceding step, Requirement
Engineering activities, is done first in an agile manner. Natu-
rally, activities should be done to regularly (re)evaluate priori-
ties, take the value and urgency of the collected requirements
into account, define the requirements by considering who the
target customer is precisely, and identify the value to deliver
to that customer.
This will first require that the author has a practical guide
for agile REs, and the author needs to propose tailoring activi-
ties based on cultural characteristics and the properties of large
organizations. The important thing is that the proposed method
should not hurt the essence of agile.
Fig. 3.
Objective and relationship among RQs
 Our research questions are:
RQ1. How can we focus on customer value and represent it
clearly to ensure smooth communication among various teams
in a large enterprise? How should we use this to evaluate prior-
ity?
RQ2. How should we handle the problem of User Story Hell?
[15] How can we organize well-mixed requirements with hy-
potheses and validated facts? Are there procedures to facilitate
the impact assessment of changes and requirements updates?
How can we support dual-track agile?
RQ3. What is a natural, efficient, and reliable way to re-eval-
uate/prioritize requirements on a value-based basis? Is it possi-
ble to utilize crowd knowledge rather than a few specific indi-
viduals for valuation?
Figure 3 depicts that the three research questions are strictly
interrelated and an example of the classic chicken-and-egg prob-
lem, so the author has to look at all three together rather than
individually.
IV.
RELATED WORKS
Agile software development can be summarized in one sen-
tence: "Deliver customer highest value with working quality
product frequently and continuously." However, agile require-
ment engineering can be summarized on this basis as "Discover
and manage customer highest value frequently and continu-
ously."
RQ1. Customer value-based requirement representation
It is pointed out that the format of the user story itself is sim-
ple and not faithful as a document [16]. However, agile advo-
cates claim that the user story format was initially intended to
consider customer-focused value without containing all levels of
its details. All of the hidden and implicit information should be
revealed by face-to-face communication [17], [18], which is
why agile emphasizes cross-functional teams in the same loca-
tion. Meanwhile, Lucassen created a format to satisfy 14 quality
attributes of requirement documentation [19]; however, this will
likely hinder the agility of product development.
There have been many attempts to solve this problem. Since
customers feel that their values help them carry out their tasks
and find solutions, Klement proposed another format, the Job
Story [16]. Martin Fowler often failed to represent all cases in a
single User Story, which suggests that one User Story should be
extended to at least three categories (basic, uncaught exceptions,
and bug fixes). To link test-driven development (TDD) with the
requirements, we need to specify Specification by Example [20]
and use examples to make requirements that can then be used to
create test cases through specific scenarios instantly. There is
Behavior-Driven Development (BDD), which records behavior
based on the style of the Given-When-Then; these things are not
new. RE researchers had already presented the similar concepts
Scenario-based RE [21] and Goal-Scenario [22].
466
RQ2. Organize requirements effectively and support dual-
track agile [23]
1)
Academic Community
In academia, similar to traditional organizations, they know
that agile RE is carried out in projects’ early stages [24] or before
the start of each iteration [25]. However, in agile development,
RE works in parallel with development throughout the project
period [26], and development starts even when the requirements
are imperfect. In the goal sketching technique [27], allowing
TBD in goal modeling means that it can provide a level of ab-
straction to Goal-oriented RE (only as needed when necessary)
and give a few notations that various stakeholders can use easily.
However, RE-KOMBINE [28] tolerates the presence of incon-
sistencies and conflicts in requirements that are incurred when
undertaking development with incomplete requirements. How-
ever, it also provides paraconsistent logic to detect and resolve
inconsistencies early on. It is quite flexible but challenging to
learn and use because it is a formal method.
Olsson and Bosch noted that a few decision-makers tend to
determine features because getting feedback from customers
takes too long, and collecting and analyzing data is inefficient.
To overcome this, they proposed a Hypothesis Experiment Data-
Driven Development (HYPEX) [29] or Qualitative/quantitative
Customer-driven Development (QCD) [30] model that can
check the customer's value and product features by receiving
prompt and accurate feedback data from customers. This model
considers requirements as a hypothesis and validates them pro-
gressively based on the results of the experiment.
2)
Business Analyst Community
Discover to Deliver [31] presents agile product planning and
analysis methods. The discovery phase, which uncovers new re-
quirements, and the delivery phase, which develops and delivers
the needs of the identified customers, are repeated continuously.
This provides seven predefined dimensions for stakeholders to
guide collaboration. Structural communication is made for each
dimension, and after pouring out various ideas (divergence) and
screening the items with the highest ROI (convergence), the
product requirements of the next iteration are determined. Alt-
hough this approach is concerned with iterative development, it
does not deal with how to manage the change of requirements
based on what we have learned.
Value Proposition Design [32] is a follow-up study of the
Business Model Canvas [33]; it is a separate extension of “Value
Proposition” and “Customer Segment” among the nine blocks.
In-depth analysis of customers can help us identify needs and
pains and separately consider what features the company will
offer to provide value to customers. During each iteration, we
can review whether the product prepared (“value proposition”)
by the company matches the customer analysis (“customer seg-
ment”) and visualize it with a whiteboard and post-its.
3)
Agile and Lean Community
 Impact Mapping [34] presented a simple and effective re-
quirements management system to escape the "user story card
hell” [15]. Impact mapping is a strategic planning technique that
prevents organizations from getting lost while building products
and delivering projects by clearly communicating assumptions,
helping teams align their activities with overall business objec-
tives, and make better roadmap decisions. It restructures the typ-
ical user story format "As a <type of actor>, I want <delivera-
ble> so that <impact>" into a mind-map form. It rearranges user
stories into the form Why–Who–How–What. It acts as a goal- and
customer-centered map that guides us not to be lost during de-
velopment.
Moreover, the connection line between each item is the as-
sumption that needs to be validated. However, there is a limita-
tion in that despite showing the entire requirement map. It is dif-
ficult to see how features are connected and how they flow from
a customer's perspective.
Instead, User Story Mapping [18] creates narrative end-to-
end backbone scenarios that deliver value to the customer and
then attach specific work and exception handling tasks below
each stage of the skeleton scenario according to priority and then
groups them so that can provide the outcome of the customer's
perspective and establish a release plan. It is easy to understand
the overall functional flow and natural to plan releases, but it is
difficult to grasp the product context from an individual cus-
tomer perspective.
RQ3. Value-based requirement (re)prioritization
There are several ways to calculate priority. Generally, if the
Return on Investment (ROI) is high, the priority is set to high.
The ROI is the result of the potential return (value) divided by
the effort (the cost to implement) a feature. This approach as-
sumes that high ROI requirements must be developed first for
low ROI requirements [35]. However, if the ROI is low but
needs to enable other requirements, [7] should be developed first.
For example, if requirement A depends on requirement B, then
the priorities of these requirements should be consistent, and re-
quirement B should have at least as high a priority as A (e.g., B
should be implemented either before A or during the same build
as A) [36].
To address this problem, the Scaled Agile Framework (SAFe)
has adopted the Weight Shortest Job First (WSJF) method that
uses Reinersten's Cost of Delay (CoD) concept, as a method of
prioritizing [37], [38]. Cost of Delay is calculated as the sum of
user-business value, time criticality, and risk reduction and/or
opportunity enablement. WSJF makes a relative estimate by
concentrating on one item at a time, evaluating the item with the
smallest value as "one," and assigning the remainder to the rela-
tive value. Relative values are the Fibonacci numbers used in
planning poker. Finally, the WSJF value can calculate the CoD
as the job size (job duration), and the item with the highest WSJF
value has the highest priority [38].
Meanwhile, there have been attempts to evaluate and apply
17 different priority algorithms for value-based requirement pri-
oritization (VBRP) [39]. There are in-depth studies of items and
criteria that assess value. The Software Value Map [40]
467
identified 62 universal and comprehensive value propositions
(called components). Value is assessed subjectively, which
means that there is not only a difference between individuals but
also between companies. In the VALUE project [41], [42], they
saw a different value proposition (or value factor) for each com-
pany. Therefore, they interviewed the key stakeholders involved
in valuation and analyzed the results to identify 36 value propo-
sitions that were classified into six dimensions: customer value,
market competitiveness, economic value/profitability, cost effi-
ciency, technology & architecture, and company strategy.
V.
PROPOSED METHOD (IN PROGRESS)
RQ1. Customer value-based requirement representation
Using specific scenarios can help with goal modeling [43].
In addition, if the development team uses TDD, it can be used as
a test case (i.e., an executable specification) to check the imple-
mentation results [20]. Besides, large companies often have re-
quirements that must be communicated across multiple channels,
so multiple functional departments often communicate and eval-
uate their priorities. Here, the authors prefer intuitive represen-
tation rather than the formal model. (1) When the UI flow show-
ing the screen switching is the most natural to understand, and
there is no UI; (2) it was adequate to use the Given–When–Then
style of BDD; (3) JTBD style (When <situation> I want to <mo-
tivation> So I can <outcome>) [16], which makes the custom-
er's situation easier to understand instead of the classic User
Story format. This study aimed to establish the criteria based on
the actual application result, which is suitable to use in certain
situations. Meanwhile, there is a concern about coverage based
on the scenarios [44], but it is not a problem unless it is either an
embedded product or a mission-critical system.
Fig. 4.
Process of our approach in the dual-track context
RQ2. Organize requirements effectively and support dual-
track agile
The author will consider how to manage the three candidate
requirement representations for RQ1. In addition, the author
wants to provide what prioritization information is necessary for
RQ3 to quickly reflect updated information and expand previous
research [23] on how to express and reveal the dependencies be-
tween requirements.
RQ3. Value-based requirement (re)prioritization
(Re)prioritization activities that should be performed regu-
larly are based on three alternatives: (1) In the early stage of de-
velopment. Key stakeholders were interviewed in a similar man-
ner to [41] to derive value factors. AHP analysis identifies the
hierarchy between value factors and calculates the weights.
Then, individual requirements are used to prioritize using TOP-
SIS, such as [39]. (2) The author will expand the WSJF method
and adopt the method proposed by [45]. The proposal is to cor-
rect the CoD calculation by separating the orthogonal Urgency
from the Value. In addition, (3) whether KANO Analysis can be
applied practically is confirmed through a case study.
VI.
PLAN TO VERIFY
The proposed approach was developed experimentally and
promoted at the in-house SW college, and training was con-
ducted twice in total with personnel who wanted to learn and get
the opportunity to practice with various organizations. In this
process, the approach was refined to be easily understood and
applied, and actual cases were collected while conducting semi-
nars for organizations managing requirements within the com-
pany.
The author would like to apply the pilot to a few projects at
the organization that manages the requirements to verify that the
proposed approach can solve problems at the company to which
the author belongs. Meanwhile, the author will recruit agile prac-
titioners who belong to medium- and large-scale organizations
with the same cultural environment in South Korea and confirm
that the proposed approach is both practical and helpful.
VII.
TECHNICAL CHALLENGES AND DISCUSSIONS
The author determined that none of the three RQs should be
handled separately. There will be meaningful results when it is
finished but could each be considered too big a topic and thus
the focus should be on just one of them? This is a concern. Mean-
while, business analysts and startup entrepreneurs also need lean
and agile philosophies, and similar approaches have recently
emerged in terms of concepts such as Value Proposition Design
and Lean UX. It is difficult to determine the meaning of a doc-
toral dissertation by simply acquiring cases and providing spe-
cific procedures for the software development domain.
Regarding priority evaluation, the most important thing is
that priority evaluation and rebalancing should occur at least at
every iteration. Therefore, the cost of prioritization should be
small, and there should be consistent and realistic decision mak-
ing so that the priority evaluation results do not overturn the re-
sults per metric. For the MCDM algorithm, there may be a limit
to the number of items to be evaluated or the scale, or sometimes
a reverse ranking problem. In addition, since the MCDM is the
optimal choice among equivalent levels of mutually competitive
alternatives, it is questionable whether the same algorithm can
be used to assess mutually dependent requirements; therefore,
we intend to concentrate on WSJF. In this case, there is a concern
468
that the algorithm’s constraints do not result in productive and
positive results.
REFERENCES
[1]
S. Jayatilleke and R. Lai, “A systematic review of require-
ments change management,” pp. 1–23, Oct. 2017.
[2]
B. Boehm, “Value-based software engineering: reinvent-
ing,” SIGSOFT Software Engineering Notes, vol. 28, no.
2, p. 3, Mar. 2003.
[3]
A. Fabijan, P. Dmitriev, H. H. Olsson, and J. Bosch, “The
Evolution of Continuous Experimentation in Software
Product Development: From Data to a Data-Driven Or-
ganization at Scale,” presented at the 2017 IEEE/ACM
39th International Conference on Software Engineering
(ICSE), pp. 770–780.
[4]
M. Poppendieck and M. A. Cusumano, “Lean software
development: A tutorial,” SOFTWARE, vol. 29, no. 5, pp.
26–32, 2012.
[5]
M. Poppendieck and T. Poppendieck, Implementing lean
software development: From concept to cash. Pearson Ed-
ucation, 2007.
[6]
E. Ries, The Lean Startup. Crown Business, 2011.
[7]
D. Leffingwell, Agile software requirements: lean re-
quirements practices for teams, programs, and the enter-
prise. Addison-Wesley Professional, 2010.
[8]
B. Boehm and L. G. Huang, “Value-based software engi-
neering: a case study,” Computer, vol. 36, no. 3, pp. 33–
41, 2003.
[9]
S. Pahuja, “Questioning if Agile Works in Asia,” Jun.
2016.
[10]
B. Vodde, “Scrum doesn't work in China!?,” presented at
the Scrum Gathering, Shanghai, 2010, pp. 1–66.
[11]
H. Ayed, B. Vanderose, and N. Habra, “Agile cultural
challenges in Europe and Asia: insights from practition-
ers,” presented at the 2017 IEEE/ACM 39th International
Conference on Software Engineering: Software Engineer-
ing in Practice Track (ICSE-SEIP), pp. 153–162.
[12]
“Country Comparison of East Asia and the United
States,” Hofstede Insights. [Online]. Available:
https://www.hofstede-insights.com/country-compari-
son/china,japan,south-korea,the-usa/.
[13]
H. L. Yi, “[Korean Culture 101] ‘Ppalli Ppalli Culture’ –
Korean’s Disposition to Like Fast-paced Lifestyle,” Ko-
rea Daily, 26-Feb-2016.
[14]
R. Kasauli, G. Liebel, E. Knauss, S. Gopakumar, and B.
Kanagwa, “Requirements Engineering Challenges in
Large-Scale Agile System Development,” presented at the
2017 IEEE 25th International Requirements Engineering
Conference (RE), 2017, pp. 352–361.
[15]
J. Shore, “Beyond Story Cards: Agile Requirements Col-
laboration,” 25-Mar-2005. [Online]. Available:
http://www.jamesshore.com/Presentations/Be-
yond%20Story%20Cards.html.
[16]
A. Klement, “Replacing The User Story With The Job
Story – Jobs to be Done,” 13-Nov-2013. [Online]. Availa-
ble: https://jtbd.info/replacing-the-user-story-with-the-
job-story-af7cdee10c27#.i6750x1yu.
[17]
M. Fowler, “Conversational Stories,” 04-Feb-2010.
[Online]. Available: https://martinfowler.com/bliki/Con-
versationalStories.html.
[18]
J. Patton and P. Economy, User Story Mapping. “O'Reilly
Media, Inc.,” 2014.
[19]
G. Lucassen, F. Dalpiaz, J. M. E. M. van der Werf, and S.
Brinkkemper, “Forging high-quality User Stories: To-
wards a discipline for Agile Requirements.,” RE, pp. 126–
135, 2015.
[20]
G. Adzic, Specification by Example. Manning Publica-
tions, 2011.
[21]
A. Sutcliffe, “Scenario-based requirements engineering,”
presented at the Requirements Engineering Conference,
2003. Proceedings. 11th IEEE International, 2003, pp.
320–329.
[22]
C. Rolland, G. Grosz, and R. Kla, Experience with goal-
scenario coupling in requirements engineering. IEEE,
1999, pp. 74–81.
[23]
W. Shim and S. W. Lee, “An agile approach for managing
requirements change to improve learning and adaptabil-
ity,” Journal of Industrial Information Integration, vol.
14, pp. 16–23, 2019.
[24]
Ben Linders, “Delivering Software with Water-Scrum-
Fall,” Nov. 2015.
[25]
Z. Racheva, M. Daneva, and A. Herrmann, “A conceptual
model of client-driven agile requirements prioritization:
Results of a case study,” presented at the Proceedings of
the 2010 acm-ieee international symposium on empirical
software engineering and measurement, 2010, p. 39.
[26]
S. Lerén and I. Domingues, “Impact-Driven Scrum Deliv-
ery,” presented at the Global SCRUM Gathering, Phoe-
nix, 2015.
[27]
K. Boness and R. Harrison, “Goal Sketching: Towards
Agile Requirements Engineering,” presented at the Inter-
national Conference on Software Engineering Advances
(ICSEA), 2007, pp. 71–71.
[28]
N. A. Ernst, A. Borgida, I. J. Jureta, and J. Mylopoulos,
“Agile requirements engineering via paraconsistent rea-
soning,” Information Systems, vol. 43, no. C, pp. 100–
116, Jul. 2014.
[29]
H. H. Olsson and J. Bosch, “From Opinions to Data-
Driven Software R&D,” presented at the Software Engi-
neering and Advanced Applications (SEAA), 2014 40th
EUROMICRO Conference on, 2014, pp. 9–16.
[30]
H. H. Olsson and J. Bosch, “Towards Continuous Cus-
tomer Validation - A Conceptual Model for Combining
Qualitative Customer Feedback with Quantitative Cus-
tomer Observation.,” ICSOB, vol. 210, no. 13, pp. 154–
166, 2015.
469
[31]
E. Gottesdiener and M. Gorman, Discover to Deliver.
EBG Consulting, Inc., 2012.
[32]
A. Osterwalder, Y. Pigneur, G. Bernarda, and A. Smith,
Value Proposition Design. John Wiley & Sons, 2014.
[33]
A. Osterwalder and Y. Pigneur, Business Model Genera-
tion. John Wiley & Sons, 2010.
[34]
G. Adzic, Impact Mapping. Provoking Thoughts, 2012.
[35]
J. Karlsson and K. Ryan, “A cost-value approach for pri-
oritizing requirements,” SOFTWARE, vol. 14, no. 5, pp.
67–74, 1997.
[36]
D. Firesmith, “Prioritizing Requirements,” JOT, vol. 3,
no. 8, pp. 35–14, 2004.
[37]
D. G. Reinertsten, The principles of product development
flow: second generation lean product development. Celer-
itas, 2009.
[38]
D. Leffingwell, SAFe 4.5 Reference Guide: Scaled Agile
Framework for Lean Enterprises. Addison-Wesley Pro-
fessional, 2018.
[39]
N. Kukreja, S. S. Payyavula, B. Boehm, and S. Pad-
manabhuni, “Value-Based Requirements Prioritization:
Usage Experiences,” Procedia - Procedia Computer Sci-
ence, vol. 16, pp. 806–813, 2013.
[40]
M. Khurum, T. Gorschek, and M. Wilson, “The software
value map—an exhaustive collection of value aspects for
the development of software intensive products,” Journal
of software: Evolution and Process, vol. 25, no. 7, pp.
711–741, 2013.
[41]
P. Rodríguez, E. Mendes, and B. Turhan, “Key Stake-
holders' Value Propositions for Feature Selection in Soft-
ware-intensive Products: An Industrial Case Study,” IEEE
Transactions on Software Engineering Y1 -, pp. 1–1,
2018.
[42]
V. Freitas, M. Perkusich, E. Mendes, P. Rodríguez, and
M. Oivo, “Value-Based Decision-Making Using a Web-
Based Tool: A Multiple Case Study,” presented at the
2017 24th Asia-Pacific Software Engineering Conference
(APSEC), Nanjing, China, 2017, pp. 279–288.
[43]
C. Rolland, C. Souveyet, and C. Ben Achour, “Guiding
Goal Modeling Using Scenarios,” IEEE Transactions on
Software Engineering, vol. 24, no. 12, pp. 1055–1071,
Dec. 1998.
[44]
S. Misra, V. Kumar, and U. Kumar, “Goal-oriented or
scenario-based requirements engineering technique - what
should a practitioner select?,” … and Computer Engineer-
ing, pp. 2288–2292, 2005.
[45]
J. Arnold, “SAFe & Cost of Delay: a suggested improve-
ment,” Jun-2016. [Online]. Available: http://blackswan-
farming.com/safes-cost-of-delay-a-suggested-improve-
ment/.