seaduspx wrote
Here's what the business wants from the application - "A minimum of 100 forms shall be validated in a 24-hour period."
The IT shop has stated that they are not sure that they can do it, but they can try. The business has stated that "this is what we require."
Question: Since IT is not sure if they can meet this requirement, should it be documented? After all, this is what the business wants. But by putting their signature to the reqs doc, IT feels as though their hands will be held to the fire. If IT doesn't know if they can meet the requirement they should sign off occur?
What do I do? Others want sign-off on the requirements.
Thanks!
|
In answer to your question - should these be in the requirements, I would say definitely yes. Now the tricky question - what is the priority of this requirement? Is it a must-have, nice-to-have, optional, etc.?
I do not know the details of your analysis process, but I presume that this is a requirements document that is written on behalf of the business to be provided to the solution provider for development. If that's the case, then from the business' perspective it is a must-have mandatory requirement. Assuming they're the only group to sign off on the requirements, then this is how it should be documented. Usually there would be a process to take this document from the business requirements to the actual software specs stage, where such a (non-functional/performance) requirement would be turned into a Service Level Agreement (or if it cannot be guaranteed, a Service Level Objective).
Now, since the solution provider is already involved in the discussion and there's disagreement over whether the solution can meet this requirement, there needs to be an understanding of the tradeoff involved here. I think IT's statement is a little misleading - usually performance requirements can be met, but they cost more to ensure the design/solution can scale, that there's sufficient hardware in place, etc. Furthermore, there should be ample ways to test the performance of the system before it hits production - even if a testing environment does not completely mimic production you should be able to extrapolate results based on performance in the testing environment and baselining other systems already in production.
If this is an internal project then presumably the cost of the system is coming out of the business' budget - so the tradeoff of having their desired performance against the costs it will take to achieve their desired performance requirement. Ideally the IT shop would estimate such costs, but at the very least they should be able to estimate the costs required to determine how test the performance of the system at the appropriate juncture in the process. That way business can determine whether it's worth the extra budget implications to demand the performance requirement as mandatory versus highly desirable (note: if such systems don't come out of business' budget then you have some major structural issues at your firm - there's no good way to align interests if such systems are 'free').
As a BA you should be in a good position to point out these aspects and options to both groups - help bridge the divide by helping each side understand the other's viewpoint and suggest how they can present their position to each other so that they'll find a way to arrive at an agreement.