COMSATS Institute of Information Technology

Requirements Engineering

Requirements Engineering in Agile Methods

Lecture-28

2

Recap How traceability information is used in change

impact analysis? Impact on time Impact on cost

Requirement engineering in agile methods

3

Today’s lecture Requirement engineering for agile methods

The Agile Manifesto Manifesto includes following points:

Individuals and Interactions over Process and Tools Customer Collaboration over Contracts Working Software over Documentation Responding to Change over Planning

From such values, a set of common practices and behaviors are identifies. Adaptability Incremental Development Frequent Releases Requirements Prioritization Before Every Iteration High Customer Involvement

Team Size in Agile Methods

Read more: http://www.devx.com/architect/Article/32836/0/page/2

Agile Approaches to Requirements Engineering The Customer

In AMs, the customer assumes a vital role. Usually, the term “customer” identifies a set of stakeholders that belongs to the organization that is paying for the development of a software product.

In the case of mass-products for which there are no organizations paying directly for the product, the development team has to identify an expert in the area (e.g., a marketing expert) that is able to act as the customer and participate in the development of the product.

This approach is feasible only if the size of the problem is limited and a single person can act as customer, representing all the stakeholders.

Agile Approaches to Requirements Engineering The customer-on-site practice defines some specific

requirements for the customer: Availability:

The customer has to be always available to answer questions coming from the development team. Any delay in the answer delays the development of the product.

Complete Knowledge: The customer is the representative for all the stakeholders.

Therefore, he is able to answer all questions, since he is the domain expert and knows how the application should work and the input/output data required. Again, this is possible if the size of the project is limited.

Decision Power: The customer is able to make final decisions and commitments.

Changes in requirements, acceptance of the features implemented, etc. can be decided directly by the customer, allowing a fast decision making process.

Agile Approaches to Requirements Engineering Waste in Requirements

AMs focus on the identification and reduction of waste in the development process.

Requirements engineering in AMs focuses on: Reduction of waste from requirements Managing the requirements evolution

Agile Approaches to Requirements Engineering

The main effects of waste in this area include: More source code to write and higher cost Increased complexity of the source code Delayed delivery of the final version of the application

with all functionalities More complex and costly maintenance More resources required by the application, including:

memory usage, processing power, network usage, etc Increased complexity of the application from the point

of view of the customer (e.g., more complex user interface, more effort to learn how to use the application, etc.)

Savings produced by the application in the production process of the customer are delayed

Agile Approaches to Requirements Engineering In order to reduce the probability of such

misunderstanding, AMs adopt several techniques focused on the interaction between the customer and the development team: The whole Development Team Collects Requirements

from the Customer Requirements are Collected using a Common Language Direct Interaction Between the Development Team and

the Customer Requirements Splitting

Waste Management Requirements Prioritization Incremental Releases

Requirements Evolution AMs base the requirements collection and

management on three main hypotheses: Requirements are not well known at the beginning

of the project Requirements change Making changes is not expensive

Requirements Evolution Managing variability is a challenge that AMs

approach in two ways: Decoupling Requirements Requirements Prioritization

Non-Functional Requirements AMs do not provide any widely accepted

technique for eliciting and managing non-functional requirements .

The need of specifying non-functional requirements is less important than in other context due to the continuous interaction with the customer.

After every iteration, the product is released and the customer is able to test the product.

If he identifies problems related to non-functional qualities, the team can adapt the system to meet such requirements in the subsequent iteration without affecting the schedule too much.

Roles and Responsibilities The Customer

The customer’s presence is extremely important in AMs, since the amount of documentation is reduced to the minimum and the development team often asks for clarification regarding requirements.

Developers They have to be very good developers, be able to work in

teams, and interact with the customer using his/her own language.

Managers In AMs, managers have to create and sustain a framework

for the establishment of a productive interaction between the development team and the customer.

They can achieve this goal identifying the best people to be included in an agile team, promoting collaboration, and negotiating contracts with the customer.

Agile process models Extreme Programming (XP) Adaptive Software Development Scrum Dynamic System Development Method (DSDM) Crystal Feature Driven Development Agile Modeling (AM)

Extreme Programming (XP) Perhaps the best-known and most widely used

agile method. Extreme Programming (XP) takes an ‘extreme’

approach to iterative development. New versions may be built several times per day; Increments are delivered to customers every 2 weeks; All tests must be run for every build and the build is only

accepted if tests run successfully. XP Values

Communication Simplicity Feedback Courage Respect

Extreme Programming (XP)

Extreme Programming (XP) XP Planning

Begins with the creation of user stories Agile team assesses each story and assigns a

cost Stories are grouped to for a deliverable

increment A commitment is made on delivery date After the first increment project velocity is used

to help define subsequent delivery dates for other increments

Extreme Programming (XP)

XP Design Follows the KIS (keep it simple) principle Encourage the use of CRC (class-responsibility-cards)

cards For difficult design problems, suggests the creation of

spike solutions — a design prototype Encourages refactoring — an iterative refinement of the

internal program design XP Coding

Recommends the construction of a unit test for a store before coding commences

Encourages pair programming XP Testing

All unit tests are executed daily Acceptance tests are defined by the customer and

executed to assess customer visible functionality

XP and agile principles Incremental development is supported through small,

frequent system releases. Customer involvement means full-time customer

engagement with the team. People not process through pair programming, collective

ownership and a process that avoids long working hours. Change supported through regular system releases. Maintaining simplicity through constant refactoring of code.

21

Summary Requirement engineering in AMs

Customer involvement Customer involvement is a key part of XP where

the customer is part of the development team. The role of the customer is:

To help develop stories that define the requirements To help prioritize the features to be implemented in each

release To help develop acceptance tests which assess whether or

not the system meets its requirements.

Requirements scenarios In XP, user requirements are expressed as scenarios or user

stories. These are written on cards and the development team break

them down into implementation tasks. These tasks are the basis of schedule and cost estimates.

The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates.

Story card for document downloading

Downloading and printing an article

First, you select the article that you want from a displayed list. Youthen have to tell the system how you will pay for it - this can eitherbe through a subscription, through a company account or by creditcard.

After this, you get a copyright form from the system to fill in and,when you have submitted this, the article you want is downloadedonto your computer.

You then choose a printer and a copy of the article is printed. Youtell the system if printing has been successful.

If the article is a print-only article, you canÕ t keep the PDF versionso it is automatically deleted from your computer .

XP and change Conventional wisdom in software engineering is to design

for change. It is worth spending time and effort anticipating changes as this reduces costs later in the life cycle.

XP, however, maintains that this is not worthwhile as changes cannot be reliably anticipated.

Rather, it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented.

Refactoring Refactoring is the process of code improvement where code

is reorganised and rewritten to make it more efficient, easier to understand, etc.

Refactoring is required because frequent releases mean that code is developed incrementally and therefore tends to become messy.

Refactoring should not change the functionality of the system.

Automated testing simplifies refactoring as you can see if the changed code still runs the tests successfully.

Testing in XP Test-first development. Incremental test development from scenarios. User involvement in test development and validation. Automated test harnesses are used to run all component

tests each time that a new release is built.

Task cards for document downloading

Task 1: Implement principal workflow

Task 2: Implement article catalog and selection

Task 3: Implement payment collection

Payment may be made in 3 dif ferent ways. The userselects which way they wish to pay. If the userhas a library subscription, then they can input thesubscriber key which should be checked by thesystem. Alternatively , they can input an or ganisationalaccount number. If this is valid, a debit of the costof the article is posted to this account. Finally , theymay input a 16 digit credit card number and expirydate. This should be checked for validity and, ifvalid a debit is posted to that credit card account.

Test case description

Test 4: Test credit card validity

Input:A string representing the credit card number and two integers representingthe month and year when the card expiresTests:Check that all bytes in the string are digitsCheck that the month lies between 1 and 12 and theyear is greater than or equal to the current year .Using the first 4 digits of the credit card number ,check that the card issuer is valid by looking up thecard issuer table. Check credit card validity by submitting the cardnumber and expiry date information to the cardissuerOutput:OK or error message indicating that the card is invalid

Test-first development Writing tests before code clarifies the requirements to be

implemented. Tests are written as programs rather than data so that they

can be executed automatically. The test includes a check that it has executed correctly.

All previous and new tests are automatically run when new functionality is added. Thus checking that the new functionality has not introduced errors.

Tools for Requirements Management in AMs UML Modeling Tools Requirements Negotiation Tools Instant Messaging Tools Project Management Tools