Sad Use Case

Only available on StudyMode
  • Topic: Register, Education, Registration
  • Pages : 16 (3705 words )
  • Download(s) : 9
  • Published : March 16, 2013
Open Document
Text Preview
Starting point: the overall HE-Business Process Diagram

[pic]

Overview of Use Cases within the various Business Processes.

BP: Enrolment (ENR)
• ENR1: Enroll in the university
• ENR2: Enroll in a study year
• ENR3: Enroll in (individual) courses

BP: Course Development (CD)
• CD1: Register a study
• CD2: Add courses to a study year
• CD3: Register a course

BP: Facilitating Activities (FA)
• FA1: Register organizational unit
• FA2: Register staff member

BP: Education Process
• EP1: Register test results
Use Case ENR1: enroll in the university (belongs to BP: Enrolment)

[pic]

Goal: to register a new student at the university

Primary actor: applicant (to become a student)

Stakeholders and their interests:
- Student: wants to start university studies, and therefore wants to be registered properly for a given study. - University: wants to have students registered in a uniform, structured way. - Registrar: wants a smooth and efficient administration (registration) process, with minimal efforts and disturbances.

Pre-conditions:
- Basic data on studies already registered in the system, since a student always registers for a (at least one) study. Post-condition: student properly registered for a study.

Happy Path (main scenario)
1. Applicant present him/herself at the registrar administration desk. 2. Registrar controls whether the applicant is eligible for application [BRENR1.1] 3. Registrar hands over an application form to the applicant [Alt course A] [Alt course B]. 4. Applicant fills in the application form

5. Registrar controls the application form (all required items filled in, in the correct way, according to BR’s) [Alt course C] [Alt course D]. 6. Registrar registers the form data in the system (“fees paid” not checked) [Alt course E] [Alt course F] 7. System generates student ID

8. System executes “enrollment in study year” component. 9. System calculates fees.
10. Applicant pays fees to registrar [BRENR1.2] [Alt course G] [Alt course H] [Alt course I] . 11. Registrar makes the registration definitive, i.e. enters amount of fees paid and checks “fees paid” indication. 12. System executes the “update fees balance” component. 13. System produces a confirmation of registration and (including) a receipt of fees payment. 14. Registrar hands over confirmation of enrolment and receipt of fees payment to the student. Alternate course A: in case of an electronic application form A3. Registrar indicates electronic form to applicant (PC, terminal) A4. Applicant fills in the application form

A5. System controls the application form (all required items filled in, in the correct way, according to BR’s) A6. System registers the form data (“fees paid” indication unchecked) From here on (step 7) the main scenario executes.

Other alternative courses/extensions

Alternate course B: applicant not eligible to enrol in university B3 Registrar informs student about reasons
B4 Use case ends unsuccessfully.

Alternate course C: Information not filled in or wrongly filled in and applicant has correct information available C5a Registrar handles back the form to the student for correction C5b Student corrects information

(below in case of electronic form)
C5a System warns student to correct information (in case of electronic form) C5b Student corrects information
From here onthe main scenario (step 6) executes.

Alternate course D: information not filled in or wrongly filled in and applicant has information not directly available D5a Registrar informs the applicant about the BR for supply of missing information [BRENR1.3.]

Alternate course E: Not all information available
E6a Registrar enters data with “Form complete” indication unchecked. (below: in case of electronic form)
E6a System registers data with “Form complete” indication unchecked (in case of electronic...
tracking img