Business Specification

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.

Inputs

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

Outputs

Business specification
Project Plan

Parallel Activity

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.

Primary Participants

Executives and directors formulate and approve specification.
Team members reporting to directors provide input.

Business Specification Contents

Overview

Describes the context of the systems, processes, and/or services to be developed.

Business goals

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
Description of business models supported

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.

Critical Success Factors

Defines the expected business outcomes of deploying the new or improved systems, services, and/or processes.

Risk Analysis
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.
Business models not included/supported
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.
Issues Register

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.

Project Plan Contents

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

Send E-Mail