|
Requirements Are Simply Requirements—or Maybe Not
Slideshow
When talking about requirements, people use identical terms and think they have a common understanding. Yet, one says user stories are requirements; another claims user stories must be combined with requirements; and yet another has a different approach. These “experts” seem unaware of...
|
Robin Goldsmith, Go Pro Management, Inc.
|
|
Working with Nonfunctional Requirements Nonfunctional requirements describe aspects of the system that do not map onto a single piece of functionality. Essentially, they're constraints you need to operate within. Allan Kelly details how running performance tests regularly can be the key to nonfunctional requirements, as well as how much value these constraints produce.
|
|
|
Acceptance Criteria, Specifications, and Tests One of the benefits of agile is how it helps specify requirements. Instead of trying to predict the future with your requests, you can wait an iteration and see if more criteria are needed. This article gets into how executable specifications, specification by example, and test automation can help further improve your requirements management.
|
|
|
Defining Acceptance Criteria for Agile Requirements Acceptance criteria can be helpful in expanding on user stories in order to capture requirements for agile projects. However, acceptance criteria should not be a route back to long, detailed documents, and they are not a substitute for a conversation. This article tells you how and when acceptance criteria should be written and employed.
|
|
|
Product Owner, Product Manager, or Project Owner? If you really want to get the benefit of Scrum, you have to make the mind shift to product ownership, not project management or project ownership. The product owner role is often thought of as being a requirements specifier, when in fact a good product owner is a value maximizer, and a great product owner is a product maximizer.
|
|
|
Stories, Epics, and Tasks: Organizing Agile Requirements Some teams only work with stories, but it can be difficult for a team new to agile to write stories that are easy to understand and provide value every time. An alternative is to add epics and tasks. Understanding the differences between each level and knowing what size story to use for each situation will improve the accuracy of your sprint planning.
|
|
|
Know Your Customers: They Can Help You Write Better User Stories Too many user stories begin, "As a user …" Who is your user? Or, more accurately, who are they? Improving your understanding of the types of customers who use your software lets you see multiple products where previously, there was only one—and identifying dedicated products will help you prioritize and accelerate delivery.
|
|
|
User Story Heuristics: Understanding Agile Requirements Agile emphasizes just-in-time requirements rather than upfront preparation. The requirements person—be it the product owner, business analyst, product manager, or someone else—embodies the understanding of what is needed, and the user story represents the work that needs doing. This article details what user stories are (and what they are not).
|
|
|
Requirements Are Simply Requirements—or Maybe Not
Slideshow
People talk about requirements, use identical terms, and think they have a common understanding. Yet, one says user stories are requirements; another claims user stories must be combined with requirements; and another has a still different approach. These “experts” seem unaware of the...
|
Robin Goldsmith, Go Pro Management, Inc.
|
|
Agile Dev, Better Software & DevOps Conference West 2015: EARS: The Easy Approach to Requirements Syntax
Slideshow
One key to specifying effective functional requirements is minimizing misinterpretation and ambiguity. By employing a consistent syntax in your requirements, you can improve readability and help ensure that everyone on the team understands exactly what to develop. John Terzakis provides...
|
John Terzakis, Intel
|