Functional Requirements

Programme UCAS Policy and Communications Project Author Version No EFIFA - Effective Feedback to Improve Fair Admissions Neil England !"

This document has been prepared by the Programme Unit. This document contains confidential information regarding the functional requirements of UCAS for the E ! A pro"ect. All information shall remain the shared property of UCAS and #!SC and the recipient is e$pected to hold this information in the strictest confidence. %y receipt and revie& of this document you agree to these terms of confidentiality.

Functional Requirements

#a$le o% Contents
' (ocument housekeeping.................................................................................................... ) * !ntroduction......................................................................................................................... + *.' %ackground............................................................................................................. + *.* (ocument Purpose.................................................................................................. , *.) -igh .evel Scope..................................................................................................... , *.+ Assumptions............................................................................................................ / *., 0vervie&................................................................................................................. / ) unctional 1equirements.................................................................................................... 2 ).' 3umber of Users 4 Anticipated (ata 5olatility.........................................................2 ).* Accessing The Screen6s7......................................................................................... 2 ).) Security................................................................................................................... 2 ).+ unctionality........................................................................................................... 8 '9 )., 1eporting.............................................................................................................. '* )./ !nterfaces.............................................................................................................. '* ).2 (ata Cleansing Considerations.............................................................................'* ).8 (ata :igration Considerations..............................................................................'* + 0utstanding !ssues........................................................................................................... ') APPE3(!CES........................................................................................................................ '+ Screen Prints.............................................................................................................. '+

';2;)9;+;.doc

5ersion '.9

Page * of **

Functional Requirements &ocument house'ee(ing Change Control (ate 16/01/2009 05/02/2009 0/0!/2009 Reviewed by (ate 3ame #eslie $%rrie David *organ (lan 'a%ll ,eoff "amshaw (ndrea "o-ertson *atthew /illard Position &'( liaison and e)pert adviser &enior &%pplier 'ro+ect *anager 'ro+ect E)ec%tive &enior .ser #ead Developer Author Neil England Neil England Neil England 5ersion 0.1 0.2 1.0 Change 1eference First Draft Following initial review and amendments to technical approach "eflection of what was delivered

Distribution 3ame Position

Status This version of the document is< Location The location of this document is< /var/www/apps/conversion/tmp/scratch0!/1919 09!9.docDept2 'ro+ects3EF4F( 2 (pplicant Feed-ac5310(nal6sis31. 0F%nctional "e7%irements Draft

';2;)9;+;.doc

5ersion '.9

Page ) of **

Functional Requirements ) Introduction )! *ac'ground 8he &chwar9 "eport :Fair Admissions to HE: Recommendations for Good Practice ;200!< listed five principles of a fair admissions s6stem= of which the first was that a fair admissions s6stem sho%ld -e transparent. (s well as providing the information applicants needed to ma5e an informed choice of co%rse= transparenc6 was considered to incl%de a mechanism for providing feed-ac5 to applicants> Institutions should conduct and publish a periodic analysis of admissions data, and pro ide feedbac! on re"uest to unsuccessful applicants 4n accordance with this principle= in Fe-r%ar6 200? the &%pporting 'rofessionalism in (dmissions gro%p ;&'(< p%-lished a &tatement of ,ood practice on Feed-ac5 to .ns%ccessf%l (pplicants= following cons%ltation with the sector which started in *a6 2001. 8he &'( &tatement of ,ood 'ractice provides a detailed development of the transparenc6 principle= with si)teen sections related to the p%-lication of clear criteria for decision ma5ing on applications and to the provision of feed-ac5 to %ns%ccessf%l applicants. 4n the earl6 development of this statement &'( colla-orated in the wor5 of a @4&$2f%nded .$(& scoping st%d6= which investigated the wa6 in which feed-ac5 was provided to applicants for emplo6ment= as a possi-le model for AE. 8his st%d6= which was completed in *arch 2001= concl%ded that emplo6ersB processes for providing s%ch feed-ac5 had not reached an6 higher level of development than the -est AE practice of the time. Aowever= as a res%lt of the investigations= the st%d6 was a-le to ma5e seven specific recommendations a-o%t good practice in the field and findings were s%mmarised in an aspirational view of good practice= la-elled an :AE (pplication *odelB. 8his &tatement of ,ood 'ractice and the findings of the scoping st%d6 form the -ac5gro%nd to this pro+ect. 8he pro+ect see5s to improve and enco%rage fairness in admissions to AE -6 investigating the provision of high27%alit6 feed-ac5 to applicants on their application to AE= whilst minimising the additional administrative -%rden placed on instit%tions. Cne of the 5e6 concl%sions of the scoping st%d6 has partic%lar relevance for this pro+ect> For applicants applyin# throu#h $%A& there is a pro#ression throu#h a centralised system, 'hich permits three distinct rounds of application for a particular year of entry, up to si( initial choices )this 'ill be * from +,,- entry. and, if unsuccessful, follo'ed by further choices in E(tra and, finally, choices in %learin#/ 0he pro#ression pro ides a structure, throu#h 'hich the applicant can impro e performance, in respect of applications to different HEIs and in some cases the same ones, or e en sometimes the same course/ For school and colle#e lea ers the process mi#ht be stron#ly supported by staff in the feeder establishment, 'ho are 'ell placed to act as a#ents for the applicant/ 0hese factors increase the demand for feedbac! and probably its efficacy/ 8he implication of the a-ove is that the %ni7%e feat%res of the .$(& application process co%ld allow a response to feed-ac5 -6 an applicant within the same application cycle= allowing an applicant to tailor and direct s%-se7%ent applications so as to ma)imise the chance of s%ccess. (s a res%lt of developments at .$(&= it is alread6 possi-le for instit%tions to s%ppl6 some feed-ac5 to %ns%ccessf%l applicants for 2009 entr6 thro%gh the .$(&= $.D(& and ,88" schemes. 8his has -een achieved -6 %se of an amended decision with the addition of free te)t= or an instit%tion2specific a--reviation providing details of the feed-ac5. 'art of the pro+ect will -e to investigate whether this process co%ld or sho%ld -e f%rther developed.

';2;)9;+;.doc

5ersion '.9

Page + of **

Functional Requirements )!)&ocument Pur(ose 8he p%rpose of this doc%ment is to> Define the f%nctional re7%irements of the EF4F( protot6pe Doc%ment formal acceptance of these re7%irements.

)!+,igh -e.el Sco(e )!+! Included in Sco(e 8he a-ilit6 for each instit%tion/%ser to maintain a data-ase of predefined te)t= 5e6ed -6 code= which is accessed to provide feed-ac5 to the (pplicant o 8he data-ase sho%ld -e men% driven -6 the t6pe of %ser and= in the case of AE4s= instit%tion= fac%lt6 and co%rse= th%s introd%cing a high level of fle)i-ilit6 in -oth the te)t maintenance and s%-se7%ent %se o $onsideration will -e given to the -%l5 feed of $odes and associated te)t in parallel with 12221 maintenance thro%gh we-lin5 or similar 8he a-ilit6 to provide free format te)t as feed-ac5 to the (pplicant 8he a-ilit6 for an instit%tion/%ser to provide feed-ac5 via a com-ination of predefined and free format te)t 8he a-ilit6 for an instit%tion/%ser to provide feed-ac5 at the point of EDecisionE or at a later date= in response to an (pplicantEs re7%est for feed-ac5 or greater feed-ac5 o $onsideration will -e given to the processing of F%l5 Feed-ac5 in the form of a .csv file= 5e6ed -6 (pplicant N%m-er 8he a-ilit6 for an (pplicant to view their decisions and an6 associated Feed-ac5 'rod%ction of doc%mentation to ena-le each instit%tion/%ser to %tili9e the protot6pe. ( national set of codes and associated paragraphs 8he a-ilit6 for an (pplicant to re7%est feed-ac5 via .$(& 8he a-ilit6 for an (pplicant to re7%est a cop6 of Feed-ac5 to (dviser= &chool= $ollege etc. 'resentation of decisions and associated feed-ac5 to a $%stomer &ervices .nit ;or similar<. 8ime to complete the design and development and meet the @4&$ deadline of deliver6 -6 9th *arch 2009 ma6 limit the scope of the protot6pe (ss%ming the protot6pe is deplo6ed on a server at &8(" ;.$(& Disaster "ecover6 site in ,lo%cester<= in the event of Disaster "ecover6 -eing re7%ired= the service will= pro-a-l6= -e lost.

)!+!) E/cluded %rom Sco(e

)!+!+ Constraints

';2;)9;+;.doc

5ersion '.9

Page , of **

Functional Requirements )!0 Assum(tions 8he development will -e carried o%t -6 a contractor= as s%ita-le reso%rce is not availa-le from the Digital &ervices developer pool within the timescales re7%ired 8he protot6pe will -e developed in *6&G# and deplo6ed %sing 8C*$(8 8he protot6pe will -e deplo6ed on a server at &8(" ;.$(& Disaster "ecover6 site in ,lo%cester< 8he EF4F( protot6pe ma6 reside at &8(" for 22 6ears in order to complete the @4&$ eval%ation. &eli.era$les ( data-ase of predefined te)t= 5e6ed -6 code= which will -e men% driven -6 the t6pe of %ser and= in the case of AE4s= instit%tion= fac%lt6 and co%rse (n (pplications data-ase 4nstit%tion/.ser interfaces for o 8he maintenance of 'redefined 8e)t o "eading (pplications o *a5ing Decisions o 'roviding Feed-ac5 ( %ser interface for (pplicants to view their decisions and an6 associated Feed-ac5 Doc%mentation that ena-les each instit%tion/%ser to %tili9e the protot6pe.

)!0!

)!12.er.ie3 Deliver6 of the pro+ect is -ro5en down as follows> 'hase 1 H F%nctional "e7%irements 'hase 2 H Design 'hase H F%ild 'hase ! H 8est 'hase 5 H "elease 'hase 6 H /arrant6

';2;)9;+;.doc

5ersion '.9

Page / of **

Functional Requirements + Functional Requirements +! Num$er o% Users 4 Antici(ated &ata Volatility 8he proposed s6stem will -e a protot6pe for demonstration p%rposes= hence= the n%m-er of conc%rrent %sers will -e small ;I10<. E7%all6= the data-ases will -e relativel6 small and= altho%gh data ma6 change fre7%entl6= the vol%me of changes will -e small. +!)Accessing #he Screen5s6 8he screens will -e accessed via a ."#= which the .ser will call from a we- -rowser. http>//research.%cas.com/efifa/ +!+Security 4n a EliveE sit%ation an 4nstit%tion/.ser sho%ld onl6 -e a-le to see (pplications= which are applica-le to them= for instance (n (pplicant to .niversit6 ma6 ma5e %p to 5 $hoices= which ma6 -e at 5 different instit%tions. 4n this case= an 4nstit%tion ma6 onl6 see the (pplication to their 4nstit%tion. F%rther Ed%cation $olleges and Emplo6ers have m%ch more of a 12221 relationship with their (pplicants= -%t= if the protot6pe s6stem is deplo6ed across man6 %ser t6pes= (pplications sho%ld onl6 -e viewa-le -6 those for whom the6 were intended. Aowever= for the p%rposes of the protot6pe/demonstrator= s%ch sec%rit6 is= pro-a-l6= not necessar6= as 2 (ll scenarios and associated names will -e fictitio%s 2 8here will -e advantages in -eing a-le to demonstrate all scenarios= e.g. a AE4 ma6 -e interested in what is delivered for an Emplo6er< 8o accommodate this= it will -e necessar6 to select of instit%tion or applicant from a list= there-6 removing the need for login credentials= -%t= also= show the f%ll f%nctionalit6.

';2;)9;+;.doc

5ersion '.9

Page 2 of **

Functional Requirements +!0Functionality 3.4.1 Pre-defined Text Maintenance

3.4.1.1

Business Rules

Each instit%tion/%ser needs to -e a-le to maintain a data-ase of predefined te)t= 5e6ed -6 code= which is accessed to provide feed-ac5 to the (pplicant o 8he data-ase sho%ld -e men% driven -6 the t6pe of %ser and= in the case of AE4s= instit%tion= fac%lt6 and co%rse= th%s introd%cing a high level of fle)i-ilit6 in -oth the te)t maintenance and s%-se7%ent %se o 4nitiall6= 12221 maintenance will -e s%pported via a set of screens= which will permit the .ser to Delete= (dd or *odif6 the $odes and associated te)t o Aaving selected their instit%tion= -6 scrolling down a list and highlighting it= the instit%tion representative will -e presented with new BscrollingB -o)es>
5ersion '.9 Page 8 of **

';2;)9;+;.doc

Functional Requirements 1. $ontaining statements relating to the 4nstit%tion in general. 2. $ontaining statements relating to (## Fac%lties in the instit%tion. . $ontaining statements relating to (## $o%rses in the instit%tion. o $onsideration will= also= -e given to the -%l5 feed of $odes and associated te)t= pro-a-l6= via a .csv file= together with an (ctivator ;D J Delete= ( J (dd= *J *odif6<. N.F. 8he c%rrent EliveE .$(& $onditions maintenance s6stem s%pports the addition of new $onditions or the editing of e)isting $onditions= -%t new ones are a%tomaticall6 given the ne)t $ode in se7%ence and added to the -ottom of the list. 4f time permits= consideration sho%ld -e given to enhancing the proposed str%ct%re with the a-ilit6 to select a $ode to -e %sed for the ne)t $ondition= rather than a%tomatic allocation of the ne)t $ode in se7%ence.

';2;)9;+;.doc

5ersion '.9

Page ; of **

Functional Requirements 3.4.2 The eed!ac" Process

3.4.2.1 #ddin$ the eed!ac" 8he (dmissions officer= or similar representative ;.ser<= will have access to a screen into which the6 ma6>
';2;)9;+;.doc 5ersion '.9 Page '9 of **

Functional Requirements 2 /rite EFree 8e)tE 2 $all 1 or more pre2defined &tatements from an6 of lists> 1. &tatements relating to the 4nstit%tion in general= 2. &tatements relating to (## Fac%lties in the instit%tion= . &tatements relating to (## $o%rses in the instit%tion= i.e. no limit on the n%m-er of pre2defined &tatements selected 2 4ntersperse an6 of the pre2defined &tatements with additional EFree 8e)tE. N.F. 8he :idealB sit%ation wo%ld -e= for -oth maintenance and calling f%nctions= to offer the %ser the a-ilit6 to enter the Fac%lt6= e.g. #aw= then onl6 #aw related Fac%lt6 and $o%rse statements will -e presented for maintenance or calling. Aowever= it will not -een possi-le to incl%de this level of sophistication in the first release of the protot6pe.

3.4.2.2 %ditin$ 1. 'ermit editing of te)t on the preview screen followed -6 K&end Feed-ac5 to (pplicantK. 2. 'ermit the %ser to ret%rn to the E$allingE screen= where the original com-ination of EFree 8e)tE and pre2defined &tatements will -e displa6ed for ad+%stment. N.F. 4f the .ser adds EFree 8e)tE to the preview screen and then ret%rns to the E$allingE screen= their changes will -e lost. 8o preserve preview screen changes is possi-le= however= it will not -een possi-le to incl%de this level of sophistication in the first release of the protot6pe.

3.4.2.3 &cenarios 8he (pplication Data-ase will need to accommodate (pplication details= which meet the following scenarios> (pplicants who have completed the f%ll c6cle of application to an instit%tion= with a decision and/or feed-ac5 (pplicants who have completed the f%ll c6cle of application to a compan6= with a decision and/or feed-ac5 (pplicants who have completed a part c6cle of application to an instit%tion= with no decision or feed-ac5 (pplicants who have completed a part c6cle of application to a compan6= with no decision or feed-ac5. N.F.1. 8he scenarios o%tlined a-ove are defined at a high level= the details of which will -e -%ilt in a separate doc%ment. N.F.2. 8he scenarios need to -e demonstra-le on a laptop at a .serEs site. 4n addition= the6 m%st -e accessi-le and maintaina-le -6 a .ser from their site to a server at &8(" ;.$(& Disaster "ecover6 site in ,lo%cester<. 3.4.2.4 #pplication 'ata!ase #ttri!utes 8he following are the minim%m data re7%irements re7%ired to s%pport the scenarios o%tlined a-ove (pplicant N%m-er (pplicant Name (pplicant $ontact (ddress= incl. 'ostcode Email (ddress ;not necessaril6 pop%lated< G%alifications achieved to date F%t%re G%alifications 2 /hat= /hen and associated 'redicted ,rades 'ersonal &tatement $hoices 4nstit%tion/.ser
';2;)9;+;.doc 5ersion '.9 Page '' of **

Functional Requirements o Decision o Feed-ac5 (pplicant o "epl6 3.4.2.( )orrespondence with the #pplicant 8he flowchart a-ove omits something= which c%rrentl6 happens in the .$(& EliveE s6stem and ma6 -e possi-le to demonstrate= in a similar manner= in the protot6pe= -%t is not considered essential in the first iteration> /henever= the (pplication Data-ase is %pdated with a Decision and/or Feed-ac5 the (pplicantEs (pplication sho%ld -e e)amined to see if an email address is present 4f an email address is present= send an email to the (pplicant= containing the Decision and/or Feed-ac5 4f an email address is not present= send a letter to the (pplicantEs contact address= containing the Decision and/or Feed-ac5. +!1Re(orting 'erformance anal6sis will -e re7%ired some time ;8F(< after the protot6pe is la%nched. 8his anal6sis will cover s%ch things as> /hich instit%tions %se the service /hich other -odies %se the service /hat is their vol%me of %se /hat are their reactions to %sing the s6stem /hat is EcommonE Feed-ac5 Aowever= how and when this reporting will -e prod%ced is still %nder disc%ssion at this time ;1 th @an%ar6 2009<. +!7Inter%aces 8his will -e a stand2alone protot6pe= hence= there sho%ld -e no need for interfaces with specific e)ternal s6stems. Aowever= there will need to -e %ser interfaces for 4nstit%tions/.sers for o 8he maintenance of 'redefined 8e)t o "eading (pplications o *a5ing Decisions o 'roviding Feed-ac5 (pplicants to view their decisions and an6 associated Feed-ac5. N.F. (pplicants ma6 re7%est Feed-ac5 or (dditional Feed-ac5= -%t the6 will -e re7%ired to contact the 4nstit%tion/.ser directl6. +!8&ata Cleansing Considerations 4f this was a Eprod%ctionE s6stem= personal information wo%ld Enormall6E -e 5ept for no more than 2 (pplication $6cles= according to the agreement -etween .$(& and the AE4s and that entered into with the (pplicants. 8his ma6 var6 for other E.sersE in the f%t%re= e.g. FE $olleges= Emplo6ers. Aowever= this is a Eprotot6peE s6stem and personal information will -e fictitio%s or anon6mised. Aence data cleansing sho%ld not -e a consideration. +!9&ata :igration Considerations Not applica-le= as this is a protot6pe= not a prod%ction= s6stem.

';2;)9;+;.doc

5ersion '.9

Page '* of **

Functional Requirements 0 2utstanding Issues

Action Update screen te$t accordingly &ate Resol.ed

Issue Some screen te$t does not reflect the latest design of the process flo&s.

(etail of issue

The action taken to resolve

';2;)9;+;.doc

5ersion '.9

Page ') of **

Functional Requirements APPEN&ICES Screen Prints ,ome Page

';2;)9;+;.doc

5ersion '.9

Page '+ of **

Functional Requirements :aintain Pre-&e%ined Fields - Select ;our Institution

';2;)9;+;.doc

5ersion '.9

Page ', of **

Functional Requirements :aintain Pre-&e%ined Fields - Institution Page

';2;)9;+;.doc

5ersion '.9

Page '/ of **

Functional Requirements :aintain Pre-&e%ined Fields - ty(ical :odi%y Screen

';2;)9;+;.doc

5ersion '.9

Page '2 of **

Functional Requirements Sta%%< =i.e Feed$ac'

';2;)9;+;.doc

5ersion '.9

Page '8 of **

Functional Requirements Select A((licant and %rom< Vie3> &ecide> Feed$ac'

';2;)9;+;.doc

5ersion '.9

Page '; of **

Functional Requirements #y(ical Feed$ac' 5%rom the (aragra(hs a.aila$le in the test data$ase6

';2;)9;+;.doc

5ersion '.9

Page *9 of **

Functional Requirements Students< Vie3 Feed$ac' - All ;our A((lications

';2;)9;+;.doc

5ersion '.9

Page *' of **

Functional Requirements Students< Vie3 Feed$ac' - Feed$ac' %rom chosen A((lication

';2;)9;+;.doc

5ersion '.9

Page ** of **