ArticlePDF Available

Abstract and Figures

Requirements engineering (RE) is pivotal and central to every successful software development project. There are several reasons why software projects fail; however, poorly elicited, documented, validated and managed requirements contribute grossly to software projects failure. Software project failures are normally very costly and risky and these could even a times be life threatening also. Projects that overlook RE processes often suffer or are most likely to suffer from failures, challenges and other consequent risks. The cost of project failures and overruns when estimated is quite great and grave. In addition, software project failures or overruns portend a challenge in today's competitive market environment. It affects negatively the image, goodwill, profitability, and revenue drive of companies and decreases the marketability of their products, as well as, the perceived satisfaction of their customers and clients (which also leads to poor loyalty). In this paper, RE was discussed. Its role in software projects success was elaborated. The place of software requirements process in relation to software project failure was explored and examined. Furthermore, project success, challenge and failure factors were also discussed with emphasis placed on requirements factors as they play a major role in software projects' successes, challenges and failures. The paper relied on secondary statistics to explore and examine factors responsible for the successes, challenges and failures of software projects in large, medium and small scaled software companies.
Content may be subject to copyright.
International Review of Management and Marketing | Vol 6 • Special Issue (S7) • 2016
306
International Review of Management and
Marketing
ISSN: 2146-4405
available at http: www.econjournals.com
International Review of Management and Marketing, 2016, 6(S7) 306-311.
Special Issue for "International Soft Science Conference (ISSC 2016), 11-13 April 2016, Universiti Utara Malaysia, Malaysia"
The Role of Requirements in the Success or Failure of Software
Projects
Azham Hussain1*, Emmanuel O. C. Mkpojiogu2, Fazillah Mohmad Kamal3
1School of Computing, Universiti Utara Malaysia, Sintok 06010, Malaysia, 2School of Computing, Universiti Utara Malaysia, Sintok
06010, Malaysia, 3School of Quantitative Sciences, Universiti Utara Malaysia, Sintok 06010, Malaysia. *Email: azham.h@uum.edu.my
ABSTRACT
Requirements engineering (RE) is pivotal and central to every successful software development project. There are several reasons why software projects
fail; however, poorly elicited, documented, validated and managed requirements contribute grossly to software projects failure. Software project failures
are normally very costly and risky and these could even a times be life threatening also. Projects that overlook RE processes often suffer or are most
likely to suffer from failures, challenges and other consequent risks. The cost of project failures and overruns when estimated is quite great and grave.
In addition, software project failures or overruns portend a challenge in today’s competitive market environment. It affects negatively the image,
goodwill, protability, and revenue drive of companies and decreases the marketability of their products, as well as, the perceived satisfaction of their
customers and clients (which also leads to poor loyalty). In this paper, RE was discussed. Its role in software projects success was elaborated. The
place of software requirements process in relation to software project failure was explored and examined. Furthermore, project success, challenge and
failure factors were also discussed with emphasis placed on requirements factors as they play a major role in software projects’ successes, challenges
and failures. The paper relied on secondary statistics to explore and examine factors responsible for the successes, challenges and failures of software
projects in large, medium and small scaled software companies.
Keywords: Requirements Engineering Process, Software Projects, Failure, Success
JEL Classications: L86, M15
1. BACKGROUND
Requirement is a statement about a proposed system that all
stakeholders agree must be made true in order for the customers’
problems to be truly solved. It is an expression of the ideas to
be embodied in a system or an application under development.
Requirement is the statement of system service or constraint
describing the user-level properties, general systems, specic
constraints and needs of clients. However, it may also describe the
attributes and behaviour of a system (Inam, 2015). Furthermore,
Gupta and Wadhwa (2013) stated that requirement forms the
basis for the original assessment and ideas for developing and
validating any product. Krauss (2012) further stated that it is
critical to dening the purpose and process of a project and it helps
to analyse and manage a project. More so, requirement has to do
with capturing the objectives and the purpose of a system. It is the
conditions or the capability needed by users to solve problems or
meet their objectives. The accuracy and quality of requirements
immensely contribute to the success of a project/system
development (Krauss, 2012). Furthermore, quality requirements
are pivotal and key to customer/user product satisfaction (Hussain
et al., 2015; Mkpojiogu and Hashim, 2015; 2016; Hussain et al.,
2016a; 2016b; 2016c; Hussain and Mkpojiogu, 2016a; 2016b;
2016c).
Every project has some basic requirements that denes what the
end users, customers, clients, developers, suppliers or business
(i.e., stakeholders) require from it coupled with some needs of
the system for efcient functioning. Requirement is a key factor
during every software development as it describes what different
stakeholders need and how the system will satisfy these needs.
It is generally expressed in natural language so that everyone
can understand it well. It helps the analyst to better understand
which elements and functions are necessary in the development
Hussain, et al.: The Role of Requirements in the Success or Failure of Software Projects
International Review of Management and Marketing | Vol 6 • Special Issue (S7) • 2016 307
of a particular software project. More so, requirements are
considered as an input to design, implementation and validation
phase of software product development. Thus, a software project
is successful or a failure during software development because of
poor requirement elicitation as well as in requirements managing
process (Peeger and Atlee, 2006).
RE is one of the branches of software engineering. It is the
systematic processes and techniques for requirements elicitation,
requirement analysis, specication, verication and management
of requirements. It is the initial phase of software engineering
process in which user requirements are collected, understood,
and specied for developing quality software products. In other
words, it is a practical and systematic approach through which the
software or system engineer collects functional or non-functional
requirements from different customers/clients for the design
and development of quality software products (Swarnalatha et
al., 2014). Requirements engineering (RE) is an incremental
and iterative process, performed in parallel with other software
development activities such as design, implementation, testing
and documentation. RE process is divided into two main set of
activities; namely, requirements development and requirement
management (Hussain et al., 2016). Software requirement
development mainly covers the activities of discovering, analysing,
documenting, verication and validation of requirements whereas
software requirement management commonly includes activities
related to traceability and dynamic change management of
software requirements (Pandey and Suman, 2012; Swarnalatha
et al., 2014).
Research reveals that software project failures are mainly
due to inadequate requirements, changing requirements, poor
requirements, and impracticable expectations, etc. Nonetheless,
the application of a systematic approach will reduce the
challenges of RE process and the chances of any project failing.
It is also very crucial to gather accurate information about the
proposed system/product and analyse the organizational needs
and practices, document the requirement acquisition and ensure
completeness and consistency with stakeholder requirements
whilst effectively managing conicting requirements (Hussain
et al., 2015; Mkpojiogu and Hashim, 2015; 2016; Hussain et al.,
2016a; Hussain and Mkpojiogu, 2016a). Requirements of software
are captured through RE which is the process of determining
requirements (Cheng and Atlee, 2009). Cheng and Atlee (2009)
mentioned that successful RE involves the discovering of the
stakeholders needs, understanding of the requirements contexts,
modelling, analysing, negotiating, validating, as well as assessing
documented requirements; and managing of the requirements
(Shah and Patel, 2014). There are many researches that identify the
need for the development of quality software that meet the needs
and objectives of the customers and give value to stakeholders
(Wiegers, 2013; Inam, 2015). Asghar and Umar (2010) pointed out
that RE is acknowledged as the rst phase of software engineering
process and it is considered as one of the main phases in software
development. Furthermore, Khan et al. (2014), and Shah and Patel
(2014), asserted that, unclear requirement is the main reason of
software project failures. Khan et al. (2014) said that “RE phase is
difcult and crucial.” Also, Young (2004) stated that the neglect of
RE contributes to project failures. RE impacts productivity as well
as product quality. Thus, it can be stated that RE is an essential
phase for software development (Sankhwar et al., 2014), and
therefore RE practices should be taken into consideration in every
software development project. In this paper, RE process is dened
based on Wiegers (2003). He maintained that RE is composed of
two main activities which are: Requirements development and
requirements management.
According to Kavitha and Thomas (2011), proper comprehension
and management of requirements are the main determinants of
success in the process of development of software. In this paper,
secondary statistics from previous studies were closely examined
and used to assess and succinctly understand why software projects
succeed or fail.
In summary, there are many reasons for software project failures;
however, poorly engineered requirements process contributes
immensely to the reason why software projects fail (Inam, 2015).
Software projects failure are usually costly and risky and could
also be life threatening. Projects that undermine RE suffer or are
likely to suffer from failures, challenges and other attending risks.
The cost of project failures and overruns when estimated is very
huge. Furthermore, software project failures or overruns pose a
challenge in today’s competitive market environment. It affects
the company’s image, goodwill, protability, and revenue drive
and decreases the marketability, and the perceived satisfaction
of customers and clients (which leads to their poor loyalty to the
company and their products) (Hussain and Mkpojiogu, 2016a;
2016b; 2016c; Hussain et al., 2016b).
The remaining part of this paper is presented as follows: Section 2:
Why software projects succeed or fail; Section 3: The role of
requirements in software projects success; and lastly, Section 4:
Conclusion.
2. WHY SOFTWARE PROJECTS SUCCEED
OR FAIL
A software project, as categorized by the Standish Group, can be
successful, challenged, or failed. A successful software project
is one that is completed on time and within allocated budget,
and which has all the originally specied features and functions.
A challenged project is one that is completed but with time and
budget overrun and also with fewer features and functions when
compared to those originally specied. A failed project is one that
is aborted or cancelled before its completion. It is also one that is
completed, but never implemented (Kamuni, 2015).
2.1. Software Projects’ Success, Challenge, and Failure
Factors
The Standish Group study of 2009 reported that only 34% of
software projects succeeded, 44% were challenged and 22%
failed (Kamuni, 2015). The 1995 Chaos report established that RE
practices contributed more than 42% of overall project success.
Likewise, inappropriate RE practices represent more than 43% of
the reasons for software project failure. In addition, many previous
Hussain, et al.: The Role of Requirements in the Success or Failure of Software Projects
International Review of Management and Marketing | Vol 6 • Special Issue (S7) • 2016
308
researchers have identied that 70% of the requirements were
difcult to identify and 54% were not clear and well organized
(Gause and Weinberg, 1989; Asghar and Umar, 2010; Khan and
Mahrin, 2014; Young, 2004; Sankhwar et al., 2014; Wiegers, 2003;
Kavitha and Thomas, 2011; Kamuni, 2015). The 1995 chaos report
lists “incomplete requirements” as the leading cause of software
project failure. The Standish Group reports a low point in 1994
in which only 16% of projects were successful (Wiklund and
Pucciarelli, 2009). Gause and Weinberg (1989) also pointed out
that: (i) Requirements are difcult and challenging to describe in
natural language; (ii) requirements have many different types and
levels of details; (iii) requirements are difcult to manage if they
are not in control; (iv) most of the requirements change during
software development. Taimour (2005) identied the following:
Poor planning including missing dependencies, requirements
changed and not nalized, key requirements missed and high
turnover of top IT manager; as reasons why software projects
fail. The Standish Group chaos report (1994) show that 29% of all
projects succeeded (i.e., delivered on time, on budget, with required
features and function); 53% were challenged (i.e., delivered late,
over budget and/or with less the required features and functions);
and 18% failed (cancelled prior to completion or delivered, but
never used). Figures 1-3 display the project success, challenged,
and failure factors of the Chaos report as republished by Project
Smart. In the Figure 1, user involvement (15.90%), executive
management support (13.90%) and clear statement of requirements
(13%) are the top three factors responsible for project success.
In Figure 2, lack of user input (12.80%), incomplete requirements
and specication (12.30%), and changing requirements (11.80%)
are the top three factors responsible for challenged projects.
In Figure 3, incomplete requirements (13.10%), lack of user
involvement (12.40%), and lack of resources (10.60%) are the
top three factors causing impaired or failed projects. From these
presentations, it is very clear that requirements related issues are
the top factors for affect software project success, challenge, and
failure (impairment).
Furthermore, the 1995 Standish Group chaos report (Project
Smart, 2014) identied user involvement, executive managerial
support, clear statement of requirement, proper planning,
realistic expectation, and smaller projects milestones, etc. as
success factors and reports incomplete requirements, lack of user
involvement, lack of resources, unrealistic expectation, lack of
executive support, changing requirements and specications,
lack of planning, etc. as problem causes. Wiklund and Pucciarelli
(2009) in their study revealed that 25% of projects fail out-right,
20-25% do not meet return on investment and up to 50% require
material rework.
In addition, from the 1995 Chaos report, the gures for failure
were equally disheartening in companies of all sizes. Only 9% of
projects in large companies were successful. At 16.2% and 28%
respectively, medium and small companies were somewhat more
successful. A whopping 61.5% of all large company projects
were challenged compared to 46.7% for medium companies and
50.4% for small companies. 37.1% of projects were impaired and
subsequently cancelled (failed) in medium companies, compared
Figure 1: Project success factors
Source: Project Smart (2014)
Figure 2: Project challenge factors
Source: Project Smart (2014)
Figure 3: Project failure factors
Source: Project Smart (2014)
to 29.5% in large companies and 21.6% in small companies
(Project Smart, 2014).
The Standish Group categorized software companies into large,
medium and small based on their annual income. A large company
Hussain, et al.: The Role of Requirements in the Success or Failure of Software Projects
International Review of Management and Marketing | Vol 6 • Special Issue (S7) • 2016 309
is one with >$500 million in annual revenue. A medium company
is one that has between $200 million and $500 million in yearly
revenue while a small company has between $100 million to
$200 million revenue per year. The Standish Group observed that
only 9% of the projects in large companies, 16.2% of projects in
medium companies and 28% of projects in small companies were
successful. Furthermore, 61% of all large company projects were
challenged. Most of the failed projects were within the medium
scale company category (37.1%) in comparison to large companies
(29.5%) and small companies (21.6%) (Kamuni, 2015). In a related
survey by the Standish Group, the success rate was 24% in large
software companies, 37.2% in medium scale companies and 48%
in small scale software companies. In addition, 69.5% of large
software company projects were very challenging, in comparison
to 52.7% and 60.4% in medium and small software companies
respectively. Also, 39.5% of projects in large software companies
were cancelled in comparison to 45.1% and 31.6% in medium
and small scale software companies, respectively (Swarnalatha et
al., 2015). As could be consistently observed, poor requirements
processes are responsible for software projects challenges and
failures. A good requirements collection and process contributes
to software projects successes.
One of the major causes of both cost and time overruns is restarts.
For every 100 projects that start, there are 94 restarts. This does
not mean that 94 of 100 will have one restart; some projects can
have several restarts (Project Smart, 2014). The most important
aspect of the research is discovering why projects fail. To do this,
The Standish Group surveyed IT executive managers for their
opinions about why projects succeed. The three major reasons
why a project will succeed are user involvement, executive
management support, and a clear statement of requirements.
There are other success criteria, but with these three elements
in place, the chances of success are much greater. Without
them, chance of failure increases dramatically. The survey
participants were also asked about the factors that cause projects
to be challenged. Opinions about why projects are impaired and
ultimately cancelled ranked incomplete requirements and lack
of user involvement at the top of the list (Project Smart, 2014)
(Figures 1-3). Another key nding of the survey is that a high
percentage of executive managers believe that there are more
project failures now than 5 and 10 years ago. This is in spite of
the fact that technology has had time to mature (Project Smart,
2014) (Figure 4).
3. THE ROLE OF REQUIREMENTS PROCESS IN
SOFTWARE PROJECT SUCCESS
RE is the important phase of software development process.
It basically aims at collecting meaningful and well dened
requirements from clients in the proper way. It is important to
develop quality software that can satisfy user’s needs without
errors. It is mandatory to apply RE practices at every stage of
software development process (Swarnalatha et al., 2014). RE
is commonly accepted to be the most important, critical and
complex process in the software development process. A well-
defined requirement is software functionality that satisfies
client’s needs (Inam, 2015). The RE process has the highest
impact on the capabilities of the emerging software product
(Swarnalatha et al., 2014). RE is important because it helps to
dene the purpose of any project by dening the constraints,
specifying the process involved and documenting it. It also
ensures incremental improvement by matching the most effective
measures with the crucial problems. Furthermore, it critically
identies what the stakeholders’ need and helps to make decisions
more efciently, hence providing effective results. The success
or failure of a project is dependent on the accuracy and effective
management of requirements. It is crucial to determine the mix
of effective techniques to use for requirement acquisition and
properly document the process and the requirements to reduce
the challenges and chances of failure. RE should therefore be the
starting point and backbone of any project or decision because
it helps to determine and focus on the objective, match needs
of stakeholders to the product development process thereby
increasing the chances of achieving the best result. However,
it must be managed throughout the entire system or product
development life cycle for project success and the mitigation
of failures.
4. CONCLUSIONS
RE is at the foundation of every successful software project.
There are many reasons for software project failures; however,
poorly engineered requirements process contributes immensely to
the reason why software projects fail. Software project failure is
usually costly and risky and could also be life threatening. Projects
that undermine RE suffer or are likely to suffer from failures,
challenges and other attending risks. The cost of project failures
and overruns when estimated is very huge. Furthermore, software
project failures or overruns pose a challenge in today’s competitive
market environment. It affects the company’s image, goodwill,
and revenue drive and decreases the perceived satisfaction of
customers and clients. In this paper, RE was discussed. Its role in
software projects success was elaborated. The place of software
requirements process in relation to software project failure was
explored and examined. Also, project success and failure factors
were also discussed with emphasis placed on requirements factors
as they play a major role in software projects’ challenges, successes
Figure 4: Executive managers’ perceptions on project failures
Source: Project Smart (2014)
Hussain, et al.: The Role of Requirements in the Success or Failure of Software Projects
International Review of Management and Marketing | Vol 6 • Special Issue (S7) • 2016
310
and failures. The paper relied on secondary statistics to explore
and examine factors responsible for the successes, challenges and
failures of software projects in large, medium and small scaled
software companies.
In conclusion, the success or failure of any given software
development project hinges on how the software requirements
process was carried out. The cost or the risks involved in
a poorly engineered requirements process are great and
sometimes irreparable. RE stands as a bedrock upon which
the success of software projects stands. Colossal wastes can
be avoided if adequate attention is given to proper RE in all
software development projects. In this paper, the connection
of requirements to project success or failure is established and
emphasized using secondary data analysis from previous studies.
As could be consistently observed, poor requirements processes
are responsible for software projects challenges and failures while
on the other hand, a good requirements collection and process
contributes to software projects successes. Thus, it behoves of
software project planners, analysts, engineers and managers to
incorporate adequate RE process in every software development
project to achieve project success and eliminate project failures
and challenges.
5. ACKNOWLEDGMENT
This study was funded by Ministry of Higher Education under
RAGS grant.
REFERENCES
Asghar, S., Umar, M. (2010), Requirement engineering challenges in
development of software applications and selection of customer-
off-the-shelf (COTS) components. International Journal of Software
Engineering, 1(1), 32-50.
Cheng, B.H.C., Atlee, J.M. (2009), Current and future research directions
in requirements engineering. Design Requirements Engineering:
A Ten-Year Perspective. Heidelberg: Springer.
Gause, D.C., Weinberg, G.M. (1989), Exploring Requirements: Quality
Before Design. New York: Dorset House.
Gupta, S., Wadhwa, M. (2013), Requirement engineering: An overview.
International Journal of Research in Engineering and Technology,
1(2), 155-160.
Hussain, A., Mkpojiogu, E.O.C. (2016a), An application of Kano method
in the elicitation of stakeholder satisfying requirements for an e-Ebola
awareness system. International Journal of Systems Applications,
Engineering and Development, 10, 169-178.
Hussain, A., Mkpojiogu, E.O.C. (2016b), Requirements model for an
e-health awareness portal, 1st International Soft Science Conference
(ISSC’16), Langkawi Island, Malaysia, 11-13 April, 2016.
Hussain, A., Mkpojiogu, E.O.C. (2016c), Predicting the perceived worth
of software products requirements with customer satisfaction.
Advanced Research in Engineering and Information Technology
International Conference (AREITIC’16), 31 May - 2 June, 2016,
Bandung, Indonesia.
Hussain, A., Mkpojiogu, E.O.C., Abdullah, I. (2016a), Investigation
of Current Requirements Engineering Practices Among Software
Developers at the Universiti Utara Malaysia Information Technology
(UUMIT) Centre. 1st International Soft Science Conference
(ISSC’16), Langkawi Island, Malaysia, 11-13 April, 2016.
Hussain, A., Mkpojiogu, E.O.C., Hassan, F. (2016b), Assessing
the inuence of self-reported requirements importance on the
perceived quality of proposed software products. 2nd International
Conference on Information and Communication Technology for
Transformation (IC-ICT4T’16), 5-7 April 2016, Kota Kinabalu,
Sabah, Malaysia.
Hussain, A., Mkpojiogu, E.O.C., Husin, Z. (2016c), Requirements:
Towards an understanding on why software projects fail.
1st International Soft Science Conference (ISSC’16), 11-13 April
2016, Langkawi, Island, Malaysia.
Hussain, A., Mkpojiogu, E.O.C., Kamal, F.M. (2015), Eliciting user
satisfying requirements for an e-health awareness system using kano
model. Proceedings of the 14th WSEAS International Conference
on Computer and Computational Science (ACACOS’15), Kuala
Lumpur, Malaysia.
Inam, A. (2015), A Study of Requirements Engineering Practices Among
Software Developers at UUM Information Technology. MSc.
Dissertation Report. Malaysia: Universiti Utara Malaysia.
Kamuni, S.K. (2015), Study of Factors that Induce Software Project
Overrun Time, Mechanical and Manufacturing Engineering.
Paper, 10.
Kavitha, C.R., Thomas, S.M. (2011), Requirement gathering for small
projects using agile methods. IJCA Special Issue on Computational
Science-New Dimensions and Perspectives, 3, 122-128.
Khan, H.H., Mahrin, M. (2014), Factors generating risks during
requirement engineering process in global software development
environment. International Journal of Digital Information and
Wireless Communications (IJDIWC), 4(1), 63-78.
Krauss, E. (2012), Requirement Engineering and Project Management.
Heidelberg: Springer.
Mkpojiogu, E.O.C., Hashim, N.L. (2015), Quality-based prioritization:
An approach for prioritizing software requirements. 2015,
2nd Advancement on Information Technology International
Conference (ADVCIT’15), Krabi, Thailand, 3-5 December, 2015.
Mkpojiogu, E.O.C., Hashim, N.L. (2016), Understanding the relationship
between Kano model’s customer satisfaction scores and self-stated
requirements importance. Springerplus, 5(1), 1-22.
Pandey, D., Suman, U. (2012), An effective requirements engineering
process model for software development & requirements
management. International Conference on Advances in Recent
Technologies in Communications and Computing. p287-291.
Peeger, S.L., Atlee, J.M. (2006), Software Engineering: Theory and
Practice. London, UK: Pearson, India.
Project Smart. (2014), The Standish Group, 1995 Chaos Report.
Available from: https://www.projectsmart.co.uk/whitepapers/
chaos-report.pdf.
Sankhwar, S., Singh, V., Pandey, D. (2014), Requirement engineering
paradigm. Global Journal of Multidisciplinary Studies, 3(3), 1-8.
Shah, T., Patel, V.S. (2014), A review of requirement engineering
issues and challenges in various software development methods.
International Journal of Computer Applications, 99(15), 36-45.
Swarnalatha, K.S., Srinivasan, G.N., Dravid, N., Kasera, R., Sharma, K.
(2014), A survey on software requirements engineering for real time
projects based on customer requirements. International Journal of
Advanced Research in Computer and Communication Engineering,
3(1), 5045-5050.
Swarnalatha, K.S., Srinivasan, G.N., Rakesh, R., Dwivedi, V. (2015),
Software Requirements Collection Enhancement Using Sampling
Technique and Applying T-Distribution. Available from: http://
www.ijsetr.com.
Taimour, A. (2005), Why IT Projects Fail. Available from: http://www.
projectperfect.com.au.
Hussain, et al.: The Role of Requirements in the Success or Failure of Software Projects
International Review of Management and Marketing | Vol 6 • Special Issue (S7) • 2016 311
The Standish Group. (1994), 1994 Chaos Report. Available from: http://
www.standishgroup.com/services.php.
Wiegers, K. (2013), Creating a Software Engineering Culture. Reading,
MA: Addison-Wesley.
Wiegers, K.E. (2003), Software Requirements: Practical techniques for
gathering & managing requirement through the product development
cycle. USA: Microsoft Corp.
Wiklund, D., Pucciarelli, J. (2009), Improving IT Projects Outcomes
by Systematically Managing and Hedging Risk: An IDC Insight
Research Document.
Young, R.R. (2004), The Requirements Engineering Handbook. Norwood,
MA: Artech House.
... A study conducted in 2016 [11] ensures that in 70% of the software projects the requirements were difficult to identify and that in 54% of those projects they were not clear or well organized, in addition to other problems associated with the difficulty and challenge of describing requirements in a natural language, the different types of requirements and levels of detail, and the constant change in scope and requirements during the project. In 2014 the Standish Group report [12] revealed that within the failure factors of a software project 13.10% were due to incomplete requirements, 12% ...
... In the requirements survey stage, problems have been identi- the client's need is covered by the system to be implemented [11]. ...
... Correct implementation of RE practices serves as the key base for all other software development activities, and is considered to be vital to the success of software projects. According to [4], a large portion of software project failures are due to poorly elicited, documented, validated, and managed requirements. Accordingly, RE is still receiving much attention from both researchers and practitioners to enhance the overall RE process and to identify more efficient practices. ...
Conference Paper
Full-text available
Requirements Engineering (RE) is critical to the success of software development projects. Industrial software projects that apply poor RE practices usually suffer from severe quality challenges and even project failures. Even though RE has been drawing more attention in the literature, there is a lack of empirical evidence of RE practices and challenges at industrial contexts. To address this we carried out a study to evaluate the perspectives of software engineers on their RE practices to understand more about how software engineers approach RE process and what are the challenges they face. We conducted a multi-case study by interviewing 8 participants from 5 software development companies in Palestine. Our results show that for all the RE process seems to be fairly systematic with whole team involvement. Further, the agile RE model is the dominant model, and over half reported that key challenges are caused by issues that originated from the client side. Finally, we highlight interesting future RE research from the perspective of industrial practitioners.
... In a comprehensive study of the importance of requirement engineering in ensuring the success of a project [6], it was investigated the various methods and approaches to requirement engineering, highlighting the benefits and drawbacks of each. The authors begin by discussing the various challenges that can arise when requirements are not properly defined and managed, such as scope creep, misunderstandings, and project delays. ...
Article
The subject matter of the research is the process of satisfaction with requirements during software development. A qualitative requirements engineering stage for the system being designed to fulfill all business goals, please the client, and eventually satisfy the end user, is one of the key prerequisites for effective implementation of any IT project. The level of satisfaction with requirements must rise as a prerequisite for the project's success through requirement engineering. To ensure that a product or service meets the needs and expectations of its users or consumers, it is critical to satisfy these requirements. The primary purpose of the proposed study is to establish a methodology for quantitatively assessing the satisfaction with requirement level considering various characteristics of requirements before the development phase begins. The tasks to be solved are: to investigate the up-to-date state of the subject area; to develop a methodology for assessing satisfaction with requirements; to provide and investigate the proposed methodology on the real-life example; to recommend actions to increase the level of satisfaction with requirements. The suggested methodology, as opposed to others, considers such characteristics of the requirements as atomic, completeness, consistentness, conciseness, feasibility, unambiguousness, testability, prioritized, understandability, security, and performance to obtain a quantitative assessment of satisfaction with requirements level. The result of this paper is a methodology for quantitative assessing the satisfaction with requirements considering different characteristics of requirements before the development phase begins. This study is significant and necessary since, in the majority of cases, previous research does not offer comprehensive quantitative and measurable methods for determining the degree to which requirements for certain characteristics are satisfied. Also, it is demonstrated how the created methodology may be used with actual requirements. There are additionally recommendations for strengthening satisfaction with requirements. Conclusions. The proposed methodology is extensible, unlike others, which means that the characteristics and rating scale can actually change depending on the requirements, goals, and other features of the IT project.
... The reason for failure of software projects include unsatisfaction from customer due to poor understanding of the requirements. Requirements gathering and understanding is the main factor for the success or failure of the projects [34]. Any business process can be understood in order to better grasp the requirements, and as a result, communication between clients and engineers improves. ...
Article
Full-text available
Software reverse engineering and reengineering are becoming common in the field of games and website development. Simulation and modeling play an important role in understanding the flow of the overall system. Business process modeling notation (BPMN) is used to show the overall architecture of the business process. Simulated business process re-engineering is essential for implementing change or creating new processes. The simulation model explains whether a change will be successful or not prior to adopting any new business processes or other changes. Some available tools help convert the BPMN to a simulating BPMN model but converting the discrete event simulation model build in commercial off the shelf simulation packages like Simul8 to the BPMN to help generate business process simulation to BPMN is also a key challenge. This framework is introduced to convert the simulation model to BPMN using the reverse engineering concept to understand how the converting tools convert the BPMN model to the simulation model. After understanding this process, the concept of reengineering will be used to build a BPMN from the simulation model. The framework is divided into three main parts model translation, model mapping, and model formation. For model building, two simulation tools Simul8 and BPSimulator are used. It is then tested on two case studies bank and product manufacturing. The output shows the BPMN model is generated from the simulation model within less time on a single click saving time and resources for developing BPMN model first and then making simulation model for testing purpose.
... Requirements Engineering (RE) is a critical system development activity that makes or breaks many software development projects (Hussain et al., 2016). A myriad of RE methods, following different paradigms, have been around for at least four decades. ...
Thesis
Full-text available
Over the past few years, the financial industry has been disrupted by innovations that have shaken up the world of money, payments, and economic exchanges. These advances, which include blockchain technologies, cryptocurrencies, programmable money, and the tokenization of assets, create new forms of trust, money, and innovative models for economic exchanges. Although they have the potential to contribute to the evolution and efficiency in the provision of financial products and services, they pose significant challenges regarding the safeguarding of financial stability, the definition of regulatory frameworks and proper governance models. The lack of conceptual clarity in the financial sector domain is arguably one of the reasons behind these problems. An insufficient level of understanding and agreement about a domain harms the communication among the different actors, and consequently, the definition of laws, regulations, and proper governance models. Furthermore, it hinders the ability to properly integrate information and provide semantic interoperability. Consequently, it becomes more difficult to manage risks. In this thesis, we address these issues by means of ontologically well-founded reference conceptual models to make the nature of the conceptualizations explicit, as well as to safely establish the correct relations between them, thereby supporting semantic interoperability. We present the Ontology Network in Finance and Economics (OntoFINE), a network of reference ontologies, grounded in the Unified Foundational Ontology, which provides ontological foundations on money, trust, value, risk, and economic exchanges. We demonstrate the usability and relevance of OntoFINE by applying it to solve real-world problems in the areas of decentralized finance, requirements engineering, enterprise modeling, and game theory.
... III. RELATED WORK Most of the software projects fail due requirement engineering challenges and the poor management of these challenges [15]. Studies show that the project development challenges are 37% (13% poor user input, 12% incomplete requirements and 12% changing requirement) in the requirement phase as illustrated by [16,17]. Poor requirements gathering may cause the improper formation of user stories that ultimately leads to faulty development decisions. ...
... (5) Requirement Quality: Requirement is a statement describing the proposed system where all stakeholders agree must be made true for the customers' problems to be genuinely solved (Hussain et al., 2016). It is essential to create test cases based upon the requirements (Craig & Jaskiel, 2002). ...
Article
Full-text available
A test case is a cornerstone of the testing process; hence, it is quintessential to ensure the quality of the test cases. However, test case design in the Agile testing process has limitations that affect its quality standards, leading to the failure of many software projects. Previous studies are limited in providing a clear guideline for assessing the test case quality. However, evaluating the quality of test cases will help software testing practitioners to understand some critical issues in designing test cases from various perspectives. Therefore, this paper aims to present the verified factors and criteria of test case quality by software testing experts in an Agile environment. The proposed factors and criteria were verified through expert review techniques, which included an online survey of professionals and those in domain and knowledge experts. Twenty-three industry practitioners, including developers, testers, and systems analysts, were used to identify the domain experts. In contrast, the knowledge experts were drawn from 13 academic areas of software engineering and testing. The results showed that the quality of test cases is paramount in Agile projects; therefore, the experts accept seven factors and 32 criteria with a few modifications and suggestions. The finding may assist the researchers in improving the proposed factors and criteria for validation purposes. Hence, may contribute to software testing practitioners as a guideline in constructing, designing, and assessing compelling test cases. Most significantly, the fixed factors and criteria may contribute to the body of knowledge in the software testing domain and industries.
Chapter
Context and motivation: Machine Learning (ML) algorithms and Natural Language Processing (NLP) techniques have effectively supported the automatic software requirements classification. The emergence of pre-trained language models, like BERT, provides promising results in several downstream NLP tasks, such as text classification. Question/problem: Most ML/DL approaches on requirements classification show a lack of analysis for requirements written in the Spanish language. Moreover, there has not been much research on pre-trained language models, like fastText and BETO (BERT for the Spanish language), neither in the validation of the generalization of the models. Principal ideas/results: We aim to investigate the classification performance and generalization of fastText and BETO classifiers in comparison with other ML/DL algorithms. The findings show that Shallow ML algorithms outperformed fastText and BETO when training and testing in the same dataset, but BETO outperformed other classifiers on prediction performance in a dataset with different origins. Contribution: Our evaluation provides a quantitative analysis of the classification performance of fastTest and BETO in comparison with ML/DL algorithms, the external validity of trained models on another Spanish dataset, and the translation of the PROMISE NFR dataset in Spanish. KeywordsSpanish requirementsAutomatic classification requirementsfastTextBETO
Chapter
Traditional businesses face fast‐changing client needs, increased marketplace changing aspects, and the constant appearance of new technological progressions in an increasingly digital world. Faced with the demands of a digital world, businesses are attempting to embrace agile methodologies on a bigger level to satisfy these demands. Researchers were compelled to design new techniques and methodologies to fulfill marketing needs as company requirements grew rapidly. Traditional‐driven development approaches, which emphasize requesting and detailing requirements that take extra time in comparison to changing dynamics of the market, have been superseded by Agile methodology. On the other side, there is a need for a development process where customers can interact and collaborate in teams. Instead of the benefits of agile development and new tools introduction, various challenges are required to be discussed. In the agile software development process, various techniques have been used for improving software quality and reliability. The goal of such techniques is to improve test cases, which leads to cost‐effective and time‐effective software. Particularly, various theoretical perspectives have been provided by researchers on agile software development which contribute rich insights. This work provides a theoretical foundation for ASD. Agile has given an adequate solution to varying requirements of customers in the marketplace; it is built on iterative enhancement, with each line representing its minimal size and independent Software Development Life Cycle (SDLC). Essentially, using agile in the right way necessitates a thorough comprehension of the technique. Despite their benefits, which included a fresh strategy, the ability to adapt to changes fast, new tools, coordination, and cooperation concepts, several obstacles arose, necessitating their resolution. The goal of this article is to discover challenges of putting Agile into reality in digital era. Challenges necessitate answers for agile and its techniques towards progress, therefore novel trends and expansion technologies will now be mirrored in Agile.
Article
Full-text available
Agile development methodology has become popular among software developers. Some non-agile developers integrate certain agile and design thinking practices in their development. Among these practices include identifying personas, creating empathy and journey maps and writing user stories. This research adopts the Design Science Research Methodology, focusing on integrating agile and design thinking practices in generating quality user stories in the design of augmented reality (AR) applications. An integrated development process is modelled and applied in an example application, an AR application for student welfare services events. The study goes through the process of eliciting user requirements by identifying user personas, creating empathy maps and customer journeys and writing user stories as part of the discovery stage of the AR application development. The user stories are evaluated by fifteen agile practitioners based on fourteen criteria adapted from Quality User Story Framework. The user stories are scored and assessed to determine the level of quality.
Conference Paper
Full-text available
Customer satisfaction is highly associated with product quality. It is thus a proxy for the perceived quality of software products. It is a good quality indicator for proposed software products. The place of the perceived satisfaction of users or customers as a reflection or indicator of their perception of the quality of software product cannot be overlooked especially in today software market that is highly competitive. The perceived quality of products serves as a driver for the loyalty of customers and also promotes high profitability, viability of products and return on investment. Therefore, understanding the importance of requirements as it is associated with the satisfaction of users or customers when their requirements are fulfilled is worth the stress considering. It is necessary to know the relationship between customer satisfactions when their requirements are met and the importance of such requirement. So many studies have been done on customer satisfaction in relation with the importance of requirements but the correlation between customer satisfaction coefficients of the Kano model (as a proxy for perceived software quality) and users or customers reported requirements importance have not been sufficiently examined. In this study, an attempt is made to investigate the influence of customer reported requirements importance on the perceived quality of proposed software products. The result of the study indicates a significant relationship between the reported requirement importance and perceived quality of proposed software products (captured using Kano model customer satisfaction coefficients). The analysis indicates that the perceived customers or users requirements importance (that is, the value they place on the requirements/features of the proposed product) positively influences the level of satisfaction such customers derive from the product and their perception of the quality of the product. The importance of a product feature significantly affects the perceived satisfaction customers get from the inclusion of such feature in the product design and construction and thus, their perception of the products quality. Since customer satisfaction (perceived quality) is directly related to the reported requirements importance, it is therefore essential to give adequate place to user or customer satisfying requirements (features) all through the software development lifecycle as this enhances the products perceived quality. Customer reported requirements importance highly accounts for variations in the perceived quality of proposed software products.
Conference Paper
Full-text available
Requirements Engineering (RE) is a systemic and integrated process of eliciting, elaborating, negotiating, validating and managing of the requirements of a system in a software development project. UUM has been supported by various systems developed and maintained by the UUM Information Technology (UUMIT) Centre. The aim of this study was to assess the current requirements engineering practices at UUMIT. The main problem that prompted this research is the lack of studies that support software development activities at the UUMIT. The study is geared at helping UUMIT produce quality but time and cost saving software products by implementing cutting edge and state of the art requirements engineering practices. Also, the study contributes to UUM by identifying the activities needed for software development so that the management will be able to allocate budget to provide adequate and precise training for the software developers. Three variables were investigated: Requirement Description, Requirements Development (comprising: Requirements Elicitation, Requirements Analysis and Negotiation, Requirements Validation), and Requirement Management. The results from the study showed that the current practice of requirement engineering in UUMIT is encouraging, but still need further development and improvement because a few RE practices were seldom practiced.
Conference Paper
Full-text available
Requirements engineering is at the heart and foundation of software engineering process. Poor quality requirements inevitably lead to poor quality software solutions. Also, poor requirement modeling is tantamount to designing a poor quality product. So, quality assured requirements development collaborates fine with usable products in giving the software product the needed quality it demands. In the light of the foregoing, the requirements for an e-Ebola Awareness Portal were modeled with a good attention given to these software engineering concerns. The requirements for the e-Health Awareness Portal are modeled as a contribution to the fight against Ebola and helps in the fulfillment of the United Nation’s Millennium Development Goal No. 6. In this study requirements were modeled using UML 2.0 modeling technique.
Conference Paper
Full-text available
Requirement engineering is at the foundation of every successful software project. There are many reasons for software project failures; however, poorly engineered requirements process contributes immensely to the reason why software projects fail. Software project failure is usually costly and risky and could also be life threatening. Projects that undermine requirements engineering suffer or are likely to suffer from failures, challenges and other attending risks. The cost of project failures and overruns when estimated is very huge. Furthermore, software project failures or overruns pose a challenge in today’s competitive market environment. It affects the company’s image, goodwill, and revenue drive and decreases the perceived satisfaction of customers and clients. In this paper, requirements engineering was discussed. Its role in software projects success was elaborated. The place of software requirements process in relation to software project failure was explored and examined. Also, project success and failure factors were also discussed with emphasis placed on requirements factors as they play a major role in software projects’ challenges, successes and failures. The paper relied on secondary data and empirical statistics to explore and examine factors responsible for the successes, challenges and failures of software projects in large, medium and small scaled software companies.
Conference Paper
Full-text available
Despite advances in the requirements elicitation research, software engineers do not still comprehend what exactly a software system/product should offer to succinctly meet the needs and expectations of users/ customers. There is a relationship between quality and user satisfaction. Eliciting user satisfying requirements contribute to the quality and competitiveness of the product. Requirements, met or unmet, can influence the extent of user/customer satisfaction or dissatisfaction for a product, because in the eyes of users/customers, products with the right functionality that satisfy them implies that such products are quality ones. This aspect of quality consideration is often neglected be researchers and practitioners. Kano Model and its extensions explore an approach that clearly explains how software product requirements/features can influence the level of satisfaction derived from such product as well as the level of dissatisfaction the absence of such requirements/feature in the product could cause in users/customers. This paper explores and applies this model in eliciting requirements for a proposed e-health awareness system. The result reveals that eliciting user satisfying requirement increases the satisfaction level of potential users/customers of the proposed product and also improves the perceived quality of such product in the eyes of the potential users/customers as evidenced from their satisfaction scores and self-stated importance ratings.
Article
Full-text available
Several software requirements elicitation techniques exist and are used in the elicitation of software requirements. However, most of the techniques are limited in that they are only effective in capturing the voice of the customer/user. They are not effective in capturing their mind. There are some kinds of requirements that stakeholders take for granted, not expecting or are not apt to voice out. Such requirements need special requirements elicitation approaches that will probe the psychology of the respondents so as to succinctly collect the needed requirements from them were necessary. Kano model provides a framework that enables the elicitation of these kinds of requirements. More so, it allows appropriate requirements to be elicited that will lead to the satisfaction of stakeholders if the requirements are met or to their dissatisfaction if they are unmet. It categorizes software requirements based on some quality attributes that describes the kind of requirements elicited. The Kano approach also, helps to obtain the perceived quality of the proposed product from the customer/users’ point of view. This method helps to filter out requirements that do not lead to the satisfaction of stakeholders and thus the quality of elicited requirements and the proposed software solution. Kano method, though popular in the interdisciplinary field of quality management, is seldom applied in the field of software engineering, especially in requirements elicitation. In this study, the Kano method was applied in the elicitation of requirements for a proposed e-Ebola Awareness System. The result of the Kano analysis indicated that the elicitation of stakeholders’ satisfying requirements leads to increase in the satisfaction level of potential users/customers of the would-be product. It also indicated improvement in the perceived quality of such product from the viewpoint of the potential users/customers as shown from the customer satisfaction coefficients and the self-stated importance ratings. © 2018, World Scientific and Engineering Academy and Society. All rights reserved.
Article
Full-text available
Customer satisfaction is the result of product quality and viability. The place of the perceived satisfaction of users/customers for a software product cannot be neglected especially in today competitive market environment as it drives the loyalty of customers and promotes high profitability and return on investment. Therefore understanding the importance of requirements as it is associated with the satisfaction of users/customers when their requirements are met is worth the pain considering. It is necessary to know the relationship between customer satisfactions when their requirements are met (or their dissatisfaction when their requirements are unmet) and the importance of such requirement. So many works have been carried out on customer satisfaction in connection with the importance of requirements but the relationship between customer satisfaction scores (coefficients) of the Kano model and users/customers self-stated requirements importance have not been sufficiently explored. In this study, an attempt is made to unravel the underlying relationship existing between Kano model's customer satisfaction indexes and users/customers self reported requirements importance. The results of the study indicate some interesting associations between these considered variables. These bivariate associations reveal that customer satisfaction index (SI), and average satisfaction coefficient (ASC) and customer dissatisfaction index (DI) and average satisfaction coefficient (ASC) are highly correlated (r = 96 %) and thus ASC can be used in place of either SI or DI in representing customer satisfaction scores. Also, these Kano model's customer satisfaction variables (SI, DI, and ASC) are each associated with self-stated requirements importance (IMP). Further analysis indicates that the value customers or users place on requirements that are met or on features that are incorporated into a product influences the level of satisfaction such customers derive from the product. The worth of a product feature is indicated by the perceived satisfaction customers get from the inclusion of such feature in the product design and development. The satisfaction users/customers derive when a requirement is fulfilled or when a feature is placed in the product (SI or ASC) is strongly influenced by the value the users/customers place on such requirements/features when met (IMP). However, the dissatisfaction users/customers received when a requirement is not met or when a feature is not incorporated into the product (DI), even though related to self-stated requirements importance (IMP), does not have a strong effect on the importance/worth (IMP) of that given requirement/feature as perceived by the users or customers. Therefore, since customer satisfaction is proportionally related to the perceived requirements importance (worth), it is then necessary to give adequate attention to user/customer satisfying requirements (features) from elicitation to design and to the final implementation of the design. Incorporating user or customer satisfying requirements in product design is of great worth or value to the future users or customers of the product.
Article
Full-text available
Requirement Engineering is an important phase of any software development. The requirements should be unambiguous (measurable and testable), traceable, consistent, and approved. Now-a-days the importance of security is growing with the rise of phenomena such as e-commerce and nomadic and geographically distributed work. Therefore, it becomes necessary to apply requirement engineering practices in every phase of software development. Requirements engineering for software development process is a complex exercise that considers product demands from several viewpoints, roles, responsibilities, and objectives. In this paper, we propose an effective requirement engineering process model to generate appropriate, accurate, consistent requirements.
Article
The paper investigated principal-agent models and the incentive and restraint mechanism in the management of petroleum projects. The importance of the incentive, supervision and selection mechanism for petroleum project management was discussed. Service companies would not try their best to actualize oil companies'biggest benefits and adverse selection cannot be avoided unless oil majors use effective contracts to prompt contractors. Oil companies can't restrict service companies effectively unless they supervise the contractor's work. In the optimal contracts, incentive index is in the negative correlation with projects' uncertainty, contractor's marginal cost and its risk elusion coefficient, and it is in the positive correlation with contractor's marginal productivity. The factors influencing incentive index can assemble different types of contracts. In the optimal supervision level, when contractor's marginal productivity is high and marginal cost is low, it is easier to supervise and the marginal revenue of supervision is high. It is possible to offset the difficulty of monitoring by reinforcing punishment. Incentive contracts can decrease the harm of adverse selection. Construction of dynamic alliance can further strengthen incentive effect, reduce moral hazard and resolve adverse selection problems.