Requirements

Tutorials

MB Software Requirements Fundamentals for BAs, Testers, and Developers NEW

Lee Copeland, Software Quality Engineering

Mon, 11/10/2014 - 8:30am

You deal with software requirements all the time. Whether you are a developer in an agile environment, an analyst who identifies and documents requirements for plan-driven development, a software designer who studies requirements as the basis for agile development, a tester who employs or often must discover requirements as the foundation of test cases, or a technical user who describes your needs to development, you need the right approaches and skills to develop and interpret software requirements.

MD Specification by Example: Mastering Agile Testing

Nate Oster, CodeSquads, LLC

Mon, 11/10/2014 - 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.

ME Build Product Backlogs with Test-Driven Thinking—and More NEW

David Hussman, DevJam

Mon, 11/10/2014 - 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, instead, focus 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 test-driven thinking that is meaningful to testers, developers, product owners, and others. Using real-world examples, David shares his experiences and teaches tools you can use to fuse centered-product thinking with end-to-end testing.

MM The Role of the Agile Business Analyst

Steve Adolph, Blue Agility

Mon, 11/10/2014 - 1:00pm

The business analyst (BA) role seems conspicuously absent from most agile methods. Does agile make the BA role obsolete? Certainly not! But how does a BA exploit the short cycle times and collaborative nature of agile methods? Drawing from the principles of lean product development flow, Steve Adolph introduces five principles for the agile BA—Open the Channels, Chart the Flow, Generate Flow, Lean Out the Flow, and Bridge the Flow. As a communicator, the BA must Open the Channels and Chart the Flow to align all stakeholders.

TH Agile Project Failures: Root Causes and Corrective Actions

Jeff Payne, Coveros, Inc.

Tue, 11/11/2014 - 8:30am

Agile initiatives always begin with the best of intentions—accelerate delivery, better meet customer needs, or improve software quality. Unfortunately, some agile projects do not deliver on these expectations. If you want help to ensure the success of your agile project or get an agile project back on track, this session is for you. Jeff Payne discusses the most common causes of agile project failure and how you can avoid these issues—or mitigate their damaging effects.

TL Get the Requirements Right―the First Time NEW

Tim Lister, Atlantic Systems Guild, Inc.

Tue, 11/11/2014 - 1:00pm

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.

TQ Product Owner Imperatives for Championing Agile Projects NEW

Paul Reed, EBG Consulting

Tue, 11/11/2014 - 1:00pm

Engaged and passionate product owners balance strategic and tactical activities to ensure that the right product is built—and built right. Yet how do these product owners guide planning toward longer-term goals while also ensuring that requirements are sufficiently understood for development and delivery? Join Paul Reed as he shares techniques for setting context and collaboratively establishing a shared understanding of requirements. Discover methods to envision the product and identify the stakeholders and their value considerations.

TS Specifying Non-Functional Requirements NEW

John Terzakis, Intel

Tue, 11/11/2014 - 1:00pm

Non-functional requirements present unique challenges for authors, reviewers, and testers. Non-functional requirements often begin as vague concepts such as “the software must be easy to install” or “the software must be intuitive and respond quickly.” As written, these requirements are not testable. Definitions of easy, intuitive, and quickly are open to interpretation and dependent on the reader’s experiences. In order to be testable, non-functional requirements must be quantifiable and measurable.

Concurrent Sessions

BW2 Requirements Are Requirements—or Maybe Not

Robin Goldsmith, Go Pro Management, Inc.

Wed, 11/12/2014 - 11:30am

Many people talk about requirements. They 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 yet another has a 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.

BW6 EARS: The Easy Approach to Requirements Syntax

John Terzakis, Intel

Wed, 11/12/2014 - 1:30pm

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.

BW10 Non-Functional Requirements: Forgotten, Neglected, and Misunderstood

Paul Reed, EBG Consulting

Wed, 11/12/2014 - 2:45pm

Implementing non-functional requirements is essential to build the right product. Yet teams often struggle with when and how to discover, specify, and test these requirements. Many teams neglect non-functional requirements up front, considering them less important or unrelated to user requirements; other teams specify them incompletely or with untestable and non-measurable attributes.

BW14 Big Data Business Analytics: Get Ready for Tomorrow’s Projects

Candase Hokanson, Seilevel

Wed, 11/12/2014 - 4:15pm

Normal people don't look at data sets just for fun; they analyze them to make business decisions. More and more often, business analysts and product managers find themselves on strategic projects that require turning large—and often highly complex—data sets into meaningful information from which conclusive decisions and actions can be derived. In most IT organizations today, analysis of big data is a reality and will grow in significance as businesses look to better understand capturing, structuring, and learning from their data.