Software Requirements Specication (SRS) Project : Music School Administration System Team Respect

August 7, 2003

Revision 1.14

Team Members
Amy Curran Jonathan Conn Nikhil Malani Vinit Praneel Kumar Rohan DSouza Document Maintainer:
Abstract

CS login
aecurran jwac nkmalani vpkumar rohandd Amy Curran

This SRS forms part of the assessment for subject 433-340 at The University of Melbourne. The SRS contains details of the requirements for the administration system being developed by Team Respect for Christine Masters of Masters Music School, Brisbane. It contains a list of functional and non-functional requirements to be met by the system. The purpose of the SRS is to develop a contract between the client and the team to enable successful completion of the system and ensure client satisfaction.

CONTENTS

Contents
1 Introduction 1.1 Purpose . . . . . . . . . . 1.2 Contact Details . . . . . . 1.2.1 Team Respect . . . 1.2.2 Client . . . . . . . 1.3 Scope . . . . . . . . . . . 1.4 Denitions, Acronyms and 1.4.1 Denitions . . . . 1.4.2 Acronyms . . . . . 1.4.3 Abbreviations . . . 1.5 References . . . . . . . . . 1.6 Document Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 1 1 1 1 1 3 4 4 4 5 5 5 5 5 6 7 7 7 8 8 8 8 8 8 9 9 10 10 10 10 11 11 11 11 11 12 12 12 12 12

2 System Overview 2.1 Stakeholders . . . . . . . . . . . 2.1.1 User Characteristics . . 2.2 Existing System . . . . . . . . . 2.3 Proposed System . . . . . . . . 2.4 Product Features . . . . . . . . 2.5 Assumptions and Dependencies 2.6 Project Constraints . . . . . . . 2.7 Requirements Prioritisation . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

3 Functional Requirements 3.1 Core Requirements . . . . . . . . . . . . . . . . . . 3.1.1 Administrative Features . . . . . . . . . . . 3.1.1.1 Login . . . . . . . . . . . . . . . . . . . 3.1.1.2 Enter Term Dates and Public Holidays 3.1.1.3 Add Prospective Student . . . . . . . . 3.1.1.4 Add New Teacher . . . . . . . . . . . . 3.1.1.5 Add New Class . . . . . . . . . . . . . 3.1.1.6 Add Inventory Item . . . . . . . . . . . 3.1.1.7 Add Supplier . . . . . . . . . . . . . . 3.1.1.8 Edit Details . . . . . . . . . . . . . . . 3.1.1.9 Delete Database Member . . . . . . . . 3.1.1.10 Account Paid . . . . . . . . . . . . . . 3.1.1.11 Store Information Letter . . . . . . . . 3.1.1.12 Generate Information Letter . . . . . . 3.1.1.13 Change Student Status . . . . . . . . . 3.1.1.14 Edit Supplier List . . . . . . . . . . . . 3.1.2 Timetabling Features . . . . . . . . . . . . 3.1.2.1 Enrol a Student . . . . . . . . . . . . . 3.1.2.2 Unenrol a Student . . . . . . . . . . . . 3.1.2.3 Allocate a Teacher to a Class . . . . . 3.1.2.4 Remove a Teacher from a Class . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

CONTENTS 3.1.3 Viewing Features . . . . . . . . . . 3.1.3.1 View Student Details . . . . . 3.1.3.2 View Teacher Details . . . . . 3.1.3.3 View Class Details . . . . . . 3.1.3.4 View Inventory Item Details . 3.1.3.5 View Timetable . . . . . . . . 3.1.3.6 View School Timetable . . . . 3.1.3.7 View Supplier List . . . . . . 3.1.3.8 View List . . . . . . . . . . . . 3.1.3.9 View Account . . . . . . . . . 3.1.3.10 List Unpaid Accounts . . . . . 3.1.3.11 List Wages Owed . . . . . . . 3.1.4 Print Features . . . . . . . . . . . 3.1.4.1 Print Details . . . . . . . . . . 3.1.4.2 Print List . . . . . . . . . . . 3.1.4.3 Print Wage Slip . . . . . . . . 3.1.4.4 Print Wage List . . . . . . . . 3.1.4.5 Print Account . . . . . . . . . 3.1.4.6 Print Timetable . . . . . . . . 3.1.5 Calculation Features . . . . . . . . 3.1.5.1 Calculate Wages . . . . . . . . 3.1.5.2 Generate Account . . . . . . . 3.1.5.3 Automatic Late Fee Inclusion 3.1.6 Miscellaneous Features . . . . . . . Optional Requirements . . . . . . . . . . . 3.2.1 BAS Figures . . . . . . . . . . . . 3.2.2 Add Book Owing . . . . . . . . . . 3.2.3 View Marketing List . . . . . . . . 3.2.4 Add Lesson Plan . . . . . . . . . . 3.2.5 Edit Lesson Plan . . . . . . . . . . 3.2.6 View Lesson Plan . . . . . . . . . 3.2.7 Print Lesson Plan . . . . . . . . . 3.2.8 View Stock Count . . . . . . . . . 3.2.9 List Book Owings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ii 12 13 14 15 15 15 15 16 16 16 16 16 17 17 17 17 17 18 18 18 18 18 19 19 19 19 19 20 20 20 20 20 21 21 22 22 22 22 24 25 25 25 25 25 26 26

3.2

4 Non-functional Requirements 4.1 Interface Requirements . . . . . 4.1.1 External Interfaces . . . 4.1.1.1 User Interfaces . . . 4.1.1.2 Hardware Interfaces 4.1.1.3 Software Interfaces 4.1.2 Internal Interfaces . . . 4.2 Performance Requirements . . 4.3 Security Requirements . . . . . 4.4 Implementation Constraints . . 4.5 Hardware Constraints . . . . . 4.6 Software Constraints . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

CONTENTS 4.7 4.8 Design Constraints . . . . Quality System Attributes 4.8.1 Availability . . . . 4.8.2 Security . . . . . . 4.8.3 Operability . . . . 4.8.4 Attractiveness . . 4.8.5 Learnability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iii 26 26 26 26 27 27 27 28 29 30 32 33

5 Acceptance Criteria 6 Client Sign-O 7 Appendix B 8 Appendix C 9 Appendix D

LIST OF FIGURES

iv

List of Figures
1 Example Main Screen Layout . . . . . . . . . . . . . . . . . . . . . . . . 24

LIST OF TABLES

List of Tables
1 2 Main Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 View Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

INTRODUCTION

Introduction

This section introduces the project and also the reasons for the production of an SRS. It also contains denitions, acronyms and abbreviations used throughout the document.

1.1

Purpose

This document states the requirements for an interactive database system to be agreed upon between the client and Team Respect. This document is an artifact of the Team Respect Music School Administrative Database project. Further details can be found in the Software Project Management Plan. The client is Christine Masters of Masters Music School, a small business based in Brisbane, Queensland. The intended audience of this document is Team Respect, the client and 433-340 markers and assessors.

1.2
1.2.1

Contact Details
Team Respect

The team can be contacted: 1. via email: s340gr@students.cs.mu.oz.au 2. through the Client Liaison, Amy Curran. Ph: 0402 823687 Email: aecurran@students.cs.mu.oz.au or 3. through the University of Melbourne Computer Science department 1.2.2 Client

Christine Masters can be contacted through Kathleen Keogh, the University of Melbourne Computer Science department, who is acting on behalf of the client. Kathleen Keoghs email: kathleen@cs.mu.oz.au

1.3

Scope

The product will be used exclusively by Christine Masters of the Masters Music School. It will be hosted on the main Masters Music School computer, a lap-top owned by Ms Masters. At this stage, Ms Masters is intending to purchase a new lap-top computer, so the portability of the lap-top will allow the program to be accessed anywhere. The program is the rst time that Masters Music School will be computerising their business. Exact requirements of the afore-mentioned computerised system are stated in following sections.

1.4
1.4.1

Denitions, Acronyms and Abbreviations

Denitions

1. Account An account is the details of any monies owed to the music school by a student/family. i.e. Accounts Receivable

INTRODUCTION

2. Business Activity Statement The Business Activity Statement is a document which small businesses operating in Australia are required to submit to the Australian Taxation Oce either once a month or once a quarter. The document includes details of the business GST, withholding tax, installment tax and fringe benets tax. Refer to Appendix C. 3. Combo-box This refers to a eld which appears on screen as a horizontal box with an arrow. When the arrow is selected, a list of options is displayed, allowing the user to choose their preferred option. The user is only able to select one option. 4. Current Student A current student is any student who is currently enrolled in lessons at the music school. 5. Database Member Either a student, teacher, class or inventory entry in the database system. 6. Deferred Student A student with this status has previously been enrolled in classes at the music school, but has ceased classes either indenitely or for a specied period of time. 7. Enrolment Status A students enrolment status is dened as one of the three student categories(Current, Deferred or Prospective as dened at denitions 4, 6 and 16 respectively). 8. Gross Wage The amount earned before tax. 9. Inventory A storage of items which are for sale through the music school. 10. Inventory Item An item, which is currently for sale, details of which are stored in the database. 11. Lesson Plan An outline of the plan to be followed during any class of a particular level. 12. Levels This refers to the dierent levels of classes which are taught at the music school. (a) Level 1 - This is the rst level. Successful completion is determined by the knowledge of a set list of songs. (b) Level 2 - Again successful completion is determined by the knowledge of a set list of a higher level of songs. (c) Level 3 - Piano Preparation. (d) Level 4 - Piano lessons 13. Marketing Information Refers to the medium through which the student found out about the classes.

INTRODUCTION 14. Net Wage The amount earned after tax.

15. Prole This refers to the interface which is produced when the user selects the View Details function. (See 3.1.3) 16. Prospective Student A prospective student is any student who has enquired, or whose parents have enquired, into lessons but does not wish to begin immediately. Their details are kept on the database to ensure a smooth enrolment in classes. 17. Teacher A teacher is dened as being employed by the school to teach students of dierent levels. A teacher may teach classes of more than one level. (See Levels, denition 12 above.) 18. Wage Slip This is a document which will detail an employeess (a) minutes worked (b) hourly rate (c) gross wage (d) tax paid (e) superannuation contribution (if any) (f) net wage 1.4.2 Acronyms

1. CPU Central Processing Unit 2. GUI Graphical User Interface 3. HTML Hypertext Markup Language, a standard language for writing web sites. 4. SADD Software Architectural Design Document 5. BAS Business Activity Statement 6. GST Goods and Services Tax 7. UofM University of Melbourne

INTRODUCTION Abbreviations

1.4.3

1. Music school Refers to the clients business: Masters Music School.

1.5

References

1. Australian Taxation Oce - www.ato.gov.au 2. IEEE Standard for Software Requirements Specications (Std 830-1998) 3. Masters Music School - Current Excell Spreadsheet of student details 4. Masters Music School - Sample Account 5. Masters Music School - Information Letter template 6. Sample SRS for Mission Planning System from Team Ballistix 7. Sample SRS for DORiS project - UofM 433-440 SRS, 1998 8. Sample SRS for KISS project - UofM 433-440 SRS, 1999 9. Van Vliet, H Software Engineering: Principles and Practice, 2nd edition, 2000, John Wiley and Sons Ltd

1.6

Document Overview

The remaining sections of this document will detail the requirements of the system to be implemented. Sections are as follows: 1. Section 2 - An outline of the system as a whole. It contains details of the current system in use by the music school and the features to be implemented by the new system. A description is given of the stakeholders of the project. The prioritisation of requirements is also explained. 2. Section 3 - A detailed interpretation of the functional system requirements. 3. Section 4 - A detailed interpretation of the non-functional system requirements. Implementation, Software, Hardware and Design Constraints are discussed as well as Performance features.

SYSTEM OVERVIEW

System Overview

This section provides a high-level description of the proposed system. A brief outline of the main features of the Music School Administration System is given here, and then discussed in further detail in sections 3 and 4. The classication of the requirement priorities is also dened in this section. Stakeholders in the system are described, as are the User Characteristics.

2.1

Stakeholders

There will be one primary user: Ms Christine Masters of Masters Music School. During the design, implementation and testing phases of the project, Ms Kathleen Keogh of the Computer Science Department, University of Melbourne, will be acting on behalf of Ms Masters. Other stakeholders are: 1. Team Respect 2. Team Respect Supervisor: Sharyn Oh 3. 433-340 Markers and Assessors The system will also be designed to be left open for the possibility of being extended to be available on the world wide web. (See section 4.7). This would then introduce a new group of stakeholders. 2.1.1 User Characteristics

The software will be used by the manager of Masters Music School. To be able to use the software to its full potential, the user will need to be literate with mouse and keyboard operation. (See 4.1.1.2.) The client is a mother with young children and so the requirements specied are aimed at allowing the user to operate the system whilst looking after small children. Should the product be extended for web use however (See 4.7), the user characteristics will be extended to include those of any potential customer or employee of the music school.

2.2

Existing System

The Music School currently uses a Microsoft Excel spreadsheet to store the details of its students. The spreadsheet contains the basic contact details of the students. The client manually calculates accounts and wages and also manually forms the timetables for the school. This system has been incredibly time-consuming in the past. This year there are positions for between 90 and 100 students, however the school usually has an enrolment of up to 200.

2.3

Proposed System

The proposed product will automate the current features with an administration database and graphical user interfaces. It will be implemented to cover the requirements of the manager of the school as specied in this document. This product will be used in conjunction with a web-browser capable of supporting HTML.

SYSTEM OVERVIEW

2.4

Product Features

For detailed descriptions of the proposed requirements, refer to sections 3 and 4. The following core features will be implemented: 1. Main Database Members The main database members which will be a part of the proposed system are Students, Teachers, Classes and Inventory. 2. Database Manipulation The user will be able to add, edit and delete database members. The user will also be able to edit and add term dates and public holidays into the system. See 3.1.1. 3. Viewing The user will be able to view proles of database members, and timetables. The user will also be able to view teacher wages and student accounts, which will be calculated automatically by the system. See 3.1.3. 4. Printing The user will be able to print proles, timetables, accounts and wage slips. The user will also be able to generate and print an information letter to be sent to prospective students detailing information about the music school such as price and availability of classes. See 3.1.4. 5. Inventory The system will include an inventory database in which the user will be able to store the details of any items for sale, for example music books and musical instruments. 6. Suppliers The system will contain information of suppliers who supply musical items to the musical school. 7. Timetabling The timetabling functions will use the data provided by students as to their availability and preferred lesson times, and also their levels, to group students into classes. When the system cannot accommodate a students requests, the user will be notied. The timetabling sub-system will also create timetables for teachers, based on their availability and teaching level (dened in Denitions. See 1.4.1). The following (optional) features will be implemented if time allows: 1. Compilation of Marketing Data This functionality will create an overview of the dierent ways parents/children found out about Masters Music School. See 3.2.3. 2. Owings on Books This functionality will allow the user to enter information into a students prole about a book they owe money for. See 3.2.2.

SYSTEM OVERVIEW

3. Generate BAS This functionality will generate the details required to complete a Business Activity Statement for the music school. See 3.2.1. 4. Database of lesson plans A storage of the lesson layout for each of the dierent levels. The user will be able to add, edit and view lesson plans.

2.5

Assumptions and Dependencies

As the client is situated in Brisbane, successful completion of the project depends on the client being easily contactable. Kathleen Keogh, of the Melbourne University Computer Science department will act on behalf of the client in order to lessen the impact of this dependency.

2.6

Project Constraints

1. The major constraint on the project is the clients location (ie Brisbane). The team plans to attempt to overcome this by ensuring client communications are well organised. This will be done through the acting client, Ms Kathleen Keogh of the University of Melbourne Computer Science department. 2. The client location also means that the completed system will need to be easily maintained as team members will not be readily available for routine maintenance. 3. There is a time constraint on the project as the system will need to be completed by the end of the academic year of 2003. 4. The project development is also constrained to the resources available at the University of Melbourne as well as those owned by team members.

2.7

Requirements Prioritisation

The requirements will be prioritised in the following way: 1. Requirements will be split into Functional and Non-functional. 2. Each of these will be ranked as either Core (1st priority) or Optional(2nd priority). 3. The Optional functionality will then be prioritised into: (a) Highly Desirable - These requirements will be the rst optional requirements to be implemented if time allows. (b) Desirable - These requirements will be implemented only after all highly desirable requirements have been implemented and tested. The system will be considered satisfactorily completed after all Core requirements have been implemented and tested.

FUNCTIONAL REQUIREMENTS

Functional Requirements

The functional requirements are the requirements of what the system will do.

3.1

Core Requirements

The following requirements will be implemented before the system is deemed satisfactorily completed. 3.1.1 Administrative Features

These features will allow manipulation of the underlying databases of the system. 3.1.1.1 Login

The system will provide functionality to allow the user to log in to the system with a username and password. 3.1.1.2 Enter Term Dates and Public Holidays

The system will provide functionality to store, edit and view school term-dates and public holidays. The user will enter the dates at the beginning of a term, and the system will use these to calculate wages and fees. (See 3.1.5.1 and 3.1.5.2). 3.1.1.3 Add Prospective Student

This function will allow a new student to be added to the system database. The user will enter into the system the following information related to a prospective student: 1. Surname 2. First Name 3. Date of Birth 4. Sex 5. Postal Address 6. Town 7. Postcode 8. Contact Email Address 9. Mothers Name 10. Fathers Name 11. Home Telephone 12. Contact Number

FUNCTIONAL REQUIREMENTS 13. Day(s) Available 14. Time(s) Available 15. Date of Enquiry 16. Lesson Commencement Date 17. Marketing Information

3.1.1.4

Add New Teacher

The system will provide the functionality to add a teacher into the system database. The user will enter into the system the following information related to a teacher: 1. Surname 2. First Name 3. Date of Birth 4. Sex 5. Postal Address 6. Town 7. Postcode 8. Email Address 9. Home number 10. Mobile number 11. Tax File Number 12. Tax Bracket 13. Hourly Rate 14. Wages Owing 3.1.1.5 Add New Class

The system will provide the functionality to add a new class into the system database. The user will enter into the system the following information related to a class: 1. Time 2. Day 3. Level 4. Lesson length 5. Location 6. Maximum enrolment

FUNCTIONAL REQUIREMENTS Add Inventory Item

10

3.1.1.6

The system will provide functionality to add a new inventory item into the system database. The user will enter into the system the following information related to an inventory item: 1. Item name 2. Item description 3. Supplier (Could be a company or individual) 4. Cost Price 5. Sale Price 3.1.1.7 Add Supplier

The system will provide functionality to add a supplier to the supplier list. The user will enter into the system the following information related to a supplier: 1. Supplier name 2. Items they supply 3. Retail prices of items 4. Discounts for bulk buying 5. Contact details 3.1.1.8 Edit Details

The system will provide functionality to allow the user to edit the details of any database member. In particular, editing of minutes worked by a teacher will only allow increases of 15, 20 or 30 minutes, in line with standard lesson lengths. 3.1.1.9 Delete Database Member

The system will provide functionality to delete a database member and all their details from the database. 1. Teacher A teacher is deleted when they cease teaching classes indenitely. When a teacher is deleted, the system will also automatically disassociate the teacher with any classes they were teaching before deletion. 2. Prospective Student A prospective student is deleted when they show no further interest in commencing lessons, 6 months after the date stored in the Date of Enquiry eld. This deletion will be done automatically by the system.

FUNCTIONAL REQUIREMENTS

11

3. Current Student A current student is deleted when they cease classes with no intention of continuing with the music school. When a current student is deleted, the system will automatically unenrol them from any classes they are enrolled in. 4. Deferred Student A deferred student is deleted by the user after they have been in the system as a deferred student for a consecutive period of 2 years without noting an expected date of resuming lessons. This deletion will be done automatically by the system. 5. Class A class is deleted when it is no longer being held. 6. Inventory Item An inventory item is deleted when the item is sold. 3.1.1.10 Account Paid

The system will provide functionality to allow the user to click a button on a students prole and enter an amount when a part or full payment is made on an account. This will automatically alter the Fee Details eld of the student to reect the payment. 3.1.1.11 Store Information Letter

The system will provide functionality to store and edit an information letter. The information letter will contain information about the music school for prospective students and their parents. An original information letter template provided by the client will be stored on the system at system delivery time. See Appendix D for an example letter. 3.1.1.12 Generate Information Letter

The system will create a personalised information letter for prospective students using the template stored with Functional Requirement 3.1.1.11. 3.1.1.13 Change Student Status

The system will provide the functionality to change the status of students on the database, between Current, Prospective and Deferred. The system will only allow changes from Prospective to Current, from Current to Deferred and from Deferred to Current. 3.1.1.14 Edit Supplier List

The system will provide functionality to allow the user to edit the supplier list, which will contain details: 1. Supplier name 2. Items they supply

FUNCTIONAL REQUIREMENTS 3. Retail prices 4. Discounts for bulk buying 5. Contact Details

12

See also Section 3.1.3.7 3.1.2 Timetabling Features

The following requirements aim at automating the current systems timetabling functions. 3.1.2.1 Enrol a Student

The system will provide functionality to enrol a current student in a class which ts in with the students availability and class level. 1. The system will display a list of times of classes with spare places, allowing the user to select which of these to enrol the student in. 2. If there are no available places in the students availability times, the system will display the times of all classes with places available. 3.1.2.2 Unenrol a Student

The system will provide functionality to remove a student from a class. 3.1.2.3 Allocate a Teacher to a Class

The system will provide functionality to nd a teacher for a particular class. 1. The system will provide a list of available teachers (who are qualied for the particular class level), allowing the user to select their preferred teacher. 2. The system will check each teachers availability times and also whether they are already assigned to a class at the same time. 3.1.2.4 Remove a Teacher from a Class

The system will provide functionality to remove/unassign a teacher from a class. 3.1.3 Viewing Features

These features will allow the user to view information stored in the system.

FUNCTIONAL REQUIREMENTS View Student Details

13

3.1.3.1

The system will provide the functionality to allow the user to view the details of any given student, regardless of their status. The system will display the following details: Current Student 1. Full Name (Surname rst) 2. Date of Birth 3. Sex 4. Address 5. Email Address 6. Parent Names 7. Home and Work Phone Numbers of parents (To be highlighted) 8. Days and Times theyre available for lessons 9. Lesson details: Venue, Day, Time, Length and Level 10. Lesson history: Previous Levels completed 11. Current Teacher 12. Fee details - How much they owe for classes and when it was/is due. The amount will incremented only by the Generate Account functionality and the Automatic Late Fee Inclusion. (See 3.1.5.2 and 3.1.5.3. After an account has been paid, the user will reset the amount to zero using the Account Paid functionality. (See 3.1.1.10). 13. Money owing for books 14. Books purchased Prospective Student 1. Full Name (Surname rst) 2. Date of Birth 3. Sex 4. Address 5. Email Address 6. Parent Names 7. Home and Work Phone Numbers of parents

FUNCTIONAL REQUIREMENTS 8. Days and times theyre available for lessons 9. Possible/Actual lesson commencement date 10. How the prospective student heard about the classes 11. Date information letter sent out.

14

Deferred Student 1. Full Name (Surname rst) 2. Date of Birth 3. Sex 4. Address 5. Email Address 6. Parent Names 7. Home and Work Phone Numbers of parents 8. Reason for ceasing lessons 9. Lesson history: Previous levels completed 10. Length of enrolment - The amount of time for which the student was a current student during their last period of enrolment. 11. Expected date of resuming lessons 3.1.3.2 View Teacher Details

The system will provide the functionality to allow the user to view the details of any given teacher. The system will display the following information: 1. Name 2. Address 3. Phone Number(s) 4. Lesson times 5. Tax bracket 6. Minutes worked 7. Hourly Rate 8. Wages owing

FUNCTIONAL REQUIREMENTS View Class Details

15

3.1.3.3

The system will provide the functionality to allow the user to view the details of any given class. The system will display the following information: 1. Time 2. Day 3. Level 4. Length of lesson 5. Teacher 6. Maximum enrolment 7. Students enrolled 8. Location 3.1.3.4 View Inventory Item Details

The system will provide functionality to allow the user to view the details of an item in the inventory. The system will display the following information: 1. Item name 2. Item description 3. Supplier (Could be a company or individual) 4. Cost Price 5. Sale Price 3.1.3.5 View Timetable

The system will provide functionality to produce a weekly timetable of a teacher or current student. This functionality will use the class details stored in the teacher or current student prole. See 3.1.3.2 and 3.1.3.1 and 3.1.2.3 and 3.1.2.1 3.1.3.6 View School Timetable

The system will provide functionality to allow the user to see an overview of the classes scheduled across the whole school for the week.

FUNCTIONAL REQUIREMENTS View Supplier List

16

3.1.3.7

The system will provide functionality to allow the user to see a list of suppliers. The system will display the following information: 1. Supplier Name 2. Items they supply 3. Retail prices of items 4. Discounts for bulk buying 5. Contact details 3.1.3.8 View List

The system will provide the functionality to allow the user to view the details of any given group, regardless of their status. The system will display the following information: 1. List of Teachers - Teacher Name, Contact Number 2. List of Students - Student Name, Status, Contact Number 3. List of Classes - Class Time, Level, Teacher 3.1.3.9 View Account

The system will provide functionality to allow the user to view an account as generated by the Generate Account functionality. See 3.1.5.2. 3.1.3.10 List Unpaid Accounts

The system will provide functionality to display the details of all unpaid accounts. The information displayed will be: 1. Name of Account 2. Amount Owing 3. When it is/was due Note: The system will automatically change the amount a student owes after the rst date of term to reect the late payment fee. (Refer to section 3.1.5.2. 3.1.3.11 List Wages Owed

The system will provide functionality to allow the user to view a list of wages owed. The list will show: 1. Teacher Name 2. Minutes Worked

FUNCTIONAL REQUIREMENTS 3. Gross Wage 4. Tax Paid 5. Superannuation contribution (if any) 6. Wages Owed

17

3.1.4

Print Features

The following functionalities all result in a print format output. 3.1.4.1 Print Details

The system will provide the functionality to print the details as displayed when the user requests to view the details of a student, teacher or class. 3.1.4.2 Print List

The system will provide functionality to allow the user to print a list of either students, teachers or classes. The system will prompt the user to select which of these they wish to print. See 3.1.3.8 3.1.4.3 Print Wage Slip

The system will provide the functionality to print either one or two copies of a given teachers wage slip: one for the teacher and one for the school records. The wage slip will contain the following information: 1. Teacher Name 2. Tax File Number 3. Period of Payment 4. Hours Worked (Although the system will store the time worked by a teacher in minutes, the wage slip will display the time in hours, (ie Minutes worked/60). 5. Rate of Pay 6. Gross Wage 7. Tax Paid 8. Superannuation Contribution (if any) 9. Net Wage See 3.1.5.1 3.1.4.4 Print Wage List

The system will allow the user to print o the wage list formed in Functional Requirement 3.1.3.11.

FUNCTIONAL REQUIREMENTS Print Account

18

3.1.4.5

The system will provide functionality to print one or two copies of either a single account, a family account or all accounts. The second copy is for record-keeping purposes. The layout of the account will be as generated with the Generate Account functionality. (See Section 3.1.5.2.) A sample account template is given in Appendix B. This is not the exact format to be used in the system. 3.1.4.6 Print Timetable

The system will provide functionality to print the timetable of a particular student or teacher. (See 3.1.3.5.) The user will also be able to print the timetable for the whole school, as described in 3.1.3.6. 3.1.5 Calculation Features

This section contains requirements which involve multiple calculations using data stored in the system 3.1.5.1 Calculate Wages

The system will provide the functionality to calculate the wages for a given period of time for a selected teacher with the following considerations: 1. If a teacher has earned over the superannuation threshold, the superannuation contribution will also be listed. 2. It will also provide a single function to calculate all teachers wages. 3. If this second option is chosen, the system will create a list of teachers names and their corresponding wages. 3.1.5.2 Generate Account

1. The system will provide functionality to generate the accounts for the up-coming term for all the current students or a specic student. 2. If there is more than one student from a family taking classes at the music school, the system will generate only one account. An account is to be generated for a student at the beginning of each term, charging the student for the upcoming terms lessons. 3. Students pay in advance. 4. If a student misses a class, their account is not adjusted. Instead they arrange for a make-up class at some stage. However this will not be arranged by the system being designed. 5. There are two amounts calculated. The rst amount is to be paid on the rst day of term and is the amount of classes multiplied by the class rate. The second amount is the amount to be paid if the student does not settle the account on the rst day of term and includes an additional late fee of 10

FUNCTIONAL REQUIREMENTS 6. Related functionalities are 3.1.3.9.

19

7. A sample account layout, currently used by the music school, can be found in Appendix B. This layout will not necessarily be used in the nal system. 3.1.5.3 Automatic Late Fee Inclusion

The system will provide functionality to automatically update accounts which have not been paid on the rst day of term to include the late fee of 10 3.1.6 Miscellaneous Features

The system will be designed to incorporate an icon which will inform the user when the system is processing information. This icon will be referred to as a thinking icon.

3.2

Optional Requirements

The following requirements are optional and will be implemented only after all core requirements have been satised. Optional requirements do not have to be satised for the system to be satisfactorily completed. 3.2.1 BAS Figures

The system will provide functionality to determine the information necessary for the user to complete a quarterly business activity statement. The system will not produce the actual BAS in the ATO required format. The system will perform the calculations required to complete the BAS seen in Appendix C. The user will be prompted to input the information required to calculate the dierent facets of the BAS that are not stored in the system. The system will calculate four types of tax as required: 1. GST 2. Withholding Tax 3. Installment Tax 4. Fringe Benets Tax Priority: Desirable 3.2.2 Add Book Owing

The system will provide functionality to associate an amount of money for each book a student owes the music school for, to the students prole. The system will store the books 1. Title 2. Author(s) 3. Supplier

FUNCTIONAL REQUIREMENTS 4. Amount owing

20

Note: This functionality is also related to 3.2.9. If this functionality is not implemented, the user will still be able to add monies for book owings with the Edit Details functionality. See 3.1.1.8. Priority: Desirable 3.2.3 View Marketing List

The system will provide functionality to allow the user to see a list of the ways students found out about the music school, and the percentage of total students (of all statuses) that found out through each medium. This is to determine the most successful forms of advertising. The list will include: 1. Word of Mouth 2. Family 3. Public Advertisement 4. School Priority: Highly Desirable 3.2.4 Add Lesson Plan

The system will provide functionality to allow the user to add a generic lesson plan, for each level, to the system. See Denition 7. The lesson plan will be in a plain text format. Priority: Highly Desirable 3.2.5 Edit Lesson Plan

The system will provide functionality to allow the user to edit a lesson plan stored in the system. Priority: Highly Desirable 3.2.6 View Lesson Plan

The system will provide functionality to allow the user to view a generic lesson plan for each level. Priority: Highly Desirable 3.2.7 Print Lesson Plan

The system will provide functionality to allow the user to print a lesson plan as it is displayed by the View Lesson Plan functionality. See 3.2.7. Priority: Highly Desirable

FUNCTIONAL REQUIREMENTS View Stock Count

21

3.2.8

The system will provide functionality to display the number of each musical item purchased by the music school, the number sold to students, and therefore the number remaining in stock. Priority: Desirable 3.2.9 List Book Owings

The system will provide functionality to allow the user to see a list of all students who owe money for books, what book they owe for and how much they owe. Priority: Desirable

NON-FUNCTIONAL REQUIREMENTS

22

Non-functional Requirements

Non-functional requirements are those which specify how the system will be implemented. These requirements include constraints on design and implementation. All non-functional requirements are considered to be core requirements.

4.1

Interface Requirements

The following requirements apply to the communication of the system with outside entities and within itself. 4.1.1 External Interfaces

An external interface is dened as being a mode of communication with entities which are external to the system being developed. Examples of such entities are users and hardware. 4.1.1.1 User Interfaces

1. All interaction between the user and the system is to be through a graphical user interface (GUI). 2. All features are to be accessed through buttons that are to appear in structured menus. 3. The user is to communicate to the system through the use of a mouse and keyboard. Figure 1 on the following page is an example GUI for the systems main screen. Note: Figure 1 is only for the purposes of illustrating the standard of the clarity and usability required for the system, and is not intended to be used in the nal system. The logo is a copy of the logo to be used in the nal system, however the menu will contatin other functionality and be displayed dierently. The user will navigate the functionalities through two main panes of GUIs. At least 70 percent of functional core requirements will be accessed through these two panes. Specically: 1. Main interface - which will provide access to functionalities shown in Table 1. For a description of the functionalities, see Section 3. The main interface will be 3.1.3.11the rst interface the user will see after they login to the system. 2. View Prole Interface This will display the details of either a student, teacher, class or inventory item and will provide access to functionalities described in Table 2. See section 3 for a full description of functions in Tables 1 and 2. Note: The interface descriptions may change slightly during the design phase of the software lifecycle. The following requirements have also been given for the user interfaces:

NON-FUNCTIONAL REQUIREMENTS

23

Item 1 2 3 4 5 6 7 9 10 11 12 13 14 15 16 17 18 19 20

Functionality Add Prospective Student Add New Teacher Add New Class View Details View List Calculate Wages (to calculate all wages) Print Wage List Generate Information Letter View School Timetable View Marketing List BAS Figures View Lesson Plan Generate Account (to generate all accounts) Print Account (to print all accounts) Add Inventory Item Enter Dates Add Supplier Store Information Letter View Supplier List Table 1: Main Interface

Priority Core Core Core Core Core Core Core Core Core Optional Optional Optional Core Core Core Core Core Core Core

Reference 3.1.1.3 3.1.1.4 3.1.1.5 3.1.3 3.1.3.8 3.1.5.1 3.1.4.4 3.1.1.12 3.1.3.6 3.2.3 3.2.1 3.2.6 3.1.5.2 3.1.4.5 3.1.1.6 3.1.1.2 3.1.1.7 3.1.1.11 3.1.3.7

Item 1 2 3 4 5 6 7 8 9 10 11 12 13

Functionality Print Details Edit Details Calculate Wages Print Wage Slip Generate Account Print Account Change Student Status Enrol a Student Unenrol a Student Add Book Owing Allocate a Teacher to a Class View Timetable Print Timetable

Prole from which the functionality will be accessible All All Teacher Teacher Student Student Student Student Student Student Class Student and Teacher Student and Teacher

Priority Core Core Core Core Core Core Core Core Core Core Core Core Core

Reference 3.1.4.1 3.1.1.8 3.1.5.1 3.1.4.3 3.1.5.2 3.1.4.5 3.1.1.13 3.1.2.1 3.1.2.2 3.2.2 3.1.2.3 3.1.3.5 3.1.4.6

Table 2: View Interface

NON-FUNCTIONAL REQUIREMENTS

24

Figure 1: Example Main Screen Layout 1. The Class Prole interface will contain a list of students names and also their contact telephone numbers and the name of both parents. 2. The interfaces will display menu items as lists, not as drop-down menus, in order to allow the user to view all options immediately. 4.1.1.2 Hardware Interfaces

1. The software is expected to operate on a personal computer with the following minimum hardware characteristics: (a) Intel Celeron 1000MHZ CPU (b) 32MB RAM (c) 1 gigabyte free disk space 2. The software is to interact with a mouse and keyboard, which are to be the sources of user input. 3. Interaction with the computers default printing device is also a necessary core hardware interface requirement, however the specications of the printing hardware are not essential to the design of the software.

NON-FUNCTIONAL REQUIREMENTS Software Interfaces

25

4.1.1.3

1. The main software interfacing will be done with a web browser. This is due to the requirement of designing the system to be compatible with the possibility of making parts or all of the system available on the web in the future. (See 4.7) The exact details of the web browser to be used however are not a specic requirement of the system. 2. Following are details of specic software that will be interfaced with: (a) Software name: Windows Version: XP Source: Microsoft (b) Software name: Excel Version: 2000 Source: Microsoft

4.1.2

Internal Interfaces

The following interfacing is required within the system: 1. Interfacing between the database and the user interfaces.

4.2

Performance Requirements

1. The user will wait no longer than ten seconds after requesting a functionality from the system for the request to be completed. 2. The exceptions to this requirement are the printing functional requirements(See 3.1.4 and the calculate all wages and accounts functionalities (see Section 3.1.5). 3. In the case of printing requirements, as the printing hardware performance is out of the control of the team, the system will take no longer than 10 seconds for the system to initiate a request to a printer. 4. The system will take no longer than 15 seconds to process a calculation request.

4.3

Security Requirements

The system is to provide a login feature which will be password activated. Users will be allocated a username and a password. This will allow only users with a username and password to access the system. (See section 3.1.1.1)

4.4

Implementation Constraints

The system will be implemented to allow for the possibility of making parts or all of the system available for use on the web at a later date. See 4.7.

NON-FUNCTIONAL REQUIREMENTS

26

4.5

Hardware Constraints

The design team will allow for mouse control of functionality which does not require text input. This is to aid the client who has small children and will require the system to be usable whilst a child is on the clients knee.

4.6

Software Constraints

1. The development of the system will be constrained by the availability of required software such as compilers and development tools. 2. The availability of these tools will be governed by the University of Melbourne. 3. The most recent versions of software development tools may not be installed at the University of Melbourne.

4.7

Design Constraints

1. The main constraint on the design of the system is the location of the client, in Brisbane. This will make the clarication of requirements dicult. However, the appointment of Kathleen Keogh to act on behalf of the client will aid in minimising the eects of this constraint. 2. The client location also means that the completed system will need to be easily maintained as team members will not be readily available for routine maintenance. 3. The system must be designed to allow web portability. That is, the system must be designed in such a way that transferring it onto the World Wide Web at a later date is possible.

4.8

Quality System Attributes

The following requirements relate to the quality of the system being produced. 4.8.1 Availability

This system will only be available on the clients personal lap-top, 24 hours a day. Should the user leave the programme running whilst sitting at the lap-top, data will remain in memory, unless edited, and the system will remain in the state in which the user left it. 4.8.2 Security

There will be a login to the lap-top, requiring a username and password. The software will only be available to people who have been able to log on to the computer through the Microsoft Windows XP security system already on the computer.

NON-FUNCTIONAL REQUIREMENTS Operability

27

4.8.3

The system will allow the user to operate it with a mouse, unless input is required from the keyboard. This is to allow the client to have one hand free to hold small children. 4.8.4 Attractiveness

The system will be presented such that menu items and database member details will be at least size 12 point to ensure readability. 4.8.5 Learnability

The system will be delivered with a user manual which will detail the use of the system to the client. Team Respect will also provide a tutorial for the client if the client wishes at system delivery time.

ACCEPTANCE CRITERIA

28

Acceptance Criteria

The acceptance criteria for the Music School Administration System are: 1. All core functional requirements are implemented. See 3.1 for details. 2. All non-functional requirements are satised. 3. User Documentation has been provided.

CLIENT SIGN-OFF

29

Client Sign-O

I, on behalf of Christine Masters, the client of the Music School Administration System, hereby agree that the requirements detailed in this document adequately define her requirements for the system.

-----------------Kathleen Keogh on behalf of Christine Masters

We, on behalf of Team Respect, hereby agree to provide the system as defined in this document.

--------------------------Amy Curran - Client Liaison

------------------------------Jonothan Conn - Project Manager

APPENDIX B

30

Appendix B
Term Two Account 2003 Tax Invoice ABN 39195022593

Term Two Dates: Monday 28 April (9 week term)

Friday 27 June 2003

Term Two Fees If paid at first lesson after this date 30 minute class 45 minute class $89.10 $118.80 $198.00 If paid

$98.00 $130.70 $217.80

piano lesson + group class

Total Due

THIS IS A TERM FEE. children are sick.

Lessons are only made up when

THERE IS NO REFUND FOR MISSED LESSONS. (Please note that lessons are not made up when holidays are taken during the term). Please complete the section below and return this sheet in an envelope with your payment. PLEASE PRINT CLEARLY Name Address Childs Name and Lesson Details

APPENDIX B Amount paid

31

Date paid

APPENDIX C

32

Appendix C
Business Activity Statment Template
G
Office use only

Michael Jones Pty Ltd 123 Lower Mountains Road MT PLEASANT NSW 2222

January to March 2003

Document ID ABN

Business Activity Statement

12 123 123 123 97 999 999 999 21 Apr 2003 21 Apr 2003 Cash

When completing this form, please use a BLACK pen only (to help with processing) leave boxes blank if not applicable (do not use N/A, NIL) show whole dollars only (do not show cents) do not use symbols such as +, , /, $ PAYG income tax instalment Complete Option 1 OR 2 (indicate one choice with an X)
Option 1: Pay a PAYG instalment amount quarterly ATO instalment amount T7

for the QUARTER from 1 Jan 2003 to 31 Mar 2003

Write the T7 amount at 5A in summary over the page OR if varying this amount, complete T8, T9, T4
Estimated tax for the year Varied amount for the quarter

T8 T9

$ $

Write the T9 amount at 5A in summary over the page and then complete the other sections
Reason code for variation

T4 OR

Option 2: Calculate PAYG instalment using income times rate

PAYG instalment income

T1 T2 T3

ATO instalment rate

OR New varied rate T1 x T2 (or x T3)

T11 $

Write the T11 amount at 5A in summary over the page and then complete the other sections
Reason code for variation
NAT 4235-7.2002

T4

E L P M A S
Payment due on GST accounting method Contact phone number Contact person who completed the form

Form due on

Goods and services tax (GST)

for the MONTH from 1 Mar 2003 to 31 Mar 2003

Total sales

5,300

From XXXX amended assessment

G1

.00

, ,

, ,

.00 .00

Does the amount shown at G1 include GST? (indicate with an X) Export sales

Yes

No

G2 G3

$ $

, , , ,

, , , ,

.00 .00 .00 .00

Other GST-free sales

Capital purchases

G10 $ G11 $

Non-capital purchases

.00

Go to summary over the page to report GST on sales at 1A and GST on purchases at 1B and then complete the other sections

1.70 .

Notional tax $XXX,XXX,XXX from XXXX amended assessment

.00

How to pay
Direct credit: transfer funds directly to the ATO using computer based banking software. Direct debit: have your payment deducted from your nominated bank account (excluding credit cards). Mail payments: mail this payment advice form together with your cheque / money order using the envelope provided. Please do not use pins or staples. Do NOT send cash.

Post Office: payments can be made at any Post Office by cash or cheque. A $3,000 cash limit applies. Your payment advice form must be presented with your payment. BPAY: contact your bank, credit union or building society to make this payment from your cheque or savings account. Cheques or money orders should be made payable to the Deputy Quote biller code 75556 and your EFT code (shown on the Commissioner of Taxation and crossed Not Negotiable. other side of this payment advice form) as the customer All cheques must be tendered in Australian currency. reference number.

Please note: payments cannot be made by credit card or in person at any ATO branch or ATOaccess site.

APPENDIX D

33

Appendix D

Sample Information Letter

date Dear Parent, Thank you for your phone call inquiring about the Music Masters program.I have enclosed some information about the classes for your perusal. During each lesson children are introduced to the fundamentals of music in a fun way. Using varying resources (puppets, stories, light percussive instruments) a foundation of beat, rhythm, listening skills and singing skills are introduced. Classes are held at 56 Strathmore Street Kedron and Oxford Street Bulimba. Children are placed in classes according to age and previous musical experience. The very young children attend a hour class ($9.90) while the children 3-4 years and older attend a hour class ($13.20). When the children reach school age they have the option of learning piano. They attend a 20 minute individual piano lesson and a 20 minute group class each week (both classes $22.00). These prices include the GST. You do not need to wait for a new term to enrol in a class. If you would like to enrol your child, please phone me to discuss available lesson times. (Always leave a message as when I am teaching I cannot answer the phone). Yours sincerely,

Christine Masters