PDRM Assignment

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


References.................................................................................................................................................26

Abstract.....................................................................................................................................................29

References.............................................................................................................................................30


Dissertation Proposal

And

Literature Review

On

“Requirement engineering and traceability

In an 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.


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.


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



Traditionally Software Engineering generally includes the RE process which consists of

requirements elicitation, analysis, validation, documentation and management. RE tries to


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)


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


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


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.


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


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


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.


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.



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.


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.


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.


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


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.


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)


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.


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.



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:


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.


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.


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:


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:


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


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):


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.


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.


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.


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


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 .

Documents

PDRM Assignment