pdrm assignment
TRANSCRIPT
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Contents
Abstract.......................................................................................................................................................4
Dissertation Proposal..................................................................................................................................4
Introduction.................................................................................................................................................4
Problems.................................................................................................................................................4
Theoretical Background...............................................................................................................................5
Requirement Engineering........................................................................................................................6
Traceability..............................................................................................................................................7
Agile software development....................................................................................................................8
Aims and Objectives....................................................................................................................................9
Intellectual Challenge................................................................................................................................10
Research Program.....................................................................................................................................10
Deliverables...............................................................................................................................................13
Resources..................................................................................................................................................14
Literature Review......................................................................................................................................14
Related Literature......................................................................................................................................15
Learning Requirements.............................................................................................................................21
Types of requirements...............................................................................................................................21
Functional requirements and non functional requirements..................................................................22
Interviews..............................................................................................................................................22
Scrum.....................................................................................................................................................23
Scrum Process....................................................................................................................................23
Roles..................................................................................................................................................24
Extreme Programming (XP)...................................................................................................................24
User Story..............................................................................................................................................25
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
References.................................................................................................................................................26
Abstract.....................................................................................................................................................29
References.............................................................................................................................................30
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Dissertation Proposal
And
Literature Review
On
“Requirement engineering and traceability
In an agile environment”
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Requirement engineering and traceability
In an agile environment
AbstractThe Requirements Engineering (RE) process often dominates the quality of a project. The requirement practices in a project team are supposed to be an important part of the whole software development process. RE is a process under an agile environment that investigates that there Exist relatively formal but agile and changeable requirements within a project. The methods planned to be used are literature study and Non probabilistic Interviews. How traceability is handled in agile methods vary from organization to organization, and project to project. When working with traditional development traceability is an important part of the process. However for some reason this is not the case when working with agile methods. For example in Scrum there is no real definition of how configuration management is supposed to be done. The initial problem is to look into how traceability is supposed to be performed in agile methods, do we need traceability? One of the focuses will be on the support of tools and how they can help reduce the administrative overhead of adding traceability to the project. If tracing is supposed to succeed in agile methods such as Scrum and XP, it needs to add some value to the project.
KeywordsRequirement Engineering, Traceability, Configuration management, Agile, requirements, searchable data, software interoperability, costs, benefits, documentation, scrum master, configuration managers
Dissertation Proposal
Introduction
This Proposal focuses on how the Requirement Engineering (RE) and Requirement Traceability
(RT) can be added to the agile methods and what the potential costs and benefits there will be.
This Proposal is written as a part of the master dissertation in Software engineering at the
department of computer science at the Faculty of Engineering at APIIT SD INDIA Affiliated to
Staffordshire University.
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Problems
The problem that needs to be solved is how to conduct a RE process in a scrum environment ‐ so
that there will be more formal requirements at the beginning of the project but the requirements
can still be changed and the changes are traceable.
Another problem was how to add traceability in agile methods such as Scrum and XP. Some
organizations, customers and regulations require that tracing information is saved during
development. Tracing information about events such as code changes, test results, implemented
requirements and so on. The problem is how this is supposed to be done when using agile
development. Some questions that came up were:
Can traceability be agile?
Can it be added without too much administrative overhead?
Do tracing need to be expensive?
Can the project gain anything from traceability?
Is it possible to use agile methods when developing critical systems where there are
requirements on traceability?
Another problem that was looked at is who would benefit the most from tracing information.
Perhaps the tracing information gathered by the team would help someone outside the team in
another stage of the software’s lifecycle.
There is a problem when tracing information is gathered and never used as well as never
updated. Can this affect the final result of the product?
In the proposal “Requirement Engineering and Traceability in an agile environment” the focus is
on what are the benefits using RE and RT. The intent is to identify the characteristics of Agile by
comparing with the traditional software engineering, and introduce how RE and RT are
conducted in an agile environment.
The concepts of RE and RT with the knowledge of agile Methods such as Scrum and XP are
required for the Dissertation.
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Theoretical Background
Requirements Engineering (RE) is a principal area in software development and production. A
high quality RE process often dominates a successful project (A. Sillitti ,G. Succi 2005, p 315).
Traditional Software Engineering (SE) usually includes the RE process which consists of
requirements elicitation, analysis, documentation, validation and management.
In recent years, in order to have rapid delivery of high‐quality software many industrial project
teams work in an agile environment. Different from traditional SE process, agile method relies
on iterative and incremental development and face‐to‐face communication. Among all the agile
developments Scrum is one of the most popular methods in industry (Agile Journal).It separates
a project into sprints, with each sprint being two to four weeks long, depending on the size of the
requirement and project and has new delivery product after each sprint. Tasks to be done are
discussed before every new sprint starts in order to meet customers’ changing needs. The
requirements in Scrum development will evolve rapidly during the project in this way.
With the changing requirements and in order to fulfill those requirements one of the problems is
that traceability is an important part in traditional software development but it is not a standard
practice for the agile methods such as Scrum and extreme programming (XP). Can agile methods
be used in larger project where it was necessary to have traceability? Is the traditional
development methods better suited? There was also focus on how traceability was supposed to
be added to the methods like Scrum. Requirements traceability is “the ability to describe and
follow the life of a requirement in both forwards and backwards direction (i.e., from its origins,
through its development and specification to its, subsequent deployment and use, and through
periods of on-going refinement and iteration in any of these phases)” (Gotel, O., and Finkelstein
1994 p 94).
Requirement Engineering
Requirements Engineering (RE) is a principal area in software development and production. A
high quality RE process often dominates a successful project (A. Sillitti ,G. Succi 2005, p 315).
Traditionally Software Engineering generally includes the RE process which consists of
requirements elicitation, analysis, validation, documentation and management. RE tries to
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
communicate the thoughts or ideas and requirements of the product’s stakeholders to the
engineers and developers who ultimately build the product. While stakeholders generally know
the functions and features the software should include, they have difficulty quantifying the fine
grain details and behavior of a system. They make the mistaken assumption that the high-level
description of the features implies the detailed procedural steps (Moore, J. et al 2000).
Requirements indicate what customers really needs, the functionalities the system is supposed to
provide to satisfy the customer’s requirements, the constraints of the system etc. It is important
to gather complete requirements so that developers will clearly know users’ needs and thus
decide how to implement the system. The details of software development techniques and
requirements ranges greatly from project to project, and there is not a single requirements
engineering specification that covers each project perfectly. One of the most precise descriptions
of requirement engineering is Zave’s:
“Requirements engineering is defined as the branch of Software Engineering concerned with the
real‐world goals for, functions of, and constraints on software systems; it is also concerned with
the relationship of these factors to precise specifications of software behavior and to their
evolution over time and across software families.” (Zave, P. 1997 p 315-321)
Traceability
The ability to trace through the artifacts of a product lifecycle, source code, acceptance tests,
requirements, and design rationale, is critical to the success of large complex projects.
Traceability in general terms is the ability to chronologically relate the entities that are uniquely
identifiable. Traceability can also refer to the completeness of the information about the steps
performed and changes at every step in process change. Requirement Traceability (RT) is a sub-
discipline of requirement management within software development. RT is concerned with
documenting the life of a requirement and provides bi-directional traceability between various
associated requirements. A characteristics of a system in which the requirements are clearly
linked to their sources and to the artifacts created during the system development life cycle based
on these requirements (Ramesh, B.,Jarke, M. 2001 page 58)
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Traceability is supposed to keep all the information organized in a chronological order and easy
to find when needed. One part of traceability is to give all the teams involved in developing a
product a way to see how different artifacts are linked together. Even if traceability could be
considered important in traditional development it is not always used. Requirements traceability
can prove to be beneficial in following ways
Requirement Traceability helps to identify the source of the requirement either it is issued
by a person or document or group of persons (Ramesh, B 1998 p 37).
It helps in performing impact analysis (Cleland-Huang, J. 2006 p. 323) which traces out
what other component (s) might be affected in response to change in a particular
requirement.
Requirement Traceability helps in test case verification for example which test cases
verify which requirement (Ramesh, B 1998 p 37).
It helps tracking the overall progress of the project for example we can measure how
much requirements are implemented, how much requirements are in design phase and
how much requirements are completed.
Agile software development
Agile is an iterative and incremental software development method. A study by the Standish
Group showed that thirty-one percent of software development projects are cancelled before they
are completed (Standish Group, 1995). Many development methodologies have suggested
strategies for on-time software delivery, but due to a variety of issues (Boehm, B 2000 p 94-96),
projects are late, over-budget, or cancelled. Agile methodology aims to improve the software
development process by promoting the use of the industry’s best practices. To keep up with the
fast pace of business, software projects must handle the frequently changing goals and needs of
the customer. However, increased understanding of the problem-space and potential solution, fail
to reach the entire development team due to flaws in the chain of communication.
Agile methods do not fix all the plans at the beginning of the project. Instead, the project is
broken into smaller sub‐tasks and they are implemented in short time‐boxed iterations, with the
goal producing shippable code incrementally (Leffingwell, D 2007). All iterations have the same
pattern, which has three phases. The first phase is a planning session, including the prioritization
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
and the estimation of the working tasks and the team commits to the work. The second phase is
the development phase which includes implementation and tests, and the last phase is the
delivery of the increment (Leffingwell, D 2007). In this way, requirements may be introduced,
modified or removed in successive iterations, and the agile development methods have the
feature of embracing changing requirements during the process (Abrahamsson, P et al 2002).
Most agile methods, such as scrum, follow a daily stand‐up meeting among the team. Every day,
the team members report what they did the last day, what they plan to do today and the issues
they have met. In this way the progress made by everybody is shown of the current iteration and
the problems are reported in time (Leffingwell, D 2007).
The intent is to identify the characteristics of Agile by comparing with the traditional software
engineering, and introduce how RE and RT are conducted in an agile environment. For an
approach to be successful at capturing traceability in an agile project, it must account for the
principles and practices commonly supported by agile development teams.
The Ideas of the RE and RT with the agile methods and traceability tools will serve as the basis
for the proposal and dissertation.
Aims and Objectives
The Aim of the proposal is to look into how the Requirement engineering can be done to agile
methods and if traceability can be added to agile methods and if so, how it could be done. It is
suggested that interview of some people from the software development industry should be done
in order to get a wider view of the problem.
1) Find out the problems the teams have in working with the current requirements changes.
2) Find the real problem with tracing in agile methods and try to formulate the problem
description as well as preliminary solution.
3) Receive Feedback and try to improve the preliminary solution.
The intent is to find out an effective way to conduct a Requirements Engineering process in an
agile environment and if tracing is assumed to be added in agile methods it should not
overburden the requirement documentation and tracing or add too much administrative overhead
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
for the team. The benefits from the information gathered should be clear to the team. Some of the
early questions that were raised in the early stages of the research and that this report will try to
answer are:
How is traceability handled in Scrum and XP?
When should traceability be implemented?
Can it increase productivity or at least decrease the time it take to identify and fix bugs?
Can traceability reduce redundant maintenance?
How can tools help minimize the time/cost of tracing?
Intellectual Challenge
The big challenge for this project is interviews:
During the research phase the main source of information will be interviews. The results
that would come out after the interview will be my interpretation to the interviews based
on some studies and available literature. The company should be eager to follow or
should be following one of the agile methodologies such as Scrum or XP.
Find out the problems the teams have in working with the current requirements changes:
what are the effect of changes on the software and how the company will manage those
changes.
How can tools help minimize the time/cost of tracing: The tools used for traceability how
they will help the people to maintain the traces without overburden of the work.
Scrum and XP can work best in combination. Scrum focuses on everything around the
developing methods XP does the opposite and focuses on the team and developing practices. XP
focuses more on some configuration management practices such as version control, workspace
management and build control. Because XP is a good partner to Scrum most of the practices that
could be implemented to adding traceability to Scrum can be added to XP.
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Research Program
Need to gather relevant theories starting with literature study. The collection narrowed down
after a period of searching for general knowledge from books, academic papers and professional
magazines. The primary method that will be used for the Dissertation will be interviewing
people at different companies and with different roles in order to get a broader view of what the
potential problems with Requirement Engineering and Requirement Traceability were.
Qualitative interviews within the teams are done to get the broader view of the problem.
Interview:
Qualitative interviews will be performed with the company members
The teams worked according to scrum and thus there was not enough documentation which
described the work process and all relevant elements. I needed to talk to the team members to
have a complete overview of the teams’ work.
The scrum work will be done by people. It is hard to understand how the work is carried out only
by reading theoretical literatures. To know about the teams’ practical feelings and feedback will
be necessary since not all the theories can be applicable to real world.
After the initial phase of the interviews a paper known as first result will be created. This
document will then be sent out in order to get feedback on the preliminary results. However it
will not be easy to get people to read and send feedback on the first version of feedback. It will
take some time to read and review a paper and most people would be having a lot of work to do.
Questionnaire: Open ended or closed ended questions will be asked to the interviewers
The methodology used will be agile methods using Scrum and XP.
Limitation
In the beginning of the project it will be easy to find people and talk to. However, I think towards
the end when the working document was sent out in order to get feedback there will be some
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
problems getting feedback from people. The aim would be to cover the committed teams towards
the research.
Sources
During the research on traceability several people with different roles will be interviewed. The
sources of interview will be working professionals in different companies and on different
projects; this will result in a broader view of the problems and potential solution. Among the
interviewees the probable would be configuration managers, developers, testers, product owners
and scrum masters, scrum coach.
The aim would be to find the attitude towards traceability among different sections of the team
interviewed among different peoples.
Dissertation Schedule Table
Task No Task Description Duration
1 In Depth study of Agile methodology (Scrum and
XP)
1 week
2 In depth understanding of the RE and RT in SE 1.5 Weeks
3 How the RE and RT can be added to the Agile
methodology
2 weeks
4. Survey the existing literature and find the existing
tools
1.5 weeks
5. reviewing the accessible research work and finding the
problems
2.5 weeks
6. Identifying the teams for the interviews 1.5 weeks
7. Interviewing the Teams and generating first paper
for feedback
1.5 weeks
8. Sending the first paper for the feedback to the
Teams and other people
1.5 weeks
9. Reviewing the tools for the RE and RT in SE 2.5 weeks
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
10. Testing the Tools for the correctness and according
to the need of the team.
2.5 weeks
11. Reviewing the tools according to the Requirement 1.5 weeks
12. Writing the Final Dissertation report 2.5 weeks
13. Time for evaluating the dissertation 2 weeks
Bar Chart
Task1Task2Task3Task4Task5Task6Task7Task8Task9
Task10Task11Task12Task13
0 5 10 15 20 25 30
Chart Title
Weeks
Deliverables
Following will be the probable deliverables of the proposal:
Tangible Deliverables
1. How to include effective RE in Agile methods.
2. Tracing Practices that can be used in order to add traceability in the agile methods.
3. Agile methodologies like Scrum and XP: how they can be tailored for the RE and RT.
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
4. Traceability tools review i.e. how the use of tools in traceability can help the team in
maintaining the tracing of the requirement changes.
Intangible Deliverables
1. RE will be maintained and properly learned.
2. Saved time to maintaining the versions of the software product.
3. Tracing the changes will become easy.
Resources
Resources for the Dissertation required would be:
Online library journals, library books, Research Papers.
E-books of software engineering
To Access some of the current practitioner and researchers of the topic: The practioners
are and researchers are the best people to ask about the topic, therefore the some
practioners and researchers will be interviewed to investigate about the topic.
Team for the interviews who are ready to give their valuable feedback.
Literature Review
Software engineering is the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines. (Pressman
2001, p 20). Software Development is planned activity and is done following the methodologies.
Requirement Engineering and Traceability plays a major role in the Successful completion of the
project.
Requirements Engineering (RE) is a principal area in software development and production. A
high quality RE process often dominates a successful project (A. Sillitti ,G. Succi 2005, p 315).
Traditionally Software Engineering generally includes the RE process which consists of
requirements elicitation, analysis, validation, documentation and management.
The ability to trace through the artifacts of a product lifecycle, source code, acceptance tests,
requirements, and design rationale, is critical to the success of large complex projects.
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Traceability in general terms is the ability to chronologically relate the entities that are uniquely
identifiable. Traceability can also refer to the completeness of the information about the steps
performed and changes at every step in process change.
Agile is an iterative and incremental software development method. A study by the Standish
Group showed that thirty-one percent of software development projects are cancelled before they
are completed (Standish Group, 1995). Many development methodologies have suggested
strategies for on-time software delivery, but due to a variety of issues (Boehm, B 2000 p 94-96),
projects are late, over-budget, or cancelled. The focus is on how Requirement engineering and
traceability can be added to the agile methods and what would be the probable costs and benefits
there will be.
Related Literature
Review 1: Framework for Requirements Traceability - TLFRT supporting pre-RS & post-RS
traceability at Blekinge Institute of Technology (Uzair Akbar Raja, Kashif Kamran April 2008)
Topic: Framework for Requirements Traceability - TLFRT supporting pre-RS & post-RS
traceability
Uzair Akbar Raja and Kashif Kamran Under the guidance of Dr. Tony Gorschek has carried out
the research on the Framework for requirement traceability and the tools available for
traceability.
The aims of the research were:
i) Identify the current state of research in requirements traceability using a systematic review.
ii) Identify the factors that obstruct the implementation of traceability practices based on reports from
academia and industry.
iii) Investigate if any observable differences can be found in relation to the factors reported from
academia versus industry experience reports.
iv) Combine various traceability techniques to develop a framework for requirements traceability
based on systematic review and interviews in software companies.
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
The research was aimed at presenting a systematic review of requirements traceability and a
framework for requirements traceability called TLFRT.
The Results that that were found are:
Backward and Forward Traceability is required:
Based on the systematic review results it can be concluded that Gotel & Finkelstein provided
comprehensive and state-of-the-art definition of requirements traceability. They define
requirements traceability as the ability to describe and follow the life of requirements in both
forward and backward direction throughout the system specification, development, deployment
and refinement phases. It is to be noted here that tracing requirements in forwarding direction
relates to the post-RS traceability while tracing requirements in backward direction relates to the
pre-RS traceability. Therefore it is evident that for complete traceability these two aspects of
traceability are essential.
Tools for Traceability are reviewed Rational Requisite Pro, DOORS, Design Track and Scenario
Advisor Tool, RETRO, TRAM etc are reviewed.
A framework TLFRT is reviewed for the pre-RS & post-RS traceability.
Review 2: Requirements engineering in an Agile Environment at Uppsala University (Yunyun
Zhu, June 2009)
Topic: Requirements engineering in an Agile Environment
Yunyun Zhu Under the guidance of Anders Nyberg and Anders Jansson has carried out the
research on the how to conduct a RE process under an agile environment – so that there exist
relatively formal but agile and changeable requirements within a project.
The aims of the research were:
i) Investigate the working process of the two teams in the test tools section at SEMC
ii) Find out the problems the teams have in working with the current requirements
iii) Design some possible improvements based on the discovered problems
iv) Try out the improvements in one pilot for each team
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
v) Evaluate the effects of the pilots in order to propose a suggestion on the future work of the
teams
The research was aimed at solving the problem that Sony Ericsson is facing:
The test tools section at Sony Ericsson Mobile Communications AB (SEMC) is working hard to
become a more agile and lean software development organization. The teams are working
according to Scrum, using test driven development, continuous integration etc. However,
traditional RE, which requires long meetings and documents, is usually pre‐designed step by step
preciously. This process is obviously inapplicable to the quick and changeable work under an
agile environment. Thus, the problem that needs to be solved is how to conduct a RE process in a
scrum environment ‐ so that there will be more formal requirements at the beginning of the
project but the requirements can still be changed and the changes are traceable.
The Results that that were found are:
User stories:
Developers believed that user stories must be used in the requirements concerning with users,
especially the new requirements that were user related, so that they would know what the
customers wanted to do for some specific function. They also thought that user stories were more
helpful for test‐case‐based testing than the heuristic testing they were following.
Done Criteria:
Developers welcomed the done criteria very much.
a) The team was forced to think through the requirement precisely, more details considered so
that the estimation of working hours could be more accurate.
b) The Product Owner had to think what he really wanted and might find that the original
requirements were not realistic enough.
c) The testing goal became clearer because everybody knew what “pass” meant exactly.
Review 3: Implementing Traceability in Agile Software Development at Lund University
(Marcus Jakobsson, 2009)
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Topic: Implementing Traceability in Agile Software Development
Marcus Jacobsson Under the guidance of Christian Pendleton and Lars Bendix has carried out
the research on this report focuses on how traceability can be added to the agile methods and
what the potential costs and benefits there will be.
The aims of the research were:
i) The goal was to look into if traceability can be added to agile methods and if so, how could it
be done.
ii) Initial research; find the real problem with tracing in agile methods.
iii) Formulate a first problem description as well as a preliminary solution
iv) Receive feedback and improve correct the preliminary solution
The research was aimed at finding how the traceability can be added to the agile methodology.
The Result or analysis that that were found by interviewing the people is:
Two main issues were discovered to be a possible cause for not having traceability is:
a) The attitude towards traceability.
b) The lack of knowledge about it.
The problems are:
a) Practices: These practices could be used to add traceability to the agile methods. There
are several things that could be useful to trace. It is therefore important to know what,
why and how to trace.
b) Initial problem description to requirements: If there is an initial problem description from
the customer and he wants to validate that the initial problem description was properly
converted to requirements, we need to keep track of this connection.
c) Requirements to story/sprint log: The user stories should be marked along with sprint log
with the requirement id so that the information can be tracked down later if needed to
change or validate the requirement.
The Results that that were found are:
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
a) In which cases to add traceability: Not all projects needs to have traceability but some
form of tracing is always useful.
b) How to add traceability: The considerations one should take before and during the
introduction of traceability as an explicit practice in the agile method at a company.
Versioning control system is introduced to control the version of the project if the
requirement are changed with the previous requirements
c) Saving Information: The tracing information should be saved during the sprint. It is
important to document the code, tests and design while it is fresh otherwise it will begin
to fade. If the information is saved in, for example, the repository during the sprint, it is
still possible to write reports based on this information after the sprint. This could help
the team be a bit more productive during the sprint at the same time as the information is
stored and kept up to date.
Review 4: An Agile Approach to Capturing Requirements and Traceability (Xiaoping Jia et al)
Topic: An Agile Approach to Capturing Requirements and Traceability
Xiaoping Jia et al in the paper “An Agile Approach to Capturing Requirements and Traceability”
have tried to explain the Current requirements engineering practices that addressed traceability
approaches for well defined phase-driven development models.
The aim of the Paper was:
The Paper tries to explain ECHO: Echo is a tool-based approach that provides for the implicit
recording and management of relationships between conversations about requirements,
specifications, and subsequent design decisions. By providing a means to capture requirements in
an informal manner and later restructure the information to suit formal requirements
specifications, Echo aims to solve the problems of applying traditional requirements engineering
practices to agile development methods making available the demonstrated benefits of
requirements traceability – a key enabler for large-scale change management.
The Problems that were discussed are:
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
The challenges of Engineering and traceability in agile environment
From requirements to artifacts, there is an elicitation and elaboration process that is often
overlooked in the requirements gathering and development processes and critical to the
scalability of large software projects. Maintaining traceability in the standard fashion would
require manual tracking and maintenance from artifact to artifact, across the different stages. In
complex projects, management of the links becomes burdensome, and accuracy depends on the
frequency of updates. If not maintained correctly, links from one artifact to another may be
incorrect, as requirements or other requirements documents are disposed of. The traceability is
therefore rarely end-to end, as the time and effort required is more than the perceived worth. The
tools that were discussed are Version control system, Swing, Eclipse.
The final discussion of the paper describes:
The paper has described a tool-based approach to enable the scalability of agile requirements
gathering practice. Echo provides a mechanism that allows for flexible and dynamic creation of
content as well as the supporting traceability structure.
Review 5: Fluid: Echo Agile Requirements authoring and Traceability (Christopher Lee et al)
Topic: Fluid: Echo Agile Requirements Authoring and Traceability
Christopher Lee et al in the paper “Fluid: Echo Agile Requirements Authoring and Traceability” has
discussed the Project FLUID proposes the development of models and tools that will assist the
flow of information, communication, and conversation in agile project environments in order to
satisfy customer needs and requirements. By providing a means to gather requirements in an
informal manner and later restructure the information to suit formal requirements specifications,
FLUID: Echo hopes to alleviate many of the pains in requirements engineering. FLUID: Echo
also attempts to address issues in traceability management, by including conversations about
requirements in the information model.
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
The aim of the Paper was:
This paper will describe the background of the work, and the need to remedy specific pains of
requirements gathering experienced using XP’s User Stories as an example. Following the
description of the problem, the paper will then propose a revised model for collaborative
requirements gathering and traceability. The paper will also introduce the FLUID: Echo for
Extreme Programming User Stories, comparing it to other requirements engineering tools.
The Problems that were discussed are:
During the requirements elicitation process, collaboration and communication lead to an increase
in understanding of the problem space and the formulation of insights often critical to the success
of the project. Without a proper mechanism to capture and organize this influx of information
and its elaboration into insights, design rationale and traceability models cannot attain their full
potential impact in the delivery of customer satisfying solutions.
The final discussion of the paper describes:
This paper has described the need for tools to support the scalability of agile requirements
gathering practice. Providing a mechanism that allows for flexible and dynamic creation of
content as well as the supporting structure allows the focus of software system design and
development to be maintained on requirement elicitation. A transparent model in which
traceability is implicitly maintained while the content is created would allow for traceability to
become more commonly used. FLUID: Echo can also be used to support Customer needs may be
recorded and translated into features. The features lead to the software requirements of the
system to be captured.
Learning Requirements
The concepts or the theory learning time it is necessary to get familiar with the teams working
process. The teams are supposed to be following agile methodology such as Scrum or XP.
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Types of requirements
System requirements are usually separated into two types: functional requirements and
nonfunctional requirements (Agile Modeling).
Functional requirements and non functional requirements
Functional requirements describe what a system should do while non‐functional requirements are
constraints on the services or functions offered by the system (Sommerville Ian 2004).
Functional requirements are dependent of the end users and what kind of software that is
developed, etc. (Sommerville Ian 2004). They are related to the system’s actions and can be
regarded as business requirements, i.e., a user or a customer will be able to describe what the
system is intended to do.
Non‐functional requirements are seldom associated with single system features (Sommerville Ian
2004). They often refer to the properties that the system should have and the way in which the
customers want the product to act. (E.g., performance, security, usability etc.) (Sommerville Ian
2004) Also, some nonfunctional requirements may limit how the system should be developed
(Sommerville Ian 2004).
There are three types of NFRs: (Sommerville Ian 2004)
1. Product requirements, which specify product behavior. E.g., performance requirements
or reliability requirements.
2. Organizational requirements, which are from the customer’s and the developer’s
organization. E.g., the limitation of the programming language to be used.
3. External requirements, which cover all requirements that are from factors outside of the
system. E.g., the legislative requirements which mean that the system must act follow the
law.
Interviews
In can be of two types:
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
1. Structured Interview: In this the Interviewer has set of questions and follows the same
pattern and asks the questions in the same order as specified.
2. Unstructured Interview: In this the Interviewer starts the interview without any set of
questions but the conversation is kept on the topic by the interviewer and questions were
asked according to the conversation seriousness.
In both the formats of the Interview the questions can be closed ended (Specific answers to
questions based on some scale) or open ended (answer can be given according to the choice and
will of the interviewee)
Scrum
Scrum is a more project oriented approach to agile methods. One thing that is good with Scrum
and also the reason for selecting it as one of the two methods to focus on is that it does not focus
so much on the development but more on everything around it. This gives a broader view on
development. The RE and RT can be done with Scrum. The working style of scrum should be
collaborative and communicative (Abrahamsson, P et al 2002).
Scrum Process
Before the development, when a scrum team starts a new project or a new big release,
there will be a planning which defines a comprehensive backlog list, where all the
functionality requirements are logged. Based on the known backlog, the backlog items to
be implemented in the new release are chosen, and the cost and the risk is estimated and
analyzed.
The architecture/high level design takes place after the planning. The implementation of
the backlog items is designed and the architecture of the system is refined to be adapted
to the new environment and/or requirements.
Then comes the development phase, where sprints happen iteratively. Usually a sprint
lasts for one to four weeks. The backlog items in the current sprint are prioritized and are
not allowed to be changed (Abrahamsson, P et al 2002). During a sprint, there are
usually:
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Daily scrum that happens precisely on time and is time‐boxed to 15 minutes. Every
developer reports what he/she has done the last day, what he/she plans to do today and if
there are any problems in the work.
Sprint planning meeting which is at the beginning of a sprint. The scrum team chooses
what tasks should be done in the sprint and estimates the working time for these tasks.
Sprint review meeting. The team presents to the stakeholders what they have completed.
Sprint retrospective, where all the team members reflect on the past sprint, to see what
has been done well and what can be improved in the coming sprint (Scrum Alliance).
The last phase is closure phase which happens when the management thinks that it is time
for a new release. The integration, system testing, documentation etc are the tasks in this
phase.
Roles
The Main roles in the Scrum are played by the:
Product Owner: The one who speaks for the customers and makes sure that the team is working
with what the customers need. A product owner should write customer centric items, prioritize
them and put them into product backlogs. During the working time, the product owner should sit
with the developers and answer all their questions about the requirements.
Scrum Master: A scrum master is not a team leader, but he/she should remove the obstacles that
prevent the team from releasing on time and make sure that scrum process is executed as it
should be.
Team: The group of people who are responsible for the development.
Customers: Participates in the tasks related to product backlog items for the system.
Managements: Makes the final decision and participates in the goals and requirements settings.
Extreme Programming (XP)
Extreme Programming is a software development methodology which is intended to improve
software quality and responsiveness to changing customer requirements. As a type of agile
software development. It advocates frequent "releases" in short development cycles (time
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
boxing), which is intended to improve productivity and introduce checkpoints where new
customer requirements can be adopted.
Extreme Programming Includes:
Programming in Pairs i.e. one person is viewing the code and other sits beside that person
interchangeably from time to time.
Code Review: With the programming in pairs the code is reviewed by the person who is sitting
with the person who is doing the code.
Unit Testing: XP does unit testing of each and every module that is prepared and delivers it to
the customer.
While Scrum focuses on everything around the developing methods XP does the opposite and
focuses on the team and developing practices. Therefore XP is a perfect partner to Scrum. XP
focuses more on some configuration management practices such as version control, workspace
management and build control. Because XP is a good partner to Scrum most of the practices that
could be implemented to adding traceability to Scrum can be added to XP.
User Story
User stories are used for agile software development (Agile Modeling).
They describe very thin slices of work to be implemented (Bergman, G, 2008). A user story is
usually just one or two sentences of description. It is written in the format of (Cohn, M. 2004):
As a [person in a role] I want to [perform some activity] so that [some goal is achieved].
The aim of using a user story is to mark the requests for system functionality. It is just a marker
rather than a requirements document. Later there will be more expansion on it when the relevant
requirement is to be handled (Bergman, G, 2008).
There are both advantages and disadvantages of using user stories.
A user story has these benefits (Bergman, G, 2008):
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Short
Smaller and thus easier to be estimated, prioritized and managed.
Can be split as small as one wants, which means it can fit into any size of iteration.
One thing worth being noted is that Mike Cohn suggested that non‐functional requirements can
also be described in the format of user stories, and the advantage of doing it is that people will
not forget the reason of having this NFR after sometime, especially when the NFR is an
organizational decision (mountaingoatsoftware).
Because user stories are extremely short descriptions of some single functionality to be
implemented (A. Sillitti ,G. Succi 2005, p 315), one of the main limitations of writing user stories
is:
It is hard to cover large projects only with user stories
The practice of the agile methods like Scrum and XP the RE and RT can be made and will the
Scrum team to gain the knowledge what is the current position of the software and what are the
requirement changes that have been proposed and maintaining traceability between the changes.
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
References
1. Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta, j. . (2002). Agile Software
Development Methods – Review and Analysis. VTT Electroniikka.
2. Agile . (1995). The State of Scrum. Available: Requirement engineering and traceability in
an agile environment.docx. Last accessed 12th Dec 2011.
3. Alliance,S.. Sprint Retrospective Meeting. Available:
http://www.scrumalliance.org/articles/39‐ glossary‐of‐scrum‐terms#1113. Last accessed
13th Dec 2011.
4. Bentley, R. and Dourish, P.. (1995). Medium versus mechanism: Supporting collaboration
through customization. Proceedings of the European Conference on Computer-
Supported Cooperative Work.
5. Bergman, G.. (2008). As a Gazelle to a Gazebo. Lean Magazine.
6. Boehm, B. (2000). Project Termination Doesn’t Equal Project Failure. Computer. 33 (9),
94-96.
7. Carroll, J.M., Rosson, M.B., Chin, G. and Koenemann, J.. (1997). Requirements
Development: Stages of opportunity for collaboration needs discovery. Proceedings of
Designing Interactive Systems: Processes, Practices, Methods, & Techniques., 55-64.
8. Cleland-Huang, J. . (2006). Requirements Traceability – When and how does it Deliver
more than it Costs?. 14th IEEE International Requirements Engineering Conference
(RE'06), IEEE. 14 (12), 323-323.
9. Cohn, M. . (2004). User Stories Applied: For Agile Software Development. Addison‐
Wesley.
10. Gotel, O., and Finkelstein, A.. (1994). An Analysis of the Requirements Traceability
Problem. Proceedings of the IEEE International Conference on Requirements
Engineering., 94-101.
11. Group ,S. (1995). Chaos Report. Available: Requirement engineering and traceability in
an agile environment.docx Last accessed 13th Dec 2011.
12. Ian,S. (2004). Software Engineering .: Addison‐Wesley, .7th Edition.
13. Leffingwell,D. . (2007). Mastering the Iteration: An Agile White Paper. Rally Software
Development Corporation.
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
14. Macfarlane, I and Reilly, I. (1995). Requirements Traceability in an Integrated
Development Environment. Proceedings of the Second IEEE International Symposium on
Requirements Engineering. 116-123.
15. Modeling,A.. (2000). User Stories. Available: Requirement engineering and traceability
in an agile environment.docx. Last accessed 14th Dec 2011.
16. Modeling,A.. Agile Requirements Modeling. Available: http://www.agilemodeling.com/
essays/ agileRequirements.htm#Types . Last accessed 13th Dec 2011.
17. Moore Michael, J and Shipman III, Frank M. (2000). A Comparison of Questionnaire-
Based and GUI-Based Requirements Gathering. The Fifteenth IEEE International
Conference on Automated Software Engineering. 116-123.
18. Potts, C., Takahashi, K. and Anton, A.I.. (1994). Inquiry-Based Requirements Analysis.
IEEE Software. 11 (2), 21-32.
19. Pressman ,R. Software Engineering . 5th ed. New York: Thomas Casson . 20.
20. Ramesh, B. (1998). Factors Influencing Requirements Traceability Practice. ”,
Communication of the ACM. 41 (12), 37-44.
21. Ramesh, B. and Jarke, M.(2001). Towards Reference Models for Requirements
Traceability. IEEE Transactions on Software Engineering.
22. Sillitti,A and Succi, G. (2005). Requirements Engineering for Agile Methods.
Engineering and Managing Software Requirements. 315.
23. Succeeding with Agile. Non‐functional Requirements as User Stories. Available:
http://blog. mountaingoatsoftware.com/non‐functional‐requirements‐as‐user‐stories .
Last accessed 14th Dec 2011.
24. Zave, P. . (1997). Classification of Research Efforts in Requirements Engineering. ACM
Computing Surveys. 29 (4), 315-321.
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
Abstract (10%)
Abstract
WAP (Wireless Application Protocol) phones are a growing relevant part of the mobile market,
and the number of offered WAP services is rapidly increasing. Usability is crucial for these
services, which must be easily operated on small screens and keyboards. Unfortunately, there are
very few published studies on the evaluation of WAP devices and services on users is not
typically on the rigorous experimental evaluations demanded by HCI research. This paper
PDRM Abstract, Dissertation Proposal And Literature review on Requirement Engineering and Traceability in agile Environment
presents a user study that evaluates two important interface design choices for WAP services
(implementation of single-choice selection and navigation among the different cards of a WAP
Site). Which have not been thoroughly investigated neither in the literature nor in design
practice. Besides the specific results obtained, one of the contributions of the paper is also to
present a case study of a carefully thought experimental procedure for evaluating different design
choices for a WAP service. This paper tries to provide confirmation that exploiting links for
single-choice selection and for navigation purposes can considerably increase the user’s
efficiency and overall usability of services intended for WAP mobile phones, with respect to
alternative solutions supported by WML.
Keywords: evaluation, mobile phones, user interfaces, user study, WAP.
References
1. Arehart C., Chidambaram N., Guruprasad S.,et al.: . (2000). Professional Wap, . Wrox
Press.
2. Kaasinen E., Aaltonen M., Kolari J., Melakoski S., Laakko T.. (2000). Two Approaches
to Bringing Internet Services to WAP Devices. Proc. 9th Internat. WWW Conf.,
Computer Networks Journal . 33, 231-246
3. Jokela T., Pirkola J. (1997). Using Quantitative Usability Goals: A Case Study about
Development of a User Interface for a Cellular Phone. . Proc. INTERACT 97. Chapman
and Hall, London .
4. Schmidt A., Schroder H., Frick O. (2000). WAP – Designing for small user interfaces. .
Proc. CHI2000 Conf. Human Factors in Computing Systems, Abstracts Volume. ACM
Press, New York Hall, London .
5. egroups.. WML and WMLScript Programmers . Available: www.egroups.com.
6. wap-dev. wap-dev, mailing list at . Available: wapwarp.com/wap-dev.
7. wap-dev. (2000). Openwawe Systems.: GSM Application Style Guide. Available:
http://www.phone.com/pub/gsm900-1800.pdf .