Reading List: Requirements / Business Rules / BDD

Agile / BDD Requirements
Use Cases, User Stories, Use Case Scenarios
Requirements Storytelling / Storymapping
Requirements and Business Rules
Cucumber / Gherkin
General
Lists

Agile / BDD Requirements

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 – “In meeting the needs of consumers, you must hear their stories and learn from them to empathize. You must then promote a brand story to your audience, so they can imagine themselves with your product or service”; “… studies show that most people remember information far better when it’s conveyed in a narrative rather than as a list”
  • 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

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

Lists

Leave a comment