Agile comparison with requriement approaches
9
Click here to load reader
-
Upload
fungfung-chen -
Category
Business
-
view
1.966 -
download
0
description
IEEE 830, use case, scenario planning & user stories are all requirement-based approaches. Each approach can be used in the different situation.
Transcript of Agile comparison with requriement approaches
Comparison with Requirement-
based Approaches
Chen Jing Fung @iii
2011/7/5
IEEE
830
Use
case scenario
Ref: Agile solutions as How to write, gather ideas, estimate
the approach, planning an iteration
The common requirement-based approaches
• IEEE std. 830 - 1998
– Guidelines on how to write software requirements specifications
• Use case (Dr. Ivar Jacobson 1992, update: 2003 & 2005)
– A description of steps/actions btw user/actor & software system => towards something useful
• Scenarios planning/thinking/analysis
– Some organizations use to make flexible long-term plans
http://ieeexplore.ieee.org/Xplore/login.jsp?url=http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=720574&authDecision=-203
http://blog.ivarjacobson.com/ivarblog/
Dr. Ivar Jacobson
(born 1939)
Comparison lists
Scenarios
• Purpose: communication (shared) -> analysis/design (user needs)-> decision-making
• Description: actors, activities (tasks), things (objects)
• Problem: +/- effects of features on the actor’s experience
Use case
• Tool: use case diagram in UML (graphical overview of the functionality)
• Terms: actors, goal, dependencies btw those use case (include/ extend/ generalization/ associations in practice)
• One use case tell >1 user story
IEEE 830
• Focus: how to organize the requirements spec. doc., the role of prototyping & characteristics of good requirements
• Method: PM write doc. ←→ developers rewrite it.
• Typical fragment: “The system shall …”
• Problem: too wordy (Ex: 300 pages/ medium system)
High Level
Design
customers
developers
Low Level
Design
User
story
2 groups writing separate version of
the same doc. => feedback loop
Few/
little
IEEE 830 – 1998 vs. User stories
3.4) The product shall have a gasoline-powered
engine.
3.5) The product shall have four wheels.
3.5.1) The product shall have a rubber tire
mounted to each wheel.
3.6) The product shall have a steering wheel.
3.7) The product shall have a steel body.
Problem: First few requirements
1. The product makes it easy
and fast for me to mow my
lawn
2. I am comfortable while using
the product
User told: her goal …
IEEE 830 User stories
Focus A list of attribution on solution User’s goal
Scope Write all requirement statement Iteration manner
Communication
strategy
Make sure words convey the
proper meaning
Feedback loop =>change of scope
Superiority of
conversations for
clarifying detail
Difficulty!! No efficiency (every
one just cares her part!!)
Enhance
writing skill Enhance
talking skill
Use Case
Class A …
log(data);
Class B …
log(data); Class B …
B(log);
Class A …
A(log);
Class log …
void log(string data) …
actor
Use case
From: wiki
• Use case (UML)
– AOP (Aspect-Oriented Programming) for log/security
refactoring
http://www.agile-ux.com/2009/01/23/use-cases-user-stories-so-precious-but-not-the-same/
http://fungsiong.blogspot.com/2011/05/refactoring-chapter-7.html
Agile: Use case vs. User stories
Use case User stories
Purpose Model the interaction btw users & the
system (a behavior to meet user need);
(write down conditions)
Customer-oriented; perform by
user language (Card)
An
iteration
Compose more story (more detail) > 1
user story (~use case slice)
Small, main success scenario
Plan &
estimate
No (just estimate project size by “use
cases points”)
Project estimation & planning (via
story points & velocity)
Scope
(time cost)
More time for analysis & writing; more
docs. ; a textual model (+ graphical
diagrams)
Faster; shorter (sticky note …);
verbal discussion to clarity details
(3C: Card, Conversation,
Confirmation)
Test Acceptance tests are created in a
separate docs.
Acceptance tests are written on
the back of the story card
• The same of use case & user stories – Capture functional requirements
– Goal-oriented => discover during user / customers workshop
– Easily combined with UX(user experience) activities & Agile contexts
• Different
Card ->
Word, Excel
& Wiki pages
(depending
on how the
particular
project is run)
System needs
to do for user “raw” user
needs
Scenarios vs. User Stories • Scenarios (interaction design) are stories
– How to the future approaches for our org./world
• Different Interaction design
scenarios
User stories
Focus Describe the persona(role),
context of the system
User’s goal
Goal Find well plans or strategies
to confront uncertainties
Make product
for customer
Scope Broader; include more
stories; complexity
Customer
wants directed
Anggreeni and Van der Voort, 2008b
Summary • User/customer will aim to well design
– No mater how much thinking3 we do • Can’t perfectly specify a non-trivial system upfront
– For a company/org/country, • Scenario planning draws the future development map => cut
down several user stories
• Customer-oriented: User stories aim to ask user wants – The value of feedback loop
» Define requirements <= user frequent access to software early
– Focus a sprint in an iteration
– Through conversations
» fill the facilitate release planning & serve as reminders
– Use 3C (Card/electrical recorder, Conversation, Confirmation) to talk, analysis & test
• Use case are mapped to the respective user stories – After user took, how the system responds
(close to developer programming design)
– only use “user stories” • Pair programming (stager-rookie) would be successful
… ….
Name
+Task
+ test
pair
scenario
story story story
Use
case
Use
case
Ref: Agile solutions as How to write, gather ideas,
estimate the approach, planning an iteration
Reference
• Mike Cohn (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional.
• http://www.mountaingoatsoftware.com/books/2-user-stories-applied-for-agile-software-development
• Ivar Jacobson (2011). Use cases – What is New?. • http://blog.ivarjacobson.com/use-cases-what-is-new/
• Gipi blog (2010). Use case diagram. • http://www.dotblogs.com.tw/jimmyyu/archive/2010/01/18/use-
case-diagram.aspx
• Andrew Stellman (2009). Requirements 101: User Stories vs. Use Cases.
• http://www.stellman-greene.com/2009/05/03/requirements-101-user-stories-vs-use-cases/
2005 Andrew Stellman review ->
