System Name

Functional Specifcation
Date: 18 October 2014
Functional Specifcation
System Name
Release: Draft/Final
Date: DD !!!
"ut#ors: $$$$$
24800%28&'(oc )a*e 1
System Name
Functional Specifcation
Date: 18 October 2014
1 Report History
Document Location
+#is (ocument is only ,ali( on t#e (ay it -as printe('
+#e source of t#e (ocument -ill be foun( at $$
Revision History
Revision date Author Versio
n
Summary of Chanes Chanes
mar!ed
Approvals
+#is (ocument re.uires t#e follo-in* appro,als:
Name "itle Date of
#ssue
Version
Distri$ution
+#is (ocument #as a((itionally been (istribute( to:
Name "itle Date of #ssue Status
24800%28&'(oc )a*e 2
System Name
Functional Specifcation
Date: 18 October 2014
"a$le of Contents )a*e
1 Report /istory 2
1'1 Document 0ocation1111111111111111111111111111111111111111111111111111112
1'2 Re,ision /istory1111111111111111111111111111111111111111111111111111111112
1'2 "ppro,als1111111111111111111111111111111111111111111111111111111111111112
1'4 Distribution111111111111111111111111111111111111111111111111111111111111112
2 )urpose 4
2 3ac4*roun( 4
4 etrics 4
& Scope 4
&'1 5n Scope111111111111111111111111111111111111111111111111111111111111111114
&'2 Out of Scope111111111111111111111111111111111111111111111111111111111111&
% +imescales an( )riorities &
6 Summary of 3usiness Re.uirements &
8 )olicy an( 5ssues &
7 Summary of Functional "reas &
10 Functional Re.uirements by o(ule %
10'1 o(ule 1 : )RO811111111111111111111111111111111111111111111111111111111%
11 Screens an( 9or4:o-s 6
12 ;ser 5nterface Description 6
12 5nterfaces to ot#er systems 6
14 Reportin* 6
1& ;sers an( Security 6
1% System a(ministration an( maintenance 6
16 Non<Functional Re.uirements 8
18 "ppen(ices 8
24800%28&'(oc )a*e 2
System Name
Functional Specifcation
Date: 18 October 2014
% &urpose
+#e purpose of t#is (ocument is to summarise t#e functional re.uirements of ='
5t is not a system solution> but a *ui(eline of t#e re.uire( system functionality'
+#e (ocument sets out (etail of
etrics
;ser types
+#e mo(ules
;ser tas4s
Functional re.uirements of eac# mo(ule'
' (ac!round
3ac4*roun( information to t#e pro?ect'
) *etrics
+#e system is re.uire( to cater for t#e follo-in* appro=imate current ,olumes>
@base( on f*ures from !A"RB
+,A*&L+
Ne- stu(ents re*istere( per annum 4>400
/istoric re*istere( stu(ents 140>000
Ne- en.uirers per year 400
Course mana*ers an( (esi*ners accessin* t#e
system
22
- Scope
#n Scope
.ut of Scope
/ "imescales and &riorities
When are diferent functional areas of the software required by and what are the
business/operational reasons?
24800%28&'(oc )a*e 4
System Name
Functional Specifcation
Date: 18 October 2014
0 Summary of (usiness Re1uirements
Summary of business requirements that have been selected for this phase of
development following review of the Statement of Requirements, with:
brief descriptions
priority
cross reference to the Statement of Requirements
!ptionally could include details of requirements identi"ed in the Statement of
Requirements that have not been selected #for this phase of wor$% and reasons
why& 'owever this might be placed in the (ppendices #see "nal section below%&
2 &olicy and #ssues
)articular points to consider that may in*uence the development& +ecisions
regarding why it should be done in one way and not in another way&
3 Summary of Functional Areas
,rief summary of $ey functions required - if possible with diagram illustrating
the relationship between them&
24800%28&'(oc )a*e &
System Name
Functional Specifcation
Date: 18 October 2014
14Functional Re1uirements $y *odule
+#is section sets out t#e functional re.uirements of t#e system by mo(ule' 5t
-oul( inclu(e (etails of 4ey functions t#at t#e system must perform:
< Dey processes @inclu(in* bul4 processes> -or4:o-s etcB
< Creation/"men(ment/Deletion of recor(s
+#e re.uirements set out #ere are ran4e( in *oSCo5 or(er:
E ust /a,e
S E S#oul( /a,e
C E Coul( /a,e
9 E 9oul( li4e to #a,e
+,A*&L+ #may wish to ma$e this section landscape%
*odule 1 6 &R.7
+o mana*e an( a(minister an o,erall )ro*ramme for a Department
Functi
on #d
18 &R.7RA**+ Functional
description
&riority
Level
9*oSCo
5:
;ey
Analysis
&oints<Not
es
(usiness
Re1uirem
ent 9in
SoR:
1'1 "llo- (epartment CA mana*ers
an( /ea(s to ,ie- on<screen an(
report #istoric information of
courses run in t#e (epartment'
+o inclu(e for eac# course run
from t#e (epartment an( a
summary for t#e (epartment
alto*et#er:
Courses ran t#at year
Courses cancelle(
Stu(ent numbers enrolle(
@actual an( F+AB in total>
inclu(in* -it#(ra-als

1'2 "bility to select> cut an( paste

24800%28&'(oc )a*e %
System Name
Functional Specifcation
Date: 18 October 2014
11Screens and 5or!=o>s
.or an internal development the .unctional Speci"cation should contain details
of the screens required with:
< ,asic moc$ ups
< /in$s to processes de"ned in the .unctional (reas
< +etails of the wor$*ow between the screens, i&e& data *ow, inputs and
outputs
0n the case of amendments/enhancements to e1isting systems #either internally
or e1ternally provided% the .unctional Speci"cation might include suggestions for
changes to e1isting screens which are already in operation in order to meet
business requirements&
1%?ser #nterface Description
Whilst the ,usiness (nalyst will not be designing the 2ser 0nterface for a new
system, the .unctional Speci"cation should include a description of the e1pected
2ser 0nterface&
1'#nterfaces to other systems
0nterfaces required to other systems should be detailed, with information about
the nature of the interface and of each system concerned&
1)Reportin
+etails of any reports required including:
< Selection criteria
< Sorting and subtotalling criteria
< 3alues to be shown in output columns
4he intended recipients of each report should be recorded&
1-?sers and Security
+iferent types of users/user roles
2ser permissions - i&e& where permissions are required to access:
< Speci"c processes
< Speci"c data
1/System administration and maintenance
'ow will base data in the system #e&g& users, parameters% be maintained and by
whom? Who is the owner of the data?
24800%28&'(oc )a*e 6
System Name
Functional Specifcation
Date: 18 October 2014
10Non@Functional Re1uirements
Where identi"ed, relevant 5on.unctional Requirements #requirements that do
not specify what the software functions should do, but how the software should
operate% should be speci"ed& 0deally there should be some descriptive detail that
will allow assessment of whether the requirement has been met #e&g& response
time in the case of performance%&
( chec$list of nonfunctional requirements can be found in GGis<
app1'a(min'bris'ac'u4GusersGstrate*ic<pro?ectsG"nalysis an( De,elopment
)roce(ures '
5on.unctional Requirements should have already have been included in the
SoR but these should be reviewed and amended if necessary for this document&
12Appendices
4hese might include:
< +ata catalogue where applicable Where appropriate details of new data
"elds that need to be created and how they might be grouped into or
added to a table and why
< +etails of requirements identi"ed in the SoR but e1cluded from this phase,
with reasons why
24800%28&'(oc )a*e 8