The business specification document's primary purpose is to serve as a contract between the development organization and the client or executives as to what business activity will be supported by the new or improved system. It states in clear terms the goals and limitations of the systems to be developed.
Because of the inevitable "feature creep," it is important that the business specification be complete and accurate, and considered final.
The following information helps create the business specification:
![]() | Business plans |
![]() | Sales and marketing plans |
![]() | Client surveys and requests |
![]() | Competing business solutions |
![]() | Existing business processes |
![]() | Business specification and project plan templates |
![]() | Business specification |
![]() | Project Plan |
Other departments including program management, sales, marketing, quality assurance, documentation, training, information systems administration and support, and maintenance begin to prepare plans to execute their responsibilities during the development of the system as well as during deployment.
![]() | Executives and directors formulate and approve specification. |
![]() | Team members reporting to directors provide input. |
Describes the context of the systems, processes, and/or services to be developed.
Describes the goals that a solution would meet, such as:
![]() | enter market first with system/support/service |
![]() | provide best-of-breed product to gain or corner market share |
![]() | decrease costs |
Describes, at a detailed level, the business activity that the system and services will provide.
Use cases, prose, diagrams, charts, and tables are effective means for business processes and flows.
Defines the expected business outcomes of deploying the new or improved systems, services, and/or processes.
![]() | Defines dependencies and unknowns that could derail the business and software development effort. For example, dependency on another organization to deliver needed tools or failure to staff to levels required to complete development effort. |
![]() | Should quantify the risk and propose solutions and approaches to negate or manage the risk. |
![]() | Defines desired business activities or needs that given high-level analysis cannot be included in current phase of project. |
![]() | Defines business activities that were discussed and analyzed but were dismissed. |
In a perfect world there would be no issues or unknowns. However, issues are inevitable and need to tracked in an issues register during every stage of the project's life cycle.
![]() | Time-line and major tasks |
![]() | Based on business requirements, determine deployment date and schedule major milestones to achieve that date. |
![]() | The high-level time-line should note the involvement and interdependencies of organizations, departments, and teams within departments. |
Business Specification Analysis Detailed Design Testing Post Study Functional Specification Architecture Design Implementation Deployment and Maintenance HOME