While the business specification serves mainly to ensure that the right system is developed and that all the business needs will be supported, the functional specification serves to assist in planning the software and hardware development lifecycle, from analysis to deployment. In other words, the functional specification attempts to remove any surprises from the execution of the software development process, looking to define every aspect of what needs to be developed and how it should be developed. Further, the business specification combined with the functional specification will define the scope of the project.
| Business specification |
| Project Plan |
| Functional specification template |
| Development plan template |
| Functional specification |
| Development plan |
Research and development organization, primarily the directors of the development groups responsible for the project in conjunction with team leaders from those groups.
Approved by executives and directors of development.
| High level description and architecture of systems needed to support business models.Use cases, prose, state diagrams (life cycle diagrams), and process and data flow diagrams are effective in describing high level system structure. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Requirements, Constraints, and Trade-offs
| ||||||||||||||||||||||||||||||||||||||||||||||||||
| Risk Analysis |
In every stage of development, risk analysis should be performed as described in the business specification section. In the functional specification the concerns are more related to the development effort.
| Issues |
The software development plan is formulated during the same phase as the definition of the functional specification. It focuses primarily on the software and hardware engineering of the system, but notes dependencies on other groups such as training or documentation. The development plan is a macro plan that identifies tasks, resource needs, and major milestones. Detail should be added to the plan, such as internal training needs, where specifics can be anticipated.
| Schedule |
| Timeline indicating milestones within the development group and showing dependencies and inputs and outputs with other groups. For example, at the milestone Analysis Complete, the business specification, functional specification and analysis document should be shown as inputs to the training and documentation groups that then uses that material to plan and develop training materials and user documentation. |
| This timeline should show parallel tasks both within the development group and with other groups that have a direct input/output relationship with the development group. For example, the task of developing training materials and user documentation would be occurring in parallel with the development group continuing on with design and implementation. |
| Development tasks should be given priorities and placed within the timeline so that work that multiple groups will be dependent on is done first. For example, if a means for distributing load between processes is needed, the distribution framework should be designed and developed before the specific applications that need the load-balancing functionality. Separate, broken-out schedules may be necessary to show this level of detail. |
| Resource allocation |
| Teams and individuals will be referred to in the schedule. Details of those teams and individuals should be specified in a separate section. Skills, expertise, and leadership abilities should be specified for each participant in the development effort. This information can be summarized in a roles document, then those role names can be used to specify the members of each team. However, even with role definitions, specific skills will need to be determined for each group. For example, a team that is assigned to develop a system framework may need a team leader, a system architect, two developers at level 3, and two developers at level 1 or 2. Within the team, expertise in C++, Smalltalk, distributed objects, and network protocols may be required. |
| Methodologies |
| The methodologies that will be used throughout the remainder of the development life cycle should also be specified at this time. For each task in the schedule, a methodology should be specified. If there are unknowns, this points out the need for a group to investigate the methodologies in parallel with the analysis effort. For example, if integration or validation testing methodologies are an unknown, a team or individual should be tasked with investigating existing methodologies as soon as possible. |
| A methodology should be defined before formal activity can begin. This is necessary so that clear communication will be possible within and across development teams. For example, an analysis methodology should be determined before full-scale analysis is begun. |
| Training |
| An internal training plan must be defined so that vendors and internal resources can be scheduled to deliver the required training. |
| Training requirements will also impact the development effort and must be factored into the schedule |
A parallel activity that should begin in this stage of the development cycle to develop or adopt a plan and procedures for tracking cost, time, and staff resource allocation. The directors and executives in the research and development organization will be most interested in this information and will determine the forms and techniques for tracking this information. Team leaders and directors will then execute the details of tracking the information.
Business Specification Analysis Detailed Design Testing Post Study Functional Specification Architecture Design Implementation Deployment and Maintenance HOME
