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 ................................................................................................................................................... 5 Theoretical Background ................................................................................................................................ 6 Requirement Engineering ......................................................................................................................... 6 Traceability................................................................................................................................................ 7 Agile software development ..................................................................................................................... 8 Aims and Objectives...................................................................................................................................... 9 Intellectual Challenge ................................................................................................................................. 10 Research Program ....................................................................................................................................... 11 Deliverables................................................................................................................................................. 13 Resources .................................................................................................................................................... 14 Literature Review ........................................................................................................................................ 14 Related Literature ....................................................................................................................................... 15 Learning Requirements ............................................................................................................................... 21 Types of requirements ................................................................................................................................ 22 Functional requirements and non functional requirements .................................................................. 22 Interviews................................................................................................................................................ 22 Scrum ...................................................................................................................................................... 23 Scrum Process ..................................................................................................................................... 23 Roles .................................................................................................................................................... 24 Extreme Programming (XP)..................................................................................................................... 24 User Story................................................................................................................................................ 25
PDRM
References .................................................................................................................................................. 27 Abstract ....................................................................................................................................................... 29 References .............................................................................................................................................. 30
PDRM
Dissertation Proposal And Literature Review On

Requirement engineering and traceability In an agile environment
PDRM
Requirement engineering and traceability In an agile environment

Abstract
The 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. Keywords Requirement 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
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 softwares 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
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 highquality software many industrial project teams work in an agile environment. Different from traditional SE process, agile method relies on iterative and incremental development and facetoface 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
communicate the thoughts or ideas and requirements of the products 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 customers 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 Zaves: Requirements engineering is defined as the branch of Software Engineering concerned with the realworld 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 subdiscipline 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
PDRM
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 industrys 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 subtasks and they are implemented in short timeboxed 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
PDRM
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 standup 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
PDRM
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
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
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 1
Task Description
Duration
In Depth study of Agile methodology (Scrum and 1 week XP)
2 3
In depth understanding of the RE and RT in SE
1.5 Weeks
How the RE and RT can be added to the Agile 2 weeks methodology
4.
Survey the existing literature and find the existing 1.5 weeks tools
5. 6. 7.
reviewing the accessible research work and finding the 2.5 weeks problems
Identifying the teams for the interviews
1.5 weeks
Interviewing the Teams and generating first paper 1.5 weeks for feedback
8.
Sending the first paper for the feedback to the 1.5 weeks Teams and other people
9.
Reviewing the tools for the RE and RT in SE
2.5 weeks
PDRM
10.
Testing the Tools for the correctness and according 2.5 weeks to the need of the team.
11. 12. 13.
Reviewing the tools according to the Requirement Writing the Final Dissertation report Time for evaluating the dissertation
1.5 weeks 2.5 weeks 2 weeks
Bar Chart
Weeks
Task13 Task12 Task11 Task10 Task9 Task8 Task7 Task6 Task5 Task4 Task3 Task2 Task1 0 5 10 15 20 25 30
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
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
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
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
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 predesigned 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 testcasebased 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
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
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
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
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 XPs 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
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 nonfunctional 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 systems 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.
Nonfunctional 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 customers and the developers 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
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
Daily scrum that happens precisely on time and is timeboxed 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
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
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 nonfunctional 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
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 glossaryofscrumterms#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 ComputerSupported Cooperative Work. 5. Bergman, G.. (2008). As a Gazelle to a Gazebo. Lean Magazine. 6. Boehm, B. (2000). Project Termination Doesnt 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. AddisonWesley. 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 .: AddisonWesley, .7th Edition. 13. Leffingwell,D. . (2007). Mastering the Iteration: An Agile White Paper. Rally Software Development Corporation.
PDRM
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 QuestionnaireBased 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. Nonfunctional Requirements as User Stories. Available: http://blog. mountaingoatsoftware.com/nonfunctionalrequirementsasuserstories . 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 (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
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 users 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 .

PDRM Assignment

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PDRM Assignment

Загружено:

Авторское право:

Доступные форматы

PDRM

Dissertation Proposal And Literature Review On

Requirement engineering and traceability In an agile environment

Dissertation Proposal Introduction

Agile software development

Aims and Objectives

Interview: Qualitative interviews will be performed with the company members

Dissertation Schedule Table

In Depth study of Agile methodology (Scrum and 1 week XP)

In depth understanding of the RE and RT in SE

How the RE and RT can be added to the Agile 2 weeks methodology

Identifying the teams for the interviews

Reviewing the tools for the RE and RT in SE

11. 12. 13.

1.5 weeks 2.5 weeks 2 weeks

The Results that that were found are:

approaches for well defined phase-driven development models.

The Problems that were discussed are:

The challenges of Engineering and traceability in agile environment

The final discussion of the paper describes:

The aim of the Paper was:

The Problems that were discussed are:

The final discussion of the paper describes:

Functional requirements and non functional requirements

The Main roles in the Scrum are played by the:

Extreme Programming (XP)

Extreme Programming Includes:

There are both advantages and disadvantages of using user stories.

A user story has these benefits (Bergman, G, 2008):

Вам также может понравиться