Functional Specifications
Page 6 of 7
Functional Specification
Owners and List of Contacts
Name Email Phone Role
John Doe
[email protected] 303-894-7315 W Project Manager
303-471-8344 H Development Lead
303-203-5567 Pgr
Joe Tester System Test Lead
Jane ProdSupport Production Support Mgr
Joe UserMgr User Test Lead
Joe Developer Developer – Presentation
Tier
Jane Developer Developer – Business Tier
Joe DBA Data Base Administrator
Joe Tester Tester
Jane Tester Tester
Joe Customer Department VP
Jane Customer Department Mgr
Josey Customer Product Support
Signoffs
Phase Name Date Signature
Functional John Doe, PM/DM xx/xx/xx
Specifications
Joe Tester, System Test
Lead
Jane ProdSupport,
Production Support Mgr
Joe User Mgr, UM
Joe Customer, Customer
Revision History
Date Reason for change(s) Author(s)
09/15/1988 First Draft John Doe
Table of Contents
Functional Specification 1
Owners and List of Contacts 1
Signoffs 1
Revision History 1
1. Summary 3
2. Project Goals, Justification, and Success Criteria 3
2.1 Project Goals 3
2.2 Justification 3
2.3 Success Criteria 3
3. Features 3
3.1 Feature 1 3
3.2 Feature 2, etc. 3
4. Security Requirements 3
5. Data Conversion Requirements 3
6. Performance and Response Time Requirements 3
7. Platform Dependent and Installation Requirements 3
8. Localization Requirements 3
9. Parallel Testing Requirements 3
10. Cross System Interface Requirements 4
11. Data Archival, Backup and Recovery Requirements 4
12. Reporting Requirements 4
13. Project Flexibility Matrix 5
14. Stack Ranking of Features 6
15. Roles and Responsibilities 6
1. Summary
This document describes the features and timeframe desired for [ProductName]…
2. Project Goals, Justification, and Success Criteria
2.1 Project Goals
Explain the goals of the project here…
2.2 Justification
Explain why the project is needed. List revenue impact or cost savings information.
2.3 Success Criteria
List the success criteria for the project. Once the project is complete, it will be measured back to
the criteria listed here to determine if the project was successful.
3. Features
3.1 Feature 1
Explain exactly what the feature is to perform in Use Case format. List any constraints, actors,
security implications, etc.
3.2 Feature 2, etc.
4. Security Requirements
Explain the security requirements of the system. If needed, assign user groups and define what those
groups have access to.
5. Data Conversion Requirements
Explain any requirements in which we must convert data to import into the system. Detail the mapping
needed from their system to the new system.
6. Performance and Response Time Requirements
Explain how many concurrent users will be using the system and expected response time.
7. Platform Dependent and Installation Requirements
Explain what platforms the client presentation layer must run on (Windows 95, 98, NT 4, 5, etc) and
describe the installation process.
8. Localization Requirements
Explain any requirements that are specific to localization (European date and postal code format, etc.)
9. Parallel Testing Requirements
Explain the areas of the system (if any) that must be run parallel to an existing production system and
compared for consistency.
10. Cross System Interface Requirements
Explain the systems this system interact with and detail any requirements for testing with that system to
ensure integrity.
11. Data Archival, Backup and Recovery Requirements
Explain the purge, archival, backup and recovery requirements of the system.
12. Reporting Requirements
Describe the reports (if any) are required for the system. Are they to be online or run in batch and must
they be exportable to other formats such as MS Word, MS Excel or HTML.
13. Project Flexibility Matrix
For a project to succeed, there are 3 variables that affect how quickly a project can be completed:
Resources, Schedule and Feature (see diagram below). One of the sides of the triangle must always
be flexible to achieve success. For example, if the client has a fixed number of resources (people that
work on the project) and their schedule has been set in stone, the feature set must be flexible. This
means that they must be flexible to drop some features to make the pre-determined date with that number
of resources.
Project Trade-off Matrix
Inflexible Flexible
Resources(Cost)
Ship Date
Features
Working together, the team and customer place a check mark in the appropriate column for each of the
project variables. The columns are defined as:
· Inflexible. Mark 2 items that are inflexible. For example, if the cost and ship date are set in
stone, make Resources (Cost) and Ship Date as Inflexible. Only 2 items can be inflexible, the last
item must be flexible.
· Flexible. Mark one item as flexible. For example, if you are flexible with the features that are
included in the project, mark Features as Flexible.
A team should use the project trade-off matrix as a reference when making decisions. The matrix is not
intended to show absolute priorities; it is merely a tool to facilitate communication and understanding.
Most important for the project team is that the matrix shows areas in which the customer is willing to
compromise. Make sure that no row or column in the project trade-off matrix has more than one check
mark. Any other combination poses serious risk to the project and must be accounted for explicitly in the
risk management plan.
In order for a team to be successful, at least one check mark must be in the “flexible” column. This means
that the team owns one side of the triangle (that iws, owns at least one variable) so that the team is
empowered to manage change and risk, and is therefore positioned to achieve success instead of failure.
14. Stack Ranking of Features
To ensure that items are worked on in order of importance, stack rank the features with the lowest stack
rank being most important and the highest stack rank being least important. This will allow the
development team to focus on the important items and to manage risk.
Ranking Req # Feature
1 1.1 Display MSL Listings (very important)
… … …
… … …
… … …
99 1.2 Update agent information (not very important)
15. Roles and Responsibilities
Below are the roles and responsibilities for each phase of the life cycle. Smaller projects may not be
broken out to this level of detail.
Life Cycle Role Responsibility
Planning Setup hardware for Development Development Team
Functional Specs Development Team / Client PM
Detailed Design Development Team
Test Design System Test Lead
Development Project Plan Development Team
Test Project Plan and Budget System Test Lead
Overall Project Plan Project Manager (PM)
Construction Coding Development Team
Unit Testing Development Team
System Test - Test Cases System Test Team
User Test – User Test Lead User Test Team
User Test - Test Cases User Test Team
Setup hardware for System TestingSystem Test Team
System Testing Migration of code/database from Development Team
Development to System Test
Populate test database for System Development Team
Test
System Testing System Test Team
Bug Tracking / Triage System Test Lead, Development Manager, PM
Drops for reiteration of fixes Development Team
User Acceptance Migration of code from System Development Team
Test (UAT) Test to UAT
Populate test database for UAT Development Team
UAT Testing User Test Team
Bug Tracking / Triage System Test Lead, DM, PM, User Test Lead
Drops for reiteration of fixes (must Development Team
go back through System Test)
Production Migration of code from UAT to Development Team
Production
_____________________________________________________________________________
Developed by Pragmatic Software Co., Inc. http://www.PragmaticSW.com
