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
Then log the defect
Let's look at it from the point of view of the support person who is trying to work with the end user, as opposed to the BA trying to justify the work that they want to do. First, the support people needs access to the version of the working system being used by the end user, which can be a challenge when multiple versions are in production. They need this access so they can use the system to simulate the "problem" that the end user is experiencing and hopefully work them through it.
Second, they need access to a defect/change request tracking system. The problem may be an actual defect(s) or it may generate one or more change request(s) to the existing functionality which should be fed back to the development team. This defect/CR should be treated by the team as a new requirement and be prioritized appropriately. It may be very high priority and dealt with immediately, or it could be considered not important at all and effectively prioritized out of existence. Or it could be between these two extremes, of course.
Third, they need access to a training system. The end user request may generate the need for training of the end user (good luck these days with existing budgets) and the support person should have the option of helping enroll the person in the appropriate training.
Fourth, they need good people skills. In many cases the problem is addressed by the support person on the call.
They don't really need access to the requirements specification. They are very likely unlikely to trust the content because it's out of date, and even if it was solid and it was trusted there is little opportunity to add value using it anyway. Walk through a support scenario. Someone reports what they think is a defect. The support person looks up the current requirements, somehow finds the relevant information, reads it, reports what they read to the person making the call, tells them that the system is working as they should, and the person indicates that they agree. Consider how fragile that scenario is -- it's likely hard to find the relevant information quickly in any decent sized spec, they likely don't have time to read it (when was the last time you ran into a well staffed support group?), they might not understand what they're reading, and the end user likely could care less what the spec says because they think they've got a real problem.
- Scott