requirements

Articles

Agile Requirements Management with Keith Johnson

Keith Johnson is vice president of product development at Jama Software. in this Sticky ToolLook interview, he discusses some of the changes that agile development has brought to the requirements management process.

TechWell Staff's picture TechWell Staff
Tester, Know Your Product

Should you diligently produce multiple big documents before testing begins? Consultant Fiona Charles argues that you should do that only if you believe that documentation is your product as a tester. If your product is information, you should instead minimize test documentation and engage with the software to build the product your stakeholders are paying for.

Fiona Charles's picture Fiona Charles
Four Agile Tips to Eliminate Rework in Application Development

Your applications need to meet business needs, overcome complex processes, and provide instant results to customers. And, ideally, they’ll require minimal rework on your part. The first step to success is requirements definition. Here, Filip Szymanski offers some tips from agile methods that will improve your requirements—even if you haven’t otherwise adopted agile.

Filip Szymanski's picture Filip Szymanski
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
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
Requirements Come Second: A Second Look

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 an 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 maximising 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's picture 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.

Pages

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!