CT Group of Institutions, Maqsudan

Experiment Title:Study and usage of OpenProject or similar software to

draft a project plan.
Laboratory: Software Engineering Lab (BTCS 506-18)

Experiment No: 1 Department: B.TECH CSE Semester: 5TH

Aim:- Study and usage of OpenProject or similar software to draft a project

plan.
Procedure: OpenProject is an open-source project management software that offers a wide
range of features for planning, tracking, and managing projects. Here, I'll outline how to use
OpenProject (or a similar project management tool) to draft a project plan.

Create a Project:- To create a new project on openproject follow these steps-

Step 1:- Log in to your OpenProject account and create a new project.

Step 2:- After creating a new project Give it a name, and description, and set the project's start
and end dates.

Step 3:- After giving the name and description, choose the demo project on the next screen.

Roll No:- Page |

 Here you can create your own project.

Overviews:- On the overview screen you find all the descriptions and overview of the project
here you can check all about your project, you can add members, and view project progress
reports all data are presented there.

Work Packages:- On the work packages window there are several menus available that
provide a user-friendly environment, Here you can easily check your project status, and the
admin has the authority to set the priority of a task and set the time limit for that task.

Roll No:- Page |

 In the work packages menu, you can easily check the latest activity, recent activity, overdue
projects, and the Gantt chart that gives a clear overview of your projects. In simple words,
we can say that all activity related to work is shown here.

Team planners:- You can quickly plan and manage your team's workload visually in the
team planer window. You may use it to keep track of your project's progress, schedule new
tasks, reschedule or reassign existing tasks, and see what each member of your team is working
on.

BOARDS :- The "Board" window in Open Project is a visual project management tool that
provides an overview of tasks, user stories, or issues within a project. It displays these items
in customizable columns, allowing teams to track progress, prioritize work, and manage

Roll No:- Page |

workflows efficiently. This board view enhances project transparency and collaboration.

Basic Board Function: A basic board helps visualize and track tasks, organize priorities, and
facilitate teamwork by displaying items in columns based on their status or category.

Kanban Board Function:- A Kanban board visualizes work stages, limits work in progress,
and promotes continuous flow, making it ideal for optimizing workflows and maintaining
efficiency.

News :- In news section team leader can share all important announcement, update and other
information with team. Team leader has also authority to create news item for individual
project.

Roll No:- Page |

Member:- The "Members" section in OpenProject allows administrators to manage user access
and roles within a project. It enables the addition and removal of team members, assignment of
roles (such as project manager or viewer), and control over permissions, ensuring effective
collaboration and data security in project management.

Project settings:- In "Project Settings" section in OpenProject provides project administrators

with tools to configure and customize project-specific parameters. Users can set project
details, define workflows, adjust permissions, and configure various project-specific settings
to tailor the project management environment to their specific needs, ensuring efficient and
effective project execution.

Roll No:- Page |

 CT Group of Institutions, Maqsudan

Experiment Title: SRS (Software requirement analysis) for Rental

Property manager.
Laboratory: Software Engineering Lab (BTCS 506-18)

Experiment No: 2 Department: B.TECH CSE Semester: 5TH

Aim: SRS (Software requirement analysis) for Rental Property manager.

Table of Contents:

Table of Contents…..........................................................................................................ii
Revision History...............................................................................................................iii
1. Introduction............................................................................................................1
1.1 Purpose.................................................................................................................................1
1.2 Document Conventions…....................................................................................................1
1.3 Intended Audience and Reading Suggestions......................................................................1
1.4 Product Scope.......................................................................................................................2
1.5 References….........................................................................................................................2
2. Overall Description….................................................................................................2

Roll No:- Page |

2.1 Product Perspective..............................................................................................................2
2.2 Product Functions….............................................................................................................3
2.3 User Classes and Characteristics…......................................................................................3
2.4 Operating Environment…....................................................................................................3
2.5 Design and Implementation Constraints…..........................................................................4
2.6 User Documentation….........................................................................................................4
Assumptions and Dependencies… 5

3. External Interface Requirements…..........................................................................6

3.1 User Interfaces….................................................................................................................6
3.2 Hardware Interfaces.............................................................................................................6
3.3 Software Interfaces..............................................................................................................6
3.4 Communication Interfaces…...............................................................................................6
4. System Features….................................................................................................7
4.1 Authentication and Authorization…....................................................................................7
4.2 Add Property Feature...........................................................................................................8
4.3 Add Photographs Feature.....................................................................................................8
4.4 Add location Feature............................................................................................................9
4.5 Search Properties Feature.....................................................................................................9
4.6 Shortlisting Properties Feature............................................................................................10
Delete Properties Feature............................................................................................................ 10

4.7 Deleting Shortlisted Properties Feature.............................................................. 11

5.Other Nonfunctional Requirements...............................................................................2
5.1 Performance Requirements….............................................................................................12
5.2Safety Requirements............................................................................................................12
5.3Security Requirements….....................................................................................................12
Software Quality Attributes…..................................................................................................13
6. Other Requirements………………………………………………………………….14
Appendix A: Glossary...............................................................................................................15
Appendix B: Analysis Models…..............................................................................................16
Appendix C: To Be Determined List

Roll No:- Page |

1. Introduction

1.1 Purpose
The purpose of a Property Rental Manager is to oversee and streamline the management of rental
properties. They handle tenant acquisition, lease management, rent collection, maintenance, and tenant
relations. Their goal is to ensure properties are well-maintained, tenants are satisfied, and rental income
is maximized. Both the human role and software application aim to simplify property management,
enhance efficiency, and optimize financial outcomes for property owners and landlords.

1.2 Document Conventions

Document conventions in Property Rental Management entail standardized formatting, terminology, and
organizational practices for documents related to lease agreements, maintenance records, rent collection,
and tenant communication. These conventions enhance clarity, reduce errors, and improve collaboration
among property managers, staff, and stakeholders. Consistent naming conventions, file structures, and
record-keeping procedures streamline property management tasks, making it easier to efficiently
manage and maintain rental properties while ensuring effective communication and documentation.

1.3 Intended Audience and Reading Suggestions

The intended audience is the team of developers who will be designing and implementing the Property
Management System. Also, the document is to be utilized by the testing team who will be testing and
evaluating the performance and design of the application. The document consists of all the necessary
information that will be required by the team of software engineers who will be working on the project.
1.4 Product Scope
The Rental Property Management System aims to simplify the process of renting and leasing properties

Roll No:- Page |

for its Owner. The application will provide all necessary functionalities for searching properties, adding
properties and their images. There will also be functionalities for posting Remarks for tenants of
properties rent or regarding anything who are in search for roommates. In future, we plan to add
additional functionalities and features in the application which include to providing this application to
user. We also plan to add an online rental agreement feature which will reduce the efforts taken for an
agreement between the tenant and owner.

1.5 References

 Python Documentation:
 GUI Framework:
 MY SQL Database:

2. Overall Description

2.1 Product Perspective

The Rental Property Management System is intended to provide an alternative to the common way of
Managing Tenant Information and renting properties which involves Paper records. This way proves to
be expensive for Property Owner. The features of the application will allow the Admin and users to
conveniently search for properties Rooms as well as Tenant for properties. This eliminates the need of
having to avail the services of a property agent or broker, thus saving money for both the parties. Also,
the contact is directly between the buyer and the seller and so clarifications and agreements can be done
directly without the involvement of a third party.
2.2 Product Functions
 By using the Rental Property Management System, the need of a third party in the process
of taking rent of room is eliminated.
 Users can search properties in different areas and locations without having to travel to the
location.
 Direct communication between the owner and tenant of the property. Clarifications can be
done easily.
 Saves time for both the parties.

 Multiple available properties and buyers to choose from.

2.3 User Classes and Characteristics

The users of the application can be classified into two types. The ones who want to give a

Roll No:- Page |

property on lease (property owners) and the ones who want to rent a property (tenants). There is
no strict distinction between the two types of users. Both the users can access all the
functionality of the application.

2.4 Operating Environment (OE)

Since the application is a GUi application it can work on only owner pc.

 Device: Computer, Laptops, Tablets.

 Operating System: Windows, Linux distributions, Mac OS, Android

 RAM: 128 MB or more

 Disk Space: 20 MB or more.

 Browsers: Mozilla Firefox 30+, Google Chrome 27.0+, Microsoft Edge. Other browsers
can also be used.
 Internet connection: For now no need of internet when it convert in web then we need internet

2.5 Design and Implementation Constraints

CO-1:

The time allotted for this project is at most 6weak

CO-2:

The front end of the application will be made using Python Tkinter.

CO-3:

Python will be used as the language for the backend of the application and MYSQL will be
used for the database of the application.

CO-4:

The website will be in English language. Users who do not know English will face difficulties
in using the Application.

2.6 User Documentation

Appropriate instructions will be provided at every step in the application to ensure the users or
new admin do not face any difficulties while using the application. In future, we plan to add a

Roll No:- Page |

chatbot to guide users in case they face any difficulties. Instructions will be given while filling
out forms, adding photos and locations. Proper error messages will be displayed in case the user
inadvertently fills wrong information or makes any mistake while using the application.

2.7 Assumptions and Dependencies

AS-1:

The application supports only English language. We assume the users of the application will be
well versed with English.

AS-2:

The users of the application should have basic knowledge of uploading images and location.

DE-1:

The application will require Pycharm or another platform with GUI framwork as a dependency,
since we use Python as the backend language.

3. External Interface Requirements

3.1 User Interfaces

UI-1:

There will be a navigation bar at the top of the web page which will help users to navigate to
different web pages.
UI-2:

There will be alerts and pop ups which appear in case the user makes a mistake while using the
application.

UI-5:

The interface will be responsive for all screen sizes as much as possible to provide the users a
seamless experience.

3.2 Hardware Interfaces

N/A

Roll No:- Page |

3.3 Software Interfaces
 Browsers: Mozilla Firefox 30+, Google Chrome 27.0+ are the preferred browsers.

 Operating System: Android, Windows 7, 8, 10, Mac OS, Linux distributions.

3.4 Communication Interfaces

The application will be using HTTPS protocol.

4. System Features

4.1 Authentication and Authorization

4.1.1 Description and Priority:

The application will be having multiple users and so authentication becomes a high priority
system feature. The application will be using Python module in order to implement this
functionality. When the user creates a new account on the application, they will have to provide
their username and password. The passwords in the system will be hashed and stored so that no
other person can get to know the password.
4.1.2 Response Sequences:
Once the user registers in the application, they will be guided to a login page where they will
have to enter their user name and password to login. After successful login, the user will be
redirected to the landing page of the application. There will also be a logout button on the
navigation bar. On clicking the logout button, the user will be logged out.
4.1.3 Functional Requirements:
REQ-1: We use module for authentication and authorization functionality. The authentication
will be session- based authentication.

4.2 Add Property Feature

4.2.1 Description and Priority:
Feature to add properties on the Application will be provided to the user (owner in this case).
The owner will have to provide all specification about the property which he intends to put on
lease. The feature is of high priority as the application is based on owners adding properties on
the website to get more potential buyers.

4.3 Add Photographs Feature:

Roll No:- Page |

4.3.1 Description and priority:
The user gets to add photographs of the property which he intends to put on lease. This is again
a high priority feature. The user gets the option to choose images using file system or simply
drag and drop the pictures into the provided area.
4.3.2 Response Sequences:
The user can add images using the drag and drop functionality or simply choose images from
the files that he wants to upload. In case any image exceeds the maximum file size the user will
be notified using alerts. On adding the images, the user is redirected to the add location page.
4.3.3 Functional Requirements:
REQ-1: For the drag and drop functionality we use Dropzone JavaScript library.

4.4 Add location Feature

4.4.1 Description and Priority:
The user gets to add the location of the property by using the map. The user will simply have to
add a marker by clicking on the location where the property is located. The priority of the
feature is moderate.
4.4.2 Response Sequences:
On adding the location, the property is successfully added to the database and the user is
redirected to the landing page of the website.
4.4.3 Functional Requirements:
REQ-1: Mapbox APIs will be used for geolocation functionality.

4.5 Search Properties Feature:

4.5.1 Description and Priority:
The user can search different properties using the search functionality. This feature is of high
priority and is primarily for tenants. The user can search based on his requirements such as
desired location, area, number of bedrooms etc.
4.5.2 Response Sequence:
On filling the required information based on desired features, the results will be displayed on
the webpage.
4.5.3 Functional Requirements:

Roll No:- Page |

REQ-1: Mapbox APIs will be required for displaying locations of the properties on the map.

4.6 Shortlisting Properties Feature

4.6.1 Description and Priority:
This feature will allow users to shortlist or save properties that they are interested in, for future
reference. This is a moderate priority feature.
4.6.2 Response Sequence:
Once the user clicks on the shortlist button the property will be added to the list of properties
that have been shortlisted by that particular user.
4.6.3 Functional Requirements:
REQ-1: For shortlisting properties, AJAX calls will be used. Therefore, JQuery will be used on
the client side.

4.7 Delete Properties Feature

4.7.1 Description and Priority:
This feature will allow the owner of the property to remove the property from the system. This
is a moderate priority feature.
4.7.2 Response Sequence:
Once the user clicks on the delete property button, a popup will appear asking the user if he is
sure if he wants to delete the property. If the user response if Yes, then the property will be
removed from the system.

4.7.3 Functional Requirements:

REQ-1: For deleting properties, AJAX calls will be used. Therefore, JQuery will be used on the
client side.

4.8 Deleting Shortlisted Properties Feature

4.8.1 Description and Priority:
This feature will allow users to remove properties shortlisted by them. This feature is of
moderate priority.
4.8.2 Response Sequence:

Roll No:- Page |

Once the user clicks on the remove button the property will be removed from the list of
properties that have been shortlisted by that particular user.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

5.1.1 Scalability:
The application should be scalable and should perform without
any interruption for all the users.

5.2 Safety Requirements

 Backup power
supply should be present for server, so that it does not stop functioning in case of power failure.

 API keys of the APIs used should not be made open source.

 Code backup should be taken at regular time intervals.

5.3 Security Requirements

 The passwords of the users are hashed and then stored in the database so that no person can
access the passwords of the users.

 The passwords should be at least 8 characters long and must have at least one uppercase
character, one digit and at least one special symbol.

 The Application should HTTPS protocol for security.

 POST requests are used for transferring information regarding authentication, adding
properties, adding advertisements etc. through forms.

5.4 Software Quality Attributes

5.4.1 Usability:
The user interface should be simple to use and not cluttered with a lot of information.
5.4.2 Availability:
 The system should be available at all times.

Roll No:- Page |

 The system should be reliable and there should be no loss of data in case the server breaks
down when operations are going on.
5.4.3 Maintainability:
The code for the application should be written cleanly and should be well documented. The
code should contain comments to help new programmers and developers make changes in the
application.
5.4.4 Testability:
The code should be written with proper test cases to be tested upon so that no errors during
production take place.

5.5 Business Rules

The administrator of the application has full permission of controlling the

system.

6. Other Requirements

Appendix A: Glossary

 HTTPS: Hypertext Transfer Protocol Secure

 API: Application Programming Interface

 GUI: Graphical User Interface

Appendix B: Analysis Models

ER Diagram of the Application

Roll No:- Page |

Use Case Diagram for the application

Roll No:- Page |

 CT Group of Institutions, Maqsudan

Experiment Title: Preparation of Software Requirement Specification

Document, Design Documents and Testing Phase
Laboratory: Software Engineering Lab (BTCS 506-18)

Experiment No: 3 Department: B.TECH CSE Semester: 5TH

Aim: SRS (Software requirement analysis) for Compliance Software.

1. Introduction
Introduction Consider the following scenario A mid-size Consulting company with 80
employees working in the Knowledge management services and handling 20 clients. As the
delivery date of some of the projects comes closer imagine the number of meeting that these
employees have to handle at a time with an average of 7 participants in each meeting? Imagine
yourself being the meetings coordinator for couple of projects? Compliance software is one of
the most common yet critical tasks in the modern workplace. In earlier days, the time-
consuming tasks of scheduling meetings, typing up agendas, and taking minutes was the
domain of the office secretary. With the advent of computer technologies scheduling meeting
no matter has become a task that every employee get there hands in from time to time.
Scheduling a meeting in Compliance software really is not as simple as it looks, even with
scheduling software. A lot of judgment is involved, and there's a real sense of propriety
required. In bringing any group of people together, there are so many factors to take into
account. This domain is a complex one due to factors such as uncertainty, numerous
stakeholders, and potential disturbances. Complexity would increase as more participants were
added, or different components were automated. Decisions about where the meeting is held are
important as well, and very political. For some meetings, a simple announcement will do. For
others, participants will need to be polled for their availability and then confirmed later. With
the growing popularity of scheduling systems, Synergy Soft, Inc. aims to provide such a

Roll No:- Page |

product, which would outperform any such system that is currently available in the highly
competitive market. Synergy Soft, Inc. is proposing an innovative approach to a new product
called compliance software in which this product is intended for supporting people to schedule
their meetings. Many software vendors are eager to offer such a system, especially one with a
powerful vantage point (e.g. Microsoft, IBM-Lotus, etc.). Synergy Soft, Inc. is also aware that
getting the right requirements the first time will be the barometer to successfully completing the
entire development effort, reducing production time, and to keeping up its well-established
reputation and ultimately to satisfying their workforce and customers. In essence, Synergy Soft,
Inc. is looking to our company’s expertise to deliver a detailed requirements description, which
precisely, concisely and conceptually as possible to capture real customer’s real needs or want

1.1.Purpose
Purpose The purpose of this Compliance software Requirements Elicitation document is to
provide a clear understanding as to what actually he is the system and to identify the critical
requirements essential for the project’s successful completion. This document provides an
abstract overview of the compliance software system and provides a general overview of the
entire project. However, the architectural and detail design is outside the scope of this
document, but will be covered in the Software Requirements Specification document. This
document will be used to organize our team’s project plan and deliverables. This document
explains our team architecture, our team’s initial understanding of the user needs. It will assist
our team in understanding the system specifications and analyze the critical aspects of our
project. It will allow the project management and development group to grasp the high level
details delivered to the end user. This document will briefly discuss the stakeholders involved in
the development, documents will show how our team was divided to handle the multiple
stakeholders, the sources of the requirements, provide an informal preliminary requirements
description, and address any issues encountered while transforming the requirements.

1.2.Scope
This document is intended for providing an abstract overview of Compliance software system and
general overview of the entire project.
The scope of the document:
• The Enterprise Functional and Non-Functional requirements,
• Stake Holders,
• Team Architecture,
• System Functional and Non-Functional Requirements
This document is also intended to provide a proto-type of the Compliance software system. However,
the Software Architectural Design and Detailed Design of Compliance software system are beyond the
scope of this initial Requirements Elicitation Document and will be described in Software Architectural
Design and Detail Design Document in II and III phases of this project.

Requirements Description

Roll No:- Page |

Enterprise Functional Requirements
Description To determine a meeting date and location.

Meeting Initiation
 The meeting initiator issues a meeting request by inviting all potential meeting attendees for a
meeting based on the meeting’s agenda. An initiator can be one of the participants or some
representative, such as a secretary.
• The initiator fills in the fields like the date range, meeting type, and all potential meeting
attendants. The initiator also designates attendees’ importance levels.
• The initiator notifies the potential attendants to input their data. Active participants should fill
in the equipment they need. If an attendee is designated as an important participant, he is
required to fill in his preferred locations. The exclusive sets and preference sets should be
contained in the date range.
• After all participants input their data; the initiator asks the system to make a meeting schedule
based on the given information. The proposed meeting date should belong to the stated date
range and to none of the exclusion sets and to as many preference sets as possible.

Meeting Conflict Resolution

• If a conflict occurs while generating a meeting, the system shall notify the initiator and ask to
o Notify a participant to remove a date from his exclusive set,
o Propose a participant with low importance level to withdraw from the meeting,
o Propose a participant to extend his preference set.
o Propose the initiator to cancel the meeting.
If none of the proposed locations can meet the equipment requirements while making a
meeting schedule, the system should inform the initiator. The initiator can propose other
locations and start the scheduling process again or cancel the meeting and inform all of the
participants about that.

Roll No:- Page |

Enterprise Non-Functional Objectives
• All conflicts shall be resolved within minimum round of interactions.
• All conflicts should be solved as early as possible.
• Meeting location should be flexible.
• Meeting room shall belong to one of the locations preferred by as many important participants
as possible.

System Functional Requirements:

Functional Requirement Modified

Roll No:- Page |

System non functional requirements description:
• Easiness:--The system should be usable by the non-experts. The user should be able to
operate on the functionality easily.
• PERFORMANCE :: -- The elapsed time between the user sending request for meeting and the
date and location set should be minimal i.e. the user should not wonder whether he has
submitted the request or not. Lower bound should be fixed between determination of meeting
date and actual meeting
EXTENSIBILITY: -- The system should be able to handle explicit priorities among dates in
preference sets. It should handle explicit dependencies between meeting date and meeting
location. The system should provide provision to participant for his replacement by other
person at the meeting.
• PRIVACY: -- Privacy rules should be enforced a non-privileged participant should not be
aware of constraints stated by other participants. The system should accommodate as much
decentralized requests as possible. Therefore, any authorized user should be able to request a

Roll No:- Page |

meeting independently of his/her whereabouts
CUSTOMIZABLE::-- The system shall be customizable to two ways
(1) Private
(2) Professional meetings
–these are characterized by different restrictions on the time period that may be allocated (e.g.
meeting during office hours, private activities during leisure time).
• FLEXIBLE: -- Rescheduling of a meeting should be done dynamically and with as much
flexibility as possible. Also, the system should be flexible enough to accommodate evolving
data (e.g. the sets of concerned participants may be varying; the address at which a participant
can be reached may be varying, etc.).
• ACCURACY:--the meetings should be monitored accurately especially when
the meeting is carried out in a distributed manner

1. Test Objectives:

 The primary objective of testing is to ensure that software functions as intended, meeting
the specified functional and non-functional requirements.
 Testing aims to identify and rectify defects, vulnerabilities, and performance bottlenecks to
enhance the software's quality.

2. Test Scenarios:

 Comprehensive test scenarios are developed to cover various use cases and user
interactions with the software.
 These scenarios encompass both typical and edge cases to evaluate how the system
performs under different conditions.

3. xPerformance Testing:
 Performance testing is conducted to assess the software's responsiveness, scalability, and
stability under different workloads.
 Load testing, stress testing, and scalability testing are performed to ascertain that the
software can handle anticipated user loads and data volumes.

4. Security Testing:

 Rigorous security testing is essential to identify vulnerabilities and potential threats to

government data and services.
 Penetration testing, vulnerability scanning, and code reviews are part of the security
assessment process.

5. Regression Testing:

 Regression testing is carried out to ensure that new code changes or updates do not
introduce defects into existing functionality.
 Automated regression tests are executed to verify the software's stability after
modifications.

Roll No:- Page |

6. Accessibility Testing:

 Accessibility testing evaluates the software's compliance with accessibility standards,

ensuring it can be used by individuals with disabilities.
 Screen readers, keyboard navigation, and other assistive technologies are tested.

7. Compatibility Testing:

 Compatibility testing ensures that the software functions correctly on various browsers,
devices, and operating systems.
 Cross-browser and cross-platform testing are conducted to guarantee a seamless user
experience.

8. Usability Testing:

 Usability testing assesses the software's user interface for user-friendliness, efficiency, and
clarity.
 Feedback from users is collected to enhance the overall user experience.

9. Testing Documentation:

 Comprehensive test plans, test cases, and test scripts are documented to ensure consistency
and repeatability in testing.
Test documentation also serves as a reference for future testing and auditing.

10. Test Reporting:

 Detailed test reports are generated to document test results, including defects, performance
metrics, and compliance with requirements.
 Test reports serve as a basis for making informed decisions about software readiness.
6. SYSTEM CONSTRAINTS:

6.1 Hardware dependency:

 Server Specifications
 Client Devices
 Peripheral Devices

6.2 Software dependency:

 Operating System: This includes Windows, macOS, iOS, Android, etc.

 Database Management System: The DBMS used to store this software data are MySQL,
PostgreSQL, MongoDB, or another database system.

 Back-end Technologies: The programming languages Java, Python, PHP and

frameworks Django, Spring Boot are used in the back-end development.

 Front-end Technologies: The front-end technologies HTML, CSS, JavaScript and

frameworks React, Angular are used to build the user interface.

7. APPENDIX:

Roll No:- Page |

 SRS: Software Requirements Specification
 UI: User Interface
 API: Application Programming Interface
 UX: User Experience

Roll No:- Page |