|
|
|
» Best Practice with Structured Requirements
Analysts report poor requirements management accounts for as much as 71 percent of software project failures. The main cause is the gap between (a) what the business team wants and how it communicates this, and (b) what IT understands and delivers.
No matter how good a project development environment is, if the requirements captured in the first place are inaccurate or incomplete, then the project is destined for failure. The same fate awaits project plans that are structured around passive and unmeasurable module and task definitions rather than measurable, business-defined goals. It sounds obvious, but the current rate of project failure demonstrates that this is plainly a difficult task.
The main challenge with a software project is that the end result is, essentially, invisible. It is not like building a house, where design anomalies are often clearly visible. Communication in technical projects can be problematic, both between the customer/user and the business analyst and between the business analyst and the development/QA team. As a result, there is often inaccurate or poor understanding of the project scope amongst stakeholders. Project estimation relies on “gut feel” and there is often an overreliance on having particular technical people involved. Similarly, project progress cannot be measured easily or accurately due to inaccessible or overly technical milestones. This increased risk to the project often results in cost overruns, late delivery or, worst of all, outright failure to deliver the system required.
A structured approach to requirements capture and management resolves these problems and is the only way all stakeholders can be confident that all requirements have been understood and incorporated into the project plan.
Author: Fergal McGovern, Product Manager, Optimal Trace Compuware Corporation
Read More ...
| Comments |
Currently, there are no comments. Be the first to post one!
You must be logged in to post a comment. You can login here
|
|