Tài liệu Module 12: Introduction to Functional Specifications pdf

Module 12: Introduction to Functional
Specifications

428 Module 12: Introduction to Functional Specifications



Module Overview

Module 3: A Services-based
Approach to Solution Design
Module 4: Business Solution
Conceptual Design
Module 5: Business Solution
Logical Design
Module 6 : Be ginning Physical
Design
Module 1: Course Overview
Module 2: Solution Design Using
the MSF
Module 7: Selecting Solution
Tec hnolo gies
Module 8: Solution Design and the
Component Object Model
Module 9: Designing Solutions with
Microsoft Technologies
Module 10: Completing the
Physical Design
Module 11: Designing the
Presentation Layer

Module 12: Introduction to
Functional Specifications
Designing Business
Solutions
Functional Specification
Basics
Review
Functional Specification
Validation
Activity 12.1: Risk of No
Functional Specification
Functional Specification
Creation
Module 12:
Introduction to
Functional
Specifications
Module 12: Introduction to Functional Specifications 429




!
!!
!

Overview
"
Functional Specification Basics
"

Activity 12.1: Risk of No Functional Specification
"
Functional Specification Creation
"
Functional Specification Validation
"
Review
In this module
In this module


The Planning Phase of the MSF Process Model culminates in the Project Plan
Complete Milestone. One of the primary deliverables of this milestone is the
functional specification. The functional specification describes the solution in
sufficient detail for the development team to implement it.
In this module, you will learn about the functional specification, its contents
and purpose, and how to validate it.
After completing this module, you will be able to:
"
Describe the purpose and benefits of functional specifications.
"
Describe the contents of a functional specification.
"
Describe the purpose and methods of validating a functional specification.

Slide Objective
To provide an overview of
the module topics and
objectives.
430 Module 12: Introduction to Functional Specifications

!
!!
!

Functional Specification Basics
In this section
In this section
"
Setting the Target
"
Goals of the Functional Specification
"
Baseline Early, Freeze Late
"
Benefits of the Functional Specification


As you approach the milestone for the Planning Phase, the focus of the project
team begins to shift from design to development. Physical design views the
solution from the perspective of the development team. That perspective is
ultimately presented in the functional specification.
In this section, you will learn about the functional specification — its purpose,
its content, and its value.
Slide Objective
To provide an overview of
the topics and activities in
this section.

Module 12: Introduction to Functional Specifications 431




Setting the Target
Alice: “Would you tell me
please, which way I
ought to go from here?”
Cat: “That depends a
good deal on where
you want to get to.”
Alice: “I don’t much care
where …”
Cat: “Then it doesn’t
matter which way you
go.”
Alice in Wonderland
by Lewis Carroll


Many projects are started informally and are frequently implemented without a
plan. They do not have a well-defined destination. The success of these projects
is questionable from the start.
To ensure the success of your project, you need not only a design process, but
also a method of communicating the details of the desired result — the
destination — to the development team. The vehicle for that communication is
the functional specification.
Slide Objective
To illustrate the importance

of having a well-defined plan
so that the team knows
when it has been
successful.
Lead-in
Any successful project must
have an agreed upon
destination.
432 Module 12: Introduction to Functional Specifications



Goals of the Functional Specification
"
Describe, in explicit detail, the solution to be built
"
Identify the project scope
"
Serve as a primary deliverable of the Planning Phase of
the MSF Process Model
"
Provide the basis for other project plan documents,
such as the project schedule
"
Serve as a form of contract within the project team and
between the project team and the customer
"
Function as a living document during development

The functional specification is the culmination of the design work accomplished
through the Planning Phase of the MSF Design Process. It describes the
solution that is to be developed and provides the design details that the
developers need.
The functional specification also establishes the scope of the project,
identifying what should and should not be included in the application.
Other planning documents, such as the project schedule and project plan, are
created based on the details of the functional specification.
Furthermore, because the functional specification requires the approval of the
team and the customer, it serves as a form of contract among all the
stakeholders.
Although the functional specification describes the solution, it is certainly not a
static document. It can, and should, be modified during the Developing Phase to
reflect any design changes that occur.
Slide Objective
To describe the functional
specification.
Module 12: Introduction to Functional Specifications 433




Baseline Early, Freeze Late
"
Baseline when there is enough information to move
forward
"
Freeze when it is too risky or costly to make additional
changes
"

Avoid analysis paralysis
"
Allow for an iterative versioning process
"
Develop a change-control process


The project team should baseline the functional specification as soon as there is
enough information to move forward and freeze it only when leaving it open to
change poses an unacceptable project risk.
Due to the constant innovation that occurs on a development project, functional
specifications are inherently incomplete. If you spend too much time analyzing
requirements, though, no actual development will get done. By baselining the
functional specification early, you are creating a fairly stable description of the
solution. By freezing it late, you can modify the functional specification as
changes occur.

Remember to enforce some type of change-control process on the
functional specification.

Slide Objective
To describe how the
functional specification
should be treated in terms of
change control.
Lead-in
The functional specification
must be allowed to change
and grow as the project
progresses. The

recommended way of
accomplishing this is by
baselining the functional
specification as early as is
reasonable but freezing it as
late as possible.
Note
434 Module 12: Introduction to Functional Specifications



Benefits of the Functional Specification
"
Clarifies what should be built at an appropriate level of
detail
"
Communicates the solution to all interested parties
"
Drives and records the agreement on the proposed
solution
"
Facilitates parallel development
"
Drives early project trade-offs
"
Assists in managing change during development


The functional specification describes the solution in a clear and precise way so
that the development team can build the solution that the project stakeholders

expect to be built.
The functional specification also serves as a method of communicating the
project’s specifics to the team members, the customer, and all other
stakeholders. It serves as a written agreement on the specific features that are to
be included in this release of the solution.
The functional specification facilitates parallel development by describing what
the product will be; therefore, it is not necessary for one team to await the
output of another team in order to begin building its piece of the solution. To
help prevent integration problems, though, parallel development requires a high
level of communication among the development teams.
The functional specification drives project trade-offs by forcing the team to
make hard decisions early in the development process, when changes are less
risky and costly.
The functional specification is useful as a change-control mechanism during
implementation and development of the solution. If all changes to the solution
features, and the reasons for the change, are recorded in the functional
specification, then it provides a means of tracing changes for the stakeholders.
Slide Objective
To describe the benefits that
a functional specification
brings to a project.
Lead-in
A functional specification is
sometimes seen as process
overhead, but there are
many benefits to having a
one.
Module 12: Introduction to Functional Specifications 435

Activity 12.1: Risk of No Functional Specification


This activity emphasizes the importance of implementing a solution with a
functional specification as well as the difficulties that arise when working
without a completed functional specification.
You will create an origami boat by using the instruments provided to you by the
instructor.
After completing this activity, you will be able to:
"
Articulate the value of a functional specification.

Slide Objective
To introduce this activity.
Delivery Tip
Remember that only some
students should receive the
functional specification.
436 Module 12: Introduction to Functional Specifications



!
!!
!

Functional Specification Creation
"

Contents of the Functional Specification
"
Design Process Output
"
Forms of the Functional Specification
"
Factors That Determine the Form
"
Functional Specification Pitfalls
In this section
In this section


Now that you know what a functional specification is, and some of its benefits,
you will focus on the process and contents of the functional specification.
In this section, you will learn how to create a functional specification and some
ways to communicate the functional specification to the development team.
Slide Objective
To provide an overview of
the topics and activities in
this section.
Module 12: Introduction to Functional Specifications 437




Contents of the Functional Specification
Content Purpose
Vision summary
Design goals

Requirements
Usage
summary
Features
Dependencies
Schedule summary
Issues
Appendixes
What you want the solution to be,
justification for it, and key
high-level constraints
What you want to achieve with the
solution
What you require from the solution
When the solution will be used
and who will use it
What exactly the solution does
Other factors on which the solution
depends
Key dates and deliverables
What risks might impact the
project
Design process output


The typical contents of the functional specification are as follows:
"
The vision summary is a summary of the vision document and includes the
business context for the solution.
"

The design goals describe what the project team and customer want to
achieve with the solution. The development team uses these design goals to
make decisions on such issues as performance, reliability, timeliness, and,
possibly, usability and accessibility.
"
The requirements identify what the users, customer, and other stakeholders
expect the product to do.
"
The usage summary is a high-level aggregation of the usage scenarios
created during the design process, which describe who will use the solution,
when, and how.
"
The features describe each aspect of the solution and how that solution will
accomplish the design goals.
"
The dependencies provide a description of external entities upon which the
solution relies, including high-level items such as interfacing to corporate
systems and low-level items such as a shared component.
"
The schedule summary identifies key interim milestones, deliverables, and
the product ship date.
"
The issues include a list of risks that require external visibility or escalation.
"
The appendixes include the design process outputs that the team used to
develop the functional specification.

Slide Objective
To list and describe the
contents of the functional

specification.
Lead-in
The following core items
compose the functional
specification.
438 Module 12: Introduction to Functional Specifications



Design Process Output
"
Is the basis for the features section
"
Serves as supporting information in the appendix
$
Conceptual design provides future-state usage
scenarios and models
$
Logical design provides business object model, logical
data model, and logical user interface design
$
Physical design provides technology selections,
component specifications, and a deployment model


The outputs of the design process are key contributors to the functional
specification. Conceptual, logical, and physical design each have deliverables
that provide supporting information for the functional specification. This
information should be added as an appendix.
Conceptual design provides the future-state use case models and the usage

scenarios.
Logical design provides the business object model — the services, objects,
attributes, and relationships of the solution. The functional specification should
also include the data design for the data structure as well as the user interface
design.
Physical design provides the topologies, the component specifications, and the
design of the data store. The functional specification should include the
candidate technologies that were selected in physical design. The functional
specification should contain the deployment model with existing and proposed
network, data, and component topologies. The physical user interface design,
however, is generally not included here, because it is incorporated into the
features section of the document.
Slide Objective
To show where the outputs
of the design process fit into
the functional specification.
Lead-in
Throughout the course, we
have been working through
the design process. The
outputs of all of the phases
of the process provide the
foundation for the functional
specification and are
included as appendixes.
Module 12: Introduction to Functional Specifications 439

Forms of the Functional Specification
"
Text documents
"
Web pages
"
Presentation format
"
Annotated screen prints
"
Prototypes
"
Question-and-answer format
"
Electronic mail


A functional specification is often thought of as a rather thick document, but
this does not have to be the case.
The functional specification can be communicated through many different
forms and styles.
Slide Objective
To help the students
understand that the
functional specification
should be in the form that is
best suited to the
development team.
Lead-in
The functional specification

can take many forms and
can include many different
types of information.
440 Module 12: Introduction to Functional Specifications



Factors That Determine the Form
"
Ultimately must meet the needs of the team
"
Needs can be influenced by:
$
Scope of solution
$
Complexity of solution
$
Size of team
$
Team’s level of understanding
$
Existence of previous version of solution


Because the functional specification is for the development team, it should take
whatever form is most appropriate for the team.
Be sure to use whatever is most appropriate for the situation, depending on the
scope of the project and the preferences of the team. For example, one
organization may deal particularly well with a Web-based interface, which
allows each stakeholder to review the functional specification at any time

during the project.
Slide Objective
To describe the factors that
determine the form of the
functional specification.
Lead-in
Several factors affect how
the functional specification
is presented.
Module 12: Introduction to Functional Specifications 441




Functional Specification Pitfalls
"
Failing to involve the whole team in its validation
"
Failing to provide enough detail
"
Providing too much detail
"
Creating an unrealistic design
"
Spending too much time updating the functional
specification
"
Failing to communicate changes effectively
"
Freezing the document too early

Be sure to involve the entire team in the validation of the functional
specification. Group validation will assist in capturing everyone’s needs and
developing a consensus among the project team.
Be sure to provide the appropriate level of detail. If the functional specification
is too broad or vague, the development team will lose valuable time filling in
the gaps in the functional specification instead of developing. A functional
specification, however, should not contain volumes of information: It should
contain all the needed detail while remaining concise. If large amounts of
information are required, summarize the information for the functional
specification and attach the details as an appendix.
Although the functional specification should be updated throughout the
development phase, you should be cautious not to spend too much time
updating the functional specification. After all, the goal of the project is to
deliver a solution that meets the business needs, not to deliver a document.
When changes in the functional specification are necessary, be sure to
communicate those changes to each of the groups involved so that there are no
surprises later in the project. Ensure that these changes are marked clearly so
that only the specified sections are addressed. In addition, exercise caution in
freezing the functional specification too early, because legitimate changes are
often better understood as the product reaches implementation.
Slide Objective
To describe some possible
pitfalls to avoid when
creating functional
specifications.
Lead-in
When creating the functional
specification, you should be

aware of a few potential
pitfalls.
442 Module 12: Introduction to Functional Specifications



!
!!
!

Functional Specification Validation
"
The Search for Consensus
"
Prototypes
"
Content Reviews
In this section
In this section


Although the functional specification is based on the outputs of the design
phases, all stakeholders should still validate it.
In this section, you will learn about the process of validating the functional
specification.
Slide Objective
To explain the purpose of
this section and what
students will learn in this
section.

Module 12: Introduction to Functional Specifications 443




The Search for Consensus
"
Successful projects require consensus of the design
"
Customers must agree that the current design meets
their needs
"
Project team members must agree that the design is
realistic given the constraints
"
Project team members must agree that the requirements
of the business and the users are met


For a project to be successful, it is important that the members of the team and
the customer agree on the proposed solution. The functional specification can
be used as a tool to help in building a consensus.
The customer should agree that the solution solves the business problem and
meets the business requirements.
Project team members must agree that the functional specification solves the
problem and can be implemented under the project constraints, such as schedule
or resources.
Finally, project team members should agree that the user and business needs are
met by the functional specification.
Slide Objective

To describe the importance
of consensus and how
validation can assist in
reaching a consensus.
Lead-in
A primary goal of the
functional specification is to
build consensus for the
design of the business
solution.
444 Module 12: Introduction to Functional Specifications



Prototypes
"
Validate the functional specification by:
$
Mitigating design risks
$
Generating feedback
$
Achieving consensus
"
Can take many forms
$
Storyboard, visual design, or visual specification
$
Proof of concept
$

Demo or snapshot


Prototyping is a technique used to validate the functional specification by
allowing the team and the customer to visualize different aspects of the
solution. Prototypes help clarify and refine the scope and user requirements, as
well as give examples of the user interface that will be built for the project.
Working application prototypes can also be used to provide proof that a
technology or design choice is valid. Some types of prototypes are listed in the
following table.
Type of prototype Purpose Cautions or tips

Storyboard Surface requirements
Understand user activities
Drive system functions
Focus on interface, not
functionality
Write with a language different
from the delivery language
Visual design or
visual specification
Specify visual interface Write with a language different
from the delivery language
Allocate time for quality coding, if
starting point for final system
Proof of concept Explore implementation
risks or unknowns
Use as an exploration of
implementation options
Place little emphasis on the visual

or interactive aspects
Demo or snapshot Convey status and vision
Enable usability testing
Convey high percentage of
functionality
Schedule demos to coincide with
milestones
Operational
prototype
Obtain feedback through
alpha and beta of the
system
Convey high percentage of
functionality

Slide Objective
To explain that prototypes
are a useful tool for
validating a design.
Lead-in
Prototypes can assist in
validating the functional
specification.
Module 12: Introduction to Functional Specifications 445




Content Review
"

Encourage everyone with a stake in the functional
specification to take part in the validation process
"
Involve a variety of people in making sure that audience
needs are met
"
Communicate what will be built
"
Provide a forum for negotiating
trade-offs and achieving
consensus


Reviewing allows everyone with a stake in the project to take part in validating
the functional specification. The easiest way to ensure that an individual or
group of individuals agrees with a specific item is to allow them to be involved
in validating and reviewing it.
By involving a variety of people with different viewpoints and goals, reviewing
brings together disparate perspectives to ensure that the functional specification
actually meets all the requirements of the application.
In addition, reviewing serves as a method of communicating what is going to be
built and ensuring that everyone understands the design.
Finally, reviewing provides a forum for negotiating and achieving a consensus
around the functional specification. This consensus is the goal at the end of the
functional specification. All those directly involved with the project should
concur that the functional specification accurately and adequately documents
their expectations of the product.

Conducting reviews is also a good way to ensure that each interested
party has actually read the functional specification.

Slide Objective
To explain the role that
content reviews play in
validating the functional
specification.
Lead-in
Content reviews of the
functional specification are
important for achieving and
maintaining a consensus.
Note
446 Module 12: Introduction to Functional Specifications



!
!!
!

Review
In this section
In this section
"
Guidelines
"
Review Questions
"
Looking Forward

Slide Objective
To reinforce module
objectives by reviewing key
points.
Lead-in
In this section, you will learn
some practical guidelines for
practicing the concepts of
this module, and you will
test yourself on your
understanding of those
concepts.
Module 12: Introduction to Functional Specifications 447




Guidelines
"
Understand the requirements of the business and user
"
Iterate often during creation to encourage feedback
"
Include mandated project requirements as explicit
design goals
"
Create prototypes to articulate what the solution will be
"

Identify and focus on the core feature set


The functional specification should clearly address the requirements of the
customer and user. It should convey the required information in such a way that
the project stakeholders can understand how the design solves the business
problem.
During the creation of the functional specification, the project team should
attempt to get feedback from project stakeholders as often as possible. You
should use the iterative nature of the design process to facilitate and encourage
feedback.
Translate mandated project variables into explicit design goals; in other words,
design with project constraints in mind. For example, if it has been mandated
that the project will use Windows
®
2000 Server as the only operating system,
then the team must design the project with that goal in mind. Be sure to include
a chart that translates mandated project variables into explicit design goals.
Use prototypes in the functional specification and the review process.
Prototypes are invaluable tools for conveying the final product and ensuring
that everyone understands the proposed solution and agrees that it solves the
business problem.
Finally, focus on the core feature set in the functional specification—do not
allow it to be buried in the details of the project. The core feature set identifies
high-priority features for the implementation team.
Slide Objective
To present some general
guidelines related to the
information in this module.
Lead-in

The following are some
general guidelines to
consider.
448 Module 12: Introduction to Functional Specifications



Review Questions
"
Describe the purpose and benefits of functional
specifications
"
Describe the contents of a functional specification
"
Describe the purpose and methods of validating a
functional specification


1. What is the purpose of the functional specification?
The purpose of the functional specification is to describe the solution
that is to be developed and to provide the details of the design that are
needed by the developers.


2. What is the basis of the functional specification?
The design process — including the conceptual, logical, and physical
design phases — provides the basis for the functional specification.


3. What are the primary supporting items for the functional specification?

Conceptual design provides future-state usage scenarios and models;
logical design provides the business object model and logical user
interface design; and physical design provides technology selections,
component specifications, and a deployment model.


4. Why is consensus important when approving the functional specification?
The functional specification describes the solution that is to be
developed. If a stakeholder does not agree with the functional
specification, that stakeholder will not agree that the developed solution
addresses the original business requirements.


Slide Objective
To reinforce module
objectives by reviewing key
points.
Lead-in
The review questions cover
some of the key concepts
taught in this module.
Module 12: Introduction to Functional Specifications 449




Looking Forward
Module 3: A Services-Based
Approach to Solution Design
Module 4: Business Solution

Conceptual Design
Module 5: Business Solution
Logical Design
Module 6: Beginning Physical
Design
Module 1: Course Overview
Module 2: Solution Design
Using the MSF
Module 7: Selecting Solution
Technologies
Module 8: Solution Design and
the Component Object Model
Module 9: Designing Solutions
with Microsoft Technologies
Module 10: Completing the
Physical Design
Module 11: Designing the
Presentation Layer
Module 12: Introduction to
Functional Specifications
Designing Business
Solutions
Design Courses
Experience
Implementation Courses
Certification Exams


In this course, you learned about the MSF Design Process by using the MSF
Process Model for Application Development and the MSF Application Model.

You learned about the three phases of the design process (conceptual, logical,
and physical) and how the functional specification provides the development
team with all the information necessary to start development.
If you would like to continue your education, you can take other design courses,
such as Course 1585: Gathering and Analyzing Business Requirements or
Course 1609: Designing Data Services and Data Models. Or you can continue
with any of the implementation courses offered by your local Microsoft
®

Certified Technical Education Center or Microsoft Authorized Academic
Training program.
Additionally, you can demonstrate your knowledge and skill by taking a
Microsoft certification exam.

For more information about Microsoft Official Curriculum courses or
Microsoft certification, visit or


Slide Objective
To provide a context in
which students can frame
what they have just learned
and foreshadow what they
will be learning.
Note
450 Module 12: Introduction to Functional Specifications



THIS PAGE INTENTIONALLY LEFT BLANK