See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/324997752

Software requirement analysis: Research challenges and technical approaches

Conference Paper · March 2018

DOI: 10.1109/ISDFS.2018.8355322

CITATIONS READS

13 4,516

2 authors:

Senay Demirel Resul Das

Architecht Bilişim Firat University
10 PUBLICATIONS   46 CITATIONS    113 PUBLICATIONS   2,462 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Heart disease View project

Master Thesis View project

All content following this page was uploaded by Senay Demirel on 26 June 2020.

The user has requested enhancement of the downloaded file.

Software Requirement Analysis: Research Challenges
and Technical Approaches
Senay Tuna Demirel Resul Das
NETAù A.ù., 34912, Kurtköy – Pendik Dept. of Software Engineering, Technology Faculty, Firat Univ.,
Istanbul / Turkey 23119, Elazig / Turkey
[email protected] [email protected]

Abstract— Requirement analysis is one of the key challenges in that is accurate and stable throughout the long time intervals
software development projects. Customer requirement of in the SDLC of large and complex systems.
specification and management entails various impacts to software
projects and still is an improvement area on both academic and The two most popular SDLC methodologies, waterfall and
industrial fields. Models like CMMI also uncovers requirement
agile, behave totally different ways in requirement analysis
development and management and specifies the specific goals and
practices for them. In this paper, key challenges and issues of and management. Waterfall tries to analyze the requirements
requirement management are listed with respect to a from the early beginning and does not let implementation
standardization activity, namely CMMI. begin until it is very well understood, documented and almost
froze. Unlike waterfall, Agile methodologies accept the fact
Keywords—Requirement Analysis and Management; Software that requirements may not de detailed enough at the beginning
Delivery Life Cycle (SDLC); Agile; Waterfall; Capability Maturity of the project but they will evolve over time and stakeholders
Model – Integration (CMMI). will gain more insight about what they need [6]. So agile
welcomes the requirement changes but focuses on correctly
I. INTRODUCTION handling them [7]. It allows customers to continuously involve
In software development projects, understanding and in the project and evolve the requirements.
fulfilling the customer needs from the first stage to the
delivery of the project has been recognized as one of the This paper aims first to understand the issues and
biggest challenges among many others [1]. Misunderstanding challenges in software requirement analysis. Throughout the
the customer needs, wrong elicitations and assumptions cause paper, we will try to understand the different approaches for
significant impacts to the projects by means of time, quality requirement management in different SDLC methodologies
and budget. In addition, this is the reason why requirement and examine the standards to understand better what needs to
management is an activity based on a multidisciplinary effort be done for successful requirement management.
that involves marketing, analysis, engineering, product design, The paper is organized into five chapters. After the
verification, and validation. introduction, challenges in requirement management are
Requirements can be classified as (functional) business and identified and listed. Then standardization activity is described
technical (non-functional) requirements [2]. A business by referencing the CMMI model. Moreover, the paper
(functional) requirement commonly specifies a behavior from conclude with a description of technical approaches.
an end-user perspective. It describes a user behavior or an II. CHALLENGES
action that is performed by the user of the system and does not
constrain by any system limitations. Whereas technical
Requirement identification really starts with the initial
requirements specify the result of the end user behaviors. And stage of the projects when business needs are stated and
can be constrained by platform, environment, design begin to be identified. The requirements analysis phase is
limitations or dependencies of the system. Business mentioned as `analysis and planning`[2]. The software-
requirements are general in nature, while requirements at low engineering community had focused its efforts on the
levels in the hierarchy are very specific[3], [4]. problem-analysis phase, which is what many decomposition
There are different approaches in Software Delivery Life methods address [8]. During the planning phase, high-level
Cycle (SDLC) methodologies that welcome the requirement requirements are refined and detailed into technical
changes at any stage or that try to freeze the requirements in requirements. By building a traceability matrix,
the initial stages and tries to avoid any changes in upcoming requirements are committed and mapped into the product
cycles. Requirement engineering is mostly seen an effort to requirements that will be implemented in the design phase.
occur in early stages of development lifecycle [5]. In the Project management and change management processes are
development of small systems, this may be even true. But it highly interrelated with the requirements and used to
seems impossible (in practice) to develop a requirement set

978-1-5386-3449-3/18/$31.00 ©2018 IEEE

manage and control them. In general, the Requirements Requirement Definitions
Management Process covers phases, as shown in figure 1:
Frequently, each of the stakeholders use different contexts
− Identify Requirements; to explain and state the requirements. Differences users in
− Evaluate Requirements; terminology and semantics may weaken the ability to
− Validate and Prioritize Requirements; transfer information from customers to designers effectively.
− Obtain Approval and Baseline; In general, customers or business people tend to use the
− Conduct Analysis and Detailing of Requirements; native language terms to explain the actual need whilst the
− Control Changes to Requirements. technical people want to see the more logical structure to
understand the intended behavior precisely (e.g. Unified
Input 1: Input 2: Input 3:
Modeling Language UML). There should be a distinguish in
Business Needs Regal and Regulatory Needs Product Needs terms of business needs and functional requirements as well
as document them. And that effort should be included in the
Identify
project phases during the early stages of the product
Requirements development.

Evaluate Project Charter Requirement Prioritization

Requirements

Change
In most cases, requirements are negotiable and may
Management
Validate & Prioritize
conflict with one another. Requirements should be reviewed
Process
Requirements
If Yes: Update by key stakeholders, there should be prioritization of all the
If No:
Needs Refining requirements, and conflicting requirements should be re-
Obtain Approval
evaluated. The reviewed and approved priority needs to be
& Baseline documented to make the outcome visible to each participant
If Yes in the project team.
Analysis and Detaling of Requirements

System
Requirements Traceability Matrix
Requirement Changes
Requirements
Specifications
Control There may be changes in existing requirements as project
Requirements
evolve or new requirements may arise. Requirement changes
Revised/Requirements Revised/Requirements have potential impact on project design, plans, resource
allocations or schedule. Each requirement change should be
Figure 1: Requirement Management Flowchart tracked with proper tools/methods in order to make a risk
and affect analysis first and then to decide to handle the
change or not. Each stakeholder should be aware of the
Regardless of how requirement management is processed
impacts and approve the change. Otherwise, it is impossible
(close to the steps above or far beyond) it is related to the
to track the changes and control with a plan within the
elicitation, definition, analysis and specification stages. During
project cycle.
these phases, there have been some challenges faced,
regardless of which SDLC model you reference. Requirement change management has a strong relationship
with baselining [9]. And requirements management is a
Ambiguous Requirements continuous activity that can perform after development and
during maintenance because requirements may continue to
Customer requirements may not be detailed enough at the change [10], [11].
beginning of the project and stakeholders have limited Traceability
insight into what they really need. In most cases, customers'
states the business needs but they do not have any idea of the Traceability is one of the main parts of requirement
detailed scenarios, race conditions or any conflict between management, which refers ability to describe and follow the
different stakeholders needs. So requirements are normally life of a requirement and its relations with other items in
underdeveloped and tend to be ambiguous. Thus, there both ways (forwards and backward) [12], [13].
should be an identification step on the requirement process Requirements traceability will allow tracking the relation
that one of the elicitation techniques (e.g. workshops, from a requirement, to a design component, to a test case
interviews or meetings etc.) are applied. Customer needs and validation procedure that is related to that requirement.
should then analyzed and evolved to compose the business That relationship is critical to understand how a change (or
requirements (from high-level requirements) change request) to a requirement will affect other
requirements, upstream and downstream teams. It should be
implemented so that, whenever any requirement is changed,
all parent and child requirements, software components, and CMMI for Development (CMMI-DEV): Product and service
test cases impacted by the change are identified. development.
CMMI for Services (CMMI-SVC)- Service establishment,
Technical Solution management.
Requirements are direct inputs for the technical solution CMMI for Acquisition (CMMI-ACQ)- Product and service
that will be implemented in the design phase. There should acquisition.
be a mapping between the requirements and software
components to keep an interrelation through the Throughout this paper, we focus on CMMI-DEV, which
development lifecycle. It should be traced how an update in is the model used for software engineering and has two main
a software component or a reported problem in a specific "process areas" for requirements (and will use the term
subsystem, will affect the related requirements. This also CMMI instead of CMMI-DEV). Process areas are defined as
helps the re-use of subsystems or work components to "A cluster of related practices in an area that, when
handle the similar requirements. implemented collectively, satisfies a set of goals considered
important for making improvement in that area." in CMMI
Requirements Verification and Validation Dev v1.3 [15]. There are 21 process areas categorized into 5
maturity levels in CMMI-DEV. (The higher the rating, the
The purpose of requirements validation is to certify that higher the maturity of the organization [4].) Requirements
the requirements are an acceptable description of the system Management is also a process area for CMMI Level 2 and
to be implemented[14]. It should be noted that traceability Requirements Development is required for Level 3, which
from requirements to test cases are also an important area to can be summarized as multi-stakeholder requirements
be covered. Requirements verification consists of those evolution, as shown in Table I.
activities that confirm that the product of a system
development process meets its technical specifications. TABLE I. CMMI PROCESS AREAS [14]
Requirements validation consists of activities that confirm
Level Focus Process Area
that the behavior of a developed system meets its user needs Continuous - Organizational Performance
[12]. Without verification and validation traces, it cannot be 5 - Optimizing Process Management
ensured that the requirements are met or not. Improvement - Casual Analysis & Resolution
- Organizational Process
4 - Quantitatively Quantitative Management
Project Management Managed Management - Quantitative Project
Management
Even when requirement management is handled in initial - Requirements Development
phases of the projects, traceability between requirements and - Technical Solutions
- Product integration
project lifecycle may be getting tight in the later phases of - Verification
projects. There should be a total awareness that requirement - Validation
management is not only required in initial phases of the - Organizational Process Focus
projects but a fully integrated activity throughout the Process - Organizational Process
3 - Defined
Standardization Definition
delivery of the project. The correlation between the - Organizational Training
requirements and risk management, project plans, technical - Integrated Project Management
solution, configuration management, project integration, Risk
verification, and validation project areas should be well - Management
- Decision Analysis &
covered in project management overall. Resolution
- Requirements Management
- Project Planning
III. STANDARDIZATION ACTIVITIES - Project Monitoring & Control
- Supplier Agreement
In this section, CMMI, requirement development and Basic Project
2 - Managed Management
Management
requirement management concepts are outleined respectively. - Measurement & Analysis
- Process & Products Quality
CMMI Assurance
- Configuration Management
1 - Initial
Capability Maturity Model – Integration was developed
by Carnegie Mellon University`s Software Engineering
Institute (SEI) and is known as CMMI. It is basically a Requirement Development
process improvement model that helps organizations to
improve performance, process maturity and achieve the Requirement development (RD) is to understand and
organizational goals[15]. analyze the stakeholder's needs and produce customer,
product and component requirements. It is critical in any
SDLC, as most of the software defects and issues are related aims that they are managed correctly through the life cycle
to incorrect or misunderstood requirements. In addition, of the project. As they may affect the project plans directly
without understanding the exactly customer needs it will be and scope, timeline as well as the budget, REQM specifies
impossible to have happy customers or successful project the appropriate steps to ensure that requirements are
deliveries in spite of all the efforts, time or budget spent. reviewed with appropriate stakeholders, they are well
understood, incorporated into the project plans and are being
RD specifies three types of requirements: customer executed within the plan. Once the requirements are
requirements, product requirements, and product component altered/evolved, there should be a commitment from the
requirements. Whole together these are used to specify the project participants before they are incorporated into the
needs of the stakeholders, applicable to various phases of the project plans. It should be documented with tracked the
SDLC (e.g., verification, validation or acceptance testing) and changes as they evolve and keep traceability between the
attributes of the project (e.g., safety, reliability, and product components and tests.
maintainability). It also specifies constraints caused by the
platform dependencies or selected design solutions (e.g., open
CMMI determines one specific goal for managing the
source code).
requirements and provides five specific practices for that goal,
CMMI describes three specific goals for developing the
which are in Table III.
requirements and provides specific practices for each goal,
shown in Table II. TABLE III. CMMI REQUIREMENT MANAGEMENT PROCESS AREA[15]

TABLE II. CMMI REQUIREMENT DEVELOPMENT PROCESS AREA[15] The purpose of REQM is to manage the requirements of the project's
components and to identify inconsistencies between those requirements
Requirements Development – Specific Goals & Practices and the work products
SG 1 Develop Customer Requirements - "Stakeholder needs,
expectations, constraints, and interlaces are collected and SG 1 Manage Requirements
translated into customer requirements." SP 1.1 Obtain an Understanding of Requirements
SP 1.1 Elicit Needs SP 1.2 Obtain Commitment to Requirements
SP 1.2 Transform Stakeholder Needs into Customer Requirements SP 1.3 Manage Requirements Changes
SP 1.4 Maintain Bidirectional Traceability of Requirements
SG 2 Develop Product Requirements - "Customer requirements SP 1.5 Identify Inconsistencies Between Project Work and Requirements
are relined and elaborated to develop product and product
component requirements."
SP 2.1 Establish Product and Product Component Requirements IV. PRINCIPLES AND TECHNICAL APPROACHES
SP 2.2 Allocate Product Component Requirements
SP 2.3 Identify Interface Requirements
The basic principle while developing a software is “If
SG 3 Analyze and Validate Requirements - "The requirements are requirements are unclear, incomplete or wrong, then the
analyzed and validated." architecture will be equally wrong”.
SP 3.1 Establish Operational Concepts and Scenarios
SP 3.2 Establish a Definition of Required Functionality and Quality The basic principle while developing a software is "If
Attributes
SP 3.3 Analyze Requirements SP 3.4 Analyze Requirements to
requirements are unclear, incomplete or wrong, then the
Achieve Balance architecture will be equally wrong".
SP 3.5 Validate Requirements In order to overcome the challenges and issues in requirement
management, each specific goal related requirement definition
CMMI aims to determine the specific goals first in order to or management– as also stated by CMMI – should be planned
develop the requirements correctly. Then for each specific and handled properly within the SDLC.
goal, it determines the specific practice to achieve the goal. In a waterfall project, requirement specification is the initial
The important point about CMMI is, it is not focused on "how phase of the project. The aim is to define what needs to be
to do" and focuses on "what to do". For example, for delivered to the customer from the beginning and state that
developing customer requirements CMMI specifies that needs clearly so that everyone knows the scope and detailed
should be indicated. However, does not specify how to do that. descriptions. Requirement definition effort ends up with the
Each organization can use its own way to achieve that. collection of documents and diagrams, such as functional
specifications or use case diagrams. These definitions are
referred throughout the delivery of the project and should be
Requirement Management
kept up to date if any change occurs. Change requests often
Required Management(REQM) aims to handle the have a high impact on both resources, budgets, and timelines.
inconsistencies between requirements, project plans, and
work products. Requirement engineering is used to gather In several studies, CMMI and agile methodologies are
the information, define requirements and is related to compared [25], and mappings between them are proposed [17-
analyses and documentation of the requirements [17]. 22]. In an agile project which is an iterative approach to
Requirements Development has the goal of setting correct software development, customers do not need to work out all
requirements for the project and requirement management their requirements in details up front. "User stories" states the
customer needs and defined as a representation of a small
piece of functionality that provides some value to the business. requirement set in the beginning and keep it stable throughout
It states what needs to be delivered to the customer for that the development is almost impossible and not effective.
functionality and can be often enough to be a few sentences. A Therefore, a newer approach to define the requirements
good user story should determine who needs the requirement, incrementally and iteratively in order to let stakeholders
why needed and what needs to do. In each iteration, sufficient involve in each iteration and let the system to adopt is
requirements are analyzed and refined to support the delivery assimilated. Therefore, in agile, requirement change is more
of that iteration's functionality. As customers get the delivery welcomed and requirement management is more important to
of iterations frequently, they are involved in the project ensure that changes are managed properly. In order to
standardize different approaches, there are quality models that
progress directly and can refine their requirements for the next
can be referenced, like CMMI. CMMI is not a process but a
iterations.
model and an approach that helps to reduce the risks and to
The important point about requirements are the improve the quality. CMMI includes two PAs (process areas)
prioritization as if there are new prioritized requirements for related to requirements, which are requirement development
that iteration, then there must be some requirements to push and requirement management. For this two process areas,
down the priorities. Agile welcomes change requests any CMMI specifies ‘what' needs to be done but does not specify
time but require proper planning for each iteration[23, 24]. ‘how to' do it. Therefore, it is applicable regardless of the
SDLC model that you use. Moreover, it tries to ensure that
Beside of the SDLC model you use either waterfall or agile, proper REQM/RD can save on development costs if they are
software requirement management should cover below: managed properly.
− Requirements should be elicited based on stakeholder
needs and transformed into customer requirements.
− Product and work component requirements should be REFERENCES
stated according to customer requirements. [1] Jianxin (Roger) Jiao and Chun-Hsien Chen, “Customer Requirement
− Requirements should be analyzed and validated with Management in Product Development: A Review of Research Issues”,
relevant stakeholders. Vol 14, Issue 3, 2006.
[2] P. Jalote, “An Integrated Approach to Software Engineering”, 3rd
− Requirement definitions should be clear and well stated edition, Narosa Publishing house, India, 2005.
for each party. There should be a prioritization of each [3] P. Parviainen, H. Hulkko, J. Kaariainen, J. Takalo & M. Tihinen,
requirement to achieve balance and commitments need to “Requirements Engineering”, Inventory of Technologies, VTT
be obtained for a requirement. Publications, Espoo, 2003.
[4] Sommerville & P. Sawyer, Requirements Engineering: A Good Practice
− Requirement changes should be analyzed, managed and Guide. John Wiley & Sons, 1997.
tracked. There should a bi-directional traceability between [5] R. H. Thayer & W. W. Royce, Software Systems Engineering, IEEE
requirements to work components of the technical System and Software Requirements Engineering. IEEE Software
Computer Society Press Tutorial. IEEE Software Society Press. Los
solution, also to a test case and validation procedure that
Alamos, California, 1990.
is related to that requirement. [6] W. W. Royce, “Managing the Development of Large Software Systems”
− There should not be any inconsistencies between the Proceedings of IEEE Wescon, Reprinted in Proceedings 9th
project work components and the requirements. International Conference Software Engineering IEEE Computer Society
Press, Los Alamitos. California. USA, 1987, pp. 328-338.
− Project plans should allow managing the requirements [7] Cho, Juyun. Issues and Challenges of agile software development with
and its related product areas in any phase throughout the SCRUM. Issues in Information System.VOL IX, No. 2. 2008.
project timeline. [8] J. Siddiqi, “Requirement Engineering: The Emerging Wisdom”, IEEE
Software, 1996, pp.15- 19.
[9] M.E.C Hull, K. Jackson & A. J. J Dick, Requirements Engineering.
Springer-Verlag. Berlin, 2002.
V. CONCLUSION [10] R. Stevens, P. Brook, K. Jackson & S. Arnold, Systems Engineering -
The requirement engineering requires more focus in SDLC Coping with Complexity, Prentice Hall, London, 1998.
and in industrial development projects. Requirement [11] S. Blanchard & W. J. Fabrycky, Systems Engineering and Analysis,
Prentice-Hall, 1981.
engineering is defined as a systematic, multidisciplinary effort [12] S. Lauesen, Software Requirements: Styles and Techniques,
that collects needs from different stakeholders and maps them AddisonWesley,2002.
in software development stages. It needs to be managed [13] H. Berlack, Software configuration management. John Wiley & Sons,
through the SDLC and system development. 1992.
[14] F. Paetsch, A Eberlein, F Maurer - “Requirements Engineering and
Requirement engineering covers mainly two activities: Agile Software Development“, 2003.
requirement development and management. Development is [15] CMMI-DEV, CMMI for Development, V1.3 model, CMU/SEI-2010-
focused on actions of the investigation, analysis, specification, TR-033. Software Engineering Institute, 2010.
[16] T. B. Alakuú, R. Daú, and ø. Türko÷lu, “YazÕlÕm Geliútirme Süreçlerinin
documentation, verification, and validation of the requirements.
Analizi: Zorluklar, TasarÕm Prensipleri ve Tekniksel YaklaúÕmlar,” in
Whereas requirement management is related to traceability, 2017 International Artificial Intelligence and Data Processing
change, and management of the requirements. In traditional Symposium (IDAP), Inonu University, Malatya, 2017, pp. 1–10.
SDLC models, like the waterfall, requirement development is [17] D. Pandey, U. Suman, A. K. Ramani, “Impact of Requirement
performed mostly at the beginning of the development cycle Engineering Practices in Software Development Processes for Designing
and resistant to changes throughout the project lifecycle. In Quality Software Products”, National Conference on NCAFIS, DAVV,
Indore, 2008.
newer models, like agile, it is recognized that developing a
[18] Anderson D. J., "Stretching Agile to fit CMMI Level 3 the story of [22] Turner R., and A. Jain, "Agile Meets CMMI: Culture Clash or Common
creating MSF for CMMI Process Improvement at Microsoft Cause," In proceedings of the Second XP Universe and First Agile
Corporation" presented at Agile2005 Conference, [Online] Universe Conference on Extreme Programming and Agile Methods
http://www.agilemanagement.net/Articles/Papers/Agile_2005_Paper_DJ XP/Agile Universe, pp. 153165, 2002.
A_v1_5.pdf. (December 2006) [23] M. Lang & J. Duggan, “A Tool to Support Collaborative Software
[19] Kähkönen T. and P. Abrahamsson, "Achieving CMMI Level 2 with Requirements Management” Requirements Engineering Journal 6(3),
Enhanced Extreme Programming Approach," In proceedings of the 5th 2001, pp. 161–172.
International Conference on Product Focused Software Process [24] Agile Manifesto, Manifesto for Agile Software Development, [Online]
Improvement, pp. 378392, 2004 http://agilemanifesto.org (Accessed date: 10.01.2018)
[20] Nawrocki J., W. Bartosz, and A. Wojciechowski, "Toward Maturity [25] G. Gurgoze, R. Das, and ø. Türko÷lu, “Comparison of software
Model for eXtreme Programming," In proceedings of the 27th development process models, The 8th International Advanced
Euromicro Conference, pp. 233239, 2001. Technologies Symposium (IATS-2017), Firat University, Elazig,
[21] Paulk M. C., "Extreme Programming from a CMM Perspective," Turkey, 2017, pp. 1923– 1932.
Software, vol. 18, issue 6, pp. 1926, 2001.

View publication stats