|
|
A Defined Process for Requirements Peer Reviews Most software projects include reviews-whether or not they are officially part of the development process. Unfortunately, these reviews are often inefficient, and even unproductive. Implementing a defined peer review process for requirements is an excellent means to both improve your requirements and kick-start overall process improvement because participants can immediately see timesaving and increased quality in work products. Find out how to measure benefits and potential savings from these reviews and how they can identify major gaps in other project processes. Take away a Peer Review Toolkit that allows your team members to start their first effective requirements review right away.
- A simple, efficient peer review process with a 30-minute training program
- Instant results and metrics, including potential savings
- A Peer Review Toolkit to get started.
|
Rob Wyatt, Wachovia
|
|
|
Refining Requirements with Test Cases Requirements are supposed to be the basis of most test cases, but can you use test cases to define what the system needs to do--to improve or to actually become the requirements? To some degree, your development process dictates the opportunities you have for test cases to define or refine requirements. However, everyone can benefit from test case writing techniques to identify missing requirements, surface ambiguous statements, and expose implied requirements early in the process. Find out how Tanya Martin-McClellan produces test cases that accurately reflect the requirements, as they are understood at the time, and conducts team reviews to find the gaps and misunderstandings. Although more time is spent writing and rewriting test cases, less time is spent later discussing requirements.
- Find the vaguely defined parts of the requirement definition
- A template of implied requirements you can customize
|
Tanya Martin-McClellan, Texas Mutual Insurance Company
|
|
|
Expressing Requrirements as Users Stories - an Agile Approach Expressing requirements as user stories is one of the most broadly applicable techniques introduced by eXtreme Programming and adopted by other agile development processes. User stories are an effective approach for capturing requirements from an agile project, not just those using XP. In this session learn what user stories are, how they differ from other requirements approaches, and why you should consider using them. You also will learn the six attributes all good stories must exhibit and see how to get started with user stories. Whether you are a developer, requirements analyst, tester, manager, or even a customer interested in applying agile techniques to your projects, this session is for you.
- The differences between user stories and other requirements documentation
- Attributes of "good" user stories
- Examples of User Stories from agile development projects
|
Mike Cohn, Mountain Goat Software
|
|
|
RequireMINTS - Fresh Approach to Analyzing Requirements Studies show that most application defects are introduced before a single line of code is developed-with many (if not most) of these defects attributed to poor requirements. Studies also show that it is less costly to identify and correct these defects prior to code development. Despite this data, many of us have requirements analysis approaches that have become stale and are ineffective. Many analysts acknowledge that their processes need some improvement but feel helpless to do much about the problem. Dion Johnson offers a package of small yet effective "RequireMINTs" that will freshen up those stale requirements processes in a highly practical way. You will take away a road map for collecting metrics that make a case for requirements improvements, identifying necessary improvements, and implementing these improvements.
- Reverse the reverse-engineering trend with better requirements
|
Dion Johnson, DiJiMax Consulting, Inc.
|
|
|
Assuring Testable Requirements One strategy for assuring testable software is to assure testable requirements, i.e., requirements that are clearly and precisely specified and cost-effectively checkable. David Gelperin describes two specification techniques, action contracts and Planguage quality specs, which both support testable requirements. Functionality can be precisely defined with pre- and post-conditions using action contracts. The measurement of non-functional characteristics can be precisely specified with Planguage specs. The techniques will be illustrated with examples and short exercises.
- An application information architecture that assures testability
- How to specify functions with action contracts
- How to specify measures for nonfunctional characteristics
|
David Gelperin, LiveSpecs Software
|
|
|
Gathering Requirements in a Low-Process Environment Knowing the requirements for a system means understanding the problem to be solved. If the problem isn't understood, the solution can't address it. Not taking time for requirements discovery at the beginning will cost far more time and money in the end. This paper explains requirements gathering techniques.
|
Elisabeth Hendrickson, Quality Tree Software, Inc.
|
|
|
Software Inspection: Taking a Step Forward to Completion n
|
Neela Majumder, Intel Corporation
|
|
|
Achieving Software Quality Through Test Automation Process Integration With increasing demands for high-quality software applications in shorter development cycles, it's clear that teams need to go beyond simply running tests at the end of their development cycle. Instead, teams must approach development with quality as their primary objective. Brian Bryson shows you how to integrate automated testing tools with best practices to implement an effective quality assurance process from the beginning (and throughout) the development lifecycle.
|
Brian Bryson, Rational Software Corporation
|
|
|
Requirements Workshops: What, Why, and How There's no standard formula for requirements workshops. Each project, business situation, and group of people will combine to make each workshop unique. Preparing for the requirements workshop requires collaboration. It permits you to tap into the collective wisdom of all of the
project stakeholders. In your workshops, participants are active, engaged, committed and task oriented. A well-run workshop builds trust and mutual understand among all the participants. Workshops are not new, but are proven best practices in software development. They can go a
long way not only in product delivery, but also in building a "jelled" team.
|
Ellen Gottesdiener, EBG Consulting, Inc.
|
|
|
Requirements Are Requirements Are Requirements - Not! "This isn't what I need," states Customer Bob. "But it's what you said you wanted," replies Engineer Joe. "It's not right. I need something else." We've all encountered this classic users-don't-know-what-they-want scenario. The fact that software professionals continue to have this same experience over and over again suggests that we're overlooking the real reasons for the user/engineer disconnect. This presentation contrasts the different uses of the term "requirements" as it explores the possible solutions to improving understanding between business people and technical people.
|
Robin Goldsmith, GoPro Management, Inc.
|
