This page is dedicated to software requirements management.
| Title | Author(s) | Notes |
|---|---|---|
| Death by UML Fever | Alex E. Bell | A humourous look at the overuse of UML by software teams. The moral of the story is "Use UML where appropriate and something else where it is not". |
| Don’t fall prey to these false project requirements | Tom Mochal | This article contains advice aimed at helping avoid problems with requirements. |
| Effective Requirements Definition and Management | Borland Software Corporation | By now, it is well known that shortcomings in requirements definition and management lead to excessive rework on software projects that fail to achieve full customer satisfaction. A closer look at their own software organisations can help managers at all levels identify pain points related to how requirements are elicited, analyzed, specified, validated and managed. (from article) |
| Ensure requirements are tracked throughout a project | Tom Mochal | This article discusses the need for tracking requirements during a project to ensure that they are implement. A simple traceability matrix is described. |
| Five critical questions you need to answer when evaluating a business case | Ilya Bogorad | This blog gives some guidance for reviewing business cases to ensure they provide sufficient information allowing appropriate decisions to be made. |
| Follow this simple scope change management process | Tom Mochal | Tom Mochal provides a simple scope change process that you can use on your project. (from article) |
| Good Practices for Developing User Requirements | Ellen Gottesdiener | |
| Interpreting Requirements in a He Said/She Said World | Deb Jacobs | This article is primarily aimed at software requirements; however the basic principles are the same for most other types of projects. It is very important to spend time working on requirements as this defines the scope of the work being delivered. The article has a short story at the start that seems awfully familiar ... |
| Mining project requirements - techniques to use before and after an interview | Joe Goss | This article discusses some of the things that should be done before and after a requirements interview. There is some good advice in this article. |
| Software Tracking: The Last Defense Against Failure | Capers Jones | This article looks at tracking software projects in order to prevent them failing. It discusses a number of reasons why software projects have failed, and why the customer has litigated. The article proposes a number of milestones that tracked, and suggests a format for monthly reporting. The information in this article is targeted at large projects; however I think the ideas and suggestions can be adapted for use within smaller projects. |
| Tests and Requirements, Requirements and Tests: A Möbius Strip | Robert C. Martin, Grigori Melnik | This articled shows that FIT (Framework for Integrated Testing) style acceptance test definitions can be used as a mechanism for developing system acceptance tests before the system is actually built. The idea is to get the stakeholders to define the acceptance tests in a simple, table driven format that can then be used to drive the system and prove that it meets its requirements. The article shows how to define scenarios that the system must meet. The scenarios are written in a logical fashion that should allow anyone to understand and adapt for different types of testing. Simultaneous access to the system can also be specified and tested using this method. The article presents the notion that the software requirements written in this format are actually acceptance tests, and the acceptance tests are the requirements. It's an interesting concept, and one that has some merit. |
| Twelve Requirements Basics for Project Success | Dr. Ralph R. Young | Whilst the advice in this article applies mainly to software development, the principles apply to all sorts of projects. |
| Use these interviewing techniques to gather project requirements | Tom Mochal | This article discusses techniques for obtaining requirements from a customer. |