|
Kill by Wire Linda Hayes has worked in the software industry for a long time and through a lot of changes. But a series of recent events has led her to question whether the industry has changed for the better or worse. In this article, she recommends some attitudes we should lose and some we should adopt in order to save our software and—in some cases—our lives.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
Tailoring Requirements Development and Management In part 1 of this article (published as a weekly column on May 22), Ellen Gottesdiener discussed the need to adapt your requirements practices to your product and project. In part 2, she explores additional issues for tailoring requirements development and management.
|
|
|
Adapting Your Requirements Practices Should your requirements practices embrace the change-driven approach of agile methods--lightweight models, minimal documentation, and little process? Or should you take a risk-driven approach--robust models, careful validation, and rich documentation? In this two-part weekly column, Ellen Gottesdiener explains that you should tailor your requirements practices to your project and product.
|
|
|
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.
|
|
|
Information Gathering If your customer interview questions focus too narrowly on a problem that must be solved, you run the risk of missing information that could be critical to a successful outcome. In this column, Naomi Karten says playing detective improves your ability to gather information. To improve the odds of success, it's important to ask questions from multiple perspectives—and to pay attention not only to the customers' response, but to how they say it as well.
|
|
|
It Is Still The Requirements Why are information systems requirements so difficult to define? What causes the yawning chasm between documented requirements and the actual implemented system? Requirements definition is difficult for two major reasons. First, the customer may have only the vaguest idea of what an information system should look like prior to implementation and use. Second, system developers lack sufficient knowledge of the business functions a system must support.
|
|