The document compares requirement-based approaches to software specification, focusing on IEEE Std. 830 and use cases. It highlights the communication, analysis, and decision-making roles in software requirements, contrasting traditional detailed specifications with more agile user stories that prioritize user goals. The discussion emphasizes the iterative and feedback-driven nature of user stories and scenarios in agile development, advocating for a user-centric approach in defining software requirements.

1. Comparison with Requirement-
based Approaches
IEEE Use
scenario
830 case
Chen Jing Fung @iii
2011/7/5
Ref: Agile solutions as How to write, gather ideas, estimate
the approach, planning an iteration

2. 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
Dr. Ivar Jacobson
planning/thinking/analysis (born 1939)
– 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/

3. Comparison lists
customers
• Purpose: communication (shared) -> analysis/design (user
needs)-> decision-making
• Description: actors, activities (tasks), things (objects)
High Level Scenarios • Problem: +/- effects of features on the actor’s experience
Design
User
story • 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)
Use case • One use case tell >1 user story
• Focus: how to organize the requirements spec. doc., the role
of prototyping & characteristics of good requirements
Low Level • Method: PM write doc. ←→ developers rewrite it.
Design • Typical fragment: “The system shall …”
IEEE 830
• Problem: too wordy (Ex: 300 pages/ medium system) Few/
little
2 groups writing separate version of
developers the same doc. => feedback loop

4. IEEE 830 – 1998 vs. User stories
Problem: First few requirements
User told: her goal …
3.4) The product shall have a gasoline-powered
engine. 1. The product makes it easy
3.5) The product shall have four wheels. and fast for me to mow my
3.5.1) The product shall have a rubber tire lawn
mounted to each wheel. 2. I am comfortable while using
3.6) The product shall have a steering wheel. the product
3.7) The product shall have a steel body.
Enhance Enhance
writing skill talking skill
IEEE 830 User stories
Focus A list of attribution on solution User’s goal
Scope Write all requirement statement Iteration manner
Communication Make sure words convey the Superiority of
strategy proper meaning conversations for
Feedback loop =>change of scope clarifying detail
Difficulty!! No efficiency (every
one just cares her part!!)

5. Use Case
• Use case (UML)
Use case
actor
From: wiki
– AOP (Aspect-Oriented Programming) for log/security
Class log …
void log(string data) …
Class A … Class B … refactoring
log(data); log(data);
Class A … Class B …
A(log); B(log);
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

6. Agile: Use case vs. User stories
• 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 System needs
“raw” user
Use case to do for user User stories needs
Purpose Model the interaction btw users & the
Customer-oriented; perform by
system (a behavior to meet user need);
user language (Card)
(write down conditions)
Card ->
An Compose more story (more detail) > 1 Small, main success scenario Word, Excel
iteration user story (~use case slice)
& Wiki pages
Plan & No (just estimate project size by “use Project estimation & planning (via (depending
estimate cases points”) story points & velocity) on how the
Scope More time for analysis & writing; more Faster; shorter (sticky note …); particular
(time cost) docs. ; a textual model (+ graphical verbal discussion to clarity details project is run)
diagrams) (3C: Card, Conversation,
Confirmation)
Test Acceptance tests are created in a Acceptance tests are written on
separate docs. the back of the story card

7. Scenarios vs. User Stories
• Scenarios (interaction design) are stories
– How to the future approaches for our org./world
• Different
Interaction design User stories
scenarios
Focus Describe the persona(role), User’s goal
Anggreeni and Van der Voort, 2008b
context of the system
Goal Find well plans or strategies Make product
to confront uncertainties for customer
Scope Broader; include more Customer
stories; complexity wants directed

8. 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
scenario
down several user stories
• Customer-oriented: User stories aim to ask user wants
– The value of feedback loop
story story story » 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
Use Use talk, analysis & test Name
case case• Use case are mapped to the respective user stories
+Task
– After user took, how the system responds
(close to developer programming design) + test
– only use “user stories”
• Pair programming (stager-rookie) would be successful
pair
Ref: Agile solutions as How to write, gather ideas,
estimate the approach, planning an iteration

9. 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/
Andrew Stellman review -> 2005