Federal Aviation Administration Aircraft Safety Knowledge Management Environment (ASKME)

magazinebindΔιαχείριση

6 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

71 εμφανίσεις


Federal Aviation Administration

Aircraft Safety Knowledge Management
Environment

(ASKME)


Electronic File Service

(EFS)




Functional Requirements Document

v 1.0





January 2007














i


EF
S Functional Requirements v0.4
11/7/2013


Revision History Summary


Version Number

Date

Author

Justification

0.1

12/20/06

Scott Stolzfus

Created initial
document draft.

0.2

01/16/07

Jennifer Frye

Updated document
to incorporate ISUG
comments and
updates resulting
from first round
requirements
review.

0.3

01/25/07

Jennifer Frye

Updated docume
nt
to make changes
noted

in 1/18
/07
team meeting.

0.4

1/25/07

Jennifer Frye

Updated document
to make change
indicated in 1/25/07
meeting and a
couple of other
minor additions.

0.5

3/15/07

Jennifer Frye

Added search by
category and check
for duplicate
documents on
upload.

1.0

3
/23/07

Jennifer Frye

Changed document
to indicate final
version.














ii


EF
S Functional Requirements v0.4
11/7/2013


RECEIPT / ACCEPTANCE



By signing below, I acknowledge receipt of this document. Comments and
feedback to this document shall be provided within 5 business days of receipt of
this document.

In the absence of any comments or feedback within the period
specified above, I acknowledge acceptance of this document.



FAA

Jennifer Frye

EFS PM

Signature


Date



FAA

James Seipel

EFS Sponsor

Signature


Date



FAA

EFS ISUG Members

Wanda Kimura, C
arlos Quiles, Margaret Magnifico,
Patricia G Smith, Gregory Michalik, Naomi Bryant,
Bobbie Smith, Glen Young, Hank Tong,

Perry W Cutts, Michelle Sauer

Signatures






Date















iii


EF
S Functional Requirements v0.4
11/7/2013



1

Introduction

................................
................................
................................
..............

1

1.1

Purpose

................................
................................
................................
...........

1

1.1.1

Background

................................
................................
................................
..

1

1.1.2

Assump
tions and Constraints

................................
................................
.......

1

1.1.3

Interfaces to External Systems

................................
................................
.....

2

1.2

Document References

................................
................................
.....................

2

2

Functional Requirements

................................
................................
.........................

2

2.1

Data Requirements

................................
................................
..........................

2

2.2

Functional Process Requirements

................................
................................
...

2

2.2.1

Catalog

................................
................................
................................
........

4

2.2.2

Index

................................
................................
................................
............

5

2.2.3

Search

................................
................................
................................
.........

5

2.2.4

Retrieve

................................
................................
................................
.......

8

2.2.5

Security

................................
................................
................................
........

8

2.2.6

Store

................................
................................
................................
............

9

2.2.7

Print

................................
................................
................................
...........

10

2.2.8

Disposition

................................
................................
................................
.

10

2.2.9

Reporting

................................
................................
................................
...

10

2.2.10

Administration

................................
................................
........................

11

2.2.11

Other

................................
................................
................................
......

12

3

Operational Requirements

................................
................................
.....................

13

3.1

Security

................................
................................
................................
..........

13

3.1.1

User Security

................................
................................
.............................

13

3.2

Database Security

................................
................................
.........................

13

3.3

Physical Security

................................
................................
...........................

14

3.4

Audit Trail

................................
................................
................................
......

14

3.5

Reliability

................................
................................
................................
.......

14

3.6

Maintainability

................................
................................
................................

14

3.7

Availability

................................
................................
................................
......

14

3.8

Recovery

................................
................................
................................
.......

15

3.8.1

Data Rollback

................................
................................
............................

15

3.8.2

Restoration of data

................................
................................
.....................

15














iv


EF
S Functional Requirements v0.4
11/7/2013


3.9

Capacity

................................
................................
................................
.........

15

3.10

Data Retention

................................
................................
...............................

15

3.11

Enhanceability

................................
................................
...............................

15

3.11.1

Scalability

................................
................................
...............................

15

4

Requirements Traceability Matrix

................................
................................
...........

16

Appendix F

Acronyms, Abbreviations, and Glossary

................................
.................

17













Page
1

of
24

EFS Functional Requirements v0.2
11/7/2013


1

INTRODUCTION

1.1

P
urpose

The Electronic File Service (
EFS
)

is a commercial off
-
th
e
-
shelf (COTS) enterprise class
document management system infrastructure that will provide document management
services for multiple applications within AVS.
The first interface
to EFSI will be limited to
the
Aircraft Certification
(
AIR
)

organization
. Ultimately, EFSI will be used
internally
throughout

AVS
and

externally to the general public.

This document contains
requirements gathered through Information System Users Group (ISUG) meetings, from
the EFS Concept of Ope
rations (CONOP
S) Document,
the
FAA AIR Concept Paper,
and
policy Orders relating to document management. This document is intended to
define the
requirements for the
EFS
infrastructure in addition to the EFS application
.


1.1.1

Background

The
AV
S

organization is responsible f
or promoting aviation safety by regulating and
overseeing civil aviation.
AV
S

establishes aviation safety and certification standards;
monitors safety performance; conducts aviation safety education and research; issues
and maintains aviation certificates

and licenses; and manages the FAA rulemaking
program. AIR, an organization within
AVS
, is responsible for developing, administering,
and ensuring compliance to standards governing the design, production, airworthiness,
and continued operational safety of

civil aircraft and related components.

Among AIR’s most valuable assets are the knowledge, skills, and abilities of its
workforce. This is especially true in the issuance of engineering and manufacturing
approvals for aircraft design, related components,

and production systems. Data
generated during original certifications is used as a basis for design and production
modifications, some of which may occur twenty or more years after the original approval.

In order to provide continued operational safety

and promote the FAA Flight Plan, AIR
needs an integrated source of safety and compliance information and organized
processes for easy, qui
ck access at
any time and place. Automated tools are needed
for capturing and creating an inventory of knowledge ass
ets as part of normal work
activities. Automated tools are required for analyzing data to predict potentially unsafe
conditions and for providing easily accessible management information.

EFS will meet these identified needs by storing knowledge assets, m
aking them
accessible, facilitating management and workforce decision making, and providing a
proactive system safety approach. This will be accomplished through a collection of
automated tool sets developed under the ASKME program beginning with EFS. EFS

will
provide electronic storage information capability and will require an application interface.


1.1.2

Assumptions and Constraints

The EFS Application Interface shall use the EFS services to provide document
management services. The application shall not
pro
vide any functions that

overlap the
fun
ctionality of the EFS services provided by the COTS product chosen for
implementation.














Page
2

of
24

EFS Functional Requirements v0.2
11/7/2013


Administrative

requirements may be satisfied through the COTS administrator
application. If the COTS application program can satis
fy the administrative requirement
then the application interface shall not implement these functions. If the COTS
application program cannot satisfy the administrative requirement then the EFS
application interface shall provide the functionality.


1.1.3

Interfa
ces to External Systems

There are several interface requirements that are deferred from version 1.0 of the
application interface. However, the functionality of the requirements should be
considered in the initial design of the application interface. Extern
al interfaces to
consider are:



Searching external databases

or content repositories
.




Electronic data
deletion based on disposition dates
,
archiving, transfer,
and migration to and from EFS.


1.2

Document References



EFS Project Document
-

"Concept of Operation
s (CONOPS) Document
(Business Requirements)"



EFS Project Document
-

“EFS Business Process Analysis and Software
Specification Development Statement of Work”



EFS Project Document
-

“EFS Concept/System Boundary Paper”



EFS Project Document
-

“EFS Requirements

Team Charter”



FAA Order FAA
-
IR
-
04
-
01, “Records Management Requirements Manual”
and its referenced mandates to NARA



FAA Order 0000.1G, “FAA Standard Subject Classification System”



FAA Order 1350.14A, “Records Management”



FAA Order 1350.15C, “Records Orga
nization, Transfer, and Destruction
Standards”



Information Technology Standards Document
-

“Institute of Electrical and
Electronics Engineers (IEEE) Standards Document (1362)”


2

FUNCTIONAL

REQUIREMENTS


2.1

Data Requirements

All data accessed by the EFS Applica
tion Interface shall be in electronic format.


2.2

Functional Process Requirements

The ASKME Electronic File Service (EFS) provides electronic documentation storage.

EFS shall

provide

an interface to logically categorize, store,
search,
and retrieve













Page
3

of
24

EFS Functional Requirements v0.2
11/7/2013


documents

to and from the file service.

This c
omponent is referred to as EFS a
pplication
interface
.















Page
4

of
24

EFS Functional Requirements v0.2
11/7/2013


2.2.1

Cata
log

2.2.1.1

EFS shall

provide for adding

information about the document (called metadata)
such as title, subject, document type, etc., while other information such as
a
uthor, date created, version number, physical location, is automatically
captured by
the
EFS

interface
.

(AIR Concept Paper, High Priority)
1

2.2.1.2

EFS shall

allow users to populate metadata fields from data entries in a drop
down list.

EFS shall employ defaults a
nd
valid
-
value lists to choose from

wh
ere
applicable (e.g., metadata
)
.

Metadata drop down lists may have sub menus.
(CONOPS, High Priority)


2.2.1.3

EFS shall display automatic metadata fields first, followed by Required fields,
and Optional fields last.

(ISUG Req
uirements Meeting, High Priority)

2.2.1.4

EFS will only allow one version of a document.

(ISUG Requirements Meeting,
High Priority)

2.2.1.5

EFS shall

display

appropriate

metadata fields based on the document type that
is selected by the user.

(AIR Concept Paper, High Prio
rity)

2.2.1.6

EFS shall

populate the document type drop down list based on the user's
authority to upload those document types.

(AIR Concept Paper, High Priority)

2.2.1.7

EFS shall

store

documents to the

appropriate storage

location.

(AIR Concept
Paper, High Priority)

2.2.1.8

EFS

shall

validate the metadata field values that
have been selected by the
user

based on the business rules that have been defined
.

(ISUG Requirements
Meeting, High Priority)

2.2.1.9

EFS shall

prompt the user

to make corrections or selections until all
required
meta
data fields are validated.

(ISUG requirement meetings, High Priority)

2.2.1.10

EFS shall

provide a
n administrator

method to
add
document types.

(ISUG
requirement meetings, High Priority)

2.2.1.11

EFS shall

provide
an admin
i
strator

method to define or modify what metadata
fi
elds are
associated with

each document type.

(ISUG requirement meetings,
High Priority)

2.2.1.12

EFS shall

provide
an administrator
method

for defining optional or required
metadata fields.

(ISUG requirement meetings, High Priority)

2.2.1.13

EFS shall

provide

an administra
t
or

method to

define

or modify
whether a
metadata field will have a
valid values
list.

(ISUG requirement meetings, High
Priority)

2.2.1.14

EFS
shall

provide
an adminis
t
ra
t
or

method to establish the default value for a
metadata field
.

(ISUG requirement meetings, High

Priority)

2.2.1.15

EFS shall

provide the ability to relate

or link

one document to
one or more other
document
s
.

(AIR Concept Paper, High Priority)




1

The initial item in par
entheses is the origin of the requirement. The second item in parentheses
is the priority for implementing in the first release.














Page
5

of
24

EFS Functional Requirements v0.2
11/7/2013


2.2.1.16

EFS shall provide a spell check for users to check spelling of
open field
metadata entered. (
CONOPS,
Low priority
)

2.2.1.17

On

document upload, EFS shall check to see if a document already exists in
the repository. If a duplicate document is found, a message shall be displayed
indicating the content already exists with a link to the document. (ISUG
Requirements Meeting
,
Medium

p
riority)

2.2.2

In
dex

Text documents
and associated metadata
are submitted
to a full
-
text in
dexing engine.
When
documents are submitted to EFS the indexing occurs automatically.

2.2.2.1

EFS

must ensure the indexing is enabled.

(AIR Concept Paper, High Priority)


2.2.3

S
earch

2.2.3.1

EFS shall

search within the EFS system

and return results
according to
user

access permissions.

(AIR Concept Paper, High Priority)

2.2.3.2

EFS
shall

search data sources

external to EFS
.

(AIR Concept Paper, Deferred
for release 1.0)

2.2.3.3

EFS shall

offer basic and advanc
ed searching.

(ISUG requirement meetings,
High Priority)

2.2.3.4

The basic search will consist of searching for a string
anywhere within metadata
and/or a document. (ISUG requirement meetings, High Priority)

a.

within document
s of specific document

types

b.

within metad
ata fields

c.

within document

names

d.

within document

content

2.2.3.5

EFS shall

allow the user to select one or

more allowable document types
to
search.
(ISUG requirement meetings, High Priority)

2.2.3.6

EFS shall allow document types to be selected and deselected from the sea
rch
list. (ISUG requirement meetings, High Priority)

2.2.3.7

EFS shall allow a search on the list of documents

from a previous search
.

(ISUG requirement meetings, High Priority)

2.2.3.8

EFS will allow metadata to be selected to limit the search criteria. (ISUG
requirement

meetings, High Priority)

2.2.3.9

EFS shall

display a list of document types that the user is authorized to search.

(AIR Con
cept Paper, High Priority)

2.2.3.10

The advanced search will consist of
a basic search plus additional search
criteria
.

(ISUG requirement meetings, H
igh Priority)

a.

Searching with all words

specified

b.

Searching with at least one of the words

specified














Page
6

of
24

EFS Functional Requirements v0.2
11/7/2013


c.

Searching
excluding

the words

specified

d.

Search by file format

(Microsoft Word, Excel, Image etc..)

e.

Search by c
reation date

range

f.

Search by c
reated by

g.

Search

by m
odified date

range

h.

Search by m
odified by

i.

Search by disposition date (author and administrator)

j.

Search by metadata fields

k.

Search within

a specific folder














Page
7

of
24

EFS Functional Requirements v0.2
11/7/2013


2.2.3.11

EFS

search
will provide s
upport for Boolean operators, full text search methods
(text strings, pro
ximity searches and wild cards).

(AIR Concept Paper, High
Priority)

2.2.3.12

EFS

search
will s
upport relevancy ranking.

(CONOPS, Low Priority)

2.2.3.13

For performance
EFS

search
will allow the search to be limited to a specific
number of documents.

(ISUG requirement meetin
gs, Low Priority)

2.2.3.14

For performance
EFS

search
will allow the search results to be limited to a
specific number of
result documents
.

(ISUG requirement meetings, Low
Priority)

2.2.3.15

EFS

search results will display
a standard set of metadata fields including File
Co
de, Description, Author, Creation Date
.

(ISUG requirement meetings, High
Priority)

2.2.3.16

EFS search will retain search criteria settings from the previous search. (ISUG
requirement meetings, High Priority)

2.2.3.17

EFS

search
will allow the search criteria to be cleared

or reset
.

(ISUG
requirement meetings, High Priority)

2.2.3.18

EFS

search will provide for a paged view of the search results.

(ISUG
requirement meetings, High Priority)

2.2.3.19

EFS

search will provide for sorting by selecting the header of each column in
the search results

dialog.

(ISUG requirement meetings, High Priority)

2.2.3.20

EFS

search will allow the search results to be exported to a comma separated
value (csv)
file
format.

(ISUG requirement meetings, High Priority)

2.2.3.21

EFS

search will allow the search to be interrupted or stopp
ed.

(ISUG
requirement meetings, High Priority)

2.2.3.22

EFS shall provide the ability to save and modify common queries available in
EFS.

(ISUG requirement meetings, High Priority)


2.2.3.23

EFS shall provide the ability to view multiple search results
. (ISUG requirement
me
etings, Low Priority)


2.2.3.24

If feasible, EFS shall be integrated with a FAA Thesaurus, when and if the FAA
Thesaurus is finalized. (ISUG Requirements meetings, Deferred

for release
1.0
)















Page
8

of
24

EFS Functional Requirements v0.2
11/7/2013


2.2.4

Retr
i
eve

2.2.4.1

EFS shall include
the FAA data disclaimer on the main screen of
the application
interface.

(
ISUG Requirements Meetings
, High Priority)

2.2.4.2

EFS shall

provide an interface to retrieve
one or more
documents from the EFS
and save the documents to the user's computer or network storage location.

(AIR Concept Paper, High Priorit
y)

2.2.4.3

EFS shall

allow documents to be selected from a search list or a directory/folder
browse list.

(CONOPS, High Priority)

2.2.4.4

Multiple document selection will be according to the operating system selection
method using the shift, CTRL or other keys.

(ISUG requ
irement meetings, High
Priority)

2.2.4.5

EFS shall

allow the user to browse the operating system/network to choose a
location to store the documents that are being retrieved.
(ISUG requirement
meetings, High Priority)

2.2.4.6

EFS shall not write to the user
'
s computer or
network locations other than
documents that the user specifies.

(ISUG requirement meetings, High Priority)


2.2.5

Security

2.2.5.1

EFS must be developed in accordance with

National Institute of Standards and
Technology (NIST)
Security Guidelines and Federal Information
Processing
Standards (FIPS).

2.2.5.2

EFS shall

s
upport designation/categorization
of documents
for secure
access/disposition

within EFS
.

(AIR Concept Paper, High Priority)

2.2.5.3

EFS shall

allow users to submit and retrieve documents based on permissions
within the EFS.

(AIR Concept Paper, High Priority)

2.2.5.4

EFS shall prevent the unauthorized destruction of documents. (1350.15, 2
-
2,
High Priority)

2.2.5.5

EFS shall allow the transfer of documents from one user to another. (FAA
-
IR
-
04
-
01A, 307,
Deferred

for Release 1.0
)

2.2.5.6

EFS shall

authe
nticate users
within the EFS
when they login.
(AIR Concept
Paper, High Priority)

2.2.5.7

Single Sign
-
On will be used
. (ISUG requirement meetings, High Priority)

2.2.5.8

EFS shall

ensure that a user's authentication is preserved throughout the
session and that the authenti
cation is accurately provided to the EFS for
submitting and retrieving documents.

(AIR Concept Paper, High Priority)

2.2.5.9

EFS will provide role
-
based security.

(CONOPS, High Priority)

2.2.5.10

EFS will interface with Active Directory.

2.2.5.11

EFS will provide the following role
s:

(CONOPS, High Priority)

a.

Reader
-

can retrieve documents but not
store/
submit














Page
9

of
24

EFS Functional Requirements v0.2
11/7/2013


b.

Author
-

inherits ri
ghts from Reader, can submit

new documents
and
link submitted documents to other documents.

Can delete documents
with
in

14 days of posting.

c.

Editor
-

inheri
ts righ
ts from Reader and Author, can delete
documents
they did not author
, can generate a report for scheduled dispositions.

d.

System Administrator
-

full authority, generally provided by the COTS
product.

e.

Content Administrator
-

full authority, generally pr
ovided by the COTS
product.

f.

Roles may be further refined.


2.2.6

Store

2.2.6.1

EFS shall

provide an interface to store
electronic
documents in the EFS.
(AIR
Concept Paper, High Priority)

2.2.6.2

EFS shall only accept electronic data.
The process of converting paper,
electronic,

and verbal information into an electronic version shall be performed
in an offline/external process to EFS.

(AIR Concept Paper, High Priority)

2.2.6.3

Scanners will be
evaluated, purchased, and

installed at a specified number of

locations in conjunction with the
EFS implementation
. (AIR Concept Paper,
High Priority)

2.2.6.4

EFS shall

apply the same
document type and
metadata field valu
es to all
documents submitted a
t

one time.

(CONOPS,
Low

Priority
)

2.2.6.5

EFS shall

allow the user to

browse
the operating system
/network

to choose

the
documents to be submitted.
(ISUG requirement meetings, High Priority)

2.2.6.6

EFS shall

display a list of documents to be submitted as the user selects
documents during one or more browse operations.

(ISUG requirement
meetings, Low Priority)

2.2.6.7

EFS shall

allow d
ocuments to be removed from the list of documents to be
submitted.

(ISUG requirement meetings, Low Priority)

2.2.6.8

EFS shall be

able to accept all Standard AVS

Client software file types for the
upload process (e.g., Microsoft Office applications and graphic fil
e types).
(CONOPS, High Priority)

2.2.6.9

EFS shall accept input directly fro
m within MS Office applications.

(
ISUG
Requirements Meetings
,
Deferred for Release 1.0
)

2.2.6.10

Documents shall be organized by docum
ent type (e.g.
Initial types of
Letters

and

M
emos)
and then fi
le code
s

identified by the ISUG from

FAA
-
IR
-
04
-
01A.doc.

(FAA
-
IR
-
04
-
01A, High Priority)















Page
10

of
24

EFS Functional Requirements v0.2
11/7/2013


2.2.7

Print

Printing shall

be performed through the native application
and operating system
appropriate for the document.
EFS

is not

required to directly print documents that

are
retrieved from the EFS.

2.2.7.1

EFS shall be able to pri
n
t the application interface screens including complete
lists that are within scrolling regions. (ISUG requirement meetings, Low Priority)


2.2.8

Disposition

2.2.8.1

EFS

will

provide an

interface to perform dispositio
n
in compliance
with the
requirements extracted by the ISUG user group from

FAA

orders1350.15 and
1350.14

identified below
.

(1350.15 and 1350.14,
High Priority
)

2.2.8.2

Disposition dates will default based on disposition rules that a records manager
assigns to a
particular document type

or file code
.

(ISUG requirement meetings,
High

Priority)

2.2.8.3

Disposition dates and disposition instructions shall be populated based
on
information provided by the ISUG for each
file code.
(
FAA
-
IR
-
04
-
01
, High
Priority)

2.2.8.4

When a document
contains re
lated documents,

the disposition date is the latest
of all the documents that are linked in this manner.

(FAA Order 1350.14, High
Priority)

2.2.8.5

EFS

will provide a disposition date report
.

(FAA Order 1350.14, High Priority)

2.2.8.6

EFS

shall provide for docu
ment archival (
AIR CONOPS
,
deferred for Release
1.0
,
functionality will be to export and transfer in the appropriate format rather
than archival
)

2.2.8.7

EFS shall provide for the transfer of documents to NARA electronically. (FAA
-
IR
-
04
-
01
, Appendix 2, d
eferred

fo
r Release 1.0
)

2.2.8.8

EFS shall provide for data migration when necessary (FAA
-
IR
-
04
-
01
, Appendix
2,
deferred

for Release 1.0
)


2.2.8.9

Disposition time periods

will default based on file codes.

The starting date for
the time period will be the ‘Date Signed’ metadata fie
ld.

2.2.8.10

Records administration functionality will provide for disposition dates in the
8000 series to be extended. (ISUG Requ
irements Meetings, Med Priority)


2.2.9

Reporting

2.2.9.1

EFS shall provide basic and advanced search functionality in place of ad
-
hoc
reporting func
tionality.

(ISUG requirement meetings, High Priority)

2.2.9.2

EFS shall provide the following reports:

(ISUG requirement meetings, High
Priority)

a.

Common EFS

user query

report.














Page
11

of
24

EFS Functional Requirements v0.2
11/7/2013


b.

File code report.

c.

Disposition date report.

d.

Organization/division/directorate report
.

e.

A
uthor name report.

f.

Information within 30 days of disposition date report.

g.

Ability for authors to generate a report to view all their information that
is within 30 days of disposition date.

h.

Metadata taxonomy report

i.

Recommended for Public Viewing Report


2.2.10

Ad
ministration

Some a
dministration functions may be
accessed

through
the EFS administrator
interface
.
If any administrator functio
ns are not available in the EFS administrator
interface

then the
EFS application interface

must provide the administrator
functi
ons
.

The following are
required administrator functions:

2.2.10.1

Assign default disposition

dates
.

(AIR Concept Paper, High Priority)

2.2.10.2

Notification of pending deletion
.

(ISUG requirement meetings
, Deferred

for
Release 1.0
)

2.2.10.3

Approving deletions.
(ISUG requirement mee
tings
,
Deferred
for Release 1.0
)

2.2.10.4

Report for scheduled dispositions
.

(ISUG requirement meetings, Deferred)

2.2.10.5

Add and modify document types, metadata, and metadata selection drop down
lists and default values
.

(ISUG requirement meetings, High Priority)

2.2.10.6

Add and

modify users and groups
.

(ISUG requirement meetings, High Priority)

2.2.10.7

User Name

Report
(CONOPS, High Priority)

2.2.10.8

Modify permissions for documents and folders
.

(ISUG requirement meetings,
High Priority)

2.2.10.9

Create and modify document storage and folder layout.

(IS
UG requirement
meetings, High Priority)

2.2.10.10

C
onfiguration and reporting of auditing. Auditing data should consist of who
did what and when. Uploads of documents should be audited to include the
action, the user, the document
,

and the time.
(ISUG requirement me
etings,
High Priority)

2.2.10.11

Metadat
a reporting for quality control of metadata definitions and for quality
control of document metadata assignments. (ISUG requirement meetings, High
Priority)















Page
12

of
24

EFS Functional Requirements v0.2
11/7/2013


2.2.11

Other

2.2.11.1

EFS shall be available to 1400 AIR employees

(AIR Concept Pape
r, High
Priority)

2.2.11.2

EFS shall be available to
currently estimated 73
00 AVS employees

(AIR
Concept Paper, Deferred

for Release 1.0
)

2.2.11.3

EFS shall be available to an unlimited number of users external to the FAA (
AIR
Concept Paper, Deferred

for Release 1.0
)

2.2.11.4

EFS sh
all be 508 compliant.

(FAA Web Application Standards, High Priority)

2.2.11.5

EFS shall initially be

configured with the
following metadata fields for the
Letters
and

Memos document type
s
.
(ISUG requirement meetings & ITSG Approval,
High Priority)

1.

User who submits
the data into EFS

Required, captured automatically

2.

Approving Official (Name in title block)

Required, no default

3.

Prepared By (Person who created the content)

Optional

4.

Office

Required, captured automatically, defaults based on user

5.

File Code

Required, sele
ction of valid values from FAA IR
-
04
-
01A

6.

Disposition date


(When it can be destroyed or archived)

Required, defaults based on disposition dates identified for file
codes, cannot be modified

7.

Disposition Instructions

Required, defaults based on disposition
instructions identified for
file code, cannot be modified

8.

Access Rights

Required, Defaults to all, can be limited to office

9.

Recommended for future public viewing (?)

Required, Choose Yes/No, Default to No

10.

Subject

Required, free
-
form

11.


Applicant Provided I
nformation

Required, Choose Yes/No

12.


Keywords (Country, Regulation Part, etc.)














Page
13

of
24

EFS Functional Requirements v0.2
11/7/2013


Optional, free
-
form

13.

Date Signed Field

Required, default to system date

14.

Date Submitted



Required, System date automatically captured



2.2.11.6

EFS shall support an upload of 100,000

d
ocuments within the first year.

(ISUG
requirement meetings, High Priority)

2.2.11.7

EFS sh
all support an upload of 1 million

documents within the first 3 years.

(ISUG requirement meetings, High Priority)

2.2.11.8

EFS shall support 10

million documents once it is made availa
ble to all of AVS.

(ISUG requirement meetings, High Priority)

2.2.11.9

EFS shall support user
-
defined event
-
driven notification (alert service) of
documents for review (
AIR CONOPS, Low P
riority)


2.2.11.10

EFS shall be developed in accordance with FAA Web application standa
rds.


3

OPERATIONAL REQUIREM
ENTS

3.1

Security

3.1.1

User Security

The application interface shall assign and track various user security levels. The general
security model follows. The roles in the security model below include but are not limited
to those indicated. R
ole authority will be detailed in the EFS Systems Administrators
document.

The general security model is composed of the following attributes:



Personal identification and authentication



The role(s) assigned to the person



The organization(s) the person be
longs to



The organizational hierarchy



Any delegation authority extended to the person

The above model will control access and navigation within the EFS system.


3.2

Database Security

It is a requirement that all data that is part of the system not be inadver
tently disclosed or
accessible to unauthorized users. Transaction logs must be maintained by the system.
The logs should record user, time date, file accessed, report run, etc. The transaction
logs must be maintained in a secured condition that would pre
clude tampering.
Additionally, access to the logs should be controlled to only those specifically authorized
to read or edit the log














Page
14

of
24

EFS Functional Requirements v0.2
11/7/2013



3.3

Physical Security

EFS is designed so that many users will be accessing the system and its data from
portable computing de
vices. Should a portable computing device be lost or stolen, it is
essential that it cannot be used to access either the data within it or the data from the
central database. Should a lost or stolen computing devise be used to attempt access of
the central

database, some form of detection and forensic tracing of the attempt should
be available


3.4

Audit Trail

A
udit logs shall be accessible to system administrators. Access to system and
component audit logs shall be controlled and generally restricted to secur
ity personnel
and system administrators


3.5

Reliability

The system must be reliable to the following specifications:

The first year, (1) four hour delay (one time occurrence) and (2) one hour delays will be
allowable.

Every year there after, (2) one hour dela
ys will be allowable


3.6

Maintainability

The system must also be maintainable to certain specifications and parameters.
They are as follows:



Maintainable to meet the 60 minute down time



Data driven processes (i.e. all constants or tables of constants are
rev
isable by authorized users or administrators.)



Operational parameters must be changeable by the authorized owners of
the system


3.7

Availability

Availability refers to when and where the users of the system can access EFS.
Maintenance of the system will not
occur during the system core hours of 6:00AM EST
-

6:00PM PST, Monday thru Friday.


The system must be available to the system users, if a connection to the FAA
infrastructure can be established via the Intranet.

When a public interface is implemented,
the system will need to be available 24/7 exce
pt
during agreed upon
maintenance timeframes.














Page
15

of
24

EFS Functional Requirements v0.2
11/7/2013


3.8

Recovery

Recovery is defined as what is the user expectation for recovering data and getting the
system up and running if the system should go down. Recovery also

refers to restoring
data which has been erroneously modified.

The database will be backed
-
up on a daily basis.

If the system should go down, data
from the previous day will be restored.

3.8.1

Data Rollback

The data rollback process from the latest transaction
will be set at 10 minutes. If the
system becomes inoperable during a transaction, the transaction will not be completed.


3.8.2

Restoration of data

Transaction logs indicating additions, revisions, or deletions must be maintained in order
to restore data errone
ously changed. The logs should record, in addition to the data
revised: user name, time, date, and terminal/computer ID


3.9

Capacity

EFS shall support an upload of 100,000

documents within the first year. EFS sh
all
support an upload of 1 million

documents wi
thin the first 3 years.

EFS shall support 10

million documents once it is made available to all of AVS.


3.10

Data Retention

All data must be retained until disposition dates and activity determine otherwise. The
EFS system shall perform data retention and disp
osition according to the requirements
listed in section 2.2.8 of this document.


3.11

Enhanceability

The system is to be constructed so as to be flexible to the evolution of EFS. This
maintenance function is to be designed intuitively so that the maintenance f
unctions can
be performed without the intervention of application programmers. In this manner, the
application will continue to evolve and keep pace with the EFS process while remaining
structured around a consistent framework. Programming shall be modu
lar and/or object
based (data driven rather then hard coded).


3.11.1

Scalability

Scalability refers to the fluctuation of size and the system accommodations for it.

Given the appropriate network and services architecture, EFS shall be able to scale from
1400 i
nitial AIR users to accommodate 7300 AVS users and ultimately to an unlimited
number of external users.
















Page
16

of
24

EFS Functional Requirements v0.2
11/7/2013


4

REQUIREMENTS TRACEAB
ILITY MATRIX

See separate document EFS Functional Requirements Traceability Matrix.xls














Page
17

of
24

EFS Functional Requirements v0.2
11/7/2013


APPENDIX F

ACRONYMS, ABBREVIATI
ONS, AND GLOSSARY


AD

Airworthiness Directive

AIR

Aircraft Certification Service

ASKME

Aviation Safety Knowledge Management Environment

Assumption

A statement that is believed to be true in the absence of proof or definitive
knowledge.

Attribute

A characteristic

Author

An
EFS user who can read, submit, and edit information. This role can only
edit its own information.

AVS

Office of Aviation Safety



Business
Requirement

A high
-
level business objective of the organization that builds a product or of a
customer who procure
s it.

Business Rule

A policy, guideline, standard, or regulation that defines or constrains some
aspect of the business.



Catalog

The process of entering attribute information (metadata) about information
(e.g., title, subject, document type, author,

date created, version number).

ConOps

Concept of Operations

Constraint

A restriction that is imposed on the choices available for the design and
construction of a product.

COTS

Commercial
-
off
-
the
-
shelf

Crawl

To search the web for web pages relevant to

search criteria.

Cut
-
off Date

The date when a file is “closed” and the retention period begins.



DIN

Designee Information Network

Disposition
Instructions

Instructions for what to do with data once the retention period has expired
(e.g., destroy, tr
ansfer for permanent storage).

DOT

Department of Transportation

DPC

Designee Process Coordinator



Editor

An EFS user who has the ability to read, submit, and edit information. This
role can edit their own and other EFS users’ information.

EFS

Elect
ronic File Service
















Page
18

of
24

EFS Functional Requirements v0.2
11/7/2013


EFS User

An entity that interacts with EFS. Examples of ‘EFS user’ include applications,
other services, and in some instances, individuals.


FAA


Federal Aviation Administration

File Codes

Codes outlined in the “Reco
rds Management Requirements Manual”


FAA
Order FAA
-
IR
-
04
-
01 that are attached to FAA files.

FOIA

Freedom of Information Act

Functional
Requirement

A statement of a piece of required functionality that is specified or built into a
product.



GOTS

Gover
nment
-
off
-
the
-
shelf



Index

The process of
reading data and storing the words contained in the data to
allow the data to be searchable.

Information

The term “information” as used in this document refers to various types of
information used by AIR (e.g.
, paper
-
based documents, official records, and
electronic
-
based information like e
-
mails).

Input

The process of uploading electronic information into EFS.

ISUG

Information System User Group



Metadata


Data about data. In data processing, metadata is d
efinitional data that
provides information about or documentation of other data managed within an
application or environment.


For example, metadata would document data about data elements or attributes,
(name, size, data type, etc) and data about records
or data structures (length,
fields, columns, etc) and data about data (where it is located, how it is
associated, ownership, etc.). Metadata may include descriptive information
about the context, quality and condition, or characteristics of the data.



N
ARA

National Archives and Records Administration

Non
-
functional
Requirement

A description of a property or characteristic that a software system must
exhibit or a constraint that it must respect other than an observable system
behavior.



Output

The pro
cess of displaying, printing, saving, and/or disposing of information.



“Passive”
A service that does not actively “prompt” users to take action.














Page
19

of
24

EFS Functional Requirements v0.2
11/7/2013


Service

Process

A sequence of activities performed for a given purpose.



Reader

An EFS user who has t
he ability to read information submitted by other
individuals.

Requirement

A statement of a customer need or objective, or of a condition or capability that
a product must possess to satisfy such a need or objective.

Retention
Period

The length of time t
o store information before disposition.

Retrieve

The ability to view information stored in EFS.

RGL

Regulatory and
Guidance Library



SDLC

System Development Lifecycle

Search

The process of locating information stored in EFS by specifying keywords.

Security

Ensuring that data stored in a computer cannot be read or compromised by any
individuals without authorization.

Single Sign
-
on

A feature that will allow authorized users who are already signed on the FAA
network to access EFS without having to s
ign
-
on to EFS.

Spider

A program that automatically fetches web pages. Spiders are used to feed
pages to search engines.



UAT

User Acceptance Testing

Unit Testing

Tests that evaluate the integrity of software code units before they are
integrated wi
th other software units.

User Class

A group of users for a service who have similar characteristics or requirements
for the service.



Workflow

The defined series of tasks within an organization to produce a final outcome.