Specification Template

Technical Specifications
& Requirements
Contents
Functional Specifications .............................................................................................................................................. x
Functional Description ............................................................................................................................................... x
Functional Specification ............................................................................................................................................ x
Issues ........................................................................................................................................................................ x
Assumptions .............................................................................................................................................................. x
Data Security ............................................................................................................................................................. x
Functional Specification Approval ............................................................................................................................. x
Technical Specifications ............................................................................................................................................... x
Technical Description ................................................................................................................................................ x
Program Logic ........................................................................................................................................................... x
Program/Process Modification Details ...................................................................................................................... x
Development And Impact Considerations ................................................................................................................. x
Batch Specifications ...................................................................................................................................................... x
Batch Program Definition .......................................................................................................................................... x
Input Flat File Format (Field Mapping) ...................................................................................................................... x
Output Flat File Format (Record/Field Mapping Where The Data Exists) ................................................................ x
Paste Sample Report Here ....................................................................................................................................... x
Online Specifications .................................................................................................................................................... x
Page Properties ......................................................................................................................................................... x
Paste Sample Page Here .......................................................................................................................................... x
Component Properties .............................................................................................................................................. x
Menu Properties ........................................................................................................................................................ x
Portal Properties ........................................................................................................................................................ x
Object Specifications .................................................................................................................................................... x
Field Properties ......................................................................................................................................................... x
Table Field Edits ........................................................................................................................................................ x
Record/View Properties ............................................................................................................................................. x
Peoplecode................................................................................................................................................................ x
Queries ...................................................................................................................................................................... x
Component Interface Properties ............................................................................................................................... x
File Layout Properties ............................................................................................................................................... x
File Parser ................................................................................................................................................................. x
Message Catalog ...................................................................................................................................................... x
Security...................................................................................................................................................................... x
Integration Broker Specifications .................................................................................................................................. x
Application Message ................................................................................................................................................. x
Application Messaging Channel ................................................................................................................................ x
Application Messaging Node ..................................................................................................................................... x
Web Service .............................................................................................................................................................. x
Inventory of Objects ...................................................................................................................................................... x
Non-Functional Requirements…………………………………………………………………………………………………x
Page 1 of 20
Document1
12/23/2014
Technical Specifications
& Requirements
Functional Specifications
Requestor and/or the Functional Lead/Consultant should complete the Functional Description section, and as much of the Technical
Specification as possible/practical; using only those sections that pertain to this particular request. Once the functional specification is complete,
there should be a functional spec review, including at a minimum the requestor/end user, functional spec author, and the assigned tech spec
writer. If the requestor/end user is in agreement that the functional spec is complete and accurate, they should sign-off. At that point the tech
spec writer will complete a technical specification, consulting with the functional spec writer as needed.}
Replace all blue instructions with details about the target project.
FUNCTIONAL DESCRIPTION
General Description, Background and Purpose of this Customization/Modification:
Enter a description of the general functionality and goal.
Example:
The University utilizes position data to create, review and approve position related information in order to assign employees to them. There are
certain pages, fields and tables that are not delivered by People Soft.
This design addresses the modifications/customizations that will be made to the Position Data to meet University’s business and processing
needs.
Business Functional Requirements:
Write a narrative describing the proposed business function process flow and how it will work within the revised solution.
Main Features of Proposed Solution / Description of the Modification
Create a bulleted list of all features to be created and implemented. List each feature separately and avoid buzzwords or acronyms.
Example:

Remove all custom field edits

Move custom fields for Closure Long and Closure Short to the Position child table

Move custom field for Appointment Length to the Position child table

Move custom Comments field to the Position child table

Retro-fit custom Supervision/Essential Duties fields and pages on Position child table

Retro-fit custom Education/Experience fields and pages on Position child table
Definition of Terms
Define terms associated with the existing and new process. Include acronyms and buzzwords.
User Process
Flowchart the process using standard flows charting symbols.







Rectangle = Process
Diamond = Decision
Oval = Start/End
Rectangle with curve bottom = Document
Rectangle with parallel curved sides = External Data
Rhombus = Data
Cylinder = Database
Page 2 of 20
Document1
12/23/2014
Technical Specifications
& Requirements
FUNCTIONAL SPECIFICATION
Detailed Functional Specification of this Customization/Modification:
Include any/all appropriate screen prints or mock-ups. Add specific and detailed instructions. This portions is typically the major part of this
document.
Example:
A.
Description Page – POSITION_DATA1:
This page contains data related to Position Information, Job Information, Work Location and Salary Plan Information.
Under Group Box Label - Position Information:
No modifications will be made to this group. This will be used as delivered in v9.2.
Page 3 of 20
Document1
12/23/2014
Technical Specifications
& Requirements
Under Group Box Label – Job Information:
1.
Add Comments link - DERIVED_DUMMY. DUMMY_FIELD (POSITION_COMNTS_OS secondary page). This will be retrofitted from v8.9.
The following custom fields will be added to this subpage - POSITION_COMNTS_OS
Under Group Box Label - Comments:
2.
3.
POSITION_DATA.DESCR254
Add Supervision/Essential Duties link - ABS_BEGIN_DT_VW (POSITION_SUPR_OS secondary page). This will be retrofitted from v8.9.
The following custom fields will be added to this subpage - POSITION_SUPR_OS.
Under Group Box Label - Supervises:
4.
Mgrs/Dirs field - OS_POSN_DTA_CD1.OS_SUPV_MGRDIR
5.
Non-Supervisory Prof Staff field - OS_POSN_DTA_CD1.OS_SUPV_NON
6.
Students field - OS_POSN_DTA_CD1.OS_SUPV_STUDTS
7.
Supervisors field - OS_POSN_DTA_CD1.OS_SUPV_SUPER
ISSUES
Enter details about issues or risks associated with this system and the proposed solution.
Example:
Page 4 of 20
Document1
12/23/2014
Technical Specifications
& Requirements
With the custom position approvals being removed from PeopleSoft, there may be a need for auditing that ensures data entered into Position is
the same that was approved in HRA. We also need to define the future business process for entering data into Position.
ASSUMPTIONS
List all assumptions related to this process.
Example:
Position approvals will take place in HRA. Med Center positions must automatically be approved; Med Center does not use HRA.
DATA SECURITY
List all security roles and document their access levels for this system.
Page 5 of 20
Document1
12/23/2014
Technical Specifications
& Requirements
FUNCTIONAL SPECIFICATION APPROVAL
Requestor:
Approval date:
The assigned Technical Lead should review information provided by the functional spec writer and develop a detailed technical specification.
Upon completion a review should be conducted with, at a minimum, the functional spec writer and the assigned developer. The end
user/requestor may be included. The functional spec writer or end user should sign-off if the delivered tech spec. covers the functional
requirements.
Page 6 of 20
Document1
12/23/2014
Technical Specifications
& Requirements
Technical Specifications
Technical Lead should complete the Technical Description and Program Logic Sections giving a description that addresses the intentions of the
functionality, recommended approach as well as pseudo code and/or flow charts to document the required changes. This is intended to give
guidance as to how the developer approaches a solution. Effort should be made to Separate the logic for the online portion as from the batch
portion of the changes if both will be addressed in this document.
Developer will complete the Program/Process Modification Details section since references will be to the actual record, page, component, Etc.
names related to the change.
TECHNICAL DESCRIPTION
Overall Technical Description of the Customizations/Modifications:
Describe the intentions of the functionality as well as recommended approach. Technically high level indicating the preferred development tools
to use.
PROGRAM LOGIC
Overall flow and logic of the Customizations/Modifications:
Use pseudo code and/or flow charts to document the functionality and required changes.
PROGRAM/PROCESS MODIFICATION DETAILS
Development Details of the Customizations/Modifications:
First indicate the SIR number then a description of the changes made to satisfy the requirements of the SIR number.
Page 7 of 20
Document1
12/23/2014
Technical Specifications
& Requirements
DEVELOPMENT AND IMPACT CONSIDERATIONS
SIR Number:
(Include Impact such as the type of restricted data HIPPA, FERPA, SSN, BuckID or Functional change that needs to be communicated.)
External Integration Impact
Internal Modules Impacted
AutoSys impact
Customer Readiness impact
Sensitive or Restricted Output
Data Warehouse Impact
Database impact
Identity Management
Security:
Other(Specify)
SIR Number:
(Include Impact such as the type of restricted data HIPPA, FERPA, SSN, BuckID or Functional change that needs to be communicated.)
External Integration Impact
Internal Modules Impacted
AutoSys impact
Customer Readiness impact
Sensitive or Restricted Output
Data Warehouse Impact
Database impact
Identity Management
Security:
Other(Specify)
Batch Specifications
BATCH PROGRAM DEFINITION
Batch Program Name:
Type: (Application Engine,
SQR, nVision, Cobol, Crystal,
etc.):
Integration Considerations
Any details beyond the
purpose or logic that is
specific to this program.
INPUT FLAT FILE FORMAT (FIELD MAPPING)
SOURCE SYSTEM:
FILE RECORD LENGTH:
FILE NAME:
Descriptive Name
(Ex: Hire Date)
Field
Type
Field
Length
Start
Position
End
Position
Record
Name
Field
Name
Notes
OUTPUT FLAT FILE FORMAT (RECORD/FIELD MAPPING WHERE THE DATA EXISTS)
FILE NAME:
TARGET SYSTEM:
FILE RECORD LENGTH:
Page 8 of 20
Document1
12/23/2014
Technical Specifications
& Requirements
Descriptive Name
(Ex: Hire Date)
Field
Type
Field
Length
Start
Position
End
Position
Record
Name
Field
Name
Notes
REPORT PROPERTIES
Report Name:
SQR, XML Report, Crystal
or Other (Specify):
Elements on Report:
Sort Sequence:
Totals by:
Frequency:
Sensitive Information:
PASTE SAMPLE REPORT HERE
PROCESS DEFINITION PROPERTIES
Process Definition Name:
Process Type:
Component:
Description:
JOB DEFINITION PROPERTIES
Job Name:
Component(s):
List of Processes
Description:
Online Specifications
PAGE PROPERTIES
Page Name:
Description:
PASTE SAMPLE PAGE HERE
COMPONENT PROPERTIES
Component Name:
Page 9 of 20
Document1
12/23/2014
Technical Specifications
& Requirements
Description:
Search Record:
Pages on Component:
MENU PROPERTIES
Menu Name:
Bar Item Label:
Menu Item Label:
Menu Item Type:
PORTAL PROPERTIES
Portal Registry:
Folder Path:
Folder Name:
Content
references:
Nodes
Object Specifications
FIELD PROPERTIES
Field Name
Field Type
Field Format
Field Length
TABLE FIELD EDITS
Field Name
XLAT Code
Active/Inactive
Effective Date
Long Description
Short Description
Note: Until we have a versioning software in place, use “Record/View Properties” section for each Table or View
being referenced. You can paste the details below the section if necessary. If the details are not required, you
should list all tables and views in a single section.
RECORD/VIEW PROPERTIES
Record Name
Record
Type:
Description: (Data and how it is used)
Table Growth and
Size considerations
PEOPLECODE
Object
Type
Page 10 of 20
Object Name
Field Name
PeopleCode
Event
Document1
PeopleCode Logic Description
12/23/2014
Technical Specifications
& Requirements
Record
Page
Component
QUERIES
Query Name:
Description:
COMPONENT INTERFACE PROPERTIES
Component Interface Name:
Source Component:
Permission List(s):
Standard Methods:
(Cancel, Create, Find,
Get, Save)
FILE LAYOUT PROPERTIES
File Layout Name:
Description
Type
Format
Definition Delimiter
FILE PARSER
File Parsing Definition:
Description
MESSAGE CATALOG
Set Nbr
Message Nbr
Severity
Actual Message
SECURITY
Permission List(s):
Menu:
Component:
Display Only? (Y/N)
Actions:
Page 11 of 20
Document1
12/23/2014
Technical Specifications
& Requirements
Integration Broker Specifications
APPLICATION MESSAGE
App Message Name:
Description
Message Channel
Default Version
APPLICATION MESSAGING CHANNEL
App Message Channel Name:
Description
Messages in Channel
Publish Message Nodes
Subscribe Message Nodes
On-Route Publication Logic
On-Route Subscription Logic
APPLICATION MESSAGING NODE
App Message Node Name:
Description
Local or Remote
URL(If Remote)
WEB SERVICE
Web Service Name:
Overview:
Web Service Type:
WSDL:
Input:
Output:
Service Operation Name:
Handler Name:
Routing Name:
Node Name:
Generate SOAP Template Service Name:
Message Schema Builder Message Name:
Message Schema Builder Message Name:
Page 12 of 20
Document1
12/23/2014
Technical Specifications
& Requirements
Inventory of Objects
Impact Type
(New, Mod, Delete)
Object Type (Component,
Field, Page, Menu,
PeopleCode, Security,
Records, View/Query,
Other)
Object Name
SIR Number:
Page 13 of 20
Document1
12/23/2014
Technical Specifications
& Requirements
Click the ¶ button on the HOME tab of the MS Word Toolbar to see additional, hidden text guidelines for
completing this document.
1
2
PROJECT INFORMATION
Project Name:
Project ID:
Business Sponsor:
Primary IT Sponsor:
PMO Project Manager:
Document Author:
Date Created:
Date Baselined:
DELIVERABLE INFORMATION
Project Phase:
PLAN; Requirements Analysis and Definition
Deliverable Name:
Non-Functional Requirements (NFR) Document
Deliverable Description:
3
This deliverable confirms that, through a collaborative process that engaged all relevant stakeholders,
non-functional project requirements have been identified, documented and approved by the relevant
teams and are now baselined.*
* A baseline is achieved when a deliverable has been formally reviewed and agreed upon and
thereafter serves as the basis for further development. Baselines may only be changed through formal
change control procedures.
NON-FUNCTIONAL REQUIREMENTS (NFRS)
Each NFR shall be assigned a project-unique number to support testing and traceability. Each NFR shall be stated
in such a way that an objective test can be defined for it (i.e., start with the end in mind). The degree of detail to be
provided shall be guided by the following rule: Include those characteristics that are conditions for acceptance of
the IT solution. If information requested below exists in another document, reference the document in the section
below and append a copy of the referenced document to this document. If there are no requirements in a given
section, enter N/A.
The following sections in this document are intended to provoke consideration, questions and follow-up
during the Requirements Analysis and Definition activities of the project. Not all sections will be required
for all projects nor is this list intended to be all-inclusive.
Data Requirements
This section identifies data
elements and logical data
groupings that will be stored and
processed by the software.
Include sensitivity of data. This
section may be supported by a
data model. An accompanying
data dictionary, if available, should
be included as an attachment to
this document.
Page 14 of 20
<Project #>-DR-1.
<Project #>-DR-2.
Etc.
Document1
12/23/2014
Technical Specifications
& Requirements
Adaptation Requirements
This section identifies the system
requirements, if any,
concerning installation-dependent
data to be provided by the solution
(e.g., state tax codes, state
employment laws, menus and
pricing, etc.)
<Project #>-AR-1.
<Project #>-AR-2.
Etc.
Security and Privacy
Requirements
This section identifies the system
requirements, if any, concerned
with maintaining security and
privacy and the criteria that must
be met for security/privacy
certification/ accreditation. Include
in this section any requirements
related to audit trails and
authentication.
<Project #>-SP-1.
<Project #>-SP-2.
Etc.
Audit Requirements
This section identifies the system
requirements, if any, concerned
with auditability to show what has
happened, who did it, and when
(audit trail, transaction changes,
before/after pictures, and so on);
includes requirements for effective
dating.
<Project #>-AU-1.
<Project #>-AU-2.
Etc.
Computer Hardware
Requirements
This section identifies the system
requirements, if any, regarding
computer hardware that must be
used. Document any
environmental considerations for
hardware such as extreme
temperatures and use/abuse (e. g.,
handheld devices being dropped
on hard surfaces, etc.).
Capacity
Projection
sby
Technolog
y Area
Storage
Server /
Processors
Network
Page 15 of 20
Product
<Project #>-CH-1.
<Project #>-CH-2.
Etc.
Environme
nt (e.g.,
Point to
Point,
Local)
Type
(e.g.
packet)
Unit of
Measure
(e.g., port
counts)
Current
Quarter
Forecast
Quarter +1
Forecast
WAN Traffic
LAN Total
Document1
12/23/2014
Quarter +
2 Forecast
Quarter +
3 Forecast
Technical Specifications
& Requirements
Computer Software
Requirements
This section identifies the system
requirements, if any, regarding
computer software that must be
used by, or incorporated into,
the solution. Examples include
operating systems, database
management systems,
communications/ network
software, utility software, etc.
Specify correct name and version
numbers.
<Project #>-CS-1.
<Project #>-CS-2.
Etc.
Computer
Communications
Requirements
This section identifies the system
requirements, if any, concerning
computer communications.
Examples include geographic
locations to be linked; transmission
techniques; data transfer rates;
gateways; required system use
times; type of data to be
transmitted/ received; time
boundaries for transmission/
reception/response, etc..
<Project #>-CC-1.
<Project #>-CC-2.
Etc.
Transaction Projections
This section identifies the system
requirements, if any, for the
resources and transaction
projections.
Current
Quarter
Quarter + 1
Quarter + 2
Quarter + 3
Recommendations/Comments
Total No. of Concurrent Users
Hourly Transaction Rate
Peak Transactions
Performance
Requirements
This section identifies user defined
standards for system operations,
relating to hours of operations,
system response time, volumes,
growth, and reliability.
Page 16 of 20
<Project #>-PF-1.
<Project #>-PF-2.
Etc.
Document1
12/23/2014
Technical Specifications
& Requirements
Data Conversion
Requirements
This section identifies the
requirements, if any, needed to
convert data from old systems to
the new system being developed
and/or deployed.
Backup & Recovery
Requirements
This section identifies details of
back up and recovery
requirements. If software is
identified as mission essential a
continuity of operations plan must
be developed.
Failover & Redundancy
Requirements
This section identifies details of
failover and redundancy
requirements.
<Project #>-DC-1.
<Project #>-DC-2.
Etc.
<Project #>-BR-1.
<Project #>-BR-2.
Etc.
<Project #>-FR-1.
<Project #>-FR-2.
Etc.
Archival Requirements
This section identifies the
requirements, if any, related to
length of time data needs to be
retained within the application;
level of difficulty to retrieve
archived data, etc.
<Project #>-AC-1.
<Project #>-AC-2.
Etc.
Availability Requirements
This section identifies the
requirements, if any, related to
support (e.g., 24x7 ) and up-time
(e.g., 99.9%). These requirements
tie into how critical the solution is
to the business. Requirements
may also include a manual backup
process in case the application
fails.
Page 17 of 20
<Project #>-AV-1.
<Project #>-AV-2.
Etc.
Document1
12/23/2014
Technical Specifications
& Requirements
Personnel-Related
Requirements
This section identifies the system
requirements, if any, needed to
accommodate the number, skill
levels, duty cycles, or other
information about the personnel
who will use or support the system.
Examples include
requirements for no.of
simultaneous users, non-English
languages, considerations for
capabilities and limitations
of humans, requirements for color
and duration of error messages,
physical placement of critical
indicators or keys, use of auditory
signals, etc.
<Project #>-PR-1.
<Project #>-PR-2.
Etc.
Training and
Documentation-Related
Requirements
This section identifies the
requirements, if any, needed to
train system users (end users, help
desk, maintenance personnel,
etc.). Includes items such as online help, creation of CBTs, FAQs,
User Manuals, Install instructions,
Release notes, Computer
Operations Manuals, etc. Indicate
whether training or documentation
is required in languages other than
English.
<Project #>-TD-1.
<Project #>-TD-2.
Etc.
Design Factors and
Constraints
This section identifies additional
factors or design constraints that
must be considered in the
development of the system.
Examples include things such as
scalability, reliability,
maintainability, availability,
flexibility, portability,
reusability, testability, data
integrity and usability. Also
include in this section architectural
constraints such as language,
standards, etc.
Facilities Requirements
This section identifies
requirements, if any, related to
needs such as data center space,
raised floor, rack space, HVAC,
electrical, team space, etc.
Page 18 of 20
<Project #>-DF-1.
<Project #>-DF-2.
Etc.
<Project #>-FC-1.
<Project #>-FC-2.
Etc.
Document1
12/23/2014
Technical Specifications
& Requirements
Other Requirements
<Project #>-OR-1.
This section identifies system or
project requirements, if any, not
covered by the above sections.
<Project #>-OR-2.
Page 19 of 20
Etc.
Document1
12/23/2014
Technical Specifications
& Requirements
4
DELIVERABLE ACCEPTANCE/SIGN-OFF
The following project team leads have reviewed and approved this deliverable. This deliverable confirms that
project requirements have been identified, documented and approved by the relevant teams and are now
baselined. Baselines may only be changed through formal change control procedures.
ROLE
NAME
Solution Architect
TBD
Development Team Lead
TBD
Development Team Lead
TBD
Infrastructure Team Lead
TBD
Infrastructure Team Lead
TBD
QA Lead
TBD
Project Manager
TBD
IT Sponsor
TBD
Business Sponsor
TBD
Page 20 of 20
Document1
SIGNATURE(S)
12/23/2014
DATE OF
REVIEW/AGREEMENT