This task is to be done in groups which must have been approved by your tutor.Assignments will be returned to you within two to three weeks of submission.Feedback on this assignment will be provided via a rubric which will be available on the course website. Please read the assessment summary and assessment details sections of your course outline booklet carefully for further information relating to assessment in this course.

Specifications
This assignment will enable you to improve your skills as a systems analyst and carry out various activities in the systems analysis phase of the systems development life cycle. It requires you to investigate and document system requirements, identify and document use cases, carry out domain modelling and use case modelling. The assignment should be created using the template provided on the course website. Each group member is also required to fill out the “Declaration of Contribution” form which is available in the assignment template document. As stated in the form, if any contribution does not meet the assessment requirements, the course coordinator may adjust individual marks up or down, depending on the level of contribution made.

Marking Criteria
The rubric that will be used when assessing your work will be available on the course website. The word limit will not be checked for this assessment. This task will assess completeness of the objectives
listed below.
? Completeness, suitability and thoroughness of responses to the questions
? Technical correctness of the various models created;
? Adequate presentation and format;
? Use of the template provided;
? Correct spelling and grammar;
? Clarity of expression;
? Clearly labelled questions and answers;

Submission Instructions
The assignment MUST be submitted via Learnonline through the course website or via MyUniSA. Please submit ONLY ONE assignment per group – nominate someone to submit the assignment on the
group’s behalf. Include as part of your submission ONE .pdf document containing the responses to the questions relating to the given scenario. Individual submissions will NOT be considered or marked.
Refer to your course outline for further information regarding extensions. Late submissions will not be accepted for this course unless an extension has been approved by the course coordinator (see section on extensions in your course outline for further details). Late submissions that have not been approved will receive a mark of zero.

IMPORTANT INFORMATION
It is up to each group to make sure that the submitted work does not contain any parts copied from
another group in this or any previous year, from this or any similar course; or from a common source
such as a textbook or website. The assignment must be your own collective work, and not contracted to a substitute person. If we are suspicious, we reserve the right to call you in and to test your understanding of what you have submitted in an oral examination. If plagiarism is detected it will be investigated and appropriate consequences will follow. See Next Page For Scenario

Scenario
PP Productions (PPP) is a company which gives opportunities to young performers, aged 7 to 20, to
experience music theatre first hand. The organisation hosts three workshops each year, each leading
to public performances. These performances are held in large arenas such as town halls or high school
gymnasiums or theatres and are repeated several times for each production. At each opening night,
up to three reviewers from various organisations attend the opening night performance and post their
view in newspapers and on review websites.

Currently, the organisation maintains information about productions and workshops, performers and
guardians, assistants, tutors, costumes, scenery and props in spreadsheets. The two managers have
found this is becoming increasingly challenging to maintain accurate records and have decided to
implement a computerised information system to track all elements of their business.

They are hopingthat this will provide them with more accurate information about the profitability of their business.Participants need to enrol and pay fees for each of the workshop / performances in which they participate. Each workshop / performance has a name, rehearsal and performance venue names, and dates for the auditions, rehearsals and performances. Naturally, each workshop/production has a cost which may vary depending on whether there are one, two or more children from the same family participating.

Performers, tutors, past performers returning to assist in the production after they reach 21, and other
assistants for the workshops and performances must currently submit an application for each
workshop / performance they attend. This currently involves filling out a form to be sent to PPP via
mail or email. This means that some participants will provide exactly the same information three
times per year.

This is becoming increasingly frustrating for both participants and administrators for PPP, especially when one parent must register details for more than one child each time. PPP wants to change this process to enable this information to be entered via a website and saved into a database instead of PPP staff transcribing the information to the spreadsheets. Each performer will be allocated a username and default password by the administrators when they first register as a participant. aturally, this information will be stored external to the system and not associated directly in the atabase information. Subsequent workshops/performances will require the participant to check through existing information and update the areas as necessary. This will be a great time saving
for all concerned.

To make life easier, PPP have decided to record information they need by family. This means that one
main record can be maintained related to emergency contacts with additional information linked to
different family members. This family information will include the first name of the key contact person, surname, address, landline, mobile number, family email address and whether they are Facebook users. For each family member, their given names, optional additional surname, mobile number, date of birth for performers, and gender. Medical conditions also need to be recorded,especially if emergency treatment may be required, some additional information related to the condition. The performers are requested to upload a current head shot of themselves once each year. Participants then need to select an audition type – dancing, singing, both or none – and audition time. Prior to the workshops, all performers are contacted and notified the roles they have been allocated, performance notes, song tracks and lyrics, and schedules. 

Two emergency contacts, which may be another participant, must be added for each participant. It
has been found that in some cases, the emergency contacts are “shared” amongst several performers
who may be known to each other. To make life easier for the staff, they have decided that all parents
and emergency contacts should be stored together with links to children. When looking for thecontact people, the staff can then easily display the child’s details and view all responsible adults assigned to that performer. For this to be made more efficient, one emergency contact must be assigned as the primary contact.

Payments, due one week before the workshop commences, are currently processed through bank transfers as PPP does not have the ability to process credit card payments. Payments are calculated based on the number of siblings participating. PPP have decided to give the choice of online visa payments or direct bank transfer. The option for the payment type will be selected when the performer’s family information is updated. Payment information will reflect the date the payment is
made, the type of payment, amount paid. This enables parents to distribute payments over several
instalments.

The staff of PPP send reminder notices for payments not yet completed two weeks before the audition
and workshop dates. The card payments are handled through an external link to PayPal where the
only details returned from the transaction are the receipt number, date, time and amount of the payment. Bank transfers are recorded by the payee in the system as the date and amount they paid.
Past performers, parents and some professional tutors may be involved as tutors or able to assist with
scenery, props and costumes. Some tasks require attendance at each rehearsal session and some people are required during the times of the performances.

Details about the assistants include type of assistance - tutor, costumes, back-stage, front of house, props, lighting, recording - availability during rehearsals, availability during performances and any comments related to skills. They must also have a current DSCI screening clearance ensuring their ability to work with children, proof of which should be provided entering the expiry date of the certification into the system. There is also the date of the visual check by one of the PPP staff to ensure the certification is current. Participants involved in tutoring are paid for their time, so PPP ask for their bank details.

Answer:

Certainly, I can provide you with a more detailed explanation of the Systems Analysis phase within the Systems Development Life Cycle (SDLC). This phase is pivotal in the development of any information system, as it lays the groundwork for understanding the system's requirements, objectives, and functionality.

Introduction to Systems Analysis Phase:

The Systems Analysis phase is the second stage in the SDLC, following the Initiation phase. It is a systematic and structured approach to identifying, understanding, and documenting the needs of the users and the organization, with the goal of designing a system that fulfills those needs. This phase is characterized by in-depth analysis, data gathering, and planning, ultimately serving as the basis for the subsequent phases of system development.

Key Objectives of Systems Analysis:

1. Problem Identification: The initial step in Systems Analysis is to recognize and define the problem or need that the proposed system is intended to address. It involves discussions with stakeholders to comprehend their concerns, issues, and expectations. Clear problem identification is vital, as it sets the stage for all subsequent activities.

2. Feasibility Study: After problem identification, a feasibility study is conducted to assess whether the proposed system is viable. This study typically examines financial, operational, and technical feasibility. It helps decision-makers determine if the project is worth pursuing.

3. Requirements Gathering: Once it's established that the project is feasible and should proceed, the next step is to gather detailed requirements. This includes understanding what the system should do (functional requirements) and non-functional requirements (e.g., performance, security, and usability).

4. Data Analysis: Data is a fundamental component of most information systems. In this phase, analysts scrutinize data sources, data flow, data storage, and how data is processed within the system. This helps in the design of an efficient database structure.

5. Process Modeling: Visual representations, such as flowcharts and data flow diagrams, are created to illustrate how data and processes are interconnected in the system. Process modeling helps in understanding the workflow and interactions within the system.

6. Use Case Analysis: Use cases are developed to explore how various system components interact with users and other systems. Use cases provide a detailed understanding of system functionality from a user's perspective.

7. Prototyping: In some cases, especially when there is uncertainty about user requirements or design, a prototype of the system may be created. Prototyping is a way to provide stakeholders with a tangible representation of the system's potential look and feel.

8. System Requirements Specification: All the information collected during the analysis phase is documented in a System Requirements Specification document. This document serves as a blueprint for the design and development of the system, outlining the requirements, functionality, and constraints.

9. Validation: The documented requirements are validated with stakeholders to ensure they accurately represent their needs and expectations. Validation helps in ironing out any misunderstandings or miscommunications that may have occurred during the requirements gathering process.

10. Risk Assessment: Potential risks and challenges related to the project are identified and analyzed. Risk assessment helps in planning for potential issues and developing strategies to mitigate them.

11. Cost-Benefit Analysis: A cost-benefit analysis is performed to determine if the benefits of the new system outweigh its costs. This analysis takes into account both tangible and intangible costs and benefits associated with the project.

12. Recommendations: Based on the analysis and findings, the Systems Analyst makes recommendations. These recommendations may include whether to proceed with system development, what technology to use, what the project scope should be, and any necessary changes to the project plan.

Detailed Explanation of Key Activities in Systems Analysis:

1. Problem Identification: This stage is often initiated by a request from the organization or stakeholders for a new system or for improvements to an existing one. The Systems Analyst's role is to work with stakeholders to clearly define and understand the problem. This typically involves interviews, surveys, and observations to gather information. The outcome is a Problem Statement that outlines the objectives and constraints of the project.

2. Feasibility Study: Once the problem is identified, the Systems Analyst and project team assess the feasibility of the proposed system. There are typically three aspects of feasibility to consider:

- Financial Feasibility: This assesses the project's affordability and return on investment. It involves estimating the costs of development, operation, and maintenance compared to the benefits the system will deliver.

- Operational Feasibility: This examines whether the proposed system aligns with the organization's operational processes and goals. It also considers the willingness of employees to adapt to the new system.

- Technical Feasibility: This evaluates whether the technology required to build and operate the system is available and can meet the project's technical requirements.

A feasibility study usually results in a Feasibility Report, which provides recommendations on whether or not to proceed with the project.

3. Requirements Gathering: After the decision to move forward, the Systems Analyst embarks on gathering detailed requirements. This is a crucial step that involves engaging stakeholders to capture their needs, expectations, and constraints. Common techniques include interviews, surveys, questionnaires, and workshops.

The requirements are categorized into two main types:

- Functional Requirements: These specify what the system should do, outlining its features, capabilities, and interactions with users. Functional requirements are typically documented using use cases, process maps, and user stories.

- Non-Functional Requirements: These cover aspects such as system performance, security, usability, and reliability. Non-functional requirements are equally important, as they ensure the system operates effectively and securely.

4. Data Analysis: Data is at the heart of most information systems. In this stage, the Systems Analyst analyzes the data that will be managed by the system. This includes:

- Data Sources: Identifying where the data comes from, such as databases, external sources, or user input.

- Data Flow: Understanding how data moves within the system, from source to storage and processing.

- Data Storage: Determining how data will be stored, organized, and retrieved. This is critical for designing an efficient database structure.

Data analysis helps in creating an accurate data model for the system.

5. Process Modeling: Process modeling involves creating visual representations of the system's workflow and interactions. Common tools used for process modeling include flowcharts, data flow diagrams (DFDs), and Unified Modeling Language (UML) diagrams. Process modeling aids in understanding the logical flow of data and processes within the system, making it easier to design the system's architecture.

6. Use Case Analysis: Use cases are a valuable tool for capturing how the system interacts with its users and external systems. Use cases describe specific interactions between the user (actor) and the system, detailing the steps involved in a particular task or function. They help in understanding the system's functionality from a user's perspective.

7. Prototyping: In some cases, when there is uncertainty about the system's requirements or design, a prototype may be developed. A prototype is a simplified version of the system that provides a tangible representation of its functionality. It is often used to gather feedback from stakeholders and validate requirements. Prototyping is especially useful when there is ambiguity in user needs and when stakeholders need to visualize the system before full-scale development begins.

8. System Requirements Specification: All the information collected during the analysis phase is compiled into a System Requirements Specification document. This document serves as a comprehensive guide for the design and development of the system. It typically includes: