Scribd
Upload
14 views11 pages

Requirements Engineering For Agile Methods Updated

The document discusses Agile development methods, emphasizing their iterative and incremental nature, which allows for continuous collaboration and adaptation to changing requirements. It highlights the importance of customer involvement throughout the project and introduces user stories as a key technique for expressing requirements. The mnemonic INVEST is presented to evaluate user stories, ensuring they are independent, negotiable, valuable, estimable, small, and testable.

Uploaded by

tniaz596
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
14 views11 pages

Requirements Engineering For Agile Methods Updated

The document discusses Agile development methods, emphasizing their iterative and incremental nature, which allows for continuous collaboration and adaptation to changing requirements. It highlights the importance of customer involvement throughout the project and introduces user stories as a key technique for expressing requirements. The mnemonic INVEST is presented to evaluate user stories, ensuring they are independent, negotiable, valuable, estimable, small, and testable.

Uploaded by

tniaz596
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

COMSATS Institute of Information Technology

Software Requirements
Engineering

Requirements Engineering for Agile


Methods

Dr. Muazzam Maqsood


Introduction
 Agile development refers to a set of software development
methods that encourage continuous collaboration among
stakeholders and rapid and frequent delivery of small
increments of useful functionality.
 There are many different types of agile methods; some of the
most popular are
 Scrum, Extreme Programming,
 Lean Software Development,
 Feature-Driven Development,

 Agile methods are based on iterative and incremental


approaches to software development, which have been around
for many years .
Predictive vs Adaptive
 The agile development approaches have characteristics that
distinguish them from one another, but they all fundamentally
champion an adaptive (sometimes called “change-driven”) approach
over a predictive (sometimes called “plan-driven”) approach.
 A predictive approach, such as
 Waterfall development, attempts to minimize the amount of risk in a
project by doing extensive planning and documentation prior to initiating
construction of the software.
 The project managers and business analysts make sure that all
stakeholders understand exactly what will be delivered before it gets
built.
 This can work well if the requirements are well understood at the
outset and are likely to remain relatively stable during the project.
 Adaptive approaches such as agile methods are designed to
accommodate the inevitable change that takes place on projects.
 They also work well for projects with highly uncertain or volatile
requirements.
The agile development approach
 Agile development methods attempt to address some limitations of the
waterfall model.
 Agile methods focus on iterative and incremental development, breaking the
development of software into short cycles called iterations (or, in the agile
method known as Scrum, “sprints”).
 Iterations can be as short as one week or as long as a month.
 During each iteration,
 the development team adds a small set of functionality based on priorities established
by the customer,
 tests it to make sure it works properly, and validates it with acceptance criteria
established by the customer.
 Subsequent increments modify what already exists, enrich the initial features, add
new ones, and correct defects that were discovered.
 Ongoing customer participation enables the team to spot problems and changes
in direction early, thereby guiding developers to adjust their course before they
are too far down the wrong path.
 The goal is to have a body of potentially shippable software at the end of each
iteration, even if it constitutes just a small portion of the ultimately desired
product.
Customer involvement
 Collaborating with customers on software development
projects always increases the chances of project success.
 On waterfall projects,
 Customers typically dedicate considerable time up front,
helping the BA understand, document, and validate
requirements.
 Customers should also be involved later in the project during
user acceptance testing, providing feedback on whether the
product meets their needs.
 However, during the construction phase, there is generally little
customer involvement, which makes it difficult for a project to
adapt to changing customer needs.

5
Customer involvement(Cont….)
 On agile projects, customers (or a product owner who
represents them) are engaged continuously throughout
the project.
 During an initial planning iteration on some agile projects,
customers work with the project team to identify and
prioritize user stories.
 Customers must be available during iterations to provide input
and clarification during the design and construction activities.
 They should also test and provide feedback on the newly
developed features when the construction phase of the
iteration is complete.
User Stories
 User stories are a major technique used to express
requirements, like use cases.
 User stories are special because they use a consistent format
to express requirements that is easy to write, read, and
evaluate.
 User stories take the following format:
 “As a ‘who,’ I want to ‘what,’ so that ‘why.’”
 The “who” of the requirement is the stakeholder role for whom the
requirement is being formed. The requirement should be written as if
it is from this person’s point of view.
 The “what” of the requirement is the specific task or functionality
the stakeholder wants to achieve by using the product.
 The “why” of the requirement highlights the goals or visions of the
product, and it provides insight into the value or benefit of the
requirement.
Example
 An example of a user story based on the restaurant example

“As a customer, I want to be able to identify dietary


restrictions, so that I know I can eat the food I order.”

 User stories are useful, as they provide a clear and structured way to
express a requirement that also does not use too many technical
details.
 Unlike freely formed requirements, user stories ensure the “who,”
“what,” and “why” of a requirement are always accounted for.
 User stories are also useful because they are short and can be easily
written on physical index cards or sticky notes.
 This practice allows easy organization of requirements, which can be
re-organized when requirements change.
Below is an example of what a user story
might look like on an index card.
Mnemonic INVEST.
 User stories can be evaluated using the mnemonic INVEST.
 I Independent
This means the requirement can exist outside of other user stories and
still be meaningful. This allows for requirements and their user stories
to be freely rearranged if necessary.
 N Negotiable
User stories should also be general enough for the development team
and client to work around their implementation. They should not focus
on specific technical details. Instead, focus should be on the most
important aspects of requirements, while remembering that these could
change.
 V Valuable
User stories should bring value to the client.
Mnemonic INVEST (Cont..)
 E Estimatable
It should be possible to estimate how much time it would take to
design and implement the requirement in the user story.
 S Small
A user story should be small because it is meant to be developed
in a short time period. If the time to design and implement a
requirement is uncertain, the user story is likely too big, so it
should be broken down into smaller, manageable ones.
 T Testable
User stories should be verifiable against a set of criteria in order
to determine if it is “done”, meaning that the user story has
accomplished what it set out to do, and does not need further
work. This is usually accomplished with acceptance tests.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy