Specification Template - Ohio State University€¦ · Web view2015/01/04 · Non-Functional Requirements x Functional Specifications Requestor and/or the Functional Lead/Consultant

Technical Specifications & Requirements

Contents

Functional Specifications............................................................................................................................................. xFunctional Description............................................................................................................................................. xFunctional Specification........................................................................................................................................... xIssues...................................................................................................................................................................... xAssumptions............................................................................................................................................................ xData Security........................................................................................................................................................... xFunctional Specification Approval............................................................................................................................ x

Technical Specifications.............................................................................................................................................. xTechnical Description.............................................................................................................................................. xProgram Logic......................................................................................................................................................... xProgram/Process Modification Details..................................................................................................................... xDevelopment And Impact Considerations................................................................................................................ x

Batch Specifications.................................................................................................................................................... xBatch Program Definition......................................................................................................................................... xInput Flat File Format (Field Mapping)..................................................................................................................... xOutput Flat File Format (Record/Field Mapping Where The Data Exists)................................................................xPaste Sample Report Here...................................................................................................................................... x

Online Specifications................................................................................................................................................... xPage Properties....................................................................................................................................................... xPaste Sample Page Here........................................................................................................................................ xComponent Properties............................................................................................................................................. xMenu Properties...................................................................................................................................................... xPortal Properties...................................................................................................................................................... x

Object Specifications................................................................................................................................................... xField Properties........................................................................................................................................................ xTable Field Edits...................................................................................................................................................... xRecord/View Properties........................................................................................................................................... xPeoplecode.............................................................................................................................................................. xQueries.................................................................................................................................................................... xComponent Interface Properties.............................................................................................................................. xFile Layout Properties.............................................................................................................................................. xFile Parser............................................................................................................................................................... xMessage Catalog..................................................................................................................................................... xSecurity.................................................................................................................................................................... x

Integration Broker Specifications................................................................................................................................. xApplication Message................................................................................................................................................ xApplication Messaging Channel............................................................................................................................... xApplication Messaging Node................................................................................................................................... xWeb Service............................................................................................................................................................ x

Inventory of Objects.................................................................................................................................................... xNon-Functional Requirements…………………………………………………………………………………………………x

Page 1 of 20 document.docx 12/23/2014


Functional SpecificationsRequestor 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.

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


FUNCTIONAL DESCRIPTION


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.



Under Group Box Label – Job Information:

1. Add Comments link - DERIVED_DUMMY. DUMMY_FIELD (POSITION_COMNTS_OS secondary page). This will be retro-fitted from v8.9.

The following custom fields will be added to this subpage - POSITION_COMNTS_OS

Under Group Box Label - Comments:

2. POSITION_DATA.DESCR254

3. Add Supervision/Essential Duties link - ABS_BEGIN_DT_VW (POSITION_SUPR_OS secondary page). This will be retro-fitted 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:



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.



FUNCTIONAL SPECIFICATION APPROVALRequestor: 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.



Technical SpecificationsTechnical 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 DESCRIPTIONOverall 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 LOGICOverall flow and logic of the Customizations/Modifications:

Use pseudo code and/or flow charts to document the functionality and required changes.

PROGRAM/PROCESS MODIFICATION DETAILSDevelopment 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.



DEVELOPMENT AND IMPACT CONSIDERATIONSSIR Number: (Include Impact such as the type of restricted data HIPPA, FERPA, SSN, BuckID or Functional change that needs to be communicated.)External Integration ImpactInternal Modules ImpactedAutoSys impactCustomer Readiness impactSensitive or Restricted OutputData Warehouse ImpactDatabase impactIdentity ManagementSecurity: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 ImpactInternal Modules ImpactedAutoSys impactCustomer Readiness impactSensitive or Restricted OutputData Warehouse ImpactDatabase impactIdentity ManagementSecurity:Other(Specify)

Batch Specifications

BATCH PROGRAM DEFINITIONBatch 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)FILE NAME: SOURCE SYSTEM: FILE RECORD LENGTH: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:Descriptive Name Field Field Start End Record Field Notes



(Ex: Hire Date) Type Length Position Position Name Name

REPORT PROPERTIESReport Name:SQR, XML Report, Crystal or Other (Specify):Elements on Report:Sort Sequence:Totals by:Frequency:Sensitive Information:

PASTE SAMPLE REPORT HERE

PROCESS DEFINITION PROPERTIESProcess Definition Name:Process Type:Component:Description:

JOB DEFINITION PROPERTIESJob Name:Component(s):List of ProcessesDescription:

Online Specifications

PAGE PROPERTIESPage Name:Description:

PASTE SAMPLE PAGE HERE

COMPONENT PROPERTIESComponent Name:Description:



Search Record:Pages on Component:

MENU PROPERTIESMenu Name:Bar Item Label:Menu Item Label:Menu Item Type:

PORTAL PROPERTIESPortal Registry:Folder Path:Folder Name:Content references:Nodes

Object Specifications

FIELD PROPERTIESField Name Field Type Field Format Field Length

TABLE FIELD EDITSField 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 PROPERTIESRecord Name Record

Type:Description: (Data and how it is used) Table Growth and

Size considerations

PEOPLECODEObject Type

Object Name Field Name PeopleCode Event

PeopleCode Logic Description

Record



PageComponent

QUERIESQuery Name:Description:

COMPONENT INTERFACE PROPERTIESComponent Interface Name:Source Component:Permission List(s):Standard Methods: (Cancel, Create, Find, Get, Save)

FILE LAYOUT PROPERTIESFile Layout Name:DescriptionTypeFormat Definition Delimiter

FILE PARSERFile Parsing Definition:Description

MESSAGE CATALOGSet Nbr Message Nbr Severity Actual Message

SECURITYPermission List(s):Menu:Component:Display Only? (Y/N)Actions:



Integration Broker Specifications

APPLICATION MESSAGEApp Message Name:DescriptionMessage ChannelDefault Version

APPLICATION MESSAGING CHANNELApp Message Channel Name:DescriptionMessages in ChannelPublish Message NodesSubscribe Message NodesOn-Route Publication LogicOn-Route Subscription Logic

APPLICATION MESSAGING NODEApp Message Node Name:DescriptionLocal or RemoteURL(If Remote)

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



Inventory of ObjectsImpact Type

(New, Mod, Delete)Object Type (Component,

Field, Page, Menu, PeopleCode, Security, Records, View/Query,

Other)

Object Name

SIR Number:



Click the ¶ button on the HOME tab of the MS Word Toolbar to see additional, hidden text guidelines for completing this document.

1 PROJECT INFORMATION

Project Name: Project ID:

Business Sponsor: Primary IT Sponsor:

PMO Project Manager: Document Author:

Date Created: Date Baselined:

2 DELIVERABLE INFORMATION

Project Phase: PLAN; Requirements Analysis and Definition

Deliverable Name: Non-Functional Requirements (NFR) Document

Deliverable Description:

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.

3 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 RequirementsThis 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.

<Project #>-DR-1.

<Project #>-DR-2.

Etc.



Adaptation RequirementsThis 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 RequirementsThis 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 RequirementsThis 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 RequirementsThis 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.).

<Project #>-CH-1.

<Project #>-CH-2.

Etc.

Capacity Projection

sby Technolog

y AreaProduct

Environment (e.g., Point to Point, Local)

Type(e.g.

packet)

Unit of Measure (e.g., port counts)

Current Quarter

ForecastQuarter +1 Forecast

Quarter + 2 Forecast

Quarter + 3 Forecast

StorageServer / ProcessorsNetwork WAN Traffic

LAN Total



Computer Software RequirementsThis 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 RequirementsThis 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 ProjectionsThis 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 RatePeak Transactions

Performance RequirementsThis section identifies user defined standards for system operations, relating to hours of operations, system response time, volumes, growth, and reliability.

<Project #>-PF-1.

<Project #>-PF-2.

Etc.



Data Conversion RequirementsThis section identifies the requirements, if any, needed to convert data from old systems to the new system being developed and/or deployed.

<Project #>-DC-1.

<Project #>-DC-2.

Etc.

Backup & Recovery RequirementsThis section identifies details of back up and recovery requirements. If software is identified as mission essential a continuity of operations plan must be developed.

<Project #>-BR-1.

<Project #>-BR-2.

Etc.

Failover & Redundancy RequirementsThis section identifies details of failover and redundancy requirements.

<Project #>-FR-1.

<Project #>-FR-2.

Etc.

Archival RequirementsThis 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 RequirementsThis 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.

<Project #>-AV-1.

<Project #>-AV-2.

Etc.



Personnel-Related RequirementsThis 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 includerequirements for no.of simultaneous users, non-English languages, considerations for capabilities and limitationsof 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 RequirementsThis section identifies the requirements, if any, needed to train system users (end users, help desk, maintenance personnel, etc.). Includes items such as on-line 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 ConstraintsThis 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.

<Project #>-DF-1.

<Project #>-DF-2.

Etc.

Facilities RequirementsThis section identifies requirements, if any, related to needs such as data center space, raised floor, rack space, HVAC, electrical, team space, etc.

<Project #>-FC-1.

<Project #>-FC-2.

Etc.



Other RequirementsThis section identifies system or project requirements, if any, not covered by the above sections.

<Project #>-OR-1.

<Project #>-OR-2.

Etc.



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 SIGNATURE(S) DATE OF REVIEW/AGREEMENT

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


Documents

Specification Template - Ohio State University€¦ · Web view2015/01/04 · Non-Functional Requirements x Functional Specifications Requestor and/or the Functional Lead/Consultant