SOLUTION

SOFTWARE ENGINEERING REQUIREMENT AND

SPECIFICATION ANALYSIS FOR RUBIS PETROL STATION
Date:20th march 2023
Author: Mushirara Chrispus 2021BIT004

2A PURPOSE FOR STUDY

To analyze the requirements and specifications for the software engineering project at Rubis
petrol station.

2B DOCUMENT CONVENTION

here's an example illustration of document conventions for a software engineering

requirement and specification analysis study conducted at Rubis petrol station:
 For consistency throughout the document, all section headings and subheadings will be in bold
and use a 14-point Arial font.
 All diagrams or models used in the study, such as the Entity-Relationship (ER) model for product
features, will be labeled and referenced in the text.
 All references to sources or external materials will use the Harvard referencing style, and will
include a complete citation in the reference list at the end of the document.
 To make the document easy to read, paragraphs will be single-spaced with a 12-point Times
New Roman font and 1-inch margins on all sides.
 Any technical terms or abbreviations used in the document will be defined the first time they
are used in the text, to ensure that readers understand their meaning.
By establishing these document conventions at the beginning of the study, you can ensure
that the document is consistent, easy to read, and effectively conveys the information and
analysis you conducted during your research at Rubis petrol station.

2C Project Scope:
The software engineering requirement and specification analysis study aims to analyze the
requirements and specifications of a new software system for Rubis petrol station. The
scope of this study includes understanding the current business processes at Rubis petrol
station and identifying areas where a software system could improve operational efficiency
and customer experience. The study will focus on the following key areas:
 Identifying the functional and non-functional requirements for the software system, based on
the needs of the business and its customers.
 Analyzing the current database systems used at Rubis petrol station and determining if a
distributed database system could be more effective.
 Understanding the characteristics and needs of the different user classes, including employees,
managers, and customers, to ensure that the software system meets their needs.
 Evaluating the operating environment of Rubis petrol station, including hardware, software, and
network infrastructure, to ensure that the software system can be integrated effectively.
 Identifying any design constraints that may impact the development and implementation of the
software system.
The project scope is limited to the analysis phase of the software engineering process. The
study will not include the design or development of the software system, but will provide
the necessary requirements and specifications for future development efforts. The analysis
will be based on information gathered through interviews with key stakeholders and
analysis of existing business processes and systems at Rubis petrol station.

3
A
The software engineering project at Rubis petrol station aims to develop a new software
system to improve operational efficiency and customer experience.
The new software system will be developed as a standalone system, with no existing
software systems or interfaces to integrate with. However, the system will need to interface
with existing hardware systems at the petrol station, such as point-of-sale (POS) systems
and fuel dispensers.

CURRENTYLY SYSTEM

Currently, Rubis petrol station relies on manual processes and paper-based systems to
manage fuel sales, inventory, and customer records. These processes are time-consuming
and error-prone, leading to inefficiencies in operations and customer dissatisfaction. The
new software system aims to automate these processes and provide real-time data on fuel
sales and inventory levels.

Also current system at Rubis petrol station includes a credit card reader that enables
customers to make cashless payments for their fuel purchases. The credit card reader is a
hardware device that is connected to the point-of-sale (POS) system, which allows it to
securely process transactions and transmit payment information to the payment processor.
When a customer approaches the pump, they can either use the credit card reader at the
pump or inside the station to initiate the payment process. The credit card reader prompts
the customer to insert or swipe their card and enter their personal identification number
(PIN), if required. Once the card is authenticated and the transaction is authorized, the
payment is processed and the customer is able to begin fueling their vehicle.
The new software system will consist of multiple modules, including a fuel sales module,
inventory management module, and customer management module. These modules will be
integrated into a single system to provide a comprehensive view of fuel sales and inventory
levels at the petrol station. The system will be designed to be scalable, allowing for future
expansion and integration with other systems if needed.
Overall, the product perspective for the software engineering project at Rubis petrol station
involves developing a new, standalone software system to replace existing manual
processes and improve operational efficiency and customer experience. The system will
interface with existing hardware systems at the petrol station and consist of multiple
modules designed to provide a comprehensive view of fuel sales and inventory levels.
 B

Product Features:
The software system being developed for Rubis petrol station will include the following main
product features, as represented in the ER model below:
 Fuel Sales: This module will allow employees to record fuel sales transactions and generate
receipts for customers. It will include information such as the type and quantity of fuel sold, the
date and time of the transaction, and the employee who completed the transaction. This
module will also interface with the POS system to process payments.
 Inventory Management: This module will allow managers to monitor inventory levels of fuel and
other items sold at the petrol station. It will include information such as the type and quantity of
fuel in stock, the reorder point for each type of fuel, and the date of the last inventory check.
This module will also generate alerts when inventory levels reach the reorder point, and provide
recommendations for reordering.
 Customer Management: This module will allow employees to create and manage customer
records, including information such as the customer's name, contact details, and fuel
preferences. It will also track customer loyalty points, which can be redeemed for discounts on
fuel purchases. This module will interface with the POS system to apply loyalty points to fuel
purchases.
The ER model below illustrates the relationships between the different modules of the
software system:

FUEL SALES

INVENTORY

CUSTOMER
Overall, the main product features of the software system being developed for Rubis petrol
station include fuel sales, inventory management, and customer management. These
modules will be integrated into a single system to provide a comprehensive view of fuel
sales and inventory levels, and improve operational efficiency and customer experience.

3 C.

User Classes and Characteristics:

The software system being developed for Rubis petrol station will be used by the following
types of users, each with their own set of characteristics:

Cashiers: Cashiers will use the system to record fuel sales transactions and process
payments from customers. They will be required to have basic computer skills and
knowledge of the petrol station's products and services. They will also need to be able to
operate the fuel dispensers and handle cash and credit card payments.
Managers: Managers will use the system to monitor inventory levels, generate reports, and
manage customer records. They will be required to have advanced computer skills and
knowledge of the petrol station's operations and business processes. They will also need to
be able to analyze data and make informed decisions based on the information provided by
the system.
Customers: Customers will interact with the system indirectly, through the fuel sales and
loyalty points programs. They will be required to have basic computer skills and knowledge
of the petrol station's loyalty program. They will also need to be able to provide their
personal information to create a customer record and redeem loyalty points.
Overall, the users of the software system being developed for Rubis petrol station will have
varying levels of computer skills and knowledge of the petrol station's operations and
business processes. The system will need to be designed with these characteristics in mind,
to ensure that it is easy to use and meets the needs of all users.

3D.

Operating Environment:

The software system being developed for Rubis petrol station will operate in the following
hardware and software environments:

Hardware:
Desktop Computers: Cashiers and managers will use desktop computers to access the
software system. These computers will be equipped with standard hardware components,
such as a keyboard, mouse, monitor, and printer.
Fuel Dispensers: The fuel dispensers will be equipped with hardware components that allow
them to communicate with the software system, such as a pump controller and a
communication module.
Software:

Operating System: The software system will be compatible with the Windows operating
system, version 10 or higher.
Database Management System: The software system will use a database management
system (DBMS) to store and manage data. The DBMS will be compatible with the Windows
operating system and will be selected based on its ability to handle the data volumes and
performance requirements of the system.
Programming Language: The software system will be developed using a programming
language that is compatible with the Windows operating system, such as C# or Java.
Integrated Development Environment: The software system will be developed using an
integrated development environment (IDE) that is compatible with the Windows operating
system, such as Visual Studio or Eclipse.

Overall, the software system being developed for Rubis petrol station will operate in a
standard hardware and software environment that is compatible with the Windows
operating system. The system will be designed to be scalable and adaptable, to
accommodate future growth and changes in technology.

3E.

Design Constraints:

The software system being developed for Rubis petrol station will be designed with the
following constraints in mind:

Compatibility: The system must be compatible with the petrol station's existing hardware
and software infrastructure, including fuel dispensers and point-of-sale (POS) systems. This
will require careful planning and testing to ensure that the system can communicate with
these existing systems and share data as needed.
Security: The system must be designed with strong security features to protect customer
data and prevent unauthorized access. This will require the implementation of secure
authentication and authorization mechanisms, as well as encryption of sensitive data both in
transit and at rest.
Scalability: The system must be designed to accommodate future growth and changes in
technology. This will require the use of scalable and modular design patterns, as well as the
implementation of flexible data structures and algorithms that can adapt to changing needs.
Performance: The system must be designed to operate efficiently and provide fast response
times, even under heavy loads. This will require careful tuning of system parameters and the
use of performance-enhancing technologies, such as caching and load balancing.
Overall, the software system being developed for Rubis petrol station will be designed with
a number of constraints in mind, including compatibility with existing systems, strong
security features, scalability, and high performance. The system will need to be carefully
designed and tested to ensure that it meets these constraints while also providing the
functionality and usability required by the petrol station and its customers

4
A

PRODUCT FEATURES
functional requirements that the software system being developed for Rubis petrol station
might have:

Fuel Dispensing: The system must be able to communicate with fuel dispensers to authorize
fuel purchases and track fuel inventory levels.

Point of Sale: The system must be able to process transactions at the point of sale, including
accepting cash and credit card payments, issuing receipts, and calculating discounts and
taxes.

Inventory Management: The system must be able to track inventory levels of fuel, as well as
other products sold at the petrol station such as snacks and beverages, and generate alerts
when inventory levels fall below a certain threshold.

Loyalty Programs: The system must be able to support loyalty programs, including tracking
customer points and providing rewards for frequent customers.

Reporting: The system must be able to generate reports on sales, inventory levels, and other
business metrics to help managers make informed decisions.

Refunds: The system must be able to process refunds for customer returns and exchanges,
including issuing refunds to credit cards or providing cash back.

Security: The system must be able to ensure the security of customer data, including credit
card numbers and personal information, through encryption and other security measures.
Customer Service: The system must be able to support customer service activities, such as
tracking customer complaints and resolving issues with transactions.

Maintenance: The system must be able to track and manage maintenance activities for fuel
dispensers and other equipment at the petrol station, including scheduling routine
maintenance and identifying equipment that needs repairs.

Integration: The system must be able to integrate with other systems used by the petrol
station, such as accounting software or inventory management systems, to ensure smooth
operation and avoid data duplication.

4B

non-functional requirements that the software system being developed for Rubis petrol
station might have:

Performance: The system must be able to handle a large volume of transactions during peak
periods, such as holidays or weekends, without experiencing significant slowdowns or
crashes.

Reliability: The system must be able to operate reliably and consistently over long periods of
time, with minimal downtime or disruptions.

Security: The system must be able to protect customer data and transactions from
unauthorized access or hacking attempts, using industry-standard security measures such as
encryption, firewalls, and access controls.

Usability: The system must be easy to use and intuitive for cashiers and other users, with
clear interfaces and minimal training required.

Accessibility: The system must be accessible to users with disabilities, such as visual or
hearing impairments, using features such as screen readers or voice commands.

Scalability: The system must be able to accommodate growth in the number of petrol
stations and users over time, without requiring significant changes or upgrades.

Interoperability: The system must be able to integrate with other systems and platforms
used by the petrol station, such as accounting or inventory management software, to ensure
smooth operation and avoid data duplication.

Maintainability: The system must be easy to maintain and update over time, with clear
documentation and well-organized code that can be easily modified or extended.
Performance Efficiency: The system must be able to process transactions quickly and
efficiently, with minimal delays or wait times for customers.

Data Integrity: The system must ensure the accuracy and consistency of data used in
transactions, with clear error-checking and validation mechanisms to prevent errors or
fraud.

5
A QUALITY

quality requirements related to availability for the Rubis petrol station system:

The system must be available for use by cashiers and customers during normal business
hours, which are from 6:00 am to 10:00 pm, seven days a week.

Any scheduled maintenance or upgrades to the system must be performed during off-hours,
such as early morning or late at night, to minimize disruption to users.

The system must be designed with redundancy and failover capabilities, so that if one
component fails, there is another component that can take over without any noticeable
downtime.

The system must have a backup and recovery plan in place, to ensure that data can be
restored quickly in the event of a disaster or outage.

The system must have a help desk or support team available to respond to user inquiries or
problems, with clear escalation procedures for critical issues.

The system must be monitored for performance and availability, with alerts and
notifications sent to the support team if any issues arise.

The system must have an uptime guarantee of at least 99%, with penalties or compensation
if this level of availability is not met.

The system must be designed with scalability in mind, so that additional resources can be
added or removed as needed to ensure optimal performance and availability.

The system must have a disaster recovery plan in place, with off-site backups and redundant
hardware to ensure that data can be restored in the event of a catastrophic failure.
The system must have clear procedures in place for managing downtime or interruptions,
with communication to users and stakeholders about the status and expected duration of
any outages.

software quality requirements related to correctness for the Rubis petrol station system:

All code changes must be reviewed by at least one other team member, to ensure that there
are no obvious errors or mistakes in the implementation.

The system must have automated testing in place, to validate the correct behavior of each
component and to catch regression errors.

The system must have a well-defined set of functional requirements, with clear acceptance
criteria, to ensure that each feature is implemented correctly.

The system must be tested in a variety of scenarios, to ensure that it works correctly under a
range of conditions, such as heavy load or unexpected inputs.

The system must have appropriate error handling in place, to catch and report any
unexpected or invalid inputs, and to ensure that the system does not crash or corrupt data.

The system must be compliant with relevant industry standards, such as PCI-DSS for
payment processing or GDPR for data privacy, to ensure correctness and compliance with
legal requirements.

The system must have appropriate logging and auditing in place, to track user actions and
system behavior, and to identify any issues or anomalies that may indicate incorrect
behavior.

The system must have a well-defined process for identifying and resolving bugs or issues,
with clear procedures for reporting, prioritizing, and fixing issues as they arise.

software quality requirements related to maintainability for the Rubis petrol station system:

The system must be designed with modularity and code reusability in mind, to make it
easier to maintain and extend over time.
The system must have clear documentation and code comments, to make it easier for new
team members to understand and modify the code.

The system must be built with a modern and maintainable technology stack, with support
for modern tools and frameworks.

The system must have a clear versioning and release process, to make it easier to track
changes and roll back if necessary.

The system must have an automated build and deployment process, to make it easier to
deploy new changes and updates.

The system must have a clear process for bug tracking and resolution, with a dedicated team
responsible for maintaining and updating the system.

The system must have a plan for disaster recovery and business continuity, in case of
unexpected downtime or data loss.

The system must have appropriate security measures in place, to prevent unauthorized
access and protect sensitive data, and to make it easier to maintain and update the security
infrastructure over time.

5 D.

software quality requirements related to usability for the Rubis petrol station system:

The user interface must be intuitive and easy to navigate, with clear labels and instructions
for each function.

The system must be designed with the user's workflow in mind, minimizing the number of
steps and clicks required to perform common tasks.

The system must provide feedback to the user in real-time, indicating the status of ongoing
operations and highlighting any errors or issues.

The system must be accessible to users with disabilities, conforming to appropriate

accessibility standards and guidelines.

The system must have clear and concise documentation and training materials, to help users
learn how to use the system effectively.
The system must have a consistent look and feel across all functions and interfaces, to avoid
confusion and reduce cognitive load.

The system must be designed with performance in mind, to minimize delays and waiting
times for users.

The system must be customizable, allowing users to configure settings and preferences to
suit their needs and preferences.

Here is an example reference list using the Harvard style for the Rubis petrol station
software engineering project:

Pressman, R. S. (2014). Software engineering: a practitioner's approach. McGraw-Hill

Education.

Sommerville, I. (2016). Software engineering. Pearson Education Limited.

Bass, L., Clements, P., & Kazman, R. (2015). Software architecture in practice. Addison-
Wesley Professional.

IEEE. (1998). IEEE Recommended Practice for Software Requirements Specifications (IEEE
Std 830-1998). Institute of Electrical and Electronics Engineers.

ISO/IEC/IEEE. (2011). Systems and software engineering -- Life cycle processes --

Requirements engineering (ISO/IEC/IEEE 29148:2011). International Organization for
Standardization.

W3C. (2018). Web Content Accessibility Guidelines (WCAG) 2.1. World Wide Web
Consortium.

Nielsen, J., & Molich, R. (1990). Heuristic evaluation of user interfaces. Proceedings of the
SIGCHI conference on Human factors in computing systems, 249-256.

ISO. (2019). ISO/IEC 25010:2011. Systems and software engineering -- Systems and software
Quality Requirements and Evaluation (SQuaRE) -- System and software quality models.
International Organization for Standardization.
 NO 7

Examples of documents that could be included in the Appendix section are:

UML
Entity Relationship Diagrams (ERDs) showing the relationships between different entities in
the system.
Technical specifications of the hardware and software requirements for the system.
Flowcharts showing the process flows for different features of the system.
Use case diagrams illustrating how different actors interact with the system.
Screen designs and mockups showing the user interface of the system.
Test plans and results showing how the system was tested for functional and non-functional
requirements.
Code snippets demonstrating key functionality or algorithms used in the system.
Any legal or regulatory documents that the system must comply with, such as data privacy
laws or industry standards.
 SOLUTION THE REQUIRED
To complete a software engineering requirement and specification analysis study for a
project at Rubis petrol station, you would need to gather information about the project and
its requirements. Here's a possible outline for each section of the study:
1. Standard Face Page (provided below)
Include the standard face page template for your study. This should include the title of the
study, the name of the organization (in this case, Rubis petrol station), the date of the study,
and the names of the author(s).
2. Introduction
A. Purpose: Explain the purpose of the study, which is to analyze the requirements and
specifications for the software engineering project at Rubis petrol station.
B. Document convention: Describe any conventions used in the document, such as the ER
model for product features.
C. Project scope: Define the scope of the project, including the objectives, deliverables, and
constraints.
3. Overall Description
A. Product Perspective: Describe the context of the software engineering project, including
any existing systems and interfaces.
B. Product Features: Use an ER model to describe the main features of the software product,
such as managing inventory or processing payments.
C. User Classes and Characteristics: Identify the types of users who will interact with the
system, such as cashiers or managers, and describe their characteristics.
D. Operating Environment: Describe the hardware and software environments in which the
system will be used.
E. Design Constraints: Identify any constraints on the design of the system, such as
compatibility with existing systems or security requirements.
4. Product Features
A. Functional Requirements: Use the ER model to describe the specific functional
requirements of the system, such as the ability to generate reports or process refunds.
B. Non-Functional Requirements: Describe the non-functional requirements of the system,
such as performance, reliability, and security.
5. Software Quality
A. Availability: Describe how the system will be available to users, including any downtime
for maintenance or upgrades.
B. Correctness: Explain how the system will be validated to ensure correctness, such as
through testing or peer review.
C. Maintainability: Describe how the system will be maintained, including any plans for
updates or bug fixes.
D. Usability: Describe how the system will be designed to be easy to use and intuitive for
users.
6. Reference
Include a reference list using the Harvard style.
7. Appendix
Include any additional information or documentation that supports the study, such as
diagrams or technical specifications.