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

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: Beginning Physic

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: 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

Functional Specification

Basics

Review

Functional SpecificationValidation

Activity 12.1: Risk of No Functional Specification

Functional Specification

Creation

Module 12:

Introduction to Functional Specifications

! Overview

" Functional Specification Basics

" Activity 12.1: Risk of No Functional Specification

" Functional Specification Creation

" Functional Specification Validation

" Review

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

! Functional Specification Basics

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

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

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

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

The functional specification

must be allowed to change

and grow as the project

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

sometimes seen as process

overhead, but there are

many benefits to having a

one

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

! Functional Specification Creation

" Contents of the Functional Specification

" Design Process Output

" Forms of the Functional Specification

" Factors That Determine the Form

" Functional Specification Pitfalls

Contents of the Functional Specification

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

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

Forms of the Functional Specification

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

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

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