Fresh off two software selection projects, I am reminded that software should benefit its users, not the IT group. A well-designed software application–or commercial software implementation–starts with documenting clear, solid business requirements.
Solid requirements (prioritized business needs) are critical to success. Good business requirements, coupled with objective evaluation criteria, can help a company to identify a short list of vendors and select a solution that best meets their needs, fits the company’s IT maturity and culture, and that users will adopt.
Consider the following tips when developing business requirements. When eliciting requirements, the business analyst should:
- be clear, not ambiguous.
- document business needs in terms familiar to the users–not IT terms.
- help stakeholders reach a consensus on needs (“what” the software does).
- help the stakeholders to develop standardized business process work flows that are simple enough to use day in and day out. The software implementation will reflect these work flows, which “behind the scenes” are well thought out and can handle exceptions with built in “business rules.”
When eliciting requirements, the business analyst should not:
- document “molecular” requirements; each should be “atomic” and describe a specific need.
- discuss the software features or look and feel (“how” the software does it) This will happen after software selection, during design.
- allow certain stakeholder’s opinions to override what is best for the group as a whole.
- help stakeholders to develop different work flows for different locations. Use “business rules” to address differences and to allow consistent, enterprise-wide data roll-up and reporting.
Read more about an approach to well-designed software.
Click here for a wealth of articles on software business requirements, evaluation and selection, and managing the IT systems life cycle.