PRACTICAL -1

AIM: To prepare PROBLEM STATEMENT for smart attendance system.

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.
Software Interfaces
 Any window-based operating system (Windows XP/NT/7/8/10)
 WordPad or Microsoft Word
THEORY:
 We know that every time you upload a photo to Facebook, the
platform uses facial recognition algorithms to identify the
people in that image, Or that certain governments around the
world use face recognition technology to identify and catch
criminals, and also we can now unlock smartphones with your
face.
 The applications of this sub-domain of computer vision are vast
and businesses around the world are already reaping the
benefits. The usage of face recognition models is only going to
increase in the next few years.
 In this project, we are going to do just that. We will first
understand the inner workings of face recognition, and then
take a simple case study and implement it in Python.
 PRACTICAL - 2
AIM: Understanding an SRS.
THEORY:
An SRS is basically an organization's understanding (in writing) of a
customer or potential client's system requirements and
dependencies at a particular point in time (usually) prior to any
actual design or development work. It's a two-way insurance policy
that assures that both the client and the organization understand the
other's requirements from that perspective at a given point in time.

The SRS document itself states in precise and explicit language those
functions and capabilities a software system (i.e., a software
application, an eCommerce Web site, and so on) must provide, as
well as states any required constraints by which the system must
abide. The SRS also functions as a blueprint for completing a project
with as little cost growth as possible. The SRS is often referred to as
the "parent" document because all subsequent project management
documents, such as design specifications, statements of work,
software architecture specifications, testing and validation plans, and
documentation plans, are related to it.

It's important to note that an SRS contains functional and

nonfunctional requirements only; it doesn't offer design suggestions,
possible solutions to technology or business issues, or any other
information other than what the development team understands the
customer's system requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

  It provides feedback to the customer. An SRS is the customer's
assurance that the development organization understands the
issues or problems to be solved and the software behavior
necessary to address those problems. Therefore, the SRS should
be written in natural language (versus a formal language,
explained later in this article), in an unambiguous manner that
may also include charts, tables, data flow diagrams, decision
tables, and so on.
 It decomposes the problem into component parts. The simple
act of writing down software requirements in a well-designed
format organizes information, places borders around the
problem, solidifies ideas, and helps break down the problem
into its component parts in an orderly fashion.
 It serves as an input to the design specification. As mentioned
previously, the SRS serves as the parent document to
subsequent documents, such as the software design
specification and statement of work. Therefore, the SRS must
contain sufficient detail in the functional system requirements
so that a design solution can be devised.
 It serves as a product validation check. The SRS also serves as
the parent document for testing and validation strategies that
will be applied to the requirements for verification.
SRSs are typically developed during the first stages of "Requirements
Development," which is the initial product development phase in
which information is gathered about what requirements are needed--
and not. This information-gathering stage can include onsite visits,
questionnaires, surveys, interviews, and perhaps a return-on-
investment (ROI) analysis or needs analysis of the customer or
client's current business environment. The actual specification, then,
is written after the requirements have been gathered and analyzed.
Chracteristics of a good SRS An SRS should be
a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable
Correct - This is like motherhood and apple pie. Of course you want
the specification to be correct. No one writes a specification that
they know is incorrect. We like to say - "Correct and Ever Correcting."
The discipline is keeping the specification up to date when you find
things that are not correct.
Unambiguous - An SRS is unambiguous if, and only if, every
requirement stated therein has only one interpretation. Again, easier
said than done. Spending time on this area prior to releasing the SRS
can be a waste of time. But as you find ambiguities - fix them.
Complete - A simple judge of this is that is should be all that is
needed by the software designers to create the software.
Consistent - The SRS should be consistent within itself and consistent
to its reference documents. If you call an input "Start and Stop" in
one place, don't call it "Start/Stop" in another.
Ranked for Importance - Very often a new system has requirements
that are really marketing wish lists. Some may not be achievable. It is
useful provide this information in the SRS.
Verifiable - Don't put in requirements like - "It should provide the
user a fast response." Another of my favorites is - "The system should
never crash." Instead, provide a quantitative requirement like: "Every
key stroke should provide a user response within 100 milliseconds."
Modifiable - Having the same requirement in more than one place
may not be wrong - but tends to make the document not
maintainable.
Traceable - Often, this is not important in a non-politicized
environment. However, in most organizations, it is sometimes useful
to connect the requirements in the SRS to a higher level document.
Why do we need this requirement?

REQUIREMENTS:
 SOFTWARE REQUIREMENT
 Operating system : Windows 10
 PyCharm Community Edition
 Packages
 cmake
 dlib
 face-recognition
 numpy
 opencv-python

 HARDWARE REQUREMENT
 Pen Drive
 Web camera
 Processor: Intel or AMD Quad core Processor
 Ram: 2GB or more than 2GB
 Hard disk: 15 GB of available space
 EXCERCISE NO. 3
AIM: To prepare DATA FLOW DIAGRAM for smart attendance system.
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,
Software Interfaces
 Any window-based operating system (Windows 7 ,8 and 10)
 WordPad or Microsoft Word.
Description: Data flow diagram is graphical representation of flow of
data in an information system. It is capable of depicting incoming
data flow, outgoing data flow and stored data. The DFD does not
mention anything about how data flows through the system.
There is a Noticeable difference between DFD and Flowchart. The
flowchart depicts flow of control in program modules. DFDs depict
flow of data in the system at various levels. DFD does not contain any
control or branch elements.
Components:
External Entity an outside system that sends or receives data,
communicating with the system being diagrammed. They are the
sources and destinations of information entering or leaving the
system. They might be an outside organization or person, a computer
system or a business system. They are also known as terminators,
sources and sinks or actors. They are typically drawn on the edges of
the diagram .

Process any process that changes the data, producing an output. It

might perform computations, or sort data based on logic, or direct
the data flow based on business rules. A short label is used to
describe the process, such as “Submit payment”.
Data store files or repositories that hold information for later use,
such as a database table or a membership form. Each data store

receives a simple label, such as “Orders.”

Data flow the route that data takes between the external entities,
processes and data stores. It portrays the interface between the
other components and is shown with arrows, typically labeled with a
short data name, like “Billing details.”

DFD rules
 Each process should have at least one input and an output.
 Each data store should have at least one data flow in and one
data flow out.
 Data stored in a system must go through a process.
 All processes in a DFD go to another process or a data store.

DATA FLOW DIAGRAM for smart attendance system

 EXCERCISE NO. 4
AIM: To perform the user’s view analysis for the sugeested system:
Use case Diagram

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,
Software Interfaces
 Any window-based operating system (Windows 7 ,8 and 10)
 WordPad or Microsoft Word.

1. Use Cases
2. Actor
3. Relationship
4. System Boundary Boxes

i. Use Cases
A use describe a sequnece of action 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 od the
diagram.
4. Imply timing Considerations By Sta