|
Staged Requirements Management
Kishore C.S. (March 2000)
One of the major challenges in Software Development is to manage feature creep. This
happens in any software development life cycle and is most common cause of delays in
project delivery. Ultimately the customer is to be satisfied and customer keeps stating
his requirements though the product has reached advanced stage of development. Recognizing
this need to meet requirements and at the same time meet delivery schedules the contract
between Customer and Supplier needs to have a good ‘Requirements Management’
Clause that is agreeable to both.
This document gives an approach to identify and structure this crucial aspect
In a typical project user states his most critical system requirements first and
gradually as the requirements analysis and development stage emerges more requirements
will be surfacing. This typically happens if the requirements management process is
completed in short time frame. Both customer and supplier should evaluate the status of
requirements before concluding that requirement stage is completed.
The following are the stages suggested and the requirements that must be identified in
each stage.
| Stage |
Attributes of this Stage |
Requirements that should be finalized |
| Stage A |
During contract and Requirements Stage |
- All High Risk Functional Requirements must be stated.
e.g. System Requirements, Performance Requirements, Security Requirements, Usage
Requirements, Data Volume Specifications, Data Migration or Implementation related
requirements, Functional Coverage and Business Processes to be covered |
| Stage B |
During Analysis and Design Phase |
- Implied requirements should be identified through analysis.
e.g. Implicit business processes that need to support main business processes will be
identified during Analysis Stage
- Medium Risk Functional Requirements
Various User Interfaces should be reviewed and approved during this stage. |
| Stage C |
Design Review |
Business Model validation should throw any
referential integrity, concurrency related requirements and sign off should be completed. |
| Stage D |
Development |
Any requirement that qualifies in the Stage A,
Stage B, Stage C coming at Stage D is high risk to the project and should lead to Contract
Review. Requirements that can creep in at this stage should be aesthetic changes to user
interface or supporting requirements that result in minor changes in Logical Model.
e.g. Modifying user interface to change layout can be acceptable. Adding additional
attributes to existing Logical model should be acceptable. But any change in Key
Attributes of Logical Model will quality for design change. |
| Stage E |
Testing |
No Functional requirements should change at
this stage. |
| Stage F |
User Acceptance Testing |
Main Objective of this stage to ensure the
product is as per stated requirements. However during this stage the user may identify
changes to product. The contract should provide by appropriate guidelines to accept
product as it is and give enhancement project to the development team. This clause should
be added keeping in mind the recognized truth that identifying all requirements and
meeting them in one stage is nearly impossible task. If in the first stage itself there is
an agreement that there will be two version releases the feature creep can avoided in
first version and second version will be a highly useful version to users. |
Conclusion:
Having an understanding of feature creep and how it should be accepted into an ongoing
project is necessary for a healthy relationship between customers and suppliers in
Software Projects. This understanding between both the parties will avoid any bitterness
and both work together as a team and finally deliver a product that will have long term
benefits to the customer. Bring discipline into ‘feature creep’ and deliver good
quality software.
Back
| 
