COMSATS Institute of Information Technology Requirements Engineering Requirements Engineering in Agile Methods Lecture-28
Jan 19, 2016
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