Skip to main content

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

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
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

http://www.agiledad.com/Documents/BAWhitepaperJune.pdf - 0 views

www.agiledad.com/...BAWhitepaperJune.pdf

agile Agile RE requirements engineering business analysis requirements management whitepaper VersionOne tool project management

shared by Peter Van der Straaten on 01 May 12 - No Cached
  • Peter Van der Straaten on 01 May 12
     
    VersionOne: Agile project management tool
Peter Van der Straaten

CollabNet - The Leader in Agile Application Lifecycle Management - 0 views

www.collab.net/...scrumworks

agile scrum project management uwv onno

shared by Peter Van der Straaten on 23 Sep 11 - No Cached
  • Peter Van der Straaten on 23 Sep 11
     
    ScrumWorks pro - agile project management
Peter Van der Straaten

eBook: Requirements Definition and Management for Dummies - Blueprint Software Systems - 0 views

www.blueprintsys.com/...ion-and-management-for-dummies

BARE ---- ebook requirements engineering requirements management

shared by Peter Van der Straaten on 14 Jul 14 - No Cached
  • Requirements Definition and Management for DummiesSmart businesses know that high-quality requirements are the cornerstone of any successful software development project. This fun and friendly ebook is an introduction to the role that is central to requirements: the Business Analyst. It explains why the role is so critical and how Business Analysts are transforming software projects.
    • Peter Van der Straaten
      Peter Van der Straaten on 14 Jul 14
       
      Content quite superficial; It's somewhat usefull for RE, RM and BA newbies. Mostly advertises the blueprint tool
  • Peter Van der Straaten on 14 Jul 14
     
    VALT TEGEN: Relatief oppervlakkig, en meer een vehikel om eigen tool aan de man te brengen.
Peter Van der Straaten

IREB -Mission - 0 views

www.certified-re.de/...mission.html

ireb requirements engineering certification

shared by Peter Van der Straaten on 12 Mar 10 - Cached
  • Requirements Engineering is a key discipline
  • the annual report of the Standish Group, “The Scope of Software Development Project Failures”. About half of all projects examined in the report fail to achieve their set goals because of a lack of requirements engineering.
Peter Van der Straaten

Requirements by Collaboration Book - Ellen Gottesdiener - 0 views

www.ebgconsulting.com/...reqtcoll.php

agile requirements engineering method workshops

shared by Peter Van der Straaten on 23 Sep 11 - No Cached
  • Peter Van der Straaten on 23 Sep 11
     
    Ellen has years of hands-on experience with Agile projects, with a focus on requirements. Key-note speaker on DREAM 2011; met her at evening workshop on 20110920.
Peter Van der Straaten

The beginner's guide to BDD (behaviour-driven development) - 0 views

inviqa.com/bdd-guide

BDD requirements requirements analysis TDD EPO agile

shared by Peter Van der Straaten on 20 May 21 - No Cached
  • to support the ability for systems to change, we should be able to safely make big changes (supported by automated scenarios), as well as the small ones (supported by automated object specifications).
  • Impact mapping
  • mind mapping
  • ...19 more annotations...
  • business goal, one or more actors, one or more impacts and one or more ways to support or prevent these impacts
  • You always start with the business goal; it is your map’s root node. You then grow the map out from the goal by first identifying all the actors (e.g. the customer or the team) that could help or prevent the project from achieving the goal. Each actor could have multiple ways to help or hinder achieving the goal, we call these impacts. The last layer of an impact map defines what the project or delivery team can do in order to support or prevent particular impacts from happening, and this is the layer where your software options come into play.
  • In BDD we use Cynefin to identify which features require the most attention
  • Value and complexity analysis
  • reuse
  • outsource
  • Cynefin to make strategic planning decisions based on value/complexity analysis
  • Planning in examples
  • Usage-centered design
  • Ubiquitous language
  • eliminate the cost of translation
  • borrowed from DDD (Domain Driven Design)
  • 'Given, describes the initial context for the example'When' describes the action that the actor in the system or stakeholder performs'Then' describes the expected outcome of that action
  • Introducing the three amigos
  • no single person has the full answer to the problem
  • business person, a developer and a tester.
  • Development through examples
  • The BDD loops
  • How we use it
Peter Van der Straaten

The PMI-PBA vs. IIBA CBAP or CCBA - 0 views

www.bridging-the-gap.com/e-pmi-pba-vs-iiba-cbap-or-ccba

certification CBAP CCBA PMI-PBA business analysis

shared by Peter Van der Straaten on 22 Jul 15 - No Cached
  • Through the new practice guide and PMI-PBA certification, PMI will drive an awareness of the role globally that IIBA® has simply not had the resources to do
  • To obtain a PMI-PBA, first you complete an application that verifies you meet the following requirements: Minimum of 3 years (4,500 hours) of business analysis experience within the past 8 consecutive years if you have a bachelor’s degree. (Or 5 years/7500 hours of experience if you do not.) (For comparison, the CBAP® requires 7,500 hours of experience and the CCBA® 3,750.) 2,000 hours working on project teams within the past eight consecutive years. 35 business analysis education (contact hours).
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

IREB - Mission - 0 views

www.certified-re.de/mission.html

requirements engineering certification

shared by Peter Van der Straaten on 12 Mar 10 - Cached
  • Requirements Engineering ist eine Schlüsseldisziplin
  • jährliche Bericht der Standish Group “The Scope of Software Development Project Failures”
  • Rund die Hälfte der in dem Bericht untersuchten Projekte erreicht die angestrebten Ziele nicht aufgrund von Fehlern im Requirements Engineering.
Peter Van der Straaten

InfoQ: IIBA announce Agile Extension to the Business Analysis Body of Knowledge - 1 views

www.infoq.com/...agile-babok-announce

IIBA infoq agile BABOK requirements engineering

shared by Peter Van der Straaten on 23 Sep 11 - No Cached
  • IIBA(tm)) announced the release of a draft of the Introduction for the Agile Extension to the Business Analysis Body of Knowledge (BABOK
  • many business analysts are struggling to understand how the role changes in Agile projects
  • "weak" or "sham" Agile implementations in organisations where "doing Agile" is not accompanied by any real cultural or governance change
  • ...2 more annotations...
  • public draft of the introduction to the extension.  This is available from the IIBA website 
  • Simultaneously Chris Matts and others formed the Agile BA Requirements Yahoo group
  • Peter Van der Straaten on 23 Sep 11
     
    Also other remarks on Agile and BA
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

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.
1 - 20 of 22 Next ›
Showing 20▼ items per page