Documents

Use_Cases

Categories
Published
of 15
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Description
good examples
Transcript
  Starting point: the overall HE-Business Process Diagram 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 )   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 unche cked (in case of electronic form) E6b System indicates deadline for providing missing information. E6c1 Applicant provides missing data according to BR. E6c2 Applicant does not provide missing data according to BR. E7 Registrar deletes form E8 use case ends unsuccessfully. Alternate course F: preliminary exam needed    F6a Registrar enters data; “preliminary needed” indication checked   F6b. Registrar provides information (where, when, etc…) on the preliminary to student.   (below: in case of electronic form)   F6b System provides information (where, when, etc…) on the preliminary to student. F6c Applicant (after taking the preliminary) provides preliminary result to registrar. F7 In case of failure for preliminary: registrar deletes applicant information F8 Use case ends unsuccessfully. In case preliminary has been passed succesfully: main scenario (step 7) continues Alternate course G: applicant pays fees electronically or by CC   G10a Applicant pays immediately on line or by credit card G10b System invoke s “Handle credit/electronic payment” component.   From here on the main scenario (step 10) executes.   Alternate course H: student cannot pay now and (wants to) pay(s) later   H10a. Student indicates he/she wants to pay later H10b Registrar informs the student about modalities for payment [ BRENR1.2]   H10c Student pays (at a later time) H10d Student comes back to the registrars office with receipt of payment document. From here on the main scenario (step 10) executes.   Alternate course I: student does not pay (enough or in time) I10 Student does not pay I11 Data deleted from system I12 Use case ends unscuccessfully.  Use Case ENR2: enroll in a study year (belongs to BP: Enrolment )   Goal:  to register a student for a given study year. Primary actor:  student Stakeholders and their interests: - Student:  wants to be registered properly for a given study year. - Faculty/department (responsible unit for the study):  wants to have students registered for each year in a uniform, structured way. - Registrar:  wants a smooth and efficient administration (registration) process, with minimal efforts and disturbances. Pre-conditions: - Basic data on curricula structure and individual courses for the study year in question already registered in the system. Post-condition:  student properly registered for a study. Happy Path (main scenario) 1. Student goes to an ARIS-authorized work station and starts up the ARIS. 2. Student authenticates him/herself through the authentication component (log in). 3. Student starts up the “enrol in study year” component.   ======== here start the process steps also used in the “enrol in university” use case ==========  4. Student indicates for which study and study year he/she wants to register. 5. System checks whether student is eligible for the study year in question [ BRENR2.1][ BRENR2.2] [Alt course A] 6. System executes “enrolment in courses” component for all compulsory courses of the study year. 7. System presents the “compulsory from list” courses for the given study year with their BR's to the student for choice [ BRENR2.3]  8. Student picks courses from the list. 9. System executes “enrolment in courses” component for the picked courses.  10. System registers (saves) study year data for the student in question (“fees paid” not checked). 11. System executes “add to turma” component in case of 1st study year   [BRENR2.4]  12. System calculates fees and informs student about fees to be paid [ BRENR2.5]   ========= here end the process steps also used in the “enrol in university” use case ==========   13. Student pays fees to the registrar [ BRENR2.5] [Alt course B] [Alt course C] [Alt course D]   14. Registrar makes the registration definitive, i.e. enters amount of fees paid and checks “fees paid” indication.  
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks