requirements

Articles

Agile Testing as if People Mattered

As a test professional in waterfall, I was used to getting the code much later and buggier than I expected and being under tremendous pressure to finish my testing before the go-live date hit. Then one day, I found out that there was a better way. Testers could be involved much earlier in the lifecycle, they could participate in requirements and design decisions as they happened, and the code could actually be unit tested before I received it! Heaven? Nope, agile.

Daryl  Kulak's picture Daryl Kulak
Two Cheers for Ambiguity

Some people dismiss words such as skill, diversity, problems, and mission as being too ambiguous to be useful. But one tester's ambiguity is another tester's gauge for assessing consensus on a project and how to achieve that consensus.

Michael Bolton's picture Michael Bolton
A Story About User Stories and Test-Driven Development: Into the Field

Drawing on real events from the authors' combined experience, this story picks up where it left off in the November 2007 issue and follows a fictional team as it encounters some of the pitfalls of using test-driven development.

Gertrud Bjørnvig Neil Harrison
A Story About User Stories and Test-Driven Development: The Setup

While "testing" is part of its name, many TDD pundits insist TDD is not a testing technique, but rather a technique that helps to focus one's design thinking. Drawing on real events from the authors' combined experience, this story follows a fictional team as it encounters some of the pitfalls of using test-driven development.

The Forgotten Side of Quality

Our perception of quality includes objective and subjective factors. In this week's column, Jeff Patton explains the difference between the two and proposes we forget those differences so we can start viewing the two as equals.

Jeff Patton's picture Jeff Patton
Practical Software Sizing with Testable Requirements

A new strategic project is in the design stages-how much will it cost? Your application requirements are constantly growing-what is the impact? System testing is scheduled soon-how much time and what resources will we need? And how do you get the answers? Measurement. Although software developers are often collecting measures of defects, earned value, variances, etc., the most fundamental measure-how big is the system?-is usually lacking. Lines of code and function points are established sizing measures but both have limitations that have prevented their widespread acceptance. Karen Johns presents testable requirements, an alternative sizing measure that can help you meet these challenges and more. Learn from Karen what testable requirements are and how to use them to size your software systems.

Karen Johns, Mosaic, Inc.
Prioritization Puzzles: Practices for Prioritizing Product Requirements

Not all requirements are created equal, so to make smart choices about which product requirements you should explore and implement-or whether you should delve into them at all-you need to prioritize them. Many teams do not prioritize properly and waste time specifying requirements that are never delivered. Why spend time and energy on requirements you won't use? In this week's column, Ellen Gottesdiener answers the question by detailing how and when requirements should be dealt with.

Ellen Gottesdiener's picture Ellen Gottesdiener
The Whorfian Hypothesis

Benjamin Whorf hypothesized that the language we speak constrains the thoughts we can have. Learn how a well-developed organizational vocabulary can help increase the quality of your products.

Lee Copeland's picture Lee Copeland
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
Know What's at Stake

Everyone knows the importance of well-defined functional requirements. We want our products to work, don't we? But how many of us are paying as much attention to defining our non-functional requirements? In this historically focused feature, we learn from past mistakes the potentially disastrous results of inadequately tested NFRs.

Pages

StickyMinds is a TechWell community.

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