Functional Specifications Template

Functional Specification - FRS document
Enter Project Name Here

Software Version <X.Y>
Sponsor: Enter sponsors name Prepared By: Enter persons name Approved By: Enter persons name Customer: Enter customer name here QA Resource: Enter QA Tester name here DMDC Lead: Enter leads name Published: Enter date Project Officer: Enter persons name Data Model Review Board: Enter name of approving review board member Data Dictionary Manager: Enter name of approving data dictionary manager
Table of Contents
1.0 2.0 3.0 4.0 5.0 6.0 7.0 Introduction.........................................................................................................................................1 Business Context................................................................................................................................1 Functional Requirements...................................................................................................................2 Non-Functional Requirements...........................................................................................................4 Future Requirements..........................................................................................................................5 Resource Requirements.....................................................................................................................5 Revision History..................................................................................................................................6
To update the Table of Contents, click in the table then press F9
Functional Specification
Elaboration Phase
1.0
Introduction
The introduction should give a summary of the system for which this functional specification is being written. This summary may include as little or as much detail as necessary, but should describe the purpose and approach of the system while also providing background and/or history where appropriate.>
2.0
Business Context
The business context section should describe the system as it relates to business processes and other systems. 2.1 Definitions Business definitions go here Term1 - <Definition> TermN - <Definition> 2.2 Context Models
<The business context models should depict the each of the different business contexts in which the system may operate>
www.BusinessAnalystFAQ.com
Page 1
Elaboration Phase 2.2.1 <business process #1>
User Action User
User Action
System X Action System X
System Y Action System Y
System Y Action
System Z
System Z Action
<followed by paragraph description>

2.2.2 <business process N>
<UML activity diagram goes here> <followed by paragraph description>
3.0
Functional Requirements
<The functional requirements section should detail the functionality or behaviors provided through the system> 3.1 System Actor-Goal Listing The following table depicts the systems primary actors and their goals in using the system. Actor Goal Description
3.2
System Use Case Model
The following use case diagram depicts the high-level functionality of <System>. Details on each of the specific uses are captured in the following use case narratives (Section 3.3) and business rules (Section 3.4)
Page 2
Elaboration Phase
System Name
Use Case 1 Actor1 Use Case 2
<<Includes>>
Secondary Actor1
Use Case 4 Actor2

<<Includes>>
Use Case 3
3.3
System Use Case Narratives
The following use case narratives provide details on each of the specific uses of the system: UC1. <Use Case Name> Description: < In one or two sentences, describe the interaction that occurs in this use case. Try not to regurgitate the basic course of events, rather summarize the events, actors, and goals, providing context not included in other sections.> Assumptions <Description of assumption 1> <Description of assumption 2> Basic Course of Action 1. <First step in the Basic Course of Action> (See Alternate Actions A & B) 2. <Next Step> (See Business Rule 3.4.2) Alternate Course of Action A (<Summary description of Action A>) A1.<First step in Alternate Course of Action A> A2.<Next Step> Alternate Course of Action B (<Summary description of Action B>) B1.<First step in Alternate Course of Action B> B2.<Next Step> 3.4 Business Rules
<The business rules section should contain details specific to the business for which the system is being built. These rules are used to supplement the system behavior described in the use cases. For example, the system may provide the ability to record a sale, and may have associated business rules that define the sales data to be captured and how to calculate the sales tax.>
Page 3
Elaboration Phase 3.4.1 BR1 <Business Rule Category 1>
BR.1.1 <Business rule text goes here> BR.1.2 <Business rule text goes here> <List item1> <List item 2>
3.4.2 BR2 <Business Rule Category 2>
BR.2.1 <Business rule text goes here> BR.2.2 <Business rule text goes here> <List item1> <List item 2>
4.0
Non-Functional Requirements
<While functional requirements address specific functionality or behaviors provided by the system, non-functional requirements (sometimes referred to as technical requirements or technical constraints) are criteria or constraints of these functions or behaviors. For example, we may have functional requirement that states the system will print a receipt for all sales. The associated non-functional requirements might address the speed with which that receipt must print and might also require that we log the sale item, amount, and time for audit purposes.> 4.1 Performance Requirements
P.1 P.2
<How many transactions at peak?> <Throughput?> <Monitor and Logging Requirements>
4.2
Monitoring and Logging Requirements

M.1 M.2
4.3
Security Requirements Yes No N/A
Security Requirements
4.3.1 Does proposed project include COTS Products? 4.3.1.1 Are they security products or security enabled products? 4.3.2 Does proposed project include only standard ports? 4.3.2.1 If not, please identify the ports the product uses. 4.3.3 Does proposed project include hashing or encryption? 4.3.4 Will the application display a Privacy Act Statement? 4.3.5 Is there a valid or legal reason to display the Social Security Number? 4.3.6 Is there a valid or legal reason for not requiring CAC/PIN login?
Page 4
Elaboration Phase
4.4
Privacy Requirements
Personally Identifiable Information (PII) is any form of information that can be used to identify, locate, or contact an individual. This information includes, but is not limited to SSN, name, home address/phone number, complete DOB, personal medical information, financial information, religion, or national origin. There are also indirect identifiers, which when used in combination, could help to narrow down the identity of a specific individual. This information includes, but is not limited to gender, age, race, geographic indicators, and job position. Privacy Requirements Yes No Unknown If any question is answered Yes or Unknown, see the DMDC Privacy Information Officer.
4.4.1 Is Privacy Act data to be displayed? 4.4.2 Will the application collect, maintain, or disseminate information in identifiable form? 4.4.3 Will this application change anonymous information into information in identifiable form? 4.4.4 Will this application change how information in identifiable form is managed? 4.4.5. Will this application alter a business process that results in significant new uses or disclosures of information? 4.4.6. Will this application alter a business process that will incorporate additional information items in identifiable form? 4.4.7 If new information in identifiable form is added to a collection, will this application raise the risks to personal privacy? 4.4.8 Based on all of Section 4.4 questions is a PIA (Privacy Impact Assessment) required?
Business Analyst Interview Questions Business Analyst Job Description Business Analyst 4.5 Testability Requirements
T.1 T.2
<As needed>
4.6
General Constraints
C1 C2
<As needed>
5.0
Future Requirements
F.1
<As needed>
6.0
Resource Requirements
Page 5
Elaboration Phase
6.1
Human Resource Needs
Define the human resource needs. Complete the table as well as possible. Need
Project Officer Requirements/Design Technical Expert Systems Architect Database Administrator Development QA Testing Configuration Management Production Support Technical Writer DSC Systems
Resource
Amount
N hours N hours N hours N hours N hours N hours N hours N hours N hours
Status
Comments
7.0
Revision History
Revised By Date
Revision
Page 6

Functional Specifications Template

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Functional Specifications Template

Încărcat de

Drepturi de autor:

Formate disponibile

Functional Specification - FRS document

Enter Project Name Here

To update the Table of Contents, click in the table then press F9

User Action User

System X Action System X

System Y Action System Y

<followed by paragraph description>

<UML activity diagram goes here> <followed by paragraph description>

System Use Case Model

Use Case 4 Actor2

System Use Case Narratives

<How many transactions at peak?> <Throughput?> <Monitor and Logging Requirements>

Monitoring and Logging Requirements

Security Requirements Yes No N/A

Human Resource Needs

S-ar putea să vă placă și