ANALYSING AND
MODELLING SYSTEM
REQUIREMENTS
Student Name:
Student Id
Introduction
This report presents a case study analysis and system requirements modelling for a case study
scenario to be undertaken in the ICT103 unit. The case study is based on an organisation that
is suffering operational losses because of a lack of a structured information system. Delays in
receiving accurate information, limited user integration, and manual processes have
underscored the importance of designing a well-built system to support business activities
and decision-making.
In this case study, as a Systems Analyst, I am expected to research theorganisation'ss existing
issues, understand stakeholders' needs, and translate requirements into concise, structured
system requirements. This entails analysing how the proposed system is to work, the
interaction between users and the system, and the flow of data within the system. The aim is
to ensure the proposed solution aligns with organisational objectives and enhances efficiency,
usability, and reliability.
This report discusses the stages of systems design and analysis. It starts with an explanation
of the System Development Life Cycle (SDLC) and the choice of an appropriate
development methodology for the proposed system. It then examines requirements-gathering
methods used to enumerate stakeholder expectations. According to this analysis, there are
functional and non-functional requirements. The system is also modelled using UML charts,
including use case, activity, sequence, and domain model class diagrams. Lastly, there is a
simple user interface design, backed by dialogue and a storyboard, that shows how the user
interacts with the system.ystem.
Methodologies and Selected Methodologies
The System Development Life Cycle (SDLC) is a process model used in the development of
information systems, from planning through deployment and support. It offers a methodical
approach to analysing user requirements, designing solutions, implementing systems, and
ensuring quality control. SDLC promotes minimising project risks, enhancing
communication among actors and systems, and ensuring they are sufficient to address the
organisation's requirements.
There are a few SDLC models that are regularly applicable to system development. The
waterfall model is linear and sequential, requiring each stage to be completed before
transitioning to the next. next. It is not flexible and therefore cannot be used in projects where
requirements are likely to change frequently. The spiral model is an iterative development
risk-analysis model that enables risks to be identified at an early stage; it is complex,
expensive, and more applicable to large, high-risk projects. Agile model, in turn, focuses on
iterative development, iterative feedback, and tight coordination with stakeholders, enabling
systems to mature with the requirements.
Regarding the specified case study, the Agile methodology is the most appropriate. The
organisation needs a system that is flexible to changes in user needs, and Agile facilitates this
by providing small iterations of the system that allow it to be developed in small steps, with
stakeholders providing feedback at every step. This minimises the risk of developing a
system that does not meet users' expectations.
The main benefits of Agile are flexibility, prompt supply of running aspects, better
stakeholder communication, and faster problem detection. Conversely, the strictness of the
Waterfall structure prevents any changes, whereas the Spiral model is complex and expensive
and is not suitable for the scale of this system. Hence, Agile offers the best trade-off between
efficiency, flexibility, and end-user satisfaction for the proposed system.
Requirements Gathering Techniques
An apt requirements-gathering process is an important step in system analysis because it
ensures that the proposed system meets stakeholders' needs and addresses current
organisational issues. In the case study provided, the various requirements-gathering methods
were utilised to provide detailed, trustworthy, and accurate system requirements. The most
important stakeholders in the interviews were the administrators and operational staff, who
provided deeper insight into the current workflows, challenges, and expectations for the new
system. This method provided an opportunity to clarify complex requirements and identify
pain points in current procedures. Feedback was gathered through questionnaires to the wider
user segment, including customers, which allowed the analyst to understand typical user
requirements, expectations of the systems regarding how they could be used, and the features
they most preferred.e It used observation to research the way the users are currently doing
their work in the organisation. Inefficiencies, manual errors, and gaps in the processes were
identified by observing real-time interactions with the existing processes.
1. How will different users interact with the system based on their roles?
2. What types of reports are required by management, and how frequently should they
be generated?
3. What level of security and access control is expected for system users?
4. What payment methods should the system support to ensure user convenience?
System Requirements
This section outlines the functional and non-functional requirements of the proposed system
based on the provided case study.
Functional Requirements
Functional requirements explain the essential characteristics and services that the
systFunctional requirements specify the essential characteristics and services that the system
must offer. The suggested system would provide user registration and user login so that
customers, staff, and administrators could use the system safely in their designated roles. The
system should assist with data management, including the creation, updating, and storage of
user records, service information, and transaction information in a central database.Search
functionality in the system should also be provided so users can easily find the information
they need, such as a customer record, services, or customer transaction history. Payment
processing is a vital function, and the system is expected to facilitate secure payment
transactions and automatically generate payment confirmations or receipts. Besides, the
system should facilitate the generation of reports, enabling administrators to produce
operational and financial reports to monitor performance and make decisions. Control by
administrators must enable authorized users to control system users, update system data, and
maintain overall system integrity.
Non-functional Requirements
The system should be very secure with authentication, authorization, and protection of the
sensitive data of the users. It needs to be easy to use, and the system must have a
straightforward, intuitive interfIt needs to be easy to use, and the system must have a
straightforward, intuitive interface that enables users to do their work with minimal training.
The system must also be dependable, with regular availability and proper data processing
without frequent breakdowns. Performance requirements involve quick response times to
user activity, such as searches and transactions, even during peak hours. Lastly, the system
needs to be scalable, that is, it should be able to support more users and more transactions as
the organization increases, without the need to significantly redesign it.ng of functional
involvement among the users.
Use Case Diagram & Use Case Description
A Use of Case Diagram
Use Case Name:
Make Payment
Scenario:
A customer pays for a booked service through the system
using an available payment method and receives a receipt
after successful payment.
Customer clicks “Pay Now / Make Payment” on the
booking summary page.
Triggering Event:
Brief Description:
Actors:
Stakeholders:
The system displays the payable amount and payment
options, accepts customer payment details, sends the
transaction for authorisation, updates payment status, and
generates a receipt.
 Primary Actor: Customer
 Supporting Actors: System, Payment Gateway
(external), Staff (optional assistance)





Preconditions:


Customer (wants fast, secure payment +
receipt)
Organisation/Business (wants confirmed
payments and accurate records)
Administrator (wants reporting and audit trail)
Staff (wants booking status updated correctly)
Payment Service Provider (processes
transaction securely)
Customer is registered and logged in
Customer has an existing booking with an
amount due
Postconditions:

System is online and payment service is
available



Payment is recorded and stored in the database
Booking status is updated to Paid/Confirmed
Receipt is generated and available to
view/download
Confirmation is shown to the customer

Flow of Activities:
Exception
Conditions:
Customer opens booking
System displays total amount
summary and selects Make and available payment
methods
Payment
Customer selects method and System validates the entered
enters payment details
details
Payment declined (insufficient funds / invalid details) →
system shows error + retry
Use case Diagram Description
A use case diagram depicts the functional involvement of users and the proposed service
management system. It is a high-level graphical description of the system's functionality that
clearly illustrates the system's boundaries, system actors, and use cases. The system has three
major players: Customer, Staff, and Administrator, and they interact with the system as per
their roles and responsibilities. The customer actor interacts with core service-related use
cases, including Register/Login, Search Services, Book Service, Make Payment, and View
Receipt. These applications are the most common customer experience: accessing the system
and completing a transaction. The Staff actor assists operational processes, such as service
booking, record searching, and service status. The Administrator actor involves administering
the system at a higher level, such as managing Users, creating reports, and managing general
bookings.The system boundary named the proposed service management system captures all
use cases, making the system's functionality quite clear by separating the system's
functionality from external actors. The connection between Make Payment and View Receipt
is described by the relationship type of an <<include>, which means that the receipt
generation process is an obligatory component of the payment process.re involved in the
payment of a service.
Use Case Description: Make Payment
The Make Payment use case explains the procedure for paying for a service booked by a
customer. The use case is triggered when the customer selects the payment option after
verification of the booking details. The customer is the main participant, and the system will
provide secure transaction processing.meThe conditions for this use case are a successful
login and an established, confirmed booking. The sequence of actions will include showing
payment details, choosing a payment method, verifying information, and, on success, creating
a credit receipt. The postcondition is that the booking status is changed and the payment
records are recorded. Exception instances include payment failures, cancellations, or system
failures, in which the user is notified and asked to try again.se and shows the order of tasks
and points of choice in the process of paying for a service in the suggested system. This
diagram starts with the start node, which denotes the beginning of the payment process by the
customer when they have affirmed a service booking.
Activity Diagram
This begins when the customer clicks the Make Payment button, which triggers the system to
display the payment information (service cost and payment options). The customer then adds
the required payment details. After processing the payment information, the system compares
it against a decision point labelled "Payment Valid?" where the information is evaluated. The
system automatically creates a payment receipt. After payments are successfully processed,
the system updates the bookings' status, and they are considered confirmed once the
transaction is complete. The end node, in turn, receives the workflow, and the payment
process is considered successful.
In case of payment validation failure, the system takes a different route, displaying an error
message and giving the customer the option to make a second payment attempt. This
decision-based branching ensures that any incorrect or incomplete payment details are
handled appropriately without halting the entire process. Outcomes flow through the payment
process and contribute to improving the system's behaviour comprehension and its
compliance with the functional requirements.
Sequence Diagram (Make Payment Use Case)
The sequence diagram shows the chronological relationships among the Customer, the
System, and the third-party payment Gateway in the Make Payment use case.
The Customer initiates the process and clicks the Make Payment option. The System
responds. The Customer initiates the process and clicks the Make Payment option. The
System responds by showing the total of available booking and payment options. The
customer would then provide payment details, such as the payment method and required
credentials. After receiving the details, the System forwards the authorisation request to the
Payment Gateway that contains the payment amount and the transaction token. The
authorisation request was approved or rejected. Once the response is received, the System
will update the payment status and save a transaction record in the database for traceability
and accurate reporting. If the payment is valid, a receipt and a confirmation message are
generated for the customer. Last but not least, the customer can view or download the receipt,
completing the interaction.
This sequence diagram affirms that the payment procedure is organised and consists of
external authentication using a payment service, and that system information is updated upon
receiving a successful authorisation reply. and system reliability.
Domain Model Class Diagram
The domain model class diagram shows the main backbone of the proposed service
managemenThe domain model class diagram shows the backbone of the proposed service
management system, including the identification of the main classes, their features, and their
connections. The key classes are Customer, Booking, Service, Payment, Receipt, and User
(Staff/Admin). These are the fundamental objects needed to run systems such as bookings,
payments, and administration. password hash. There is an opportunity of a customer making
several bookings, which is represented as a 1 to 0 to many association between the Customer
and Booking. Booking class includes a bookingID, booking date, booking status and total
amount, which occupy the booking information and might track the progress of the service
request. A Service is associated with each booking, containing serviceId, serviceName,
description and basePrice. This relationship ensures that a booking is linked to the service
being requested.
The payment model is represented by the Payment class that has paymentId, method,
payment amount, paidAt, and payment status. A booking can contain 0..1 payment (such as
an unpaid booking), whereas a successful payment will cause a single Receipt which contains
receiptId, receiptNo and issuedAt. Lastly, the User (Staff/Admin) class represents system
operators, and has such attributes as the userId, role, username, and passwordHash, and is
linked with the bookings so that it represents management and changes made by the staff or
administration.
User Interface ( Dialogue and Storyboards)
The user interface design shows how users access the proposed service management system
in a well-organised way. The interface is dedicated to simplicity, usability, and efficiency to
ensure that people can fulfil tasks with the minimum effort. To illustrate how users interact, a
dialogue-based interface and a storyboard representation of the Make Payment process are
provided.
Customer: I would like to pay.
System: The booking details and the amount are shown. Pay one of the following ways.
Customer: I have also filled in my payment details.
System: Processing payment. Please wait.
System: Payment successful. Receipt has been created.
Customer: Thank you. I will download the receipt.
This conversation is a common type of interaction between the customer and the system that
demonstrates how the system's responses guide the user through every step of the payment
process.
Storyboards
The storyboard visually captures the same intercourse in several screens. The booking
summary and payment option are shown on the first screen. The second screen gives the
customer the option to enter payment information. The third screen confirms that the payment
is being processed successfully, and the last screen shows the generated receipt with the
option to download and read it later. Such storyboards show the logical flow of screens and
ensure they conform to the functional requirements and system workflows.
Conclusion
The report provides a detailed analysis and design of the recommended system using the case
study. Agile approach was chosen as the most appropriate approach to develop the system
becauseThe agile approach was chosen as the most appropriate approach to develop the
system because of its flexibility, iterative nature, and the capacity to integrate ongoing
feedback of stakeholders, which guarantees the system will be flexible to accommodate
changes in these requirements.at the requirements of the stakeholders were captured
effectively and the functional and non-functional requirements were identified clearly.
To convert these requirements into a structured system design, several UML diagrams were
created: a use case diagram, an activity diagram, a sequence diagram, and a domain model
class diagram. These diagrams provided a clear depiction of system functionality, process
flow, time-based interactions, and the system's structure. Moreover, the user interface design
was presented through dialogue and storyboards to show how the user interacts with the
system in a simple, intuitive way.
References
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,
Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.C., Mellor,
S., Schwaber, K., Sutherland, J. and Thomas, D. (2001) Manifesto for Agile Software
Development. Available at: https://agilemanifesto.org (Accessed: 10 January 2026).
Dennis, A., Wixom, B.H. and Roth, R.M. (2021) Systems Analysis and Design. 8th edn.
Hoboken, NJ: John Wiley & Sons.
Kendall, K.E. and Kendall, J.E. (2019) Systems Analysis and Design. 10th edn. Boston:
Pearson Education.
Larman, C. (2004) Applying UML and Patterns: An Introduction to Object-Oriented Analysis
and Design and Iterative Development. 3rd edn. Upper Saddle River, NJ: Prentice Hall.
Pressman, R.S. and Maxim, B.R. (2020) Software Engineering: A Practitioner’s Approach.
9th edn. New York: McGraw-Hill Education.
Sommerville, I. (2016) Software Engineering. 10th edn. Harlow: Pearson Education.
Wiegers, K.E. and Beatty, J. (2013) Software Requirements. 3rd edn. Redmond, WA:
Microsoft Press.