University of South Wales

Spring Term 2016

Module: Dissertation Project (Client Project 5)
Tutor: Dr. Paul Davies

Requirements Elicitation for

Mobile B2B Applications
A project-based consulting approach
Management Summary

Mobile B2B applications are an emerging issue when it comes to the adoption of new
technologies in business, providing innovative opportunities for multiple operations between
customers and companies. For organisations that have decided to implement such an
application within the scope of a project, the requirements elicitation process depicts an
important step in order to determine necessities and to build a basis for subsequent strategic
decisions. This paper depicts an offer for a B2B food sector company with the intention of
identifying the requirements for such a project. The introduced approach utilises approved
methods and techniques from the fields of project and software management.

The offer covers an examination of three relevant categories of requirements. In order to

determine the functional requirements (functionalities the B2B application has to exhibit), the
methods stakeholder analysis and software benchmarking are introduced. For the structural
requirements (possibility and appropriateness to implement the application within the
company’s structural circumstances), system environment analysis, personnel analysis as well
as risk identification and analysis cover a basis for future decisions. Finally, project time
planning and life-cycle cost analysis investigate the resources requirements the company will
have to face. The study will be conducted within a timeframe of 6 months (26 weeks) which
is illustrated by a Gantt-chart. Overall, the holistic character of the approach, the
acknowledged benefits of the individual methods as well as the recommendations which can
be derived on the basis of the defined objectives will make the study of high value to the
client and provide adequate information for further actions regarding the application’s
programming and implementation process.
Table of Contents
1. Introduction – Background and Objectives............................................................................1
2. Supporting Evidence – The Requirements Elicitation Approach...........................................2
2.1 Objective 1 – Functional Requirements............................................................................3
2.1.1 Stakeholder Analysis..................................................................................................3
2.1.2 Software Benchmarking.............................................................................................3
2.2 Objective 2 – Structural Requirements.............................................................................4
2.2.1 System Environment Analysis....................................................................................4
2.2.2 Personnel Analysis.....................................................................................................5
2.2.3 Risk Identification and Analysis.................................................................................6
2.3 Objective 3 – Resources Requirements.............................................................................6
2.3.1 Project Time Planning................................................................................................6
2.3.2 Life-Cycle Cost Analysis............................................................................................7
3. Study Gantt-Chart...................................................................................................................8
4. Contribution..........................................................................................................................10
4.1 Stakeholder Analysis.......................................................................................................10
4.2 Software Benchmarking..................................................................................................10
4.3 System Environment Analysis........................................................................................11
4.4 Personnel Analysis..........................................................................................................11
4.5 Risk Identification and Analysis.....................................................................................12
4.6 Project Time Planning.....................................................................................................12
4.7 Life-Cycle Cost Analysis................................................................................................13
5. Concluding Remarks.............................................................................................................13

I. References.............................................................................................................................14
1. Introduction – Background and Objectives

New communication technologies always bring along new chances and ways of conducting
daily business operations. In this context, the utilisation of the internet to collaborate with
trading partners depicts a notable advance within the last two decades. These direct
electronical collaborations are commonly labelled as business-to-business (B2B) applications,
which for example target “e-procurement, supply-chain management (SCM), and B2B e-
payment” (Al-Naeem et al., 2005, p. 41). Due to the rise of mobile devices like smartphones
or tablets and the concomitant increased usage of professionals’ mobile devices during work,
especially mobile B2B applications have been evolving as an important tool for customer
relationship management (Smilansky, 2015). Nowadays, people already spend more time
using mobile applications than internet via traditional desktop computers (Zamfiroiu, 2015).
Well-known software manufacturers already detected this development, offering mobile B2B
applications for multiple business purposes (Tornack et al., 2011).

The client, an SME providing food products to catering companies, is aware of this progress
and intends to program and implement a mobile B2B application for his customers. However,
due to the high complexity of such IT projects, only an extensive exposure of the
requirements can prevent the project from certain failure (Azadegan et al., 2013). Based on
the results of more than hundred research and development projects, Dvir et al. (2003) point
out that project success is strongly correlated with the definition of those requirements. In
order to determine relevant requirements of this project, a study shall provide valuable
information about different project necessities. Regarding software development, this process
is commonly labelled as ‘requirements engineering’ respectively ‘requirements elicitation’
which describes “seeking, uncovering, acquiring and elaborating requirements for computer
based systems” (Zowghi and Coulin, 2005, p. 19). Although requirements elicitation is mostly
perceived as the first major step of a software engineering project, the shape of its process and
used methods varies, depending on the particular project (Vijayan and Raju, 2011). Hence,
this report can be understood as a consulting offer to conduct a requirements elicitation study,
outlining all pertinent methods which are of importance for the individual case of the client.

It is of fundamental importance that the study as well as the development of the mobile B2B
application for the client itself can be seen as projects. Projects are unique sets of temporary
activities with a definable goal, which cut across functional lines and imply risks as well as
costs for an organisation (Nicholas and Steyn, 2012). That is why project management
methods as well as experiences from software project management case studies will take a
key role in the presented requirements elicitation approach. The study covers the following
objectives and related methods in order to reveal the client’s requirements for the project of
developing and implementing a mobile B2B application, whereas objectives and methods
build on one another:

1
Objective 1: Identifying the functional requirements of mobile B2B applications within the
food market for catering companies

 Stakeholder Analysis
 Software Benchmarking

Objective 2: Identifying the structural requirements to program and implement the

application within the current company structure and capabilities

 System Environment Analysis

 Personnel Analysis
 Risk Identification and Analysis

Objective 3: Identifying the resources requirements the client has to raise for programming,
implementing and operating the mobile B2B application

 Project Time Planning

 Life-Cycle Cost Analysis

At first, the offer will illustrate the intended relevant methods which are required in order to
reveal the particular requirements of the three objectives. Here, the methods are described
shortly, while evidences from project management background exemplify the adequacy of the
methods. Based on the introduced methods and their approximate time need, the offer will
illustrate the intended approach with the aid of a Gantt chart, providing an overview with start
and end times for the individual project steps and methods. Subsequently, the contribution of
the particular methods and the project as a whole will elucidate why the illustrated approach is
the most useful one for the company’s objectives, supported by several industry cases.
Finally, the concluding remarks will summarise the main details of the offer in order to
provide final decision guidance towards this offer.

2. Supporting Evidence – The Requirements Elicitation Approach

The general aim of the study is to provide a holistic research approach for the client, which
covers all relevant kinds of requirements in order to assess the necessities of programming
and implementing the mobile B2B application. The following chapter illustrates the
background as well as the individual processes of the particular methods.

It has to be considered that the information gathering process of all the intended methods
requires an open communicative exchange with the client. Changing client requirements or
circumstances can occur during the whole requirements elicitation process and should be
incorporated as soon as the changes are identified. Therefore, a continuous two-way
communication process with the client in the form of a permanent contact person secures
adequacy of the study (Nakatani et al., 2014). This is supported by Houdek and Pohl (2000)
who examine the requirements elicitation process of Daimler-Chrysler projects and emphasise
that over 50% of the requirements changes happen after the actual identification process.

2
2.1 Objective 1 – Functional Requirements
As already indicated, B2B applications are able to cover several functionalities, from being
just a marketing tool to comprising a whole e-procurement system including embedded sales
and payment possibilities (Al-Naeem et al., 2005). In order to provide a basis for the further
requirements analyses, the examination of the functional requirements focuses on the
questions, how the application has to look like to please the stakeholders and in which
functional direction (e.g. sales, marketing, supply-chain management, e-payment, etc.) the
application has to go. Overall, the client receives knowledge about what the market and its
key players require of the B2B application.

2.1.1 Stakeholder Analysis

Stakeholder analysis as a project management technique is widely acknowledged among
management practitioners and researchers as a part of the requirements elicitation process,
providing a broad layer of necessary information (Glinz and Wieringa, 2007; Newcombe,
2003). Stakeholders of software are persons, organisations or other groups who affect or are
affected by the software (Power, 2010). The technique tackles the questions of who the
relevant project stakeholders are, how their wants and needs look like as well as how
important they are in comparison to other stakeholders. It should be considered that each
project has its own stakeholders which may partly not be that obvious as it would appear
(Lock, 2013). All of these stakeholders have expectations for the intended software, with the
wants and the needs often being in conflict with each other (Newcombe, 2003).

The stakeholder identification process for the client happens on the basis of a brainstorming
meeting, as suggested by Calvert (1995). Here, also the client participates due to his superior
knowledge of the internal proceedings and affected groups (Pouloudi and Whitley, 1997). The
identification particularly focuses on what Sharp et al. (1999, p. 389) call ‘Baseline
Stakeholders’, which represent internal and external “users, developers, legislators and
decision-makers” with respect to the complete predicted software lifecycle. After the
identification of the relevant stakeholders, direct stakeholder communication is necessary in
order to determine their needs and requirements. This can happen through structured meetings
or personal conversations. This step ensures an understanding and involvement of the relevant
stakeholders from the beginning of the project (Passenheim, 2009). Also, the prioritisation of
stakeholders and their individual requirements are elementary steps towards stakeholder
comprehension since stakeholders are not equally important for the mobile application.
Overall, this prioritisation has to consider the strategic adjustment of the company (Glinz and
Wieringa, 2007). On the basis of these results, a final stakeholder matrix with objectives,
priorities and contributions is produced (Lock, 2013). Difficulties during the stakeholder
analysis may especially emerge in the case of hard accessibility of stakeholders as well as if
there is an individual stakeholder with diverging inner objectives (e.g. in the case of a
heterogeneous organisation) (Jepsen and Eskerod, 2009).

2.1.2 Software Benchmarking

On the basis of the stakeholder analysis, the subsequent software benchmarking examines if
there are already existing best practice examples in the market which coincide with the results
of the stakeholder analysis’ objectives. Here, the analysis especially focuses on those

3
functional requirements, which were identified by those stakeholders with the highest
prioritisation. Benchmarking describes the practice of comparing the own organisational
operations with equivalent processes of industries’ market leaders. Doing so, it is possible to
gather information and achieve an improvement of the own business operations by applying
this information (Watson, 1993). In this sense, software benchmarking can be understood as a
certain kind of focused competitive analysis which, however, also includes software
companies as well as best practice examples of comparable markets. With this form of an
external benchmarking analysis, it is possible to set the functional requirements of the client
on a level which enables him to compete with his competitors on a qualitative and
technological high level (Hines, 1998).

Since benchmarking subjects (competitors and software companies) are already set, the first
step of the software benchmarking process is the collection of data (Kodali, 2008). The data
collection process for software benchmarking as such is a qualitative one (Jones, 1995). The
information is derived on the basis of general market reports from acknowledged data bases
such as Key Note, Mintel and MarketLine as well as providers of special benchmarking
reports such as Best Practices, LLC. Furthermore, the online visibilities of software
manufacturers such as SAP, Oracle and Microsoft offer further information about their mobile
solutions for several industry segments including the food industry. Based on the gathered
data, an analysis and evaluation of the benchmarks is performed subsequently. This analysis
will compare the identified stakeholder objectives with the elaborated benchmarks in order to
set the final functional requirements which the mobile B2B application has to fulfil in order to
achieve a possible competitive advantage within the industry (Kodali, 2008). However, it also
has to be considered that benchmarking has its bottlenecks. In times of fast changing
technology, it is not taken for granted that current software benchmarks remain the same
benchmarks in the future. Hence, long-term developments have to be considered (Kumar and
Harms, 2004).

2.2 Objective 2 – Structural Requirements

After the prior techniques exposed the functional requirements of the B2B application, the
subsequent methods will focus on the question, if the client fulfils the structural requirements
to program and implement an application with such functions within the current
organisational environment. Especially IT, personnel as well as risk capacities play a pivotal
role due to their influence on the matter whether the client is able to solve respectively control
deviations and occurring risks or whether external service providers could be an alternative.

2.2.1 System Environment Analysis

The system environment analysis provides the basis for the structural requirements analysis.
Before, the stakeholder matrix with its objectives and prioritisation as well as the results of
the software benchmarking analysis revealed the functional requirements of the mobile B2B
application (Nicholas and Steyn, 2012). Subsequently, the system environment analysis has to
examine how “easy” it is to program and implement those functions within the client’s IT
system environment. This process is highly relevant for the requirements elicitation process
due to the necessity to embed the B2B application within the existing system environment
(MacLean et al., 2004). An IT infrastructure consists of interacting subsystems which are part

4
of the operative business (Singer et al., 2009). Embedding changes within such an IT
environment which involves other entities creates constraints which are relevant due to the
question whether the client is able handle these constraints (MacLean et al., 2004).

Hence, the analysis has to comprise the identification of existing systems, modules and
interfaces (before) and of necessary systems, modules and interfaces (after) between the new
mobile application and the existing system environment (Pries and Quigley, 2008).
Furthermore, it has to reveal existing IT service, security and support processes which also
have to be considered during the implementation of the B2B application. The foundation of
the system environment analysis is an interview with the responsible IT leader or respectively
the responsible application owner of the client, in order to get an overview of the related
systems. For the case that the IT processes are administered by an external provider, it might
be necessary to consult the provider as an additional information source. Also already existing
system manuals can be drawn upon to collect information (Vijayan and Raju, 2011). On basis
of the information gathering process, a before & after graphic of the IT environment is
prepared. These graphics enable an understanding of which modules are affected by the new
application and which additional interfaces respectively interface tools might be necessary to
allow an automated data exchange and, hence, an operative usage of the application (Pries and
Quigley, 2008). Analysing further needs which may be derived from the graphics will reveal
possible necessary module adoptions. Depending on which systems are affected, it is also
possible to detect which particular IT skills are needed in order to conduct these changes. This
provides the basis for the subsequent personnel analysis.

2.2.2 Personnel Analysis

After coming to know which functions need to be programmed, implemented and embedded,
and how those functions have to interact with the system environment, it is possible to
investigate which personnel resources are necessary to implement it. In order to determine the
client’s requirements, an important point is the question if the client is able to provide the
necessary personnel resources. Only if the client can provide the required employees and their
related skill sets which are needed for the development and implementation of a mobile B2B
application, a self-initiated project is executable (Project Management Institute, 2013).
Moreover, the personnel analysis has to illustrate, how the project organisation is embedded
within the organisation and how the project team itself has to be structured (Passenheim,
2009).

Training time of developers and other staff in order to acquire necessary skills can be quite
intricate, so a systematic personnel analysis which compares necessary tasks and roles with
the human capital of the client reveals the exact personnel requirements for the project (Otero
et al., 2009). In this sense, the personnel analysis depicts an actual state analysis, comparing
‘what we need’ with ‘what we have’. In this analysis, the project role planning depicts the
first step. Taking the data of the functional requirements and the system environment analysis
as a basis, necessary roles have to be defined and adjusted to the client’s project. The project
roles also have to consider and be embedded within the organisational hierarchy, reflecting
administrative as well as technical tasks (Jucan, 2013). The second major step is the actual
state analysis which takes the information gathered by the project role planning, comparing it

5
with the organisational capabilities. Here, sources are the organigram of the client, position
descriptions as well as a possible personnel data base. If required, an interview with the CEO
or HR principle could deliver further insights (Project Management Institute, 2013). Problems
could occur if the staff and skill set of the company is given, but the staffing collides with
other operational responsibilities of the client. Furthermore, it can be hard to assess the
amount of required roles for a new project with a new combination of project teams (Barreto
et al., 2008).

2.2.3 Risk Identification and Analysis

The last step of the structural requirements analysis is risk identification and analysis.
Although project risk management approaches normally contain the steps risk identification,
analysis, planning and control (Nicholas and Steyn, 2012), the objective of assessing the
structural requirements of the client to realise the project just requires the execution of the
first two points. There is a broad consensus that a conscientiously conducted risk management
approach is one of the major steps in the preparation of each project (Passenheim, 2009). Each
project contains risks which can be defined as unplanned deviations from initial objectives.
Although absolute elimination of risks is not possible, the common aim is to identify and
control them (Nicholas and Steyn, 2012). Project risks can be caused by multiple elements
and can occur at each project stage (Lock, 2013). Furthermore, they can be either based on
internal or on external factors (Maley, 2012).

The basis of the risk identification is a brainstorming meeting, which is supported by a

checklist of possible project risks, as suggested by Maley (2012). The checklist is provided by
Boehm (1991). Furthermore, experiences from prior client projects have an impact on the
identification process (Lock, 2013). This process contains each risk that may somehow have
negative consequences for the project outcome. Once identified, the risks have to be analysed
in order to allow for conclusions if the client is able to handle them. The factors risk
likelihood and risk impact play a pivotal role in assessing the project risks (Nicholas and
Steyn, 2012). Here, the analysis provides an ordinal scale (high, medium, low) for the
likelihood as well as a quantitative cost estimation for the risk impact (Maley, 2012;
Passenheim, 2009). Based on this assessment, the risks can be ranked in a matrix. Due to the
fact that the risk identification and analysis affect multiple requirements elicitation areas such
as IT, personnel, time and costs risks, the risk identification and analysis are conducted as an
overarching process (see Gantt chart). This approach enables a gapless identification,
considering the possibility that other methods also reveal additional risks.

2.3 Objective 3 – Resources Requirements

After revealing the structural requirements for implementing a mobile B2B application, it is
possible to conduct classical project management planning techniques in order to determine
the required resources the client has to raise. The necessary resources probably constitute the
most tangible kind of requirements, also because they are expressible in quantitative numbers.
Overall, this analysis unveils, how long the software engineering and implementation process
(including all necessary testing and coordination procedures) will take and which monetary
resources will be necessary to conduct the project and handle follow-up costs.

6
2.3.1 Project Time Planning
Just like each project, the client’s mobile B2B software programming project consists of
individual steps which have to be undertaken. In order to get an overview of the time the
company has to spend for the project, project time planning is an important step to reveal
temporal requirements. Especially for software engineering projects, time estimates depict a
special challenge due to the high complexity and dependency on uncertain proceedings (Lock,
2013).

The two focus points of project time planning are the manufacturing of an activity-based
network and on this basis, the drawing of a Gantt chart (Maley, 2012). The first step towards
the network is to break down the project into activities in order to provide a foundation for
estimation and scheduling activities. This step requires deeper knowledge in software
programming and testing procedures, so that experiences from managers who were involved
in software engineering projects as well as software engineering case studies support this step.
Those sources, together with published estimation data, subsequently contribute to identify
the approximate required time (Project Management Institute, 2013). Afterwards, the revealed
activities have to be put into a logical sequence. Dependencies and individual task durations
allow for drawing a network diagram, considering start times, end times and milestones
(Passenheim, 2009). More detailed planning approaches would also consider costs and
resource constraints for the individual steps, which for the scope of this study however is not
relevant (Nicholas and Steyn, 2012). In the end, the network diagram results in a detailed
Gantt chart, as introduced in chapter 3. Overall, the usage of project management software
like MS Project is elementary for a project of such complexity and helps to avoid mistakes
and secures reliability for the planning approach. Furthermore, it provides multiple options for
the client regarding layout and reports of the time planning (Zhang and Bishop, 2013).

2.3.2 Life-Cycle Cost Analysis

The second part of the resources requirements depicts the life-cycle cost (LCC) analysis. This
technique tackles the questions of how much the cumulative costs for the client will be.
Software products have differing life cycle phases with connected costs. However, many
occurring costs are not obvious without an appropriate analysis (Eckardt et al., 2014). To
determine the financial requirements of the mobile B2B application, LCC analysis appears to
be a sensible approach for the client since it not only contains relevant programming and
implementation costs, but also follow-up costs such as necessary operating, maintenance,
support and disposal costs, from the beginning to the end of the product (Nicholas and Steyn,
2012). This technique is also necessary since those costs are interrelated with each other: Cost
savings in the development and testing phase could lead to increased maintenance costs in the
operating phase (Passenheim, 2009).

LCC can already be defined in the pre-project planning phase, providing an early overview
over a long time range (Lindholm and Suomala, 2005). The LCC analysis considers five
different types of costs: direct, indirect, contingent, intangible as well as external costs
(Norris, 2001). This can for example be material, labour or overhead costs (Passenheim,
2009). The data collection process for the LCC happens with help of a bottom-up approach,
applying activity-based costing which subsequently are accumulated (Vlachý, 2014). The

7
software life cycle is separated into various phases in order to distinguish the functional stages
(Kapp and Girmscheid, 2005). The results of the project time planning and its identified tasks
provide a first insight over necessary project steps. The process is supported by an open-
source estimation software and the calculations are based on market-based prices for hourly
wages and necessary software tools (Abran, 2015). Finally, the individual costs are
accumulated, providing a statement about the costs for the whole product life-cycle. However,
the danger of LCC is a possible unreliability of data. Costs can vary over time, so that the
analysis cannot anticipate possible changes (Higham et al., 2015). Hence, the result has to be
seen more as orientation and not as hard fact. In the case of a final project implementation, the
cost estimation will become on the basis of performance experiences more detailed and exact,
improving its reliability (Passenheim, 2009).

3. Study Gantt-Chart

As introduced, all techniques are connected by individual implementation steps and exhibit
certain process durations. In order to provide an overview of the process of the consulting
project for client, consultant and stakeholders, a Gantt chart is broadly identified as a useful
tool (Locke, 2013; Nicholas and Steyn, 2012). The Gantt chart considers individual
implementation durations of the single project steps as well as their dependencies. The
dependencies are shown as “Finish-to-start” dependencies, which means that they illustrate
which steps have to be completed before the dependent and following step can begin. On the
other hand, the critical path exemplifies the order of those critical steps, which have to be
completed to finish the whole project (Maley, 2012).

The entire study is scheduled for 6 months, which depicts 26 weeks, with a kick off meeting
initiating the project. As already indicated, a continuous consultant-client communication
ensures the adequacy of the study. However, this consistent possibility for consultation does
not affect the meetings which are provided for the individual techniques. The kick-off
meeting at the beginning of the study introduces the involved and responsible persons and
presents relevant details regarding the particular project steps, as suggested by Passenheim
(2009). While the first 22 weeks are part of the data gathering process, all information and
notes will be shaped in week 23 till 25 in order to produce the study. Since risk identification
and analysis are overlapping activities which include multiple factors, further adoptions may
be made during the resource requirements analysis. In the last week, the client will receive the
final report, including a presentation with recommendations towards further actions.
Furthermore, an evaluation meeting will offer the possibility for both sides to provide
improvement feedback for following consulting projects.

Figure 1 illustrates the Gantt chart, the sequence of the particular methods, their durations and
dependencies. The task ID helps to orientate and to distribute the dependencies. While the
task itself is conducted if the cells are filled, dashed cells symbolise that the individual tasks
are ancillary processes at those points. Grey cells represent slack time, which enables the
individual process to take longer, without increasing the critical path and the maximum
duration of the project. However, due to the fact that the most processes build on one another,

8
the Gantt chart does not provide much space for slack time. However, the project times were
estimated permissively, so that there should not be any major delays:

9
 Timeframe (6 months = 26 Weeks)

Week 10

Week 14
Week 15
Week 16

Week 21
Week 22
Week 23

Week 26
Week 11
Week 12
Week 13

Week 17
Week 18
Week 19
Week 20

Week 24
Week 25
Week 1
Week 2
Week 3
Week 4
Week 5
Week 6
Week 7
Week 8
Week 9
Gantt Chart

Critical Path B K W AF AJ
Task ID Tasks Duration Dependencies
A Kick Off Meeting and Client Communication 1 Week -
B Objective 1 - Functional Requirements 7 Weeks A
C Stakeholder Mapping 4 Weeks A
D Stakeholder Identification 1 Week A
E Stakeholder Meetings/ Conversations 1 Week A,D
F Stakeholder Priorisation 2 Weeks A,D
G Stakeholder Matrix (incl. Prioritisation and Objectives) 1 Week A,D,E,F
H Software Benchmarking 3 Weeks C
I Data Collection Process 1 Week C
J Benchmark Analysis 2 Weeks C,I
K Objective 2 - Structural Requirements 8 Weeks B
L System Environment Analysis 3 Weeks B
M Interview with the IT Leader/ Application Owners 1 Week B
N Producing of IT Environment Graphics 2 Weeks B,M
O Need Analysis 1 Week B,M,N
P Personnel Analysis 3 Weeks L
Q Project Role Planning (Which roles are necessary?) 2 Weeks L
R Actual State Analysis (Does the company has the staff?) 1 Week L,Q
S Risk Identification and Analysis 8 Weeks B
T Risk Identification 4 Weeks B
U Risk Evaluation 3 Weeks B,T
V Risk Ranking (Matrix) 2 Weeks B,T,U
W Objective 3 - Resources Requirements 7 Weeks K
X Project Time Planning 3 Weeks K
Y Project Break Down and Time Estimation 2 Weeks K
Z Draw Network Diagram 1 Week K,Y
AA Draw Gantt Chart 1 Week K,Y,Z
AB Life-Cycle Cost Analysis 4 Weeks X
AC Analysing Types of Costs and Necessary Activities 2 Weeks X
AD Data (Cost) Collection for Revealed Activities 2 Weeks X, AC
AE Cost Accumulation 1 Week X,AC,AD
AF Producing the Study 3 Weeks B,K,W
AG Recommendations 2 Weeks B,K,W
AH Study Submission 1 Week B,K,W,AF,AG
AI Presentation of the Results 1 Week B,K,W,AF,AG
AJ Evaluation Meeting 1 Week B,K,W,AF,AG

Key:
Slack Time
Ancillary Process

Figure 1 – Study Project Gantt Chart (Own Figure)

4. Contribution

After receiving an overview of the techniques and procedure of the study, the following
chapter will in detail deal with the question of how the individual techniques contribute to the
identified objectives and the overall aim of exposing all requirements for programming and
implementing a mobile B2B application. Evidences from industry and software case studies
are combined with insights researchers gained while using or investigating the particular
techniques.

Overall, the client will obtain all necessary information which helps him to determine a
picture of the project’s requirements from this approach. Furthermore, the client receives a
holistic and scientific approach, providing detailed insights about potentials and possibilities
for future IT projects within the company. Consequently, the client will be able to make
further relevant decisions regarding the project. If the revealed functional, structural and
resources requirements do not fit to the capabilities of the client, outsourcing the project could
be a possibility. However, if the study shows that undertaking the project is within the
capabilities of the client, the study already provides the first step of the project planning and
requirements elicitation phase, saving time and money for the client.

4.1 Stakeholder Analysis

Regarding the stakeholder analysis, Pacheco and Garcia (2012) point out that identification
and understanding of stakeholders is critical for the requirements elicitation process and for
the subsequent quality of the software. Only through the identification of all relevant
stakeholders, software can fulfil sufficiently its value-based requirements (Babar et al., 2015).
Applying a stakeholder analysis approach at a company which introduced an e-procurement
system, Pan (2005) points out that understanding stakeholders and their objectives is crucial
in order to avoid abandonment of information systems development projects. According to
Kaur and Sengupta (2011), IT projects with a lack of user involvement can lead to a lack of
commitment and a declining project support which is necessary for a successful project.

According to Vrhovec et al. (2015), stakeholder analysis before undertaking software projects
is also strongly connected to the risk identification and analysis process due to the
concomitant problems in the case of ignoring stakeholder needs. Based on a case study of an
application development in the banking sector, they point out that especially the IT
personnel’s understanding of the appropriate business process and the clear communication
among stakeholders are of particular importance. Also Rost and Glass (2009) emphasise the
impact of stakeholders on project risks, emphasising the need to analyse and assess them. Due
to the coverage of all relevant market participants such as users, programmers and customers,
a conscientious conducted stakeholder analysis in interaction with software benchmarking
makes a market analysis redundant.

4.2 Software Benchmarking

The fact that several software manufacturers already offer mobile B2B applications for
several industries and business segments, illustrates that a software benchmarking analysis
strongly contributes to the objective of revealing which functionalities are required and
appropriate for a certain industry (Tornack et al., 2011). Overall, examining and adapting
software best practices can help companies to succeed in high competitive markets such as the
B2B food market (Ojala and Tyrväinen, 2008).

Investigating its application in France, Maire et al. (2005) find that 50% of the examined
companies use benchmarking regularly in order to find best practices with the aim of
improving IT processes. Applying benchmarking theoretically and practically on the
requirements elicitation process of a website development project, Pang et al. (2009) illustrate
that benchmarking is a useful tool in order to assess IT-based requirements. In the context of
project management, Loo (2003) successfully applies benchmarking for technical aspects,
proving the suitability of benchmarking for complex projects. Especially regarding the
objective of revealing the functional requirements of the client’s mobile B2B application,
benchmarking is able to provide valuable industry insights of already existing and adopted
software. This fills the gap between those functional requirements already detected in the
stakeholder analysis, and the functional requirements which are necessary for a practical
implementation.

4.3 System Environment Analysis

Regarding the application of the system environment analysis it has to be considered that this
is not a classic technique used in software project management. However, considering the
particular case of the client, the system environment analysis allows for conclusions about the
subsequent personnel and risk analysis since a different IT environment requires a different
need for staff and skill sets of the personnel and leads to different risks. Furthermore, practical
implementations within several industry cases show its suitability regarding exposing
structural IT requirements.

Charette (2005) summarises multiple failed software projects of small and large companies,
with the result that IT problems as well as inadequate adaptions were responsible for a large
part. Those problems can lead to foregone profits which can also be prevented by a focused
analysis of the IT infrastructure of the client. Moreover, the system environment analysis
allows further conclusions regarding the requirements of the IT security, service management
and risk management which is supported by the case of a Greek software company
undertaking implementation projects at clients (Maroukian, 2010). Also Byrd and Turner
(2000) emphasise the IT infrastructure’s key role for the users (personnel) on the one hand
and for further developments on the other hand in a broad-based study. This coincides with
the introduced approach, which provides the system environment analysis to be a foundation
of the subsequent personnel analysis.

4.4 Personnel Analysis

The personnel analysis is highly recommended since developing, implementing and
maintaining software is a people intensive task, not only regarding developers, but also for
project managers, testers, administrative or maintenance staff (Barreto et al., 2008). Hence,
only a focused analysis can illustrate the personnel requirements, the client will have to face.
Also Firesmith (2004) emphasises that a case-based requirements elicitation approach always
has to consider the scope and, hence, the required staffing. This especially concerns the client,
who exhibits as an SME much tighter personnel resources as for example a multinational
company.

Furthermore, Park et al. (2015) emphasise that planning and allocation of human resources
and especially of developers during software projects to certain tasks and responsibilities
depicts a necessity in order to handle time issues and to estimate the workload per employee.
Hence, possible bottlenecks can be revealed before they occur. For the client, the personnel
analysis depicts an elementary step in order to decide whether outsourcing the project or
hiring external freelancers may be a sensible possibility. In the case of minor expertise gaps
respectively shortages, freelancers could fill these gaps (Wu and Zmud, 2010).

4.5 Risk Identification and Analysis

Especially for the client, who intends to enter an unknown area with a new product, risk
identification and analysis appears particularly important due to the high risk susceptibility of
IT projects (Lock, 2013). The risk identification and analysis is crucial in order to classify the
elaborated requirements and to assess if the client is able to handle the risks alone. This is
supported by multiple cases: Applying a holistic risk management framework for a software
engineering project in the Barbados government sector, Dey et al. (2007) point out that risk
identification and analysis at the beginning of a software project depicts a necessity for
ensuring a clear risk understanding and comprehension of which actions may be required to
control those risks. According to Baccarini et al. (2004), who undertook interviews with
leading IT experts, IT projects provide a large range of possible risks, especially regarding
personnel, scheduling and budget. The introduced methodology considers this fact with
respect to the implementation of an overlapping risk approach. Moreover, several examples of
failed IT projects can be associated with missing or insufficient risk management, such as in
the cases of “American Airlines AMR Information Services (AMRIS)” or the “London Stock
Exchange’s Transfer and Automated Registration of Uncertified Stock (TAURUS) system”
(Baccarini et al., 2004, p. 286). Hence, it is of particular importance for the client to receive
an overview of the risks and required countermeasures in order to assess the capabilities the
firm has to raise to handle the risks.

4.6 Project Time Planning

In order to assess the resources requirements, project time planning plays a crucial role for
companies due to multiple problems which occur with time: Bottlenecks and inaccurate time
estimates can cause time pressure and even late delivery, which also negatively affects the
project costs (Hazzan and Dubinsky, 2007). Providing several examples of failed IT projects,
Charette (2005) illustrates the necessity of an appropriate project time planning technique for
the appropriate estimation of temporal requirements. Although IT project estimation often is
not an exact science, scheduling is a step towards less uncertainty.

Examining the adoption of time planning approaches for software projects, Verner et al.
(2007) find out that unreasonable time planning goes along with inadequate requirements
engineering, leading to rising time risks, while the failure of many projects can be derived by
those events. Hence, a conscious analysis with reasonable time estimation can prevent the
client from wrong time assessment, occurring risks and connected losses.

4.7 Life-Cycle Cost Analysis

Regarding the project requirements, costs often are a major reason for or against
implementation (Passenheim, 2009). Applying LCC in an engineering project, Vlachý (2014)
proves that LCC is a very comprehensive and detailed technique regarding assessing a
company’s product costs till the end of the product life cycle, especially when the technique is
already applied in the product conception phase. The assistance of LCC for the strategic
decision-making depicts a major advantage of the technique (ibid.). This coincides with the
advantages of the intended implementation: Through the presented approach it is possible to
derive essential strategic conclusions for the later realisation of the project, especially
regarding the question if the company is able to raise the required resources.

Investigating several industry cases about the adoption of LCC, Korpi and Ala-Risku (2008)
point out that the technique is particularly popular due to its provided insights concerning
long-term affordability which makes it superior in comparison to other cost estimation
techniques. Also Chikofsky and Cross (1990) underline the fact that LCC reduces a lot of
uncertainty for software projects by revealing hidden costs. This is of particular importance
for SMEs which come not from an IT background due to possible lacks in estimating software
costs.

5. Concluding Remarks

Overall, the offer provides a holistic approach to reliably reveal different kinds of project
requirements which are of particular interest for the client. This holistic approach is based on
acknowledged and approved methods, which offer detailed application instructions on the one
hand, and hints regarding possible problems on the other hand. It has to be considered that the
introduced approach is adapted to the individual case of the client and his specific
requirements, so that the client receives a study which perfectly fits his needs. Especially the
presented experiences of prior software engineering projects demonstrate the appropriateness
and validity of the techniques to examine the introduced objectives and, hence, the client’s
multiple requirements of daring the development of a mobile B2B application. For the case of
changes or enhancements in the client’s requirements, the close communication process
during the study ensures optimal customisation of the gathered information. Furthermore, the
client is, with the help of the Gantt-chart, always able to identify at which point in the study
he is located at the moment.

Due to the information the client receives from the study and the final presentation about the
pivotal results, he will be able to make the important decision whether it is more sensible to
buy the mobile application or to build and implement it in-house (“build or buy”) (Cortellessa
et al., 2008). This decision can be derived by the results of all conducted analyses, which
reveal if the client has the required knowledge, structure and resources to build the application
on his own while being able to handle the risks. In order to provide a guideline for this
decision, the provided study concludes with valuable recommendations for further actions.
I. References
Abran, A. (2015), Software project estimation: the fundamentals for providng high quality
information to decision makers. Hoboken, New Jersey: Wiley.

Al-Naeem, T., Rabhi, F.A., Benatallah, B. and Ray, P.K. (2005), “Systematic Approaches for
Designing B2B Applications”, International Journal of Electronic Commerce, Vol.9(2),
pp. 41-70.

Azadegan, A., Cheng, X., Yin, G. and Niederman, F. (2013), “Collaborative Requirements
Elicitation in Facilitated Collaboration: Report from a Case Study”, 46th Hawaii
International Conference on System Sciences, pp. 569-578.

Babar M.I., Ghazali M., Jawawi D.N.A. and Zaheer, K.B. (2015), “StakeMeter: Value-Based
Stakeholder Identification and Quantification Framework for Value-Based Software
Systems”, PLoS ONE, Vol.10(3), pp. 1-33.

Baccarini, D., Salm, G. and Love, P.E.D. (2004), “Management of risks in information
technology projects”, Industrial Management & Data Systems, Vol.104(4), pp. 286-295.

Barreto, A., Barros, M. and Werner, C.M.L. (2008), “Staffing a software project: A constraint
satisfaction and optimization-based approach”, Computers & Operations Research,
Vol.35, pp. 3073-3089.

Boehm, B.W. (1991), “Software Risk Management: Principles and Practices”, IEEE
Software, Vol.8(1), pp. 426-435.

Byrd, T.A. and Turner, D.E. (2000), “Measuring the Flexibility of Information Technology
Infrastructure: Exploratory Analysis of a Construct”, Journal of Management Information
Systems, Vol.17(1), pp. 167-208.

Calvert S. (1995), “Managing stakeholders”, in: Turner, J.R. (ed.), The commercial project
manager. Maidenhead: McGraw-Hill, pp. 214-222.

Charette, R.N. (2005), “Why Software Fails”, IEEE Spectrum [Online].

URL: http://spectrum.ieee.org/computing/software/why-software-fails
(Accessed: 13.04.2016).

Chikofsky, E.J. and Cross, J.H. (1990), “Reverse Engineering and Design Recovery: A
Taxonomy”, IEEE Software, Vol.7(1), pp. 13-17.

Cortellessa, V., Marinellia, F. and Potena, P. (2008), “An optimization framework for “build-
or-buy” decisions in software architecture”, Computers & Operations Research, Vol.35,
pp. 3090-3106.

Dey, P.K., Kinch, J. and Ogunlana, S.O. (2007), “Managing risk in software development
projects: a case study”, Industrial Management & Data Systems, Vol.107(2), pp. 284-303.
Dvir, D., Raz, T. and Shenhar, A.J. (2003), “An empirical analysis of the relationship between
project planning and project success”, International Journal of Project Management,
Vol.21, pp. 89-95.

Eckardt, J.R., Davis, T.L., Stern, R.A., Wong, C.S., Marymee, R.K. and Bedjanian, A.L.
(2014), “The Path to Software Cost Control”, Defense AT&L, November–December 2014,
pp. 23-27.

Firesmith, D.G. (2004), “Creating a Project-Specific Requirements Engineering Process”,

Journal of Object Technology, Vol.3(5), pp. 31-44.

Glinz, M. and Wieringa, R.J. (2007), “Stakeholders in Requirements Engineering”, IEEE

Software, Vol.28, pp. 18-20.

Hazzan, O. and Dubinsky, Y. (2007), “The Software Engineering Timeline: A Time

Management Perspective”, IEEE International Conference on Software – Science,
Technology and Engineering, pp. 95-103.

Higham, A., Fortune, C. and James, H. (2015), “Life cycle costing: evaluating its use in UK
practice”, Structural Survey, Vol.33(1), pp. 73-87.

Hines, P. (1998), “Benchmarking Toyota’s supply chain: Japan vs UK”, Long Range
Planning, Vol. 31(6), pp. 911-918.

Houdek, F. and Pohl, K. (2000), “Analyzing requirements engineering processes: A case

study”, Proc. of the 11th International Workshop on Database and Expert Systems
Applications (DEXA’00), pp. 983-987.

Jepsen, A.L. and Eskerod, P. (2009), “Stakeholder analysis in projects: Challenges in using
current guidelines in the real world”, International Journal of Project Management,
Vol.27, pp. 335-343.

Jones, C. (1995), “Software Benchmarking”, Computer, Vol.28(10), pp. 102-103.

Jucan, G. (2013), “People in Senior Project Roles”, in: Lock, D. and Scott, L. (eds.), The
Gower Handbook of People in Project Management. Farnham: Gower.

Kapp, M.J. and Girmscheid, G. (2005), “Risk based life cycle cost analysis model for
comparable life cycle project delivery decision taking”, in: Collaboration and
Harmonization in Creative Systems. London: Taylor & Francis, pp. 895-901.

Kaur, R. and Sengupta, J. (2011), “Software Process Models and Analysis on Failure of
Software Development Projects”, International Journal of Scientific & Engineering
Research, Vol.2(2), pp. 1-4.

Kodali, G.A.R. (2008), “Benchmarking the benchmarking models”, Benchmarking: An

International Journal, Vol.15(3), pp. 257-291.

Korpi, E. and Ala-Risku, T. (2008), “Life cycle costing: a review of published case studies”,
Managerial Auditing Journal, Vol.23(3), pp. 240-261.
Kumar, S. and Harms, R. (2004), “Improving business processes for increased operational
efficiency: a case study”, Journal of Manufacturing Technology Management, Vol.15(7),
pp. 662-674.

Lindholm, A. and Suomala, P. (2005), “Learning by costing: sharpening cost image through
life cycle costing?”, 7th Manufacturing Accounting Research Conference, Tampere,
Finland, 30.May – 1.June.

Lock, D. (2013), Project Management. 10th ed., Farnham: Gower Publishing Ltd.

Loo, R. (2003), “A multi-level causal model for best practices in project management”,
Benchmarking: An International Journal, Vol.10(1), pp. 29-36.

MacLean, R., Stepney, S., Smith, S., Tordoff, N., Gradwell, D., Hoverd, T. and Katz, S.
(2004), Analysing Systems: determining requirements for object oriented development.
Hemel Hempstead: Prentice Hall International.

Maire, J.-L., Bronet, V. and France, A. (2005), “A typology of best practices for a
benchmarking process”, Benchmarking: An International Journal, Vol.12(1), pp. 45-60.

Maley, C.H. (2012), Project management concepts, methods, and techniques. Boca Raton,
Fla.: CRC Press.

Maroukian, K. (2010), “IT Project Environment Factors Affecting Requirements Analysis in

Service Provisioning for the Greek Banking Sector”, Journal of Software Engineering &
Applications, Vol.3, pp. 858-868.

Nakatani, T., Hori, S., Katamine, K., Tsuda, M. and Tsumaki, T. (2014), “Estimation of the
Maturation Type of Requirements from Their Accessibility and Stability”, IEICE
Transactions on Information and Systems, Vol.97(5), pp. 1039-1048.

Newcombe, R. (2003), “From Client to Project Stakeholders: A Stakeholder Mapping

Approach”, Construction Management and Economics, Vol.21, pp. 841-848.

Nicholas, J.M. and Steyn H. (2012), Project management for engineering, business and
technology. 4th ed., London: Routledge.

Norris, G.A. (2001), “Integrating life cycle cost analysis and LCA”, The International
Journal of Life Cycle Assessment, Vol.6(2), pp. 118-120.

Ojala, A. and Tyrväinen, P. (2008), “Best practices in the Japanese software market”, Global
Business & Organizational Excellence, Vol.27(2), pp. 52-64.

Otero, L.D., Centeno, G., Ruiz-Torres, A.J. and Otero, C.E. (2009), “A systematic approach
for resource allocation in software projects”, Computers & Industrial Engineering, Vol.56,
pp. 1333-1339.

Pacheco, C. and Garcia, I. (2012), “A systematic literature review of stakeholder

identification methods in requirements elicitation”, The Journal of Systems and Software,
Vol.85, pp. 2171-2181.
Pan, G.S.C. (2005), “Information systems project abandonment: a stakeholder analysis”,
International Journal of Information Management, Vol.25, pp. 173-184.

Pang, M.-S., Suh, W., Kim, J. and Lee, H. (2009), “A Benchmarking-Based Requirement
Analysis Methodology for Improving Web Sites”, International Journal of Electronic
Commerce, Vol.13(3), pp. 119-162.

Park, J., Seo, D., Hong, G., Shin, D., Hwa, J. and Bae, D.-H. (2015), “Human Resource
Allocation in Software Project with Practical Considerations”, International Journal of
Software Engineering and Knowledge Engineering, Vol.25(1), pp. 5-26.

Passenheim, O. (2009), Project Management. Copenhagen: Bookboon.

Pouloudi, A. and Whitley, E.A. (1997), “Stakeholder identification in inter-organizational

systems: gaining insights for drug use”, European Journal of Information Systems,
Vol.6(1), pp. 1-14.

Power, K. (2010), “Stakeholder Identification in Agile Software Product Development

Organizations”, Agile Conference, August 2010, pp. 87-94.

Pries, K.M. and Quigley, J.M. (2008), Project Management of Complex and Embedded
Systems Ensuring Product Integrity and Program Quality. Hoboken: Taylor and Francis.

Project Management Institute (2013), “A Guide to the Project Management Body of

Knowledge (PMBOK Guide)”, Newtown Square, Pa.: Project Management Institute.

Rost, J. and Glass, R.L. (2009), “The Impact of Subversive Stakeholders on Software
Projects”, Communications of the ACM, Vol.52(7), pp. 135-138.

Sharp, H., Finkelstein, A. and Galal, G. (1999), “Stakeholder identification in the

requirements engineering process”, Proceedings of 10th International Workshop on
Database & Expert Systems Applications (DEXA), pp. 387-391.

Singer, L., Brill, O., Meyer, S. and Schneider, K. (2009), “Utilizing Rule Deviations in IT
Ecosystems for Implicit Requirements Elicitation”, Second International Workshop on
Managing Requirements Knowledge (MaRK'09).

Smilansky, O. (2015), “Third-Party Power: The Rise of the B2B App Store”, CRM Magazine,
Vol.19(11), pp. 28-31.

Tornack, C., Christmann, S. and Hagenhoff, S. (2011), “Tendenzielle Unterschiede zwischen

B2B und B2C-Anwendungen für mobile Endgeräte”, University of Goettingen, Chair of
Application Systems and E-Business, Working Paper No. 3/2011.

Verner, J.M., Evanco, W.M. and Cerpa, N. (2007), “State of the practice: An exploratory
analysis of schedule estimation and software project success prediction”, Information and
Software Technology, Vol.49, pp. 181-193.

Vijayan, J. and Raju, G. (2011), “A New approach to Requirements Elicitation Using Paper
Prototype”, International Journal of Advanced Science and Technology, Vol. 28, pp. 9-16.
Vlachý, J. (2014), “Using Life Cycle Costing for Product Management”, Management,
Vol.19(2), pp. 205-218.

Vrhovec S.L.R., Hovelja, T., Vavpotič, D. and Krisper, M. (2015), “Diagnosing

organizational risks in software projects: Stakeholder resistance”, International Journal of
Project Management, Vol. 33, pp. 1262-1273.

Watson, G.H. (1993), Strategic Benchmarking: How to Rate Your Company’s Performance
Against the World’s Best. New York: Wiley.

Wu, W.W. and Zmud, R.W. (2010), “Facing the Challenges of Temporary External IS Project
Personnel”, MIS Quarterly Executive, Vol.9(1), pp.13-21.

Zamfiroiu, A. (2015), “Factors Influencing the Quality of Mobile Applications”, Informatica

Economică, Vol.18(1), pp. 131-138.

Zhang, Y. and Bishop, C. (2013), “Project-Management Tools for Libraries: A Planning and
Implementation Model Using Microsoft Project 2000”, Information Technology and
Libraries, Vol.24(3), pp. 147-152.

Zowghi D. and Coulin C. (2005), “Requirements Elicitation: A Survey of Techniques,

Approaches, and Tools”, in: Engineering and Managing Software Requirements. Berlin:
Springer, pp. 19-46.