Requirements

Tutorials

MA An Introduction to SAFe: The Scaled Agile Framework

Al Shalloway, Net Objectives

Mon, 06/08/2015 - 8:30am

The Scaled Agile Framework (SAFe) is quickly being adopted by many large organizations that have had some success with agile at the team level but have not been able to scale up to large projects. Al Shalloway describes what SAFe is, discusses when and how to implement it, and provides a few extensions to SAFe. Al begins with a high-level, executive’s guide to SAFe that you can share with your organization’s leaders. He then covers the aspects of implementing SAFe: identifying the sequence of features to work, establishing release trains, the SAFe release planning event, SAFe’s variant of Scrum, and when to use the SAFe process. Al concludes with extensions to SAFe including creating effective teams—even when it doesn’t look possible—and implementing shared services and DevOps in SAFe using kanban. Get an introduction to SAFe, discover whether it would be useful to your organization, and identify the steps you should take to be SAFe.

MD Specification by Example: Mastering Agile Testing

Nate Oster, CodeSquads, LLC

Mon, 06/08/2015 - 8:30am

On agile teams, testers can struggle to keep up with the pace of development if they continue employing a waterfall verification process―finding bugs after development. Nate Oster challenges you to question waterfall assumptions and replace a “test last” mentality with “specification by example.” Practice “test first” by writing executable specifications for a new feature before development begins. Learn to switch from tests as verification to tests as specification and guide development with concrete examples written in the language of your business. Start by joining a team for a humorous simulation of real-world issues and experience. Learn how specification by example helps build quality in instead of trying to test defects out. Progress to increasingly more realistic scenarios and practice the art of specifying intent with table-based and given-when-then formats. These paper-based simulations give you meaningful practice specifying concrete examples and will change the way you think about writing tests and collaborating as a team. This is not a tools session—no laptops required.

ME Build Product Backlogs with Test-Driven Thinking―and More SOLD OUT NEW

David Hussman, DevJam

Mon, 06/08/2015 - 8:30am

Many product backlogs of user stories are nothing more than glorified to-do lists. Teams have lost the idea of prioritizing real business value and focus instead only on finishing stories and accumulating story points. Join David Hussman as he drives a stake into the heart of lame backlogs and breathes new life into product design with pragmatic UX and test-driven thinking. Using real-world examples, David shares his experiences and teaches tools you can use to fuse centered-product thinking with end-to-end testing. These techniques include: developing test-driven user experiences, improving product discovery (backlog grooming) sessions with testing talk, adding story clarity with examples and tests, validating requirements with tests, connecting program teams by decomposing product ideas into small testable stories, and recomposing them to validate product level learning. Because we learn by doing and questioning as we go, show up ready to work. This session is for testers, developers, product owners, and anyone else interested in improving their product thinking and product backlog. Bring your failing product backlog stories for discussion, too.

MF Get the Requirements Right―the First Time

Tim Lister, Atlantic Systems Guild, Inc.

Mon, 06/08/2015 - 8:30am

One group—customers, users, and business—need a software system to help them work more efficiently or make more money, but they don’t know how to build it. Another group—software developers and testers—know how to build the system, but they don’t know what it is supposed to do. Bridging this gap is where requirements—the work products describing the system accurately and concisely while at the same time not missing important customer and user needs—are essential. To get the requirements right the first time, you need strategy, tactics, and a practical process for discovering the real requirements—which may not turn out to be what the users think they need. Tim Lister presents a strategy to get accurate and explicit requirements, tactics to efficiently develop these requirements, and a process to keep everything glued together when tackling a large, complex job. Take back an 85-page, annotated requirements specification template to help get your requirements right—the first time.

TB Great Product Design with User Story Mapping NEW

Jeff Patton, Jeff Patton & Associates

Tue, 06/09/2015 - 8:30am

A story map is a simple model, built from index cards or sticky notes, which helps the people who make it envision a customer’s experience with their product. Jeff Patton explains that within a design process story maps are a core practice focused on understanding and building empathy with customers and users, and then identifying and testing solutions to improve the customer’s experience with your product or service. The design process and story mapping can identify completely new product opportunities or improve the existing product experience. Join Jeff to learn how to map your customer’s and user’s experience today and then how to deliberately improve that experience. Use empathy maps, persona sketches, archetypes and stereotypes, story mapping, and design studio concepts to speed your design work. Since all solution ideas are speculative, learn how to validate solutions as quickly and cost-effectively as possible. In the end, discover an essential design process that allows you to identify and validate innovative product solutions.

This is a hands-on workshop. Come prepared to learn.

Concurrent Sessions

BW2 Business Analysis: From Interviews through Implementation

Barry Harvey, Florida Virtual Campus

Wed, 06/10/2015 - 11:30am

The keys to delivering better software lie in understanding what customers want―even when they are unable to articulate what they want―and being able to create a system that will improve the end users’ work. This is why your starting point should be understanding the differing, and sometime conflicting, needs of the customer and the end-users. Analyzing user needs, developing clearly defined requirements, and managing stakeholder expectations are three areas of business analysis that lead to greatly improved customer and end user satisfaction. Barry Harvey details his experience analyzing the system needs of a culturally and geographically diverse statewide academic support organization; explains how to translate those needs into detailed requirements; and most importantly, shares proven strategies for managing stakeholder expectations throughout the development and implementation process. Transparency and traceability allow both customers and users to understand how specific features and functionality came to be included in the final system, and how their particular needs are being addressed.

BW6 Requirements and Acceptance Tests: Yes, They Go Together

Ken Pugh, Net Objectives

Wed, 06/10/2015 - 1:30pm

The practice of software development requires a clear understanding of business needs. Misunderstanding requirements causes waste, slipped schedules, and mistrust. Developers implement their perceived interpretation of requirements; testers test against their perceptions. Disagreement can arise about implementation defects, when the cause is really a disagreement about a requirement. Ken Pugh shows how early acceptance test development decreases requirements misunderstandings by both developers and testers. A testable requirement provides a single source that serves as the analysis document, acceptance criteria, regression test suite, and progress tracker for each feature. Explore how the business, testers, and developers can create, evaluate, and use testable requirements. Join Ken to examine how to transform requirements into stories, which are small units of work that have business value, small implementation effort, and easy-to-understand acceptance tests. Learn how testers and requirement elicitors can work together to create acceptance tests prior to implementation.

BW10 Requirements Are Simply Requirements—or Maybe Not

Robin Goldsmith, Go Pro Management, Inc.

Wed, 06/10/2015 - 2:45pm

People talk about requirements, use identical terms, and think they have a common understanding. Yet, one says user stories are requirements; another claims user stories must be combined with requirements; and another has a still different approach. These “experts” seem unaware of the critical inconsistencies of their positions. No wonder getting requirements right remains a major challenge for many projects. Robin Goldsmith analyzes often conflicting, not-so-shared-as-presumed interpretations of what requirements are, reveals likely implications, and challenges not-so-wise conventional wisdom. Robin describes a more appropriate model of REAL business requirements—whats that provide value when combined with product/system/software hows. He introduces the powerful Problem Pyramid™ systematic disciplined guide to help you more reliably get requirements right. The structure makes it easier to see where user stories do or do not fit, identifies pitfalls of the “as a <role>” format, and reconciles some of the conflicts between user stories, features, use cases, and requirements.

BW14 EARS: The Easy Approach to Requirements Syntax

John Terzakis, Intel

Wed, 06/10/2015 - 4:15pm

One key to specifying effective functional requirements is minimizing misinterpretation and ambiguity. By employing a consistent syntax in your requirements, you can improve readability and help ensure that everyone on the team understands exactly what to develop. John Terzakis provides examples of typical requirements and explains how to improve them using the Easy Approach to Requirements Syntax (EARS). EARS provides a simple yet powerful method of capturing the nuances of functional requirements. John explains that you need to identify two distinct types of requirements. Ubiquitous requirements state a fundamental property of the software that always occurs; non-ubiquitous requirements depend on the occurrence of an event, error condition, state, or option. Learn and practice identifying the correct requirements type and restating those requirements with the corresponding syntax. Join John to find out what’s wrong with the requirements statement—The software shall warn of low battery—and how to fix it.