Business Requirements vs. User Requirements

Posted by Rich Crowley in Requirements

High level business requirements are usually pretty simple in a small project. Minor enhancements or changes to an existing product or service would fall into this category. Examples would be a wording change change in client correspondence or changing a commission calculation formula for a sales force contract.

These business requirements often get documented in a project charter and in the business requirements with the same level of detail because from the perspective of the business sponsor and the business analyst, the change is pretty simple and doesn’t require much detail.

However, the challenge in these seemingly simple requirements is to turn them into the detailed requirements needed by the developer in order to make changes to the underlying system. I use the word challenge here because it really can be quite a big step to go from the high level requirement to the coding.

For example, with further analysis, it may be determined that the correspondence change required should only occur for some products, or it should occur conditionally for some products. The required wording needed might, after more detailed analysis, be two or more wording changes that are product dependant and require logic to determine when each should be applied. Similarly, a commission calculation may be simple enough on its own but often sale forces are compensated through a combination of commissions and the results of another.

It is finding all these tentacles of seemingly simple requirements that make them not so simple. The better this is done up front during requirements gathering and documentation, the smoother development, testing and deployment will be.