Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile comparison with requriement approaches


Published on

IEEE 830, use case, scenario planning & user stories are all requirement-based approaches.

Each approach can be used in the different situation.

Published in: Business, Technology

Agile comparison with requriement approaches

  1. 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. 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
  3. 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 requirementsLow 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. 4. IEEE 830 – 1998 vs. User stories Problem: First few requirements User told: her goal …3.4) The product shall have a gasoline-poweredengine. 1. The product makes it easy3.5) The product shall have four wheels. and fast for me to mow my 3.5.1) The product shall have a rubber tire lawnmounted to each wheel. 2. I am comfortable while using3.6) The product shall have a steering wheel. the product3.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. 5. Use Case • Use case (UML) Use caseactor 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);
  6. 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 needsPurpose 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, Exceliteration user story (~use case slice) & Wiki pagesPlan & No (just estimate project size by “use Project estimation & planning (via (dependingestimate cases points”) story points & velocity) on how theScope 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. 7. Scenarios vs. User Stories • Scenarios (interaction design) are stories – How to the future approaches for our org./world • Different Interaction design User stories scenariosFocus Describe the persona(role), User’s goal Anggreeni and Van der Voort, 2008b context of the systemGoal Find well plans or strategies Make product to confront uncertainties for customerScope Broader; include more Customer stories; complexity wants directed
  8. 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 loopstory 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. 9. Reference• Mike Cohn (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional. • applied-for-agile-software-development• Ivar Jacobson (2011). Use cases – What is New?. •• Gipi blog (2010). Use case diagram. • case-diagram.aspx• Andrew Stellman (2009). Requirements 101: User Stories vs. Use Cases. • user-stories-vs-use-cases/ Andrew Stellman review -> 2005