use cases

Articles

Designing Scenarios for Agile Stories Designing Scenarios for Agile Stories

The needs to improve the time to market of a quality product and adapt to a changing business environment are driving organizations to adopt agile practices in order to be competitive in the marketplace. However, a project team is bound to face difficulties if it is not trained on the fundamentals of agile. Read on to learn how to design scenarios for agile stories using a structured framework.

Sharath Bhat's picture Sharath Bhat
Moving Beyond Basic Load Testing True Performance: Moving Beyond Basic Load Testing

Basic load testing is valuable, but it's important to move past simplistic efforts. Here are some ways to gain more accurate metrics from your load tests.

Jim Holmes
Helping the Customer Stick to the Purpose of a User Story

Lisa Crispin writes that you need to understand the purpose of a user story or feature. Start with the "why." You can worry later about the "how." The customers get to decide on the business value to be delivered. They generally aren't qualified to dictate the technical implementation of that functionality. It's up to the technical team to decide the best way to deliver the desired feature through the software.

Lisa Crispin's picture Lisa Crispin
When Requirements Collide

Could it be that not every set of business requirements has the customer's best interest in mind? Karl Wiegers had always believed that implemented software functionality should enable users to accomplish their goals and help the business achieve its objectives. But a recent experience with a less-than-helpful parking meter system suggested to him that conflicts sometimes might exist between business and user requirements.

Karl E. Wiegers
swing hanging from tree Finish on Time by Managing Scale

When deciding how a user's task is to be supported in our software, we often look at possible design solutions and select one that's best for the product and the user. As the project deadline approaches, however, we might choose to dismiss some features outright. In this column, Jeff Patton suggests we try keeping more features by adjusting their scale.

Jeff Patton's picture Jeff Patton
What Is a Customer?

When we communicate, the words sound familiar so we think we understand each other. But understanding fizzles when we attribute different meanings to the words we use. In this column, Naomi Karten illustrates how differences in the way departments and companies define their terms can cause confusion, flawed conclusions, and faulty decisions. Naomi asks us to question the meanings of terms before starting a project to ensure that we understand what's called for.

Naomi Karten's picture Naomi Karten
Taking the Mystery out of Requirements

Ambiguity, false assumptions, theories, and red herrings. These basic elements of a good mystery story are also encountered in software requirements gathering. And just as the detective has his bag of tricks for solving the mystery, you can learn a few things about uncovering elusive requirements in this column from Becky Winant.

Becky Winant
UML notation for sequence diagrams Sequence Diagrams

This is the second in a series of articles written to a) introduce you to the most important diagrams used in object-oriented development (use case diagrams, sequence diagrams, class diagrams, and state-transition diagrams); b) describe the UML notation used for these diagrams; and c) give you as a tester a set of practical questions you can ask to evaluate the quality of these object-oriented diagrams.

Lee Copeland's picture Lee Copeland
Use Case Completion Worksheet (template)

This use case template will help you keep track of changes and the disposition of use cases during a requirements workshop.

Ellen Gottesdiener's picture Ellen Gottesdiener

StickyMinds is a TechWell community.

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