requirements

Articles

The Satir Interaction Model Why Not Ask Why? Get Help From the Satir Interaction Model

Having trouble with responses to why questions? Get help from the Satir Interaction Model and learn when to use data-oriented questions.

Don Gray's picture Don Gray
working together Harvesting Stakeholder Perspectives to Organize Your Backlog

When Mary Gorman and Ellen Gottesdiener facilitated a game called The Backlog Is in the Eye of the Beholder for the Boston chapter of the International Institute of Business Analysis, both the players and the facilitators learned some important lessons in organizing a project requirements backlog. In this article, they describe the game and what it revealed, including the value of truly knowing your stakeholders.

Building Team Trust, Front to Back

Trust is more than a feeling. In a project, it is something that can be grown from careful planning and development of good requirements. Ellen Gottesdiener describes three types of trust which can be built from good requirements and team management.

Ellen Gottesdiener's picture Ellen Gottesdiener
Acceptance Test-Driven Development: Not as Optional as You Think

The components of software processes work together in important and sometimes unrecognized ways. The removal of one of those components will affect the others. In this article, which originally appeared in the August 2010 issue of the Iterations eNewsletter, Jennitta Andrea takes a look at the value of acceptance test-driven development and the costs of making it an optional practice.

Jennitta Andrea's picture Jennitta Andrea
9 Questions You Must Ask When Selecting the Right Tool and Vendor

The key to selecting the best vendor and tool is asking the right questions. The answers to these nine essential questions can mean the difference between satisfaction with your purchase and a giant waste of time and money.

Joe Townsend's picture Joe Townsend
How Agile Practices Reduce Requirements Risks

Requirements risks are among the most insidious risks threatening software projects. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry. As requirements expert and agile coach Ellen Gottesdiener explains, agile practice can go a long way in mitigating those risks.

Ellen Gottesdiener's picture Ellen Gottesdiener
A Second Look at "Requirements Come Second"

My article, "Requirements Come Second," in a recent issue of Agile Journal caused something of a fuss. The piece was picked up by several more sites and was widely commented on - both on websites and in my inbox. I'm not entirely surprised by this reaction, I've been discussing this research for a year or so now and often find it surprises people. Given this level of interest it is worth looking at how people responded. It is also worth restating the key message: Requirements are an essential part of maximizing business value, but when an organization is struggling with effectiveness it is best to start change by improving delivery.

Allan Kelly's picture Allan Kelly
An Agile Approach to Scheduling

When we schedule too many variables, things start to slip and soon the schedule is out the window. Paying attention to your project's constraints can help you set realistic scheduling goals that you will actually be able to stick to.

Carlos Sirias
Transitioning from Analysis to Design

The step between specifying requirements to working on a system design can be tricky. Fortunately, the basis on which the step is made can be calculated. Paul Reed thoroughly explains how the transition should progress and offers some instructions on how to move properly through this phase.

Paul R. Reed, Jr.'s picture Paul R. Reed, Jr.
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

Pages

StickyMinds is a TechWell community.

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