Functional Specification Template

This document can be sensitive and should only be used for internal team planning and
communication.

Summary of Changes
Provide a high-level summary of the changes to this version of the document. .
No content changes from the original version has been done before relocating the doc in EDCS. Key
doc control element has been added in the first 2 pages of the template.

Required Reviewers (must approve content and changes)

http://ecm-link.cisco.com/ecm/view/objectId/090dcae18183c8a4/versionLabel/CURRENT

NOTE to Template Users: This page is for the purpose of Document

Control for the PLC Template. Please be sure to remove this page
when utilizing the template for your project.

Document

Xxxxx

Rev. x

Based on Template

EDCS-1155656 Rev.1

Cisco Systems, Inc.

11i Best Practices

Functional Specification Template

Functional Specification

Functional Specification

<Release>
<Business Flow/Track>

<Date>

2007 Cisco Systems, Inc. All rights reserved

Document Number: ERMOFS_XXXX

Based on Template: ERMOFS_0006 Rev1.0
Document Number: ERMOFS_XXXX
Based on Template: ERMOFS_0006 Rev1.0

Document Control
READ ME FIRST

Template Instructions

Template instructions and guidelines are included in this document. Please delete these
sections before submitting for approval.
At prompts delineated by angle brackets (for example, <project name>), please insert
appropriate information. If no information is to be added, please delete these prompts
before publication.
If a section is not applicable, do not remove the section. Instead note that it is not
applicable.

Change Record
Date

Author

Version

Change Reference

Reviewers
Date

Name

Organization

Role

If your project team has defined a document review process for this release, please include a link here.

Approval
Date

Name

Organization

2007 Cisco Systems, Inc. All rights reserved.

Role

Contents
Document .........................................................................................................................................................ii
Xxxxx Rev. x..................................................................................................................................................ii
Based on Template.............................................................................................................................................ii
EDCS-1155656 Rev.1........................................................................................................................................ii

Document Control........................................................................................................................................1
Change Record....................................................................................................................................................1
Reviewers............................................................................................................................................................1
Approval..............................................................................................................................................................1

Contents.......................................................................................................................................................2
Overview......................................................................................................................................................4
Business Requirement ID....................................................................................................................................4
Functional Requirement ID ................................................................................................................................4
Use Case #...........................................................................................................................................................4
BRD Name..........................................................................................................................................................4
Assumptions and Dependencies..........................................................................................................................4
References...........................................................................................................................................................4

Proposed Process.........................................................................................................................................5
Process Flow.......................................................................................................................................................5
Process Description.............................................................................................................................................5

Use Cases.....................................................................................................................................................6
<Use Case>.........................................................................................................................................................6
Actors................................................................................................................................................................. 6
Preconditions......................................................................................................................................................6
Primary Flow......................................................................................................................................................6
Alternative Flow.................................................................................................................................................7
Post-conditions...................................................................................................................................................7

Requirements...............................................................................................................................................8
Interface Requirements .......................................................................................................................................8
Access Requirements..........................................................................................................................................8
Constraint Requirements.....................................................................................................................................8
Reliability/Availability Requirements.................................................................................................................9
Operational Requirements...................................................................................................................................9
Configuration Requirements................................................................................................................................9
Personalization Requirements.............................................................................................................................9

Architecture................................................................................................................................................10
Interface Summary............................................................................................................................................10
2007 Cisco Systems, Inc. All rights reserved.

File Transfer Timings and Requests.................................................................................................................10

Interface Description........................................................................................................................................11
Data Flow Diagram .........................................................................................................................................11
Data Mapping and Translation Rules...............................................................................................................11
Data Cleansing ................................................................................................................................................12
Oracle Application Rules .................................................................................................................................12
Volume and Performance Considerations.........................................................................................................12
Error Handling..................................................................................................................................................12

User Interface Design................................................................................................................................13

Navigation Hierarchy........................................................................................................................................13
Screen/Form Inventory.....................................................................................................................................13
Description.......................................................................................................................................................13
Layout and Design............................................................................................................................................13
Screen/Form Usage..........................................................................................................................................13
Field Information..............................................................................................................................................14
Volume and Performance..................................................................................................................................14
Frequency of Use..............................................................................................................................................14
Error Handling...................................................................................................................................................14

Batch Processes and Programs...................................................................................................................15

Program Name...................................................................................................................................................15
Input Parameters...............................................................................................................................................15
Program Initiation Method...............................................................................................................................15
Volume and Performance.................................................................................................................................15
Frequency of Use..............................................................................................................................................15
Dependencies...................................................................................................................................................15
Error Handling..................................................................................................................................................15

Testing Recommendations.........................................................................................................................16
Implementation..........................................................................................................................................17
Security Requirements...............................................................................................................................18
SoX Considerations...................................................................................................................................19
Issues..........................................................................................................................................................20
Appendix A. Glossary................................................................................................................................21

2007 Cisco Systems, Inc. All rights reserved.

Overview
A functional specifications document is used to verify that predefined product requirements are
met by the resulting features and functionality. It focuses on the visual aspects, behavior, and
the interaction of the user with the designed user interface.
Describe the purpose, scope, and main audience of this document. Detail problem domain areas covered here and
exclusions, if any.
Identify the Level-3 process that these requirements will impact, and any target metrics.
Provide a high-level summary of the requirements associated with this functional specification.

Business
Functional
Requirement Requirement Use Case # BRD Name
ID
ID

Assumptions and Dependencies

Highlight any assumptions made, key dependencies, and prerequisites for this document. Note any requirements
that have not yet been validated, and an estimated date to complete the validation.

References
List any relevant document references, and include links to the documents.
Reference other related functional specifications describing project components such as interfaces, conversions,
workflows (required, if applicable), reports, and programs.
Include gap documentation, if any.
Include relevant research topics.
List related application configuration documents.

2007 Cisco Systems, Inc. All rights reserved.

Proposed Process
Describe the proposed to be process briefly.

Process Flow
Display or provide a reference to the to be process flow diagram.
The flow diagram should include both user and system interactions and should be at a deeper level than
than found in the BRD.
If referencing an external document, include a link to the document

Process Description
This section is optional.
Describe the process to be implemented. If a process flow narrative document was created during prototyping,
provide a reference to it.

2007 Cisco Systems, Inc. All rights reserved.

Use Cases
Use the table format below to list related use cases. In the next section, describe each individual use case on this
list.
Case Number

Unique reference number for the use

case to indicate levels of
functionality

Name

Name of the use

case

Description

Purpose and functionality of the use case

<Use Case>
Describe the function of this use case briefly. This section provides an important context for the reader. In
addition, the use case titles and descriptions can be extracted to provide a high-level overview of the entire use
case inventory. Please note there are no assumptions in a use case.

Actors
List the actors that interface with the system in this use case. Actors are entities that participate in the use case and
can be people, software, hardware, data stores, etc. For example, customer, internal employee, external employee,
LDAP system, etc. Identifying actors helps determine the boundaries of the system that will be built. It also helps
the developer, because actors are objects that later become classes in object-oriented programs.

Preconditions
Describe the state of the system before this use case starts. For example, a valid use is logged in to the system.

Primary Flow
Provide a detailed, step-by-step description of the flow of events in this use case, including screen shots whenever
possible. Steps should follow the flow numbering sequence from the L3 Process diagram and each step should
relate back to the flow diagram via the step number. Consider the following:
Write in complete sentences, using active verbs. Short, choppy phrases are difficult to read and may cause
confusion.
Describe the actions the actor performs and the interaction the actor has with the system.
Include details on error-checking and handling, so the developer can then plan for this in the code.
Include details on message flows between systems as well as between the system and actors.
Focus on the main scenario of a use case. In other words, focus on what is most likely to happen. Alternative
paths or branch-offs should be detailed in the primary flow only if they are not overly complex. If they are very
detailed or involve many actions and messages, it may be better to include them in a separate section or use case.

2007 Cisco Systems, Inc. All rights reserved.

Alternative Flow
This section is optional.
This section is similar to the primary event flow, but it details what happens when there is a large deviation from
the basic path. For example, describe what happens if the user has some sort of special entitlement.
In general, it is best to keep simple, alternate detail in the primary flow, because it is difficult to jump back and
forth between the primary and alternative flows.

Post-conditions
Describe the state of the system after this use case ends. For example, after a successful login, the main menu is
displayed. Provide screen shots whenever possible.

2007 Cisco Systems, Inc. All rights reserved.

Requirements
As an initiative moves from idea toward Execute Commit, the business and IT requirements which drive it should
be made very clear. Requirements may be stated at a high level for Concept Commit, and must be thoroughly
documented prior to Execute Commit. Presently available solution capabilities may or may not meet all the stated
requirements. Indicate which requirements are and are not being addressed by this initiative.

Interface Requirements
Identify all required interfaces with anything external to this solution including hardware, software, and
users. Include:

Required logical interfaces such as communications media, protocols and interfaces, APIs,
messaging systems, etc.

Software dependencies, installation and provisioning methods including user interfaces, backwards
compatibility of interfaces, products, database schemas, etc.

Upgrade requirements, compatibility issues, integration with existing frameworks and solutions, etc.

Environmental requirements: electrical, physical, rack space, ventilation, air conditioning, extreme
environmental conditions, etc.

Access Requirements
Identify which end users should have access to this new functionality. This is important to ensure that sensitive
data is only viewed by the proper end user.
Examples: Onboard Contingent Worker is accessible to all regular Cisco employees, or Onboard Contingent
Worker Administration is accessible only to members of the Convert Operations Team.
Also list the security level for each new functionality:

Confidential Information represents most information created or used within Cisco including most
documents and email. Any Cisco-badged personnel with a business need can create and gain access to
Cisco Confidential information.

Highly Confidential Information includes more sensitive information that should be kept from the
majority of Cisco-badged personnel. This includes security, personnel, financial and other particularly
sensitive information.

Restricted REDISTRIBUTION PROHIBITED: Information is the most sensitive information to Cisco.

It is generally only available to a very limited number of Cisco-badged personnel and has the strongest
protections on its storage and distribution. This includes mergers and acquisition information, global
financial information, investigations and similar information.

Constraint Requirements
Identify valid constraints on solution functionality, architecture and design. Include:

Compliance. (For example, is our use of encryption subject to regulation in certain countries or
locales? Is the application governed by S-Ox controls? Is our use of voice over IP technologies

2007 Cisco Systems, Inc. All rights reserved.

restricted? Are we prohibited from carrying certain types of traffic between two countries?)

Legal requirements, to avoid breach of law or contract, avert tort risk, etc.

Limitations on architecture and design such as size, power consumption, programming language,
processor type, existing software to be used or modified.

Internationalization: Foreign language requirements, special needs for transportation, customs, etc.

Reliability/Availability Requirements
Describe requirements for availability, redundancy, failure resilience, guaranteed message delivery,
business or service continuity, and disaster recovery.

Operational Requirements
Serviceability: Impact on servicing and support. This includes physical access, diagnostic capabilities,
automated provisioning, remote monitoring, expected maintenance, ability to upgrade software, etc. What
operational groups are involved? What SLA is expected for this solution? What impact on other SLAs
might this solution have; what SLA risks should be mitigated?

Configuration Requirements
Mandatory section for HRIT. Oracle-based solutions only. Provide a brief description of the configuration
required, such as adding tables or fields. Also provide the Remedy Alliance case number you created with the
detailed configuration requirements.
Example: The Configuration team is responsible for creating new tables, fields, and so on before engineering can
begin development.

Personalization Requirements
Mandatory section for HRIT. Oracle-based solutions only. List all changes to the look-and-feel of the user
interface.
Example: The responsibility of the Personalization team is to modify code/fields that exist within the pages below
a menu item. For example, if a new function (menu item) called Onboard Contingent Worker will be available
in the Employee Service page in HRMS, the Security team is responsible for creating the menu item, and the
Personalization team is responsible for modifying the code/fields that exist within that menu item and any
instructional text that appears within those pages.

2007 Cisco Systems, Inc. All rights reserved.

Architecture
Provide a high-level description of the project architecture, including individual components, their relationships,
and any interfaces with other hardware or software. Include an architecture overview diagram, if one is available.

Interface Summary
Provide a summary of interfaces and target system characteristics. This section can be populated with the contents
of the Interface Summary documents produced in the prototype phase. A sample summary table format is
provided below.
Interface Characteristics
Name

Value Set

Description

Value

System Characteristics
Name

Value Set

Description

Value

File Transfer Timings and Requests

List all information regarding backend programs and/or file transfer schedules:
Backend program name or file name
Name of external vendor to whom the file will be sent
Run schedule: Daily, weekly, monthly, adhoc and the time of day in PST
Describe how the file or program will be executed: $U, oracle scheduler, or adhoc request
Describe how the file will be transferred: IFWK, web services, or other means
Describe the input parameters for running this backend program (work with engineering team for input
parameters)

2007 Cisco Systems, Inc. All rights reserved.

10

Example: The HRIT HRMS application sends data to vendors such as Years of Service and Relocation
information. The information about these files should be documented here to ensure that all file transfers are
accounted for.

Interface Description
Use this section to describe the features of the interfaces in detail.

Data Flow Diagram

This diagram should depict all processes, input files, output files, and tables that will be a part of the interface.

Data Mapping and Translation Rules

Include a reference to the Interface Data Map (use the RMO interface data map template).

2007 Cisco Systems, Inc. All rights reserved.

11

Data Cleansing
Describe any assumed or required data-scrubbing activities.
Task

Owner

Describe the data cleansing task to be

performed.

Owner of the
task

Due Date

Date task should be

completed

Oracle Application Rules

Enter rules specific to Oracle Applications as pertaining to interface tables or APIs.

Volume and Performance Considerations

List any known volume and performance considerations.

Error Handling
List the possible errors that could be encountered in this interface.
Error

Describe instances where this

potential error may occur.

Cause

State the possible cause/reason for

the error.

2007 Cisco Systems, Inc. All rights reserved.

Solution Strategy

State the proposed

solution.

12

User Interface Design

In this section, describe the look-and-feel of the application from a functional perspective. Focus on how endusers will interact with the application to accomplish tasks.

Navigation Hierarchy
Illustrate the screen flow and navigation hierarchy using a site map diagram.

Screen/Form Inventory
Screen/Form #

Unique reference number for each

screen/form

Name

Descriptive name for screen/form that uniquely identifies it

Description
List the screen/form specifications in this section, or provide a reference to an external specifications document.
Provide a brief description of the usage and purpose of the screen/form, including links to other screens/forms for
the project. Also, provide a description of user interface commands and parameters.

Layout and Design

Describe the screen/form layout and design. You can create a mock-up using tools such as PowerPoint and
HTML. If available, you can also use Oracle Forms Designer or a Web-authoring program such as Dreamweaver.

Screen/Form Usage
Describe the behavior of the user interface from the clients perspective. How does the user move through the
features and functionality? For example, describe what happens when the user clicks on a screen element, such as
an icon or a button.

2007 Cisco Systems, Inc. All rights reserved.

13

Field Information
Provide details in the appropriate columns for each field that appears on the screen/form.
Name

Displa
y
name
of the
field

Security
Category

Table/
Column

Update
(Y/N)

Query
(Y/N)

Reqd
(Y/N)

Entry
(Y/N)

Derived
(Y/N)

Data
Type

Display
the
security
category
of the
field. i.e.
Confident
ial,
Highly
Confident
ial, and
Restricted

This
column
is
optional
.
Oracle
table
and
column
name
correspo
nding to
the
field.
If
known,
specify
if
custom
or
Flexfiel
d.

On
retrievin
g an
existing
record,
can this
field be
altered?

Is this
field
requir
ed as
search
criteri
a
when
the
form
is in
query
mode
?

Is this
field
mand
atory
in
entry
mode
?

Can
this
field
be
entere
d on
the
creati
on of
a new
record
?

Is this
field
derived
from a
calculati
on or
another
source?

Text,
num
ber,
date,
flag,
etc.

Length

LOV

List
any
and all
restrict
ions
such as
minim
um,
maxim
um
field
length
of field

Desc
ribe
how
dropdown
lists
are
popu
lated,
if
appli
cable
.

Validation

Sequence

Custo
m field
validati
ons,
formatt
ing,
etc.

List the
order in
which the
list of
values
should be
added, if
applicabl
e

Volume and Performance

List any known volume and performance considerations.

Frequency of Use
Define how often this screen/form will this be used in query and update modes.

Error Handling
List the possible errors that could be encountered in this screen/form.
Error

Screen/Form

2007 Cisco Systems, Inc. All rights reserved.

Cause

Error Message

Solution Strategy

14

Batch Processes and Programs

Program Name
Describe the features of the batch process or program in detail.

Input Parameters
Provide input parameter details using the table format below.
Existing programsList only the parameters that have been modified.
New programsList all parameters.
Name

Required
(y/n)

Value Set

Parameter
name

Enter a set of values,

if applicable.

Is this parameter
required?

Comments

Additional comments

Program Initiation Method

Enter the process that initiates this new functionality.

Volume and Performance

List any known volume and performance considerations.

Frequency of Use
Indicate how often the program is executed.

Dependencies
List any known dependencies for this program.

Error Handling
List the possible errors that could be encountered in this program.
Error

Cause

2007 Cisco Systems, Inc. All rights reserved.

Solution Strategy

15

Testing Recommendations
Are any special testing capabilities needed? Reference any of the above requirements that are untestable or
difficult to test, with a description of how this risk factor is being mitigated.
NOTE: This is not a replacement of test cases or scenarios from the QA or Business teams.

2007 Cisco Systems, Inc. All rights reserved.

16

Implementation
This section is optional.
Highlight implementation considerations, if any, including any phased implementation issues relating to QTC or
external system changes.

2007 Cisco Systems, Inc. All rights reserved.

17

Security Requirements
Describe required system security, levels of user security, detection and recovery of security breaches, audit
trails, mechanical lockouts, etc.
Consider these questions:

What security risks do we face in implementing this architecture?

How does this compare against existing security practices?

How does this compare against industry-accepted best practices?

What can be done to mitigate the security risks?

What trade-offs are acceptable for or against security?

This section will be reviewed by InfoSec and must be approved the Security Domain Architect
before the final document is released.

2007 Cisco Systems, Inc. All rights reserved.

18

SoX Considerations
Refer to the Initial SoX Impact Questionnaire to ensure the business has captured any and all SoX impacts.
SoX information can be found here: http://wwwin.cisco.com/cisco/sox/readiness_id_assess.shtml.

2007 Cisco Systems, Inc. All rights reserved.

19

Issues
This section is optional.
List known issues related to this project. If issues need to be escalated, enter the issue in Test Director and specify
the issue ID below.
Issue ID

Description

Resolution

2007 Cisco Systems, Inc. All rights reserved.

Responsibility

Target Date

Status

20

Appendix A. Glossary
Use this table to define any terms that would not be defined in the Global Glossary for this release.
Term

2007 Cisco Systems, Inc. All rights reserved.

Definition

21