At work our client frequently provides us with written work requests. These requests essentially contain basic business rules that they want implemented. Our job is to initially cost the full implementation of the requests. This is not too difficult if you know the existing system well.We have a separate requirements team. I think it is their job to read and understand the business requirements. Then they are to perform analysis to arrive at a list of system requirements. The development team will then design and implement a solution to these system requirements.
I am listed as the guy who needs to do most of the design for the new stuff. And I have been noticing that some of the system requirements seemed sketchy. So I have been asking the requirements team about them. Here is where the true surprise come in. For most of the questions I pose, the requirements team does not know what the system requirement means. Apparently they have been just taking the business requirements and reformatting them to produce a system requirements list.
Now I find this a bit disappointing. I can read the initial work requests that contain the business requirements. If there is no added value in the system requirements that are produced, I might as well stick with the original material. The authors of those documents know exactly what they want. But this should not be how our team works. Might be time to call in the big dogs and shed some light on this defective arrangement. Luckily I have found over the years that it is rare to find folks who excel at requirements analysis. So I do not expect much. We shall see if there can be any improvement in the current team.
