Skip to main content

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

Rss Feed Group items tagged

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

EAM-Initiative : ArchiMate® - 0 views

eam-initiative.org/...ArchiMate

ArchiMate architecture Enterprise architecture qbest togaf

shared by Peter Van der Straaten on 11 Apr 18 - No Cached
  • Advantages & Disadvantages of ArchiMate®
  • One advantage of ArchiMate® is that it enables the visualization of architectures on separate layers but also allows the depiction of cross-layer relationships
  • Additionally, ArchiMate® provides extensive list of enterprise architecture entities, a predefined meta-model, some simplified standard views and publicly available, comprehensive documentation. Also, tool support for modeling the enterprise architecture using this architecture description language is available
  • ...1 more annotation...
  • A downside of ArchiMate® is that there is a limited extensibility of the modeling language. Further, some concepts are ambiguous [BBL12] and modelers need training to apply the framework successfully. Finally, when implementing ArchiMate®, a terminology mapping assigning existing concepts to the ArchiMate concept needs to be conducted
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

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
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

Cawemo | Welcome - 0 views

cawemo.com

BPMN Business Process Modelling business analysis Business Process Analysis

shared by Peter Van der Straaten on 06 Jul 21 - No Cached
1 - 15 of 15
Showing 20▼ items per page