requirements

Conference Presentations

STARWEST 2008: Branch Out Using Classification Trees

Classification trees are a structured, visual approach to identify and categorize equivalence class partitions for test objects. They enable testers to create better test cases faster. Classification trees visually document test requirements to make them easy to create and comprehend. Julie Gardiner explains this powerful technique and how it helps all stakeholders understand exactly what is involved in testing and offers an easier way to validate test designs. Using examples, Julie shows you how to create classification trees, how to construct test cases from them, and how they complement other testing techniques in every stage of testing. Julie demonstrates a free classification tree editing tool that helps you build, maintain, display, and use classification trees.

Julie Gardiner, Grove Consultants
Who Are Your Project Stakeholders?

It's easy to list all the stakeholders and identify different types of users for your software project-WRONG! Although it may be obvious who holds the checkbook for your project and who the "average" users will be, many other people and user roles are not so obvious. Unaccounted for stakeholders and users result in missed requirements and often leave important conflicts unresolved. Even worse, you can lose support-and the whole project can fail-if important people are left out of the process. As Linda Westfall demonstrates unique "brain writing" techniques in a facilitated, interactive requirements workshop, you will learn ways to identify a complete list of the important project stakeholders and user roles. After pruning the stakeholder list to eliminate duplicates, Linda demonstrates how to define a requirements elicitation strategy to select appropriate techniques for each stakeholder.

Linda Westfall, The Westfall Team
Answer the Call: Help Product Owners Define and Prioritze Requirements

Numerous software development methodologies are available to provide project teams excellent guidance on how to build systems right. But how do we know that we are building the right systems? We often ask product owners to define and prioritize their requirements-without offering them a great deal of guidance on how to do so. Understanding what the software needs to do and the value that it will add to the organization will help them decide the importance of each requirement. Kent McDonald explains how you can employ a value model based on the project's purpose, costs, benefits, considerations, and its relation to the organization's overall strategies to help product owners define and quantify the value delivered by a project. He will also show how you can use a regular reevaluation of this value model to decide what requirements should be completed and in what order.

Kent McDonald, Knowledge Bridge Partners
Beyond User Stories: Managing Requirements by Business Need

The use of stories in agile projects is commonplace. However, teams in many organizations have discovered limitations in the user story's narrow view in complex projects. Attempts to coordinate related stories through "epics" and "themes" may help the details of managing the problem but generally leave the enterprise view unaddressed-particularly when multiple teams are working together. From his experiences on large agile projects, Alan Shalloway found that combining small pieces together to get a bigger view does not work as well as starting with the bigger view and segmenting it. With agile methods, you must go beyond stories and start with what is known as the "Minimally Releasable Feature" (MRF). The MRF creates the bigger picture of what constitutes business value and enables the management of small stories within this bigger picture.

Alan Shalloway, Net Objectives
Practical Software Sizing with Testable Requirements

A new strategic project is in the design stages-how much will it cost? Your application requirements are constantly growing-what is the impact? System testing is scheduled soon-how much time and what resources will we need? And how do you get the answers? Measurement. Although software developers are often collecting measures of defects, earned value, variances, etc., the most fundamental measure-how big is the system?-is usually lacking. Lines of code and function points are established sizing measures but both have limitations that have prevented their widespread acceptance. Karen Johns presents testable requirements, an alternative sizing measure that can help you meet these challenges and more. Learn from Karen what testable requirements are and how to use them to size your software systems.

Karen Johns, Mosaic, Inc.
A Tester's Role in Agile Projects

Some agile methodologists claim that testers are not needed in agile projects--all testing is done either by developers or users. Chris Hetzler has seen the effects of that approach, and they are not pretty. When customers find
bugs in large projects, the costs can be staggering. Chris believes that testers must be involved in agile projects at an even higher intensity since timelines are shorter and the risk of failure is higher. But Chris explains that testers' roles change and testers must be prepared for that change. In agile projects, the testers' role is one of quality engineer rather than the traditional product

Chris Hetzler, Microsoft
A Metrics Dashboard to Drive Goal Achievement

Some measurement programs with high aims fall short, languish, and eventually fail completely because few people regularly use the resulting metrics. Based on Cisco Systems' five years of experience in establishing an annual quality program employing a metrics dashboard, Wenje Lai describes their successes and challenges and demonstrates the dashboard in use today. He shows how the metrics dashboard offers an easy-to-access mechanism for individuals and organizations within Cisco Systems to understand the gap between the current standing and their goals. A mechanism within the dashboard allows users to drilldown and see the data making up measurement to identify ownership of issues, root causes, and possible solutions. Learn what programs they implemented to ensure that people use the metrics dashboard to help them in their day-to-day operations.

  • How to build an effective metrics dashboard to help achieve quality goals
Wenje Lai, Cisco Systems Inc
Why Are Requirements So Poorly Defined?

Studies have shown that the quality of the requirements is one of the most important factors in the quality of an application and also in the time and costs required to deliver a system. Yet requirements are almost always ambiguous, incorrect, incomplete, too high level, logically inconsistent, and communicated by rumor. The irony is that the various techniques-which have been around for decades-for writing better requirements have not been widely adopted. The culture and the management of the software process are equally to blame. Richard Bender gets to the root of the problem and discusses ways to address the poor requirements issues. Learn quantitative measures of the quality of the requirements specification and practical approaches to writing unambiguous requirements for your applications.

  • Early validation of requirements through testing
  • Moving user acceptance test design up prior to the start of coding
Richard Bender, Bender RBT Inc.
User Stories for Better Software Requirements

The technique of expressing requirements as user stories is one of the most broadly applicable techniques introduced by Extreme Programming. In fact, user stories are an effective approach on all time-constrained projects, not just those using Agile methods. Mike Cohn explains how to identify the functionality for a user story and how to write it well. He describes the attributes all good user stories must exhibit and presents guidelines for writing them. Learn to employ user role modeling when gathering a project’s initial stories. Whether you are a developer, tester, manager, or analyst, you can learn to write user stories that will speed up development and help you deliver the systems that users really need.

  • Defining a user story and learning how to write one
  • Six attributes of all user stories
  • Thirteen guidelines for writing better user stories
Mike Cohn, Mountain Goat Software
Building a Requirements Foundation with Customer Interviews

Whether you are building a brand new product or evolving an existing system, understanding the business needs of your customers is the foundation of a marketable product or valuable internal application. Few of us are experts in interviewing techniques, and few customers talk about their tasks, needs, and context in neat, concise statements about requirements. Hone your elicitation skills and learn what it takes to get beneath the surface and understand your customers: their world, how they work, and what really bothers them. With effective interviewing techniques and skills, you will get inside their heads and better understand their needs within their context.

Esther Derby, Esther Derby Associates Inc

Pages

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.