# VCE Software Development Unit 3 Outcome 2 ## Criterion 3: Software Requirements Specification (SRS) Task Checklist This checklist is designed to help students verify that their **Software Requirements Specification (SRS)** meets all VCAA requirements to achieve a **Very High (9–10 marks)** rating under **Criterion 3** of the School-assessed Task (SAT). --- ## Part 1: Document Structure & Formatting (Rubric Band: 9–10) An SRS is a formal technical document. To achieve the highest score, it must be highly structured and organized. * [ ] **Cover Page:** * [ ] Title: Software Requirements Specification (SRS) for [Solution Name] * [ ] Student name and student number * [ ] Date and version number (e.g., Version 1.0) * [ ] **Table of Contents:** Automated table of contents showing clear page numbers. * [ ] **Clear Headings & Sections:** Follow a logical document structure using standard markdown or document hierarchy. * [ ] **Appendices:** A separate appendix section containing supporting evidence (e.g., data collection instruments, raw interview transcripts, survey summaries). --- ## Part 2: Deliverables for Indicator 1 — Proposed Solution Documentation ### 1. Purpose & Introduction (Rubric Band: 3–4) * [ ] **Purpose Statement:** Clearly define why this software solution is being created (i.e., explain the real-world problem, need, or opportunity it addresses). * [ ] **Objectives:** List 2–3 clear objectives of what the system will accomplish. ### 2. Requirements (Rubric Band: 5–6) * [ ] **Functional Requirements:** (What the system *must* do) * [ ] Document data input processes (e.g., how data enters the system, user forms). * [ ] Document data processing steps (e.g., calculations, queries, sorting, searching). * [ ] Document system outputs (e.g., reports, dynamic displays, file outputs). * [ ] Document data validation rules (e.g., type checking, range checking, existence checking). * [ ] **Non-Functional Requirements:** (How the system performs or behaves) * [ ] **Usability:** Interface standards, readability, font sizing, ease of use. * [ ] **Reliability:** Expected uptime, error handling, database backup stability. * [ ] **Performance (Speed):** Response times for queries, search execution speed. * [ ] **Security:** Authentication, secure password storage, user access roles. * [ ] **Portability/Flexibility:** Ability to scale or run on different systems if needed. ### 3. Constraints (Rubric Band: 5–6) Identify and describe the limitations that impact the development and implementation of the solution. * [ ] **Economic Constraints:** Budget limits, software licensing costs. * [ ] **Technical Constraints:** Hardware capabilities, operating system limitations, target programming language capabilities. * [ ] **Social/User Constraints:** Digital literacy of the target audience, physical accessibility constraints. * [ ] **Time/Schedule Constraints:** Milestones and fixed deadlines for completion. * [ ] **Legal/Regulatory Constraints:** (Must explicitly reference the following laws as per the VCAA Study Design): * [ ] **Copyright Act 1968 (Cwlth):** Protecting intellectual property, assets, and third-party libraries used in the solution. * [ ] **Privacy Act 1988 (Cwlth):** Aligning with Australian Privacy Principles (APPs), specifically **APPs 1, 3, 6, 8, 9, 11** (regarding data collection, usage, overseas disclosure, and security). * [ ] **Privacy and Data Protection Act 2014 (Vic):** Aligning with Information Privacy Principles (IPPs), specifically **IPPs 1, 2, 4, 5, 7, 9, 10**. ### 4. User Characteristics & Scope (Rubric Band: 7–8) * [ ] **User Characteristics:** * [ ] Describe the target audience(s) of the solution. * [ ] Detail their digital literacy levels, frequency of use, and any special accessibility requirements. * [ ] **Scope:** * [ ] Establish the **boundaries** of the solution (exactly what the software will and will not do). * [ ] Clearly list what features are *in scope* for the current version. * [ ] Clearly list features that are *out of scope* (e.g., potential future expansions). ### 5. Technical Environment (Rubric Band: 9–10) * [ ] **Operating System Requirements:** Operating systems where the developer and end-user will run the application. * [ ] **Hardware Specifications:** CPU, RAM, and storage requirements for the target system. * [ ] **Software Dependencies:** Libraries, runtime environments (e.g., Python runtime version), or frameworks needed. * [ ] **Data Sources:** Details of the data formats to be used (e.g., SQL database engine, TXT, CSV, or XML data file structures). ### 6. Analytical Diagrams (Rubric Band: 7–8) * [ ] Include the complete and corrected analytical tools completed during analysis (Criterion 2): * [ ] **Context Diagram (Level 0):** Shows external entities, system boundary, and primary data flows. * [ ] **Data Flow Diagram (Level 1):** Illustrates processes, data stores, entities, and interior data flows. * [ ] **Use Case Diagram:** Shows system boundary, actors, use cases, and associations (including `<<includes>>` and `<<extends>>` relationships). --- ## Part 3: Deliverables for Indicator 2 — Critical and Creative Thinking Evidence To achieve a score of **9–10**, students must document their critical analysis process. This is typically presented in a dedicated section or appendix of the SRS. * [ ] **Data Collection Requirements (Rubric Band: 1–2):** * [ ] Document the data that was collected to inform the SRS requirements (e.g., interview results, surveys, or existing report files). * [ ] **Initial Analysis Questions (Rubric Band: 5–6):** * [ ] List the specific questions used to analyze the collected data. * [ ] *Example:* "What are the primary bottlenecks in the current manual booking process?" * [ ] **Evaluation of Analysis Questions (Rubric Band: 7–8):** * [ ] Document an evaluation of the analysis questions (e.g., assess which questions yielded valuable design requirements and which ones were too broad or unhelpful). * [ ] **Follow-Up Questions (Rubric Band: 9–10):** * [ ] Document the **follow-up questions** asked to clarify ambiguities or details in the collected data. * [ ] Explain how the answers to these follow-up questions directly influenced or refined the final functional or non-functional requirements. * [ ] *Example:* "Following the initial interview, we asked: *'How should the system handle simultaneous bookings for the same time slot?'* The client's response led to the requirement for a real-time reservation concurrency lock." ---