Agile / BDD Requirements
Use Cases, User Stories, Use Case Scenarios
Requirements Storytelling / Storymapping
Requirements and Business Rules
Cucumber / Gherkin
General
Lists
- 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)
- 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.
Use Cases, User Stories, Use Case Scenarios
- PMI: Use cases: What every project manager should know – “…use cases describe the conversation between a system and its user(s)…”; “Use cases provide a structure for gathering customer requirements and setting the project scope.”; “… it does facilitate the development of user interfaces (screens), screen edits and messages, and acceptance test scenarios.”; Requirements-based testing may be thought of as a synonym for Acceptance Criteria; “Use cases: are the processes that occur within the system. Like other processes, they have a process scope. That is, they begin and end. They also transform input into output. Use cases are named with an active verb and a noun, such as Fulfill Order or Return Item.”; “While the ‘system’ can be defined as a business process, we don’t think it’s practical to do so. We have found that other process models, such as process maps, swim lanes, and activity diagrams are more effective.”; “The use case diagram is a particularly effective tool to help identify and manage project scope…. helps identify scope in these ways: Sets the boundary for the project… Shows the processes under consideration… The flow of events confirms the scope… All the use cases need to link to the business and project vision and objectives…”; “… helps control scope in these ways: Once use cases have been confirmed, new use cases that arise can be better managed…. f new actors surface… if new use cases cause any linkage to change…”; “Risk management. It is helpful to examine risks and deal with the highest risk project factors first. In the beginning of the project, use cases as denoted in the use case diagram can help the project team identify and analyze such risk factors as the use of new technology…”; “We encourage a separate requirements list for traceability.”
- Robert Galen: Technical User Stories – What, When, and How? – functional vs technical user story
- Visual Paradigm: User Story vs Use Case – “User Stories deliberately leave out a lot of important details. User Stories are meant to elicit conversations…”; “Small increments for getting feedback more frequently, rather than having more detailed up-front requirement specification as in Use Cases”; “Each User Story consists of a short description written from user’s point of view, with natural language”; “User Story focuses on what the user needs instead of what the system should deliver”; “Use Cases capture all the possible ways the user and system can interact that result in the user achieving the goal. They also capture all the things that can go wrong along the way that prevent the user from achieving the goal.”; “…three main problems with User Stories: 1. Lack of context (what’s the largest goal), 2. Sense of completeness that you covered all bases relating to a goal, 3. No mechanism for looking ahead at upcoming work.”
- Wrike: What Is a Use Case? “… outlines the interactions between users or actors and the system to achieve a specific outcome.”; “A use case is a description of the ways in which a user interacts with a system or product. A use case may establish the success scenarios, the failure scenarios, and any critical variations or exceptions.”; Primary purposes: Manage scope; Establish Requirements; Outline how users interact with system; “Project managers need to know about use cases because they help communicate strategy to stakeholders and bridge the gap between business justification and technical requirements.”; “use cases provide a structure for gathering customer requirements and setting the project scope.”; “a scenario is a specific sequence of actions and interactions between actors and the system under discussion; it is also called a use case instance.”
- Greene & Stellman: Requirements 101: User Stories vs. Use Cases – Example Use Case: Search and Replace; Example User Story (aka Scenario): A user realizes they mis-capitalized a word in their doc, so they tell the word processor to search and replace to correct; “User stories are about… a “raw” user need”; “Use cases are about the behavior you’ll build into the software to meet those needs.”; “Use cases describe a complete interaction between the software and users (and possibly other systems).”;
- Alistair Cockburn: Basic Use Case Template – A solid text-based use-case format with scope, level, preconditions, etc.
- Martin Fowler: UseCase – “… Alistair Cockburn’s book, which is by far the best book on use cases.”; “Use cases appear in the UML in the form of use case diagrams, but these diagrams are of little value – the key value of use cases lies in the text which is not standardized in UML. So when you do use cases put your energy into the text.”; “Use case are at their best when they are short and readable.”
- Martin Fowler: ConversationalStories – “In terms of coming up with stories, what this means is that they are always something to be refined through conversation – and that developers should play an active role in helping that definition.”; “In the end the product owner is the final decider on stories, particularly their prioritization. This reflects the fact that the product owner should be the best person to judge that slippery attribute of business value. But having a final decision maker should never stop others from participating…”
- Bill Wake: INVEST in Good Stories, and SMART Tasks – INVEST: I – Independent; N – Negotiable; V – Valuable; E – Estimable; S – Small; T – Testable; re SMART, see this alternative model Mark Murphy: Are SMART Goals Dumb?
Requirements Storytelling / Storymapping
- Storytelling That Moves People – (interview with Robert McKee) – “…most executives struggle to communicate, let alone inspire”; “McKee believes that executives can engage listeners on a whole new level if they toss their PowerPoint slides and learn to tell good stories instead”; “There are two ways to persuade people. The first is by using conventional rhetoric… The other way to persuade people—and ultimately a much more powerful way—is by uniting an idea with an emotion. The best way to do that is by telling a compelling story”; “… it demands vivid insight and storytelling skill to present an idea that packs enough emotional power to be memorable”; “Essentially, a story expresses how and why life changes”; “Stories are how we remember; we tend to forget lists and bullet points.”; “Businesspeople not only have to understand their companies’ past, but then they must project the future. And how do you imagine the future? As a story. You create scenarios in your head of possible future events to try to anticipate the life of your company…”; “as a storyteller, you want to position the problems in the foreground and then show how you’ve overcome them”; “Desire is the blood of a story”; “Self-knowledge is the root of all great storytelling. A storyteller creates all characters from the self by asking the question, “If I were this character in these circumstances, what would I do?””
- Storytelling for Product Managers – “At the center of any story is a real person — the user of the product”; “Anytime you are communicating a product vision, or a user pain point, invest deeper in the persona. Make the user come alive. What are the obstacles, challenges and or emotions the user is going through. What are the user’s goals?”
- How To Tell Stories for Marketing and SEO – “
- 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
- 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
- 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)
- 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
- Dan North: BDD Articles (by BDD pioneer and creator of JBehave)