|
In Other Words: How Paraphrasing Helps Uncover Defects Take one phrase, throw in three different interpretations, and add zero communication: It all adds up to one big defect. Find out how paraphrasing can help you to uncover hidden problems.
|
|
|
An Elephant in the Room We make software so that people can use it. Yet these users are so hard to define that they are often simply ignored. This six-step approach to Interaction Design can help you bring your customers down to size so that you can provide the right product for them.
|
|
|
You Don't Say You've just developed and tested a system that meets each of the customer’s stated requirements. So why aren't they satisfied? Lisa Crispin shares her 5-step process for uncovering hidden assumptions and requirements so that everyone can have the happy ending they expected.
|
|
|
Common Requirements Traps - And How to Avoid Them This article details common requirements traps that teams fall into. Tips to help your team avoid these traps are also included.
|
Karl Wiegers, Process Impact
|
|
The Reality of XP: A Real World Case Study This article explains what XP Programming is and how implementing it can benefit your team.
|
Drake Kirkham, Cirrus Systems Corporation
|
|
Testing is About Requirements Specification - An Agile View This article details how to manage your XP Programming project.
|
Robert Martin, Object Mentor
|
|
Judging Use Case Quality Great test procedures cannot compensate for poor requirements. Good use cases are hard to write. This article details how to develop an effective use case for your project team.
|
Steve Adolph, WSA Consulting Inc.
|
|
Use Cases for Maximizing Project Success This article will teach you to: understand how use cases can be used on non-oo projects, employ solid techniques to develop "good" use cases, leverage use cases to increase user accountability for requirements completeness, and how to apply measurement benefits to use case deployment.
|
Carol Dekkers, Quality Plus Technologies Inc
|
|
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.
|
|
Testing and Implicit Requirements: Expanding the Unwritten Specification Testers should be encouraged to test against and report deviations from implicit specifications. There is a Universal Implicit Specification that is based on
fundamental principles. These principles are: the system will not lie, the system will impose no gratuitous keyholes or other constraints, and the system won’t do anything that’s just plain stupid.It’s worthwhile to identify, elaborate, and make explicit the fundamental principles and
common manifestations of deviations from these principles.
|
Scott Meyers, Aristeia.com
|