Read the following case study and answer the questions provided below: Newsletter Title Page 15 Case Study: Castleville Council Services Castleville council provides a range of support services and facilities to assist individual people and groups in their area to help them lead a happy and comfortable life. The council provides different types of services such as sports services or services related to health, day care facilities or providing services to people who have physical or learning disability. The council is planning to develop a web based system that will make the service management process more efficient for them as well as for the people availing those services. Summary of Requirements The proposed system should be able to identify eligible people (client) by individually assessing them according to their need and priority that is decided based on the information entered into the system by social workers or council staff. Some of these services are free of cost for people living in that vicinity however, some services may incur a fee to offset costs and that is related to the person's ability to pay. From time to time, the council can add new services or update or delete existing services. Castleville council also operates a complaints and representations procedure. People can provide feedback about their experience and services offered to them for future improvements. The system should incorporate this feature as well. The system should keep a record of individual client details that might include their name, address, contact details, payments made, current status, allocated social worker etc. There should be a facility for council supervisors to generate administrative reports regarding services provided to different people. There need to be restricted access to any confidential information about clients to those authorised to view the data using a password system You as a system analyst, are hired by the council authorities, to analyse and design the council services management system that should be able to perform tasks according to the details provided in the above case study. This will also require you to make necessary assumptions and clearly document all your assumptions in your report. T120 Final Examination: ICT103 System Analysis and Design Page 4 of 8 Newsletter Title Page 15 Your report must contain at least the following sections: SECTION A: Theory Related Questions (20 marks) 1. Introduction: Introduce the important aspects of the case study. (3 marks) 2. Work Breakdown Structure: Provide a work breakdown structure for the given project listing all the steps according to Software Development Life Cycle (SDLC) phases. (5 marks) 3. Requirements: List all functional and non-functional requirements as discussed in the case study. (5 marks) 4. Information gathering techniques: Identify at least two information gathering techniques that can be used to gather specific requirements and design at least 6 questions that can be asked from relevant stakeholders to capture the system requirements and specifications to develop the system successfully. (3 marks) 5. Conclusion: Write a brief conclusion (Conclusion can be written after competing both sections. (2 marks) 6. Structure and Formatting Guidelines (2 marks) a. Add a title/cover page of your choice at the beginning of the report. It should include the name of the assessment, subject name, student’s name, and student ID. b. Insert a table of content next to the title page. c. Insert the page number within the footer of every page in your report. d. Provide appropriate referencing(Harvard-Style) for all academic resources used e. Submit your file using the format: YourNameID_ICT103Exam.docx SECTION B: Diagram Related Questions (30 marks) Based on the outcome of the requirement analysis carried out above, create following diagrams to provide graphical illustration of the proposed system. 1. Use Case Diagram: Provide the name and complete description (see Appendix A for description table template) of main use cases for the proposed system and draw a use case diagram. (5 marks) 2. Activity Diagram: Provide an activity diagram for any use case identified above (5 marks) 3. Entity relationship Diagram : Provide one ER Diagram related to the case study (2.5 marks) 4. Domain Model Class Diagram: Provide domain model class diagram for the system (2.5 marks) 5. User Interface : Provide a final user interface design using dialog and screen prototypes for any of the use case listed above. (5 marks) 6. Test cases: provide a sample test case table with a list of test cases that can be used to test the new system (see Appendix A for test case table template) (5 marks) 7. Modelling Diagrams: Clearly define and describe your findings in few words represented by each diagram related to the case study and use accurate technical language, abbreviations and symbols. (5 marks) T120 Final Examination: ICT103 System Analysis and Design Page 5 of 8 Appendix A: Newsletter Title Page 15 Use case description table: System Name : Use Case(s) Use Case ID: Enter a unique numeric identifier for the Use Case. e.g. UC-1 Use Case Name: Enter a short name for the Use Case using an active verb phrase. e.g. Withdraw Cash Created By: Enter your name and student ID Date Created: Enter date of creation Actors: [An actor is a person or other entity external to the software system being specified who interacts with the system and performs use cases to accomplish tasks. Different actors often correspond to different user classes, or roles, identified from the customer community that will use the product. Name the actor that will be initiating this use case (primary) and any other actors who will participate in completing the use case (secondary).] Description: [Provide a brief description of the reason for and outcome of this use case.] Trigger: [Identify the event that initiates the use case. This could be an external business event or system event that causes the use case to begin, or it could be the first step in the normal flow.] Preconditions: [List any activities that must take place, or any conditions that must be true, before the use case can be started. Number each pre-condition. e.g. Postconditions: [Describe the state of the system at the conclusion of the use case execution. Should include both minimal guarantees (what must happen even if the actor’s goal is not achieved) and the success guarantees (what happens when the actor’s goal is achieved. Number each post-condition. e.g. Normal Flow: [Provide a detailed description of the user actions and system responses that will take place during execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to accomplishing the goal stated in the use case name and description. Alternative Flows: [Alternative Flow 1 – Not in Network] [Document legitimate branches from the main flow to handle special conditions (also known as extensions). For each alternative flow reference the branching step number of the normal flow and the condition which must be true in order for this extension to be executed. e.g. Alternative flows in the Withdraw Cash transaction: Note: Insert a new row for each distinctive alternative flow. ] Exceptions: [Describe any anticipated error conditions that could occur during execution of the use case, and define how the system is to respond to those conditions. Includes: [List any other use cases that are included (“called”) by this use case. Common functionality that appears in multiple use cases can be split out into a separate use case that is included by the ones that need that common functionality. e.g. steps 1-4 in the normal flow would be required for all types of ticket vending transactions- a Use Case could be written for these steps and “included” in all ticket vending Use Cases.] Frequency of Use: [How often will this Use Case be executed. This information is primarily useful for designers. e.g. enter values such as 50 per hour, 200 per day, once a week, once a year, on demand etc.] T120 Final Examination: ICT103 System Analysis and Design Page 6 of 8 Newsletter Title Page 15 Test case table: one example provided for idea Test Case Id Use Case ID Short Description Test Conditions Expected Outcomes T101 U01 Maintain Client Info Add client, Update client, delete not allowed New client created with all fields, Existing client updated with selected fields T102 T103 T104 T105 T106 T120 Final Examination: ICT103 System Analysis and Design Page 7 of 8 Marking Rubric for Final Newsletter Title Exam Assignment Page 15 Criteria Fail (0 – 49%) Pass (50 – 64%) Credit (65 – 74%) Distinction (75 – 84%) High Distinction (85 – 100%) Section A Introduction 3 marks No introduction given or most of the introduction is irrelevant Introduction of the business case is provided with some details and limited cohesion Introduction of the business case is provided with most of the required details in a cohesive manner Introduction of the business case is provided with all of the required details in a comprehensive and cohesive manner Introduction of the business case is provided with all details presented systematically in a comprehensive and cohesive manner Work Breakdown Structure (WBS) 5 marks Provided a WBS with either nothing or wrong details. Biased/irrelevant level of level of justification for the tasks chosen provided A WBS but not the most effective one, biased/irrelevant level of level of justification for the tasks chosen provided effective and relevant WBS with limited details and ambiguous relevance, basic level of level of justification for the tasks chosen provided effective and relevant WBS with nearly all required details, good level of level of justification for the tasks chosen provided effective and relevant WBS with complete required details, exceptional level of justification for the tasks chosen Functional and NonFunctional Requirements 5 marks No or mostly irrelevant requirements are identified correctly Some of the requirements are identified correctly Most of the requirements are identified correctly Nearly all of the requirements are identified correctly All of the requirements are identified correctly Information gathering/ Questions 3 marks No or mostly irrelevant requirements gathering techniques are identified and no questions provided Requirements gathering techniques are provided with some details and very few questions provided with no relevance Requirements gathering techniques are provided with most of the correct questions identified Requirements gathering techniques are provided with all with relevant and appropriate questions Requirements gathering techniques are provided with relevant and appropriate questions as expected Conclusion 2 marks No conclusion or lack of cohesion with the discussion, no or limited recommendations provided Conclusion does not link back systematically to most sections, some basic recommendations provided Conclusion links back to some sections of the report, some detailed recommendations provided Conclusion links back to all sections of the report, detailed recommendations provided Conclusion demonstrates a deep understanding of the proposed solution and relates back to all sections of the report, detailed recommendations provided Structure, format and Referencing 2 marks Very difficult to read, unclear structure, and most of the required sections are missing, no referencing provided Some difficulty in reading, not very clear, but important sections are included Clear and readable, and all required sections are included Well written and very clear, and all required sections with completed discussion are included and referencing provided Well written and very clear, all required sections with completed discussion are included, and correct referencing provided Total marks out of 20 T120 Final Examination: ICT103 System Analysis and Design Page 8 of 8 Section B Newsletter Title Page 15 Use Cases 5 marks No use cases and description provided, or diagrams are irrelevant Some required use cases and description are provided, and diagram are provided but details are incomplete Most required use cases and description are provided, and diagram are provided, and limited details are given Nearly all required use cases and description are provided, and diagram are provided, and all details are given All required use cases and description are provided, and all details are provided correctly Activity diagram 5 marks Does not provide any activity diagram Some of the required functionality is provided in the activity diagram Most of the required functionality is provided in the activity diagram Nearly all of the required functionality is provided in the activity diagram Activity diagram is provided and the diagram is complete and correct Entity relationship Diagram 2.5 marks No or irrelevant diagram is provided Entity relationship diagram is provided with few required details Entity relationship diagram is provided with some required details Entity relationship diagram is provided with nearly all required details and correct symbols Entity relationship diagram is provided with all required details and correct symbols Domain model class diagram 2.5 marks No or irrelevant diagram is provided Domain diagram is provided with few required details Domain diagram is provided with some required details Domain diagram is provided with nearly all required details Domain diagram is provided with all required details User interface, Dialogs and screen prototypes 5 marks No or irrelevant UI is provided UI is provided with some details of the methods UI is provided with most details of the methods UI is provided with nearly all details of the methods UI is provided with all details of the methods Test cases 5 marks No or irrelevant test cases are provided with no link to given use cases Test cases are provided with some details and linked with use cases Test cases are provided with somewhat correct details and linked with use cases Test cases are provided with mostly correct details and linked with use cases Test cases are provided with appropriate details and correct linked with use cases Modelling Diagrams 5 marks No description provided for any diagram and used incorrect symbols for most diagrams provided some description but not completely correct and used incorrect symbols and technical language for most diagrams provided description for few diagrams correctly and used appropriate symbols and technical language for few diagrams provided description for many diagrams correctly and used appropriate symbols and technical language for many diagrams provided excellent description and used accurate technical language, abbreviations and symbols for all diagrams Total marks out of 30 END OF EXAMINATION PAPER