requirements
Articles
 |
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. |
|
|
Requirements-Based Development: A Software Configuration Management View It seems so obvious that we should develop systems based on requirements, and yet it turns out to be rather hard to do and thus many organizations are doing it very badly. From a software configuration management standpoint, we could perhaps leave the whole process of requirements engineering to one side and focus on the management of requirements and thus the aspects of change control and traceability. That would perhaps be unduly ducking the issue, and, of course, we can’t resist giving an opinion anyway! |
||
|
The Trouble with Tracing: Traceability Dissected Traceability! Some crave it. others cringe at the very mention of it. For hardcore configuration managers and requirements and systems engineers, it is a fundamental commandment of “responsible” software development. For many hardcore agilists and other developers, the very word evokes a strong “gag” reflex, along with feelings of pain and frustration. Traceability requires work and discipline! So how does traceability add value to our business and how can we make it easier? |
||
|
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. |
|
|
RequireMINTS Ponder for a moment the impact of mints on your life. They provided an extra degree of confidence during some of life's most important moments from job interviews to first dates. Some people may even have a spouse and kids because a mint helped out in a crucial moment. In this column, Dion Johnson points out that the requirements improvement techniques called RequireMINTs can similarly impact the life of your software projects because like mints, they are small, refreshing, and effective. |
||
|
What Is a Customer? When we communicate, the words sound familiar so we think we understand each other. But understanding fizzles when we attribute different meanings to the words we use. In this column, Naomi Karten illustrates how differences in the way departments and companies define their terms can cause confusion, flawed conclusions, and faulty decisions. Naomi asks us to question the meanings of terms before starting a project to ensure that we understand what's called for. |
||
|
Product Risk Analysis Clarifies Requirements This presentation re-emphasizes that requirements are important. The difference between functional and nonfunctional requirements will be covered. Then, Product Risk Analysis will be described, along with the elements of the analysis and steps toward performing the analysis. |
Jim Kandler
November 4, 2003 |
|
|
Writing Requirements Documentation for Multiple Audiences When writing requirements documentation it's important to consider your audience. In this article, the author shows you what questions to ask yourself when you're preparing your project plan. |
||
|
Escape from Documentation Common practice says that software projects need documentation. But there's still something of a gap between the preaching and the practice. In small companies especially, managers may claim there isn't time to document, or that "Our project is different." Maybe some of these managers know something the rest of us don't know. Are there factors that might make a project exempt from documentation? I've thought of a few possibilities. |
Sheryl Smith
October 9, 2003 |
Pages
Recommended Web Seminars
Featured Resources
Visit Our Other Communities
StickyMinds is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.