Software Architectures (CS_701) Lab Work

Software Architectures (CS_701)

List of Experiments

Exp 1. Software Architectures lab purpose, and various software process models.

Exp 2. Study of object oriented approach & Event Driven approach.

Exp 3. Case Study of Online Examination System SRS document.

Exp 4. Construction of Software Requirement Specification document for Hotel Management System.

Description of UML diagrams :

a. Use Case diagram
Exp 5. b. Activity diagram
c. Sequence diagram
d. Class diagram

Exp 6. Case Study of Online Examination System SDS document.

Exp 7. Construction of Software Design Specification document for Hotel Management System.

Exp 8. Construction of Software Implementation Specification document for Hotel Management System.

Exp 9. Study of various software testing techniques and tools.

Case study of Online Examination System Software Testing document.

Exp 10. Construction of Software Testing Specification document for Hotel Management System.

Department of CSE Page 1

 Software Architectures (CS_701) Lab Work

EXP 1. Software Architectures lab purpose, and various software process models?

EXP 1 Solution:

Software Architectures lab purpose:

Lab works will consist of a mainstream project aimed at the design and implementation of an actual software system, using
the techniques, tools and notations introduced in the course. This will be carried out through successive mini projects, each
corresponding to specific steps in the course. The initial lab sessions will consist of analyzing the requirements of the
corresponding system. Then during subsequent sessions, we will build step by step the system, by focusing mainly on the
aspects concerned with software architecting. At the end of the course each student should come up with the implementation
of a specific component.

Waterfall Model:
The waterfall model is a sequential, plan driven-process where you must plan and schedule all your activities before
starting the project. Each activity in the waterfall model is represented as a separate phase arranged in linear order.
It has the following phases:
 Requirements
 Design
 Implementation
 Testing
 Deployment
 Maintenance
Each of these phases produces one or more documents that need to be approved before the next phase begins. However, in
practice, these phases are very likely to overlap and may feed information to one another.
The waterfall model is easy to understand and follow. It doesn’t require a lot of customer involvement after the
specification is done. Since it’s inflexible, it can’t adapt to changes. There is no way to see or try the software until the last
phase.
The waterfall model has a rigid structure, so it should be used in cases where the requirements are understood completely
and unlikely to radically change.

Department of CSE Page 2

 Software Architectures (CS_701) Lab Work

V Model:
The V model (Verification and Validation model) is an extension of the waterfall model. All the requirements are
gathered at the start and cannot be changed. You have a corresponding testing activity for each stage. For every phase in
the development cycle, there is an associated testing phase.
The corresponding testing phase of the development phase is planned in parallel, as you can see above.
The V model is highly disciplined, easy to understand, and makes project management easier. But it isn’t good for
complex projects or projects that have unclear or changing requirements. This makes the V model a good choice for
software where downtimes and failures are unacceptable.

Incremental Model:
The incremental model divides the system’s functionality into small increments that are delivered one after the other in
quick succession. The subsequent increments expand on the previous ones until everything has been updated and
implemented.
Incremental development is based on developing an initial implementation, exposing it to user feedback, and evolving it
through new versions. Each iteration passes through the requirements, design, coding, and testing stages.
The incremental model lets stakeholders and developers see results with the first increment. It is efficient as the
developers only focus on what is important and bugs are fixed as they arise, but you need a clear and complete
definition of the whole system before you start.
The incremental model is great for projects that have loosely-coupled parts and projects with complete and clear
requirements.

Department of CSE Page 3

 Software Architectures (CS_701) Lab Work

Iterative Model:
The iterative development model develops a system through building small portions of all the features. This helps to
meet initial scope quickly and release it for feedback.
In the iterative model, you start off by implementing a small set of the software requirements. These are then enhanced
iteratively in the evolving versions until the system is completed. This process model starts with part of the software,
which is then implemented and reviewed to identify further requirements.
The deadline and budget may change throughout the development process, especially for large complex projects. The
iterative model is a good choice for large software that can be easily broken down into modules.

RAD Model:
The Rapid Application Development (RAD model) is based on iterative development and prototyping with little planning
involved. You develop functional modules in parallel for faster product delivery. It involves the following phases:
1. Business modeling
2. Data modeling
3. Process modeling
4. Application generation
5. Testing and turnover

Department of CSE Page 4

 Software Architectures (CS_701) Lab Work

The RAD concept focuses on gathering requirements using focus groups and workshops, reusing software components,
and informal communication.
The RAD model accommodates changing requirements, reduces development time, and increases the reusability of
components. But it can be complex to manage. Therefore, the RAD model is great for systems that need to be produced in
a short time and have known requirements.

Spiral Model:
The spiral model is a risk driven iterative software process model. The spiral model delivers projects in loops. Unlike
other process models, its steps aren’t activities but phases for addressing whatever problem has the greatest risk of
causing a failure.
It was designed to include the best features from the waterfall and introduces risk-assessment.
You have the following phases for each cycle:
1. Address the highest-risk problem and determine the objective and alternate solutions
2. Evaluate the alternatives and identify the risks involved and possible solutions
3. Develop a solution and verify if it’s acceptable
4. Plan for the next cycle
You develop the concept in the first few cycles, and then it evolves into an implementation. Though this model is
great for managing uncertainty, it can be difficult to have stable documentation. The spiral model can be used for
projects with unclear needs or projects still in research and development.

Department of CSE Page 5

 Software Architectures (CS_701) Lab Work

Agile model:
The agile process model encourages continuous iterations of development and testing. Each incremental part is
developed over an iteration, and each iteration is designed to be small and manageable so it can be completed within a few
weeks.
Each iteration focuses on implementing a small set of features completely. It involves customers in the development
process and minimizes documentation by using informal communication.
Agile development considers the following:
 Requirements are assumed to change
 The system evolves over a series of short iterations
 Customers are involved during each iteration
 Documentation is done only when needed

Department of CSE Page 6

 Software Architectures (CS_701) Lab Work

EXP 2. Study of object oriented approach & Event Driven approach?

EXP 2 Solution:

Object Oriented Approach:

The object-oriented approach is a popular way to build software because it helps developers create reusable code. Object-
oriented programming (OOP) is a style of coding that focuses on creating objects that can be used in many different ways.
This means that developers can write code once and then reuse it in different parts of the program. OOP can make code
development faster and easier to understand.

However, the object-oriented approach also has some drawbacks. One is that it can be more difficult to read and
understand code written in this style. This is because OOP code can be very complex, with lots of interconnected objects.
This can make it hard to debug and maintain code written in this way.

Event Driven Approach:

The event-driven approach is another popular way to develop software. This approach is based on the principle of
responding to events. In event-driven programming, code is written to respond to specific events that occur while the
program is running. For example, an event might be a user clicking on a button or a new piece of data being added to a
database.

Event-driven programming can be used to create code that is more responsive to user input. This can make programs more
user-friendly. Event-driven code can also be easier to read and understand than code written in other styles.

However, the event-driven approach has some drawbacks. One is that it can be more difficult to predict how code will
behave. This is because the code is written to respond to events that may or may not happen. This can make event-driven
code more difficult to debug and maintain.

Department of CSE Page 7

 Software Architectures (CS_701) Lab Work

EXP 3. Case Study of Online Examination System SRS document

EXP 3 Solution:

1. Introduction:
The Online Examination System is a web-based application that enables instructors to administer exams online. The
system can be used to create exams, administer exams, and grade exams. The system can also be used to create and
manage question libraries.
2. User Classes and Characteristics:
There are three user classes of the Online Examination System: instructors, students, and administrators. Instructors use
the system to create and administer exams. They can also create and manage question libraries. Students use the system to
take exams. Administrators use the system to manage user accounts and system configuration settings.
3. Functional Requirements:
3.1. Exam Creation Instructors can use the system to create exams. Exams can be created from scratch or by using a
question library. When creating an exam from scratch, instructors can specify the exam name, description, total points,
passing score, and time limit. They can also specify whether the exam is proctored.
3.2. Exam Administration Instructors can use the system to administer exams. When administering an exam,
instructors can specify the date, time, and duration of the exam. They can also specify the location of the exam and the
proctoring method.
3.3. Exam Grading Instructors can use the system to grade exams. The system provides a variety of grading options,
including auto-grading, manual grading, and group grading.
3.4. Question Library Management Instructors can use the system to create and manage question libraries. Question
libraries can be used to create exams.
4. System Requirements:
4.1. Software Requirements The Online Examination System requires a web browser with JavaScript enabled. The
system has been tested with the following browsers:
Google Chrome, Mozilla Firefox, Microsoft Edge
4.2. Hardware Requirements The Online Examination System requires a computer with an internet connection.
5. Implementation Requirements:
5.1. Hosting The Online Examination System is a web-based application and requires a web server for hosting. The
system has been tested with the following web servers:
Apache HTTP Server
Microsoft IIS
5.2. Database The Online Examination System requires a database for storing data. The system has been tested with the
following databases:
 MySQL
 Microsoft SQL Server
 Oracle Database
5.3. Third-Party Libraries The Online Examination System requires the following third-party libraries:
 jQuery
 Bootstrap

Department of CSE Page 8

 Software Architectures (CS_701) Lab Work

6. Conclusion:
The Online Examination System is a web-based application that enables instructors to administer exams online. The
system can be used to create exams, administer exams, and grade exams. The system can also be used to create and
manage question libraries.

Department of CSE Page 9

 Software Architectures (CS_701) Lab Work

EXP 4. Construction of Software Requirement Specification document for Hotel Management System.

EXP 4 Solution:

Software Requirements Specification

1. Introduction:

1.1 Purpose
This document is the Software Requirements Specification (SRS) for the Hotel Management System (HMS). The purpose
of this document is to define the requirements of the HMS and to provide a detailed description of the functionality of the
system. The document also serves as a contract between the customer and the developer regarding the system to be
developed.

1.2 Document Conventions

The following document conventions are used in this document:
• Requirements are numbered using the format <Section Number>.<Requirement Number>. For example, 1.1 is the first
requirement in Section 1.
• References to other requirements are denoted using the format <Section Number>.<Requirement Number>. For
example, 1.1 refers to the first requirement in Section 1.
• Notes are denoted using the format <Section Number>.<Note Number>. For example, 1.1 is the first note in Section 1.
• Figures and tables are denoted using the format <Section Number>.<Figure/Table Number>. For example, Figure 1.1 is
the first figure in Section 1.

1.3 Definitions, Acronyms, and Abbreviations

The following definitions, acronyms, and abbreviations are used in this document:
• HMS: Hotel Management System
• GUI: Graphical User Interface
• SQL: Structured Query Language

1.4 References
The following documents are referenced in this document:
• [1] Example Reference

1.5 Overview
This section provides an overview of the entire document.
1.5.1 Product Perspective
The HMS is a system that will be used by hotel staff to manage hotel operations. The system will store information
about guests, rooms, reservations, and staff. The system will also provide a way for hotel staff to communicate with
each other.
1.5.2 Product Functions
The HMS will have the following functions:
• Allow hotel staff to manage hotel operations

Department of CSE Page 10

 Software Architectures (CS_701) Lab Work

• Store information about guests, rooms, reservations, and staff

• Provide a way for hotel staff to communicate with each other
1.5.3 User Classes and Characteristics
There are two types of users of the HMS: hotel staff and guests. Hotel staff will use the system to manage hotel
operations. Guests will use the system to make reservations and to view information about their stay.
1.5.4 Operating Environment
The HMS will be a web-based application that will be accessed via a web browser. The system will be hosted on a web
server.
1.5.4 Design and Implementation Constraints
The HMS must be developed using the PHP programming language and the MySQL database system.
1.5.5 User Documentation
The HMS will have a user manual that will be available online. The user manual will contain instructions on how to
use the system.
1.5.6 Assumptions and Dependencies
The HMS will assume that the hotel has a web server and a web browser. The system will also assume that the hotel
has a MySQL database.

1.6 System Features

The HMS will have the following features:
• Guest Management
• Room Management
• Reservation Management
• Staff Management
• Communication

2. Overall Descriptions:
2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 User Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communications Interfaces
2.1.6 Memory Constraints
2.2 Product Functions
2.2.1 User Registration
2.2.2 User Login
2.2.3 Guest Management
2.2.4 Room Management
2.2.5 Reservation Management
2.2.6 Staff Management
2.2.7 Communication

Department of CSE Page 11

 Software Architectures (CS_701) Lab Work

2.3 User Characteristics

2.3.1 User Profiles
2.3.2 User Environment
2.4 General Constraints
2.4.1 Security
2.4.2 Safety
2.4.3 Privacy
2.4.4 Legal
2.4.5 Cultural
2.4.6 Internationalization
2.4.7 Localization
2.5 Assumptions And Dependencies
2.5.1 Assumptions
2.5.2 Dependencies

3. Specific Requirements:
3.1 Functional Requirements
3.1.1 User Registration
3.1.2 User Login
3.1.3 Guest Management
3.1.4 Room Management
3.1.5 Reservation Management
3.1.6 Staff Management
3.1.7 Communication
3.2 Non-Functional Requirements
3.2.1 Performance
3.2.2 Security
3.2.3 Usability
3.2.4 Reliability
3.2.5 Availability
3.2.6 Maintainability
3.2.7 Portability

Department of CSE Page 12

 Software Architectures (CS_701) Lab Work

EXP 5. Description of UML diagrams :

a. Use Case diagram
b. Activity diagram
c. Sequence diagram
d. Class diagram

EXP 5 Solution:

Use Case Diagram:

A use case diagram is a type of behavioral diagram defined by and created from a Use-Case Specification. It shows the
actors of a system and their goal-oriented interactions with the system. The purpose of a use case diagram is to capture the
dynamic aspect of a system.
They are often used to:
 Help develop the system requirements
 Serve as the basis for logical design
 Help create physical design
 Help create test cases
A use case diagram consists of two elements: actors and use cases. Actors represent the people or entities that interact
with the system. Use cases represent the functionality of the system. Each use case represents a single goal that the actor
may want to achieve. For example, an actor may want to search for a product, add a product to their shopping cart, or
checkout.

Activity Diagram:

An activity diagram is a type of behavioral diagram in the Unified Modeling Language (UML) that shows the overall flow
of control for a system. It is useful for modeling the high-level behavior of a system, and can be used to understand the
overall behavior of a system, as well as to identify potential bottlenecks and issues.

Activity diagrams consist of four main elements: -

Activity nodes: These represent actions or work steps.
Control flows: These show the sequence of activities.
Swim lanes: These divide the diagram into horizontal or vertical sections to show different processes or actors.
Objects: These represent data or information that is passed between activities.

Activity diagrams can be used to model a wide variety of system behaviors, including simple workflows, complex
processes, and even entire business systems. They are a powerful tool for understanding and improving the efficiency of a
system.

Department of CSE Page 13

 Software Architectures (CS_701) Lab Work

Sequence diagram:

A sequence diagram is a type of behavioral diagram in the Unified Modeling Language (UML) that shows how objects
interact in a process over time. They are used to represent the dynamic behavior of a system.
Sequence diagrams are typically used to model the behavior of a system as a whole, or of a significant part of a system.
They can be used to represent the behavior of a system over time, or the behavior of a single object within a system.

Sequence diagrams can be used to model the behavior of a system at different levels of abstraction. For example, a
sequence diagram can be used to model the behavior of a system at the level of individual objects, or at the level of the
system as a whole.

Sequence diagrams are a valuable tool for communication between developers and stakeholders. They can be used to
capture the requirements of a system, and to communicate the design of a system to stakeholders.

Class Diagram:

A class diagram is an illustration of the relationships and interactions between classes and objects in a system. It is a static
diagram that shows the structure of a system. The class diagram is the most important of the UML diagrams, as it is the
foundation for all the other diagrams. The class diagram shows the classes in a system, their attributes, operations, and the
relationships between them.

The relationships between classes can be one of four types: association, aggregation, composition, or inheritance.
Association is a simple relationship between two classes, aggregation is a relationship between a class and its parts,
composition is a relationship between a class and its parts that also implies ownership, and inheritance is a relationship
between a class and its subclasses.

Class diagrams can be used to generate code in some object-oriented programming languages. In addition, the diagram
can be used to visualize the relationships between classes in a system and to help design the system.

Department of CSE Page 14

 Software Architectures (CS_701) Lab Work

EXP 6. Case Study of Online Examination System SDS document.

EXP 6 Solution:

1. Product and Company Identification:

Product Name: Online Examination System
Manufacturer: Not Applicable
Address: Not Applicable
Phone Number: Not Applicable

2. Hazard Identification:
This product is not considered hazardous according to the criteria of the U.S. Environmental Protection Agency (EPA).

3. Composition/Information on Ingredients:
This product is a software application and does not contain any hazardous ingredients.

4. First Aid Measures

If swallowed, do not induce vomiting. Get medical attention immediately.

5. Fire Fighting Measures:

Extinguishing Media: Water, carbon dioxide, dry chemical, foam

Special Fire Fighting Procedures: None required
Unusual Fire and Explosion Hazards: None known

6. Accidental Release Measures Spill Procedures:

No special procedures required

7. Handling and Storage Handling Procedures:

None required Storage Requirements: Store in a cool, dry place

8. Exposure Controls/Personal Protection Exposure Guidelines:

None required Personal Protective Equipment: None required

9. Physical and Chemical Properties Appearance:

Software application Odor: None
pH: Not applicable
Melting Point: Not applicable
Boiling Point: Not applicable
Flash Point: Not applicable
Evaporation Rate: Not applicable
Flammability: Not applicable
Explosion Hazard: Not applicable
Vapor Pressure: Not applicable
Vapor Density: Not applicable
Solubility: Not applicable

Department of CSE Page 15

 Software Architectures (CS_701) Lab Work

Specific Gravity: Not applicable

10. Stability and Reactivity Stability:

Stable Conditions to Avoid: None known
Incompatibilities: None known
Hazardous Decomposition Products: None known
Hazardous Polymerization: Will not occur

11. Toxicological Information

Toxicity Data: None known

12. Ecological Information

None required

13. Disposal Considerations

Disposal Methods: This product is not considered hazardous waste. Dispose of in accordance with local, state and federal
regulations.

14. Transport Information

None required

15. Regulatory Information

U.S. Federal Regulations: None known

State Regulations: None known

16. Other Information

HMIS Rating: Health: 0
Flammability: 0
Reactivity: 0
Special: N/A

The information provided in this Safety Data Sheet is correct to the best of our knowledge, information and belief at the
date of its publication. The information given is designed only as a guidance for safe handling, use, processing, storage,
transportation, disposal and release and is not to be considered a warranty or quality specification. The information relate
only to the specific material designated and may not be valid for such material used in combination with any other
materials or in any process. Such information is, to the best of our knowledge and belief, accurate and reliable as of the
date indicated.

Department of CSE Page 16

 Software Architectures (CS_701) Lab Work

EXP 7. Construction of Software Design Specification document for Hotel Management System.

EXP 7 Solution:

The Software Design Specification (SDS) is a document that describes the structure, behavior, and interfaces of a software
system. The SDS provides a blueprint for the development and maintenance of software. It is used to communicate the
software requirements to stakeholders, and to guide the development team in creating the software.

The SDS for Hotel Management System should include the following information:
1. Introduction
2. Purpose
3. Scope
4. Definitions, acronyms, and abbreviations
5. References
6. Overview
7. System architecture
8. Detailed design
9. Implementation
10. Testing
11. Maintenance
12. Appendices

Department of CSE Page 17

 Software Architectures (CS_701) Lab Work

EXP 8. Construction of Software Implementation Specification document for Hotel Management System.

EXP 8 Solution:

Introduction:
The purpose of this document is to provide a detailed description of the software to be implemented for the Hotel
Management System. The document covers the functional and non-functional requirements of the system along with a
detailed description of the software architecture, design and testing approach.

1. Functional Requirements:
The following are the functional requirements of the system:

1.1. Login:
The system shall provide a login interface for the users. The users shall be able to login using their username and
password.

1.2. Registration:
The system shall provide a registration interface for the users. The users shall be able to register by providing their
personal details like name, email id, contact number, etc.

1.3. Room Booking:

The system shall provide a room booking interface for the users. The users shall be able to book a room by providing
their check-in and check-out dates, room type, etc.

1.4. Billing:
The system shall provide a billing interface for the users. The users shall be able to generate their bill by providing
their room number, check-in and check-out dates, etc.

1.5. Cancellation:
The system shall provide a cancellation interface for the users. The users shall be able to cancel their room booking by
providing their room number, check-in and check-out dates, etc.

1.6. Reports:
The system shall provide various reports like room occupancy report, revenue report, etc.

2. Non-Functional Requirements:

2.1. Performance
The system shall be able to handle concurrent requests from multiple users.
2.2. Security

Department of CSE Page 18

 Software Architectures (CS_701) Lab Work

The system shall be secure from unauthorized access.

2.3. Scalability
The system shall be scalable to accommodate future growth.
2.4. Availability
The system shall be available 24x7.

3. Software Architecture:

3.1. Three-tier Architecture

The system shall be implemented using a three-tier architecture.

The three tiers are as follows:
Presentation Layer: This layer shall be responsible for the user interface of the system.
Business Layer: This layer shall be responsible for the business logic of the system.
Database Layer: This layer shall be responsible for storing the data of the system.

3.2. Client-Server Architecture

The system shall be implemented using a client-server architecture. The client shall be responsible for the user
interface and the server shall be responsible for the business logic and database.

4. Design:
4.1. Use Case Diagram
4.2. Activity Diagram
4.3. Class Diagram

5. Testing:
5.1. Unit Testing: Unit testing shall be performed to test the individual modules of the system.
5.2. Integration Testing: Integration testing shall be performed to test the integrated modules of the system.
5.3. System Testing: System testing shall be performed to test the system as a whole.

Department of CSE Page 19

 Software Architectures (CS_701) Lab Work

EXP 9 Study of various software testing techniques and tools. Case study of Online Examination System Software
Testing document.

EXP 9 Solution:

Various Software Testing Techniques And Tools

There are various software testing techniques and tools available, each with its own advantages and disadvantages. Some
of the most popular software testing techniques and tools include:

1. Unit Testing: Unit testing is a software testing technique in which individual units or components of a software
program are tested to verify that they are functioning as expected. Unit tests are typically written by the developers who
wrote the code being tested.

2. Integration Testing: Integration testing is a software testing technique in which individual units or components of a
software program are combined and tested as a group. Integration tests are typically written by the developers who wrote
the code being tested.

3. Functional Testing: Functional testing is a software testing technique in which a software program is tested to verify
that it meets the requirements specified for its functionality. Functional tests are typically written by the developers who
wrote the code being tested.

4. System Testing: System testing is a software testing technique in which a software program is tested as a whole system
to verify that it meets the requirements specified for its functionality. System tests are typically written by independent
testers who are not familiar with the code being tested.

5. Acceptance Testing: Acceptance testing is a software testing technique in which a software program is tested to verify
that it meets the requirements specified for its functionality. Acceptance tests are typically written by independent testers
who are not familiar with the code being tested.

6. Regression Testing: Regression testing is a software testing technique in which a software program is tested to verify
that changes made to it have not introduced new bugs. Regression tests are typically written by independent testers who
are not familiar with the code being tested.

7. Usability Testing: Usability testing is a software testing technique in which a software program is tested to verify that it
is easy to use. Usability tests are typically written by independent testers who are not familiar with the code being tested.

8. Security Testing: Security testing is a software testing technique in which a software program is tested to verify that it
is secure. Security tests are typically written by independent testers who are not familiar with the code being tested.

Department of CSE Page 20

 Software Architectures (CS_701) Lab Work

Case study of Online Examination System Software Testing document:

1. Introduction
The Online Examination System is a web-based application that enables instructors to create and administer exams online.
The application was developed using the PHP programming language and the MySQL database management system. The
application is designed to provide a secure, efficient, and user-friendly way for instructors to administer exams to their
students.

2. Purpose
The purpose of this document is to provide a comprehensive overview of the Online Examination System and to detail the
testing that was conducted on the application.

3. Background
The Online Examination System was developed by a team of developers at the University of XYZ. The application was
developed using the PHP programming language and the MySQL database management system. The application is
designed to provide a secure, efficient, and user-friendly way for instructors to administer exams to their students.

4. Testing Methodology
A variety of testing methods were used in order to thoroughly test the Online Examination System. These methods
included unit testing, integration testing, system testing, and user acceptance testing.

5. Test Results
The Online Examination System was found to be stable and effective. A variety of test cases were successfully executed,
and no major bugs or defects were discovered.

6. Conclusion
Overall, the Online Examination System is a well-designed and effective application. The application was found to be
stable and effective, and no major bugs or defects were discovered. The application provides a secure, efficient, and user-
friendly way for instructors to administer exams to their students.

Department of CSE Page 21

 Software Architectures (CS_701) Lab Work

EXP 10. Construction of Software Testing Specification document for Hotel Management System.

EXP 10 Solution:

1. Introduction
The purpose of this document is to specify the testing requirements for the Hotel Management System (HMS). This
document contains a description of the test environment, test scenarios, and test cases.

2. Test Environment
The testing environment for the HMS is a Windows-based system.

The system should have the following hardware and software requirements:
-Intel Pentium 4 2.0 GHz or higher processor
-2 GB of RAM or higher
-10 GB of free hard disk space or higher
-A compatible sound card
-A compatible graphics card
-A CD-ROM or DVD-ROM drive
-A keyboard and mouse

The following software should be installed on the testing environment:

-Windows 7 or higher
-Microsoft Office 2010 or higher
-Adobe Acrobat Reader
-Java Runtime Environment (JRE)
-MySQL Server

3. Test Scenarios
The following are test scenarios that should be covered during testing:
-Functionality testing: All functionalities of the HMS should be tested.
-Performance testing: The system should be tested for performance under various conditions, such as high load.
-Security testing: The system should be tested for vulnerabilities and security risks.
-Compatibility testing: The system should be tested for compatibility with various hardware and software configurations.
-Usability testing: The system should be tested for usability.

4. Test Cases
The following are sample test cases that should be included in the testing of the HMS:
-Test case 1: Functionality testing
-Test case 2: Performance testing
-Test case 3: Security testing

Department of CSE Page 22

 Software Architectures (CS_701) Lab Work

-Test case 4: Compatibility testing

-Test case 5: Usability testing

5. Exit Criteria
The Hotel Management System will be deemed ready for release when all test cases have been executed successfully and
all defects have been resolved.

Department of CSE Page 23