SRS - Software Requirement Specification

TSE2451
Project Part 1
for
Alumni System
Version 1.0
Tutorial Section: TT4L

Group No.: Group 5
Lim Jun Xiang (Leader) 1181200619

Cheng Jer Seng 1201200759
Kok Jun Xuan 1201100699
Date:
Table of Contents
Table of Contents......................................................................................................................2
1 Introduction......................................................................................................................... 3
1.1 Purpose........................................................................................................................ 3
1.2 Scope........................................................................................................................... 3
1.3 Product Overview......................................................................................................... 4
1.3.1 Product Perspective............................................................................................ 4
1.3.2 Product Functions............................................................................................... 5
1.3.3 User Characteristics............................................................................................ 5
1.3.4 Limitations........................................................................................................... 6
1.4 Definitions.....................................................................................................................7
2 References...........................................................................................................................8
3 Use Case.............................................................................................................................. 9
3.1 Use Case Specification.............................................................................................. 10
3.2 E-R Diagram...............................................................................................................44
4 Requirements.................................................................................................................... 45
4.1 Functions....................................................................................................................45
4.2 Performance Requirements....................................................................................... 45
4.3 Usability Requirements.............................................................................................. 45
4.4 Interface Requirements.............................................................................................. 45
4.5 Logical Database Requirements................................................................................ 45
4.6 Design Constraints..................................................................................................... 45
4.7 Software System Attributes........................................................................................ 45
4.8 Supporting Information............................................................................................... 46
5 Verification.........................................................................................................................47
5.1 Functions....................................................................................................................47
5.2 Performance Requirements....................................................................................... 47
5.3 Usability Requirements.............................................................................................. 47
5.4 Interface Requirements.............................................................................................. 47
5.5 Logical Database Requirements................................................................................ 47
5.6 Design Constraints..................................................................................................... 47
5.7 Software System Attributes........................................................................................ 47
5.8 Supporting Information............................................................................................... 47
6 Appendices........................................................................................................................48
6.1 Assumptions and dependencies................................................................................ 48
6.2 Acronyms and abbreviations...................................................................................... 48
1 Introduction
1.1 Purpose
The purpose of MMU Alumni Management System (MMUAMS) focusing on

improved communication, enhanced engagement, and increased fundraising
1. Promote communication between the MMU and alumni.

2. Enhance engagement between the MMU and alumni.
3. Increased fundraising efforts by the MMU.
1.2 Scope
The MMU Alumni Management System (MMUAMS) is a system designed to

facilitate communication, enhance engagement, and support fundraising efforts
between MMU and alumni community. It serves as a centralised platform where the
MMU student and staff can interact with alumni, provide them with relevant
information, and encourage their participation in various activities or events. The
system enables alumni to stay connected with MMU, engage with fellow alumni,
access resources, and contribute to MMU through donations.
Purpose Improved Communication
Benefit The system will enable efficient and effective communication between
MMU and alumnus
Objective To provide a platform for post announcements, news, and event

invitations, ensuring alumnus receive timely and relevant information
Goal To foster strong and consistent communication channels, allowing

MMU to maintain a positive and ongoing relationship with alumni
community
Purpose Enhanced Engagement
Benefit The system will increase engagement levels between MMU and
alumni, fostering a sense of belonging and involvement
Objective To provide features such as mentorship programs, job boards, and

event management, creating opportunities for alumni to connect,
collaborate, and actively participate
Goal To strengthen the alumni network, encourage alumni to contribute their

skills, knowledge, and resources, and promote lifelong engagement
with MMU
Purpose Increased Fundraising Efforts
Benefit The system will support and streamline the MMU's fundraising
initiatives
Objective To enable online donation mechanisms, making it convenient for

alumni to contribute financially
Goal To enhance the MMU's financial resources by encouraging alumni to

make regular and meaningful donations, thereby supporting the
MMU's projects, scholarships, research, and other important
endeavours
1.3 Product Overview

1.3.1 Product Perspective
The system involves three main actors: students, alumni, and admins. It leverages
AWS Amplify as the front-end server and AWS Lambda as the back-end server. The
front-end server integrates with LiveChat for messaging services and Ipay88 for
payment gateway functionality. The back-end server connects to AWS ADS for
system data storage, Amazon S3 for asset storage such as file, video and image, and
the Student Information System for accessing student data.
System interfaces
Student Information System: The AMS interacts with the Student Information System
to retrieve student data, such as enrollment status and contact details.
User interfaces
Student/Alumni Interface:
The UI style focuses on simplicity, clarity, and ease of navigation.
Clean and Modern Design:

- a clean and visually appealing design with modern UI elements and intuitive layouts.
Responsive Design:
- ensuring that it adapts to different screen sizes and devices including desktop,
tablets, and mobile devices.
System Administrator (Admin Panel) Interface:

The UI style focuses on usability, data management, and system control.
Dashboard:
- provides admins with an overview of system metrics, notifications, and important
updates.
Hardware interfaces
Hardware Name Specification
Front-end Server AWS Amplify
Back-end Server AWS Lambda x86 Processor, 2GB RAM
Cloud-based Storage Amazon S3 1TB ROM
End-User Devices Desktop computers, laptops,

tablets, and smartphones
Software interfaces
The system should be designed to be compatible with popular web browsers such as
Google Chrome, Mozilla Firefox, Safari, and Microsoft Edge.
Communications interfaces
The system uses standard network protocols, HTTP/HTTPS, for communication

between the front-end and back-end server, as well as external service providers.
Memory constraints
The system requires a minimum of 1GB of primary memory (RAM) and 2GB of
secondary memory (ROM) for browser installation and execution.
Operations
Admin:
- News management: Create, edit, and publish news articles.
- Event management: Approve or reject event proposals, manage event details.
- Memory management: Upload and manage alumni memories.
- Application management: Review and process student applications for discounts,
career workshops, and events.
- Account management: Administer user accounts and permissions.
- Message management: Receive and respond to user messages.
- Donation tracking: Monitor and track donation records.
- Job vacancy management: Create and manage job postings.
Alumni:
- Job vacancy management: Create and manage job postings.
- Donation tracking: View personal donation history and details.
- Message interface: Communicate with admins via LiveChat service.
- Information view: Access information related to donations, news, memories, job
vacancies, events, career workshops, and discounts.
- Donation: Make donations to MMU.
- Event proposal submission: Submit event proposals for review.
- Event request management: Manage event requests.
Student:
- Information view: Access information related to donations, news, memories, job
vacancies, events, career workshops, and discounts.
- Message interface: Communicate with admins via LiveChat service.
- Discount application: Apply for available discounts.
- Career workshop application: Apply for career workshops.
- Resume submission: Submit resumes for a job.
- Event application: Apply for participation in events.
Site adaptation requirements
Not relevant
Interfaces with services
Service Description
LiveChat a messaging service provider, to enable real-time communication

between users. It relies on LiveChat's infrastructure and APIs to deliver
messaging functionality.
Ipay88 a payment gateway service, to facilitate secure online payments. It

leverages Ipay88's services and APIs for payment processing and
transaction management.
1.3.2 Product Functions
Figure 1.0 Alumni Management System Use Case
1.3.3 User Characteristics
User Admin
Characteristics A system administrator responsible for managing and
maintaining the Alumni Management System.
Educational Diploma to bachelor's degree.

Level
Experience Experience in administrative tasks, data management, and

system administration.
Technical Have knowledge of system configuration, and user management.

Expertise
User Alumnus
Characteristics Individuals who have graduated from MMU.
Educational Diploma/foundation to doctor's degree.

Level
Experience Diverse professional experiences.
Technical Have varying levels of technical expertise, ranging from basic

Expertise computer skills to advanced knowledge.
User Student
Characteristics Individuals who are currently enrolled in MMU.
Educational Secondary school to undergraduate programs.

Level
Experience Have limited professional experience due to their ongoing

studies. However, they may have some experience using
educational technologies and online systems.
Technical Possess varying levels of technical expertise. However, they are

Expertise generally more familiar with technology and digital tools than
the average user.
1.3.4 Limitations
Regulatory Requirements and Policies
- Data Protection and Privacy Laws: The Alumnus Management System needs to
comply with relevant data protection and privacy regulations, such as the General
Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA).
These regulations dictate how personal data should be collected, stored, processed,
and shared.
- Education Regulations: The system may need to adhere to specific regulations and
policies set by educational authorities or governing bodies to ensure compliance with
academic standards, student information privacy, and alumni engagement.
Hardware Limitations
Signal Timing Requirements: In some cases, the system may need to integrate with
hardware devices or external systems that have specific signal timing requirements.
The software must be designed to handle such timing constraints to ensure proper
synchronization and communication.
Storage Capacity: The alumni system may accumulate a significant amount of data
over time. A strong storage capacity is necessary to handle this data growth and
ensure seamless system operations.
Higher-Order Language Requirements
English
Safety and Security Considerations

User Authentication and Authorization: The system should have appropriate
mechanisms to verify user identities, such as username/password authentication,
two-factor authentication.
1.4 Definitions
Term/ Acronym/ Abbreviation Expansion/ Description
AMS
ROM Read-Only Memory. It is a type of

computer memory that stores data
permanently and cannot be modified
or erased.
RAM Random Access Memory. It is a type

of computer memory that is used for
temporary storage of data that is
actively being accessed by the
computer's processor.
GB Gigabyte. It is a unit of digital storage

capacity that equals 1 billion bytes. It
is commonly used to measure the
size of computer files, storage
devices, and memory capacity.
Front-end It refers to the part of a website or

application that users interact with
directly.
Back-end It refers to the server-side of a

website or application that users do
not directly interact with.
2 References
Alumni Management System
https://www.iitms.co.in/blog/features-of-alumni-management-software.html
LiveChat
https://platform.text.com/docs/messaging
MMU Centra of Alumni

https://alumni.mmu.edu.my/
TAYLOR'S ALUMNI COMMUNITY

https://www.taylorsalumni.org/
System Architecture
https://aws.amazon.com/blogs/architecture/throttling-a-tiered-multi-tenant-rest-api-at-
scale-using-api-gateway-part-1/
3 Requirement
3.1 Function
Use Case ID UC001 Version 1.0
Feature F001 Upload Event Proposal
Purpose To allow alumnus to submit event proposal
Actor Alumnus
Trigger -
Precondition The alumnus must be registered and logged into the Alumnus
Management System
Scenario Name Step Action
Main Flow 1 The alumnus clicks the "Upload Event Proposal" button.
2 The system prompts the alumnus to enter information about the

event, including the event name, description, proposed date and
time, type of event and attach the event proposal (PDF).
3 The alumnus enters the required information into the system.
4 The alumnus uploaded the event proposal attachment.
5 The alumnus clicks the “Submit” button to submit the form.
6 The system validates the information entered and confirms that all
required fields have been completed.
7 The system saves the event proposal and notifies the alumnus that
their proposal has been submitted for review.
Alternate Flow - 6.1 If the alumnus enters invalid or incomplete information, the system
Invalid will prompt them to correct the errors before allowing them to
Information submit the proposal.
Rules Only registered alumnus with the necessary permissions can submit event
proposals.
All required fields must be completed before a proposal can be submitted.
Author Jun Xiang

Figure 2.0 Activity Diagram - Upload Event Proposal
Feature F002 Check Event Proposal Status
Purpose To allow alumnus to track the status of submitted event proposals
Actor Alumnus
Trigger -
Precondition The alumnus must be registered and logged into the Alumni Management
System and must have previously submitted one or more event proposals.
Main Flow 1 The alumnus clicks the "Check Event Proposal Status" button.
2 The system displays a list of all event proposals submitted by the

alumnus.
3 The alumnus selects the proposal they want to check the status of.
4 The system displays the current status of the proposal, which may
be one of the following: "Submitted," "Under Review," "Approved,"
"Rejected," or "Cancelled."
Alternate Flow - 2.1 If the alumnus has not submitted any event proposals, the system
No Submitted should display a message “No Submitted Proposal”.
Proposal
Alternate Flow - 4.1 If the proposal is still "Under Review", the system should display
Status the estimated timeline for review and approval.
4.2 If the proposal has been "Rejected", the system should display the
reason for the rejection commented by the admin and allow the
alumnus to resubmit the proposal.
4.3 If the proposal has been "Approved”, the system should display the
advisor information.
Rules Only registered alumnus can check the status of event proposals they
have submitted
Author Jun Xiang
Figure 3.0 Activity Diagram - Check Event Proposal Status

Feature F003 Leave a message
Purpose To allow student/alumnus to send live chat messages to the support team
of the system for any inquiries, assistance, or feedback
Actor Student, Alumnus
Trigger -
Precondition -
Main Flow 1 The student/alumnus clicks the "LiveChat" icon button.
2 The system connects the student/alumnus to “LiveChat” and

listens to the new message.
3 The student/alumnus types in their message in the chat box and

clicks the “send” button.
4 The system pushes the message to the chat history.
Alternate Flow - 2.1 If the “LiveChat” is unavailable, the system should display the
“LiveChat” is alternative contact methods.
unavailable
Rules The system may log all conversations for quality assurance and future
reference.
The student/alumnus and the admin can exchange messages in real-time

until the admin ends the chat
Author Jun Xiang

Figure 4.0 Activity Diagram - Leave a message
Feature F004 Check & Response Message
Purpose To allow admin to manage “LiveChat” conversations and respond to

inquiries, assistance requests, or feedback from the alumnus and student.
Actor Admin
Trigger -
Precondition The admin must be logged into the Alumni Management System and they
must have the necessary permissions to access the “LiveChat” feature.
Main Flow 1 The admin clicks the "LiveChat" button in the navigation bar.
2 The system connects the admin to “LiveChat”.
3 The system displays a list of all active and past “LiveChat”

conversations.
4 The admin selects a conversation they wish to view or respond to.
5 The system displays the chat history for the selected conversation.
6 The system listens to the new message.
7 The admin types in their response in the chat box.
8 The system sends the admin's response to the admin in real-time.
9 The admin and the student/alumnus can exchange messages until

the admin ends the chat.
10 The admin clicks the “End Chat” button to end the conversation.
Rules Only registered admin with the necessary permissions can access the
"LiveChat” feature.
The system may log all conversations for quality assurance and future
reference.
Author Jun Xiang

Figure 5.0 Activity Diagram - Check & Response Message
Feature F005 View Donation
Purpose To provide alumnus with detailed information about a donation campaign

before making a donation.
Actor Alumnus
Trigger -
Precondition -
Main Flow 1 The alumnus click the "Donation" button in the navigation bar.
2 The system displays detailed information about the donation,

including the goal, the expected impact of the donation, and any
other relevant details.
3 The alumnus reviews the information provided and decides

whether or not to make a donation.
4 If the alumnus decides to make a donation, they can proceed to

the “Make Donation” process by clicking the “Make Donation”
button.
Rules -
Author Jun Xiang
Figure 6.0 Activity Diagram - View Donation
Feature F006 Make Donation
Purpose To allow alumnus to make donations
Actor Admin
Trigger -
Precondition -
Main Flow 1 The alumnus clicks the "Make Donation" button in the “Donation”
page.
2 The system prompts the alumnus to specify the donation amount,

donation purpose, donor's name, email, and payment method
(credit card, online banking, e-wallet).
3 The alumnus enters the required information and selects the

preferred payment method.
4 The alumnus click the “Donate” button, to confirm the donation.
5 The system redirects the alumnus to the Ipay88 payment gateway

website.
6 The alumnus enters their payment details and confirms the

transaction.
7 The Ipay88 payment gateway processes the transaction and

notifies the system of the payment status.
8 The system updates the donor's record, sends a confirmation email

to the donor, and records the donation in the system.
Alternate Flow - 4.1 If the alumnus encounters any technical issues during the donation
Donation process, the system should suggest that the user try again later.
Process Failed
Rules The donation process must be secure, with appropriate measures in place
to protect donor information and prevent fraud.
The system must provide a variety of payment methods to accommodate

the preferences of different alumnus.
The system may track and report on donation activity.
The system should issue receipts or acknowledgments to donors to

confirm their donation and provide tax information if applicable.
Author Jun Xiang

Figure 7.0 Activity Diagram - Make Donation
Feature F007 Manage news
Purpose The admin manages news by creating, updating, or deleting news articles.
Actor Admin
Trigger -
Precondition The user must have the appropriate login credentials to access the
system.
Main Flow 1 The admin clicks the "Manage news" button.
2 The system displays a list of existing news articles.
3 The admin selects an existing article to update or delete, or

chooses to create a new article.
4 If the admin chooses to create a new article, the system displays a

form for the admin to fill out with the article details, including the
article title, date, author, content, and any additional information.
5 If the admin chooses to update an existing article, the system

displays the article details in a form that can be edited..
6 If the admin chooses to delete an existing article, the system

prompts the admin to confirm the deletion.
7 The admin saves any changes made to the article or confirms the
deletion, and the system updates the database accordingly.
Alternate Flow - 4.1& If the admin enters invalid or incomplete information, the system
Invalid 5.1 will prompt them to correct the errors before allowing them to
Information submit the update.
Rules The news articles must include a title, date, author, and content.
Author Kok Jun Xuan

Figure 8.0 Activity Diagram - Manage news
Feature F008 Manage events
Purpose The admin manages events by creating, updating, or deleting them.
Actor Admin
Trigger
system.
Main Flow 1 The admin clicks the "Manage events" button.

2 The system displays a list of existing events.
3 The admin selects a current event to update or delete, or chooses

to create a new event.
4 If the admin chooses to create a new event, the system displays a

form for the admin to fill out with the event details, including the
event name, date, time, location, description, and any additional
information.
5 If the admin chooses to update an existing event, the system

displays the event details in a form that can be edited.
6 If the admin chooses to delete an existing event, the system

prompts the admin to confirm the deletion.
7 The admin saves any changes made to the article or confirms the
deletion, and the system updates the database accordingly.
Alternate Flow - 4.1& If the admin enters invalid or incomplete information, the system
Invalid 5.1 will prompt them to correct the errors before allowing them to
Rules The admin must provide a unique title for each event.
Author Kok Jun Xuan

Figure 9.0 Activity Diagram - Manage events
Feature F009 Manage memories
Purpose An admin user manages the memories in the system, including creating,
updating, and deleting memories, as well as managing tags and
categories associated with the memories.
Actor Admin
Trigger The admin selects an option to manage desired information.
system.
Main Flow 1 The admin clicks the "Manage memories" button.

2 The admin selects a memory to manage or creates a new memory.
3 The system displays a list of all memories currently in the system.
4 The admin selects a memory to manage or creates a new memory.
5 The system displays the details of the selected memory, including

the title, description, image, and associated tags and categories.
6 The system updates the information in the database and provides

feedback to the admin on the success or failure of the operation.
Alternate Flow - 4.1 If the admin enters invalid or incomplete information, the system
Rules The system should allow the admin to upload multiple images for each
memory.
Author Kok Jun Xuan
Figure 10.0 Activity Diagram - Manage memories
Feature F010 Manage event request
Purpose An admin user manages event requests in the system, including

reviewing, approving, or rejecting event requests, updating event
information, and communicating with event organizers.
Actor Admin
system.
Main Flow 1 The admin clicks the "Manage event requests" button.
2 The system displays a list of pending event requests..

3 The admin can review the event details, including the event name,
description, date, time, location, and organizer information.
4 The admin can approve or reject the event request based on the
event details and system requirements.
5 If the event is approved/rejected, the system notifies the event

organizer and updates the event status to "approved/rejected.."

Rules The admin should be able to view a list of approved events and their
details.
Author Kok Jun Xuan
Figure 11.0 Activity Diagram - Manage event request

Feature F011 Manage application
Purpose The admin manages job applications by viewing, approving, or rejecting

them.
Actor Admin
system.
Main Flow 1 The admin clicks the "Manage application" button.
2 The system displays a list of pending job applications.
3 The admin selects the application to be reviewed.
4 The system displays the details of the selected application..
5 The admin selects "Approve/Reject".

Alternate Flow - 2.1 If there are no pending applications, the system displays a
Invalid message indicating that there are no applications to review
Information
Rules The admin should be able to view a list of approved and rejected job
applications, as well as their details.
Author Kok Jun Xuan

Figure 12.0 Activity Diagram - Manage application
Feature F012 Manage account
Purpose An admin user manages user accounts in the system, including creating,
updating, and deleting user accounts
Actor Admin
Trigger The admin selects an option to manage the desired account.
system.
Main Flow 1 The admin selects the option to manage user accounts.
2 The system displays a list of existing user accounts.
3 The admin can create a new user account by providing the

necessary user information, including the user's name, email,
username, password, and role.
4 The admin can manage user accounts, including creating,

updating, or deleting user accounts, as well as resetting passwords
or disabling accounts as needed.

Rules The system should enforce password complexity and expiry policies to
ensure the security of user accounts.
Author Kok Jun Xuan
Figure 13.0 Activity Diagram - Manage account
Feature F013 Track donation
Purpose An admin user tracks donations made to the organization, including

recording donations and generating reports.
Actor Admin
Trigger The admin selects an option to track donations.
system.
Main Flow 1 The admin selects the option to track donations.
2 The system displays a list of existing donations, including the

donor name, donation amount, date of donation, and any
associated notes.
3 The admin can generate reports based on the donation data.
4 The system updates the donation information in the database and

provides feedback to the admin on the success or failure of the
operation.
Alternate Flow - 4.1 If there are no existing donations in the system, the system
Invalid displays a message indicating that there are no donations to track
Information
Rules The admin can export donation records to a file format, such as CSV or
Excel, for reporting or analysis purposes.
Author Kok Jun Xuan

Figure 14.0 Activity Diagram - Track donation
Feature F014 Manage job vacancy
Purpose An admin user tracks donations made to the organization, including

recording donations and generating reports.
Actor Admin
Trigger
system.
Main Flow 1 The admin selects the option to manage job vacancies.
2 The system displays a list of existing job vacancies, including the
job title, job description, required qualifications, and application
deadline.
3 The admin can create a new job vacancy by providing the

necessary information.
4 The admin can edit an existing job vacancy by modifying the job
details
5 The system updates the job vacancy and candidate information in

the database and provides feedback to the admin on the success
or failure of the operation.
Alternate Flow - 4.1 The system updates the job vacancy in the database and provides
Invalid feedback to the admin on the success or failure of the operation.
Information
Rules The admin can specify the application process for each job vacancy, such
as whether to require a cover letter, resume, or references.
Author Kok Jun Xuan
Figure 15.0 Activity Diagram - Manage job vacancy
Feature F015 View memories
Purpose To allow alumnus and student to view memories
Actor Alumnus, student
Trigger The alumnus and student clicks the “information" button.
Precondition The alumnus and student must be registered and logged into the Alumni
Management System
Main Flow 1 The alumnus and student clicks the “information” button.
2 The alumnus and student chooses “memories” button in

information interface
3 The alumnus and student is able to select a year of memories.
4 The system should display the memories of the year.

5
Alternate Flow - 4.1 If the student enters an invalid or incorrect year, the system will
Invalid prompt them to correct the errors before allowing them to enter the
Information next stage.
Rules The system will request the alumnus or student to select a year to view its
memories.
Author Cheng Jer Seng
Figure 16.0 Activity Diagram - View memories
Feature F016 View news
Purpose To allow alumnus and student to view news
Management System.
2 The alumnus and student chooses “news” button in information

interface
3 The system should display the latest news.
Alternate Flow - -
Invalid
Information
Rules
Figure 17.0 Activity Diagram - View news
Feature F017 View job vacancy
Purpose To allow alumnus and student to view job vacancy
Trigger The alumnus and student clicks the “job vacancy" button.
Management System.
2 The alumnus and student chooses “job vacancy” button in

3 The alumnus and student is able to select the type of their faculty.
4 The system should display the list of jobs that are related to their
faculty.
Alternate Flow - 4.1 If the student enters invalid or incorrect faculty, the system will
Invalid prompt them to correct the errors before allowing them to enter the
Rules The system will request the alumnus or student to select a faculty to view
the list of jobs that are related.
Figure 18.0 Activity Diagram - View job vacancy

Feature F018 View event
Purpose To allow alumnus and student to view event
Management System.
2 The alumnus and student choose “event” button in information

interface
3 The system should display the latest event.
Alternate Flow - -
Invalid
Information
Rules -

Figure 19.0 Activity Diagram - View event
Feature F019 View career workshop
Purpose To allow alumnus and student to view career workshop
Trigger The alumnus and student clicks the “career workshop" button.
Management System.
2 The alumnus and student chooses “career workshop” button in

3 The system should display all the career workshops.
Alternate Flow - -
Invalid
Information
Rules -
Figure 20.0 Activity Diagram - View career workshop
Feature F020 View discount
Purpose To allow alumnus and student to view discount
Management System.
2 The alumnus and student chooses “discount” button in information

interface
3 The alumnus and student is able to view discount that provided
Alternate Flow - -
Invalid
Information
Rules -
Figure 21.0 Activity Diagram - View discount

Feature F021 Apply career workshop
Purpose To allow student to apply career workshop
Actor student
Trigger student clicks the “information" button.
Precondition The student must be registered and logged into the Alumni Management
System.
Main Flow 1 The student clicks the “information” button.
2 The student choose “career workshop” button in information

interface
3 The student should be able to view the career workshop that is

provided.
4 The student can select and apply for the workshop by clicking the
“apply” button.
5 The system will display a success message.
Alternate Flow - 4.1 If the student doesn't meet the requirement to apply for the
Invalid workshop, the system will prompt them to reselect the workshop
Information before allowing them to enter the next stage.
Rules The system will check the requirement of the workshop that is applied.

Figure 22.0 Activity Diagram - Apply career workshop
Feature F022 Apply discount
Purpose To allow student to apply discount
Actor student
System.
2 The student choose “discount” button in information interface
3 The student should be able to view the discount that is provided.
4 The student can select and apply for the discount by clicking the
“apply” button.
Alternate Flow - 4.1 If the student doesn't meet the requirement to apply for the
Invalid discount, the system will prompt them to reselect the discount
Information before allowing them to enter the next stage.
Rules The system will check the requirement of the discount that is applied.

Figure 23.0 Activity Diagram - Apply discount
Feature F023 Submit resume
Purpose To allow student to submit resume
Actor student
Trigger The student clicks the “information" button.
System.
2 The student choose “personal information” button in information

interface
3 The student should be able to view their personal information.
4 The student can upload and submit their resume by clicking the
submit button.

Feature F023 Submit resume
Purpose To allow student to submit resume
Actor student
Alternate Flow - If the student enters invalid or incorrect information, the system will
Invalid prompt them to correct the error before allowing them to enter the
Rules The system will update the latest information to his personal information.
Figure 24.0 Activity Diagram - Submit resume

Feature F024 Apply event
Purpose To allow student to apply event
Actor student
System.
2 The student choose “event” button in information interface
3 The student should be able to view the latest event..
4 The student can select and apply to join the event by clicking the
“apply” button.
Alternate Flow - 4.1 If the student doesn't meet the requirement to apply for the event,
Invalid the system will prompt them to reselect the event before allowing
Information them to enter the next stage.
Rules The system will check the requirement of the event that is applied.

Figure 25.0 Activity Diagram - Apply event
3.2 Performance Requirements
Specify the static and the dynamic requirements numerically as described in the
ISO guidelines, to describe the required performance of the software system.
Requirement ID Description Author
REQ_PR001 The system takes no Cheng Jer Seng

longer than 5 seconds to
log into the interface.
REQ_PR002 The system is able to Lim Jun Xiang

respond to the user's input
in 2 seconds.
REQ_PR003 The system is able to Kok Jun Xuan

handle 2000 online users
at the same time and will
not crash.
3.3 Usability Requirements
Define usability and quality in use requirements and objectives for the software
system that can include measurable effectiveness, efficiency, satisfaction criteria
and avoidance of harm that could arise from use in specific contexts of use.
Requirement ID Description Author
REQ_UR001 The system should provide Lim Jun Xiang

a clean interface by using
suitable font colour and
size.
REQ_UR002 The system should Kok Jun Xuan

respond to user
interactions within 2
seconds, ensuring that
users can navigate through
the system quickly.
REQ_UR003 The system should Cheng Jer Seng

respond to invalid
input.The system will
prompt them to correct the
error.
3.4 Interface Requirements

3.5 Logical Database Requirements
3.6 Design Constraints
Specify constraints on the system design imposed by external standards,

regulatory requirements or project limitations.
The MMUAMS should be built by using specific technology or programming

languages such as html5 or python.There may be strict deadlines for the alumni system
needs to be developed and deployed. Time constraints can impact the scope of the
system.
3.7 Software System Attributes
Specify the required attributes of the software product. For example:

a) Reliability - specify the factors required to establish the required reliability of
the software system at
the time of delivery.
b) Availability - specify the factors required to guarantee a defined availability
level for the entire system
such as checkpoint, recovery and restart.
c) Security - specify the requirements to protect the software from accidental or
malicious access, use
modification, destruction or disclosure.
d) Maintainability - specify attributes of software that relate to the ease of
maintenance of the software
itself. These may include requirements for certain modularity, interfaces or
complexity limitation.
Requirements should not be placed here just because they are thought to be good
design practices.
e) Portability - specify attributes of software that relate to the ease of porting the
software to other host
machines and/or operating systems.
Attributes Description
Reliability Error handling, fault tolerance, data integrity, reliability testing

factors
Security User authentication and access control, Data encryption
Maintainability Code quality,Documentation
Portability Platform independence, Configuration flexibility
3.8 Supporting Information
Place any supporting information from requirements elicitation here.

Additional supporting information to be considered includes:
a) sample input/output formats, descriptions of cost analysis studies or results of
user surveys;
b) supporting or background information that can help the readers of the SRS;
c) a description of the problems to be solved by the software; and
d) special packaging instructions for the code and the media to meet security,
export, initial loading or
other requirements.
The SRS should explicitly state whether or not these information items are to be
considered part of the
requirements.
4 Verification
Provide the verification approaches and methods planned to qualify the software. The
information items
for verification are recommended to be given in a parallel manner with the information
items in 9.6.10 to
9.6.18.
Verification is to prove the correctness of software or specification - the system has
been built right.
Basically, you just need to provide the verification methods and associated criteria for
every verification
action. Review/inspection can be conducted for verification also. So you can describe it
as your
verification method by having these considerations:
— How – identify which verification method to be applied.
— Who – identify the organization or person with the lead responsibility for
performing the
verification, such as a contractor, subcontractor, vendor, product team or supplier.
— When – designate a time in the program plan when the verification is to be done.
This should be
an event-based, and not a calendar date, accomplishment.
— Where – specify any unique venue and environment needed for the verification
activity.
More info: You can look for SRS review in another standard (IEEE Std 1012-2016,
IEEE Standard for
System, Software and Hardware Verification and Validation).
4.1 Education Verification
This involves validating the educational credentials of alumni, such as degrees or diplomas.
The system can request copies of the relevant documents and verify their authenticity with
the issuing institutions.
4.2 Testing
The testing for this system can use the white-box testing method or black-box testing
method.The goal of white-box testing is to ensure that the software functions correctly
according to its code paths. Test cases are designed based on an understanding of the system's
internal components, algorithms, and data structures.Black-box testing is a testing approach
where the tester has no knowledge of the internal workings of the software. Testers focus on
the functionality of the system.
5 Appendices
5.1 Assumptions and dependencies
Write any assumptions and dependencies that may factor in the software requirements.
5.1.1 Assumptions
1. The system depends on the university's IT department for ongoing technical support
and maintenance.
2. Users will provide accurate and up-to-date contact information and preferences.
3. The alumni data provided by users will be stored securely and protected from
unauthorized access.
4. Users have basic computer skills and are familiar with web-based applications.
5. The system will be compatible with commonly used web browsers, such as Chrome,
Firefox, and Safari.
5.1.2 Dependencies
1. The MMU Alumni Management System relies on the availability and functionality of
the university's existing alumni database.
2. The system depends on the university's IT department for ongoing technical support
and maintenance.
3. The MMU Alumni Management System relies on an email delivery service for
sending notifications and updates to alumni.
4. The system depends on a reliable payment gateway for alumni event registrations or
donations.
5. The MMU Alumni Management System depends on the availability of adequate
server resources, such as CPU, memory, and storage.
5.2 Acronyms and abbreviations

SRS - Software Requirement Specification

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRS - Software Requirement Specification

Uploaded by

Copyright:

Available Formats

TSE2451

Tutorial Section: TT4L

Lim Jun Xiang (Leader) 1181200619

The purpose of MMU Alumni Management System (MMUAMS) focusing on

1. Promote communication between the MMU and alumni.

The MMU Alumni Management System (MMUAMS) is a system designed to

Purpose Improved Communication

Objective To provide a platform for post announcements, news, and event

Goal To foster strong and consistent communication channels, allowing

Purpose Enhanced Engagement

Objective To provide features such as mentorship programs, job boards, and

Goal To strengthen the alumni network, encourage alumni to contribute their

Objective To enable online donation mechanisms, making it convenient for

Goal To enhance the MMU's financial resources by encouraging alumni to

1.3 Product Overview

Clean and Modern Design:

System Administrator (Admin Panel) Interface:

Hardware Name Specification

Front-end Server AWS Amplify

Back-end Server AWS Lambda x86 Processor, 2GB RAM

Cloud-based Storage Amazon S3 1TB ROM

End-User Devices Desktop computers, laptops,

The system uses standard network protocols, HTTP/HTTPS, for communication

Site adaptation requirements

Interfaces with services

LiveChat a messaging service provider, to enable real-time communication

Ipay88 a payment gateway service, to facilitate secure online payments. It

Figure 1.0 Alumni Management System Use Case

1.3.3 User Characteristics

Educational Diploma to bachelor's degree.

Experience Experience in administrative tasks, data management, and

Technical Have knowledge of system configuration, and user management.

Characteristics Individuals who have graduated from MMU.

Educational Diploma/foundation to doctor's degree.

Experience Diverse professional experiences.

Technical Have varying levels of technical expertise, ranging from basic

Characteristics Individuals who are currently enrolled in MMU.

Educational Secondary school to undergraduate programs.

Experience Have limited professional experience due to their ongoing

Technical Possess varying levels of technical expertise. However, they are

Higher-Order Language Requirements

Safety and Security Considerations

Term/ Acronym/ Abbreviation Expansion/ Description

ROM Read-Only Memory. It is a type of

RAM Random Access Memory. It is a type

GB Gigabyte. It is a unit of digital storage

Front-end It refers to the part of a website or

Back-end It refers to the server-side of a

MMU Centra of Alumni

TAYLOR'S ALUMNI COMMUNITY

Use Case ID UC001 Version 1.0

Feature F001 Upload Event Proposal

Purpose To allow alumnus to submit event proposal

Scenario Name Step Action

2 The system prompts the alumnus to enter information about the

3 The alumnus enters the required information into the system.

4 The alumnus uploaded the event proposal attachment.

5 The alumnus clicks the “Submit” button to submit the form.

All required fields must be completed before a proposal can be submitted.

Author Jun Xiang

Use Case ID UC002 Version 1.0

Feature F002 Check Event Proposal Status