Skip to main content

Home/ BARE+IA Requirements Engineering Information&Business Analysis/ Group items tagged use case

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Peter Van der Straaten

Alistair.Cockburn.us | Use cases, ten years later - 1 views

alistair.cockburn.us/Use+cases,+ten+years+later

requirements engineering use case training cockburn debate

shared by Peter Van der Straaten on 05 Feb 15 - No Cached
  • Is a use case a requirement or just a story? Is a scenario just another name for a use case? Is a use case a formal, semi-formal, or informal structure? Is there a linking structure for use cases, or do they just come in piles?
  • make use cases “rigorous
  • People want a fairly informal medium in which to express their early thoughts
  • ...28 more annotations...
  • handling all the variations a system must handle.
  • Using these semi-formal structures, we can both Assert that use cases really are requirements and need a basic structure, and also Allow people to write whatever they want when they need to.
  • Here is the semi-formal structure
  • Linking use cases to actors’ goals
  • If the software supports those goals, the software will yield the greatest business value.
  • goals sometimes fail
  • failure handling
  • Therefore, a use case is structured into two sections: the sequence of actions when everything goes well, followed by various small sequences describing what happens when the various goals and subgoals fail.
  • Why do we write things in the use case that are not externally visible behaviors?
  • contract between stakeholders
  • there remained a split between those who still wanted to keep use cases short and informal and those who wanted them to be detailed
  • Here are four key pieces of advice that you should note from the evolution of use cases.
  • readable use cases might actually get read
  • Prepare for Multiple Formats
  • Only Use Them When the Form is Appropriate
  • Be Aware of Use Case Limits
  • Use cases should not be used to describe UI designs
  • use case is normally intended as a requirements document, and the UI design is a design
  • The same system feature is likely to show up as a line item in multiple use cases
  • Use cases have a basic mismatch with feature lists
  • Use cases are not test plans or test cases
  • Avoid the Standard Mistakes in Use Cases
  • The two most common and most costly to the project are including too many details and including UI specifics
  • it’s just that by the time I get subgoals at a good level and remove the design specifics, the task is less than nine step
  • The greatest value of the use case does not lie in the main scenario, but in alternative behaviors
  • If the main scenario is between three and nine steps long, the total use case might only be two or three pages long, which is long enough.
  • The Stakeholders and Interests model fills the holes in the Actors and Goals model
  • Originally published in STQE magazine, Mar/Apr 2002
Peter Van der Straaten

BDD,Cucumber,Gherkin,User Stories,use cases,TDD - IT Jobs Watch Search - 0 views

www.itjobswatch.co.uk/default.aspx

specification development BDD TDD EPO Agile requirements engineering business analysis

shared by Peter Van der Straaten on 27 May 21 - No Cached
  • TDD34-8£60,000-6,064 (6.48%)1,470
  • BDD109-29£60,000+3.44%2,823 (3.02%)607
  • User Experience43+8£55,000-5,279 (5.65%)1,045
  • ...9 more annotations...
  • User Stories1730£55,000-1,814 (1.94%)335
  • DescriptionRank6 Months to27 May 2021RankYoY ChangeMedian SalaryMedian SalaryYoY ChangeHistoricalPermanentJob AdsLiveJobs
  • Cucumber279-20£60,000+14.28%1,051 (1.12%)143
  • User Acceptance Testing284-56£47,500-5.00%1,039 (1.11%)193
  • Business Cases311-71£56,878-5.20%932 (1.00%)210
  • Use Case3170£63,500+10.43%917 (0.98%)206
  • User Experience Designer443-30£52,500-4.54%581 (0.62%)101
  • Gherkin598-4£52,500-331 (0.35%)45
  • Epic User Stories616+64£57,542-7.93%304 (0.33%)50
Peter Van der Straaten

Alistair.Cockburn.us | Why I still use use cases - 1 views

alistair.cockburn.us/Why+I+still+use+use+cases

agile use case user story uml cockburn debate

shared by Peter Van der Straaten on 25 May 12 - Cached
  • XP pretty much banned use cases, replacing them with the similar sounding “user stories”
  • Scrum did similar, using the “product backlog” instead of user stories
  • Yet as I go around projects, I keep running across organizations suffering from three particular, real, painful, and expensive problems
  • ...15 more annotations...
  • User stories and backlog items don’t give the designers a context to work from
  • don’t give the project team any sense of “completeness
  • don’t provide a good-enough mechanism for looking ahead at the difficulty of upcoming work
  • Staring at the set of extension conditions in a use case lets the analysts suss out which ones will be easy and which will be difficult, and to stage their research accordingly
  • Here 5 reasons why I still write use cases
  • The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users
  • The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do.
  • The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget
  • The use case extension scenario fragments provide answers to the many detailed, often tricky business questions
  • The full use case set shows that the investigators have throught through every user’s needs, every goal they have with respect to the system, and every business variant involved
  • how much should be written up front to get the project estimate into a safe place
  • several sticky parts for people using use cases
  • iteration/sprint lengths are so short that it is not practical to implement an entire use case in just one of them.
  • Writing good use cases (or any other requirements) requires thinking, communicating, and thinking again. It is much easier just to write user-story tags on index cards and let the project blow up later
  • We have adopted many of the concepts of Agile development—such as daily build and test, build the smallest piece of functionality that delivers value, etc.—but have retained our up-front work. It’s worked extremely well
Peter Van der Straaten

Alistair.Cockburn.us | A user story is the title of one scenario whereas a use case is ... - 0 views

alistair.cockburn.us/contents+of+multiple+scenarios

agile use case user story uml cockburn debate

shared by Peter Van der Straaten on 25 May 12 - Cached
  • As a … I want… so that…” is a new-fangled user story format. The original XP user story format had no rules, so you could simply highlight any phrase in a use case and call it a user story. Personally, I feel sorry for anyone who has to write “As a… I want… so that…” for 200 user stories. Kind of like being kept after school and having to write “I will not write silly user stories in class” 100 times
  • A use case pretty much by definition contains multiple stories. A use case is a collection of scenarios related to the primary actor’s goal – some scenarios show the actor interacting with the system and the system interacting with other systems so that they succeed with the goal, some show failure. That’s all in the nature of a use case. see Structuring use cases with goals (discussion: Re: Structuring use cases with goals) from 1995. A use case written for this will occupy between half a page for a shortish one to 2 pages for a long one. A user story is a nickname for a single scenario – it contains neither the information content of the scenario nor failure or alternate paths. A user story typically occupies 1/2 to one sentence no matter its size.
  • (p.s. Agile was supposed to reduce bureaucracy and overhead, not add to it. :) Alistair
Peter Van der Straaten

Use Cases of Mass Destruction | Dr Dobb's - 1 views

www.drdobbs.com/...184415814

Use case cockburn agile Scott Ambler review debate

shared by Peter Van der Straaten on 27 Sep 13 - No Cached
  • examined the effectiveness of use cases;
  • two fundamental observations
  • 1. Use cases, when used properly, can be an effective form of requirements. 2. From an industry perspective, use cases may have a negative impact on overall productivity.
  • ...7 more annotations...
  • bureaucrats often want you to make your use cases more complex and wordy than they need to be
  • many organizations are struggling with use cases
  • use cases have had a negative impact on our overall productivity across the IT industry
  • Use-case modeling specialists
  • use cases are a critical part of anything you do, whether it's appropriate or not
  • They're very good for exploring usage requirements, but not so good for exploring user-interface or data requirements, business rules, or constraints
  • too many people arguing about formatting issues, content issues, traceability issues
Peter Van der Straaten

Use-Case 2.0: the Power of Use Cases with the Lightness of User Stories by Piermarco Bu... - 0 views

prezi.com/...-the-lightness-of-user-stories

Use case cockburn presentation Use case 2.0 jacobson prezi agile ++++ debate

shared by Peter Van der Straaten on 26 Sep 13 - No Cached
  • Peter Van der Straaten on 26 Sep 13
     
    Note: Nice presentation, but should check for content (it states that use cases are test cases, and that would at least need some additional instructions).
Peter Van der Straaten

Use Cases for Business Analysts - The New School - 0 views

www.modernanalyst.com/...Use-Cases--The-New-School.aspx

requirements engineering business analysis use case BPMN

shared by Peter Van der Straaten on 22 Jul 21 - No Cached
  • In my experience use cases are very powerful tools - their purpose is show the view from a *user's point of view*. The presented example is already very technical, and specifies a lot of details.
  • May I offer alternatives to the example in the article?A) A few brief classic requirements (for business) & a diagram (BPMN or UML activity diagram) (for the engineers)B) A use case with a lot less details (maybe 4-8 steps) & user interface design & a list of business rules (describing the essence of the details)C) No use case. One single sentence describing the goal & rationale ("As a user I want to have a recovery method when I forget the password because ....") & brief description of the important parts, business rules (no flow details!) & user interface design
  • May I offer other improvements to the "classic" use case in the example?- Instead of a summary, formulate it as a goal (remove redundancy)- Adding how frequently this is done ("Frequency: seldom, max. once per month ... once every few years")- Keep the main flow under 10 points- Remove pre-conditions and post-conditions. Keep it simple.- Integrate the alternative flows into the main flow (if possible, leave away details)
Peter Van der Straaten

Use cases or business process maps, what technique to use? - 0 views

www.modernanalyst.com/...aps-what-technique-to-use.aspx

requirements engineering business analysis use case BPMN

shared by Peter Van der Straaten on 22 Jul 21 - No Cached
  • shed some light on the difference between process maps and use cases.
  • different techniques and basically the result is the same
  • if you’re more comfortable with use cases then stick to them or if you’re more familiar with process maps then draw a map
Peter Van der Straaten

agile - How to use BPMN and use case and other diagrams together - Software Engineering... - 0 views

softwareengineering.stackexchange.com/...se-and-other-diagrams-together

use case business analysis requirements engineering BPMN

shared by Peter Van der Straaten on 22 Jul 21 - No Cached
  • The only use cases that should be left over should be cases that describe situations that are not fully covered by the BPMN.
Peter Van der Straaten

The Rational Edge -- June 2002 -- Top Ten Ways Project Teams Misuse Use Cases -- and Ho... - 0 views

diigo.com/07b4b1

use case ++++ gottesdiener requirements engineering agile debate

shared by Peter Van der Straaten on 05 Feb 15 - No Cached
  • Be ambiguous about the scope of your use cases.
  • Don't be concerned with defining business rules.
  • Write your first and only use case draft in excruciating detail.
  • ...3 more annotations...
  • use case nicely describes an aspect of its behavior
  • Don't Bother with Any Other Requirements Representations
  • behavior, structure, dynamics, and control mechanisms.
Peter Van der Straaten

Use-Case 2.0 ebook - 0 views

www.ivarjacobson.com/use_case2.0_ebook

ebook book requirements engineering use case cockburn ++++ Use case 2.0 debate

shared by Peter Van der Straaten on 25 May 12 - No Cached
  • re-focuses on the essentials and offers a slimmed down, leaner way of working, for software teams seeking the benefits of iterative, incremental development at an enterprise level
  • Author: Ivar Jacobson, Ian Spence, Kurt Bittner
  • Based on several years of work with many of our customers around the world, we have revamped use cases to provide a scalable approach to managing requirements for agile projects and programs.
  • Peter Van der Straaten on 25 May 12
     
    Free e-book (after registration)
Peter Van der Straaten

User story - Wikipedia, the free encyclopedia - 0 views

en.wikipedia.org/User_story

use case debate user story

shared by Peter Van der Straaten on 05 Feb 15 - Cached
  • Comparing with use cases
  • Kent Beck, Alistair Cockburn, Martin Fowler and others discussed this topic further on the c2.com wiki (the home of extreme programming).[16]
  • "User Story And Use Case Comparison". c2.com.
Peter Van der Straaten

Introduction to Personas - 0 views

www.agilemodeling.com/...personas.htm

agile requirements engineering business analysis 2011-2015 personas Scott Ambler actors Use case

shared by Peter Van der Straaten on 23 Nov 12 - Cached
  • Unlike actors, personas are not roles which people play
  • Personas are different because they describe an archetypical instance of an actor.  In a use case model we would have a Customer actor, yet with personas we would instead describe several different types of customers to help bring the idea to life.
  • first introduced by Alan Cooper
1 - 20 of 31 Next ›
Showing 20▼ items per page