requirements gathering

Articles

It’s Time for Requirements Craftsmanship It’s Time for Requirements Craftsmanship

Holly Bielawa explains that being a a requirements craftsman means that you need to test your assumptions in real time while developing a product. Then you pivot as needed, change your business model as you learn, and constantly get out of the building and gather data to determine your minimally marketable product.
Holly Bielawa's picture Holly Bielawa
March 4, 2014
SDLC phases and activities Requirements Engineering: Our Best Practices

This article focuses on a methodology adopted during a requirements and functional specification phase of a project. The chosen model for requirements engineering was founded on a combination of six sigma techniques and a set of best practices adopted from within the organization.
Bonney Joseph
December 12, 2007
one way to categorize and organize questions Capturing Implied Requirements

Sometimes the user, project sponsor, and other key stakeholders haven't provided in the requirements documentation all the expectations of the software you're building. Instead, these expectations are only implied. In a perfect requirements-gathering process, there would be no such thing as an "implied requirement" because every requirement would be captured in the document. But no process is perfect, in theory or in practice. This article should help you look for and recognize the presence of implied requirements and learn how to capture them and convert them to documented requirements.
Robert Rose-Coutré's picture Robert Rose-Coutré
October 24, 2007
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
February 9, 2006
More

Better Software Magazine Articles

Managing Your Analysis Debt

What is your project's analysis debt load? What's the difference between good and bad analysis debt? What are causes and remedies for such debt? Mary Gorman and Ellen Gottesdiener explore the concept of analysis debt and consider strategies for prudent investing.
Ellen Gottesdiener's picture Ellen Gottesdiener Mary Gorman
November 10, 2009
How Agile Practices Reduce the Top 5 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 the top five requirements risks.
Ellen Gottesdiener's picture Ellen Gottesdiener
July 15, 2009
Building a Foundation for Structured Requirements: Aspect-Oriented Requirements Engineering Explained (Part 2)

Aspect-oriented requirements engineering (AORE) is a new methodology that can help us to further improve the analysis, structure, and cost of development of software requirements. The second part of this two-part series focuses on the AORE specification techniques.
Yuri Chernak
February 26, 2009
Building a Foundation for Structured Requirements: Aspect-Oriented Engineering Explained (Part 1)

Aspect-oriented requirements engineering (AORE) is a new methodology that can help us improve the analysis, structure, and cost of development of software requirements. AORE does not replace but rather complements any of the existing requirements methodologies. This two-part paper explains to software practitioners the AORE concept, illustrates how it can be applied on software projects, and discusses the benefits of AORE. Part I focuses on the AORE analysis techniques.
Yuri Chernak
December 30, 2008
More

Conference Presentations

Building a Requirements Foundation with Customer Interviews

Whether you are building a brand new product or evolving an existing system, understanding the business needs of your customers is the foundation of a marketable product or valuable internal application. Few of us are experts in interviewing techniques, and few customers talk about their tasks, needs, and context in neat, concise statements about requirements. Hone your elicitation skills and learn what it takes to get beneath the surface and understand your customers: their world, how they work, and what really bothers them. With effective interviewing techniques and skills, you will get inside their heads and better understand their needs within their context.
Esther Derby, Esther Derby Associates Inc
Evaluating Requirements for Testability

For a test engineer, perhaps the most important measure of requirements quality is testability. By improving testability during requirements development, you not only will make test design easier, but you also will have gone a long way toward building better software for less cost. Learn methods to identify the requirements problems that reduce or improve testability: ambiguity, incompleteness, inconsistency, incorrectness, and "compoundness." This method first was used successfully in a very large payroll system development project and has since been practiced in both large and small development projects. From this session take away a spreadsheet-based method for tracking requirements testability throughout the project, and see examples from an Access database that can be used for further requirements analysis.

  • How to analyze requirements for attributes that increase testability
Rodger Drabick, Lockheed Martin Transportation & Security Solutions
Cosmic Truths about Software Requirements

The history of many software projects shows that requirements mistakes are the most expensive ones to correct late in development. So, why do we make big requirements errors over and over, even in mission-critical software projects? Karl Wiegers, author of a best-selling book on software requirements and a consultant on many such projects, shares his top ten requirements principles to help your organization produce accurate, consistent, and unambiguous requirements. Although there are few absolute truths in software development, Karl has found several that almost universally apply to software projects. These principles emphasize the critical contribution that good requirements make to a project's success, and the critical contribution that customer involvement makes to good requirements.
Karl Wiegers, Process Impact
A Defined Process for Requirements Peer Reviews

Most software projects include reviews-whether or not they are officially part of the development process. Unfortunately, these reviews are often inefficient, and even unproductive. Implementing a defined peer review process for requirements is an excellent means to both improve your requirements and kick-start overall process improvement because participants can immediately see timesaving and increased quality in work products. Find out how to measure benefits and potential savings from these reviews and how they can identify major gaps in other project processes. Take away a Peer Review Toolkit that allows your team members to start their first effective requirements review right away.

  • A simple, efficient peer review process with a 30-minute training program
  • Instant results and metrics, including potential savings
  • A Peer Review Toolkit to get started.
Rob Wyatt, Wachovia
More

CMCrossroads is a TechWell community.

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