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

net/publication/308186449

Requirements Engineering in Scrum Framework

Article  in  International Journal of Computer Applications · September 2016

DOI: 10.5120/ijca2016911530

CITATIONS READS

7 4,744

2 authors:

Nagy Ramadan Salwa Megahed

Faculty of Graduate Studies for Statistical Research, Cairo University Cairo University
94 PUBLICATIONS   131 CITATIONS    1 PUBLICATION   7 CITATIONS   

SEE PROFILE SEE PROFILE

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

Information Security View project

Information systems View project

All content following this page was uploaded by Nagy Ramadan on 18 September 2016.

The user has requested enhancement of the downloaded file.

 International Journal of Computer Applications (0975 – 8887)
Volume 149 – No.8, September 2016

Requirements Engineering in Scrum Framework

Nagy Ramadan Darwish Salwa Megahed
Department of Information Department of Information
Systems and Technology Systems and Technology
Institute of Statistical Institute of Statistical
Studies and Research Studies and Research

ABSTRACT The rest of this paper is structured as follows: Section

Requirement Engineering (RE) plays an important role in the 2provides related work, Section 3introduces requirements
success of software development life cycle. As RE is the engineeringframework, Section 4provides the fundamental
starting point of the life cycle, any changes in requirements concepts related to Scrum, Section 5shows the common RE
will be costly and time consuming. Failure in determining techniques that are used in Scrum framework, Section
accurate requirements leads to errors in specifications and 6presents the conclusionand future work.
therefore to a mal system architecture. In addition, most of
software development environments are characterized by user
2 RELATED WORK
requests to change some requirements.Scrum as one of agile In the last years, there has been a growing awareness of the
development methods that gained a great attention because of RE importance for increasing the quality of software projects
its ability to deal with the changing environments. This paper and lot of research has been conducted in this area. This
presents and discusses the current situation of RE activities in section introduces some important related work in RE and
Scrum, how Scrum benefits from RE techniques and future agile methods and scrum frameworkin addition, it introduces
challenges in this respect. the current situation of scrum approach and RE.
 The authors in [12] provide their research that was
Keywords conducted using qualitative methods. Respondents
Agile, Requirement Engineering, Software Development, who play different job roles from nine organizations
Scrums. were interviewed in order to collect data. Majority
of the respondents successfully practices the scrum
1 INTRODUCTION RE practices, face to face communication,
RE is a branch of the system engineering, concerned with requirements prioritization, iterative requirements
constrains and goals to be achieved [1]. As many projects engineering and managing requirements change.
ran over budget and schedule, some projects caused property Some organizations were not comfortable with the
damage and a few projects caused loss of life. From its test driven development.
beginnings in the 1960s, writing software has evolved into a
profession concerned with how best to maximize the quality  The author in [4] discusses the requirements
of software and of how to create it. By early 90th, a radical traceability problem in agile software development
shift emerged as independent field of study. IEEE sponsored and the relationships between the traceability and
conferences and symposiums for RE. By late 90th, the field refactoring processes and their impact on each
had grown and supported a large number of projects [16].RE other.
is a process of determining the purpose of the system by
identifying users and their needs, documenting these in way  The author in [3], provides a comparison between
that helps in analysis, communication and implementation RE and agile development approaches. In addition,
[16]. the author presents commonalities and differences
between both of them and the ways of how agile
Scrum is one of the agile lightweight methods that used in software development can benefit from
software development. It is a simple set of roles, requirements engineering methods.
responsibilities, and meetings that never change. Scrum
process benefits the organization by helping it to:  The author in [13] describes an agile requirements
engineering approach for re-engineering and
 Ensure a high quality of products, changes in existing Brownfield adaptive system.
The approach has few modifications that can be
 Scalable from single process to entire project,
used as a part of Scrum development process for re-
 Provide better estimates to time and cost, engineering and changes. The approach illustrates
the re-engineering and changes requirements
 Be more in control of the project schedule and state through introduction of GAP analysis &
[10]. requirements structuring & prioritization by creating
Although RE and agile methodology seem to be incompatible AS-IS & TO-BE models with 80 / 20 rule. An
as RE is heavyweight in documentation while agile methods attempt to close the gap between requirements
are people oriented, still agile in general and scrum in engineering & agile methods in form of this
specific can get benefit from RE techniques. Examples of RE approach is provided for practical implementation.
techniques in scrum approach: interviewing, JAD, modeling,  The author in [15]explores requirements changes in
prototyping,and documentation. This paper aims to highlight an agile-scrum software development process. The
the current situation of scrum approach and RE, the use of RE goal of the study was two folds:
techniques in scrum, and future challenges facing scrum and
RE techniques.

24
 International Journal of Computer Applications (0975 – 8887)
Volume 149 – No.8, September 2016

 To empirically investigate the claims of agile relationship of these factors to precise specifications of software
proponents that Agile methodology allows behavior [16].Requirements are classified into process and
changes to requirements even late into the product. Process is concerned with cost, lead time and
project with minimal impact on software organization, while requirement product is broken down to
functionality and quality of the delivered functional and non-functional requirements. Functional
product. requirements are viewed from two sides: user side (user
requirements) and developer side i.e. testability,
 To investigate the impact of requirements maintainability [1]. Non-functional requirements i.e.
changes on the development productivity, if (availability, reliability, maintainability, reusability) are
there exist a correlation between the considered the responsibility of developers.
development effort and requirements changes.
Measurement data were collected from the 3.1 Requirements Engineering Framework
development teams. Productivity of multiple RE includes many activities that can be framed in framework.
project teams was evaluated using both One of the most common frameworks for RE, is as shown in
traditional and new measures. Passed test cases fig (1). RE includes five main activities that can be:
is one of the measures investigated in this Elicitation, Analysis and Negotiation, Documentation,
research. The findings of the experiments Validation, and Management.
demonstrate a high correlation between the
number of test cases passed and the
productivity. RE
Elicitation
Current situation of scrum approach and RE is as follow:
 During requirement elicitation: product owner
formulates the product backlog. Different
stockholders can participate in product backlog. A RE RE RE
user story is used to describe a feature that delivers Validation Management Analysis
a value to the customer. Story is written on the
face of the card while it’s acceptance test on the
back [2].
 In RE Analysis stage: at this stage, requirements are RE
checked for completeness, consistency, essentiality Documentation
and feasibility. Product backlog refinement
meetings are held to discuss them. Product owner
Fig. (1) Requirement Engineering Framework
prioritizes the product backlog and analyze the
feasibility of requirements. Prioritization in Scrum 3.2 Requirements Elicitation
takes place before each development iteration which It is the process of collecting requirements from stakeholders.
is unlike the traditional requirement engineering System constrains, boundaries, identification of problems are
where prioritization is done only once during the stated in this stage. This stage is also known as “Requirements
life cycle [2]. gathering”. Some questions should be answered in this stage
 Requirement documentation: it is almost unfeasible. [4]:
In Scrum approach, documentation is done face to  Does the system contribute to high level objectives?
face. A lack of documentation can lead to a long
term problems for the team. A new team member  Can the system be implemented within given budget?
will have a lot of questions regarding the project [2,
3].  Is the system feasible?

 Requirement validation: is done through review 3.3 Requirements Analysis

meetings. Agile in general, and Scrum in specific do It checks requirements for necessity, consistency, completeness
not tend to use documentation as in RE. The and feasibility. Conflicts in requirements are resolved through
validation in scrum is done through sprint review at prioritization negotiation with stakeholders. Solutions to
the end of each cycle. This meeting puts both of requirements problems are identified and a compromise set of
stockholders and developers on the right track [2, requirements is agreed [3].
5].
3.4 Requirements Documentation
 Requirement management: generally, requirements The main purpose of the documentation is the communication
are managed through documentation that captures between stakeholders and developers. A lack of
stores and traces each requirement from elicitation documentation can lead to problems on long term [4].
till implementation is completed. In scrum Requirement document should be clear, consistent, concise and
approach this can be done through sprint planning feasible [3].
meetings, and items in product backlog which are
used for tracking. Also changes in requirements are 3.5 Requirement Validation
added or deleted to and from product backlog [4]. Validation checks consistency, completeness and realism of the
requirements [2]. In figure 2, inputs to validation process are:
3 REQUIRMENTS ENGINEERING organizational knowledge and organizational standards. The
Requirements engineering is the branch of software engineering output is a list of reported problems with action to solve these
concerned with the real-world goals for, functions of, and problems [3].
constraints on software systems. It is also concerned with the

25
 International Journal of Computer Applications (0975 – 8887)
Volume 149 – No.8, September 2016

Organizational Standards • At the end of the sprint, the work should be potentially
List of
& Knowledge Requirements shippable: ready to hand to a customer, put on a store
problems
shelf, or show to a stakeholder.
Validations & actions
to solve • The sprint ends with a sprint review and retrospective.
them
• As the next sprint begins, the team chooses another
Requirements chunk of the product backlog and begins working again
[5].

4.2 Roles in Scrum

A scrum presents a team that act cooperatively to deliver a
Fig. (2) Validation process
project within time and with minimal cost [5]:
It helps in highlighting problems at early stages of the project
• Product Owner: is responsible for setting product
life cycle to avoid project delay or failure. The main goal of
backlog, decide about the business value and ROI,
this stage is to ensure that requirements reflect the real user
prioritize the product backlog.
needs [4, 17].
• Scrum Master: responsible for the implementation of the
3.6 Requirement Management project, trouble shooter, protecting the team from
This process concerned with all activities associated with external influences.
changing the requirements of the system from change/version
control to requirements tracing [2]. Tools and techniques are • Scrum Team:self-organizing team, no titles, cross-
used to simplify the process of tracing. Analysis is done to function [9].
determine the stability of requirements and manage future
changes. 4.3 Scrum Artifacts
Scrum approach is an agile software development framework
4 SCRUM used for incremental software development. The three basic
Scrum approach was initiated by Ken Swaber in 1995 and artifacts of scrum are [8]:
included in agile methodology. Since it contains the same • Product Backlog: list of ordered and prioritized backlog
concepts of agile, it is defined asan agile framework for items.
completing complex projects. Scrum approach is originally
formalized for software development projects, but works well • Sprint Backlog: selected backlog items, unchangeable
for any complex, innovative scope of work [5]. and committed items.

4.1 Scrum Framework • Increment (Burn chart): to show how much work left
against the time.
Scrum approach is based on the principles and values of the
agile manifesto, which proposes a different style for managing
software development work, encouraging people over processes
4.4 Events in Scrum
These events enable transparency on the project progress to
orientation, working software over documentation,
all who are involved in the project. The vital events of scrum
collaboration over contract negotiation, and responding to
are:
change over following a plan.
• Sprint: is an iterative, time boxed duration with fixed
time (from two weeks to month). Each sprint starts with
planning and ends with review.
• Sprint planning:communicates the scope of work likely
during that sprint
• Selects product backlog items that likely can be
done.
• Prepares the sprint backlog that details the work
needed to finish the selected product backlog items,
with the entire team.
Fig. (3) Scrum Framework [6] • Sets a four-hour time planning event limit for a two-
• A product owner creates a prioritized list called a product week sprint [9].
backlog. • Daily Scrum: Each day during a sprint, the team holds a
• During sprint planning, the team pulls a small chunk daily scrum (or stand-up) meeting to discuss:
from the top of that list, a sprint backlog, and decides • What have finished yesterday?
how to implement those pieces.
• What will be done today?
• The team has a certain amount of time a sprint (usually
two to four weeks) to complete its work, but it meets • Any obstacles!.
each day to assess its progress (daily Scrum). • Sprint Review: At the end of a sprint, the team holds two
• Along the way, the Scrum Master keeps the team focused events: the sprint review and retrospective. At sprint
on its goal. preview, the team:

26
 International Journal of Computer Applications (0975 – 8887)
Volume 149 – No.8, September 2016

• Reviews the work that was completed and the 5.2 Requirements Analysis
planned work that was not completed. The main purpose of this stage is to ensure that requirements
• Presents the completed work to the stakeholders [9]. decided in elicitation stage are clear, complete, and consistent.
Conflicts are resolved by prioritization with users. The
• Sprint retrospective: common techniques used for requirements analysis in scrum
• Two main questions are asked in the sprint approach are [4]:
retrospective: What went well during the sprint? • JAD sessions: these sessions encourage customer
What could be improved in the next sprint? involvement which is the base line in agile
• The recommended duration is one and a half hours methodology in general and scrum in specific.
for a two-week sprint (pro-rata for other sprint Sessions are important at the beginning of the
durations). project. The results of the sessions are for
documentation. Documentation in agile methods is
• This event is facilitated by the scrum master. relaxed. Those sessions have to be held frequently
during the project [2, 3,4].
5 RE TECHNIQUES USED IN SCRUM
• Prioritization: in scrum approach, inbeginning of
APPROACH each iteration, requirements are collected and
RE in Scrum approach is iterative, not final and predefined prioritized in stack [4]. Only product owners
but evolves in each Sprint. In each Sprint, customer meets the prioritize them according to the business value,
development team to provide with the next set of customer needs and ROI. The frequent
requirements to be implemented during that Sprint. An communication between the team and stockholders
advantage of this practice is that since the customers are not helps to distinguish between “must have”
clear about the exact requirements at an initial stage, when requirements and “nice to have” requirements [4].
they see the evolving system they can be more clear and At the following diagram, if requirements are valid,
specific about the requirements. The development team also they are included in prioritized list with the new
has the benefit of immediate access to the customer in order to ones. Then a new list is prepared to identify the
understand the requirements better [12]. The following features that will be implemented.
requirements engineering techniques help those scrum
techniques as product backlog, sprints, and daily scrums to be List of Candidate
achieved. Requirements
5.1 RE Elicitation
At this stage, the team has to obtain all information about the
application domain, services that the system should provide
[4]. The choice of the suitable technique depends on what
kind of information is required, time, and cost [16]. Most
important techniques used in this stage are:
Valid
• Interviews: the important point in agile methods is Priority
“customer involvement”. Interviewing is the process of
transferring unfiltered knowledge. In order to avoid
misunderstanding, interviewing the customer is
important for development of the system [3]. As per
CHAOS report, the customer involvement by this
technique (interviewing) and user on site was found Solve the Prioritized Req.
number one in projects success [1]. Using RE techniques problem Stack
which based on user involvement is important in Scrum
approach [3, 4].
• Prototyping: it is considered an effective visualized tool
which helps the user to illustrate the proposed system.
There are three types of prototyping: low-fidelity, high-
fidelity and wizard-of-oz prototypes. The first type is a Development
sketch to show how user interface will look. It can be
manual drawing on papers or by using a computer based phase
tool. The high-fidelity type of prototype is done using
web-page. This type provides more realistic illustration Fig. (4) Requirement prioritization process [4]
of the proposed system. The wizard-of-oz, is a type of
prototype which simulates the responses of the system in 5.3 Requirements Validation
response to some user inputs [2, 18]. This process helps to improve the software quality. The main
practices used for requirements validation in scrum are:
• User stories: one of Scrum approach practices used to
record the user requirements. Features and values of the • Review meetings are held frequently for the purpose of
product are written by the user on front of the paper and validating the requirements. During review meetings,
the results on the back. User stories are also used a type customers and scrum team checking requirements against
of planning and documenting the requirements. The team organizational standards, organizational knowledge and
then writes the user stories in proper business language user requirements to know about the strength and
to understand [2]. weakness of the design, technology limitations.

27
 International Journal of Computer Applications (0975 – 8887)
Volume 149 – No.8, September 2016

Conflicts and errors in requirements have to be solved [1, 6 CONCLUSIONAND FUTURE WORK
2]. Although scrum is lightweight method used in small projects,
• Testing in scrum approach is done after each review to it can still benefit from requirement engineering techniques as
check if the system reacts in expected way. If not, then shown in section (V). Many challenges of requirements
a clarify needs to be presented [3, 18]. There are different engineering in scrum framework are presented as follow:
kinds of tests. Acceptance test, test driven development A lack of requirements techniques in scrum that practitioners
and acceptance test driven development. Acceptance test can choose from.
is a satisfaction conditions that determines if product
features are implemented. Test driven development is a Non-functional requirements: no accepted techniques for
kind of test that is developed prior to the code while managing non-functional requirements. They are ill defined.
acceptance test-driven development helps in building
Scalability: doesn’t mean growth of size in S/W. It also refers
right product [4].
to complexity, variability in software line and a degree of
5.4 Requirements Documentation heterogeneity [2].
The RE process in not only for finding out information about In this paper, a surveyresearch in requirements engineering
the system but also essential way of communication between all stages and scrum frameworkis presented. Also, an attempt of
parties involved in the software development process. answering how scrum frameworkcan benefit from RE
Requirements documentation helps in analyzing, re-writing, and techniques is introduced. A further research is targeted to
validating those requirements. Although modeling and solve the problems of using REtechniques in scrum
documentation in agile methods less used than RE, they are framework.
used as a way of communication with the user [16].Scrum
master assigns some members to produce modeling for the 7 REFERENCES
purpose of documentation in parallel. Use Cases describe the [1] Aybüke A., andClaes W., 2005, Engineering and
interaction between users and the system and considered as Managing Software Requirements, Chapter 20, pp. 453-
documentation [3,4]. Developers use computer-based and 476.
project management tools for high level description of the
system. Also, a reverse engineering process can be used to [2] Elshandidy, H., and Mazen, S., 2013, Agile and
reverse the code to documentation. Traditional Requirements Engineering: A Survey,
International Journal of Scientific & Engineering
5.5 Requirements Management Research, Vol. 4, Issue 9.
Scrum approach believes that changes in the system are [3] Eberlein, A., and Maurer, F., 2003, Requirements
inevitable. Problems of this stage are summarized in: Engineering and Agile Software Development,
• Few people are experienced in requirements University of Calgary.
management. [4] Quesf, A., 2010, Requirements Engineering in Agile
• People don’t distinguish between users and Software Development, Journal of Emerging
stakeholders requirements of the system. Technologies in Web Intelligence, Vol.2, No.3.

• The way in which requirement management [5] Mahalakshmi, M., et al, 2013, Traditional SDLC Vs
problems are managed and solved [19]. Scrum Methodology – A Comparative Study, India,
International Journal of Emerging Technology and
Managing requirements changes is fulfilled by main practices Advanced Engineering, Volume 3, Issue 6.
such as:
[6] Scrum Framework
• Iterative RE: the main source of requirements image:https://search.yahoo.com/yhs/search?hspart=avg&
information is analysis. Prior to each sprint, information hsimp=yhsfh_lsonswrow&type=ch.49.xp.nt.04.03.eg.avg
is needed for sprint planning and implementing. ._.1215tb&param2=new_tab_search&param3=ch.49
Prioritize of requirements is done according to their
business value decided by the customer. [7] Helmy, W., and Hegazy, O., 2012, Requirements
Engineering Methodology in Agile Environment,
• Short releases: in order to meet the user requirements Faculty of Computers & Information Systems, Cairo
faster, software is delivered in short releases. Release is University.
the output of the development process. Changes will be
required if output is odd. No doubt that each release [8] Nagy Ramadan Darwish and Abdel Wahab, E., 2016, A
confirms the relationship between users and development Security Testing Framework for Scrum Based Projects,
team in a way of communication. International Journal of Computer Applications, Vol.
138, No.7.
• Customers’ feed-back: before the beginning of each
sprint, a planning meeting is held to ensure that [9] Cho, J., 2008, Issues and Challenges of Agile Software
development team aware of the product details. This Development with Scrum, Journal of Management
meeting helps in minimizing changes after the sprint Information Systems, Vol. IX, No. 2, pp. 188-195.
when product is delivered. At the end of each sprint, a [10] Marchesi, M., et al, 2007, Distributed Scrum in Research
sprint review meeting is held to discuss and share feed- Project Management, Conference: Agile Processes in
back with development team if the product is not Software Engineering and Extreme Programming, 8th
meeting the customer expectations [2, 16]. Both pre- International Conference, XP, Como, Italy, June 18-22.
and post- meeting are essential to obtain a product that
meets user requirements. [11] Dick Carlson, 2007, Practical Agile Requirements
Engineering, Presented to the 13th Annual Systems
Engineering Conference, Hyatt Regency Mission Bay,

28
 International Journal of Computer Applications (0975 – 8887)
Volume 149 – No.8, September 2016

San Diego, CA. [15] Mueller, C., 2011, Requirements Management in an

http://dtic.mil/ndia/2010systemengr/WednesdayTrack1_ Agile-Scrum, Department of Computer Science San
11106Matuzik.pdf. Marcos, TX.
[12] Vithana,N., 2015, Scrum Requirements Engineering [16] Nuseibeh, B., et al, Requirements Engineering: A
Practices and Challenges in Offshore Software Roadmap, Department of Computer Science, Imperial
Development, Sri Lanka Institute of IT Sri Lanka, College, London, U.K.
Singapore.
[17] Szekely, P., 1994, User Interface Prototyping: Tools and
[13] Bin Masood, A., et al, Applying Agile Requirements Techniques, USC/Information Sciences Institute, Marina
Engineering Approach for Reengineering & Changes in del Rey, CA., USA.
existing Brownfield Adaptive Systems, Mohammad Ali
Jinnah University. [18] Sommerville, I., 1997, Requirements Engineering, John
Wiley & Sons.
[14] Fahd, M., 2014, Customer Oriented Requirement
Engineering By Using Scrum, Dept. of Computer & [19] Hull, E., et al, 2005, Requirements Engineering, Springer
Information System, Islamia University, Pakistan. London Berlin Heidelberg, Second Edition, Chapter 8,
pp. 153-154.

IJCATM : www.ijcaonline.org
29

View publication stats