Consistent, accurate, and unambiguous requirements are critical to the success of any software development project. Clearly understanding the needs and vision of your customer, the guidelines to follow, and a true understanding of the scope of a project will help ensure the application is delivered on time and on budget.

W13	Wednesday, September 29, 2004, 11:30 AM

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
• The Unified Modeling Language (UML) in the requirements process
• Maintainable, traceable requirements without a management tool.

W14	Wednesday, September 29, 2004, 1:45 PM

Use cases are a wonderfully simple concept: document a system’s functional requirements by writing down scenarios about how using it delivers value to its actors. However, writing effective use cases is more difficult than expected because you frequently must deal with difficult questions, such as: scope, level of detail needed for different people and projects, how to describe external interfaces, stored data, and more. You need a source of objective criteria to judge use case quality and effectiveness. Fill this critical information gap with a pattern language that provides simple, elegant, and proven solutions to common problems in use case development. Take away these use case patterns and profit from the knowledge and experience of other successful use case writers. And develop a new vocabulary for describing the properties of quality use cases.

• The ''signs of quality'' and properties of a good use case
• Patterns to diagnose common use case problems
• A vocabulary for describing effective use cases

W15	Wednesday, September 29, 2004, 3:00 PM

Defining requirements is a process of discovery, beginning with identifying the problem to be solved and establishing the scope of a solution. In this session Paul Desantis takes you through the important aspects of requirements discovery, including sampling documentation, research, observation, questionnaires, interviews, prototyping, and joint planning. Learn when and how to develop and use certain deliverable components in your requirements process: matrix of problem issues, opportunities, objectives and constraints, the PIECES framework (Performance, Information, Economics, Control, Efficiency, Service) for problem identification, cause and effect diagrams, problem and solution definitions, use case glossary, diagrams, and narratives. You will take away a framework for understanding ways to analyze needs and develop a suitable software solution.

• A requirements analysis framework for most lifecycle approaches
• Techniques for discovering requirements
• Deliverable components for software requirements

T17	Thursday, September 30, 2004, 10:15 AM

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

T18	Thursday, September 30, 2004, 11:30 AM

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
• Test cases force design and documentation decisions

T19	Thursday, September 30, 2004, 1:30 PM

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

T20	Thursday, September 30, 2004, 3:00 PM

Many companies have implemented quality programs such as CMM®, TQM, Six Sigma, etc., to improve requirements and software development. However, these initiatives often focus on building the software right — meeting quality expectations and specifications — but do not necessarily focus on building the right software — the right functionality at the right time and at the right cost from the customer’s perspective. Unmesh Gundewar explains how EMC employed the Goal, Question, Metric (GQM) methodology to identify key measurements that ensure the “right software” is being developed. Learn how EMC applies the Six Sigma approach to drive these measurements into the organization and the resulting software. Move beyond the processes designed to get functional requirements and specifications right as Unmesh shares experiences, the challenges faced, and lessons learned from building the right software.

• Goal, Question, Metrics approach for defining the right software to build
• The right balance of functionality, cost, and time to deliver
• Six Sigma for software development

Software Quality Engineering Home       Conference Home       To Exhibit       Get a Brochure       Register for Better Software Conference & EXPO 2004

feedback  © 2004