Existing functionality as requirements?
I'm wondering what other's think about a dilemma we are having amongst BA's in my organization. When documenting requirements for maintenance to our Legacy system, some BA's feel it is quite acceptable to include current functionality as a requirement if they feel that the enhancement requirements may cause that current functionality to be affected or removed.
An example would be something like "Retain current functionality that allows users to update termination date."
I don't necessarily agree with this, though at times it may be valid to express to the development team that the enhancement requirements should not affect current functionality.
Anyone have any comments how to communicate things like this?
MPS
Compare the TCO with the TVO
An important issue to consider is what is the Total Cost of Ownership (TCO) of that documentation with the Total Value of Ownership (TVO) of it? Estimating the initial cost is fairly straightforward although the TCO often isn't -- include maintenance cost of the documentation, process-related costs surrounding your change management effort pertaining to usage of those docs, and so on.
The TVO can be very difficult to measure -- what is the value of the BAs controlling the documentation vs the development teams? What real problems will be avoided? What real benefits will be achieved?
Also, what makes the BAs think that the development teams will follow their process and not simply ignore them and change the legacy source code anyway? If this sort of thing happens the code will be out of sync with the docs, and the BA's effort will be pretty much a waste.
What makes you think that the developers will read the documentation written by the BAs? Documentation which they likely view as inaccurate and extraneous?
- Scott
Chief Methdologist/Agile, IBM Rational