Determining the requirements of a mobile B2B

application.
By Itai Madzivanyika
Abstract

The developments in Information and Communications Technology (ICT) brought many

concomitant benefits. Amongst them the use of mobile commerce. The developments in this
sector has been unprecedented. It has revolutionised the way business is done by using pocket
size mobile devices to do purchases on the go. This has become the next big thing in
manufacturing and distribution. This form of technology has existed long in the Business to
Community (B2C) realm than it has in the (Business to Business) B2B setup. The easy of
doing business which has accrued from the use of mobile commerce in B2C can be exploited
similarly in B2B solutions bringing convenience of anytime, anywhere purchasing,
affordability of mobile devices compared to desktop computers and laptops, faster speed of
transacting, extra capabilities in mobile devices such as stronger computing power, global
positioning systems, high resolution cameras and the sheer volumes due to time spend using
mobile devices. This study seeks to outlay the requirements which are needed in coming
with a start-up mobile application for use in a B2B setup. It will come up with the functional
requirements (identified through stakeholder mapping and software benchmarking) which
satisfy the user needs, system requirements (environmental analysis, risk mapping and
personnel analysis) which is the organisation preparedness to meet the functional
requirements. The report finally looks at the resource requirements (project time planning
milestones and resources Gantt chart and project life cycle analysis) needed in the
development of mobile application. It will conclude on the real life examples on the
contribution of this study.

ii | P a g e
Contents
1.0 Background and Project Objectives.....................................................................................1
2.1 Objective 1 - Functional requirements.................................................................................3
2.1.1 Stakeholder Mapping....................................................................................................3
2.1.2 Software Benchmarking................................................................................................4
2.2 Objective 2 - Structural requirements..................................................................................5
2.2.1 System Environmental Analysis...................................................................................5
2.2.2 Personnel Analysis........................................................................................................6
2.2.3 Risk Mapping................................................................................................................6
2.3 Objective 3 - Resource requirements...................................................................................7
2.3.1 Project Time Planning...................................................................................................7
2.3.2 Life Cycle Cost Analysis..............................................................................................8
3.0 Gantt Chart Method..............................................................................................................9
3.1 Project Gantt chart..........................................................................................................10
4.0 Contribution.......................................................................................................................11
4.1 Stakeholder Analysis......................................................................................................11
4.2 Software Benchmarking.................................................................................................11
4.3 System Environmental Analysis....................................................................................12
4.4 Personnel Analysis.........................................................................................................12
4.5 Risk Identification and Analysis....................................................................................13
4.6 Project Time Planning....................................................................................................13
4.7 Life Cycle Cost Analysis...............................................................................................14
5.0 Conclusion..........................................................................................................................15
References................................................................................................................................16

iii | P a g e
1.0 Background and Project Objectives
Global internet users’ statistics show that about 86% use smartphones
(business2community.com, 2019). About 90% of the internet users use smartphones for
internet access due to their lower cost and affordability than desktop computers and laptops.
The advanced developments in smartphones come with extra capability in terms of
computing power (stronger processors, high resolution cameras, GPS, fast internet
connectivity through Wi-Fi) (Canfora et al, 2013; Lu et al, 2012) supported in Zein et al
(2016); Zabra, Khalid and Javed 2013). The sheer growth numbers and capabilities come
with concomitant benefits which can be profited from (eMarketer .com). This has seen the
use of mobile application growing astronomically. Mobile applications has become numerous
to choose such that coming up with presents a formidable challenge. Organisations using
such applications on this age of internet of things can increase the customer experience by
leveraging on the following advantages that come with the used of mobile commerce.

1. Facilitating effective communication.

2. Offering competitive advantage
3. Creating customer loyalty
4. Increased brand prominence and visibility.
5. Incremental sales advantage
6. Enhancing customer engagement (business2community.com, 2019)

Whilst mobile app development is a growing phenomenon which can make or break a
business it comes with own challenges in developing a solution that addresses the market
need (Gotter 2019; Zahra, Khalid and Javed 2013; Yang et al 2013). To realise the benefits
that accrue from the use of this trending technology, there is need for organisations to invest
in management training, scoping of the best application to use, market elicitation of the
features that come with such apps, testing of the application before full use and a sound field
support system infrastructure and human resources capability for this intellectual intensive
technology. Successful application comes from a scoping study of what the application is
supposed to accomplish and testing in a market acceptance test before full launch. Various
models have been proposed for soliciting the functional, system and resource objectives for
mobile app. The scope of each of the objectives is summarised below.

The objectives of this scoping project is to come up with functional, structural and resource
objectives. The functional requirements of the mobile application for the catering business
are elicited through stakeholders analysis and benchmarking with market related software.

1|Page
Functional requirements are a gap audit assessing the state of preparedness of the
organisation in meeting the mobile app users for the catering business. The functional
requirements are solicited through systems environmental analysis, human resource and
analysis. Lastly the resources requirements are ascertained through project time planning and
life cycle cost analysis.

This scoping study will delve into background theory behind all the requirements needed to
come up with B2B application through supporting evidence from scholarly, seminary as well
as mobile commerce industry which I learnt throughout the business administration course.
After the supporting evidence the scoping study will come up with a project time plan
illustrated through the use of a Gantt chart. Work Breakdown Structure (WBS) which is
pivotal in splitting the tasks into manageable tasks. Project management software will be used
to come up with a Gantt chart of the works illustrating the use of dependencies, slack leading
to determination of the critical path of the project. Critical analysis using life examples will
be covered in Chapter 4 giving the contribution which the scoping study is giving to the
project. The report will be concluded in chapter 5 by summarising the key findings and ways
the analysis can further be improved upon.

2|Page
2.1 Objective 1 - Functional requirements
B2B is a mobile commerce technology through the use of personal document assistant
(PDAs) devices which enable the integration of business functionalities in real time. It
enables information sharing in “ad hoc” terms and reduces duplication of efforts for example
an invoice benefits the end user as well as the business where the purchase has been made
from. The collation of the purchase patterns if stored in a computer databases can be used for
inference on the customers the organisation has. (Behkamal et al 2008, p.600). To come up
with functional requirements of such application software there are important functional
requirements to be met which are: the application features, how the application is to look like
to satisfy the customer and the business goals to be realised by the organisation in using the
application.

2.1.1 Stakeholder Mapping

One of the key enablers to delivering customer value is to understand the key stakeholders
who are affected by a business undertaking. This will enable programs to be developed which
address the needs of the stakeholders resultantly delivering superior customer value than that
of the competitors. Smith, Drumwright and Gentile (2009); McLeod and MacDonell (2011);
Paetsch, Eberlein and Maurer (2003) summarise the key components to understanding the
requirements of a customer through five major points which are; identifying the company’s
stakeholders, researching stakeholder issues, expectations and measuring the impact
stakeholders have to the organisation’s operations, ranking stakeholder needs according to
importance and engaging and embedding a stakeholder orientation.

Mobile apps are for use by a wide pool of people who have various expectations which can
be very difficult to solicit. However, there are several methods which can be used to elicit the
functional requirements of the mobile app to the users. Paetsch, Eberlein and Maurer (2003),
Boehm (2003) highlight the methods that can be used to elicit requirements which are;
interviews, use of case scenarios, brainstorming, use of focus groups, observation, social
analysis and prototyping. Interviews can be closed or open ended which provides a rich
source of user requirements. However, the qualitative data can result in conflicting
requirements which are difficult to analyse (Paetsch et al 2003). Case scenarios solicitation
technique can be used in the early stages to map the various scenarios which are intended to
be used by the users. It gives an insight into the system state before and after executing a
particular case. It is a way to simulate the interaction of the application with the external
environment. Brainstorming is another rich source of insights into the user requirements.
There are two stages to the process which are generation and evaluation phases. In the
generation phase all ideas including the odd requirements are generated. For a mobile app
were the users can be far and wide, crowd sourcing has emerged as a cheaper method for
sourcing information. It represents the requirements which mimic the intended market for the
product. This can be used throughout the life cycle of the product as it provides a cheaper
way to gets the insights of the potential and actual users and how their perceptions of the

3|Page
product vary with time. (Mahmoud et al 2013). Evaluation phase then sifts the data into
refined user requirements.

Lifelong adaptation to ever changing requirements happens to dynamic requirements.

Implying users are continuously validating the ability of software to meet requirements.
Feedback from software users can provide an assessments into the changes that can be
incorporated into future releases of the software as supported by Paetsch, Eberlein and
Maurer (2003); Mahmoud et al (2003); Boehm (2003); Alexander and Robertson (2004). In
other instances the functional requirements can be identified through identifying few
stakeholders who in turn can recommend other stakeholders for identification of functional
requirements. This is based on the premise that stakeholders operate in social networks.
Identifying a few stakeholders sets a precedent to meeting more stakeholders through peer
recommendation. It can also provide a shared group meaning of the functional requirements
of the application (Paetsch, Eberlein and Maurer 2003).

2.1.2 Software Benchmarking

Stakeholder engagement above seeks to come with the functional requirements for the
application to satisfy user requirements for the B2B app. It is an important step to map the
needs of the end user. However, the development of this application in most instances is in a
market where there are already service providers using similar applications. To come up with
business goals that match or exceed current market offering the requirements which need to
be incorporated into the application can be elicited through comparing with market best
practises. This process is called benchmarking (Rolstadås 2013). Benchmarking data can be
found from industry reports, manuals, business reports from Mintel, Forbes and e-Marketer
(Sim et al 2009; Pang et at 2009).

The development of the mobile application is a corporate strategy to improve the company
competitiveness. It therefore looks on the internal as well as functional aspects for the
business. (Daneva 1995; Maneva, Daneva and Petrova 1995). The IT department compares
the internal capabilities with the market leaders and they come up with ways to improve
capabilities on a continuous basis. To the whole organisation it looks at the efficiencies and
effectiveness of the support functions in meeting the catering trade B2B app customers’
needs. The organisation’s development provider seeks to uncover the bottlenecks and
optimise the mobile application user functions. To be useful as a software benchmarking
product the following criteria is used; appropriateness in meeting the customer needs,
functional scope such as use as e-invoicing, purchasing or marketing, reproducibility (ability
to be produce similar one), interpretability (intended use can be decoded), user friendliness
and understandability (Daneva 1995). The steps which can be followed in benchmarking a
B2B application which are; stating the goal through functional requirements, identifying the
constraints which can be skills or financial resources, selecting competitors who are in the
same industry, specifying the software benchmarks (for example the features incorporated,

4|Page
size, runtime speed), developing a measurement plan, interpreting the results, validating the
benchmark and comparing the software products.

2.2 Objective 2 - Structural requirements

The structural requirements seeks to identify the organisation’s capability in handling the
development process of the functional objectives discussed above for business application.
This is especially crucial to the organisation’s IT department which are there to fulfil the
functional requirements. The structural analysis is a gap audit on the current capabilities of
the organisation on the functions which they are able to meet internally and those they will
need to outsource. Therefore the structural requirements is to see how the organisational
structure will enhance the project.

2.2.1 System Environmental Analysis

In defining the system requirements the goal is to assess the current IT system which can
integrate the addition of the new mobile application. This include the current IT infrastructure
in place to handle the new B2B application. The functional requirements will assess the
current IT infrastructure currently in use and their suitability, compatibility and integration of
the mobile application and possibility of the changes in hardware which will still be able to
run the application. The system requirements also identifies the programming language to be
used. It entails the identification of the program domain to be used, the subcategories of the
software domain and additional modules to improve the functionality of the mobile
application software (Franch and Carvallo; Fahmy at al 2012). In identifying the system
requirements there are also support functions to manage the use of mobile application during
and after the life cycle of the software use which include system security, assistance and the
necessary IT skills to effect this support.

There is also need to manage the risks associated with using the software. This can be
identified through risk assessment and control. According to Boehm (1991 and 1997)
software risk assessment requirements has evolved over the years. It involves primary steps
of risk identification, analysis and prioritisation. Risk identification identifies project risks
that are likely to affect the success of the project (Boehm 1991, p.427; Boehm 1997, p.19).
Statistical techniques, cost models, network models and decision analysis are some of the
techniques used in analysis of risks. Risk prioritisation produce a ranking of the analysed
risked. The risk then can be controlled through risk resolution and monitoring.

The functionality requirements of the application, the programming required and how it will
be deployed need human capital support for implementation. This is addressed through
personnel analysis on the current internal capabilities in carrying out the project. This can be
accomplished through consultations with HR to understand that the will be no conflicting
roles. Personnel requirements imply the client is able to solve control deviations and

5|Page
occurring risks or whether external service providers through the life cycle of the project
(Boehm 1991). The gap analysis will identify what the client will be able to accomplish with
the current human resource base and outsourcing needed for the capabilities beyond the
organisation’s capability. It will identify the internal training needed in managing the project
for its fruition. Technical tasks will be differentiated from admin tasks.

2.2.2 Personnel Analysis

For the organisation to meet the client functional requirements human resource capital is
needed to manage the project to success. Whilst some of the employees are there to oversee
the translation of the client needs into functional requirements there are some who are tasked
to meet the administrative needs of the project. The crucial step is to come up with the human
resource requirements and capability audit to assign the people who can be assigned to
additional tasks which are not part of the organisation’s daily tasks. This can be done through
meeting the HR and organisation heads who have an understanding of the human resource
capabilities of the available personnel (Zhou 2008; IPM 2013) Assessment and matching of
the tasks involved is a crucial step in project management to meet the client needs. According
to Tausworthe (1979); Zhou (2013) Globerson (1994) a work breakdown structure (WBS)
presents a way to break down the tasks into manageable milestones which aids in cost
analysis, assessments of milestones as well as internal and external assignments of tasks
depending on organisational capability. Since the organisation has limited organisational
capability in the development of the application the tasks which are done externally will be
determined. Training of internal resource to acquire the necessary skill for the development
of the application is not the most viable option since it will prolong the development time.
However, the WBS can come up with the training needs for the organisation to be able to
address the long term organisation learning needs and adaptation to the dynamic operational
environment.

Employee preferences on which task to take over and above their routine tasks may
sometimes be overlooked while those that employ this technique often see ownership in
doing the tasks. WBS eliminates cases of conflicting interest with the current roles which
hinders meeting of projects requirements (Boehm 1991, Tausworthe 1979).

2.2.3 Risk Mapping

To manage the current and future risks associated with the software development there is
need for identification, rating, ranking and development of control measures to the risks
associated with the project. According to Ravindranath (2006) intuitive and history based
methods are the common methods that can be used to identify the risk associated with
software projects. Mind mapping presents a method that identifies the risk based on familiar
symptoms which can lead to future mishaps or through previous experience in similar
projects. Whilst mind mapping is for use by experienced software programmers,
brainstorming provides a rich of information due to the diverse composition of the people
involved. It encourages rich cross cultivation of ideas unlike in solo mind mapping. When
used in conjunction with WBS it provides a more formalised way to identify all the risks that

6|Page
can be associated with a project (Boehm 1991). Out of the box thinking during the
brainstorming session provide a way to generate ideas other than the more familiar path
which the project can take. More experienced project managers can also use analogy to
generate ideas. Current situations can be analogous to previous scenarios in processes or tasks
symptoms. Using the more familiar tasks symptoms can provide a more guided approach to
risk identification than wild guesses therefore enabling more informed risk identification than
in brainstorming. Furthermore historical methods identify top ten risks checklist (Caper
Jones’s software risks, Rex Black’s quality risks, SEI’s risk taxonomy and popular top ten
risks) and evaluate the risks associated with a software project (Ravindranath 2006; Boehm
1991).

Once the risks have been identified in the above mentioned process the risk are assigned
probabilities and impact of occurrence. This results in the in four quadrants which have high
probability high impact of occurrence, high probability low impact, low probability high
impact and low probability low impact of occurrence. Control measures are then developed
for the high risks and risk owners assigned to manage those risks (Boehm 1991; 2003;
Boehm and DeMarco 1997). The process can be cyclical, incremental or agile to address the
ever changing risks.

2.3 Objective 3 - Resource requirements

The resource requirements involves a project management technique on the tasks and steps
involved. This can be done through use a Gantt chart which will show all the milestones to be
achieved and time frames of the activities, task dependencies, and rate determining steps.
Time resources are allocated in this step. Financial resources needed in accomplishing the
project can be ascertained. The project life cycle can be analysed leading to estimation of
project life cycle cost needed for project fruition, managing project risks and maintain the
project during its life cycle.

2.3.1 Project Time Planning

To come up with a Project time plan it is important to have a WBS just like in Personnel
Analysis, Stakeholder Mapping and Risk Mapping. WBS is important in slicing the works
tasks into manageable chunks which lead to a network of activities to be done (Tausworthe
1979; Boehm 1991). The activity network gives a detailed flow of events to the project team
showing the interrelationships. Whilst this is important its complex nature result in a
graphical which is not easy for everyone to understand. This is simplified by use of a bar
graphical Gantt chart which gives a two dimensional outlay which is easier to understand to
all. A bar graph gives a start-finish times hence the duration of the task (Kerzner and Kerzner
2008). After the activities networks have been created the time estimates are allocated to the
activities. Estimation of the time for each activity requires the knowledge of software
programming as such only experienced software programmers who have to worked similar
projects can give such time estimates. The milestones, time allocation and dependencies gives
the critical path hence an estimation of the time needed to complete the project. This is
crucial in determining resource allocation (Ravindranath 2006). Slack can be allocated to

7|Page
activities which do not affect the succeeding tasks whilst not prolonging the activities in the
critical path. It gives flexibility to reallocate critical human or financial resources without
affecting the critical path jobs.

For such analysis not to omit crucial steps for the project the use of Project management
software is advisable, which enables a Gantt chart of the project to be developed. Activity
networks of different scenarios allow for comparison on different project path which is
crucial for project cost benefit analysis. The knowledge of project software comes in handy
for such analysis though not crucial to the analysis of this project. Experience in software
programming projects comes in handy in determining the time estimates since software
programming is a human intensive process.

2.3.2 Life Cycle Cost Analysis

The other most important resource needed for the completion of the project is the financial
resources. The WBS discussed previously in project planning identified the time and human
resources needed for the project. They constitute some of the costs which are direct and
indirect to the fruition of the project. The project time scale which is determined at the start of
the project has a direct bearing on cost incurred. A protracted project puts additional costs
and risks associated with such a project even if it delivers intended results (Bakker, Boonstra
and Wortmann 2009). At the same time a shorter time than the estimated time though
favourable can still lead to a catastrophic failure if deliverables are not met.

Whilst Life Cycle Analysis (LCA) can be crucial in the analysis of the cost associated with a
project, it presents a broad method of analysing costs associated with a project which looks a
value chain and the associated interaction with the environment. Life Cycle Cost Analysis
presents a better and holistic method for management decision making in estimating the cost
associated with a project (Norris 2001). LCC presents a method of determining the cost of a
project during the economic lifespan of the project. It is there to determine the direct, indirect,
tangible and intangible costs associated with a project. Direct costs come in form of the direct
materials and labour needed to programme the business application. It is estimated through
market based labour rates and the indirect costs come in form of admin and utilities expenses.
Tangible costs come in form of the computer infrastructure needed for programming and
intangible costs though difficult to measure are the benefits that ensure from customer
acceptance, customer loyalty manifested through repeat purchases, worker morale, good
union relations, community relations, sales advantage and brand visibility associated with
using the app. By using an activity based costing direct and indirect costs of the project can
be estimated (Kaplan and Anderson 2003). For the purpose of determining the feasibility of
the mobile app, LCC provides a method of evaluating competing alternatives for decision
making purposes.

8|Page
3.0 Gantt Chart Method
The linkages between the project tasks can be managed through a graphical display which is
easier to understand for stakeholders involved. According to Wilson (2000, p.435); Kerzner
and Kerzner (2009, p.557) a Gantt chart is one such tool for representing the relationship
between the activities and the time duration to complete each activity in the form of a
graphical overview. The activities are listed in order of entry by start date, criticality and
slack and the progress is displayed in form of bar graphics showing start, duration, finish time
and possibly slack. The two dimensional activity against time duration can easily be printed
unlike a network diagram which have too much detail which is not easily understood by all
parties. The key sequence of milestones which determine the completion of the project is the
critical path (Karlesky and Voord 2008, p.4).

The project is to be completed in 26 weeks. The first week start with an inception meeting to
map the way forward with the client where key stakeholders for the project are introduced.
Frequency of the meetings will be discussed so as to discuss milestones achievements. The
engagement is continuous during the whole duration of the project to stir the project in the
right direction and address any challenges which may derail the completion of the project on
time. This is usually a source of additional costs and failure to address the client needs.

As illustrated on figure 3.1 below. The overview of the project shows the tasks arranged
chronologically. The activities are identified by numerical values as task identification
numbers. Their estimated duration and dependencies for the tasks are also shown totalling 26
weeks for the project to be completed. The bar chart graphic shows the length of the tasks by
indicating start-finish times. The project rate determining path 11-25-33-37-38 gives the
minimum time that is needed to complete the project. The key gives slack time on some
tasks. However there is less of this time because of high interdependency of the project tasks.
The project Gantt chart gives a blue print of the path and priority on tasks to do to kick start
the project and ensure that the project is completed. Key milestones are highlighted in the
task descriptions.

9|Page
3.1 Project Gantt chart

Fig 3.1 Gantt Chart

10 | P a g e
4.0 Contribution
The contribution to the client project will use supporting evidence from antecedent seminal,
scholarly and industry findings in elicitation of requirements of a B2B app for the catering
business and industry wide similar cases. When this information used in gathering
requirements, it will determine the functional, system boundaries (system requirements) and
the resource requirements. The requirements solicitation process as will be highlighted in the
supporting findings is interlinked hence it will naturally follow identification of stakeholders
(end user, developers and client) functional requirements which will lead to system analysis
for the project then the resource requirements. This analysis will assist the client on internal
gap analysis of the capability to develop the app or the need to seek external partner in
developing the app.

4.1 Stakeholder Analysis

Dvir et al (2003) points out that one of the three most important ways for project success is
coming up functional requirements which meet the end user requirements which is solicited
through engagement with the stakeholder on the requirements that are desirable in a product
and or service. Mahmoud et al (2013) investigated that crowdsourcing is one of the emerging
methods of sourcing requirements from a wide audience that resembles a crowd such as what
is common in software projects. According to Paetsch et al (2008) there are several methods
such as interviews, observations and brainstorming all which involve the end user functional
requirements in doing a project. The sourcing of these requirements is an important step in
ensuring that there are no omissions which when discovered in later stages will be costly. The
requirements solicitation is also a precursor for need prioritisation on competing needs,
system setup, risk analysis and determination of the eventual cost of the project.

Whilst end user requirements might seem more obvious functional needs for project
undertaking, Paetsch et al (2008) emphasise the need to consider the system boundaries for a
software project such as the developers and owners. Understanding the stakeholder needs will
then define the system constraints. Whilst stakeholder engagement using this method may
seem to be the method of choice in some instances it can lead to poor quality requirements.
Lombriser et al (2016) in a case study of soliciting requirements for a video conferencing
software found out that use of leader boards in a gamified experiments, where requirements
are solicited through incentivised games can lead to more and better quality requirements.

4.2 Software Benchmarking

According to Dar et al (2018) mobile application software requirements elicitation is one of
the challenging tasks in coming up with user requirements. However, software benchmarking
is one of the commonly used methods for elicitation of requirements providing a comparison
of the market available solutions to the product which an organisation is offering. This is
supported by Rafiq et al (2017) that competitor analysis or benchmarking as one of the
methods that is used in coming up with market driven requirements for software start-ups.

11 | P a g e
Trendowicz (2013) further supports that since there can already be software offering on the
market, benchmarking can be used in software programming as a method of comparing risks
associated with a project. This can be done by comparing thresholds in three benchmarks
which are; effort overhead thresholds, probability of acceptable risk and acceptable risk
exposure. This benchmarking tool feeds from stakeholder analysis in improving the quality of
requirements into the next stage of risk analysis in system requirements.

Effort overhead analysis compares the level of risks to the mean effort of similar projects
whilst risk exposure probability and acceptable level of exposure is an analysis by a risk
expert on the software requirements to perform at an acceptable level. Pang et al (2009) in
their research for improvement on the accessibility of website found out that benchmarking
provided a low cost way of comparing what other market leaders are offering to get the
insight on the user requirements. It gives a developer the software requirements to meet the
end user requirements.

4.3 System Environmental Analysis

System environmental analysis looks at the boundary layer of the people and the risk
associated with the tasks of creating a software project. It seeks to come up with the skills
required in coming up with the project. Most of IT projects failure can be attributable to
people issues and managing risks. As supported by Charette (2005) IT project failure can be
attributable to unrealistic project goals, inaccurate project costs estimates, poor reporting of
project milestone achievements, poor communication to the developers, customers and users,
inability to manage project complexity, poor software development practices, stakeholder
politics, immature technology, commercial pressures to outshine competitors and lastly
unmanaged risks. All these point to the human element in this intellectual intensive product
development process. Kaftannikov et al (2019) highlight that market pressures that led
Boeing to make shortcut in the development of their 737 plane leading to software
malfunction and loss of lives in Ethiopia and recalls of this passenger plane. Another instance
of commercial pressure was when Kmart Corporation launched the IT project to compete
with rival Wal-Mart through upgrades in sales, marketing and distribution software. Because
of poor project costs estimation and commercial pressure the project was aborted prematurely
leading to bankruptcy (Charrette 2005).

The above mentioned examples present some of the modern day failures which are
attributable to poor environmental analysis of the system boundary in which the project is
implemented. The failures of the IT projects present themselves in combination of more than
of the above mentioned causes therefore paying attention to details of these causes assists in
managing software project risk.

4.4 Personnel Analysis

According to Baccarini et al (2004) human resource is one of the sources of risk in a project.
This stems from the capabilities of the personnel involved in handling the project from
requirements elicitation, project planning, determining costs, managing the project,
communication and interaction with others, stakeholder management and handling risks

12 | P a g e
associated. As supported by Krishnan et al (2000) high personnel capability together with
deployment of resources early in the development of the project leads to high likelihood of
project success. Ropponen and Lyytinen (2000) further support that personnel management
risk as one of the key components for managing project risk. Zhou (2008) suggest that the
task assigned should be sustainable to the capabilities. Boehm (1991) further supports the
need to assign tasks to the preferences which lead to task ownership.

It also suffices to say that if the internal resources do not have the capabilities the tasks
especially for developers can be assigned to external personnel with hiring for those on call
being easier to manage for smaller enterprise as compared to large corporates which may
need consultants for the projects (Charette 2005).

4.5 Risk Identification and Analysis

As supported by Charette (2005, p.2) about 5 to 15% projects are abandoned shortly before or
after completion while others that are completed may be done through rework or over budget
implying a very high risk of implementing IT Projects. Baccarini et al (2004) further support
that IT projects are renowned for their high failure rates and as such risk management is
imperative for the success of such projects. Chief causes for such failures are personnel
incapability, incomplete customer requirements, low budget allocations, unrealistic project
schedule and late delivery (Baccarini et al p.286). Some such examples of high profile
failures are “Wessex Health Service RISP (Regional Information Systems Plan) and Mandata
Human Resource System and the Californian State Automated Child System (SACSS)”. The
key to project success therefore lies in project risk management plan. Dey et al (2007, p.285)
support that every project undertaking presents a degree of uncertainty in the likelihood of
success. The probability of success is increased by the application of formal risk management
processes to mitigate the adverse factors that impact on the project. They further support that
the degree of risk varies with the size, complexity, system boundaries, resource availability
and lack of understanding of the customer requirements. They also found out that stakeholder
involvement in the project process minimises failure of the project. Using the business
process reengineering framework, for the Town and Country Planning Office (TCPO) that
regulates building construction in Barbados they found out that human resource capability
was a key factor to managing project development risk. Loss or lack of capable human
resource had a high likelihood of failure which is key also to this project in whether the
project can be done internally or if there is need for an external developer. This was followed
by incomplete requirements which leads to project scope creep.

Conclusively both organisational and technical risk factors are to be managed for a project to
succeed Bakker et al (2007).

4.6 Project Time Planning

Project time planning is there to manage project time schedule. As one of the project resource
requirements, it presents a risk if not managed well. Risk emanating from scheduling and
13 | P a g e
time management risks are due to; experience in risk management methods, frequency of use
of risk management methods, the size and complexity of the last completed project,
experience of project manager, the industry where application is to be used and the type of
the developed application (Ropponen and Lyytinen 2000; Munns and Bjeirmi 1996). In their
findings it is therefore important to have experienced project managers to manage projects
with familiar complexity for a project to be delivered within the programmed time scale.

In their investigation on the provision of resources to a project McLeod and MacDonell

(2011) found out the provision of adequate human, financial as well as development time is
key to the success of a software project. Time planning is crucial for stakeholders
requirements elicitation, development and implementation of projects. Inadequate resources
have been found to be a contributor to failed projects due to risk emanating at each stage of
the project cycle.

4.7 Life Cycle Cost Analysis

The determination of the financial resources needed for a software project is a great interest
to the client. Life cycle cost analysis (LCCA) is the total cost of owning the project. It
presents a way to evaluate competing projects for investment purposes. While there are other
methods of evaluation of cost associated with a project like Life Cycle Analysis (LCA),
LCCA gives the client ability to evaluate the direct costs and the benefits that come with the
software project (Norris 2000). He found out that when using LCCA the client can evaluate
cost effectiveness of alternative projects to choose the projects which gives the best returns.
The timing and the scope of the project is pivotal in determining such costs. Any costs which
are outside the project life cycle should be excluded from the total cost of doing a project.

Asiedu and Gu (1998) in their investigation on industry wide cases figured out that in order to
reduce the design changes, product lead time and cost, life cycle analysis and concurrent
engineering have emerged as the techniques of choice. They also found out that 70% of the
product life cycle is incurred as committed cost during the design stage which implies that the
major cost of the product hinges on decisions done at design stage. Therefore LCCA gives a
framework for calculating the incremental cost of conception, producing, using and disposal
of the item.

14 | P a g e
5.0 Conclusion
The write up came up with a scoping study on the models for elicitation of B2B mobile
applications requirements. This is based on the research on the functional, system and
resource requirements of a B2B application found from antecedent seminal, scholarly as well
as industry widely available practises on the solicitation of functional, resource and system
analysis of operating environment. The requirements have been explained to assist the client
in decision making on the scope of requirements. Stakeholder analysis will reveal for the
client what the requirements are when the highlighted method are followed in getting the
expected requirements from the customers. Comparing the solicited requirements with the
current market offering provide the client with what to match and exceed so as to provide
superior customer value than that of the competitors. The honours is on the client to assess
the organisation’s state of preparedness and the internal resource adequacy in coming up with
the mobile app by programming it internally or engaging the services of an IT expert if the
system gap analysis reveals lack of internal competence.

The risk associated with the project have to be managed internally. It is imperative that the
risk managers for every particular risk be vigilant to continuously scan the operating
environment by scanning and including new risks into the risk matrix consequently new risk
plans are developed to mitigate the impact of the risk. The system environment should
continuously ensure the adequacy of the human capital so that it remains relevant for
continual success of the application throughout the product life cycle. The Gantt chart gives a
realistic time plan considering other software projects the consultant has been exposed to.
Though having its own shortcomings highlighted in the study, the Gantt chart is widely
accepted as the easiest way to communicate the project time plan to all stakeholders. If
followed the Gantt chart will ensure that milestones for the project are completed on time.
When complied using Project Management software such as Microsoft Project it will ensure
project comparisons are done when there are competing ways of doing tasks extracted from
WBS. It will also ensure that the financial resources are not strained due to behind the
schedule tasks. The management of the time resource implies the no financial risk will arise
due to extra cost.

15 | P a g e
References

Al-Ali, A.R., Aloul, F.A., Aji, N.R., Al-Zarouni, A.A. and Fakhro, N.H. (2008) ‘Mobile
RFID tracking system’, 3rd International Conference on Information and
Communication Technologies: From Theory to Applications (pp. 1-4). IEEE. [Online]
Available at: https://ieeexplore.ieee.org/abstract/document/4530117/ (Accessed: 15
April 2019).

Alexander, I. and Robertson, S. (2004) ‘Understanding project sociology by modeling

stakeholders’, IEEE Software, 21(1), pp.23-27.

Asiedu, Y. and Gu, P. (1998) ‘Product life cycle cost analysis: State of the art
review’, International Journal of Production Research, 36:4, 883-908.

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

Barnes, S.J. (2002) ‘The mobile commerce value chain: analysis and future
developments’, International journal of information management, 22(2), pp.91-108.
[Online] Available at:
https://www.sciencedirect.com/science/article/pii/S0268401201000470 (Accessed: 18
April 2019).

Batra, G.S. (1996), ‘Human resource auditing as a tool of human resource valuation:
interface and emerging practices’, Managerial Auditing Journal, Vol. 11 Issue: 8,
pp.23-30. [Online] Available at: https://doi.org/10.1108/02686909610131657
(Accessed: .20 April 2019)

Boehm, B. (2003) ‘Value-based software engineering’, ACM SIGSOFT Software

Engineering Notes, 28(2), p.4.

Boehm, B.W. (1991) ‘Software risk management: principles and practices’, IEEE

software, 8(1), pp.32-41. [Online] Available at:
https://ieeexplore.ieee.org/abstract/document/62930/ (Accessed: 18 April 2019).

Boehm, B.W. and DeMarco, T. (1997) ‘Software risk management’, IEEE software, (3),
pp.17-19. [Online] Available at:
https://www.computer.org/csdl/mags/so/1997/03/s3017.pdf (Accessed: 18 April
2019).

Charette, R.N. (2005) ‘Why software fails [software failure].’ IEEE spectrum, 42(9), pp.42-
49. [Online] Available at: https://ieeexplore.ieee.org/abstract/document/1502528/
(Accessed: 20 May 2019).

Daneva, M. (1995) ‘Software benchmark design and use.’ In Re-engineering the

Enterprise (pp. 20-29). Springer, Boston, MA.

16 | P a g e
Daneva, M., Heib, R. and Scheer, A.W. (1996) ‘Benchmarking business process models’.

Dar, H., Lali, M.I., Ashraf, H., Ramzan, M., Amjad, T. and Shahzad, B. (2018) ‘A systematic
study on software requirements elicitation techniques and its challenges in mobile
application development’, IEEE Access, 6, pp.63859-63867. [Online] Available at:
https://ieeexplore.ieee.org/abstract/document/8513829 (Accessed: 18 May 2019).

De Bakker, K., Boonstra, A. and Wortmann, H. (2010) ‘Does risk management contribute to
IT project success? A meta-analysis of empirical evidence’, International Journal of
Project Management, 28(5), pp.493-503. [Online] Available at:
https://www.sciencedirect.com/science/article/pii/S0263786309000787 (Accessed: 8
May 2019).

Dey, P.K., Kinch, J. and Ogunlana, S.O. (2007) ‘Managing risk in software development
projects: a case study’, Industrial Management & Data Systems, 107(2), pp.284-303.

Dubelaar, C., Sohal, A. and Savic, V. (2005) ‘Benefits, impediments and critical success
factors in B2C E-business adoption’, Technovation, 25(11), pp.1251-1262. [Online]
Available at:
https://pdfs.semanticscholar.org/9982/2970c2105ee95b68a9f8c2c09579d743ffdd.pdf
(Accessed: 14 April 2019).

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, 21(2), pp.89-95. [Online] Available at:
https://www.sciencedirect.com/science/article/pii/S0263786302000121 (Accessed 18
April 2019).

Fahmy, S., Haslinda, N., Roslina, W. and Fariha, Z. (2012) ‘Evaluating the quality of
software in e-book using the ISO 9126 model’, International Journal of Control and
Automation, 5(2), pp.115-122. [Online] Available at:
https://www.researchgate.net/profile/Syahrul_Fahmy/publication/266507818_Evaluat
ing_the_Quality_of_Software_in_e-
Book_Using_the_ISO_9126_Model/links/5639948d08aed5314d222446.pdf
(Accessed: 15 April 2019).

Franch, X. and Carvallo, J.P. (2003) ‘Using quality models in software package
selection’, IEEE software, 20(1), pp.34-41. [Online] Available at:
https://ieeexplore.ieee.org/abstract/document/1159027/ (Accessed: 16 April 2019).

Global Digital Users Update 2018. [Online] Available at:

https://www.emarketer.com/content/global-digital-users-update-2018 (Accessed: 18
April 2019).

Gotter, A., (2019) ‘Mobile Marketing Statistics You Need to Know’. [Online] Available at:
https://www.business2community.com/marketing/38-mobile-marketing-statistics-
you-need-to-know-02185085 (Accessed: 18 April 2019).

17 | P a g e
Heitkötter, H., Majchrzak, T.A. and Kuchen, H. (2013) ‘Cross-platform model-driven
development of mobile applications with md 2’, In Proceedings of the 28th Annual
ACM Symposium on Applied Computing (pp. 526-533). ACM. [Online] Available at:
https://dl.acm.org/citation.cfm?id=2480464 (Accessed: 15 April 2019).

Hosseini, M., Phalp, K.T., Taylor, J. and Ali, R. (2014) ‘Towards crowdsourcing for
requirements engineering’. [Online] Available at:
http://eprints.bournemouth.ac.uk/21904/ (Accessed: 18 April 2019).

Jung, H.W., Kim, S.G. and Chung, C.S. (2004) ‘Measuring software product quality: A
survey of ISO/IEC 9126’, IEEE software, 21(5), pp.88-92. [Online] Available at:
https://ieeexplore.ieee.org/abstract/document/1331309/ (Accessed: 16 April 2019).

Kaftannikov, I.L., Zhernova, V.M. and Minbaleev, A.V. (2019) ‘Problems of structuring
risks and ensuring legal relations in IoT’, 1st International Scientific Conference"
Modern Management Trends and the Digital Economy: from Regional Development
to Global Economic Growth"(MTDE 2019). Atlantis Press. [Online] Available at:
https://www.atlantis-press.com/proceedings/mtde-19/125907543 (Accessed: 20 May
2019).

Kan, S.H. (2002) Metrics and models in software quality engineering. Addison-Wesley

Longman Publishing Co., Inc...

Kaplan, R.S. and Anderson, S.R. (2003) ‘Time-driven activity-based costing’. [Online]
Available at: SSRN 485443. (Accessed: 8 May 2019).

Karlesky, M. and Vander Voord, M. (2008) ‘Agile project management’, ESC, 247(267), p.4.

Kerzner, H. and Kerzner, H.R. (2017) ‘Project management: a systems approach to

planning, scheduling, and controlling’, John Wiley & Sons.

Krishnan, M.S., Kriebel, C.H., Kekre, S. and Mukhopadhyay, T. (2000) ‘An empirical
analysis of productivity and quality in software products’, Management
science, 46(6), pp.745-759.

Lombriser, P., Dalpiaz, F., Lucassen, G. and Brinkkemper, S. (2016) ‘Gamified requirements
engineering: model and experimentation’, In International Working Conference on
Requirements Engineering: Foundation for Software Quality (pp. 171-187). Springer,
Cham [Online] Available at: https://link.springer.com/chapter/10.1007/978-3-319-
30282-9_12 (Accessed: 20 May 2019).

McLeod, L. and MacDonell, S.G. (2011) ‘Factors that affect software systems development
project outcomes: A survey of research’, ACM Computing Surveys (CSUR), 43(4),
p.24. [Online] Available at: https://dl.acm.org/citation.cfm?id=1978803 (Accessed: 8
May 2019).

Munns, A.K. and Bjeirmi, B.F. (1996) ‘The role of project management in achieving project
success’ International journal of project management, 14(2), pp.81-87.

18 | P a g e
Norris, G.A. (2001) ‘Integrating life cycle cost analysis and LCA’, The international journal
of life cycle assessment, 6(2), pp.118-120. [Online] Available at:
https://link.springer.com/article/10.1007/BF02977849 (Accessed: 8 May 2019)

Paetsch, F., Eberlein, A. and Maurer, F. (2003) ‘Requirements engineering and agile software
development. In WET ICE 2003. Proceedings’, Twelfth IEEE International
Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises,
2003. (pp. 308-313). IEEE. [Online] Available at:
https://ieeexplore.ieee.org/abstract/document/1231428/ (Accessed 8 May 2019).

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, 13(3), pp.119-162.

Patel, M. (2019) ‘Mobile App Development- 7 Benefits for Modern Businesses in 2019’
Available at: https://www.business2community.com/mobile-apps/mobile-app-
development-7-benefits-for-modern-businesses-in-2019-02189059 (Accessed: 18
April 2019).

Rolstadås, A. ed. (2013) ‘Benchmarking-theory and practice’, Springer.

Ropponen, J. and Lyytinen, K. (2000) ‘Components of software development risk: How to

address them? A project manager survey’, IEEE transactions on software
engineering, 26(2), pp.98-112.

Shim, S.S., Pendyala, V.S., Sundaram, M. and Gao, J.Z. (2000) ‘Business-to-business e-
commerce frameworks’, Computer, 33(10), pp.40-47. [Online] Available at:
https://ieeexplore.ieee.org/abstract/document/876291/ (Accessed: 15 April 2019).

Sim, S.E., Easterbrook, S. and Holt, R.C. (2003) ‘Using benchmarking to advance research:
A challenge to software engineering’, In proceedings of the 25th International
Conference on Software Engineering (pp. 74-83). IEEE Computer Society.

Smith, N.C., Drumwright, M.E. and Gentile, M.C. (2010) ‘The new marketing
myopia’, Journal of Public Policy & Marketing, 29(1), pp.4-11. [Online]. Available
at: http://journals.ama.org/doi/abs/10.1509/jppm.29.1.4 (Accessed: 12 May 2018).

Tausworthe, R.C. (1979) ‘The work breakdown structure in software project

management’, Journal of Systems and Software, 1, pp.181-186. [Online] Available at:
https://www.sciencedirect.com/science/article/pii/0164121279900189 (Accessed: 8
May 2019).

WordPress (2019) Some Essential Characteristics of Mobile Applications. Available at:

https://ittechsols.wordpress.com/2012/12/18/some-essential-characteristics-of-mobile-
applications/ (Accessed: 18 April 2019).

Yang, W., Prasad, M.R. and Xie, T. (2013) ‘A grey-box approach for automated GUI-model
generation of mobile applications’, In International Conference on Fundamental

19 | P a g e
 Approaches to Software Engineering (pp. 250-265). Springer, Berlin, Heidelberg.
[Online] Available at: https://link.springer.com/chapter/10.1007/978-3-642-37057-
1_19 (Accessed: 18 April 2019).

Zahra, S., Khalid, A. and Javed, A. (2013) ‘An efficient and effective new generation
objective quality model for mobile applications’, International Journal of Modern
Education and Computer Science, 5(4), p.36.[Online] Available at :
https://www.researchgate.net/profile/Ali_Javed2/publication/274048560_An_Efficien
t_and_Effective_New_Generation_Objective_Quality_Model_for_Mobile_Applicatio
ns/links/56a8dc1d08aeea2a20497e7e.pdf (Accessed 18 April 2019).

Zein, S., Salleh, N. and Grundy, J. (2016) ‘A systematic mapping study of mobile application
testing techniques’, Journal of Systems and Software, 117, pp.334-356. [Online]
Available at: https://www.sciencedirect.com/science/article/pii/S0164121216300140
(Accessed: 18 April 2019).

Zhao, L., Lu, Y., Zhang, L. and Chau, P.Y. (2012). ‘Assessing the effects of service quality
and justice on customer satisfaction and the continuance intention of mobile value-
added services: An empirical test of a multidimensional model’, Decision support
systems, 52(3), pp.645-656. [Online] Available at:
https://www.sciencedirect.com/science/article/pii/S0167923611002028 (Accessed: 18
April 2019).

20 | P a g e