1

** SOFTWARE ENGINEERING **

Software engineering is the application of engineering to the development of software in

a systematic method.

Software engineering is a field of engineering for designing and writing programs

for computers or other electronic devices.

Typical formal definitions of Software Engineering are:-

 "Research, design, develop, and test operating systems-level
software, compilers, and network distribution software for medical, industrial,
military, communications, aerospace, business, scientific, and general computing
applications."
 "The systematic application of scientific and technological knowledge, methods,
and experience to the design, implementation, testing, and documentation of
software".
 "The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software".
 "An engineering discipline that is concerned with all aspects of software production".
 And "the establishment and use of sound engineering principles in order to
economically obtain software that is reliable and works efficiently on real
machines."
 3

** PHASES OF SOFTWARE DEVELOPMENT **

 Requirement gathering and analysis.

 Design.
 Implementation or coding.
 Testing.
 Deployment.
 Maintenance.

There are various software development approaches defined and designed which are
used/employed during development process of software, these approaches are also
referred as “Software Development Process Models” (e.g. Waterfall model, incremental
model, V-model, iterative model, RAD model, Agile model, Spiral model, Prototype
model etc.). Each process model follows a particular life cycle in order to ensure
success in process of software development.

Software life cycle models describe phases of the software cycle and the order in which
those phases are executed. Each phase produces deliverables required by the next
phase in the life cycle. Requirements are translated into design. Code is produced
according to the design which is called development phase. After coding and
development the testing verifies the deliverable of the implementation phase against
requirements. The testing team follows Software Testing Life Cycle (STLC) which
is similar to the development cycle followed by the development team.

1) Requirement gathering and analysis:  Business requirements are gathered in

this phase. This phase is the main focus of the project managers and stake
holders. Meetings with managers, stake holders and users are held in order to
determine the requirements like Who is going to use the system? How will they use the
system?  What data should be input into the system?  What data should be output by
the system?  These are general questions that get answered during a requirements
gathering phase. After requirement gathering these requirements are analysed for their
validity and the possibility of incorporating the requirements in the system to be
development is also studied.

Finally, a Requirement Specification document is created which serves the purpose of

guideline for the next phase of the model. The testing team follows the Software Testing
Life Cycle and starts the Test Planning phase after the requirements analysis is
completed.
 4

2)  Design:  In this phase the system and software design is prepared from the
requirement specifications which were studied in the first phase. System Design helps
in specifying hardware and system requirements and also helps in defining overall
system architecture. The system design specifications serve as input for the next phase
of the model.In this phase the testers comes up with the Test strategy, where they
mention what to test, how to test.

3)  Implementation / Coding:  On receiving system design documents, the work is

divided in modules/units and actual coding is started. Since, in this phase the code is
produced so it is the main focus for the developer. This is the longest phase of the
software development life cycle.

4)  Testing:  After the code is developed it is tested against the requirements to make
sure that the product is actually solving the needs addressed and gathered during the
requirements phase. During this phase all types of functional testing like unit
testing, integration testing, system testing, acceptance testing are done as well as non-
functional testing are also done.

5)  Deployment: After successful testing the product is delivered / deployed to the

customer for their use. As soon as the product is given to the customers they will first do
the beta testing. If any changes are required or if any bugs are caught, then they will
report it to the engineering team. Once those changes are made or the bugs are fixed
then the final deployment will happen.

6) Maintenance: Once when the customers start using the developed system then
the actual problems come up and needs to be solved from time to time. This process
where the care is taken for the developed product is known as maintenance.
 5

** WATER FALL MODEL **

It is also referred to as a linear-sequential life cycle model. It is very simple to

understand and use. In a waterfall model, each phase must be completed before the
next phase can begin and there is no overlapping in the phases.
Waterfall model is the earliest SDLC approach that was used for software development.
 6

** PROBLEM STATEMENT **
This application aims to allow user to specify his/her symptoms about body problem and
get the desired advice about curing the diseases, through a platform that produces
prescription of the medicines with the click of a button, and simultaneously keeps track .
 All Work are done manually.
 To give proper treatment to user.
 To provide easy treatment
 To provide facility to use easily.

** DESCRIPTION **
 To Create Web Based Application For our Organization.
 To Provide Search Facility For Customer.
 To Generate Different Types of prescription.
 To provide the online prescription and medicine search facility for customer.
 To provide medicinal Details.

** SOFTWARE REQUIREMENTS **

 Operating System: Windows 2000 and above

 Runtime Environment: .NET Framework 4.0
 Web Server: 000Webhost
 Front End HTML
 Back End PHP and MySQL
 Other Tools M S Office, CSS, and Bootstrap
 7

** CLASS DIAGRAM **
 8

** DATA FLOW DIAGRAM **

 9

** DATA DICTIONARY **

Table Name: Customer

Description: To store User Personal Information.
Primary Key: UserID

Sr. No. Field Name Type Description

1 UserID Integer(10) Used to identify user uniquely
2 UserName Varchar(30) Username for logging in
3 Password Varchar(30) Password for username
4 Address Varchar(50) Physical address of user
5 Email Varchar(20) Email of user
6 Phone Integer(10) User phone number
7 symptoms Varchar(100) Enter symptoms

Table Name: Admin

Description: To store ADMIN information.
Primary Key: UserName

Sr. No. Field Name Type Description

1 UserName Varchar(40) Used to Login
2 Password Varchar(40) Password for UserName
 10
** SOFTWARE REQUIREMENT SPECIFICATION **

Table of Contents

1. Introduction...............................................................................................................10
1.1 Purpose 10
1.2 Scope 10
1.3 Definitions, Acronyms, and Abbreviations 10
1.4 References 10
1.5 Overview 10
2. Overall Description..................................................................................................11
2.1 Product Perspective 11
2.2 Product Functions 11
2.3 User Classes and Characteristics 11
2.4 General Constraints 11
2.5 Assumptions and Dependencies 11
3. External Interface Requirements............................................................................12
3.1 User Interfaces 12
3.2 Hardware Interfaces 12
3.3 Software Interfaces 12
3.4 Communications Interfaces 12
4. Functional Requirements........................................................................................13
5. Nonfunctional Requirements..................................................................................15
6.1 Performance Requirements 15
6.2 Safety Requirements 15
6.3 Security Requirements 15
6.4 Software Quality Attributes 15
7. Other Requirements.................................................................................................16
8. Design of Software ……………………………………………………………………20
9. Coding of Software……………………………………………………………………21
10. Testing of Software…………………………………………………………………….22
11. Risk,Reliabiliity,Fault Maintainance………………………………………………….23
12. Study of Star UML and its Advantages and Disadvantages……………………..24
 11

INTRODUCTION
1.1 PURPOSE

To create a website that enables the customers to enter symptoms and get prescription
according to symptom.
1.2 SCOPE
Each customer has to enter symptoms and get prescription from our lifeline customer
Can choose treatment according to his problem
1.3 DEFINITIONS and ACRONYMS and ABBREVIATIONS
 GB- Gigabyte- 230 Bytes
 GHz- Giga-Hertz
 MB – Megabyte- 220 Bytes
 MySQL- Structural Query Language used in managing the database required
 MS Office- Microsoft Office (Word, PowerPoint, etc.)
 RAM- Random Access Memory
 HTML- Hyper Text Markup Language- used for making websites
 CSS- Cascading Style Sheets- used for adding extra stylish looks to website
 PHP- Personal Home Page Hypertext Preprocessor- server side scripting
language
 Bootstrap- used for stylizing website

1.4 REFERENCES

http://www.medicinenet.com
https://sites.google.com

1.5 OVERVIEW

The rest of the SRS examines the specifications of the lifeline in detail. Section 2 of the
SRS presents the general factors that affect the system and its requirements, such as
user characteristics and project constraints. Section 3 outlines the detailed, specific
functional, performance, system and other related requirements of the software.
Supporting information about appendices is provided in Section 3.
 12

OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

The lifeline medical health system runs on most supported browser. The system is
responsible for planning the prescription for the customer .There will be various
prescription that user can select from. The details of various interfaces have been
provided in Section 3.1
2.2 PRODUCT FUNCTION
 VIEW MEDICINE
 SEARCH MEDICINE
 PRODUCE ONLINE PRESCRIPTION
 FEEDBACK
 LOGIN
 REGISTER
 ADMIN LOGIN

2.3 USER CLASSES and CHARACTERISTICS

 USER
o ADMIN
o CUSTOMER
 PRESCRIPTION
 INFORMATION
 MEDICIENE
 DATABASE
o DISEASES
o MEDICINE
 FEEDBACK

2.4 DESIGN and IMPLEMENTATION CONSTRAINTS.

 To Create Web Based Application For our Organization.

 To Provide Search Facility For Customer.
 To Generate Different Types of Reports.
 To provide the online prescription and symptoms Facility for Customer.
 To provide prescription Details.

2.5 ASSUMPTIONS and DEPENDENCIES

The use of XAMPP is very important in order to make the database connected to the
website.
 13

SPECIFIC REQUIREMENTS

3.1 EXTERNAL INTERFACE REQUIREMENTS

3.1.1 USER INTERFACES

Admin: - admin can see detail of customer and feedback.
Customer: - customer can view prescription
Visitor: - Visitor view site and give feedback.

3.1.2 HARDWARE INTERFACES

 Server Side:
o Processor 2.0 GHz
o RAM 2 GB
o Hard Disk 20 GB Free space

 Client Side:
o Processor 1.0 GHz
o RAM 256 MB
o Hard Disk 1 GB Free space

3.1.3 SOFTWARE INTERFACES

 Server Side:
o Operating System: Windows 2000 and above
o Runtime Environment: .NET Framework 4.0
o Web Server: 000Webhost
o Front End HTML
o Back End PHP and MySQL
o Other Tools M S Office, CSS, and Bootstrap
 Client Side:
o Operating System: Any OS with a browser
o Web Browser: Any compatible browser

3.1.4 COMMUNICATION INTERFACES

So far, the website is not connected to a domain. Webhost will be used for hosting a
server and using a public domain or URL.
 14

3.2 FUNCTIONAL REQUIREMENTS

3.2.1 REGISTRATION
 Description- It is used when a user is new to the website and he needs to create
a new account in our database.
 Inputs-
o Username
o Email
o Phone Number
o Password
o Symptoms.
 Outputs-
o Generates Prescription.

3.2.2 VIEW
 Description- The user can query his problems and can get corresponding
medicine and treatment.
 Inputs-
o Symptoms
 Process- It fetches all the medicine and required treatment for the disease.
 Outputs-
o Generation of prescription.

3.2.3 LOGIN
 Description- The admins having an account can login using this.
 Inputs:
o Username
o Password
 Process- The username and password must match with the admin username
and password.
 Outputs-
o Logged In

3.2.4 OUTPUT
 Description - When customer enters a symptom, then he gets detailed medicinal
information and treatment in the form of prescription.
 Inputs:
o Symptoms
o Body area
 Process- A Prescription will generate when function is executed.
 Outputs-
o Online Prescription.

3.2.5 UPDATE
 Description- This lets the administrator view all the customers who have logged
in the site and the respective treatment received by them and also the reviews
given in the form of feedback.
 Inputs:
o Username
o Password
 Process-It fetches all the database from the User database and review and
displays it on screen.
 Outputs- The reviews and treatment will be on display for users.
 15

OTHER NONFUNCTIONAL REQUIREMENTS

4.1 PERFORMANCE REQUIREMENTS

This subsection specifies numerical requirements placed on the software or on the

human interaction with the software, as a whole.
Numerical requirements will include:
 300 terminals will be supported at a time
 Only text information will be supported(HTTP)
 All the transactions will be processed within seconds.

4.2 SAFETY REQUIREMENTS

Only registered users will be able to access the website by entering the correct login
name and corresponding password.

4.3 SECURITY REQUIREMENTS

Only the accessed members with individual password are allowed to access the site.
Passwords and the user id’s used to perform the payment transactions are kept in much
safe. Everything is accessed and observed by admin group thoroughly to keep the
customer details safely.

4.4 SOFTWARE QUALITY ATTRIBUTES

 Security: Only registered users will be able to access the website by entering the
correct login name and corresponding password.

 Maintainability: The website can be maintained in present or future. It will be easy

to incorporate new requirements in the individual modules.

 Portability: As the website is online so will be easily portable on various systems.

OTHER REQUIREMENTS

SITE ADAPTATION REQUIREMENTS:-

Web Browser with Cookies Enabled.
 16

** DESIGN OF SOFTWARE **

FRONT-PAGE

MAIN-PAGE
 17

REGISTRATION-PAGE

PRESCRIPTION-PAGE
 18

** CODING OF SOFTWARE **

DATA BASE CONNECTIVITY

<?php
require 'Review.php';
$servername = "localhost";
$username = "root";
$password = null;

// Create connection
$conn = mysqli_connect($servername, $username, $password);

// Check connection
if (!$conn)
die("Connection failed: " . mysqli_connect_error());

mysqli_select_db($conn,"reviews");

$sql = "INSERT INTO user_info(name,age,email,phone_number,gender,comments)

VALUES('$_POST[name]','$_POST[age]','$_POST[email]','$_POST[mobile]','$_POST[g
ender]','$_POST[comment]')";

if (mysqli_query($conn, $sql))echo("THANK YOU");

else
echo "Error: " . $sql . "<br>" . mysqli_error($conn);

mysqli_close($conn);
?>
 19

** TESTING **

DEFINITION
White Box Testing (also known as Clear Box Testing, Open Box Testing, Glass Box
Testing, Transparent Box Testing, Code-Based Testing or Structural Testing) is
a software testing method in which the internal structure/ design/ implementation of the
item being tested is known to the tester. The tester chooses inputs to exercise paths
through the code and determines the appropriate outputs. Programming know-how and
the implementation knowledge is essential. White box testing is testing beyond the user
interface and into the nitty-gritty of a system.
This method is named so because the software program, in the eyes of the tester, is like
a white/ transparent box; inside which one clearly sees.

DEFINITION BY ISTQB

 White-Box Testing: Testing based on an analysis of the internal structure of the

component or
system.
 White-Box Test Design Technique: Procedure to derive and/or select test cases
based on an analysis of the internal structure of a component or system.

EXAMPLE

A tester, usually a developer as well, studies the implementation code of a certain field
on a webpage, determines all legal (valid and invalid) AND illegal inputs and verifies the
outputs against the expected outcomes, which is also determined by studying the
implementation code.
White Box Testing is like the work of a mechanic who examines the engine to see why
the car is not moving.

LEVELS APPLICABLE TO

White Box Testing method is applicable to the following levels of software testing:

 Unit Testing: For testing paths within a unit.

 Integration Testing: For testing paths between units.
 System Testing: For testing paths between subsystems.

However, it is mainly applied to Unit Testing.

 20

WHITE BOX TESTING ADVANTAGES

 Testing can be commenced at an earlier stage. One need not wait for the GUI to
be available.
 Testing is more thorough, with the possibility of covering most paths.

WHITE BOX TESTING DISADVANTAGES

 Since tests can be very complex, highly skilled resources are required, with
thorough knowledge of programming and implementation.
 Test script maintenance can be a burden if the implementation changes too
frequently.

TEST CASES
21
 22

** RISK, RELIABILITY, FAULT MAINTAINENCE **

 Only registered users will be able to access the website by entering the correct
login name and corresponding password.

 Only the accessed members with individual password are allowed to access the
site. Passwords and the user id’s used to perform the payment transactions are
kept in much safe. Everything is accessed and observed by admin group
thoroughly to keep the customer details safely.
 Security: Only registered users will be able to access the website by entering the
correct login name and corresponding password.

 Maintainability: The website can be maintained in present or future. It will be easy

to incorporate new requirements in the individual modules.

 Portability: As the website is online so will be easily portable on various systems.

 23

** STUDY OF STAR UML **

 Star UML is a UML tool by MK Lab. The software was licensed under a modified version
of GNU GPL until 2014, when a rewritten version 2.0.0 was released for beta testing
under a proprietary license.

 After being abandoned for some time, the project had a revival to move from Delphi to
Java/Eclipse and then stopped again. In 2014, a rewritten version was released as
proprietary software. However, the open source version's community is still active and
many topics are discussed on the forums.

 The stated goal of the project was to replace larger, commercial applications such as
Rational Rose and Borland Together.

 Star UML supports most of the diagram types specified in UML 2.0. It is currently
missing timing and interaction overview diagrams.

 Star UML was written in Delphi, which is one of the reasons why it was abandoned for a
long time. Since December 2005 Star UML was not updated anymore, although some
external modules were updated.

 Currently the newest version of Star UML by the original authors is available for
download under the handle "Star UML 2". The public beta is available, although not
under the GPL license. Final price and new license type yet remains unknown. This
version has been completely rewritten from scratch and includes among many
features: support for extensions, OS X compatibility and a new graphical user interface.

•The Unified Modelling Language (UML) is a general-purpose, developmental, modelling

language in the field of software engineering, which is intended to provide a standard way to
visualize the design of a system.

•UML has been evolving since the second half of the 1990s and has its roots in the object-
oriented methods developed in the late 1980s and early 1990s. The timeline shows the
highlights of the history of object-oriented modelling methods and notation.
 24

•UML has many types of diagrams, which are divided into two categories. Some types
represent structural information, and the rest represent general types of behaviour, including
a few that represent different aspects of interactions.

ADVANTAGES OF STAR UML

 MDA (MODEL DRIVEN ARCHITECTURE)

Star UML is designed to support MDA and provides many customization variables like
as UML profile, Approach, Model Framework, NX (notation extension), MDA code and
document template and so on. They will help you fitting tool into your organizational
cultures, processes, and projects.

 PLUG-IN ARCHITECTURE
Many users require more and more functionalities to software modelling tools. To
meet the requirements, the tool must have well-defined plug-in platform. Star UML
provides simple and powerful plug-in architecture so anyone can develop plug-in
modules in COM-compatible languages (C++, Delphi, C#, VB).

 USABILITY
Usability is most important issue in software development. Star UML is implemented
to provide many user-friend features such as Quick dialog, Keyboard manipulation,
Diagram overview, etc.

ADVANTAGES OF UML

VISUAL REPRESENTATION
A UML diagram is a visual representation of the relationships between classes and
entities in a computer program. A class is an object in programming that organizes
similar variables and functions in one location. To understand a program, it is essential
to understand what each class object does, the information it stores and how it relates
to other classes in the program. By showing this information in a diagram, it is easy to
understand and visualize a program's relationships.

READABILITY AND RE-USABILITY

A UML diagram is beneficial in that it is very readable. The diagram is meant to be
understood by any type of programmer and helps to explain relationships in a program
in a straightforward manner. Traditionally, to understand a program, a programmer
 25

would read the code directly. This could be thousands or millions of lines of code in very
large programs. Having a UML diagram helps to quickly illustrate those relationships.
Additionally, by using a diagram to show the code running in a program, a programmer
is able to see redundant code and reuse portions of code that already exist rather than
rewrite those functions.

STANDARD
UML is the current standard for programming in object-oriented programming
languages. When creating classes and other objects with relationships between each
other, UML is what is used to visually describe these relationships. Because it is used
as a standard, it is widely understood and well known. This makes it easy for a new
programmer to step into a project and be productive from day one.

PLANNING TOOL
UML helps to plan a program before the programming takes place. In some tools used
to model UML, the tool will generate code based on the classes set up in the model.
This can help reduce overhead during the implementation stage of any program.
Additionally, a UML model diagram is easy to change, whereas reprogramming a
section of code can be tedious and time-consuming

DISADVANTAGES OF UML

 UML does not define a standard file format, meaning that each UML tool vendor
stores the representation of its UML model in a proprietary format.
 The result is that the UML model is generally limited to what the vendor provides out
of the box, which is usually some form of code generation. Code will be generated
once.
 UML is large and complex (very much like the systems it wants
to model)    Comprises many different concepts and imprecise   semantics 
 Synchronizing code with models is difficult: Using multiple models/diagrams makes it
difficult to keep them consistent with each other and the code and much code has to
be added by hand

***********************************************************************************************************