MUFFAKHAM JAH COLLEGE

OF ENGINEERING &
TECHNOLOGY

I N F O R M AT I O N T E C H N O L O G Y

D E PA R T M E N T

PROJEC T HAND BOOK

2 0 2 2 - 23
Muffakham Jah College of Engineering and Technology (MJCET) was established in the year
1980 by Sultan-ul-uloom Education Society (SUES) which is formed by a group of visionaries
and intellectuals from various walks of life. Today that tiny acorn has developed into a mighty
oak. Today it is a premier institute, offering B.E Courses in 8 Branches (Civil, ECE, CSE,IT,
EEE,EIE, Mechanical & Production) and 5 M.E Courses (CAD/CAM, Structural Engg,
Digital systems, Computers & Power Electronics) of two years duration. The current intake of
all the B.E. Courses is 780 in addition to the 102 students in the M.E. Programmes. Research
Centers started in ECE Dept & Mech. Engg. For Doctral Studies. The college is affiliated to
the Osmania University, Hyderabad and approved by AICTE, New Delhi. We are applying for
Re-accreditation of NBA. As per survey of Out-Look Magazine, MJCET was ranked 48th
among top 100 Engg. Colleges of both Govt. and Private in India. The Week Magazine Ranked
50th among the Top 50 Pvt. Engg. colleges in India. MJCET is among the Top 5 Engg.
Colleges in Hyderabad and Top the list among Minority Engg. Colleges in the State.
 ABOUT THE IT DEPARTMENT

The department was established in the year 2000 with an initial intake of 60 to cater to the
needs of IT industry. The current student intake is 120. The curriculum of the BE (IT) 4-year
programme is framed as per the guidelines of Osmania University and the current Industry
requirements.
The department has 5 computer laboratories equipped with latest computer systems and
software meeting to the curriculum requirements along with separate Basic Electronics and
Microprocessor Lab, coupled with qualified teaching faculty and staff. The software in the
labs include Microsoft Products under Campus and School Agreement (CASA), Rational
Enterprise Suite (RES), Rational Software Architect (RSA), Macro Media Studio, WEKA
Data Mining Tool, KEIL Embedded System Software, MATLAB, C/C++/Java IDE, Operating
Systems (Linux, Windows etc), Net Beans IDE, Web Sphere, Tom Cat, Web Logic, Glass Fish
etc just to name a few.
In addition the College has an established Centre for Innovative Computing Lab with 60
seating capacity and latest All-in-One computer systems with Internet connection used for
conducting advanced certification courses viz. Microsoft Technology associate (MTA)
Certification under Microsoft IT Academy (MSITA), IIT-Bombay Workshops, etc..
Facilities like Internet access (30 Mbps), Digital library with access to online IEEE journals,
online database viz., MCGRAW HILL, SCIENCE DIRECT, KNIMBUS, SPRINGERLINK,
printed magazines (Digit, Chip) and journals, NPTEL lectures, etc are also provided.
 Abstract Preparation Guidelines
Definition

Abstracts must include sufficient information about the nature and significance of the topic, the
adequacy of the investigative strategy, the nature of the results, and the conclusions. The abstract
should summarize the substantive results of the work and not merely list topics to be discussed.

Abstract Content

 An abstract is an outline/brief summary of your paper and your whole project.

 It should have an introduction, body and conclusion.
 It highlights major points of the content and answers why this work is important, what was
your purpose, how you went about your project, what you learned, and what you concluded.
 It is a well-developed paragraph and should be exact in wording.
 It must be understandable to a wide audience.
 Do not include any charts, tables, figures, or spreadsheets in the abstract body.

Abstract Body Format

Abstracts should follow these guidelines:

 In Microsoft Word format

 Title should be in in Times New Roman font, size 16 and Bold
 Abstract Heading should be in Times New Roman font, size 14 and Bold
 Body of Abstract should be in Times New Roman font, size 12
 No more than 250 words in length
 1.5-spaced and a single paragraph

1
 Sample Format

Design and Construction of Microcontroller Based Electronic Code

Lock System with Extra Administration Password for Multiple Users
in Banks
Abstract
The issue of security is very paramount in any organization, especially such organization as a
bank. Therefore we intend to aid in security of the bank by bringing in an electronic code lock
system that involves an individual to enter a password before getting an access to some items, a
particular room or building. This code lock system is not just the normal single-user code lock
system that required a user to insert an already programmed code to gain access to a room or safe; it
is a code lock system that has an administrative password and enables multiple user access. By this,
we mean that there is room for more than a one user with different unique codes to access the same
safe or room. Also, with the kind of security code lock system we intend to implement, if for any
reason a user forgets his password, with the help of the administrator user, the user’s password can
be reset to a default password after which the user can change to a password of his choice. Lastly the
administrator has records of log of activities of a user accessing a safe or a room at a particular time
or whenever a user changes his password and this will further help the administrator to easily take
security measures. The use of microcontroller, keypad, LED display and some other electronic
devices coupled together will help in accomplishment of that. Here an individual have to enter a
password which must have been programmed in assembly language and this is read from the
microcontroller for clarification and verification. From this project, we hope to build an alternative
security system for banks.

Batch No. Name of The Roll No. Contact No. Email ID Signature
student

Project Guide Date:

2
 PROJECT ASSESSMENT GUIDELINES

COURSE OUTCOMES

On successful completion of the course, students will acquire the ability to:

1. Demonstrate an in-depth knowledge of one or more areas of Information Technology

and integration of knowledge gained through several courses, by developing veritable
solution to a complex problem. (Technical Content and Contribution)

2. Demonstrate the ability to produce a formatted report with proper layout, grammar,
spelling, cross-referencing of figures, tables and references to previous works. (Report
Writing)

3. Develop and present project plan making use of management tools like PERT, CPM,
and UML diagrams by dividing the project work into suitable packages and identify
resources for completion of the packages. (Project Planning)

4. Present results clearly making use of appropriate latest IT tools in the form of graphs,
tables, drawing or text, analyze the results and state appropriate conclusions. (Results)

5. Exhibit a sound knowledge of the problem, its solutions and results through detailed
presentation of the material and oral responses to the questions based on the work.
(University viva-voce Examination)

3
Fig. 1 Flowchart depicting the Comprehensive Project Evaluation System.

4
The Guidelines for the Comprehensive Project Evaluation System are as follows:
1. The Internal Project marks shall be awarded as per the curriculum in the scheme of instructions
provided by OU.

2. The internal marks of 50 are awarded in the following manner:

a. Project Report - Maximum Marks 25 (Awarded by Project Supervisor)
b. Project Reviews - Maximum Marks 25 (Awarded by Project Monitoring Committee)

The Project Reviews are conducted twice with the following weight age:
i. Project Review I - Maximum Marks 10
ii. Project Review II - Maximum Marks 15

3. The Project Reviews are conducted by the Project Monitoring Committee. The Project
Monitoring Committee will consist of the HOD, Project Coordinators, Project Supervisor and
some senior faculty as members.

4. Project Review I shall be conducted in the 13th-14th week of I semester and Project Review II
shall be conducted in the 10th-12th week of II semester.

5. Project Review I is evaluated for a score of 10 marks by the Project Monitoring Committee. The
rubric parameters of Project Review I are as follows:

a. Objective and Problem Statement - Maximum Score 10

b. Literature Survey - Maximum Score 10
c. Project Planning - Maximum Score 5

Total - Maximum Score 25

Scaled Total - Maximum Marks 10

“Project Review I Evaluation Form” must be used for recording the score of Project Review I.
6. Project Review II is evaluated for a score of 15 marks by the Project Monitoring Committee. The
rubric parameters of Project Review II are as follows:

a. Problem Formulation and Methodology - Maximum Score 10

b. Analysis - Maximum Score 10
c. Implementation/Design - Maximum Score 10

Total - Maximum Score 30

Scaled Total - Maximum Marks 15

“Project Review II Evaluation Form” must be used for recording the score of Project Review II.

7. Each Project report is evaluated by the project supervisor for a score of 100 by using Project
Report Assessment Rubric and then scaled to 25. The evaluation parameters are as follows:

a. Objective, Problem Statement and Methodology - Maximum Score 10

b. Analysis - Maximum Score 10
c. Implementation/Design - Maximum Score 20
d. Project Planning - Maximum Score 10

5
 e. Results/Drawing/Graphical artifact /Conclusion - Maximum Score 10
f. Project Report - Maximum Score 30
g. Project Diaries - Maximum Score 10

Total - Maximum Score 100

Scaled Total - Maximum Marks 25

The Project Report Assessment rubric is placed under Annexure I. The Literature Survey rubric
is placed under Annexure II and may be used in application based/ research oriented projects.

8. The final date of submission of Project Report shall be communicated by the HOD, which in no
case shall be beyond the last working day of the semester.

9. Failure to submit the written Project report on or before the date of submission will lead to loss of
30 points on the score of 100 points.

10. The project supervisor shall maintain a project diary for recording the regularity and progress of
the individual student. The “Project Diary Proforma” must be used for recording the details.

11. Project has 5 Course Outcomes, which are assessed by using the following parameters

 Course Outcome 1:
Objective, Problem Statement and Methodology - Maximum Score 10
Analysis - Maximum Score 10 40
Implementation/Design - Maximum Score 20

 Course Outcome 2:
Project Report - Maximum Score 30 30

 Course Outcome 3:
Project Planning - Maximum Score 10 10

 Course Outcome 4:
Results/Drawing/Graphical artifact/Conclusion - Maximum Score 10 10

 Course Outcome 5:
Presentation and Viva voce - Maximum Score 10 10

- Maximum Total Score 100

12. Course Outcomes 1 to 4 will be assessed based upon the score of Project Report Assessment.
Course outcome 5 will be assessed based upon the grades obtained in the end semester viva voce
exam. The rubric for assessment of Course Outcome 5 is placed in Annexure III.

13. The Course Outcome Assessment Matrix for project will be provided by the Program
Coordinator.

6
 ANNEXURE I
Project Report Assessment Rubric

Unacceptable Marginal Adequate Exceptional Max.

Score
Problem Does not Describes the Clearly Very clearly 10
Statement describe the practical describes the describes the
(Describes the practical application and practical practical
practical application and importance of application and application and
application and importance of the the problem in importance of importance of the
importance of the problem in concise the problem in problem in concise
problem) concise technical technical terms concise technical terms and
Project terms. and partially technical terms explicitly state the
Objective No objectives identifies the and identifies methodology with
(Describe what defined. methodology. the justification.
the project is Methodology not methodology.
trying to achieve.) identified
Methodology
(Approach or (0-2) (3-5) (6-8) (9-10)
technique or
formula used to
carry out a
project)
Analysis Incorrect Correct Correct Correct modeling 10
(Detailed modeling and no
modeling and modeling and and all appropriate
examination of appropriate some appropriate assumptions listed.
the structure of assumptions appropriate assumptions
the project) listed. assumptions listed.
listed.
(0-2) (3-5) (6-8) (9-10)
Project Planning No proper Average Good planning Good planning by 10
(Description of planning planning by by gathering the gathering the ideas
course outline, No gathering the ideas from from literature
Briefing of time communication. ideas from literature survey, survey, forming the
management, literature survey, forming the project team and
Selection of forming the project team and communicating the
Topics, Tools, project team and communicating progress
Methods and communicating the progress. effectively.
supervisor) the progress.
No Time Very good Time
management. Good Time management. Excellent Time
management. management.

(0-2) (3-5) (6-8) (9-10)

Implementation Design does not Design meets Design meets Design meets or 20
/Design meet desired desired desired exceeds desired
(Description of objectives. objectives to objectives. objectives.
course outline, some extent.
Briefing of time Poor Average Good Effective
management, implementation implementation implementation implementation of
Selection of of project. of project. of project. project.
Topics, Tools, (1-5) (6-10) (11-15) (16-20)

7
Methods and
supervisor)
Numerical No or erroneous Serious Sound Insightful 10
Results/ conclusions deficiencies in conclusions supported
Drawing/ based on support for reached based conclusion and
graphical achieved results. stated on achieve recommendations.
artifact conclusions. results.
/Conclusions (0-4) (5-7) (8-9) (10)
Project Report Maximum Marks 30
Project Report Work fails to Many deviations Report format is Report format is 10
(Report format is follow the from required generally consistent.
consistent required Report Report format. consistent.
throughout format.
including (0-4) (5-7) (8-9) 10
justification, Figures/ Graphs/ Figures/ Graphs/ Figures/ Graphs/ Figures/ Graphs/ 5
heading style, Illustrations/ Illustrations/ Illustrations/ Illustrations/ Tables
font, margins, Tables does not Tables are Tables are are properly
indentation, follow any properly properly formatted with
citations and formatting rules. formatted. formatted with suitable caption and
references.) Missing or suitable caption, appropriately cited.
irrelevant but not cited in
captions. the text.
Citation failed to Citation follows Citation are Citations are
follow required few required consistent with effectively
format or no format. the required consistent with the 10
citation provided. Major format required format. (use rubric
No referencing inconsistencies Minor References in
system used. in table inconsistencies comprehensive and Annexure
representation in table follow the required II if
and references representation format. desired)
formats. and references
formats.
(0-4) (5-7) (8-9) (10)
There are many There are few There are very There are no 5
grammatical grammatical few grammatical grammatical errors.
errors. errors. errors.
Diaries Not visits, no No Punctuality Less Punctuality Punctuality in visits 10
(Recording the progress. in visits and in visits and and planning
visits and the task planning planning. .Progress as per the
completed by the .Progress not as Progress as per timestamp.
student on some per the the timestamp.
timestamp) timestamp.
(0-2) (4-6) (7-8) (9-10)

8
 ANNEXURE II

Rubric for Literature survey/ background/ related work for Application based /
Research Oriented Project
Activity Unacceptable Marginal Adequate Exceptional Max
Scor
e
Resources* Single resource Limited Multiple Multiple
Referred is used for number of resources of resources of 5
review resources are acceptable exceptional
used for quality are quality are
review used for used for
review review
Usage of No conclusions There is some Conclusions Detailed 5
Background are made from indication of are reached conclusions
work the evidence conclusions from the are reached
cited. from the evidence from the
evidence cited. evidence
cited. cited.
Total (10)

*Resources:
In case of research based project, resources would mean articles/ research papers from journals,
conference proceedings, etc.
In case of application development project, resources would mean software systems/ case studies/
white papers, etc.

9
 ANNEXURE III
Student-wise Course Outcome 5 Attainment Rubric

O.U. Grade Unsatisfactory Satisfactory Good Very Good Excellent

Score 0.0 2.5 5.0 7.5 10.0

10
 Project Diary

Class: B.E IV/IV (A & B Section) Academic Year: 2022-2023

Project Title :
Domain :
Project Guide Name :
Platform :

Team Members:
S.no. Roll No. Name Mobile No. Signature

Project Synopsis (to be stated in few lines)

Visit Details
S.No. Date Activity Project Guide Project
Signature Coordinator
Sign.

11
 PROJECT REVIEW I
EVALUATION FORM
PROJECT TITLE: MAX MARKS: 10
ACADEMIC YEAR: DATE:

TEAM DETAILS
Project Guide
S. No ROLL NO. CANDIDATE NAME
(Name & Signature)

Roll No.
Evaluator S. Max
Rubric Parameter Score
No.
Reviewer 1
1 Objective and Problem Statement. 10

2 Literature Survey 10

3 Project Planning 5
Total 25
Reviewer 2 1 Objective and Problem Statement. 10

2 Literature Survey 10

3 Project Planning 5
Total 25
HOD 1 Objective and Problem Statement. 10
2 Literature Survey 10

3 Project Planning 5
Total 25
Scaled Average to 10

Reviewer 1 Reviewer 2 Head of the Department

12
 PROJECT REVIEW II
EVALUATION FORM
PROJECT TITLE: MAX MARKS: 15
ACADEMIC YEAR: DATE:

TEAM DETAILS
Project Guide
S. No ROLL NO. CANDIDATE NAME
(Name & Signature)

Roll No.
Evaluator S. Max
Rubric Parameter Scor
No.
Reviewer 1 Problem Formulation and
1 10
Methodology.
Problem Analysis /System or
2 10
Technical Design
3 Design / Implementation 10
Total 30
Reviewer 2 Problem formulation and Methodology
1 10
Literature survey
Problem Analysis /System or
2 10
Technical Design
3 Design / Implementation 10
Total 30
HOD Problem formulation and Methodology
1 10
Literature survey
Problem Analysis /System or
2 10
Technical Design
3 Design / Implementation 10
Total 30
Scaled Average to 15

Reviewer 1 Reviewer 2 Head of the Department

13
 Template & Guidelines for preparing the Project Report for B.E. 4/4
1. Cover page and Title Page refer ANNEXURE I
2. Certificate from College (on a letter head, signed by the Head , Int. and External
Guide ) Refer ANNEXURE 2
3. Certificate from the Company (Where the Project is done. e.g. TCS/WIPRO) / others
4. Declaration (Given by the Project team member’s which should not be
sentimental)
5. Acknowledgement (Given by the Project team member’s)
6. Abstract (One Page only). Abstract is the brief overview of the Project.
7. Contents (with page numbers)
8. List of Figures
9. List of Tables
10. The Complete Project Report should contain following sections
1. Introduction (2-3 pages)
2. Literature Survey Existing Different Approaches.(About 10-20 pages
and should be specific to your project.)
3. System Analysis
a. Problems with Existing System
b. Proposed System
c. Feasibility Study (Technical, Economical & Operational)
d. Effort, Duration and Cost Estimation using COCOMO, Function Point.
(Exhaustive theoretical description of COCOMO, Function Point should
be avoided)
e. Software Requirement Specification. Refer ANNEXURE 4
4. System Design
- System Architecture / Data Flow Diagrams/ Flow Charts or UML Diagrams
(All the diagrams should be drawn. The Diagrams should be well documented)
or If the project is Hardware related or on Embedded Systems, then the
circuit diagram etc. of hardware should also be included.
5. Implementation
It should contain all the modules in the Project and their complete description.
(The complete Source code should not be included. Important
Interfaces/classes/functions should only be included. In case, if the organization
does not permit you to take the source code outside, then the Pseudo code shall be
included. )
6. Testing
(Should show how the software is tested. You can include the test cases for Unit
& Black Box testing.)
Wrong practice: Students usually write about Unit Testing, Integration
Testing, Black Box Testing etc. i.e. they write about Testing Techniques in
Software Engineering!! This should not be done.
7. Screenshots: (This is the GUI of the System. You can include a few important
Screenshots with explanation.)
Conclusion (One Page) & Future Enhancements (One Page if required)
References Refer ANNEXURE 3
APPENDIX 1
APPENDIX 2

14
Brief Guidelines:
1. The project report should be neatly typed on one side and in A4 size paper only.
2. All the pages should be numbered and bottom centered
3. The general text should be typed with 1.5 line spacing and auto paragraph spacing.
Also there should not be any free spaces left unnecessarily in the entire project report.
4. The general text shall be justified and typed in the font style, Times New Roman and
font size-12. Giving unnecessary blank spaces to increase the size of project report is
strictly prohibited.
5. Chapter title should be typed in the font style, Times New Roman, center Aligned,
upper case, and font size-16 and bold.
Ex:
1. INTRODUCTION
6. Headings should be typed in the font style, Times New Roman, left aligned and font
size-14 and bold.
Ex:
1.1 Scope of the Project
7. Sub- Headings should be typed in the font style, Times New Roman, left aligned and
font size- 12 and bold.
Ex:
1.1.1 Types of networks
8. All the remaining content should be typed in the font style, Times New Roman,
Justified and font size- 12. Each paragraph should start with a tab space.
9. Every chapter must start with new page. Every Figure and Table should have
serial number. Ex: Fig: 1.1, 1.2 etc, where the first digit represents the chapter, the
second digit represents the figure number/table number. All figures and tables should
be center aligned including figure/table number.
10. The project execution should be shown to the internal guide before the submission.
11. The students are requested to show the draft copy of the Project Report to Head /
Concerned Internal guide before printing.
12. The Internal Guide followed by the Head shall sign the Project report.
13. The students are advised to report to their respective internal guides immediately.

15
 ANNEXURE 1

PROJECT TITLE

Project Report Submitted

In Partial Fulfillment of the Requirements

For the Degree of

BACHELOR OF ENGINEERING

IN

INFORMATION TECHNOLOGY

Submitted By

XXXXXXXXXX (1604-16-737-001)
XXXXXXXXXX (1604-16-737-002)
XXXXXXXXXX (1604-16-737-003)

INFORMATION TECHNOLOGY DEPARTMENT

MUFFAKHAM JAH COLLEGE OF ENGINEERING &
TECHNOLOGY
(Affiliated to Osmania University)
Mount Pleasant, 8-2-249, Road No. 3, Banjara Hills, Hyderabad-34
2022-23
 ANNEXURE 2

CERTIFICATE

It is certified that the work contained in the project report titled “XXXXXXXXX
XXXXXXX XXXXXXXXXXXXXX,” by

Mr. XXXXXXXXXX (1604-15-737-0XX)

Ms. XXXXXXXXXX (1604-15-737-0XX)
Ms. XXXXXXXXXX (1604-15-737-0XX)

has been carried out under my/our supervision and that this work has not been submitted
elsewhere for a degree”

Project Supervisor Signature of Head

Mr. XXXXXXXXXX Dr. MOUSMI AJAY CHAURASIA
Information Technology Dept. Information Technology Dept.
MJ College of Engineering & Tech. MJ College of Engineering & Tech.
Hyderabad – 500 034. Hyderabad – 500 034

External Examiner
 ANNEXURE III

IEEE Citation Style Guide

Any citation style is set up to give the reader immediate information about sources cited
in the text. In IEEE citations, the references should be numbered and appear in the order
they appear in the text. When referring to a reference in the text of the document, put the
number of the reference in square brackets. Eg: [1]

The IEEE citation style has 3 main features:

 The author name is first name (or initial) and last. This differs from MLA style where
author’s last name is first.
 The title of an article (or chapter, conference paper, patent etc.) is in quotation marks.
 The title of the journal or book is in italics.

These conventions allow the reader to distinguish between types of reference at a glance.
The correct placement of periods, commas and colons and of date and page numbers
depends on the type of reference cited. Check the examples below. Follow the details
exactly. Eg.: put periods after author and book title, cite page numbers as pp., abbreviate
all months to the first three letters (eg. Jun.)

Check the distinctions between print and electronic sources (especially for journals)
carefully.

Print References
Book
Author(s). Book title. Location: Publishing company, year, pp.
Example:
W.K. Chen. Linear Networks and Systems. Belmont, CA: Wadsworth, 1993, pp. 123-35.

Book Chapters
Author(s). “Chapter title” in Book title, edition, volume. Editors name, Ed. Publishing
location: Publishing company, year, pp.
Example:
J.E. Bourne. “Synthetic structure of industrial plastics,” in Plastics, 2nd ed., vol. 3. J.
Peters, Ed. New York: McGraw-Hill, 1964, pp.15-67.

Article in a Journal
Author(s). “Article title”. Journal title, vol., pp, date.
Example:
G. Pevere. “Infrared Nation.” The International Journal of Infrared Design, vol. 33, pp.
56-99, Jan. 1979.

Articles from Conference Proceedings (published)

Author(s). “Article title.” Conference proceedings, year, pp.
Example:
D.B. Payne and H.G. Gunhold. “Digital sundials and broadband technology,” in Proc.
IOOC-ECOC, 1986, pp. 557-998.
Papers Presented at Conferences (unpublished)
Author(s). “Paper’s title,” Conference name, Location, year.
Example:
B. Brandli and M. Dick. “Engineering names and concepts,” presented at the 2nd Int.
Conf. Engineering Education, Frankfurt, Germany, 1999.

Standards/Patents
Author(s)/Inventor(s). “Name/Title.” Country where patent is registered. Patent number,
date.
Example:
E.E. Rebecca. “Alternating current fed power supply.” U.S. Patent 7 897 777, Nov. 3,
1987.

Electronic References
Books
Author. (year, Month day). Book title. (edition). [Type of medium]. Vol. (issue).
Available: site/path/file [date accessed].
Example:
S. Calmer. (1999, June 1). Engineering and Art. (2nd edition). [On-line]. 27(3). Available:
www.enggart.com/examples/students.html [May 21, 2003].

Journal
Author. (year, month). “Article title.” Journal title. [Type of medium]. Vol. (issue),
pages. Available: site/path/file [date accessed].
Example:
A. Paul. (1987, Oct.). “Electrical properties of flying machines.” Flying Machines. [On-
line]. 38(1), pp. 778-998. Available: www.flyingmachjourn/properties/fly.edu [Dec. 1,
2003].

World Wide Web

Author(s)*. “Title.” Internet: complete URL, date updated* [date accessed].
M. Duncan. “Engineering Concepts on Ice. Internet: www.iceengg.edu/staff.html, Oct.
25, 2000 [Nov. 29, 2003].

Odd Sources
Newspaper
Author(s)*. “Article title.” Newspaper (month, year), section, pages.
Examples:
B. Bart. “Going Faster.” Globe and Mail (Oct. 14, 2002), sec. A p.1.
“Telehealth in Alberta.” Toronto Star (Nov. 12, 2003), sec. G pp. 1-3.
Dissertations and Theses
Author. “Title.” Degree level, school, location, year.
Example:
S. Mack. “Desperate Optimism.” M.A. thesis, University of Calgary, Canada, 2000.

Lecture
Lecturer(s). Occasion, Topic: “Lecture title.” Location, date.
Example:
S. Maw. Engg 251. Class Lecture, Topic: “Speed skating.” ICT 224, Faculty of
Engineering, University of Calgary, Calgary, Alberta, Oct. 31, 2003.

E-mail
Author. Subject line of posting. Personal E-mail (date).
Example:
J. Aston. “RE: new location, okay?” Personal e-mail (Jul. 3, 2003).

Internet - Newsgroup
Author or Topic*, “Title,” Complete network address, date when it was updated [date
accessed].
Example:
G.G. Gavin. “Climbing and limb torsion #3387,” USENET: sci.climb.torsion, Apr. 19,
2000 [Oct. 4, 2002].

* if you can’t find this information, exclude it.

Exact page number References

To refer readers to specific page numbers in a text, use the number of the reference
followed by a colon (:) and the page numbers.
Example:
Johnson suggests that citing will lead to a decrease in being cited for plagiarism [1:28-
29].

The [1] refers to the numbered reference

And the 28-29 refers to the pages being cited.
ANNEXURE IV Page 1

Software Requirements Specification

Revision History

Name Date Reason For Changes Version

1. Introduction

1.1 Purpose

<Identify the product whose software requirements are specified in this document, including the
revision or release number. Describe the scope of the product that is covered by this SRS,
particularly if this SRS describes only part of the system or a single subsystem.>

1.2 Scope

<Provide a short description of the software being specified and its purpose, including relevant
benefits, objectives, and goals. Relate the software to corporate goals or business strategies. If a
separate vision and scope document is available, refer to it rather than duplicating its contents
here.>

2. Overall Description

2.1 Product Perspective

<A simple diagram that shows the major components of the overall system, subsystem
interconnections, and external interfaces can be helpful.>
ANNEXURE IV Page 2

2.2 Product Functions

<Summarize the major functions the product must perform or must let the user perform. Details will
be provided in Section 3, so only a high level summary (such as a bullet list) is needed here.
Organize the functions to make them understandable to any reader of the SRS. A picture of the
major groups of related requirements and how they relate, such as a top level data flow diagram or
object class diagram, is often effective.>

2.3 User Classes and Characteristics

<Identify the various user classes that you anticipate will use this product. User classes may be
differentiated based on frequency of use, subset of product functions used, technical expertise,
security or privilege levels, educational level, or experience. Describe the pertinent characteristics
of each user class. Certain requirements may pertain only to certain user classes. Distinguish the
most important user classes for this product from those who are less important to satisfy.>

2.4 Operating Environment

<Describe the environment in which the software will operate, including the hardware platform,
operating system and versions, and any other software components or applications with which it
must peacefully coexist.>

3. External Interface Requirements

3.1 User Interfaces

<Describe the logical characteristics of each interface between the software product and the users.
This may include sample screen images, any GUI standards or product family style guides that are
to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will
appear on every screen, keyboard shortcuts, error message display standards, and so on. Define the
software components for which a user interface is needed. Details of the user interface design
should be documented in a separate user interface specification.>
ANNEXURE IV Page 3

3.2 Hardware Interfaces (If Applicable)

<Describe the logical and physical characteristics of each interface between the software product
and the hardware components of the system. This may include the supported device types, the
nature of the data and control interactions between the software and the hardware, and
communication protocols to be used.>

3.3 Software Interfaces (If Applicable)

<Describe the connections between this product and other specific software components (name and
version), including databases, operating systems, tools, libraries, and integrated commercial
components. Identify the data items or messages coming into the system and going out and describe
the purpose of each. Describe the services needed and the nature of communications. Refer to
documents that describe detailed application programming interface protocols. Identify data that
will be shared across software components. If the data sharing mechanism must be implemented in
a specific way (for example, use of a global data area in a multitasking operating system), specify
this as an implementation constraint.>

3.4 Communications Interfaces (If Applicable)

<Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication standards
that will be used, such as FTP or HTTP. Specify any communication security or encryption issues,
data transfer rates, and synchronization mechanisms.>

4. System Features
<This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section by use
case, mode of operation, user class, object class, functional hierarchy, or combinations of these,
whatever makes the most logical sense for your product.>
ANNEXURE IV Page 4

4.1 System Feature 1

<Don’t really say “System Feature 1.” State the feature name in just a few words.>

4.1.1 Description and Priority

<Provide a short description of the feature and indicate whether it is of High,

Medium, or Low priority. You could also include specific priority component ratings,
such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1
to a high of 9).>

4.1.2 Stimulus/Response Sequences

<List the sequences of user actions and system responses that stimulate the behavior
defined for this feature. These will correspond to the dialog elements associated with
use cases.>

4.1.3 Functional Requirements

<Itemize the detailed functional requirements associated with this feature. These are
the software capabilities that must be present in order for the user to carry out the
services provided by the feature, or to execute the use case. Include how the product
should respond to anticipated error conditions or invalid inputs. Requirements should
be concise, complete, unambiguous, verifiable, and necessary. Use “TBD” as a
placeholder to indicate when necessary information is not yet available.>

<Each requirement should be uniquely identified with a sequence number or a

meaningful tag of some kind.>

REQ-1:

REQ-2:
ANNEXURE IV Page 5

4.2 System Feature 2 (and so on)

5. Other Nonfunctional Requirements

5.1 Performance Requirements

<If there are performance requirements for the product under various circumstances, state them here and
explain their rationale, to help the developers understand the intent and make suitable design choices.
Specify the timing relationships for real time systems. Make such requirements as specific as possible. You
may need to state performance requirements for individual functional requirements or features.>

5.2 Safety Requirements (If Applicable)

<Specify those requirements that are concerned with possible loss, damage, or harm that could result from
the use of the product. Define any safeguards or actions that must be taken, as well as actions that must be
prevented. Refer to any external policies or regulations that state safety issues that affect the product’s
design or use. Define any safety certifications that must be satisfied.>

5.3 Security Requirements (If Applicable)

<Specify any requirements regarding security or privacy issues surrounding use of the product or
protection of the data used or created by the product. Define any user identity authentication requirements.
Refer to any external policies or regulations containing security issues that affect the product. Define any
security or privacy certifications that must be satisfied.>

5.4 Software Quality Attributes (If Applicable)

<Specify any additional quality characteristics for the product that will be important to either the customers
or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability,
maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be
specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various
attributes, such as ease of use over ease of learning.>
 APPENDIX 1

RELEVANCE OF PROJECT TO POs / PSOs

A greedy Algorithm for reduced cost data aggregation among

Title of Project
multiple applications in a wireless sensor networks
Implementation
NS2 simulator
Details
Cost (hardware or
-NA-
software cost)
Type (Application,
Product, Research, APPLICATION
Review, etc.)

Mapping with POs and PSOs with Justification

PO PO PO PO PO PO PO PO PO PO PO PO PSO PSO
Relevance 1 2 3 4 5 6 7 8 9 10 11 12 1 2
1 2 3 3 2 1 1 1 2 3 - 2 1 1
PO1: Engineering Knowledge: SDLC phases are followed in the execution
of the project.
PO2: Problem Analysis: The different steps involved in Problem Analysis
for formulation of the solution i.e. literature survey and use of fundamental
subject knowledge has been followed.
PO3: Design/Development of solutions – Existing strategy has been
enhanced using the design principles.
Program
PO5: Modern Tool Usage: NS2 is used.
Outcomes
PO8: Ethics: Students have followed professional ethics during the various
Justification
stages of Project completion.
PO9: Individual and Team Work: Students have worked both in individual
as well as team capacity during the various stages of project work.
PO10: Communication: Effective communication with team members and
during project reviews, project seminar and viva-voce has been exhibited.
PO12: Lifelong Learning. The project carried out gives the students scope
to continue the work in the WSN area in future.
Program
Specific PSO1: Use of open source software. NS2
Outcomes PSO2: Use of Rational Software Architect is during analysis and testing.
Justification
 APPENDIX 2

GANTT CHART

Health Care System by Unification of IOT Data and Analytics

% Complete
PROJECT PLAN Period Highlight: 1 Plan Duration Actual Start % Complete Actual (beyond plan) (beyond plan)
PLAN ACTUAL
PLAN START ACTUAL PERCENT
DURATION DURATION
ACTIVITY (WEEK NO.) START (WEEK COMPLETE PERIODS
(NO. OF (NO. OF
WEEKS) NO.) WEEKS) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Problem
1 2 1 3 100%
Definition
Abstract 3 1 3 1 100%
Literature
3 8 3 9 100%
Survey
System Analysis 9 5 9 6 100%

REVIEW I 16 1 16 1 100%

System Design 17 2 17 3 100%

Implementation 19 10 19 12 100%

Testing 30 2 30 2 100%

Documentation 3 32 6 29 100%

REVIEW II 32 1 32 1 100%