Last updated: September 2026 · Reviewed by the Punjab Assignment Help software engineering team · Reading time: 11 minutes
Quick answer: ICT602 Software Engineering Assessment 2 at the Victorian Institute of Technology (VIT) is a group task. Your team writes a Software Requirements Specification (SRS) for the Smart Community Services Platform at Greenfield City Council. It must cover the system overview, functional and non-functional requirements, business rules, UI wireframes, system interfaces (GIS, payments, authentication, email/SMS), a UML use case diagram and class diagram, assumptions and constraints, plus a signed Work Breakdown Agreement. Most teams lose marks because their non-functional requirements cannot be measured.
ICT602 Assessment 2 key facts
| Item | Detail |
|---|---|
| Unit | ICT602 Software Engineering, Victorian Institute of Technology (Melbourne, Sydney, Adelaide and Geelong campuses) |
| Assessment | Assessment 2 (group): Software Requirements Specification |
| Case study | Greenfield City Council: Smart Community Services Platform (web and mobile) |
| Users | Residents, council employees, system administrators |
| Integrations | GIS, online payment gateway, authentication service, email/SMS notifications |
| Required appendix | Work Breakdown Agreement, individual contributions and team agreement, signed by all members |
| Referencing | IEEE numbered style is common in VIT ICT units (check your unit guide) |
Recommended SRS structure (based on ISO/IEC/IEEE 29148)
- Introduction: purpose, scope, the problem (duplicate records, slow responses, poor visibility of requests), definitions
- System overview: context diagram, user classes, operating environment
- Requirements specification: functional requirements, non-functional requirements, business rules
- User interface design: wireframes or mock-ups for key screens
- System interfaces: external systems and data exchanged
- UML modelling: use case diagram and class diagram
- Assumptions and constraints
- References and appendix (WBA)
Answer hints: functional requirements
Write each requirement as "The system shall…" with an ID, actor, priority (MoSCoW or High/Medium/Low) and a source linking it to the case study. Split vague requirements into testable ones. For example, do not write one line saying "manage accounts". Write these instead:
| ID | Requirement (example wording) | Actor | Priority |
|---|---|---|---|
| FR-1.1 | The system shall allow a resident to register using an email address and a verified mobile number. | Resident | Must |
| FR-2.1 | The system shall allow a resident to report an issue by selecting a category (road damage, waste, graffiti, street lighting), adding a photo and pinning a GIS location. | Resident | Must |
| FR-2.3 | The system shall send the resident an SMS/email notification whenever the request status changes. | System | Must |
| FR-4.2 | The system shall prevent double-booking of a facility time slot. | System | Must |
| FR-7.1 | The system shall allow a council officer to assign a request to a maintenance crew and set a priority level. | Council employee | Must |
| FR-10.2 | The system shall allow an administrator to create, suspend and change user roles. | Administrator | Must |
Answer hints: non-functional requirements (where marks are lost)
"The system shall be fast" or "shall provide high availability" cannot be tested. Add a metric to every NFR:
| Category (ISO/IEC 25010) | Measurable example |
|---|---|
| Performance | 95% of page loads complete in under 2 seconds with 1,000 concurrent users. |
| Availability | 99.5% monthly uptime, excluding scheduled maintenance announced 48 hours in advance. |
| Security | All data is encrypted in transit (TLS 1.2+) and at rest (AES-256). MFA is required for staff and admin accounts. |
| Access control | Role-based access control: residents cannot view other residents' requests, and every privilege change is logged. |
| Privacy | Complies with the Australian Privacy Principles and Victoria's Privacy and Data Protection Act 2014. Personal data is retained for no more than X years. |
| Accessibility | Meets WCAG 2.2 Level AA. |
| Scalability | Supports 50% growth in users without redesign (horizontal scaling). |
| Usability | A new resident can submit an issue in under 3 minutes without help (verified in usability testing). |
UI design hints
Include at least: login/registration, resident dashboard, report-an-issue form (with map pin), facility booking calendar, staff operations dashboard and admin user management. Build them in Figma, Balsamiq or draw.io. Under each figure, explain which requirement IDs the screen satisfies. This traceability impresses markers.
System interfaces hints
| External system | Data exchanged | Protocol / note |
|---|---|---|
| GIS / mapping | Issue coordinates, address lookup | REST API. Fallback: manual address entry |
| Payment gateway | Booking fees, refunds | PCI DSS compliant hosted checkout. No card data stored |
| Authentication | Login, MFA, identity verification | OAuth 2.0 / OpenID Connect |
| Email/SMS | Status updates, reminders | Provider API with a retry queue |
UML modelling hints
Use case diagram
- Primary actors (left): Resident, Council Employee, Administrator. Secondary actors (right): GIS Service, Payment Gateway, Notification Service, Authentication Service.
- Use «include» for mandatory sub-steps (e.g., Book Facility includes Make Payment) and «extend» for optional ones (e.g., Upload Photo extends Report Issue).
- Draw a system boundary box labelled "Smart Community Services Platform".
Class diagram
- Core classes:
User(abstract) →Resident,CouncilEmployee,Administrator(inheritance);ServiceRequest,MaintenanceTask,Facility,Booking,Payment,Event,Registration,Notification,Feedback. - Show attributes, key methods and multiplicities: Resident 1 — 0..* ServiceRequest; Facility 1 — 0..* Booking; Booking 1 — 0..1 Payment.
- Use an enumeration for
RequestStatus(Submitted, Assigned, InProgress, Resolved, Closed).
Assumptions and constraints hints
Keep assumptions (things you believe are true: residents have smartphones, third-party APIs are available) separate from constraints (limits you must work within: council budget, legacy data migration, privacy law, WCAG). Add a risk for each assumption. For example, if the GIS API fails, the fallback is manual address entry.
Group work: Work Breakdown Agreement tips
- Split work by section and give each person a review task, so everyone checks another member's section.
- Keep one shared document (OneDrive or Google Docs) with version history. It is your evidence if contribution is disputed.
- All members must sign and date the WBA and the declaration.
Top 5 mistakes in ICT602 SRS submissions: (1) NFRs with no numbers, (2) use case diagrams with no external system actors, (3) class diagrams with no multiplicities, (4) wireframes not linked to requirements, (5) inconsistent reference style.
Need help with your SRS, use case or class diagram?
Our software engineering tutors can review your requirements for testability, check your UML notation and explain IEEE referencing, whether you are at VIT Melbourne, Sydney, Adelaide or Geelong.
ICT602 Assessment 2 answer hints and Greenfield City Council SRS example
Students often search for ICT602 Assessment 2 answers, a Greenfield City Council SRS example or a Smart Community Services Platform use case diagram. Copying another group's SRS is risky: VIT uses similarity checks, and your WBA must show who wrote each part. What helps is knowing what a High Distinction SRS looks like. The example requirements, measurable NFRs, interface table and UML hints above give you that model.
Answer-hint recap: write every requirement as "The system shall…" with an ID and priority, add a number to every NFR, put the external services on your use case diagram as secondary actors, show multiplicities on your class diagram, and link each wireframe to requirement IDs.
Where can I find ICT602 Assessment 2 answers?
There is no official answer. Each group writes its own SRS for the Greenfield City Council case. Use the example requirements and UML hints on this page as a model. Our tutors can review your draft for testability and notation.
Is there an SRS example for the Smart Community Services Platform?
This page gives example functional requirements, measurable non-functional requirements, an interface table and use case and class diagram hints for the Greenfield City Council platform.
Can I get ICT602 help at VIT Melbourne, Sydney, Adelaide or Geelong?
Yes. Punjab Assignment Help offers online software engineering tutoring for VIT students on every campus.
Frequently asked questions
What is an SRS in software engineering?
A Software Requirements Specification is a formal document that describes what a system must do (functional requirements) and how well it must do it (non-functional requirements). It also sets out interfaces, constraints and models, and it is the baseline for design and testing.
How do I write a good non-functional requirement?
Make it measurable and testable. For example: "95% of pages load in under 2 seconds with 1,000 concurrent users" rather than "the system shall be fast."
What actors belong in the Greenfield City Council use case diagram?
The primary actors are Resident, Council Employee and Administrator. The secondary actors are the external GIS, payment gateway, authentication and email/SMS services.
What is the difference between include and extend in a use case diagram?
«include» is a step that always happens as part of the base use case. «extend» is optional behaviour that only happens under certain conditions.
Which classes should be in the Smart Community Services Platform class diagram?
User (with Resident, CouncilEmployee and Administrator subclasses), ServiceRequest, MaintenanceTask, Facility, Booking, Payment, Event, Notification and Feedback, with attributes, methods and multiplicities.
Related help
Academic integrity note: this guide gives structure and example wording to explain the concepts. Your group must write its own SRS and follow VIT's academic integrity and generative AI policies.