EXCERCISE NO.

AIM: To PREPARE PROBLEM STATEMENT.

 REQUIREMENTS:

 Hardware Interfaces:

 RAM: minimum of 1GB to 2GB

 Hard Disk drive: minimum of 16GB or 32GB

 Software Interfaces:

 Processor:
 ARM (Advanced RISC Machines):
 Qualcomm Snapdragon
 Samsung Exynos
 MediaTek Helio
 Huawei Kirin
 Intel Atom
 NVIDIA Tegra
 Sony Xperia Mobile Platform
 Google Tensor
 Unisoc (Spreadtrum)
 x86 (Intel Architecture)
 x86_64 (64-bit Intel Architecture)

THEORY:

In response to the growing mental health crisis, our Software Requirements Specification (SRS) aims to design
and implement a comprehensive mental health solution. This software will offer user-friendly interfaces,
advanced analytics, and secure communication channels to connect individuals with professional support,
fostering a proactive and inclusive approach to mental health care. By prioritizing privacy, cultural sensitivity,
and evidence-based interventions, our SRS seeks to contribute to the improvement of mental health outcomes

and the overall well-being of users.

 EXCERCISE NO. 2

AIM: UNDERSTANDING AN SRS.

 Requirements:

 Hardware Requirements:

 Processor:

 ARM (Advanced RISC Machines):

 Qualcomm Snapdragon
 Samsung Exynos
 MediaTek Helio
 Huawei Kirin
 Intel Atom
 NVIDIA Tegra
 Sony Xperia Mobile Platform
 Google Tensor
 Unisoc (Spreadtrum)
 x86 (Intel Architecture)
 x86_64 (64-bit Intel Architecture)

RAM: minimum of 1GB to 2GB

Hard Disk drive: minimum of 16GB or 32GB

Theory:
A comprehensive theory for a student result management system encompasses several key aspects, including its
objectives, components, functionalities, and underlying principles. Here's a theoretical framework for such a system:
Objectives:
 Efficiently manage student academic records and results.
 Provide timely access to results for students, faculty, and administrators.
 Ensure data accuracy and security.
 Streamline administrative processes related to result management.
 Facilitate data analysis for academic performance evaluation and decision-making.
Components:
 User Interface: Provides interfaces for students, faculty, and administrators to interact with the system.
 Database: Stores student information, course details, and result records securely.
 Result Processing Engine: Manages the computation, validation, and storage of examination results.
 Reporting Module: Generates various types of reports such as grade sheets, transcripts, and statistical analyses.
  Access Control: Ensures that only authorized users have access to specific functionalities and data.
 Notification System: Alerts stakeholders about result updates, deadlines, and other relevant information.
Functionalities:
 Student Registration: Allows students to register for courses and exams.
 Result Entry: Enables faculty members to input and submit student scores.
 Result Processing: Automatically calculates grades, aggregates results, and applies grading rules.
 Result Publication: Publishes results securely and provides access to students and authorized personnel.
 Data Analysis: Supports the analysis of academic performance trends, class averages, and individual student
progress.
 Administrative Tasks: Facilitates tasks such as generating academic calendars, managing course offerings, and
handling academic appeals.
 Data Backup and Recovery: Implements robust backup and recovery mechanisms to prevent data loss.
Underlying Principles:
 Accuracy: Ensures that the system accurately reflects student performance and maintains data integrity.
 Security: Implements measures to safeguard student information and prevent unauthorized access.
 Scalability: Designs the system to handle varying numbers of students, courses, and academic sessions.
 Usability: Prioritizes user-friendly interfaces and intuitive workflows to enhance adoption and efficiency.
 Integration: Integrates with other academic systems such as learning management systems and student information
systems for seamless data exchange.
 Compliance: Adheres to relevant regulations and standards governing student data privacy and academic
administration.

System Modules:
User Authentication:
 Login/Register: Secure registration and login for students, faculty, and administrators.
Result Management:
 View Results: Students can view their academic results for various courses and semesters.
 Enter Results: Faculty can input and submit student scores for respective courses.
 Publish Results: Administrators can publish semester-wise results for students.
Search and Filter:
 Search Courses: Students can search for courses based on course code, title, or instructor.
 Filter Results: Users can filter search results based on course type, credit hours, or semester.
Academic Planning:
 Course Registration: Students can register for courses offered in a particular semester.
 Semester Planning: Faculty can plan course offerings and schedule exams for each semester.
Appointment System (Optional for Student Result Management):
 Advisor Appointment Booking: Students can book appointments with academic advisors for course
guidance.
Communication Platform (Optional for Student Result Management):
 Messaging System: Students can communicate with faculty or administrators regarding academic queries.
 Forum/Discussion Board: Platform for students to discuss course-related topics or seek clarification.
Reporting and Analytics:
 Generate Reports: Administrators can generate reports such as class-wise performance analysis, grade
 distribution, and course-wise statistics.
 Analytics Dashboard: Visual representation of academic performance trends, class averages, and student
progress.
Data Security and Access Control:
 Role-Based Access Control: Different levels of access for students, faculty, and administrators.
 Data Encryption: Ensure the security of student records and academic data.
System Administration:
 User Management: Administrators can manage user accounts, permissions, and roles.
 System Configuration: Settings for customization, such as academic calendar setup and grading rules.
Notifications:
 Result Publication Alerts: Notify students when new results are published.
 Deadline Reminders: Remind students of registration deadlines, exam schedules, etc.

Non-functional requirements for Student Result Management System (SRMS):

Privacy:
 User Authentication: Each user must have a unique username and password for secure access to the system.
 Role-Based Access Control: Different user roles (students, faculty, administrators) should have access only to the
functionalities relevant to their roles.
 Data Encryption: Student records, grades, and personal information should be encrypted to ensure privacy and
confidentiality.
Portability:
 Cross-Platform Compatibility: The SRMS should be compatible with various operating systems including
Windows, macOS, Linux, Chrome OS, Android, and iOS (with limitations).
 Browser Compatibility: The system should be accessible from popular web browsers such as Chrome, Firefox,
Safari, and Edge.
 Mobile Responsiveness: The system's interface should adapt to different screen sizes and resolutions for seamless
access from mobile devices.
Preparation of Software Configuration Management:
 Version Control: Utilize version control systems (e.g., Git) to manage software versions and track changes made
during development.
 Configuration Management Plan: Develop a comprehensive plan for managing system configurations, updates, and
deployment processes.
Software Requirements:
 Operating System:
Compatibility: Ensure compatibility with various operating systems including Windows, macOS, Linux,
Android, and iOS (with limitations).
 Frontend:
 User Interface: Develop the frontend using appropriate technologies such as HTML, CSS, and JavaScript
for web-based access. For mobile applications, XML and Java should be utilized.

 Backend:
 Database Management: Utilize SQLite as the backend database management system to store and manage
student records, results, and other relevant data.
  IDE:
 Android Studio: Use Android Studio as the integrated development environment for Android applications.
Minimum Hardware Requirements:
 Processor:
 ARM and x86 Architectures: Ensure compatibility with processors including Qualcomm Snapdragon,
Samsung Exynos, Intel Atom, etc.
 RAM:
 Minimum of 1GB to 2GB RAM for smooth operation of the application.
 Storage:
 Hard Disk Drive: Minimum of 16GB or 32GB storage space to accommodate the application and data
storage requirements.
 EXCERCISE NO. 3

AIM: T O PREPARE DATA FLOW DIAGRAM F O R ANY PROJECT.

REQUIREMENTS:

Hardware Interfaces

 Pentium(R) 4 CPU 2.26 GHz, 128 MB RAM

 Screen resolution of at least 800 x 600 required for proper and complete viewing
of screens. Higher resolution would not be a problem.
 CD ROM Driver

Software Interfaces

 Any window-based operating system (Windows 95/98/2000/XP/NT)

 WordPad or Microsoft Word

THEORY
Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.
Data Flow Diagram Notations
You can use two different types of notations on your data flow diagrams: Yourdon & Coad or
Gane & Sarson.

Process Notations

Yourdon and Coad

Process Notations

Process

Gane and Sarson

Process Notation
A process transforms incoming data flow into outgoing data flow.

Datastore Notations

Yourdon and Coad

Datastore Notations

Gane and Sarson

Datastore Notations
DataStore
Datastores are repositories of data in the system. They are sometimes also referred to as files.

Dataflow Notations

Dataflow
Dataflows are pipelines through which packets of information flow. Label the arrows with the
name of the data that moves through it.

HOW TO DRAW DATA FLOW DIAGRAMS (cont'd)

Data Flow Diagram Layers

Draw data flow diagrams in several nested layers. A single process node on a high level diagram
can be expanded to show a more detailed data flow diagram. Draw the context diagram first,
followed by various layers of data flow diagrams.
 The nesting of data flow layers

Context Diagrams
A context diagram is a top level (also known as Level 0) data flow diagram. It only contains
one process node (process 0) that generalizes the function of the entire system in relationship to
external entities.
 External Entity Notations

External Entity
External entities are objects outside the system, with which the system communicates. External
entities are sources and destinations of the system's inputs and outputs.

DFD levels
The first level DFD shows the main processes within the system. Each of these processes can be
broken into further processes until you reach pseudocode.
CONCLUSION

LEVEL – 0 DFD
LEVEL –1 DFD

LEVEL – 2 DFD
EXERCISE NO. 4
Aim: STEPS TO DRAW THE USE CASE DIAGRAM USING STARUML.

Hardware Requirements:

Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored monitor.

Software Requirements:
StarUML, Windows XP,

Theory:

According to the UML specification a use case diagram is ―a diagram that shows the
relationships among actors and use cases within a system.‖ Use case diagrams are often used to:

 Provide an overview of all or part of the usage requirements for a system or

organization in the form of an essential model or a business model
 Communicate the scope of a development project
 Model your analysis of your usage requirements in the form of a system use case model

Use case models should be developed from the point of view of your project stakeholders and
not from the (often technical) point of view of developers. There are guidelines for:

Use Cases Actors

Relationships

System Boundary Boxes

1. Use Cases

A use case describes a sequence of actions that provide a measurable value to an actor. A use
case is drawn as a horizontal ellipse on a UML use case diagram.

1. Use Case Names Begin With a Strong Verb

2. Name Use Cases Using Domain Terminology
3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram
4. Imply Timing Considerations By Stacking Use Cases.

2. Actors

An actor is a person, organization, or external system that plays a role in one or more interactions
with your system (actors are typically drawn as stick figures on UML Use Case diagrams).

1. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram

2. Draw Actors To The Outside Of A Use Case Diagram
3. Name Actors With Singular, Business-Relevant Nouns
4. Associate Each Actor With One Or More Use Cases
5. Actors Model Roles, Not Positions
6. Use <<system>> to Indicate System Actors
7. Actors Don‘t Interact With One Another
8. Introduce an Actor Called ―Time‖ to Initiate Scheduled Events

3. Relationships

There are several types of relationships that may appear on a use case diagram:

 An association between an actor and a use case

 An association between two use cases
 A generalization between two actors
 A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with an optional open-
headed arrowhead on one end of the line indicating the direction of the initial invocation of the
relationship. Generalizations are depicted as a close-headed arrow with the arrow pointing
towards the more general modeling element.

1. Indicate An Association Between An Actor And A Use Case If The Actor

Appears Within The Use Case Logic
2. Avoid Arrowheads On Actor-Use Case Relationships
3. Apply <<include>> When You Know Exactly When To Invoke The Use Case
 4. Apply <<extend>> When A Use Case May Be Invoked Across Several Use Case Steps
5. Introduce <<extend>> associations sparingly
6. Generalize Use Cases When a Single Condition Results In Significantly New
Business Logic
7. Do Not Apply <<uses>>, <<includes>>, or <<extends>>
8. Avoid More Than Two Levels Of Use Case Associations
9. Place An Included Use Case To The Right Of The Invoking Use Case
10. Place An Extending Use Case Below The Parent Use Case
11. Apply the ―Is Like‖ Rule to Use Case Generalization
12. Place an Inheriting Use Case Below The Base Use Case
13. Apply the ―Is Like‖ Rule to Actor Inheritance
14. Place an Inheriting Actor Below the Parent Actor

4. System Boundary Boxes

The rectangle around the use cases is called the system boundary box and as the name suggests it
indicates the scope of your system – the use cases inside the rectangle represent the functionality
that you intend to implement.

1. Indicate Release Scope with a System Boundary Box.

2. Avoid Meaningless System Boundary Boxes.
Result:
 EXCERCISE NO. 5

AIM: - TO DRAW A SAMPLE ENTITY RELATIONSHIP DIAGRAM FOR

REAL PROJECT OR SYSTEM.

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard

keyboard n mouse, colored monitor.

Software Requirements: Rational Rose, Windows XP,

THEORY

Entity Relationship Diagrams are a major data modelling tool and will help organize
the data in your project into entities and define the relationships between the entities.
This process has proved to enable the analyst to produce a good database structure so
that the data can be stored and retrieved in a most efficient manner.

Entity

A data entity is anything real or abstract about which we want to store data. Entity types
fall into five classes: roles, events, locations, tangible things or concepts. E.g. employee,
payment, campus, book. Specific examples of an entity are called instances. E.g. the
employee John Jones, Mary Smith's payment, etc.
Relationship
A data relationship is a natural association that exists between one or more entities. E.g.
Employees process payments. Cardinality defines the number of occurrences of one
entity for a single occurrence of the related entity. E.g. an employee may process many
payments but might not process any payments depending on the nature of her job.

Entity Set
An entity set is a collection of related types of entities. An entity set may include entities with
attributes sharing similar values. For example, a student set may contain all the students at a
school; likewise, a teacher set may include all the teachers at a school from all faculties.
Entity set need not be disjoint.
ERD relationship symbols

Within entity-relationship diagrams, relationships are used to

document the interaction between two entities. Relationships are
usually verbs such as assign, associate, or track and provide useful
information that could not be discerned with just the entity types.

Relationship Symbol Name Description

Relationships are associations

Relationship
between or among entities.

Weak
Weak Relationships are
relationship connections between a weak entity
and its owner.

ERD attribute symbols

ERD attributes are characteristics of the entity that help users to

better understand the database. Attributes are included to include
details of the various entities that are highlighted in a conceptual ER
diagram.

Attribute Symbol Name Description

Attributes are characteristics of an

entity, a many-to-many
Attribute
relationship, or a one-to-one
relationship.

Multivalued
Multivalued attributes are those
attribute that are can take on more than
one value.

Derived
Derived attributes are attributes
attribute whose value can be calculated
from related attribute values.
Attribute Symbol Name Description

Relationship Relationships are associations

between or among entities.

Attributes

Entities are denoted utilizing their properties, known as attributes. All attributes
have values. For example, a student entity may have name, class, and age as
attributes.
There exists a domain or range of values that can be assigned to attributes. For
example, a student's name cannot be a numeric value. It has to be alphabetic. A
student's age cannot be negative, etc.
There are four types of Attributes:

1. Key attribute
2. Composite attribute
3. Single-valued attribute
4. Multi-valued attribute
5. Derived attribute

1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an

entity among the entity set. For example, the roll_number of a student makes him identifiable
among students.
There are mainly three types of keys:

 Super key: A set of attributes that collectively identifies an entity in the entity set.
 Candidate key: A minimal super key is known as a candidate key. An entity set may
have more than one candidate key.
 Primary key: A primary key is one of the candidate keys chosen by the database
designer to uniquely identify the entity set.

2. Composite attribute: An attribute that is a combination of other attributes is

called a composite attribute. For example, in student entity, the student address
is a composite attribute as an address is composed of other characteristics such
as pin code, state, country.
3. Single-valued attribute: Single-valued attribute contain a single value. For
example, Social_Security_Number.
4. Multi-valued Attribute: If an attribute can have more than one value, it is
known as a multi-valued attribute. Multi-valued attributes are depicted by the
double ellipse. For example, a person can have more than one phone number,
email address, etc.

5. Derived attribute: Derived attributes are the attributes that do not exist in
the physical database, but their values are derived from other attributes present
in the database. For example, age can be derived from date_of_birth. In the ER
diagram, Derived attributes are depicted by the dashed ellipse.
Relationships
The association among entities is known as a relationship. Relationships are represented by
the diamond-shaped box. For example, an employee works at a department, a student enrolls
in a course. Here, Works at and enrolls are called relationships.

Relationship set
A set of relationships of a similar type is known as a relationship set. Like entities, a
relationship too can have attributes. These attributes are called descriptive attributes.

 Cardinality
Cardinality describes the number of entities in one entity set, which can be associated with
the number of entities of other sets via relationship set.
Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at most one entity of entity
set B and vice versa. Let us assume that each student has only one student ID, and each
student ID is assigned to only one person. So, the relationship will be one to one.

Using Sets, it can be represented as:

2. One to many: When a single instance of an entity is associated with more than one
instances of another entity then it is called one to many relationships. For example, a client
can place many orders; a order cannot be placed by many customers.

Using Sets, it can be represented as:

3. Many to One: More than one entity from entity set A can be associated with at most one
entity of entity set B, however an entity from entity set B can be associated with more than
one entity from entity set A. For example - many students can study in a single college, but a
student cannot study in many colleges at the same time.

Using Sets, it can be represented as:

4. Many to Many: One entity from A can be associated with more than one entity from B
and vice-versa. For example, the student can be assigned to many projects, and a project can
be assigned to many students.

Using Sets, it can be represented as:

RESULT / E-R DIAGRAM: