Skip to main content

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

Rss Feed Group items tagged

Peter Van der Straaten

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

  • 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
       
      Content quite superficial; It's somewhat usefull for RE, RM and BA newbies. Mostly advertises the blueprint tool
  •  
    VALT TEGEN: Relatief oppervlakkig, en meer een vehikel om eigen tool aan de man te brengen.
Peter Van der Straaten

Requirements Management Tools - Vendors and Freeware Suppliers - 0 views

  • Trends
  • Low Cost, Low Maintenance
  • Niche Specialisation
  • ...11 more annotations...
  • Not Calling it "Requirements" at all
  • Integration
  • Requirements Management Tools
  • Use Case Tools
  • Agile Development Tools
  • Industry-Specific Tools
  • Tools to Check & Validate Requirements
  • Tools to Animate & Simulate Requirements
  • Tools to Diagram & Visualize Requirements
  • Free & Shareware Tools
  • Free Trials
  •  
    Extensive list with short descriptions for each tool, grouped by type of tool
Peter Van der Straaten

Requirements.net: - The industry consortium for business analysis. - 0 views

  • Requirements.net is home of the industry consortium for business analysis. Through focus on requirements definition, visualization, and management, the companies behind Requirements.net are driven to share and sponsor best practices and technologies to improve industry requirements practices
  •  
    Consortium consists of HP Software, Blueprint, RQNG, Orasi, Sky IT, and CorTechs
Peter Van der Straaten

DREAM event - 1 views

  • Welkom bij het DREAM Event Atos Origin organiseert op dinsdag 9 maart 2010 voor de tweede keer het Dutch Requirements Engineering and Management event. Het event is open voor de gehele Requirements community; voor iedereen die werkt met specificaties.
  • Hartelijk welkom op de website van DREAM (Dutch Requirements Engineering And Management). In 2014 is al voor de 5de maal het DREAM event succesvol georganiseerd (zie hier een terugblik op de afgelopen events). We willen ook de komende jaren een bijdrage blijven leveren aan het verder verspreiden van de kennis en het begrip betreffende alles wat te maken heeft met requirements; van business rules tot en met user stories, van functioneel ontwerp tot en met modellen van bedrijfsprocessen.
Peter Van der Straaten

Key words for use in RFCs to Indicate Requirement Levels - 0 views

  • The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Peter Van der Straaten

Requirements Kenniscentrum - 0 views

  •  
    Redelijk goede kennisbank voor requirements. LET OP: wordt niet meer bijgehouden!
Peter Van der Straaten

Community | requirements kenniscentrum - 0 views

  •  
    Nicole de Zwart
Peter Van der Straaten

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

  • 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

Solim - DISTRIBUTEUR RAVENFLOW - 0 views

  • DISTRIBUTEUR RAVENFLOW
  • De Ravenflow product portfolio richt zich op  VISUELE ondersteuning bij het opstellen van REQUIREMENTS
  • Engelse taalelementen worden herkend en in een activiteitenflow  gemodelleerd en gevisualiseerd.   Gebruikers , Business analisten en requirements engineers worden onmiddelllijk (real time) geattendeerd op (mogelijk) ontbrekende requirements f ontbrekende of verkeerde procesflow.
Peter Van der Straaten

Certified Professional for Requirements Engineering - Wikipedia, the free encyclopedia - 0 views

  • The IREB was officially founded as the International Requirements Engineering Board in Fürth (Germany) in October 2006.
Peter Van der Straaten

Requirements Engineering: A Roadmap - 0 views

  •  
    This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future.
Peter Van der Straaten

SearchSoftwareQuality - Software Requirements researched and organized - 0 views

  • Requirements Software requirements resources to help development teams create quality software.
Peter Van der Straaten

Requirements by Collaboration Book - Ellen Gottesdiener - 0 views

  •  
    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

INCOSE - RM Tools Database - 2 views

  • 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
  •  
    Survey responses by tool vendors; Microfocus tools not available
Peter Van der Straaten

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

  • 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

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

  • 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

ICSE: ICSE '00, Requirements engineering: a roadmap - 0 views

  •  
    Requirements engineering: a roadmap
1 - 20 of 108 Next › Last »
Showing 20 items per page