OUTLINING VALUE ASSESSMENT FOR SOFTWARE
REQUIREMENTS
Pasi Ojala
Hintanmutka 17 A 6, Oulu, Finland
Keywords: Software requirements, assessment, value, worth, cost and Value Engineering.
Abstract: Understanding software requirements and customer needs is vital for all SW companies around the world.
Lately clearly more attention has been focused also on the costs, cost-effectiveness, productivity and value
of software development and products. This study outlines concepts, principles and process of implementing
a value assessment for SW requirements. The main purpose of this study is to collect experiences whether
the value assessment for product requirements is useful for companies, works in practice, and what are the
strengths and weaknesses of using it. This is done by implementing value assessment in a case company
step by step to see which phases possibly work and which phases possibly do not work. The practical
industrial case shows that proposed value assessment for product requirements is useful and supports
companies trying to find value in their products.
1 INTRODUCTION
According to Ojala (2006) the objective of the
value-based approach is to explore ways to eliminate
value loss in software development, software
products, and software process improvement (SPI)
using the value assessment framework of Koskela
and Huovila (1997). Value-based approach uses
economic-driven tools, which are based on
economic studies including, for example, the areas
of cost estimation, cost calculation (for example
ABC and life cycle costing) and investment
calculation. The value-based approach prefers
calculating costs instead of estimating them, and
also considers software development and SPI as
investments, on which it is possible to spend too
much money. In practice, it takes care that the
customer requirements are met in the best possible
manner, ensuring quality, timeliness and value in
products as well as in processes, over their entire life
cycle.
The value-based approach indicates a clear
dependency between the process and products. It
sees that we need to develop and optimize process
activities so that processes produce the products
needed. Furthermore, it sees that we must analyze
products in order to reveal problems in processes
and develop processes from the product point of
view as well. This is vitally important, especially for
companies respecting customer opinions and aiming
to optimize costs in their processes, because the
customers are the ones paying for the products and
product-related services, and companies have to
allocate all costs to products to be able to price them.
The purpose of this study is to collect experiences
of using value assessment for product requirements
in an industrial case. In more detail the purpose is to
answer to following questions:
• How the proposed value assessment for
product requirements works in practice
• The strengths and weaknesses of value
assessment for product requirements
• Whether the company assessed sees the
value assessment for product requirements
useful
2 VALUE ENGINEERING
PROCESS
This study categorizes VE process into three main
phases: pre-study (orientation), value study
(information, function analysis, creativity,
evaluation, development, presentation), and post-
445
Ojala P. (2008).
OUTLINING VALUE ASSESSMENT FOR SOFTWARE REQUIREMENTS.
In Proceedings of the Tenth Inter national Conference on Enterprise Information Systems - DISI, pages 445-448
DOI: 10.5220/0001690204450448
Copyright
c
SciTePress
study (monitoring, implementation). These phases
are considered appropriate since they constitute
independent areas of VE and have been justified in
earlier discussion (Ojala, 2006).
According to Value Engineering, value is a
measure – usually in currency, effort or exchange, or
on a comparative scale – which reflects the desire to
obtain or retain an item, service or ideal. Cost is the
price paid or to be paid. It can be divided into
elements and, to some extent, functions. Park (1999,
50) defines cost as “an expenditure of money, time,
labor, etc., to obtain a requirement.” Worth is usually
defined as the lowest cost to perform the required
function, or the cost of the lowest-cost functional
equivalent. The most typical definition for value
(Ojala, 2006), is perhaps (1):
(1)
where:
Value = The value of some object, product, service
or process.
Worth = The least cost to perform the required
function (product, service or process), or the cost of
the least cost functional equivalent. If possible can
also be the worth in money, what customer sees in
product, service or process.
Cost = The life cycle cost of the object, product,
service or process (price paid or to be paid).
3 VALUE ASSESSMENT FOR
PRODUCT REQUIREMENTS
3.1 Background
Value assessment for product requirements was
implemented in a multinational company producing
electronic products in fall 2006. The basis of it was
the requirement list done by customer and vendor
together. The requirement list contained
requirements such as: picture call, emergency, user,
server, distance configuration, video, service,
camera and activities.
Together with the requirement lists, several other
documents were analyzed during the assessment as
well. These documents included strategy plans,
project plans, process descriptions, selling
agreement and different financial statements.
3.2 Information
The product to be assessed was a electronic product
containing software and hardware. It was developed
in collaboration, by the vendor and the customer. In
the assessment opening meeting, the purpose of the
assessment was discussed with the vendor and the
customer. The definition value=worth/cost was
discussed, and it was seen as extremely important to
find out which requirements of the product gave the
best value to the vendor without neglecting customer
needs. The customer had a strong interest in
analyzing priorities and worth in requirements, for
further product development work. After the
discussion, it was decided that value would be
calculated for the requirements described in the
product sales agreement. This decision was strongly
supported because the vendor’s cost accounting
system made it possible to track real costs for the
specified requirements.
As a final point of the initial meeting, vendor and
customer roles were discussed. The vendor
emphasized that it would like to undertake the
phases from creativity to presentation without the
customer being present, since these phases included
brainstorming to gain a new understanding of all the
processes used to develop products. This point of
view was clearly understood by both parties, as the
customer was primarily interested in evaluating
requirement priorities, in order to see how well the
vendor had understood their wishes.
3.3 Function Analysis
After the initial meeting it was easy to “start the
assessment”, because the requirements to be
assessed were agreed in the information phase. In
the first assessment meeting four customer
representatives (referred to as “customers”) and
three vendor representatives (referred to as
“vendors”) prioritized the requirements. Afterwards,
the customers allocated worth to each requirement
using a percentage scale from 0% to 100%. The idea
was to identify in percentages what kind of worth
the customer sees in the requirements. The vendors
allocated costs using the same percentage scale from
0% to 100%. As a result of this, the customers had
given worth percentages for all requirements, and
the vendors had given cost percentages for the same
items. The calculated worth and cost were later
compared, using percentages, to the real worth and
cost, to find out the difference between “belief” and
“reality”.
All the interviewees agreed that the prioritization
of requirements clearly helped in the next phase, in
which the same requirements were analyzed in terms
ICEIS 2008 - International Conference on Enterprise Information Systems
446
of worth and cost. The customers found it easy to
assign worth to their requirements, based on the
customer price. The vendors also considered it easy
to assign costs to requirements.
One conclusion of discussions was that worth and
cost allocations for all requirements were seen as
relevant for both sides, even if only stated as
percentages. According to customer they also had
their own idea about the actual costs of production,
and since they knew the worth they were satisfied
for the situation. Figure 1 presents the average worth
and cost for requirements. In this figure we can
observe how, for example, the customer has
evaluated the worth of picture call function as being
noticeably higher than the vendor’s estimation of its
production cost. In practice, this means value for the
vendor.
Figure 1: Average worth and cost for requirements
including all interviewees (AV=average, C=customer,
V=vendor).
On the whole, the experiences of using
prioritization in ranking requirements were positive.
Even more interest was seen in the analysis of worth
and cost for each requirement, and especially in the
differences identified between customer and vendor,
as well as between technical- and user-oriented
personnel.
3.4 Creativity
In accordance with the agreement between the
customer and the vendor, only the vendor
participated in the phases from creativity to
presentation. The first step in the creativity phase
was to allocate costs to all requirements. According
to the vendor it was easy to allocate costs to the
requirements.
Based on the figures and discussion it was noted
that certain requirements did not create good value.
After discussion of this, the project members shared
the opinion that this was because of the unfinished
architectural plan.
Project members could also see from the charts
presented how time-consuming it was to start using
new technical environments, without good planning.
The new technical environment delayed the
implementation of certain requirements
significantly. New technical challenges, such as
developing software for multiprocessor
environments, were also named as one reason for
delays. This was because project personnel did not
have sufficient training in working in the
multiprocessor environment.
3.5 Evaluation
At the beginning of the evaluation phase the project
team discussed criteria for the evaluation of
improvement ideas. The calculated weighted
averages for criteria based on discussion were as
follows: system stability 25 %, safety 20 %,
optimized functioning 7.5 %, ease of use 20 %,
maintainability 15 %, and profitability 12.5 %.
After thus defining the weightings of the criteria,
the project personnel gave points to each
improvement proposal on a scale of one to six,
where six indicated maximum points and one,
minimum. The points allocated were multiplied by
the calculated weighting percentages.
The most surprising result was that the importance
of the technical environment was as high as third
place. Problems in design and architectural planning
were expected, as were problems related to project
management. Estimation and multiprocessing got
the least points, so their importance to the project
was not considered to be as high.
3.6 Development
In the development phase, the improvement ideas
were separately developed further, in order to
examine their practical implications.
Architectural Plan and Design Plans. One
proposed change was that the number of reviews for
the architectural and design plans had to be
increased. Project personnel also identified a clear
need to develop criteria for these review rounds.
Project members did not see any disadvantages to
the proposal. They calculated that if there had been
support resources for making more comprehensive
plans and reviewing them, the project would have
been 440 working hours shorter. The potential cost
savings would have been about 26 000 €.
Worth & Cost in Requirements
0.0
5.0
10.0
15.0
20.0
25.0
30.0
P
ic
t
u
re
ca
l
l
E
m
er
ge
n
cy
User
S
e
rve
r
D
i
stan
c
e
c
onf
i
g
u
ra
t
ion
Vi
d
e
o
Service
Cam
e
ra
Ac
t
i
vi
t
i
e
s
Requirement
%
C AV
Worth
(%)
V AV
Cost (%)
OUTLINING VALUE ASSESSMENT FOR SOFTWARE REQUIREMENTS
447
Technical Environment. At the moment, the ability
to use the existing characteristics of technical tools
is weak. The use of pre-existing components is also
rather poor. The result is that code has to be written
from start to finish each time.
The project group evaluated that if basic
components for development work had existed, 100
fewer working hours would have been required. If
there had been sufficient technical training
concerning the new environments (dotNET and ATL
7) for key personnel, 150 fewer working hours
would have been required. In total, the potential cost
savings would have been approximately 9 000 €.
Project Management. From a project management
point of view, it is problematic that all the
employees are always assigned one hundred percent
to a given project. As a consequence, there is not
enough support available if needed, and “the wheel
is invented several times in different projects.”
The project team evaluated that with satisfactory
support in evaluating the architectural plan, the
design plans, and the extra need for time in starting
to use new technologies, 100 fewer working hours
would have been required. In financial terms, this
would have meant a saving of about 6 000 €.
3.7 Presentation
The results of the product value assessment were
presented phase by phase to the high-level
management. In the presentation, a clear emphasis
was placed on presenting customer needs and wants,
and the corresponding costs to the company. The
value indexes were used to outline the existing
value-increasing opportunities. The potential cost
saving proposed was approximately 26% of product
price.
As a whole, the assessment strongly emphasized
collaboration between the customer and the vendor,
and all the improvement proposals were in line with
the customer’s interests as well. All customer and
vendor representatives considered product
assessment an interesting method for the
development of product quality and value, and
process capability.
4 CONCLUSIONS
Presented product assessment for requirements
worked very well in practice. All participants agreed
that the value assessment process was clear and
practical for their use. Vendor saw it important that
the customer was involved to the assessment as it
increased the efficient use of resources and brought
more business point of view to the assessment,
which was considered to be extremely important.
The product assessment for requirements gave
more customer-oriented improvement proposals than
process assessments. Product assessment also
involved the customer in the decision process so that
described requirements were in a more solid basis to
be implemented. All participants also emphasized
that if value assessment is done in the planning
phase of a product, it is cheaper for any company
than making changes after several months of
development work.
There were also weaknesses in the proposed value
assessment for requirements. Firstly, the empirical
findings of this study are rather limited as this study
bases on one industrial case. Secondly, some costs
had to be estimated instead of having calculated
actual costs.
Generally, all the assessment results in this
assessment are reliable. The reliability of the results
was also improved significantly because the assessor
interviewed several people and went through the
same questions with all of them. The interview
results were also compared to existing written
material to check that they matched.
REFERENCES
Erdogmus H, Cusumano MA, Kontio JG & Raffo D
(2004). The sixth International Workshop on
Economics-Driven Software Engineering Research
(EDSER-6). Proceedings of the 26th International
Conference on Software Engineering (ICSE 04).
Edinburg, Scotland. IEEE Computer Society. 761-762.
Koskela, L., Huovila, P., “On foundations of Concurrent
Engineering in Construction CEC’97. London, 3-4
July. London, The Institution of Structural Engineers,
1997, pp. 22-23.
Ojala, P., Implementing a Value-Based Approach to
Software assessment and Improvement. Doctoral
dissertation. University of Oulu, 2006.
Park R Value Engineering. A Plan for Invention. New
York, St. Lucie Press, 1999.
Solingen R Measuring ROI of Software Process
Improvement. IEEE Software May, 2004, pp. 32-38
ICEIS 2008 - International Conference on Enterprise Information Systems
448
