Skip to main content

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

Rss Feed Group items tagged

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

BDD 101: Introducing BDD | Automation Panda - 0 views

automationpanda.com/...bdd-101-introducing-bdd

BDD requirements requirements analysis TDD EPO agile impact map

shared by Peter Van der Straaten on 20 May 21 - No Cached
  • 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

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
  • Here are four key pieces of advice that you should note from the evolution of use cases.
  • there remained a split between those who still wanted to keep use cases short and informal and those who wanted them to be detailed
  • The Stakeholders and Interests model fills the holes in the Actors and Goals model
  • 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.
  • readable use cases might actually get read
  • Originally published in STQE magazine, Mar/Apr 2002
Peter Van der Straaten

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

www.ietf.org/rfc2119.txt

requirements specification rfc standards MoSCoW qbest requirements engineering requirements management

shared by Peter Van der Straaten on 19 Sep 16 - Cached
  • 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

Hightech Events: Scrum - 0 views

www.runbysoftware.com/...scrum

scrum Agile SAFe 2015 SPIder

shared by Peter Van der Straaten on 08 Jul 15 - No Cached
  • Scrum works very fine within small teams, adding new functionality in an incremental way. But how to transform traditional developers into a scrum way of working and how to align the multiple teams? How to maintain piles of legacy code? And how to go about solving the specific issues the high tech industry has with Agile? The session ‘Scrum is not enough!’ will give an overview of these challenges and presents best practices to address them.
  • Peter Van der Straaten on 08 Jul 15
     
    Inclusief presentaties
Peter Van der Straaten

Requirements Management Tools - Vendors and Freeware Suppliers - 0 views

easyweb.easynet.co.uk/...vendors.htm

requirements engineering tool requirements management review

shared by Peter Van der Straaten on 17 Mar 10 - Cached
  • 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
  • Peter Van der Straaten on 17 Mar 10
     
    Extensive list with short descriptions for each tool, grouped by type of tool
Peter Van der Straaten

Free BDD Behavior Driven Development Tutorial - Basics of BDD for Beginners | Step-by-S... - 0 views

www.udemy.com/...ners-step-by-step-from-scratch

course specification development BDD TDD EPO Agile requirements engineering business analysis

shared by Peter Van der Straaten on 26 May 21 - No Cached
  • This course will teach you the very basics and foundation of BDD along with examples & workflow
  • You will learn and witness how BDD starts in an Organization along with a BDD Workshop
  • What are the different phases of BDD, BDD in Sprints and Agile Teams, BDD Roles and Responsibilities
Peter Van der Straaten

BDD,Cucumber,Gherkin,User Stories,use cases,TDD - IT Jobs Watch Search - 0 views

www.itjobswatch.co.uk/default.aspx

specification development BDD TDD EPO Agile requirements engineering business analysis

shared by Peter Van der Straaten on 27 May 21 - No Cached
  • TDD34-8£60,000-6,064 (6.48%)1,470
  • BDD109-29£60,000+3.44%2,823 (3.02%)607
  • User Experience43+8£55,000-5,279 (5.65%)1,045
  • ...9 more annotations...
  • User Stories1730£55,000-1,814 (1.94%)335
  • DescriptionRank6 Months to27 May 2021RankYoY ChangeMedian SalaryMedian SalaryYoY ChangeHistoricalPermanentJob AdsLiveJobs
  • Cucumber279-20£60,000+14.28%1,051 (1.12%)143
  • User Acceptance Testing284-56£47,500-5.00%1,039 (1.11%)193
  • Business Cases311-71£56,878-5.20%932 (1.00%)210
  • Use Case3170£63,500+10.43%917 (0.98%)206
  • User Experience Designer443-30£52,500-4.54%581 (0.62%)101
  • Gherkin598-4£52,500-331 (0.35%)45
  • Epic User Stories616+64£57,542-7.93%304 (0.33%)50
Peter Van der Straaten

Behavior-Driven Development - 0 views

www.linkedin.com/...behavior-driven-development

course specification development BDD TDD EPO Agile requirements engineering business analysis

shared by Peter Van der Straaten on 27 May 21 - No Cached
  • Peter Van der Straaten on 27 May 21
     
    LinkedIn Learning BDD course (payed)
Peter Van der Straaten

(119) What is Behavior Driven Development? (4 minute cartoon on BDD) - YouTube - 0 views

www.youtube.com/watch

specification development BDD TDD EPO Agile requirements engineering business analysis

shared by Peter Van der Straaten on 26 May 21 - No Cached
  • Peter Van der Straaten on 26 May 21
     
    Intro to BDD as compared to TDD
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
1 - 12 of 12
Showing 20▼ items per page