Skip to main content

Home/ Groups/ BARE+IA Requirements Engineering Information&Business Analysis
Peter Van der Straaten

ISO/IEC 42010:2007 architectural description of software-intensive systems - 0 views

  • Systems and software engineering -- Recommended practice for architectural description of software-intensive systems
  •  
    Systems and software engineering -- Recommended practice for architectural description of software-intensive systems
Peter Van der Straaten

IREB -Mission - 0 views

  • 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

SOLIM - software life cycle management - 0 views

Peter Van der Straaten

IREB - Zertifizierung - 0 views

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

IREB - Mission - 0 views

  • 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

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

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

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

SpringerLink - Journal - 0 views

  • Requirements Engineering
  • PublisherSpringer London
Peter Van der Straaten

Automating Requirements Management - K.E. Wiegers - 0 views

  • Automating Requirements Management
  • Software Development, July 1999
Peter Van der Straaten

BDD 101: Introducing BDD | Automation Panda - 0 views

  • Gherkin
  • test automation
  • The Big BDD Picture: The main goals of BDD are collaboration and automation
  • ...22 more annotations...
  • specification by example:
  •  Gherkin is one of the most popular languages for writing formal behavior specifications – it captures behaviors as “Given-When-Then” scenarios.
  • With the help of automation tools, scenarios can easily be turned into automated test cases.
  • Quick Points BDD is specification by example. When someone says “BDD”, immediately think of “Given-When-Then”. BDD focuses on behavior first. Behavior scenarios are the cornerstone of BDD. BDD is a refinement of the Agile process, not an overhaul. It formalizes acceptance criteria and test coverage. BDD is a paradigm shift. Behaviors become the team’s main focus.
  • 12 Awesome Benefits
  • Inclusion
  • Clarity
  • Streamlining
  • Artifacts
  • Shift-Left
  • Automation
  • Test­-Driven
  • Code Reuse
  • Parameterization
  • Variation
  • Momentum
  • Adaptability
  • behavior-driven development
  • Testing Recommendations
  • Since BDD focuses on actual feature behavior, behavior specs are best for higher-level, functional, black box tests. For example, BDD is great for testing APIs and web UIs.
  • Gherkin excels for acceptance testing
  • However, behavior specs would be overkill for unit tests, and it is also not a good choice for performance tests
Peter Van der Straaten

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

  • 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

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.
« First ‹ Previous 41 - 60 Next › Last »
Showing 20 items per page