INDEX

01 Problem statement document

1.1 Introduction
1.2 Objective
1.3 Scope
1.4 conclusion

02 Software requirement specification (SRS)

2.1 Introduction
2.2 Scope
2.3 Functional requirement
2.4 Non functional requirement
2.5 Conclusion

03 Estimation of project matrix

3.1 Introduction
3.2 Objective
3.3 Application of basic COCOMO model
3.4 Conclusion

04 Modelling UML Use Case Diagrams and Capturing Use Case Scenarios
4.1 Use case diagram
4.2 Use case diagram notation
4.3 Use case diagram for find me college

05 E-R Modelling from the Problem Statements

5.1 Key concept in ER modelling
5.2 Graphical Notations for ER Diagram
5.3 ER diagram for find me college

06 Identifying Domain Classes from the Problem Statements

6.1 Introduction
6.2 Identifying domain classes

07 State chart and Activity Modelling

7.1 Introduction
7.2 Building blocks of an activity diagram
7.3 Table for symbol and there description
7.4 State chart diagram for find me college

08 Modelling UML Class Diagrams

8.1 Introduction
8.2 Relationships Between Classes
8.3 Class diagram for FIND ME COLLEGE
8.4 Key Components of a DFD
8.5 DFD for FIND ME COLLEGE
09 Estimation of Test Coverage Metrics and Structural Complexity
9.1 Test Coverage Metrics
9.2 Structural Complexity
9.3 diagram representing Test Coverage Metrics for find me college

10 Designing Test Suites

10.1 breakdown of what test suites
10.2 best practices for software documentation standards
10.3 Test suites for find me college
Problem Statement Document

Project Title: Find me College

1. Introduction

1.1 Background
In a world where educational trajectories diverge extensively, this system not only acknowledges
but celebrates the distinctiveness of each student. Understanding that no two academic journeys
mirror each other, the system is dedicated to tailoring its suggestions based on the unique
amalgamation of individual aspirations, preferences, and academic goals.

The Find me College emerges as a dynamic and tailored platform, specifically crafted to cater
to the diverse needs of students embarking on their educational journeys. At its core, the primary
objective is to bestow empowerment upon students by offering finely tuned. personalised
recommendations for colleges and universities. This system proves to be unwavering guide for
students exploring a spectrum of academic paths, be it undergraduate programs, postgraduate
studies, or specialised courses.

The educational landscape, vast and sprawling with countless institutions globally, can be an
overwhelming maze for students. However, it is precisely in this labyrinth of options that the Find
me College shines as a guiding compass. Its role transcends mere consideration of academic
metrics; it extends into the very essence of each institution. This includes aspects such as campus
culture, extracurricular opportunities, and community engagement.By intricately weaving together
the threads of academic excellence, personal preferences, and a broader cultural fit, the system aims
to facilitate a seamless transition for students. It envisions not just intellectual growth but a
harmonious alignment with their broader vision for the future.

1.2 Problem Definition

The Find me College endeavours to tackle critical challenges prevalent in the current educational
landscape:

1.2.1 Overwhelming Information Load:

Students grapple with an excess of college information, creating a daunting task of sifting
through and pinpointing the most fitting options.

1.2.2 Personalisation Gap:

Current systems fall short in providing tailored recommendations that extend beyond
academic metrics, neglecting the individuality inherent in each student's educational journey.

1.2.3 Complex Decision-Making:

The absence of a well-defined decision-making process impedes students from efficiently
assessing and comparing multiple colleges. This shortfall encompasses considerations such as
finances, career alignment, and the campus environment.

1.2.4 Limited Access to Comprehensive Information:

Students encounter difficulties in obtaining comprehensive insights into colleges, impeding
their ability to make informed decisions about their academic paths.
1.2.5 Insufficient Support for Application Processes:
Many students face challenges in comprehending and navigating the intricate college
application process. There exists a pressing need for guidance, checklists, and reminders to
streamline this crucial stage in their educational journey.

2.Objectives

2.1 Primary Objectives

2.1.1 Personalised Recommendations

Provide finely-tailored recommendations, leveraging specific parameters, to guide students
seamlessly through their exploration of colleges.

2.1.2 Accurate College Information:

Furnish precise and relevant details about colleges, ensuring students have the information
needed for well-informed decision-making.

2.1.3 Streamlined Decision-Making:

Develop a streamlined decision-making process by incorporating considerations such as financial
aspects, career alignment, and campus safety, facilitating a holistic approach to college selection.

2.2 Secondary Objectives

2.2.1 Enhanced User Experience:

Elevate the overall user experience by implementing features like student tracking, faculty
interaction tools, and a virtual campus tour, creating an immersive and informative platform.5.
Insights into Extracurricular Offerings:
Provide in-depth insights into the array of extracurricular activities available, ensuring
students have a comprehensive understanding of the campus culture and community.

2.2.2 Housing and Accommodation Information:

Offer detailed information on housing options and accommodations, addressing a critical aspect of
students' concerns when considering a college.

2.2.3 Comprehensive Financial Aid Resources:

Extend support by presenting a comprehensive guide to financial aid resources, scholarships, grants,
and other avenues for students seeking financial assistance.

2.2.4 Internship and Job Placement Assistance:

Facilitate students' career journeys by providing guidance and support for securing
internships and post-graduation employment, ensuring a seamless transition from academia to
the professional realm.
These objectives collectively aim to create a comprehensive and user-centric College Suggestions
System that not only assists in college exploration but enriches the overall educational journey of
students.

3.Scope

3.1 Inclusions
The College Suggestions System is designed to be an encompassing and dynamic platform.
tailored to cater to the diverse needs of students embarking on their educational journeys. The
following functionalities and features are within the defined scope of the project.

3.1.1 Personalised Recommendations:

The system will provide personalised recommendations based on specific parameters, assisting
students in exploring colleges that align with their preferences, aspirations, and academic goals.

3.1.2 Accurate College Information:

Furnishing accurate and pertinent details about colleges, including location, available courses,
facilities, admission process, fees, and placement records.

3.1.3 Streamlined Decision-Making:

Aiming to streamline the decision-making process by considering financial considerations, career
alignment, safety, and other relevant factors to empower students in making well-
informed choices.

3.1.4 User-Friendly Registration and Logins:

Implementing a user-friendly registration process enabling students to create accounts by
providing essential details and authenticating users through secure login credentials.

3.1.5 College Search and Recommendations:

Facilitating students in searching for colleges based on criteria such as location, courses, and
specialisation. Providing a recommendation system suggesting colleges tailored to the student's
profile and preferences.

3.1.6 Comprehensive College Details.

Displaying comprehensive information about each college, encompassing infrastructure, admission
process, fees, placement records, and integrating ratings and reviews from other students.

These inclusions collectively contribute to the development of a robust and user-friendly

College Suggestions System, addressing the diverse needs of students and empowering them in
their educational journeys.

3.2 Exclusions

While the College Suggestions System is designed to celebrate the unique educational journeys
of each student, certain functionalities and features are explicitly excluded from the project
scope. The system's focus is on personalised recommendations and empowering students in
their educational pursuits, and the following elements fall outside the defined scope
3.2.1 Individualised Counselling Services:
The system will not provide individualised counselling services tailored to specific students
Personalised academic or career counselling beyond general recommendations is excluded

3.2.2 Psychometric or Personality Assessments:

The project will not include psychometric or in-depth personality assessments for students
While general guidance is offered, detailed psychological profiling is not within the scope

3.2.3 Real-Time Personalised Notifications:

Real-time, individualised notifications or alerts tailored to each student's preferences are no
part of the system. The focus remains on providing information through the platform rather
than personalised alerts.

3.2.4 Integration with External Personal Development Tools:

Integrations with external tools for personal development, beyond the project's educational scope,
are excluded. The system will not replace or integrate with external personal growth platforms.
These exclusions are critical in defining the boundaries of the project, ensuring clarity in
expectations, and maintaining a focused approach toward the primary objectives of the College
Suggestions System.

3.2.5 Target Audience

Primary users include students, while administrators and educational institutions are also key
stakeholders.

3.2.6 Justification
The project stands as a pivotal solution to critical shortcomings within the current educational
landscape. By introducing a comprehensive and user-centric platform, it aims to streamline the
intricate processes of college exploration and decision-making for students. This initiative is driven
by the recognition of existing gaps in the educational system, where students often face
overwhelming challenges in navigating the vast array of colleges and making informed choices
about their academic paths.

3.2.7 Constraints
The project operates within the confines of available hardware and software resources,
emphasising efficiency and optimisation. Simultaneously, it diligently adheres to stringent
privacy regulations and data protection laws, ensuring the utmost security and confidentiality of
user information. These constraints serve as guiding principles, shaping the development
process to align seamlessly with technological limitations and legal requirements.

3.2.8 Assumptions
Certain assumptions were integral to the formulation of the problem statement, including the belief
that the College Suggestions System would effectively address the identified gaps in the educational
system. Assumptions extend to the system's ability to provide accurate and
pertinent information, streamline decision-making.
3.2.9 Dependencies
The project is subject to external factors, resources, or dependencies that may impact its
progression. This includes reliance on the availability of external data sources, integration with
social media platforms for student connectivity, and potential collaboration with educational
institutions for accurate and up-to-date information. The success of the project hinges on these
dependencies functioning harmoniously.

3.2.10 Risks
Anticipated risks associated with the project include potential challenges in data accuracy, user
adoption rates, and technical hurdles during the development process. Mitigation strategies
involve rigorous testing and validation processes, user feedback loops for continuous
improvement, and a flexible development approach to swiftly address unforeseen challenges.

3.2.11 Conclusion
In conclusion, the College Suggestions System is poised to revolutionise the college selection
process by prioritising user-centric design, usability, performance, and security. This document
serves as a comprehensive guide for the development phase, steering towards the creation of a
robust, user-friendly system that empowers students throughout their educational journey. The
emphasis on addressing critical gaps, navigating constraints, and managing dependencies and risks
underscores the commitment to delivering a transformative and seamless experience for students.
Find me College - Software Requirements Specification (SRS)

1. Introduction

The Find me College is a robust platform tailored to meet the needs of students embarking on their
educational journey. Its primary objective is to empower students by providing personalised
recommendations for colleges and universities. Whether a student is exploring undergraduate
programs, postgraduate studies, or specialised courses, this system acts as a reliable guide. The Find
me College is designed to provide personalised recommendations to students seeking information
about colleges. It assists students in selecting suitable institutions based on their preferences,
academic goals, and other relevant criteria.

In a world where educational paths diverge widely, the system acknowledges and celebrates the
uniqueness of each student. Recognising that no two academic journeys are identical, it endeavours
to tailor its suggestions based on individual aspirations, preferences, and academic goals.

The vast expanse of the educational landscape can be daunting, with countless institutions scattered
globally. Navigating through this maze of options is where the system truly shines, acting as a
guiding compass for students seeking the right fit for their educational pursuits.

It considers aspects like campus culture, extracurricular opportunities, Beyond the realm of
academic metrics, the system delves into the essence of and community engagement. It strives not
only to match students with colleges that align with their academic ambitions but also to connect
them with institutions that resonate with their values and aspirations.

In essence, the Find me College is not just about numbers and statistics; it’s about understanding the
holistic educational experience. By weaving together academic excellence, personal preferences,
and a broader cultural fit, it aims to intellectual growth but also align with their broader vision for
the future. facilitate a seamless transition for students into institutions that not only foster their
intellectual growth but also align with their broader vision for the future.

1.1 Purpose
The primary objectives of this system encompass:
1.1.1. Assisting students in exploring colleges based on their specific parameters
1.1.2. Furnishing accurate and pertinent information about colleges.
1.1.3. Facilitating a streamlined decision-making process for students.
1.1.4. Considering Financial Considerations.
1.1.5. Evaluating Career Alignment and Industry Connections.
1.1.6. Assessing Safety and Campus Environment.
1.1.7. Exploring Research Opportunities.
1.1.8. Enhancing Networking and Alumni Networks.
1.1.9. Promoting Global Exposure and International Programs.
1.2 Scope
The system will encompass the following facets:
1.2.1. College particulars (e.g., location, available courses, facilities).
1.2.2. Student personal details (e.g., academic history, areas of interest).
1.2.3. In-depth exploration of Course details (e.g., curriculum, faculty expertise,
placement records).
1.2.4. A Virtual Campus Tour for a comprehensive understanding of the campus
environment.
1.2.5. Implementation of Student Tracking and Summary functionalities for
personalised recommendations.
1.2.6. Integration of Faculty Interaction and Communication tools to foster effective
communication between students and faculty.
Additional Scope Points:
1.2.7. Admission Process Guidance: Providing insights into the admission process,
requirements, and deadlines.
1.2.8. Extracurricular Offerings: Highlighting clubs, sports, and other extracurricular
activities available on campus.
1.2.9. Housing and Accommodation: Offering information on housing options and
accommodations for students
1.2.10.Financial Aid Resources: Providing resources and information regarding
scholarships, grants, and financial aid opportunities.
1.2.11.Internship and Job Placement Assistance: Offering guidance and support for
securing internships and post-graduation employment.
1.2.12.Feedback and Reviews: Incorporating a platform for students to share feedback
and reviews about their college experiences.
1.2.13.Cultural and Social Events: Showcasing information about cultural and social
events happening on campus.

2. Functional Requirements

2.1 User Registration and Login

i. Enable students to create accounts by providing essential details.
ii. Implement authentication through login credentials, including usernames and passwords

2.2 College Search and Recommendations

i. Facilitate students in searching for colleges based on criteria like location, courses,
and specialisation.
ii. Provide a recommendation system suggesting colleges tailored to the student's
profile and preferences.

2.3 College Details

i. Display comprehensive information about each college, encompassing
infrastructure, admission process, fees, and placement records.
ii. Integrate ratings and reviews from other students to offer a holistic perspective.

2.4 Personalised Dashboard

i. Allow students to save favourite colleges and facilitate easy comparison.
ii. Provide a notification system for important updates, including application
deadlines, admission status, and upcoming events.

2.5 Admin Panel

i. Empower administrators to manage college data, user accounts, and system
settings efficiently.

Additional Functionalities:

2.6 Application Guidance

i. Offer guidance on the college application process, ensuring students are well-
informed and prepared.
ii. Provide checklists and reminders for application requirements.

2.7 Social Integration

i. Allow students to connect with peers who share similar college interests.
ii. Integrate shell media features for sharing and discussing college choices.

3. Non-Functional Requirements

3.1 Usability
i. Ensure the system is intuitively designed for easy navigation.
ii. Implement responsive design to enable seamless access on various devices.

3.2 Performance
i. Maintain fast response times for search queries and recommendations.
ii. Ensure scalability to handle a large number of users efficiently.

3.3 Security
i. Implement secure user authentication protocols and robust data encryption.
ii. Enforce role-based access control to safeguard administrator privileges.

Additional Non-Functional Requirements:

3.4 Accessibility
i. Ensure the system complies with accessibility standards for users with diverse needs.
ii. Provide multiple language support for a more inclusive user experience.

4. Constraints
i. The system will operate within the constraints of available hardware and software resources.
ii. Adhere to privacy regulations and data protection laws, ensuring compliance and
user data security.
5. Conclusion
In conclusion, the College Suggestions System is designed with the overarching goal of
revolutionising the college selection process for students. By incorporating an array of.
functionalities, ranging from user-friendly registration and personalised recommendations to
detailed college information and an efficient admin panel, the system strives to create a
comprehensive and seamless experience.

The functionalities outlined in this Software Requirements Specification (SRS) document

underscore the commitment to user-centric design, with an emphasis on usability, performance, and
security. The system not only assists students in navigating the diverse landscape of colleges but
also provides valuable tools for administrators to manage data effectively.

The incorporation of additional features such as application guidance, social integration,

accessibility, and multilingual support further demonstrates a holistic approach to meeting the
diverse needs of students. This ensures that the College that fosters connections, supports decision-
making, and enhances the overall user experience.

This SRS document serves as a vital guide for the development phase, outlining the functional and
non-functional requirements that will shape the system. It acts as a crucial reference point for
stakeholders, providing a clear roadmap for development, testing, and implementation. The
collaborative effort of developers, designers, and administrators, guided by this document, will
contribute to the realisation of a robust and user-friendly College Suggestions System, empowering
students in their educational journey.

References:
1. College-Management-System (SRS)- Stucco
2. software requirements specification (SRS) for student information management
system
3. Placement Management System SRS
4. College Management System Project SRS Download
5. Student management system SRS
Estimation of Project Metrics

1.Introduction
After gathering the entire requirements specific to software project usually we need to think about
different solution strategy for the project. Expert business analysts are analysing their benefits and
as well as their shortcomings by means of cost, time and resources require to develop it.
In this experiment, we will learn how to estimate cost, effort and duration for a software project,
and then select one solution approach which will be found suitable to fulfil the organisational goal.

2.Objectives
After completing this experiment you will be able to:
• Categorise projects using COCOMO, and estimate effort and development time required for
a project
• Estimate the program complexity and effort required to recreate it using Hal stead's metrics
Project Estimation Techniques
A software project is not just about writing a few hundred lines of source code to achieve a
particular objective. The scope of a software project is comparatively quite large, and such a project
could take several years to complete. However, the phrase "quite large" could only give some
(possibly vague) qualitative information. As in any other science and engineering discipline, one
would be interested to measure how complex a project is. One of the major activities of the project
planning phase, therefore, is to estimate various project parameters in order to take proper
decisions. Some important project parameters that are estimated include:
• Project size: What would be the size of the code written say, in number of lines, files,
modules?
• Cost: How much would it cost to develop a software? A software may be just pieces of
code, but one has to pay to the managers, developers, and other project personnel.
• Duration: How long would it be before the software is delivered to the clients?
• Effort: How much effort from the team members would be required to create the software?

The concept of organic, semidetached, and embedded systems are described below.
• Organic: A development project is said to be of organic type, if
• The project deals with developing a well understood application
• The development team is small
• The team members have prior experience in working with similar types of projects
• Semidetached: A development project can be categorised as semidetached type, if
• The team consists of some experienced as well as inexperienced staff
• Team members may have some experience on the type of system to be developed
• Embedded: Embedded type of development project are those, which
• Aims to develop a software strongly related to machine hardware
• Team size is usually large

Bohm suggested that estimation of project parameters should be done through three stages:
Basic COCOMO, Intermediate COCOMO, and Complete COCOMO.
3.Basic COCOMO Model:
The COCOMO (Constructive Cost Model) model is a widely used approach to estimate the effort
(person-months), schedule (months), and cost of software development projects. It considers
various project characteristics to provide a starting point for planning and resource allocation.

4.Intermediate COCOMO Model:

The Intermediate COCOMO model, also known as the Semi-Attached COCOMO model, is an
extension of the Basic COCOMO model that provides a more refined estimation of software
development effort, schedule, and cost. It addresses some of the limitations of the Basic model by
considering various project-specific factors that can influence the development process.

5.Complete COCOMO Model:

The Detailed COCOMO model, also known as the Embedded COCOMO model, is the most
comprehensive version of the COCOMO family of models. It's designed for estimating
development effort, schedule, and cost for large, complex software projects, particularly those
embedded in real-time systems.

Applying Basic COCOMO to FIND ME COLLEGE

1. Size Estimation (Function Points and ELOC)

• Function Point Analysis:

◦ Identify system functionalities:
▪ User registration (if applicable) and login
▪ User input form for academic qualifications, interests, and location preferences
▪ College data storage (programs, admission criteria, fees)
▪ Matching algorithm to suggest suitable colleges based on user input and
college data
▪ Display of college profiles with detailed information
◦ Use a function point analysis method like COSMIC Full Function Point to assign
function points (FP) to each functionality. This involves classifying them into External
Inputs (EI), External Outputs (EO), Inquiries (IQ), Logical Internal Files (LIF), and
External Interface Files (EIF). Each category is assigned a weight based on its
complexity. The sum of weighted values gives the total function point count.
• Example:
• Consider a basic college suggestion system with user input, college data storage, a matching
algorithm (medium complexity), and college profile display. The function point analysis
might yield a total of 70 FPs.
• Estimating ELOC:
• Convert function points to Estimated Lines of Code (ELOC) using an industry-standard
conversion factor. A common value is 50 ELOC/FP. However, this can vary depending on the
programming language, development environment, and coding style.
• Example:
• With 70 FPs and a conversion factor of 50 ELOC/FP, the estimated size of the college
suggestion system would be 3500 ELOC.
2. Effort Estimation (Person-Months)

• Basic COCOMO Formula:

• Use the formula Effort (person-months) = a * (ELOC ^ b) where 'a' and 'b' are constants that
depend on the development mode.
• Organic Mode (Typical for College Suggestion Systems):
• For a new college suggestion system with well-defined requirements, the organic mode likely
applies. Organic mode uses constants a = 2.4 (man-months/KLOC) and b = 1.16.
• Example:
• With 3500 ELOC, the Basic COCOMO formula for organic mode yields an effort estimate of:
Effort = 2.4 * (3.5 ^ 1.16) = 22.36 person-months
•
3. Schedule Estimation (Development Time)

• COCOMO Schedule Estimation Model:

• Use the formula Schedule (months) = c * (Effort ^ d) where 'c' and 'd' are constants derived
from historical data.
• Organic Mode Constants:
• For organic mode, typical values are c = 2.5 and d = 0.4.
• Example:
• Using the effort estimate (22.36 person-months) and organic mode constants:
Schedule = 2.5 * (22.36 ^ 0.4) = 5.8 months (approximately)
•
4. Cost Estimation (Project Budget)

• Salary Rate:
• Determine the average staff salary rate per month (including benefits) for the development
team.
• Calculation:
• Multiply the effort (person-months) by the salary rate to estimate the total project cost.
• Example:
• Assuming an average salary rate of $8,000 per month:
Cost = 22.36 person-months * $8,000/month = $178,880
•
5.Important Considerations:
• COCOMO Assumptions:
• COCOMO estimates are based on historical data of traditional software projects. For agile
development or projects with significant uncertainty, consider using Intermediate COCOMO
with driver factors to adjust the estimates.
• Team Experience:
• The project's success and schedule can be impacted by the development team's experience. A
skilled team with experience in similar systems might be able to reduce effort and schedule
estimates.
• Project Management Overhead:
• The COCOMO estimates only consider development effort. Factor in additional time for
project management activities (planning, monitoring, quality assurance, etc.).
•
6.Additional Functionalities and Adjustments:
• If the college suggestion system includes more complex functionalities like a user
recommendation engine, personalised college rankings, or integration with external college
data sources, the function point analysis and subsequent ELOC, effort, schedule, and cost
estimates will need to be adjusted accordingly.
• As the project progresses and requirements become clearer, the estimates may be refined
using more detailed project information.

Conclusion: In this way we have studied how to Estimation of Project Metrics.

Modelling UML Use Case Diagrams and Capturing Use Case Scenarios

1.Use case diagram

A use case diagram is a visual representation of the interactions between a system (the college
suggestion system) and its external actors (users, external systems). It helps to document the
system's functionality and identify the different user roles and their goals.

Use case diagrams belong to the category of behavioural diagram of UML diagrams. Use case
diagrams aim to present a graphical overview of the functionality provided by the system. It
consists of a set of actions (referred to as use cases) that the concerned system can perform, one or
more actors, and dependencies among them.

2.Actor
An actor can be defined as [1] an object or set of objects, external to the system, which interacts
with the system to get some meaningful work done. Actors could be human, devices, or even other
systems.
For example, consider the case where a customer withdraws cash from an ATM. Here, customer is a
human actor.

Actors can be classified as below [2], [i] :

• Primary actor: They are principal users of the system, who fulfil their goal by availing
some service from the system. For example, a customer uses an ATM to withdraw cash
when he needs it. A customer is the primary actor here.
• Supporting actor: They render some kind of service to the system. "Bank representatives",
who replenishes the stock of cash, is such an example. It may be noted that replenishing
stock of cash in an ATM is not the prime functionality of an ATM.
In a use case diagram primary actors are usually drawn on the top left side of the diagram.

3.Use Case
A use case is simply [1] a functionality provided by a system.
Continuing with the example of the ATM, withdraw cash is a functionality that the ATM provides.
Therefore, this is a use case. Other possible use cases includes, check balance, change PIN, and so
on.
Use cases include both successful and unsuccessful scenarios of user interactions with the system.
For example, authentication of a customer by the ATM would fail if he enters wrong PIN. In such
case, an error message is displayed on the screen of the ATM.

4.Subject
Subject is simply [iii] the system under consideration. Use cases apply to a subject. For example, an
ATM is a subject, having multiple use cases, and multiple actors interact with it. However, one
should be careful of external systems interacting with the subject as actors.
Graphical Representation
An actor is represented by a stick figure and name of the actor is written below it. A use case is
depicted by an ellipse and name of the use case is written inside it. The subject is shown by drawing
a rectangle. Label for the system could be put inside it. Use cases are drawn inside the rectangle,
and actors are drawn outside the rectangle, as shown in figure
Actors in the College Suggestion System:
• Student: The primary actor who seeks college recommendations based on their academic
profile and preferences.
• College Administrator: Manages college data within the system (if applicable). This role
might be part of a separate system that feeds data to the college suggestion system.

Use case diagram notations:

1.Actor: Actors are external entities that interact with the system. These can include users, other
systems, or hardware devices. In the context of a Use Case Diagram, actors initiate use cases and
receive the outcomes. Proper identification and understanding of actors are crucial for accurately
modelling system behaviour.

2.Use case:Use cases are like scenes in the play. They represent specific things your system can do.
In the online shopping system, examples of use cases could be “Place Order,” “Track Delivery,” or
“Update Product Information”. Use cases are represented by ovals.

3.System boundary:The system boundary is a visual representation of the scope or limits of the
system you are modelling. It defines what is inside the system and what is outside. The boundary
helps to establish a clear distinction between the elements that are part of the system and those that
are external to it. The system boundary is typically represented by a rectangular box that surrounds
all the use cases of the system.
Here’s an example of use case diagram of FIND ME COLLEGE
E-R Modelling from the Problem Statements
The E-R (Entity-Relationship) Model in software engineering is a conceptual framework used to
design and represent databases. It focuses on defining entities, their relationships, and the
cardinality between them, providing a structured way to understand and communicate database
design.
Key Concepts in E-R Model:
1. Entity: An entity represents a real-world object or concept with unique attributes. For
example, in a college database, entities could be "Student", "Course", "Professor", etc.
2.
3. Attribute:Attributes are the properties or characteristics of an entity. For example, a
"Student" entity might have attributes like "Student_ID", "Name", "Age", and “Major".
4.
3. Relationship:Relationships describe how entities are connected to each other. For example, a
"Student" might be enrolled in a "Course", which establishes a relationship between these two
entities.
4.
4. Cardinality:Cardinality defines the number of relationships an entity can have with another
entity.
5.
6. Common cardinality types are:
• One-to-One: Each entity in the relationship is linked to one and only one other
entity.
• One-to-Many: An entity on one side of the relationship can be linked to
multiple entities on the other side, but not vice versa.
• Many-to-Many: Entities on both sides of the relationship can be linked to
multiple entities.
E-R Diagrams
E-R Diagrams (ERDs) are visual representations of the E-R Model. They use symbols and notations
to represent entities, attributes, and relationships. The key components in ERDs include:
1. Rectangles : Represent entities.
2. Ovals : Represent attributes.
3. Diamonds : Represent relationships between entities.
4. Lines : Connect entities to relationships, indicating their associations.
5. Crow's Feet Notation : Indicates cardinality at the ends of relationships. A line with a
"crow's foot" suggests a "many" relationship, while a straight line indicates a "one"
relationship.
6.
Uses in Software Engineering : The E-R Model is primarily used in the following contexts:

1. Database Design : It provides a blueprint for structuring databases, ensuring that

relationships and data integrity are well-defined.
2.
3. Requirements Analysis : During requirements analysis, ERDs help capture the system's data
requirements and validate them with stakeholders.
4.
3. Communication : ERDs are useful for communicating database designs to developers,
database administrators, and other stakeholders.
Graphical Notations for ER Diagram

Name of the set is written inside the

Entity set
rectangle

Name of the attribute is written

Attribute
inside the ellipse

Entity with Roll is the primary key; denoted with

attributes an underline

Weak entity set

Name of the relationship is written

Relationship set
inside the diamond

Related enity
sets

A person can own zero or more cars

Relationship
but no two persons can own the same
cardinality
car

Relationship
with weak entity
set
ER diagram for FIND ME COLLEGE
Modelling UML Class Diagrams

UML (Unified Modelling Language) Class Diagrams are a type of static structure diagram that
represents the structure of a system by modelling its classes, attributes, operations, and relationships
among the classes. Here's a detailed description:
Key Components of UML Class Diagrams
1. Classes:
• A class represents a blueprint for objects, encapsulating data and behaviours. It is
depicted as a rectangle with three sections:
• Top Section: Contains the class name.
• Middle Section: Lists the attributes (properties or data members) with their
types.
• Bottom Section: Lists the methods (functions or operations) with their return
types.
2. Attributes:
• Attributes are data members of a class, representing its state. They can have different
visibility levels (public, private, protected) and types. The common notations for
visibility are:
• +: Public
• -: Private
• #: Protected
3. Operations:
• Operations are functions or methods that define the behaviour of the class. They can
also have visibility levels, input parameters, and return types.

Relationships Between Classes

1. Associations:
• Represents a relationship between two classes. It can be bidirectional or unidirectional.
An arrowhead indicates the direction of the relationship.
•
2. Aggregations:
• A type of association that indicates a whole-part relationship. The "whole" class is
depicted with a diamond shape, signifying that it has one or more parts.
•
3. Compositions:
• A stronger form of aggregation where the "whole" cannot exist without its parts. The
diamond shape is filled to distinguish it from aggregation.
•
•
5. Implementations:
• Represents a relationship where a class implements an interface (like a contract for
behaviour). It is depicted with a dashed line and a hollow triangle pointing towards the
interface.
Class diagram for FIND ME COLLEGE
Modelling Data Flow Diagrams

A Data Flow Diagram (DFD) is a graphical representation used in system analysis and design to
illustrate how data flows through a system, showing the inputs, processes, storage, and outputs of a
system. It is a crucial tool for understanding the structure and functioning of a system or process,
and it is commonly used in software engineering, information systems, and business process
management.
Key Components of a DFD
1. Processes: Represented by circles or rounded rectangles.
• Show the transformation or processing of data.
• Typically contain a name or a brief description of the function they perform.
•
2. Data Flows: Represented by arrows.
• Indicate the movement of data between components.
• Include a label describing the type of data being transmitted.
•
3. Data Stores: Represented by open rectangles or parallel lines.
• Depict where data is stored within the system.
• Can represent databases, files, or any form of data storage.
•
4. External Entities: Represented by squares or rectangles.
• Denote external actors or systems that interact with the process but are not
• Often represent users, customers, or other systems.
Levels of DFDs
DFDs can be created at various levels of detail, ranging from high-level overviews to detailed
descriptions of system processes.

1. Context Diagram (Level 0 DFD):

• The highest-level DFD, providing an overview of the system.
• Shows the system as a single process and highlights external entities that interact with
the system.
• Useful for identifying system boundaries and key stakeholders.
•
2. Level 1 DFD:
• Breaks down the main process into several sub-processes.
• Illustrates the primary functions within the system and how data flows between them.
• Helps in understanding the system's internal workings.
•
3. Lower-Level DFDs (Level 2, Level 3, etc.):
• Provide increasingly detailed views of specific processes.
• Useful for detailed system analysis and design, showing sub-processes, data stores,
and detailed data flows.
Benefits of DFDs

• Clarity: Offers a visual representation that is easy to understand, promoting better

communication among stakeholders.
•
• Simplification: Allows complex systems to be simplified into manageable components.
•
• Analysis: Aids in analysing the system's structure and identifying bottlenecks or
inefficiencies.
•
• Documentation: Useful for system documentation, ensuring a consistent understanding
across teams.

Symbols in DFD’S

Term Notation Remarks

External Name of the external entity is written inside the

entity rectangle

Process Name of the process is written inside the circle

A left-right open rectangle is denoted as data store;

Data store
name of the data store is written inside the shape

Data flow is represented by a directed arc with its data

Data flow
name

Applications of DFDs
• System Analysis: Helps in understanding and analysing existing systems to improve or
redesign them.
•
• System Design: Assists in designing new systems by providing a clear blueprint of the data
flow and processes.
•
• Business Process Modelling: Used to model and improve business processes by analysing
data flows and identifying areas for optimisation.
 • DFD for FIND ME COLLEGE

LEVEL 0

LEVEL 1
LEVEL 2
Estimation of Test Coverage Metrics and Structural Complexity

Estimating test coverage metrics and structural complexity for a college suggestion system involves
analysing the system's codebase and design to understand the extent to which tests cover the
system's functionality and how complex the underlying structure is. This analysis can help guide
testing efforts and identify areas where code refactoring or additional testing might be needed.
Here's a detailed explanation of how you might approach this estimation:

Test Coverage Metrics

Test coverage metrics measure the extent to which a software system's code is executed during
testing. Common test coverage metrics include:

1. Statement Coverage:Measures the percentage of executable statements in the codebase that

are executed during testing. The goal is to ensure that all code statements are covered by test
cases.
2.
3. Branch Coverage:Measures the percentage of decision points (e.g., if statements) in the
codebase that are executed during testing. This helps ensure that all branches in the code are
tested.
4.
3. Path Coverage:Measures the percentage of all possible execution paths in the code that are
executed during testing. This metric is more comprehensive but also more challenging to
achieve high coverage.
4.
4. Function/Method Coverage:Measures the percentage of functions or methods that are
executed during testing. This metric ensures that each function has at least one test case.
5.
5. Class Coverage:Measures the percentage of classes that are executed during testing. It helps
ensure that all key components of the system are tested.
6.
Structural Complexity
Structural complexity refers to the complexity of the system's architecture and codebase. Key
factors that influence structural complexity include:
1. Cyclomatic Complexity:Measures the number of independent paths through the code. Higher
cyclomatic complexity indicates more complex code, which may be more challenging to test
and maintain.
2.
3. Depth of Inheritance:Measures the number of inheritance levels in the system's class
hierarchy. Deeper inheritance can increase complexity and introduce potential issues with
overriding methods and dependencies.
4.
3. Coupling and Cohesion:Coupling measures the degree of interdependence between classes
or modules. Lower coupling is generally preferred for easier maintenance.
4. Cohesion measures how closely related the functions within a module or class are. Higher
cohesion is generally preferred for better modularity.
5.
4. Lines of Code (LOC):Measures the total number of lines of code in the codebase. A larger
codebase can indicate higher complexity.
Estimating these metrics can be done through various methods:

• Manual Code Review: Reviewing the code and test cases to identify untested areas.
• Static Code Analysis Tools: These tools can automatically calculate metrics like statement
and decision coverage based on the codebase.
• Test Coverage Reporting Tools: These tools integrate with your testing framework and
report on the percentage of code covered by your tests.

For a college suggestion system, here's what to consider when estimating these metrics:

• Data Input Complexity: How well do your tests cover various user input scenarios,
including edge cases (e.g., very high/low GPA, unique extracurricular activities)?
• Matching Algorithm Complexity: Is the algorithm that matches students to colleges
thoroughly tested with diverse student profiles and college characteristics?
• User Interface (UI) Complexity: Are all functionalities of the UI tested, including filtering
options, sorting mechanisms, and result presentation?

diagram representing Test Coverage Metrics for a FIND ME COLLEGE:

Designing Test Suites

In software development, a test suite is a collection of organised test cases designed to validate a
software program's functionality and performance. It acts like a container that groups these
individual test cases for efficient execution, reporting, and management.

Here's a breakdown of what test suites offer:

• Structured Testing: By grouping related test cases together, test suites enable a systematic
approach to testing different aspects of the software, ensuring comprehensive coverage.
• Efficient Execution: Test suites can be automated for execution, saving time and effort
compared to running tests individually.
• Reporting and Management: Test suite results are consolidated, making it easier to track
progress, identify defects, and analyse overall test coverage.
• ** Reusability:** Well-designed test suites can be reused across different testing cycles or
projects with similar functionalities.
Test suites can be designed based on various factors, such as:

• Functionality: A suite might group tests for a specific feature or module.

• Requirement: Tests verifying a particular user requirement can be grouped.
• Type of Testing: There could be separate suites for functional, performance, or usability
testing.pen_spark

Standard of software testing documents

Software documentation standards ensure consistency, clarity, and completeness in the information
that accompanies a software product. There isn't a single universally mandated standard, but several
influential guidelines and resources are commonly followed. Here's a breakdown of some key
standards:

1. ISO/IEC/IEEE 2651x series:

This is a collection of international standards specifically focused on software documentation. It

covers various aspects like:

• Requirements specifications
• Design descriptions
• User manuals
• Installation guides
• Testing processes
The standards provide recommendations for structure, content, and formatting, promoting clear and
consistent documentation across projects.

2. Institute of Electrical and Electronics Engineers (IEEE) Style Guide:

This style guide offers recommendations for professional writing in the technical domain. It covers
aspects like:

• Formatting of text, tables, and figures

 • Use of citations and references
• Grammar and punctuation
Following this guide ensures a professional and polished look for your software documentation.

3. API Documentation Standards:

For software with Application Programming Interfaces (APIs), specific standards like OpenAPI
(Swagger) or RESTful API documentation guidelines promote clear and consistent communication
with developers who want to interact with your software.

4. Organisational Standards:

Many software development organisations establish their own internal documentation standards.
These may build upon the above resources while tailoring them to specific project needs, company
style guides, and preferred tooling.

Here are some general best practices for software documentation standards:

• Target Audience: Tailor the level of detail and technical language to the intended audience
(developers, end-users, etc.).
• Accuracy and Completeness: Ensure the information is up-to-date, accurate, and covers all
essential aspects of the software.
• Consistency: Maintain a consistent style guide for formatting, terminology, and structure
throughout the documentation.
• Accessibility: Use clear and concise language, along with helpful visuals like screenshots
and diagrams.
• Tooling: Leverage documentation generation tools and version control systems to
streamline the creation and maintenance of documentation.

Need for Software Testing

There are many reasons for why we should test software, such as:
• Software testing identifies the software faults. The removal of faults helps reduce the
number of system failures. Reducing failures improves the reliability and the quality of the
systems.
• Software testing can also improves the other system qualities such as maintainability,
usability, and testability.
• In order to meet the condition that the last few years of the 20th century systems had to be
shown to be free from the ‘millennium bug’.
• In order to meet the different legal requirements.
• In order to meet industry specific standards such as the Aerospace, Missile and Railway
Signalling standards.

Test suites for FIND ME COLLEGE

1. User Input Validation Suite:

• Description: This suite ensures the system handles user input for student profiles and
college preferences correctly.
• Test Cases:
◦ Validates numeric data like GPA within a reasonable range (e.g., 0.0 - 4.0).
 ◦ Verifies text input for fields like name, major, and extracurricular activities.
◦ Checks for missing or empty required fields.
◦ Tests handling of invalid characters or special symbols in input.
◦ Ensures proper validation for dropdown menus or checkbox selections.
2. Matching Algorithm Suite:
• Description: This suite focuses on the core functionality of matching students to colleges.
• Test Cases:
◦ Tests matching accuracy for diverse student profiles with varying academic strengths,
interests, and preferences.
◦ Verifies the system considers college factors like location, size, programs offered,
and financial aid options.
◦ Validates how weights assigned to different criteria (GPA, test scores,
extracurriculars) affect matching results.
◦ Tests handling of edge cases, such as students with limited extracurricular
involvement or colleges with unique programs.
◦ Ensures consistency in matching results for similar student profiles across multiple
runs.
3. User Interface (UI) Suite:
• Description: This suite verifies the functionality and usability of the user interface.
• Test Cases:
◦ Tests various filtering options (e.g., location, program type, cost) and ensures they
refine college listings effectively.
◦ Verifies sorting functionality for colleges based on different criteria (e.g., average
GPA, acceptance rate, cost).
◦ Checks proper display of college details (descriptions, images, links) on the results
page.
◦ Ensures accessibility features like screen reader compatibility are functional for users
with disabilities.
◦ Tests overall user experience for navigating the UI, finding relevant colleges, and
accessing information.
4. System Integration Suite:
• Description: This suite focuses on how the college suggestion system interacts with external
systems or data sources.
• Test Cases: (This will depend on your specific system's integrations)
◦ Tests successful data retrieval from external college databases or APIs.
◦ Verifies data integrity and ensures college information displayed aligns with external
sources.
◦ Checks for error handling in case of connection issues with external systems.
◦ Tests functionalities related to user authentication or account creation (if applicable).
◦ Ensures proper data encryption and security when handling sensitive user
information.
5. Performance and Scalability Suite:
• Description: This suite evaluates the system's performance under load and its ability to scale
with increased usage.
• Test Cases:
◦ Simulates various user loads and assesses response times for generating college
suggestions.
◦ Tests system performance when handling large datasets of student profiles and
colleges.
◦ Evaluates scalability by simulating how the system performs with increased
concurrent users.
◦ Monitors system resources (CPU, memory) during peak usage and identifies
potential bottlenecks.
Identifying Domain Classes from the Problem Statements

Introduction
Same types of objects are typically implemented by class in object oriented programming. As the
structural unit of the system can be represented through the classes, so, it is very important to
identify the classes before start implementing all the logical flows of the system.
In this experiment we will learn how to identify the classes from a given problem statement.

Grammatical Approach Using Nouns

This object identification technique was proposed by Russell J. Abbot, and Grady Booth made the
technique popular [1]. This technique involves grammatical analysis of the problem statement to
identify list of potential classes. The logical steps are:
1. Obtain the user requirements (problem statement) as a simple, descriptive English text. This
basically corresponds to the use-case diagram for the problem statement.
2. Identify and mark the nouns, pronouns and noun phrases from the above problem statements
3. List of potential classes is obtained based on the category of the nouns (details given later).
For example, nouns that direct refer to any person, place, or entity in general, correspond to
different objects. And so does singular proper nouns. On the other hand, plural nouns and
common nouns are candidates that usually map into classes.

We now present the steps to identify domain classes from a given problem statement. This approach
is mostly based on the “Grammatical approach using nouns” discussed above, with some insights
from [i].
1. Make a list of potential objects by finding out the nouns and noun phrases from narrative
problem statement
2. Apply subject matter expertise (or domain knowledge) to identify additional classes
3. Filter out the redundant or irrelevant classes
4. Group the objects based on similar attributes. While grouping we should remember that
1. Different nouns (or noun phrases) can actually refer to the same thing (examples:
house, home, abode)
2. Same nouns (or noun phrases) could refer to different things or concepts (example: I
go to school every day / This school of thought agrees with the theory)
5. Give related names to each group to generate the final list of top level classes
6. Iterate over to refine the list of classes
 Categories Explanation
People Humans who carry out some function
Places Areas set aside for people or things
Things Physical objects
Organizatio Collection of people, resources, facilities and
ns capabilities having a defined mission
Concepts Principles or Ideas not tangible
Things that happen (usually at a given date and
Events
time), or as a steps in an ordered sequence

From the Problem Statement we can identify the following nouns and noun phrases:-

1. College
2. Student
3. Sports
4. Cutoff
5. Student marks
6. Reservation
7. Admin
8. Cultural activities
9. Student Priorities
10. Facilities
11. College list
12. Suggestion System
13. University

Identified Domain classes:-

1. College
2. Student
3. University
4. Priorities
5. Marks
6. Cutoff
7. College reservation
8. College list
State chart and Activity Modelling

Introduction
In case of Object Oriented Analysis and Design, a system is often abstracted by one or more classes
with some well defined behaviour and states. A state chart diagram is a pictorial representation of
such a system, with all it's states, and different events that lead transition from one state to another.
To illustrate this, consider a computer. Some possible states that it could have are: running,
shutdown, hibernate. A transition from running state to shutdown state occur when user presses the
"Power off" switch, or clicks on the "Shut down" button as displayed by the OS. Here, clicking on
the shutdown button, or pressing the power off switch act as external events causing the transition.
State chart diagrams are normally drawn to model the behaviour of a complex system. For simple
systems this is optional.

Below we describe the building blocks of an activity diagram:

Activity
An activity denotes a particular action taken in the logical flow of control. This could simply be
invocation of a mathematical function, alter an object's properties and so on [x]. An activity is
represented with a rounded rectangle, as shown in table-01. A label inside the rectangle identifies
the corresponding activity.
There are two special type of activity nodes: initial and final. They are represented with a filled
circle, and a filled in circle with a border respectively (table-01). Initial node represents the starting
point of a flow in an activity diagram. There could be multiple initial nodes, which means that
invoking that particular activity diagram would initiate multiple flows.
A final node represents the end point of all activities. Like an initial node, there could be multiple
final nodes. Any transition reaching a final node would stop all activities.

Flow
A flow (also termed as edge, or transition) is represented with a directed arrow. This is used to
depict transfer of control from one activity to another, or to other types of components, as we will
see below. A flow is often accompanied with a label, called the guard condition, indicating the
necessary condition for the transition to happen. The syntax to depict it is [guard condition].

Decision
A decision node, represented with a diamond, is a point where a single flow enters and two or more
flows leave. The control flow can follow only one of the outgoing paths. The outgoing edges often
have guard conditions indicating true-false or if-then-else conditions. However, they can be omitted
in obvious cases. The input edge could also have guard conditions. Alternately, a note can be
attached to the decision node indicating the condition to be tested.

Merge
This is represented with a diamond shape, with two or more flows entering, and a single flow
leaving out. A merge node represents the point where at least a single control should reach before
further processing could continue.
Fork
Fork is a point where parallel activities begin. For example, when a student has been registered with
a college, he can in parallel apply for student ID card and library card. A fork is graphically depicted
with a black bar, with a single flow entering and multiple flows leaving out.

Join
A join is depicted with a black bar, with multiple input flows, but a single output flow. Physically it
represents the synchronisation of all concurrent activities. Unlike a merge, in case of a join all of the
incoming controls must be completed before any further progress could be made. For example, a
sales order is closed only when the customer has receive the product, and the sales company has
received it's payment.

Note
UML allows attaching a note to different components of a diagram to present some textual
information. The information could simply be a comment or may be some constraint. A note can be
attached to a decision point, for example, to indicate the branching criteria.

Partition
Different components of an activity diagram can be logically grouped into different areas, called
partitions or swim lanes. They often correspond to different units of an organisation or different
actors. The drawing area can be partitioned into multiple compartments using vertical (or
horizontal) parallel lines. Partitions in an activity diagram are not mandatory.
The following table shows commonly used components with a typical activity diagram.

State
A state is any "distinct" stage that an object (system) passes through in it's lifetime. An object
remains in a given state for finite time until "something" happens, which makes it to move to
another state. All such states can be broadly categorised into following three types:
• Initial: The state in which an object remain when created
• Final: The state from which an object do not move to any other state [optional]
• Intermediate: Any state, which is neither initial, nor final

Transition
Transition is movement from one state to another state in response to an external stimulus (or any
internal event). A transition is represented by a solid arrow from the current state to the next state. It
is labeled by: event [guard-condition]/[action-expression], where
• Event is the what is causing the concerned transition (mandatory) -- Written in past
tense [iii]
• Guard-condition is (are) precondition(s), which must be true for the transition to happen
[optional]
Action
As mentioned in [ii], actions represents behaviour of the system. While the system is performing
any action for the current event, it doesn't accept or process any new event. The order in which
different actions are executed, is given below:
1. Exit actions of the present state
2. Actions specified for the transition
Table for symbol and there description:

Component Graphical Notation

Activity

Flow

Decision

Merge

Fork

Join

Note
State chart diagram for FIND ME COLLEGE