Reading List: Requirements / Business Rules / BDD

Agile / BDD Requirements
Requirements Storytelling / Storymapping
Requirements and Business Rules
Cucumber / Gherkin
General
Lists

Agile / BDD Requirements

• Jon Tobey: Acceptance Criteria, Business Rules, & Acceptance Tests – advocates for acceptance criteria separate from acceptance tests – the former bulleted, with only the latter in Gherkin
• Prashant Kumar: Why is Acceptance Criteria Important for a Tester? – functional vs non-functional accept crit; should not include DoD items (e.g., code review done)
• Robert Galen: Technical User Stories – What, When, and How? – functional vs technical user story
• Smart & Molak: The five stages of BDD (and Agile) Adoption – Disruption -> Appreciation -> Comprehension -> Adoption -> Expansion
• Colantonio: BDD Code Review Checklist (prefers declarative style)
• Agile Aliance: BDD Definition, Benefits etc.
• Agile Aliance: Role-feature-reason (aka “user story format” – As a… I want… So that..) Definition, Benefits etc.
• Alan Klement: Replacing The User Story With The Job Story – “We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome”; “problem with user stories is that it’s too many assumptions and doesn’t acknowledge causality. When a task is put in the format of a user story… there’s no room to ask ‘why’ — you’re essentially locked into a particular sequence with no context”; a job story format: When _ (situation) I want to _ (motivation / intent) So I can _ (expected outcome); see also  5 Tips For Writing A Job Story; see also When Coffee and Kale Complete
• Good Requirements: Blog – BA Quotes etc.
• Smart: BDD in Action (book) (by primary contributor to Serenity-BDD reporting framework)
• Chris Matts: Feature Injection
• Joachim Bauernberger: The role of the Business Analyst in Agile Projects – to hold the BA accountable they are usually also involved in QA; while a BA is not a tester they should be able to define what the quality metrics of the projects are in order to meet the defined requirements and objectives; BA is accountable to both the business and the projects; specific tasks which make a BA an actual BA; having a BA in your organization is a great way to add accountability to Agile teams without stepping on your developers toes
• Ronald Ross et al.: The Business Agility Manifesto – Move beyond an IT / #rqmnts-centric view of specs. These days you need a Business Knowledge-Base.

Requirements Storytelling / Storymapping

• Storytelling for Agile (interview with Oana Juncu) – “Effective change agents are great storytellers of great inspirational stories”; “Stories bring value to people because they are such a great engagement agent”; “The base of a good story is a good answer to these questions: What is the story about? Who’s story is this? What is the hero’s quest? What is her Status Quo? Then build a narrative arch with answers to these questions”
• Oana Junco: Tell Stories To Escape The Curse of Knowledge – 6 points to tell a (good) story: 1) set the stage; 2) be concrete; 3) unveil the quest; 4) Tell what is the breaking-out event; 5) keep the groove; 6) set a clear outcome; book “Made to Stick” says good story to stick in people’s minds and ignite change should be: simple; unexpected; credible; concrete; emotional
• Jeff Patton: User Story Mapping – blog post, article, quick reference guides, slides
• Oana Junco: Leanovation Agile – blog
• Narrative Science: Let your People Be People (ebook free download)

Requirements and Business Rules

• Bill Wake: INVEST in Good Stories, and SMART Tasks – INVEST: I – Independent; N – Negotiable; V – Valuable; E – Estimable; S – Small; T – Testable
• Ronald Ross: The Kick-Off Word in Great Business Definitions: Guidelines for Building World-Class Business Glossaries – the definition of a term should start with a noun; the kick-off word of a definition should not be the term being defined; a definition should not be simply a synonym of the term defined; the kick-off word of a definition and the concept being defined should align
• Ronald Ross: The New Knowledge Paradigm: Challenges for Operational Excellence – “What IT mostly implements under today’s software platforms are not true business rules; rather, they are encoded representations of business rules.  If IT intervention is required to ‘read’ the stuff, you’re not looking at true business rules”; “True business rules are written in structured natural language (e.g., RuleSpeak^®) using standard business vocabulary.  They are about communicating knowledge, not requirements for software implementation.  True business rules are about running the business, not its systems”; “business agility:  being able to deploy change in business policies and business rules into day-to-day business activity as fast as business people and business analysts can determine the full business impact of the change and assess whether the change makes good business sense”; “Business agility results when the IT aspect of change in business policies and business rules disappears into the plumbing.  All artificial (IT-based) production-freeze dates for deployment disappear and the software release cycle becomes irrelevant.  The only constraint is how long it takes business people and business analysts to think through the change as thoroughly as they feel they need to”; “How system development needs to trace requirements into system designs is a very different proposition than the traceability needed for business obligations.  The two kinds of traceability can and should be separated.  Requirements are about building systems, whereas business rules are about running the business.  Requirements generally fade into the background when a system is delivered, whereas deployment sparks a whole new phase of life for business rules.”; “practicable rule:  an expression of a business rule that a capable (authorized) worker can read and understand and decide directly whether or not the business is in compliance in all circumstances to which the rule applies”; “those practicable rules that can be automated (by no means all of them) are interpreted into specifications that automated platforms can execute”
• Angela Wick: User Stories: You Don’t Have To Be Agile To Use Them! – “User stories become a valuable elicitation and analysis technique for all project teams, but the timing, documentation and level of detail can be adjusted to fit in a traditional, agile or hybrid model”; “Also, remember that user stories are not meant to be comprehensive—they will not lead us to every detail or task required to deliver a work product. Regardless of your project approach, you will need to supplement user stories with additional BA techniques that elicit detailed requirements, acceptance criteria or more dialog”
• Ronald Ross: Strategic Business Analysis – strategy and structure leading to the Policy Charter deliverable
• Ronald Ross: Know These 5 Basic Principles for Business Rules? – 1. No business rule is ever set in stone; 2. A business rule must make global sense across the entire scope; 3. There are no business rules until you say there are; 4. Business rules are not choices made in designing systems; 5. A business rule means exactly what the words you use to express it mean – nothing more and nothing less
• Ronald Ross: What is a Concept Model? – an analysis model that develops the meaning of core concepts for a problem domain; a semantic blueprint for the operational business concepts basic to business know-how; is expressed by a structured business vocabulary; its central business purpose is to support business communication
• Ronald Ross: What’s a True Business Rule? Not What You Probably Think – Some people think of business rules as loosely formed, very general requirements. Wrong. Business rules have definite form, and are very specific; kinds: definitional rule, behavioral rule
• Ronald Ross: The New Knowledge Paradigm: Enabling Operational Excellence – give your rules a good life; what are true business rules; “Business rules must be written in declarative form using structured natural language”
• Ronald Ross: Change Deployment Hell – treat business rules as a first-class citizen; Requirements evolve before deployment of a system; business rules continue to evolve after deployment of a system
• Ronald Ross: Requirements are Rules: True or False? – 1. Business people don’t naturally think of a ‘requirement’ as a ‘rule’; 2. Many ‘requirements’ never become rules
• Lucas van Biert: Rules vs Decisions or Decisions & Rules? – good article on the distinction between these and how decision tables are really based on business rules
• Silvie Spreeuwenberg: The future of business driven software development – Decisions, Case Mgmt. and AI – Adaptive Case Mgmt., Decision Analysis, Artificial Intelligence
• Silvie Spreeuwenberg: Top 10 columns from BRCommunity.com: Testable Requirements, Patterns and Capture, Authoring
• Silvie Spreeuwenberg: How to design for the unknown? – “There are simple ways to design systems for change and they have been around for ages”
• Silvie Spreeuwenberg: Rules in Shopify – improved overview; richer semantics; other rules
• Silvie Spreeuwenberg: Business Rules in Scrum Projects – user stories should be limited in detail by ‘what can be hand-written on a small paper note-card’; a better way is to take a breadth-first slice in the hierarchical knowledge structure
• Silvie Spreeuwenberg: The business rules virus – BRV – rules alone are not enough, predefined process has its place, can be thought of as a recipe describing what to do first, how and when to gather info, how to interact with env.
• Freddie McMahon: Knowledge Management: Why Microsoft Word is a poor medium for Procedures (Part 1) – geometric progression / series is a poor fit for being captured in ms-word
• Sylvie Dan: Eliciting Requirements for Clinical Decision Support (CDS) Systems – DMN (Decision Modeling Notation); DRD (Decision Requirements Diagram)
• 7 Reasons why the Algorithmic Business will Change Society – the oil for the IoT
• Tom Gilb: Planguage for Requirements
• Twitter: #businessrules
• Twitter: #BizArch

Cucumber / Gherkin

• theitriskmanager.com: The tragedy of Given-When-Then – “… there are at least three different types of things to specify about a system: 1. What the system looks like. 2. The calculations in a system, and the data needed. 3. The behaviour of the system based on its internal state, and the system interactions within and without the system.”; “Although Given-When-Then is a fantastic way to describe interactions, state and behaviour, it is a lousy way to describe data and calculations.”; “The reduction of the tester to an expert translator/typist is a tragedy. It means that the business analyst does not necessarily see the actual Given-When-Then statements and a disconnect occurs between the them and the testers and developers. Cucumber comes to be seen as a test automation tool rather than a repository of the system specification.”; “Business Analysts often do not see the feature files and do not fully understand the process. They see no value in cucumber, seeing it as a test automation tool.”; “Agile was created by studying those who “do it and help others do it”, except in the case of business analysis where developers make stuff up for business analysts to do… Where the observers, not the doers, define the process.”; “Ideally we will realise that Given-When-Then is a tool for describing the interactions, state and behaviour of systems. We will realise that describing data and calculations using the Given-When-Then format leads to tragedy, and will create and popularise tools and approaches using Excel to document examples.”
• Cucumber: Gherkin Wiki
• Groupon: Dima Kovalenko: Case Study: Poorly Written Cucumber Tests –
• Automation-excellence: Declare or Impair (pro-Declarative)
• WatirMelon: Cucumber: imperative or declarative? that is the question (pro-Imperative)
• Ben Mabey: Imperative vs. Declarative Scenarios in User Stories (pro-declarative but balanced perspective – endorsed by Aslak Hellesoy who created Cucumber)
• Friendly Tester: Using BDD Tools To Write Automated Checks != BDD – be sure gherkin is serving a purpose such as clarity or facilitating readability
• Jeff Nyman: The BDD Lure and Trap – “Unit tests are just another form of acceptance test when you realize that acceptance testing is an approach to testing, not a type of testing”;  references The Cucumber Trap
• Tea-Driven Development: Is Cucumber just a scam? (pro-Cucumber article, good pros and cons discussion in comments)

General

• Mosaic: Sizing Using Testable Requirements – Overview, Examples, FAQs
• Mosaic: Peter Wilson: Sizing Software Using Testable Requirements – TRs vs LOC, FPs; definition of TR: one or more TCs can validate it; TRs comprise both external user requirements and internal tech requirements; TRs vs. TCs; coverage status: HLR -> TR -> TCs -> % covered

Lists

• Dan North: BDD Articles (by BDD pioneer and creator of JBehave)