A Radically Different Approach from Traditional Requirements Gathering Methods - radically different because:
- We contend that traditional requirements gathering methods are a root cause of enterprise software project failures. The reason is that they often leave critical business expectations assumed and undocumented for some or all phases of the project.
- Our requirements approach is about how a company does business-business transaction by business transaction. This approach insures all critical business expectations are known and documented as requirements. It ensures buyers and users get what they expected, at the price they expected to pay or within the project's budgeted amount.
- Creates a reusable database of the requirements for the operation of a company's abstract business system. A database which is continually updated to become the "to be" requirements for all future enterprise software projects.
The missing component in system projects for enterprise software...
...is usually a complete and fully detailed description of the work that all of a company's systems taken as a whole must support. "The work that all of a company's systems taken as a whole must support" might be called that company's abstract business system. A company's abstract business system consists of all the work performed within the company in the course of doing business. An Abstract Business System Description, which is what our product produces, defines a company's abstract business system...
An Abstract Business System Description can be used for:
- In business terms (not in technical or software package-specific terms)
- In the language of the people who perform the work
- In terms of the work-related interactions between
- People within and outside of the company,
- The various functional areas within the company,
- And the systems that support these people.
- Enterprise software acquisition, evaluation and implementation
- System audit and break-fix planning
- Integration planning (planning the integration of disparate systems in order to serve a combined purpose)
- Enhancement and modification planning
- Regulatory compliance (on its own, or following a system replacement or enhancement)