Certification Objective 4.01: Functional Specifications

The transformation of requirements into functional specifications is the shift from problem definition to solution design. The functional specifications are a repository of documents. This document defines what will be built, how it will be done, and when it will be completed. The functional specifications consist of a summary document that physically describes the functional specifications and lists artifacts that make up the specifications. These collections of documents are considered “living documents,” meaning that they will change throughout the project cycle. The functional specifications document is a record of the decisions and agreements made regarding the functionality of the solution, design goals, and priorities.

Artifacts can include Unified Modeling Language (UML) models such as use case diagrams, usage scenarios, initial requirements, initial features, and various other models. The artifacts from the conceptual, logical, and physical design stages can be in electronic form or stored in formats of various tools. The manifest or summary can exist as an electronic document, such as a Microsoft Word document or Microsoft PowerPoint presentation. The functional specifications are a joint effort by the team.

Exam Watch

The functional specifications are a virtual collection of documents.

Goals

There are four goals of the functional specifications. First is to consolidate a common understanding of the business and user requirements. The features of a solution are determined from the business and user requirements. The number of requirements will vary based upon the size of the project. The functional specifications help the customer and the project team agree on a common understanding of the requirements of the solution.

The second goal is to break down the problem and modularize the solution logically. It is important that the team identify the entire problem clearly. This is achieved by breaking the solution into distinct, unambiguous parts. The functional specifications help simplify the solution into logical parts and document them. This segmentation helps identify if design changes need to be made early in the process. Catching these errors now is less risky and less expensive than finding them later.

The third goal is to provide a framework to plan, schedule, and build the solution. The specifications provide information for the team to create tasks and cost estimates and budgets for the project. The program manager can create estimates for resources and time that the project will require. The other purpose is for the testing team to create test cases and test scenarios early in the process. The release management team uses the functional specifications for deployment and to support the development and test environments.

Lastly, the functional specifications serve as a contract between the team and the customer for what will be delivered. This is evidence of what is to be developed and delivered. In some organizations, this is written as a contract between the team and the customer. It is not necessarily a legal document, but can serve as one. This document can be used by a third-party team or groups as an addendum to a project work order.

Risks of Skipping Functional Specifications

Sometimes the team will choose to skip the functional specifications and continue to development. Budget or time constraints may interfere with creating the functional specifications. The risks associated with skipping the functional specifications are:

• The team may develop a solution that does not completely address the customer requirements.

• The team might be unable to clearly define customer expectations and share a common understanding with the customer. Consequently, the team might not know whether they are developing the required solution.

• The team might not have enough detail to validate and verify that the solution meets customer expectations.

• Estimates of budget and schedules cannot be accurately created for the project.

  Exam Watch

  These risk factors are very important and may not be presented as risks of skipping the functional specifications.

Elements of Functional Specifications

The following table describes the possible elements of functional specifications. These elements can be separate documents.

Element	Artifacts
Conceptual design summary	Use cases, usage scenarios, context models such as screen shots
Logical design summary	Task and task sequence models, logical object and service models, conceptual models of the proposed solution, UI screen flows, logical database model
Physical design summary	Component packaging, component distribution topology, technology usage guidelines, infrastructure architecture and design, description of UI screens and physical database model
Standards and processes	Security, packaging, maintainability, supportability, stabilization, deployment

The conceptual design summary provides information on the conceptual design and provides information such as the solution overview and solution architecture. The logical design summary includes information such as users, objects, and attributes. The logical design is the next step in the evolution of the solution. The logical design takes the high-level view generated from the conceptual design and divides the information into different layers. The physical design summary provides a summary of the physical infrastructure design of the solution. The standards and processes serve as a guideline for performing various tasks for the project. In addition, this section includes details about the quality and performance metrics that will be used.