Information
AI Chat

Requirements Elicitation for B2B Mobile Application Development for Company X

Management Project dissertation requiring the student to act as a mana...

Module

Dissertation Project (BS4S03)

3 Documents

Students shared 3 documents in this course

University

University of South Wales

Academic year: 2020/2021

Uploaded by:

Olumide Agbede

University of South Wales

0followers

6Uploads

35upvotes

Comments

Please sign in or register to post comments.

Kathy2 years ago
thanks

Related Studylists

Management Project management project

Preview text

Requirements Elicitation for

Mobile Application Development for Company X

(project-based scoping study approach)

AGBEDE JOHN OLUMIDE 74108206 Management Project Report submitted to UNIVERSITY OF SOUTH WALES

SEPTEMBER 5, 2020

Tutor: Evangelia Katsikea

1

Executive Summary Mobile applications, new and fast developing segment of the global Information and Communication Technology (Islam, et al., 2010, p), and its development have revolution ized business operations with impeccable apps which streamline the process involved in various aspects of the business. The pace of development of these solutions is primarily affected by the needs of current business environment, the needs of users (Seffa, et al., 2005), and the specificity of services and applications (Lobaziewicz, 2015). The Mobile applications consist of software/set of programs that run on a mobile device and perform certain tasks for the user. The Business to Business (B2B) Mobile App is a type of enterprise mobile application designed to connect with other businesses, clients or employees within the company; this is the area of mobile application development requirements that this study covers. Focus is on determining the necessary requirements of developing a business app for Company X, a SME providing food products to the catering trade, using a project-based consulting (scoping study) approach to produce the report. The study approach exploits approved project and software management methodologies and techniques combined in the requirements elicitation process, and involves investigating three applicable objectives. Objective 1 looks into Functional Requirements, which provides answers to what the application’s features would be, how the application has to look like to satisfy the stakeholders and in which functional direction, using stakeholder analysis and software benchmarking techniques. The second objective examines the Structural Requirements, which seek to examine the possibility, appropriateness and applicability of the mobile application within the company’s structural circumstances; this uses System Environment Analysis, Personnel Analysis, and Risk Identification and Analysis to elicit requirements. And finally, Resource Requirements is Objective 3 which uses Life-cycle Costing and Project Schedule Planning techniques to investigate the types of resources for different activities, the quantities, amount, and skill level of the resources needed before and after the project. This study will take 26 successive weeks as illustrated in the Gantt chart. The A3 Map condenses the project information onto a single page in an easy-to-read, graphical format as shown in the Appendix. Recommendations made towards successful application development are based on the defined objectives, and are also contained in this requirements document. Key Words: Requirements, Software, B2B Mobile App, Gantt chart, A3 Map, Information and Communication System, Stakeholder, Benchmarking, Life-Cycle Costing, Project Schedule, Risk

TAB LE OF CONTEN TS

1. Chapter 1: Introduction........................................................................ –
  - 1. Study Background.........................................................................
  - 1. Project Objectives..........................................................................
1. Chapter 2: Supportive Evidence............................................................ –
  - 1. Objective 1: Functional Requirements...................................................
    - 2.1. Stakeholder Analysis.........................................................
    - 2.1. Software Benchmarking....................................................
  - 1. Objective 2: Structural Requirements..................................................
    - 2.2. System Environment Analysis..............................................
    - 2.2. Personnel Analysis...........................................................
    - 2.2. Risk Identification and Analysis...........................................
  - 1. Objective 1: Resource Requirements...................................................
    - 2.3. B2B Software Project Schedule Planning.................................
    - 2.3. Project Life-Cycle Costing Analysis.......................................
1. Chapter 3: Study Gantt chart............................................................... –
1. Chapter 4: Contribution.................................................................... –
  - 1. Stakeholder Analysis.....................................................................
  - 1. Software Benchmarking..................................................................
  - 1. System Environment Analysis...........................................................
  - 1. Personnel Analysis.........................................................................
  - 1. Risk Identification and Analysis.........................................................
  - 1. B2B Software Project Schedule Planning..............................................
  - 1. Project Life-Cycle Cost Analysis.........................................................
1. Chapter 5: Concluding Remark............................................................ –
- Figure 1: Typical Input/output of Requirements Elicitation Process............................
- Figure 2: Linear Requirements Engineering Model..............................................
- Figure 3: Power versus Interest Grid...............................................................
- Figure 4: Study Gantt chart.........................................................................
- References...................................................................................... –
- Appendix A: Study A3 Map................................................................. –
- Appendix B: Client Project Brief........................................................... –

3

Chapter 1 – Introduction

Study Background These days’ people are habituated in computer usage and applications in this era of informatio n and communication systems, a result of technological shift which has changed the way business operations are being conducted globally. Businesspeople use mobile devices like smartphones and tablets as complementary services to their computers that are equipped with business applications (Lobaziewicz, 2015), thus revolutionizing the way businesses interact with their partners and customers (Medjahed, et al., 2003), providing the ideal framework for interconnecting organizations, and rapidly emerging as one of the most practical approaches for the integration of customers’, vendors’, and business partners’ applications, which are synchronized into a new “product development process” (Markus, 2000, p. 4). To achieve this flexibility, the business processes must be linked to the organizational strategy and to the business goals that motivate the need of these processes. This involves the utilization of the internet to collaborate with trading partners, commonly referred to as business-to-business (B2B) applications, which have been evolving as an important tool for customer relationship management (Smilansky, 2015), especially now that people spend more time using mobile applications than internet via traditional desktop computers (Rajput, 2015). This new frontier to grow businesses has been embraced by many small businesses as they have developed their own dedicated mobile app as a way of harnessing the potential of modern digital communications. Company X understands that embracing this new trend would be relevant for increasing both sales and visibility. However, the development of this app is outside the company’s specialism, as it involves complex Information Technology project, and more up-front work in mobile projects to “get it right”, hence the project now needs its own effort rather than being part of a web, and demands a separate team to develop the mobile application. This is critical also to avoid the pitfalls associated with poorly managed projects.

Standish Group Study, 1995 reports that 13% and 8% projects fail due to incomplete requirements and rapidly changing in the requirements respectively. Furthermore, system developers are concerned with error elimination, as wrong requirements consequences may include the system being delivered late, getting costlier than originally estimated, becoming unreliable with regular defects, and customer and end-user not satisfied (Shams-Ul-Arif, and

4

Gahyyur, 2009), so the need of rigorous development makes the application of techniques based on formal methods necessary, and more urgent now when the failure of large applications can be related to complexity increase and bad requirements analysis (Coscia and Reggio, 1997, p. 2). Software requirements describe features and functionalities of the target system, conveying the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view. This process of seeking, uncovering, acquiring and elaborating requirements for computer-based systems” (Zowghi and Coulin, 2005) is commonly called requirements engineering or requirements elicitation. In order to avoid a situation where developer may build the app in a way that the owner didn’t intend it to function, it’s important to ensure project requirements are crystal clear before any work begins. This provides clarity on the new app, gets everyone on the same page in all aspects of the projects, and describes how the client sees the result of the development process with the developer.

Project Objectives The earliest and fundamental stages of project development lifecycle commonly begin with the elicitation of requirements (Kotonya and Sommerville, 1998), especially for interactive products and services, covering all the activities involved in discovering, documenting, and maintaining a set of requirements (Shams-Ul-Arif, and Gahyyur, 2009). It’s the most important activity in software project development as the other phases in the life cycle of software development depends on it (Antona, et al., 2009). This is evidenced in the principles of user-centred design (Norman and Draper, 1986), leading to the development and practice of a wide variety of methods and techniques, many of which are based on the direct participation of users or user representatives in the process of formulating their own technological needs. Berry (1994, p. 30), quoting Joseph Goguen of Oxford University in Monterey Workshop, observes that “it is not accurate to say that requirements are in the minds of the client: it would be more accurate to say that they are in the social system of the client organization; they have to be invented, not captured, and this invention is the result of a cooperation among the client, the user and the developer.” Though Gordijn, et al. (1999) argue that system requirements cannot be discovered (elicited) because usually the “underlying business activities themselves are also new and in a state of being designed”, however Lent (2013) posits in favour of requirements elicitation in that “it more accurately describes the challenging, back-and-forth conversation that must take

5

place among stakeholders to specify an application's needs effectively.” In agreement with this line of thought, the objectives of study shall be based on requirements elicitation. Generally speaking, requirements elicitation represents the set of activities involved in discovering what the system requirements are, including identifying all the stakeholders of the systems, analyzing the problem application domain, the system operating environment and of the customers’ organizational and business environment (Damian, 2000). It’s a very critical iterative phase in software development lifecycle that requires high level of precision in deciding what to build, as field studies show that misidentification of requirements is one of the most significa nt sources of customer dissatisfaction with delivered systems (Macaulay, 1996). This is followed by specifying these requirements into documents and verifying to discover possible gaps or inconsistencies (Decreus, et al., 2009). Hence, this scoping study will deal with the requirements elicitation to in order to understand the current situation and define the target system. We will apply the principles of standard project management, software project management experience and similar case studies to achieve the categories of objectives. Figures 1 and 2 represent the requirements gathering process and model; according to Kauppinen, et al., (2004), these inputs and outputs are similar for all organization in most of the cases, but only the requirements vary.

Figure 1: Typical Input/output of Requirements Elicitation Process (Kotonya, G. and Sommerville, I., 1998)

6

Figure 2: Linear Requirements Engineering Model (Kotonya, G. and Sommerville, I., 1998)

1.2. Objective 1: Identifying the Functional Requirements Functional requirements shall investigate what the business shall do (Lauesen, 2003), and the business function(s) impacted; it provides answers to what the application’s features would be, how the application has to look like to satisfy the stakeholders and in which functional direction the application has to go.

The B2B Mobile Applications requirements within the food catering industry will involve gathering and carrying out the analyses of stakeholders expectations (stakeholder analysis) and examining if there are existing best practice examples which align with the results of the stakeholder analysis (Software Benchmarking).

1.2. Objective 2: Identifying the Structural Requirements Structural requirements shall examine the possibility, appropriateness and applicability of the mobile application within the company’s structural circumstances; considering how clients fulfill the structural requirements to the program, how the implementation of the application fits within the current organizational environment, and determining possible training needs for enhancing employees’ skills while using the application. This objective is achieved through System Environment Analysis, Personnel Analysis, and Risk Identification and Analysis.

7

1.2. Objective 3: Identifying the Resource Requirements Resource requirements shall explore the types of resources for different activities, and the quantities, amount, skill level of the resources needed before and after the project. This analysis examines how long the software engineering and implementation process, including all necessary testing and coordination procedures, will take (project Schedule planning), which monetary resources will be necessary to conduct the project and handle follow-up costs (Life-cycle Costing), and how many people are needed to execute the implementation of the B2B software application.

8

Chapter 2 – Supportive Evidence

This scoping study deploys a research-based consulting approach to eliciting all kinds of requirements for successful development and roll-out of the client’s desired B2B mobile application. Hence, supportive evidence is necessary as it establishes objectives that are relevant to client’s project requirements, provides the critical explanation of how these objectives will be met in reality. This will help us develop models that support these objectives in relation to the client’s requirements and enable the project development; the theoretical perspectives in relation to the chosen models are justified, and relevant industry information to support these assertions are also examined and discussed.

Objective 1: Functional Requirements. Business-to-Business (B2B) applications’ E-commerce revolution, with far more dramatic economic implications, has been taking place away from the spotlights, which 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, Customer Relationship Management, billing, accounting, human resources, supply chain, and manufacturing (Medjahed, 2003; Al- Naeem et al., 2005). Identifying the functional requirements of the mobile B2B Applications within the food catering industry will involve carrying out the analyses of stakeholders expectations (stakeholder analysis) and examining if there are existing best practice examples which aligns with the results of the stakeholder analysis (Software Benchmarking).

2.1. Stakeholder Analysis The term stakeholder has passed the “tipping point” into common use (Gladwell, 2000) and the notion that key stakeholders must be attended to is an idea “in good currency” (Schon, 1971) and needs be taken into account by business leaders (Bryson, 2003). Stakeholders are any group or individuals who can affect or is affected by the achievement of an organization’s objectives (Freeman, 1984, p. 46; Power, 2010), development and deployment of the software applications in this case, or have interest in an organization (Walker, et al. 2008), without whose support the organization will cease to exist (Donaldson and Preston, 1995). They can influence strategic decisions and shape the course of the project, though different from shareholders who have an ownership interest in the company (Shawn, 2017).

9

Internal and external stakeholders are the two category of stakeholders that exist; the former could be employees at executives/management, divisional/departmental levels who may want the app designed in a specific way or having some features which may reflect their functions or ease their operational task, while the latter are external individuals, organizations or network of organizations who may have influence in the app development and may be impacted by its development and deployment. These external stakeholders are also frequently considered in adversarial terms as opportunities for either collaboration or threat (Blair and Fottler, 1990). These people need to be pulled together to identify what problem the app would solve, what aspect of company operations it would improve, and they prepare a specific list of functionalities expected. Stakeholder analysis encompasses a range of different methodologies for analyzing stakeholder interests (Crosby, 1992), and serving as a project management tool for collecting and analyzing data on stakeholder, thus providing a broad layer of necessary information (Glinz and Wieringa, 2007; Newcombe, 2003) for developing an understanding, and identifying opportunities for influencing (Brugha and Varvasovszky, 2000), and in determining whose interest should be taken into account when developing or implementing the project plans. In essence, this analysis acts as a framework to strategically manage these myriads groups and relationships for long term success. First step in stakeholder analysis is Stakeholder identification. Crawford (1994)) proposes group session approach which attempts to involve the right people in the process and promote cooperation, understanding and teamwork among users, developers and customers to cope with some of the social problems that could arise at subsequent phases. This process must avoid dominant behavior of individuals with organizational authority which may inhibit equal participation and communication of requirements (Macaulay 1996). Conversely, this can be done through a structured survey of a known group of stakeholders where inclusion of others as important stakeholders is determined by what percentage of respondents mentions them (Brugha and Varvasovszky, 2000), or in collaboration with the client who has the superior knowledge of the organization’s internal procedures and various stakeholder groups, or through brainstorming sessions, as suggested by Calvert (1995). Whichever method agreed on, the client must participate actively in the process (Pouloudi and Whitley, 2017), while the central focus must be on identifying what Sharp et al. (1999, p. 389) term 'Baseline Stakeholders', which primarily represent internal and external “users, developers, legislators and decision-makers”, including secondary shareholders with whom the company interact but are not essential to its survival

10

(Freeman, 1984; Clarkson, 1995). This basically entails scanning the internal and external environments to build collaborations and arrest uncertainties.

Next is stakeholder mapping, a tool used to display an organization’s key relationship by placing the organization at the centre of the map, while the internal and external stakeholders earlier identified in relation to this software application are mapped to it. This considers such factors as values/beliefs, power, cooperative potentials, and issues likely to be of concern to individ ua l stakeholder. The Map would display the strength of the relationships and the potentials for coalition by showing their interests and likely positions with regard to the software development project, and then actions for mobilizing support of each can be identified. With the aid of the map, the most influential stakeholders can then be engaged through a structured meeting or personal conversation in an attempt to determine their needs and requirements. This process of stakeholder communication is relevant at the beginning of the project (Passenheim, 2009) because it ensures the understanding of and early involvement of the relevant stakeholders. The map also makes it possible to carry out stakeholder diagnosis and strategy formulation in a way that makes it possible to assess stakeholders’ potential as threats and as opportunities for cooperation in the course of the project implementation, categorized as high or low in the matrix. This serves in identifying the appropriate strategy or what Blair and Fottler (1990) term ‘optimal fit’ for managing each category.

Ultimately, the stakeholder analysis results in a Mendelow’s stakeholder matrix with objectives, priorities and vast contributions (Lock, 2013) towards the project development phase. Mendelow (1991) considers stakeholder "power and expectations, and their likely interest, and determines the potential influence of stakeholder groups. Shown below is an example of the Stakeholder Matrix, Power/Interest Grid (Power on the vertical axis, Interest on the Horizontal Axis). Stakeholder analysis is not without its challenges in terms of difficulties in accessing some of the stakeholders, thus elongating the schedule, as well as marrying the project objectives with those of some relevant individual stakeholders having completely divergent objectives/view. However, the result should satisfy a good number of stakeholders to have been considered effective.

11

High

Low High Interest Figure 3: Power versus Interest Grid.

2.1. Software Benchmarking The term benchmarking is the process of determining the best processes, strategies and techniques for achieving business goals, or the practice of comparing business process and performance, or the process of measuring the performance of a company’s products, services/processes against those of other business(es). These point to identifying opportunities for improvement, or to show that a system is useful or provide insight into how systems behave (Wright, et al., 2005), shed light on a company’s entire value delivery system (Lacobucci and Nordhielm, 2000), and make it possible to gather and apply information to achieve an improvement of their own business operations (Watson, 1993). Benchmarking is a widely used business practice and has been accepted as a key component for organizations to search for improvement in quality, competitive position or market share (Wohlin, et al., 2002); an effort to be the best of the best (Corbett, 1998).

However, in this context, software benchmarking analysis will be tailored towards examining if there are existing best practice examples, the type which Wohlin, et al (2002) term “generic

null

 Category C: Stakeholders with High Power, but Low Interest. Keep Satisfied E. Media

 Category A:

Stakeholders with High Power and High Interest Manage Closely E. Customers Shareholders, Business Partners,

 Category D: Stakeholder with Low Power and Low Interest Monitor E. General Public, Consumers

 Category B: Stakeholders with High Interest, but low Power Keep Informed E. Employees

12

benchmarking”, within or outside the food catering industry which aligns with the results of the stakeholder analysis objectives achieved above. This analysis compares those key functiona l requirements identified by key stakeholders with those of external software companies and practice examples of comparable food catering markets; in software, it usually compares two companies' practices and results, but, occasionally, it involves sets of companies (Jones, 1995), and quantitative data on topics such as effectiveness, schedules and costs (Beitz and Wieczorek, 2000; Jones, 1995). Software benchmarks have been qualitative rather than quantitative (Jones, 1995) and involves qualitative benchmark that ranks company performance on a scale that lacks quantification for specific quality and productivity levels. In software benchmarking, it is required that objectives to be achieved be defined as has been done with stakeholder analysis above, benchmarking team be developed, what will be benchmarked be defined, and sources of information be reviewed to be ready to move to the next critical step of selecting their data collection methods. This supports Kodali (2008) who argues that “the first step of the software benchmarking process is the collection of data”, and very true because it’s a critical stage that needs to be well managed for reliable results.

Several data collection methods exist: on-site visit, telephone conversation, relevant publications/media articles, archival data, surveys, personal visits/interview, and other sources of information like government agencies, subject matter experts, trade and professional organizations and networks. And foreign data sources such as banks, consulates, libraries, chambers of commerce, databases such as Key Note, Mintel and MarketLine as well as providers of special benchmarking reports such as Best Practices, LLC, etc. may also be worthwhile sources to tap, including employees, customers, and suppliers are additional possibilities. The analysis and evaluation of the benchmarks will be carried out on the basis of the collected data. In order to achieve a possible competitive advantage in the industry, this analytical process compares the stakeholder goals with the elaborated criteria in order to establish the final functional requirements which the mobile Application has to satisfy (Kodali, 2008).

It’s worth noting that Software Benchmarking process is not without its own challenges. For instance, fast pace of technological changes may cause current software benchmarks not remaining the same benchmarks in the future, hence long-term developments have to be considered (Kumar and Harms, 2004). Also, antitrust laws or regulations covering informatio n under patent restriction, hence a benchmarker may need information from legal counsel before

13

pursuing sensitive information from competitors and non-competitor (Butler and Tonkin, 1994), however, quoting Michael J. Spendolini, Ph., during the recent San Diego seminar on "Benchmarking: A Key to Business Excellence.", concluded that there are no antitrust lawsuits or inter-organizational suits as a result of benchmarking.

Objective 2: Structural Requirements The next step is to begin to answer questions around identifying the structural requirements for implementing the application within the current company structure and capabilities. This Software App development is Information Technology driven, therefore the requirements will beam its searchlight on the IT infrastructure and support system which deals with the extent to which the app would leverage any assets already available to the company or the end user, and the new assets which would be required to support the app, personnel availability and skill level or outsourcing to external service provider, and the client’s system capability to control deviations and manage emerging risk. Good structural requirements should define how the application will interact with system hardware, other programs, and human users in a wide variety of real-world situations.

2.2. System Environment Analysis Lack of understanding about business situations and system requirements always results in less than optimum design. The analysis of the system environment provides the basis for the analysis of structural requirements. The analysis of the system environment will show the possibility of marrying the app requirements with the client’s existing IT infrastructure. This consists of interacting subsystems that are part of the operative business (Singer et al., 2009), and help incorporate the B2B application within the existing system environment (MacLean et al., 2004).

This is a social-technical problem which has a great impact on elicitation, represented by the difficulty of expressing tacit knowledge, of making explicit what is rather implicit and situated in the customers’ business and working environment (Damian, 2000), and usually results in statements about requirements that are ambiguous, incomplete and subject to multip le interpretations (Curtis et al., 1988). For Instance, Berry (1994) thinks the traditional approach of the requirements engineer's interviewing members of the client's organization does not expose what people really do, because people cannot describe what they really do very well, and direct questioning does not ferret out tacit assumptions very well because the questioner does not know

14

what to ask. Instead, Karen Holtzblatt suggests contextual inquiry in which the requirement engineer becomes a functioning member of the client's organization long enough to blend in and to observe by himself or herself what really happens and to learn about unspoken assumptions the same way that any new employee learns the ropes. More so, Crawford (1994, p. xix) points out the resistance of users to give up their current work pattern or tradition, and concerns of the managers being buffeted by unprecedented levels of environmental turbulence and change (Freeman and Mcvea, 2001), and uncertainties that possibly could heighten their fears and apprehension. Thus, it’s very critical to communicate with the end users, collaboratively analyze their work environment and clearly understand the rationale for their requirements in the context of application domain knowledge.

Fundamentally speaking, system environment analysis starts with identifying 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). This can be done through interviewing and interacting with the IT representative or process owner, or the IT provider in case the system is outsourced, and having brainstorming sessions of system manual review with the end-user in a situation where there is incomplete understanding of the system capabilities and limitations, in order to lay bare the existing IT service, security and support processes which also have to be considered during the implementation of the B2B application.

2.2. Personnel Analysis However robustly sophisticated a system is, well-trained, skillful people are needed to run it, and it’s 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, that a self-initiated project is executable (Project Management Institute, 2013). So, the personnel analysis has to evaluate client’s employees’ skills in relation to the roles to play during the software implementation, how the project team will be structured and project organization incorporated into the larger organization.

The personnel analysis will compare the necessary tasks and roles with the human capital of the client and lay bare the exact personnel requirements for the project (Otero et al., 2009); in essence, it’s the client’s actual state analysis which compares what is needed with what is available in terms of employee’s capabilities. Data from the functional requirements analysis and the system environment analysis are fed into the project role planning process in order to define all relevant

15

project roles and align them with the client’s project. Therefore, there is need to formalize the skills and capabilities of each team member – managers, developers, support personnel, practitioners, experts, customers and users – to assure that the project team is effective and efficient (Humphrey, 1998; Slomp and Molleman, 2002). And as a follow-up process, training can then be conducted to close the skill gaps thrown up, or recruitment of qualified personnel to close the shortfalls where necessary. This can be achieved through, for instance, as proposed by Acuna (2002) a “Capabilities-“Oriented Software Process Model” which entails formalization of the capabilities or behavioural competencies of the people who perform the development activities, or using the organogram of the organization (client), position descriptions as well as a possible personnel data base, and sometimes by having an interview with the CEO or deploying HR principle could deliver further insights (Project Management Institute, 2013).

Failure to rigorously analyze the people factor in the process of requirements elicitation represents the risk of developers performing activities that are beyond their capabilities, and the consequence can only be developing a software app that falls short of performance expectations. However, this process of personnel analysis has got its own challenges, ranging from client’s operational demand of the project team at variance with their availability for project, people’s behavioural competencies or characteristics of professional conduct influencing the effectiveness and efficiency with which they perform a predetermined role in the software process (Acuna, 2002), and the ability to break down all project roles in a new project.

2.2. Risk Identification and Analysis Risks implies future uncertainty about unplanned deviations from initial objectives; every project has got its own risks and it’s absolutely impossible to eliminate them entirely, however the common aim is to identify and control them (Nicholas and Steyn, 2012) in order to lessen the impact should they occur. Project risks can be caused by multiple elements and can occur at each project stage (Lock, 2013) and they can be caused by internal or external factors (Maley, 2012), but must not be ignored as they potentially can increase the likelihood of project failure (Ropponen and Lyytinen, 2000). Software risk management efforts begin with Risk identification in brainstorming sessions with all relevant stakeholders where a checklist of all possibly identified and collated project risks is developed. Ropponen and Lyytinen (2000, p. 99) suggest the use of Boehm’s list can be

16

consolidated on to determine risk sources on any project because it has been compiled by probing several large software projects and their common risks and is thus empirically grounded. Though it forms an inductively derived collection of risk items and thus lacks a theoretical foundation, it provides a simpler basis for developing instruments to measure software risk. Some of the risks items that can be identified include deadline effect, completion in time, project cancellation, managing project complexity, personnel shortfall, insufficient expertise, cost overrun, etc. Ropponen and Lyytinen (2000, p. 99) broadly categorized software risk components thus: scheduling and timing risks, system functionality risks, subcontracting risks, requirement management risks, resource usage and performance risks, and personnel management risks. Next is analysis and evaluation of identified risks for their likelihood of occurrence and their impact, ranking the likelihood on an ordinal scale of high, medium, low, as well as a quantitative cost estimation for the risk impact (Maley, 2012; Passenheim, 2009) which are put together in a risk assessment matrix, an important part of the risk management decision-making process that is used to consider the category of probability or likelihood against the category of consequence severity, and making judgments on the tolerability of the risk on the basis of the analysis while considering influencing factors.

This process of risk assessment requires a lot of time and is inundated with a lot of challenges like lack of common definition of critical terms, lack of established ground rules for conducting the risk assessment, lack of technical understanding of the organization, function, or process being assessed, etc.!

Objective 3: Resources Requirements Resource requirements are often a collection of one or more resource capabilities that are needed in order to complete the work efforts. Every project has limited resources for their execution in terms of time (schedule), financial, and human constraints, coupled with requirements being subject to significant iteration as the business environment changes, business needs change, and new requirements are identified (Firesmith, 2004), hence a need to prioritize and plan towards the optimal use of the available resources. Rigorous and successful analysis of structural requirements for implementing a mobile B2B application serves as a pedestal to conducting classical project management planning to determine the required resources that would be needed on the project. This analysis is focused on determining the project Schedule and Cost for its life cycle using the

17

Work Breakdown Structure that enables the use of Gantt chart and Life-Cycle Costing Analysis respectively.

2.3. B2B Software Project Schedule Planning Tight project schedule estimates is confronted with a special challenge as a result of high complexity and dependency on uncertain proceedings (Lock, 2013), therefore to have a general overview of how long the project would last, the project schedule planning process is very key, as the schedule resulting from the process provides guidance and direction on how the project tasks will be managed to time (Project Management Institute, 2008). Bad scheduling destructively influences the time of completion and quality of project output. The project schedule connects the scope, work estimates and deadline into a network of task, hence all the work structure has to be broken down into work packages and elementary activities using the Work Breakdown Structure (WBS) technique and time of completion is assigned to each task. The B2B Software Development project is complex, usually defined with hundreds of activities, thus WBS helps to organize the activities in some way to allow communication of plan information to others and to maintain an understanding of the various aspects of the project (De Marco, 2011).

With the understanding of the work breakdown structure, information about all tasks and processes within the project is gathered, while dependency and relationships between different phases and tasks are evaluated and then fed into drawing the Gantt chart (Maley, 2012), either developed by using a template manually or the Gantt Chart Software. The Gantt chart is an activity-based network/graphical representation of a project which displays events and milestones of a project, the duration of each event or project, where tasks overlap with others and by how much, the start and end of the entire project. Well detailed Gantt chart shows the start and finish time for all activities (Passenheim, 2009), and considers costs and resource constraints for the individual project steps (Nicholas and Steyn, 2012). With respect to Company X, expertise in software engineering projects, software engineering case study examples, and published estimation data greatly contribute to determining the approximate required time (Project Management Institute, 2013).

2.3. Project Life-Cycle Costing Analysis. Forecasting project cost at completion is of great importance to project management success. It is a forward-looking tool to assist Project Managers with the task of making timely and appropriate decisions about cost outcome of their in-progress projects (Fleming and Koppelman, 2006).

18

Project Life-Cycle costing is a technique deployed to estimate how much the entire project would gulp, including the cost associated with acquiring, using, caring for and disposing of physical asset including studies, research design, development, production, maintenance, replacement and disposed as well as support training and operating cost generated by the acquisition, use, maintenance and replacement of permanent physical assets (Bengaluru, 2016), and many of these costs are not obvious without an appropriate analysis (Eckardt, et al., 2014). These project costs, categorized into initial cost, operating cost, and disposal cost, requires a rigorous cost analysis that will help the client make a good financial decision towards cost optimization and prioritizat ion, and project alternatives that fulfill the same performance requirements, but differ with respect to initial costs and operating costs, have to be compared in order to select the one that maximizes net savings.

LCC Analysis is dependent on the result of the project schedule planning process as an input, taking into consideration the cost of all materials, tasks and overhead (Passenheim, 2009). These data are collected and rolled up using the bottom-up approach which applies this activity-based costing until all costs are accumulated. This process is usually eased by using estimation software fed with market-based data; however, unreliability of data could introduce error into the calculation and lack of trust in the whole process, but it must be noted that flexibility is allowed in the planning process as it gets progressively elaborated and so some tolerance is given to accommodate changes.

19

Chapter 3 – Study Gantt Chart

Software Development and Project Management are complementary and aim at achieving a common goal. For developers and project managers to communicate efficiently, there is need for a common language that balances system performance, quality, stakeholder expectations and needs. Project development systems often use a project structure to describe a given project. In general, a project structure maps real-world aspects of a project, such as timelines and tasks, into an electronically accessible format. For example, many project development systems describe a start, finish, and other schedule dates of a project, the tasks that are performed and the results that are achieved during the project, and the data objects that are generated by the project or used to complete the project. A Gantt chart is an example of a project structure that can be used to describe a given project; it is a graphical representation that shows the time dependency of several tasks of a project within a calendar, and provides a graphical illustration of a schedule that helps to plan, coordinate, and track specific tasks. Time planning and scheduling is considered to be one of the main purposes of Project Management to control vagueness and uncertainty (Shi and Blomquist, 2012, p. 504; Weaver, 2007, p. 4), and a great number of tools exist for the purpose of scheduling, including Work Breakdown Structure, earlier described in this study, is used to divide the project into manageable segments in an organisational chart to provide a plan of what needs to be accomplished and delivered; it is the basic project-planning tool (Garel, 2013, p. 667; Kenley and Harfield, 2014, pp. 887; Kostalova and Tetrevova, 2014, p. 680; PMI, 2017, p. 570).

However, for the purpose of this B2B Software Development project, we will be using the Gantt chart, a feature of the Microsoft Project Office, the most widely used PM software tool for scheduling (Gelbard, et al., 2002, p. 462; Hebert & Deckro, 2011, p. 21; Jugdev, et al., 2013, p. 538). A Gantt chart shows activities and dates on the axes to draw activity durations in form of bars according to start and finish dates (PMI, 2017, p. 707, Gantt, 2020). All in all, in traditional Project Management, Gantt Chart provides an overview of the process of the consulting project for client, consultant and stakeholders; it helps to organize and split up the work in projects and enable dynamic control over the actual process, which is why they are so valuable in traditional project management and the most commonly used tools (Gelbard et al., 2002, p. 467; Jugdev et al., 2013, p. 537; Kenley & Harfield, 2014, p. 887; Milosevic and Iewwongcharoen,

20

2004, p. 3; Shi and Blomquist, 2012, p. 504). However, the Gantt chart must not be viewed as representing ‘project management’; Chart alone is a blunt instrument.

The Gantt chart defines time demands, portray succession, dependencies, availability, and performance of resources to estimate the duration of activities and the project as a whole (Kostalova & Tetrevova, 2014, p. 680). This study has been scheduled to take six months, from June 29 through December 9, 2020, beginning from client briefing and kick-off meeting which respectively provide the platform for sharing the high level requirements and how they conceptually meet the business needs, and initiating the formal start of the project. And as the project continues to run, status and progress meetings will be held, especially before and after every milestone, to share work performance information about the project with the critical stakeholders for feedbacks. The dependencies are shown as “Finish-to-start” dependencies, which means that they illustrate which steps must be completed before the dependent and following step can begin. For instance, sub-tasks under structural requirements are dependent on completing the activities that make the functional requirements, while system environment analysis can run concurrently as risk identification and analysis. The first 21 weeks are scheduled for requirements gathering and analysis, but the last 2 weeks are scheduled for preparing the report for the final requirements document which will include making presentations to the client and making recommendations for further actions. Towards project closure and final release of resources, an evaluation meeting will be held with the client to provide improvement feedback and to update the lessons learnt note.

The Gantt chart shown in Figure 4 immediately below illustrates the sequence of tasks in the requirements elicitation process for the B2B Mobile Software Development, their durations, and dependencies. The task ID orientates and distributes the dependencies with each time constraints. The chart legends represent different key things to note in the Gantt chart; for instance, the critical path showing maximum duration of the project, deadlines, milestones, and symbols differentiat ing start only and finish only. Most processes are preceded by on one another; the Gantt chart does not provide much space for slack time because no delays are expected.

21

22

Chapter 4 – Contribution

Following-up on the supportive evidence section, we will be dealing with the question of how the individual techniques contribute to the identified objectives and the overall aim of eliciting all the. Evidences from industry and case studies are combined with the insights gained while using or investigating the particular techniques.

One of the most difficult aspects of a project is to understand, extract, and solidify in documented form the requirements of a project (Smith, 2000). Valuable resources are continuously being wasted on ill planned, mismanaged, and failed information technology (IT) projects. However, this study help the client have a general overview of the project’s requirements and direction, and equip them with the capacity to make the right decisions. Decisions to make or buy, to go or not to go, what resources to acquire sufficiently, and how to deal with identified risks should they occur in the course of the project implementation phase. If the client considers he has the capability to undertake the project based on the scoping study, the study already provides the first step of the project planning and requirements elicitation phase, thus saving time and money.

Stakeholder Analysis Software development involves huge amount of stakeholders/end users – the individuals or groups that can influence or be influenced by the success or failure of a software project (Nuseibeh and Easterbrook, 2000). These stakeholders include customers who pay for the system, users who interrelate with the system to get their work completed, developers who design, build, and preserve the system, and representatives who impose rules on the development and action of the system (Sharp et al., 1999, Nuseibeh and Easterbrook, 2000). They have diverse needs, which may conflict.

Stakeholder analysis typically deploys a range of techniques and tools to identify and understand the needs and expectations of these major interests inside and outside the project environment as discussed in chapter 2 of this study. For instance, its application and importance are found throughout every knowledge area of the PMBOK Guide (PMI, 1996). Critical to strategic planning and project success is understanding the attributes, interrelationships, interfaces among and between project advocates and adversaries, and as Smith (2000) describes it, “herein lies a large portion of our project risk and viability, and ultimately the support that we must effectively obtain

23

and retain.” Identification and understanding of stakeholders are critical for the subsequent quality of the software (Pacheco and Garcia, 2012), and only then can the software sufficiently fulfil its value-based requirements (Babar, et al., 2015) and makes the project manager reach a certain level of being “politically astute and street smart”, as Smith (2000) puts it, because it requires multip le skills to discriminate among project groups and help develop potential coalitions of support or, if necessary, reduce the impact of unseen opposition.

Project abandonment has become a predominant option for troubled projects (Montealegre and Keil, 2000), a common and costly problem among IS projects (Ewusi-Mensah and Przasnyski, 1995), therefore studying project abandonment from a stakeholder perspective is important because the development of an Information System project requires the effective participation of diverse stakeholders (Pan, 2005), and fulfilling the expectations of relevant stakeholders is an integral part of Information System project success (Lyytinen and Hirschheim, 1987). Stakeholder Analysis is of great value in decision-making throughout the project development process, especially with regard to managing relationships with stakeholders.

Software Benchmarking There exist a growing number of developers of B2B mobile applications in different industries, therefore it’s important to benchmark applications to elicit the different functionalities that are necessary for their development, thus helping the client compete favourably in the market, and especially for proper resource utilizatio n (Rawassizadeh, et al., 2011). When developing software, it is essential to evaluate its performance and stability, making benchmarking an essential and significant part of the software development cycle (Wright, et al., 2005).

Benchmarking shows that a system is useful or provide insight into how systems behave, including the gaps that exist compared to industry standard, and therefore it is important to compare such performance behaviour with those of competition. Ojala and Tyrväinen (2008) suggest that examining and adapting software best practices can help companies succeed in highly competitive markets. Benchmarking is so critical to staying ahead of competitors that O’Dell (1994), the author of “Out-of-the-box benchmarking,” advises firms to consider benchmarking more than competitive analysis. An organization that wants to become and remain world-class should establish external as well as internal benchmarks. Since an organization does not exist in the vacuum, a firm striving to become a world-class competitor must compare itself to the best – if best practice is found in another company within the same industry, or even in a different and

24

seemingly unrelated industry, then that best-practice should be the basis for the benchmark(s) established. Benchmarking is striving to be the best!

Pang, et al., (2009) successfully applied benchmarking to the requirements elicitation process of a website development project, while Loo (2003) successfully applies benchmarking for technical aspects in a project, which respectfully demonstrate that benchmarking is a useful tool in assessing IT-based requirements and suitable in complex projects. In the functional requirements elicitatio n of Company X’s B2B mobile application development project, benchmarking can provide valuable industry insights of already existing and adopted software in the food business industry, and complementing the requirements already addressed in the stakeholder analysis to achieve a competitive cutting-edge app product.

System Environment Analysis Sauter (2000) theorises that in order to understand the relationship between inputs, output, and processes, you need to understand the environment in which all of this occurs. The environme nt represents everything that is important to understanding the functioning of the system, but is not part of the system. There are five components that need to be considered when defining the system: people, organization, data, technology, and type of decision. Lack of understanding of the infrastructure’s potential can result in disappointment based on unrealistically high expectations for system excellence, which cannot be solved in purely technological way but in combination with the social context which is more crucial than design and programming phase (Damian, 2000). The information so gathered in this process is prepared as a before & after graphic of the IT environment which will enable an understanding of the modules that will be affected by the new application and what additional interfaces and tools would be necessary to allow an automated data exchange towards effective usage of the application. It also provides the basis for possible changes by adoption or adaptation and reveals the capabilities and possible skill gaps of the end - users. The result of this analysis serves as an input to the next stage of this requirements elicitat ion, the personnel analysis. Furthermore, Charette (2005) summarizes that from 5 to 15 percent of the IT projects initiated will be abandoned before or shortly after delivery as hopelessly inadequate and many others will arrive late and over budget or require massive reworking, thus contributing to IT difficulties and insufficient changes which can potentially lead to lost business opportunity, but can also be avoided through a systematic analysis of the client’s IT infrastructure.

25

Personnel Analysis Despite advances in technology and major shifts in economy, human resources remain an organization’s most valuable resource (Saraswathy, et al., 2011), but critical to provide answers to is whether the organization has the qualified number of personnel to manage the product of the project. It is nice to have great processes, tools and systems (Medina, 2013). Software development is recognized as a human centric and socio-technical activity (Casado-Lumbreras, et al., 2011) affected by personnel factors, which employs software practitioners who possess high levels of education, specific skills as well as the ability to apply skills to identify and solve problems (Ryan and O’Connor, 2009). The same applies to an organization deploying IT-based system to run their operations.

As a purely intellectual product, software is among the most labour-intensive, complex, and error- prone technologies in human history (Kumaresh and Ramachandran, 2012; Nggada, 2012) and greater complexity increases the possibility of errors, because no one really understands all the interacting parts of the whole (Ogheneovo, 2014), therefore a well-grounded personnel analysis will be required to identify skill gaps and fill. It is also critical for the person in charge of the technical aspects of the project to have experience with the type of system being built (Dorsey, 2000). Though, such a resource is quite expensive, but not nearly as expensive as a failed pro ject. Firesmith (2004) also suggested that consideration be given to the project scope and, hence need for the required staffing strength to avoid schedule overrun.

Risk Identification and Analysis Like every other project, software development suffers chronically from cost overruns, project delays, unmet user needs, and unused systems (Brook, 1975; Lyytinen and Hirschheim, 1987), and this has continued despite huge advances in development techniques, tools, and software technologies (Griffith and Newman, 1996), yet these difficulties have been alleviated through software risk management (McFarlan, 1982, Passenheim, 2009) in a process that critically identify the project risks and analyse them. Industries perform risk analysis and are assisted by identifying risks at the outset of a project undertaking. This study identified the various risks involved in mobile application creation (Kakkar, et al., 2012). Joorabchi, et al. (2013) investigation show that threats such as handling different diverse platforms arise when designing mobile applications. It is therefore of great importance for the client to have an overview of the risks and required countermeasures to assess

26

the capabilities of the firm to mitigate the risks. Risk analysis provides insight in develop ment of applications for mobile devices, and deals with issues related to associated risks.

B2B Software Project Schedule Planning Project schedule planning is critical to the success of a software project as it caters for the project time and timing, and the work packages that make the entire project, including human resources to be assigned to each task at every phase of the project. In terms of time planning, bottlenecks created through poor management responses and inaccurate time estimates can cause late delivery, and hence also negatively impacts the project costs (Hazzan and Dubinsky, 2007). Charette (2005) emphasises the necessity of an appropriate project time planning technique for the appropriate estimation of temporal requirement in that it is a factor that contributes greatly to IT project failure. Rand (2000) is concerned about building safety time into each estimate, this would imply that when all activities are linked together, there should be a high probability of completing on time. Yet why do we see a high proportion of overruns? According to Goldratt (1990), the answer again lies in management's understanding of the psychology of the workforce, because the employees know that safety time is built into the estimates, they think that they do not need to worry about starting on time. Project time planning helps manage the project to time and avoid delay that would lead to unplanned increase because unplanned resources would be needed, therefore proper time analysis helps with reasonable time estimation and can prevent the client from having wrong time assessment and associated risks.
Project Life-Cycle Costing Analysis Software cost estimation is critical for the success of software project management (Li, et al.,

as it affects almost all management activities including resource allocation, project bidding, and project planning (Pendharkar et al., 2005; Auer et al., 2006). The importance of accurate estimation has led to extensive research efforts to software cost estimation methods. Project Life- Cycle costing is a technique deployed to estimate how much the entire project would gulp, including the cost associated with acquiring, using, caring for and disposing of physical asset including studies, research design, development, production, maintenance, replacement and disposed as well as support training and operating cost generated by the acquisition, use, maintenance and replacement of permanent physical assets (Bengaluru, 2016), and many of these costs are not obvious without an appropriate analysis (Eckardt et al., 2014).

27

Vlachý (2014) affirms that Life-Cycle Costing 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. Therefore, a thorough examination of the project cost is required to determine whether the undertaking will be productive or not, and to forestall unnecessary risks and losses before the project begins.

28

Chapter 5 – Concluding Remark

We cannot over-emphasize the importance of Mobile devices in everyday life and business as rapid technology and innovation have evolved and are still evolving. The rising interest for mobile business, followed by the increasing demand for mobile applications has led to a high number of mobile application developments in recent years (Tarasewich, 2003; Urbaczewski et al., 2003), however the development of usable mobile business applications has turned out to be diffic ult (Venkatesh, et al., 2003). One of the major challenges in requirement gathering is selection of method (Mathews, et al., 2008) that is inherited by the complexity of mobile application development. Significant obstacles have arisen for conduction of requirements gathering (Schwartz, 2012), including adaptation of mobile application which requires requirements to be dynamically changing with user preferences, and the speed of this change, which depends on the application domain of the software system under consideration (Siadat and Song, 2012).

Some of the challenges involved in requirements elicitation are stakeholder related (Pa and Zin, 2011) due to involvement of user, staffing and stakeholder in the process; requirements related (Liu, et al., 2010) mostly technical issues which deals with problems like prioritization of requirements, traceability of any particular requirement and schedule overhead in the process; and communication related (Sabahat, et al., 2010) occasioned by different cultural and language barriers issues. Other challenges are knowledge, scope, change, human factor and organizatio n related (Ashraf and Ahsan, 2010), including perspective of requirements gathering in terms of research challenge (Antunes, et al., 2013), uncertainty of requirements in almost all intellige nt systems (Siadat and Song, 2012), and requirements verification activity during scope definitio n that widely covers method and technique. Though enterprise applications can be based on a remarkable number of different features and implementing technologies, the task of capturing and managing data (Draheim and Weber, 2005) follow the same approach and methodology as has been captured in this study

This scoping study has provided answers to these myriads of challenges through the scientifica lly approved holistic approach to the requirements elicitation process, detailing application instructions and intimations regarding possible problems, and is tailored to the client’s individual and specific requirements so that they take delivery of a study output fit for their catering business

29

needs. Requirements elicitation and system analysis is especially important for the success of enterprise application development projects. Based on the business needs, the requirements are elicited through a structured project management approach, drawing experiences from prior software development projects and cases to validate the appropriateness of the techniques and approach used in examining and clarifying the objectives needed to meet the business requirements, hence suitable for the development of the client’s B2B Mobile Application.

This requirements elicitation process begins with a kick-off meeti

Was this document helpful?