Skip to main content

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

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

Magic Quadrant for Enterprise Architecture Tools - 0 views

www.gartner.com/...reprints.do

requirements management architecture tools gartner enterprise

shared by Peter Van der Straaten on 10 Feb 14 - No Cached
  • Mega has a clear identification and understanding of stakeholder expectations across the entire organization
  • Web-based integrated platform that includes EA, GRC, and application portfolio management, and delivers an integrated set of solutions that deliver operational excellence for organizations facing complex integration issues with business and technology
  • Mega consistently integrates industry best practices in many aspects of its product offering. One example is the Object Management Group's Meta Object Facility (OMG MoF 2)-compliant repository
Peter Van der Straaten

Introduction to SAMATE - SAMATE - 0 views

samate.nist.gov/...Introduction_to_SAMATE.html

software assurance security Information security management ++++ IEEE quality assurance IEEE610

shared by Peter Van der Straaten on 27 Aug 13 - No Cached
  • establish a methodology for evaluating software assurance tools
  • Source Code Security Analyzers – This class of software tools examines source code files for security weaknesses and potential vulnerabilities
  • Web Application Vulnerability Scanners – These tools crawl a web application’s pages and search the application for vulnerabilities by simulating attacks on it
  • ...3 more annotations...
  • A new effort on Binary Code Scanners - Similar to source code security analyzers, this class of tool analyzes a compiled binary application, including libraries, and provides a report of code weakness over the entire application.
  • The SAMATE Reference Dataset (SRD) - A community repository of example code and other artifacts to help end users evaluate tools and developers test their methods
  • Third annual Static Analysis Tools Exposition, which is in progress. The goals are to enable empirical research based on large test sets, encourage improvement of tools, and speed tool adoption by objectively demonstrating their use on real software.
Peter Van der Straaten

INCOSE - RM Tools Database - 2 views

www.incose.org/...rmsurvey.aspx

requirements engineering INCOSE tool requirements management review

shared by Peter Van der Straaten on 17 Mar 10 - Cached
  • INCOSE Requirements Management Tools Survey
  • The survey responses, including the rating of compliance with each question or feature, are provided by the tool vendors directly. However, the TDWG reserves the right to review and correct any "informational injustices" (i.e. exaggerated answers).
  • Requirements Management Tool Survey Responses
  • Peter Van der Straaten on 17 Mar 10
     
    Survey responses by tool vendors; Microfocus tools not available
Peter Van der Straaten

Product Owner - Scaled Agile Framework - 0 views

www.scaledagileframework.com/product-owner

scrum SAFe product owner requirements engineering business analysis qbest

shared by Peter Van der Straaten on 17 Mar 22 - No Cached
  • For most enterprises moving to Agile, this is a new and critical role, typically translating into a full-time job, requiring one PO to support each Agile team (or, at most, two teams). This role has significant relationships and responsibilities outside the local team, including working with Product Management, Customers, Business Owners, and other stakeholders
  • Without the right number of people in the right roles, bottlenecks will severely limit velocity.
1 - 6 of 6
Showing 20▼ items per page