VAISH COLLEGE

BHIWANI

SESSION-2022-23

A
Project Report
On
Develop Software To Computerize
All The Work

Submitted to : Submitted by :
Miss Sangeeta Ankita
Assistant Professor [Link] 3rd year (CA)
Dept. of Computer Sci. Roll No. : 201602011013

1
 DECLARATION

I, ANKITA, Roll No. 201602011013, [Link]. 3rd Year

(CA) Vaish College, Bhiwani has undertaken the Project

report entitled "Develop Software to Computerize All the work"

work and same has not been submitted to any other institution

for the award of any other degree.

( ANKITA)
Roll No. 201602011013

2
 Acknowledgement

The completion of this project study has been made possible to the
enduring help and everlasting guidance of many people. I avail
opportunity and express my deep gratitude to them.

I am whole heartedly indebted to Ms Sangeeta (Lecturer, Vaish

College, Bhiwani) whose extended their valuable guidance and support
in completing the project and guided me at each step with their valuable
advice.

I finally thank the staff of personal Department and Organization who

spent their valuable time in answering the questionnaires prepared for
the study.

ANKITA

3
 CONTENTS
➢ INTRODUCTION TO TOPIC
➢ REVIEW OF LITERATURE

➢ OBJECTIVES OF THE STUDY

➢ RESEARCH METHODOLOGY

➢ DATA ANALYSIS & INTERPRETATION

➢ SUGGESTIONS

➢ BIBLIOGRAPHY

4
 INTRODUCTION

1. Overview of proposed system

The main purpose of this project is to develop software to computerize all the work that
has been done manually by concern customers. Previously all the work likes allotment
of the products, keeping the records of all customer and records of all customer
transaction. So it is too difficult to maintain all records, generate reports, and fetch
information while using manual system.

Problem description

Manual system suffers from great limitations, like wastage, errors due to work,
complications in maintaining and analyzing the records. To sort these we have designed
a computerized system for, maintaining the record of the customers and also to fetch
the information easily and in a convenient way

That will provide different kind of facilities like-

1. The main aim is automation of customer‟s record

2. To records the various things like name of customer, customer e-mail id, address,
records of his transaction.
3. To make the system independent to make the system flexible.
4. Records are easy to analyze, sereach , view etc.

Existing system with limitation

The existing system is manual. All the records are kept in the papers & prepared
manually. The records kept in registers & files written manually &different types of
records are stored in different files.

Limitation existing system:-

1. The existing system is manual so it is very difficult to analyze the records.

2. In the manual system it is very difficult to analyze the records.
5
 3. Records are not to be maintained for a long time.
4. Problem of record losing, inaccuracy are there.
5. Reports generation and computerized printouts is also a big problem.
6. Searching a particular record take very long time
2. Need of the proposed system:
We can make this software:-

i. For help in keeping the record of customer.

ii. For help in make awareness in online purchasing.
iii. For help in reduce the time and money.
iv. For easily day-to-day new products updating.

REVIEW OF LITERATURE

The scope needs to detail the basic background of your company or organization, the
aim of the design project, budget goals, completion time frame, audience, design
requirements… essentially you need to be able to tell the company what you want and
what your website needs to achieve, thus creating the framework in which they can
design your site. These principles are common to any project. Would you ever consider
building a house, a car or an airplane without detailed plans?

The scope will often require consulting with an experienced designer or project manager
to create the document for you. This will greatly ease the overall design and tendering
process and allow choosing the right design team to actually build and construct your
website.

Objectives of proposed system

Manual system suffers from great limitation like time wastage, errors due to work,
complications in maintaining &analyzing the records. To sort these problems we have
designed a computerized system for maintaining the record for the records for keeper
of the concern organisations.

Provide fully computerized purchasing system.

6
 i. Dynamic search engine.

ii. Complete day-to-day stock status.

iii. Complete day-to-day registered customer‟s report.

Project categories Tools and environment

Front-end and back-end are terms used to characterize program interfaces and services
relative to the initial user of these interfaces and services. (The "user" may be a human
being or a program.) A "front-end" application is one that application users interact with
directly. A "back-end" application or program serves indirectly in support of the front-
end services, usually by being closer to the required resource or having the capability
to communicate with the required resource. The back-end application may interact
directly with the front-end or, perhaps more typically, is a program called from an
intermediate program that mediates frontend and back-end activities.

(a) Front end

In front end we have use HTML, CSS, JAVA script, PHP. For creating a website use
HTML tag, make webpage more effective and better-looking we have used CSS. For
some restriction we have use validation.

Front-end designers basically come up with the user interface for the website. They deal
with colors, fonts, images, layout, informational structure and organization, navigation,
etc. They use HTML, Flash, CSS, etc.

Back end
The backend to a website is pretty much everything the user can't see. Generally, this
means the programming that generates pages that the user views, creating the "server-
side" content of the site. This could be scripts, directives, databases, and other
automated functions the server performs.
Back end designers are usually database people, and they design the databases or
whatever that is presented through the front end. They might need to know SQL, GNU,
or some other corporate-level database like DB2 or Lotus Domino. They deal with
order-fulfillment, inventorying, etc.
Hardware and software requirements
7
 Hardware Requirements

i. PROCESSOR CPU
ii. MEMORY (RAM)
iii. FLOPPY DRIVE iv. HARD DISK v. MONITER
vi. KEYBOARD
vii. MOUSE viii. WI-FI
ix. POWER
x. PENDRIVE
xi. CD
xii. PRINTER

Software requirements

i. OPERATING SYSTEM
ii. NOTEPAD
iii. INTERNET EXPLORER iv. GOOGLE CHROME v. WAMP SERVER
vi. PHP READER
vii. MYSQL
viii. MS-ACCESS
ix. HTML
Software Development Life Cycle

In order to understand what is Software Development Lifecycle (SDLC) let us break

these words into two parts: Software Development , and LifeCycle.

Software Development.

Software Development is A PROCESS to create [Link] first glance to a developer

- this is the coding process. This is when you sit down with the computer and start to
write codes that later processed (compiled,linked etc.) become the actual software that
is used by the end user. This is might be the case for beginners or novice developer who
are working on "garage" project.

8
In a small one person project its common for developers to go directly into coding and
then testing their code. They are using common divide and conquer, then trial and error
[Link] for a significant size software development trial and error method will be
[Link] is because large size project normally involved few developers. Any
change in any part of the codes might requires other developers to change their code
also.

Larger software development also requires better way to communicate, between the
[Link] communication is to make sure developers understand what to be
developed, when to start the development, when the other part of the software that they
dependence to will be developed, when to test these parts together, what is considered
pass..[Link]. Lot of issues to synchronized the developers.

The larger the group, the harder it is to communicate to all the team members.

This can be worst if the team members are not located in the same place - which are
common these day. The team that I am part of have people working in 4 different
continents in different time zone.

To make it easier, a concept of "Lifecycle" is introduced.

Lifecycle

Common concept of lifecycle is communicated to a development team to synchronized

all the team members - so that every one knows when are the important milestones.

Milestones are dates when certain important criteria or requirement has to be

[Link] of lifecycle is not exclusive to software development.

For example a human being also has lifecycle. Start from the day a human being is born.

Then s/he grows become baby,teenager,adult, old and died. This lifecycle also can be
traced differently based on different view -example if look from education lifecycle (of
the same human being) it can start from pre-school,junior high, high school,college
undergrad, and graduate.

9
These phases actually applicable to the final product, or even into the individual
component that make up the product. For example if you are creating a chair, then you
have components such as the arm rest, legs, cushions, and back rest. Once the "high
level" requirements (description, specification - lot of different names of the same
thing) is defined the developer of each component should be able to continue on their
own to produce the components. Each of the components will go through the same 5
phases lifecycle also.

This concept of "component" developement is that not far off from what is happening
in software development. If you have been in the industry long enough I bet you have
heard of "component based" development. The idea is to introduce generic requirement
on how components can be handled, then as long as a component is developed in
conformant to this standard it can be "plugged in" into another software that understand
this standard with very little effort.

Even a lot of people say that software development should be the same as other product
development -- such as car and building constructions, but experience has proven that
this is not true. The normal discipline that is used in building construction does not
really work in software development.

From what the expert observation this is because in normal product construction such
as a freeway, ideas and creativity are injected to the project only in very specific part of
the phase -- early phase. In building construction creativity can come from the architect
and also the civil engineers who has to figure out how to build what is envisioned by
the architect. This is done in early stage (design) of the development phase. Once it is
fixed the implementation, testing and delivery just need to follow the instructions.

In software development on the other hand, the injection of ideas is hard to controlled
since its actually needed in every phase. From the high level architecture, down to low
level programming, ingenuity and creativity is needed. Most software
developmentactually depending on in development discoveries to come up with
innovative products. New way of coding, new algorithm, new component can make the
difference between on software to the other in term of feature offered,resource usage
and performance.

10
 Because of this software development process is normally "less rigid" compare to car
or buiding construction. The side effect is that this can also caused two major
problems:

Research Methodology

SDLC consists of following activities:

1. Planning: The most important parts of software development, requirement gathering

or requirement analysis are usually done by the most skilled and experienced software
engineers in the organization. After the requirements are gathered from the client, a
scope document is created in which the scope of the project is determined and
documented.
2. Implementation: The software engineers start writing the code according to the client's
requirements.
3. Testing: This is the process of finding defects or bugs in the created software.
4. Documentation: Every step in the project is documented for future reference and for
the improvement of the software in the development process. The design documentation
may include writing the application programming interface (API).
5. Deployment and Maintenance: The software is deployed after it has been approved
for release.
6. Maintaining: Software maintenance is done for future reference. Software
improvement and new requirements (change requests) can take longer than the time
needed to create the initial development of the software.
The actual amount of steps varies according to the person describing them, but they
always cover the same steps.

1. Specify the Requirement

2. Data Analysis
3. Problem Analysis
4. Algorithm
5. Coding
6. Testing
7. Maintenance
11
The first four steps are very important as it represents the logic of the problem, and can
be used to test the execution of the algorithm. This checking of the logic eliminates
semantic problems, and allows for the utilization of the pseudocode in many languages.
You should have test data ready, and develop a trace table; This can be used to check
the output of the program when testing.

1. Specify the requirement: This area is where you describe exactly what you are
doing as clear as possible. In this statement you will include the data to be used, and
what can be assumed. Also, the desired output and its layout. 2. Data Analysis: List all
the variables needed to solve the problem. Utilizing self-documenting (Descriptive of
what they represent) variable names is always preferred. This also includes the data
type, scope, and documentation for each variable.
3. Problem Analysis: Here you will list each operation necessary to solve the
problem at hand. You can also divide the problem into multiple subtasks as needed, and
continue until they are specifically stated and easily solved.
4. Algorithm: this clarifies how the problem is to be solved. An algorithm is an
effective method for solving a problem expressed as a finite sequence of steps.
Thealgorithm must be written very clearly, as not to cause misinterpretation, and is
normally done in pseudocode. The algorithm should, when applied to the problem,
solve it in a finite amount of time.
These last three steps allow for the solution to the problem to be entered into a form the
computer can work with.
5. Coding: The translation of the algorithm from pseudocode into a programming
language. Proper mapping of the code to the algorithm, combined with refining of the
pseudocode, should lead to an easy translation to any programming language.
6. Testing: This step requires the use of the data table built with the algorithm.
You will run the program, and verify the output for correctness and proper layout. Also,
you will validate the code ensuring you requirements have been met and the problem
was solved.
7. Maintenance: Updating and testing of the software. Every time the code is
updated, it must be tested for correctness.

12
 The different phases of software life cycle development are:
Types of Software developing life cycles (SDLC)

[Link] Model :The Waterfall Model was first Process Model to be introduced. 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
.

The waterfall Model illustrates the software development process in a linear sequential
flow; hence it is also referred to as a linear-sequential life cycle model. This means that
any phase in the development process begins only if the previous phase is complete. In
waterfall model phases do not overlap.

Waterfall Model design

Waterfall approach was first SDLC Model to be used widely in Software Engineering
to ensure success of the project. In "The Waterfall" approach, the whole process of
software development is divided into separate phases. In Waterfall model, typically, the
outcome of one phase acts as the input for the next phase sequentially.

All these phases are cascaded to each other in which progress is seen as flowing
steadily downwards (like a waterfall) through the phases. The next phase is started
only after the defined set of goals are achieved for previous phase and it is signed off,
so the name "Waterfall Model". In this model phases do not overlap.

Waterfall Model Application

Every software developed is different and requires a suitable SDLC approach to be

followed based on the internal and external factors. Some situations where the use of
Waterfall model is most appropriate are:

Requirements are very well documented, clear and fixed.

13
 Product definition is stable.

Technology is understood and is not dynamic.

There are no ambiguous requirements.

ADVANTAGE

The advantage of waterfall development is that it allows for departmentalization and

control. A schedule can be set with deadlines for each stage of development and a
product can proceed through the development process model phases one by one.

Development moves from concept, through design, implementation, testing,

installation, troubleshooting, and ends up at operation and maintenance. Each phase of
development proceeds in strict order.

DISADVANTAGE

The disadvantage of waterfall development is that it does not allow for much reflection
or revision. Once an application is in the testing stage, it is very difficult to go back and
change something that was not well-documented or thought upon in the concept stage.

[Link] Model The spiral model combines the idea of iterative development with the
systematic, controlled aspects of the waterfall model.

Spiral model is a combination of iterative development process model and sequential

linear development model i.e. waterfall model with very high emphasis on risk analysis.

It allows for incremental releases of the product, or incremental refinement through

each iteration around the spiral.

Spiral Model design

The spiral model has four phases. A software project repeatedly passes through these
phases in iterations called Spirals.

Identification:This phase starts with gathering the business requirements in the

baseline spiral. In the subsequent spirals as the product matures, identification of system

14
requirements, subsystem requirements and unit requirements are all done in this phase.

This also includes understanding the system requirements by continuous

communication between the customer and the system analyst. At the end of the spiral
the product is deployed in the identified market.

Design:Design phase starts with the conceptual design in the baseline spiral and
involves architectural design, logical design of modules, physical product design and
final design in the subsequent spirals.
Construct or Build:Construct phase refers to production of the actual software
product at every spiral. In the baseline spiral when the product is just thought of and the
design is being developed a POC (Proof of Concept) is developed in this phase to get
customer feedback.

Then in the subsequent spirals with higher clarity on requirements and design details a
working model of the software called build is produced with a version number. These
builds are sent to customer for feedback.

Evaluation and Risk Analysis:Risk Analysis includes identifying, estimating, and

monitoring technical feasibility and management risks, such as schedule slippage and
cost overrun. After testing the build, at the end of first iteration, the customer evaluates
the software and provides feedback.

Following is a diagrammatic representation of spiral model listing the activities in

each phase:

Based on the customer evaluation, software development process enters into the next
iteration and subsequently follows the linear approach to implement the feedback

15
suggested by the customer. The process of iterations along the spiral continues
throughout the life of the software.

Spiral Model Application

Spiral Model is very widely used in the software industry as it is in synch with the
natural development process of any product i.e. learning with maturity and also involves
minimum risk for the customer as well as the development firms. Following are the
typical uses of Spiral model:

When costs there are a budget constraint and risk evaluation is important.

For medium to high-risk projects.

Long-term project commitment because of potential changes to economic priorities

as the requirements change with time.

Customer is not sure of their requirements which are usually the case.

Requirements are complex and need evaluation to get clarity.

New product line which should be released in phases to get enough customer
feedback.

Significant changes are expected in the product during the development cycle.

Spiral Model Pros and Cons

The advantage of spiral lifecycle model is that it allows for elements of the product to
be added in when they become available or known. This assures that there is no conflict
with previous requirements and design.

This method is consistent with approaches that have multiple software builds and
releases and allows for making an orderly transition to a maintenance activity. Another
positive aspect is that the spiral model forces early user involvement in the system
development effort.

On the other side, it takes very strict management to complete such products and there
is a risk of running the spiral in indefinite loop. So the discipline of change and the

16
 extent of taking change requests is very important to develop and deploy the product
successfully.

(a). Recognition of Need:

One must know what the problem is before it can be solved. The basis of candidate system is
recognition of need for improving the system. The key question is:

What is the problem?

This recognition of need leads to a preliminary survey or an initial investigation of current system
to determine whether an alternative system can solve the problem. If the problem is serious
enough, management may have an analyst look at it.

The idea for change may originate in the environment or within the firm. Environment-based
ideas originate from customers, vendors, government sources etc. When investigated each of these
ideas may lead to a problem definition. Idea for change may also come from within the
organization – top management, the user, the analyst. User-originated ideas also prompt initial
investigation.

(b). Feasibility study: Depending upon the results of the initial investigation, the survey is
expanded to a more detailed feasibility study. A feasibility study is a test of a system proposal
according to its workability, impact on the organization, ability to meet user needs and effective
use of resources. The key questions are:-
1. What are the user‟s demonstrable needs and how does a candidate system meet them?
2. What resources are available for given candidate systems? Is the problem worth
solving?
3. What is the impact of the candidate system on the organization? How well does it is fit
within the organization‟s master Master Information System plan?

17
Each of these questions must be answered carefully. All of these questions help to
investigate and to evaluate the problem, the cost of each system and final selection of
the best system.

The objective of a feasibility study is not to solve the problem but to acquire a sense of
its scope. Consequently, Cost and benefits are estimated with greater accuracy at this
stage.
The result of the feasibility study is a formal proposal. This is simply a formal document
detailing the nature and scope of the proposed solution.

(i)Operational Feasibility:Often, a feasibility study is needed to determine if a project

or end result of a project is feasible and beneficial. The world of feasibility studies is
not just considering the project as a whole; often you also need an example of an
operational feasibility study as part your research.

The Need for Operational Feasibility Studies

Operational feasibility studies are generally utilized to answer the following questions:

Process – How do the end-users feel about a new process that may be
implemented?
Evaluation – Whether or not the process within the organization will work but
also if it can work.
Implementation – Stakeholder, manager, and end-user tasks.
Resistance – Evaluate management, team, and individual resistance and how
that resistance will be handled.
In-House Strategies – How will the work environment be affected? How much
will it change?
Adapt & Review – Once change resistance is overcome, explain how the new process
will be implemented along with a review process to monitor the process change.

18
 Analysis and Interpretations of Data
If an operational feasibility study must answer the six items above, how is it used in the
real world? A good example might be if a company has determined that it needs to
totally redesign the workspace environment.

After analyzing the technical, economic, and scheduling feasibility studies, next would
come the operational analysis. In order to determine if the redesign of the workspace
environment would work, an example of an operational feasibility study would follow
this path based on six elements:

Process – Input and analysis from everyone the new redesign will affect along with a
data matrix on ideas and suggestions from the original plans.
Evaluation – Determinations from the process suggestions; will the redesign
benefit everyone? Who is left behind? Who feels threatened?
Implementation – Identify resources both inside and out that will work on the
redesign. How will the redesign construction interfere with current work?
Resistance – What areas and individuals will be most resistant? Develop a
change resistance plan.
Strategies – How will the organization deal with the changed workspace environment?
Do new processes or structures need to be reviewed or implemented in order for the
redesign to be effective?
Adapt & Review – How much time does the organization need to adapt to the new
redesign? How will it be reviewed and monitored? What will happen if through a
monitoring process, additional changes must be made?

ii) Economical feasibility: This is one of the most important parts of the report. The
economic overview of the area can be organized under following heads:

• General Overview

• Gross Domestic Product

• Investment Indicators

• Inflation
19
• Population and labor

• Tourism

The “area” in the “economic overview of the area” can be either the city, or the state
or even the country where the project is located. When you are working on a project
located in India (Area = 11,437 SqKm, population = 1.85 million) you should cover
the whole country. But when you are doing a project in Delhi(Area = 603 SqKm,
population = 12.5 million), you can either cover the city or can go for the state Delhi(
(Area = 307,713 SqKm, population = 112.4

[Link] Feasibility: Technical Feasibility centers on the system such as

hardware, software etc, and to what extent it can support the proposed package. It also
needs to be ensuring that the requesting hardware for operating the system is available.

[Link] Feasibility: Legal feasibility involve in verifying the legal viability of the
proposed system.

Our website follows the restriction, rule & regulationdefine by the govt. and this is not
involved in any unfair, illegal, and fraud type activity.

c. System Requirement Specifications (SRS)

Introduction
The introduction of the Software Requirements Specification (SRS) provides an
overview of the entire SRS with purpose, scope, definitions, acronyms, abbreviations,
references and overview of the SRS. The aim of this document is to gather and
analyze and give an in-depth insight of the complete Marvel Electronics and Home
Entertainment software system by defining the problem statement in detail.
Nevertheless, it also concentrates on the capabilities required by stakeholders and
their needs while defining high-level product features. The detailed requirements of
the Marvel Electronics and Home Entertainment are provided in this document.

Purpose

20
The purpose of the document is to collect and analyze all assorted ideas that have come
up to define the system, its requirements with respect to consumers. Also, we shall
predict and sort out how we hope this product will be used in order to gain a better
understanding of the project, outline concepts that may be developed later, and
document ideas that are being considered, but may be discarded as the product develops.

In short, the purpose of this SRS document is to provide a detailed overview of our
software product, its parameters and goals. This document describes the project's target
audience and its user interface, hardware and software requirements. It defines how our
client, team and audience see the product and its functionality. Nonetheless, it helps any
designer and developer to assist in software delivery lifecycle (SDLC) processes.

Scope
Primarily, the scope pertains to the Newly launched car product features for making
JIKUS AUTOMOBILE project live. It focuses on the company, the stakeholders and
applications, which allow for online sales, distribution and marketing of electronics.

This SRS is also aimed at specifying requirements of software to be developed but it

can also be applied to assist in the selection of in-house and commercial software
products. The standard can be used to create software requirements specifications
directly or can be used as a model for defining a organization or project specific
standard. It does not identify any specific method, nomenclature or tool for preparing
an SRS.

Definitions, Acronyms, and Abbreviations

Configuration It means a product which is available / Selected from a

catalogue can be customized.
FAQ Frequently Asked Questions
CRM Customer Relationship Management
RAID 5 Redundant Array of Inexpensive Disk/Drives

Overview

21
The remaining sections of this document provide a general description, including
characteristics of the users of this project, the product's hardware, and the functional
and data requirements of the product. General description of the project is discussed
in section 2 of this document. Section 3 gives the functional requirements, data
requirements and constraints and assumptions made while designing the E-Store. It
also gives the user viewpoint of product. Section 3 also gives the specific
requirements of the product. Section 3 also discusses the external interface
requirements and gives detailed description of functional requirements. Section 4 is
for supporting information.
Overall Description

This document contains the problem statement that the current system is facing which
is hampering the growth opportunities of the company. It further contains a list of the
stakeholders and users of the proposed solution. It also illustrates the needs and wants
of the stakeholders that were identified in the brainstorming exercise as part of the
requirements workshop. It further lists and briefly describes the major features and a
brief description of each of the proposed system.
The following SRS contains the detail product perspective from different
stakeholders. It provides the detail product functions of E-Store with user
characteristics permitted constraints, assumptions and dependencies and
requirements subsets.
Specific Requirements
The specific requirements are –
Functionality

Introduction –
This subsection contains the requirements for the e-store. These requirements are
organized by the features discussed in the vision document. Features from vision
documents are then refined into use case diagrams and to sequence diagram to best
capture the functional requirements of the system. All these functional requirements
can be traced using tractability matrix.
Sell Configured to Ordered Products.

22
 The system shall display all the products that can be configured.
The system shall allow user to select the product to configure.
The system shall display all the available components of the product to
configure
The system shall enable user to add one or more component to the
configuration.
The system shall notify the user about any conflict in the current configuration.
The system shall allow user to update the configuration to resolve conflict in the
current configuration.
The system shall allow user to confirm the completion of current configuration
Provide comprehensive product details.

The system shall display detailed information of the selected products. The
system shall provide browsing options to see product details.

Detailed product Categorizations

The system shall display detailed product categorization to the user.

Provide Search facility.

The system shall enable user to enter the search text on the screen.

The system shall enable user to select multiple options on the screen to search.

The system shall display all the matching products based on the search

The system shall display only 10 matching result on the current screen.

The system shall enable user to navigate between the search results.

The system shall notify the user when no matching product is found on the search.

Maintain customer profile.

23
 The system shall allow user to create profile and set his credential.

The system shall authenticate user credentials to view the profile.

The system shall allow user to update the profile information.

Provide personalized profile

. The system shall display both the active and completed order history in the
customer profile.

The system shall allow user to select the order from the order history.

The system shall display the detailed information about the selected order.

The system shall display the most frequently searched items by the user in the profile.

The system shall allow user to register for newsletters and surveys in the profile.

Provide Customer Support.

The system shall provide online help, FAQ‟s customer support, and sitemap options for
customer support.

The system shall allow user to select the support type he wants.

The system shall allow user to enter the customer and product information for
the support.

The system shall display the customer support contact numbers on the screen.

The system shall allow user to enter the contact number for support personnel to call.

24
The system shall display the online help upon request.
The system shall display the FAQ‟s upon request.

Email confirmation.

The system shall maintain customer email information as a required part of

customer profile.
The system shall send an order confirmation to the user through email.
Detailed invoice for customer.
The system shall display detailed invoice for current order once it is confirmed.

The system shall optionally allow user to print the invoice.

Provide shopping cart facility.

The system shall provide shopping cart during online purchase.

The system shall allow user to add/remove products in the shopping cart.
Provide multiple shipping methods.

The system shall display different shipping options provided by shipping

department.
The system shall enable user to select the shipping method during payment
process.

The system shall display the shipping charges.

The system shall display tentative duration for shipping.

Online tracking of shipments

The system shall allow user to enter the order information for tracking.

The system shall display the current tracking information about the order.

Provide online Tax Calculations

25
 The system shall calculate tax for the order.

The system shall display tax information for the order.

Allow multiple payment methods.

The system shall display available payment methods for payment.

The system shall allow user to select the payment method for order.

Allow online change or cancellation of order.

The system shall display the orders that are eligible to change.

The system shall allow user to select the order to be changed.

The system shall allow user to cancel the order

The system shall allow user to change shipping, payment method.

The system shall notify the user about any changes made to the order.
Allow Online Product reviews and ratings

The system shall display the reviews and ratings of each product, when it is selected.

The system shall enable the user to enter their reviews and ratings.

Offer financing options.

26
 The system shall display all the available financing options.

The system shall allow user to select the financing option.

The system shall notify the use about the financing request.

Provide detailed sitemap.

The system shall allow user to view detailed sitemap.
Offer online promotions and rewards.

The system shall display all the available promotions to the user.

The system shall allow user to select available promotion.

Online Purchase of products.

The system shall allow user to confirm the purchase.

The system shall enable user to enter the payment information.

Usability

Graphical User Interface

The system shall provide a uniform look and feel between all the web pages.

The system shall provide a digital image for each product in the product catalog.

The system shall provide use of icons and toolbars.

Accessibility

The system shall provide handicap access.

The system shall provide multi language support.

27
 Performance

The product shall be based on web and has to be run from a web server.

The product shall take initial load time depending on internet connection strength which
also depends on the media from which the product is run.
The performance shall depend upon hardware components of the client/customer.
Security

Data Transfer

The system shall use secure sockets in all transactions that include any
confidential customer information.
The system shall automatically log out all customers after a period of inactivity.

The system shall confirm all transactions with the customer‟s web browser.

The system shall not leave any cookies on the customer‟s computer containing
the user‟s password.

The system shall not leave any cookies on the customer‟s computer containing any of
the user‟s confidential information.

Data Storage

The customer‟s web browser shall never display a customer‟s password. It shall always
be echoed with special characters representing typed characters.

The customer‟s web browser shall never display a customer‟s credit card number after
retrieving from the database. It shall always be shown with just the last 4 digits of the
credit card number.

28
 The system‟s back-end servers shall never display a customer‟s password. The
customer‟s password may be reset but never shown.

The system‟s back-end servers shall only be accessible to authenticated administrators.

The system‟s back-end databases shall be encrypted.

Supportability
Configuration Management Tool

The source code developed for this system shall be maintained in configuration
management tool.

Design Constraints
Standard Development Tools

The system shall be built using a standard web page development tool that conforms to
either IBM‟s CUA standards or Microsoft‟s GUI standards.

Web Based Product

There are no memory requirements

The computers must be equipped with web browsers such as Internet explorer.

The product must be stored in such a way that allows the client easy access to it.

Response time for loading the product should take no longer than five minutes.

A general knowledge of basic computer skills is required to use the product

29
 On-line User Documentation and Help System Requirements
As the product is E-store, On-line help system becomes a critical component of the
system which shall provide – o It shall provide specific guidelines to a user for using
the E-Store system and within the system.
o To implement online user help, link and search fields shall be provided.

Supporting Information

Please refer the following document:

1. Vision document for E-store.

2. Use case analysis.

3. Structural models.

4. Behavioral models.

5. Nonfunctional requirements model.

6. Traceability Matrix.

7. Project Plan

d. System Analysis and Design: A system analyst is a person responsible for the
development of software and hardware solution to the efficient working of the
organization. Analysts study the environment and problems of an organization to
determine whether a new information method can provide solution to the problem. The
main job of system analyst is to provide right type of information, in right quantity at
the right time in post-effective manner to the management or then user.

i. Entity Relationship Diagram:An entity–relationship model (ER model) is a data

model for describing a database in an abstract way. This article refers to the techniques
30
proposed in Peter Chen's 1976 paper. However, variants of the idea existed previously,
and have been devised subsequently such as super type and subtype data entities
andcommonality relationships.

1. The building blocks: entities, relationships, and attributes

Two related entities

An entity with an attribute

A relationship with an attribute

Primary key
An entity may be defined as a thing which is recognized as being capable of an
independent existence and which can be uniquely identified. An entity is an abstraction
from the complexities of a domain. When we speak of an entity, we normally speak of
some aspect of the real world which can be distinguished from other aspects of the real
world.[4]

An entity may be a physical object such as a house or a car, an event such as a house
sale or a car service, or a concept such as a customer transaction or order. Although the
term entity is the one most commonly usedEntities can be thought of as nouns.
Examples: a computer, an employee, a song, a mathematical theorem.

A relationship captures how entities are related to one another. Relationships can be
thought of as verbs, linking two or more nouns. Examples: an owns relationship
between a company and a computer, a supervises relationship between an employee
and a department, a performs relationship between an artist and a song, a proved
relationship between a mathematician and a theorem.

31
(ii)ENTITY RELATIONSHIP DIAGRAM 1st LEVEL DATAFLOW DIAGRAM

REGISTER

UESR CUSTOMER NAME

&PASSWORD

FIG: REGISTRION FORM

iii. Design Strategies:Software design is about a sequence of steps taken to achieve a

goal. Designers must plan their approach to carrying out these steps. In studying
designers at work, the authors observed breadth- versus depth-first approaches to
design-space exploration and problem- versus solution-driven approaches during the
actual design. Which approaches and when to use them are important to effective
design. The authors suggest four archetypical strategies that designers can choose under
different circumstances, thus making design strategy one of the early design decisions.

32
e. Physical Design (Coding):

33
(f).System Integration and Testing

SIT is part of the software testing life cycle for collaborative projects. Usually, a round
of SIT precedes the user acceptance test (UAT) round. Software providers usually run
a pre-SIT round of tests before consumers run their SIT test cases.

34
 For example, if an integrator (company) is providing an enhancement to a customer's
existing solution, then they integrate the new application layer and the new database
layer with the customer's existing application and database layers. After the integration
is complete, users use both the new part (extended part) and old part (pre-existing part)
of the integrated application to update data. A process should exist to exchange data
imports and exports between the two data layers. This data exchange process should
keep both systems up-to-date. The purpose of system integration testing is to ensure all
parts of these systems successfully coexist and exchange data where necessary.

(i).Functional Testing

Functional testing is a quality assurance (QA) process and a type of black box testing
that bases its test cases on the specifications of the software component under test.
Functions are tested by feeding them input and examining the output, and internal
program structure is rarely considered (not like in white-box testing). Functional
Testing usually describes what the system does.

Functional testing differs from system testing in that functional testing "verifies a
program by checking it against ... design document(s) or specification(s)", while system
testing "validate[s] a program by checking it against the published user or system
requirements" (Kaner, Falk, Nguyen 1999, p. 52).

Functional testing typically involves five steps [citation needed]

1. The identification of functions that the software is expected to perform

2. The creation of input data based on the function's specifications
3. The determination of output based on the function's specifications
4. The execution of the test case
5. The comparison of actual and expecte

(ii).Structural Testing

▪ The structural testing is the testing of the structure of the system or component.

35
▪ Structural testing is often referred to as „white box‟ or „glass box‟ or „clear-box
testing‟ because in structural testing we are interested in what is happening „inside the
system/application‟.
▪ In structural testing the testers are required to have the knowledge of the internal
implementations of the code. Here the testers require knowledge of how the software is
implemented, how it works.
▪ During structural testing the tester is concentrating on how the software does it. For
example, a structural technique wants to know how loops in the software are working.
Different test cases may be derived to exercise the loop once, twice, and many times.
This may be done regardless of the functionality of the software.
▪ Structural testing can be used at all levels of testing. Developers use structural testing
in component testing and component integration testing, especially where there is good
tool support for code coverage . Structural testing is also used in system and acceptance
testing, but the structures are different. For example, the coverage of menu options or
major business transactions could be the structural element in system or acceptance
testing.

36
(iii)Test case.

The example above contains the main headings that a test case needs for most
cases. However, there are many more headings which could be useful and you can find
these below.

You probably won‟t need all these fields in every situation, so start with a few fields
and add others to the test case template later as the need arises. You can get started
initially using just the fields in the example above.

ID (identification)

The ID field makes it easier to cross-reference test cases, both with one another and
from defect reports. The ID obviously has to be unique, i.e.: there can never be more
than one test case with the same ID number.

The most common approach is to use a continuous sequence, so that test cases are
identified as 1, 2, 3, and so on. You don‟t have to prefix the ID with a code (like UM01
for the first test case in the user module), but some people do use prefixes to make it
easier to see which part of the system a test case belongs to.

If you have access to a good test management tool, you won‟t need to use prefixes,
since the tool will automatically assign an ID number to each test case.

37
Some people put the test case number in the test case title, to make it easier to sort the
test cases for example, however, it‟s better to keep ID as a custom field and use the
tool‟s sorting functions, because it can get pretty difficult to keep the numbering
consistent and sequential as the number of test cases grows.

Title

The title should provide a concise, revealing description of the test case, such as “Add
customer”.

The title is important because it‟s often the first or only thing you see when you are
scanning a list of test cases for example.

You should gather the test cases in a test management tool, or in a document (often
referred to as the test specification). Clear titles are key to helping testers quickly find
the right test cases.

Pre-conditions

In the pre-conditions heading, you should explain any activities that the tester needs to
carry out before he/she can execute the test steps. They may need to add test data,
perform other functions, execute other test cases, or navigate to a particular part of the
system.

The pre-conditions field isn‟t relevant to every test case, so you may want to include it
in the template but not make it mandatory. If you don‟t describe preconditions
accurately, the testers may not be able to conduct the test. If you have several cases that
all have the same pre-conditions, you should move the preconditions to a test run or test
specification instead, to avoid writing the same instructions repeatedly.
Test Steps

The Test Steps section gives the tester a numbered list of the steps to perform in the
system, which makes it easier to understand the test case.

It is recommended to have 3-8 test steps per test case, although sometimes you might
need a smaller number of test cases with a larger number of test steps. Too many steps

38
make it difficult for developers and testers to reproduce the steps in the event that a bug
report is filed against the test case.

Expected Results

The tester needs to know the expected result in order to assess whether the test case is
successful. The optimal level of detail in this field varies from situation to situation.

One of the most common problems is the wording of the expected outcome, especially
if the description is so vague that it‟s not possible to tell whether the test case has
succeeded. Ensure that the wording is clear and concise.

Post-conditions

The person executing the test case needs the Post-conditions field to know how to
restore the system to its original state and not interfere with subsequent testing. For
example, if the test case adds a customer, the tester might need to remove that customer.
In many systems it is not possible to add two customers containing the same data. If
you do not remove the customer, it is not possible to execute the test case again.
Removing the newly-added customer after executing the test steps is a typical post-
condition.

If the test case involves deleting a login account, you may need to recreate it. If the
same post-conditions is used in several test cases it‟s more efficient to move it to a test
run or test specification instead of adding it to each test case.
Test Data

You can enter test data directly in the test data field, or refer to a separate file that
contains test data for one or more test cases. For example, you can store test data in a
text file or in an Excel spreadsheet.

By using a test data file, you avoid hard coding test data in the test case, so a single test
case can be used to test several sets of test data.

Priority

39
Priority indicates how urgent and/or important a test case is. All test cases can‟t be of
equally high priority, and priority can help determine the order in which you run them.

Priority is also useful when you run up against time constraints during test execution –
you can just run the highest priority test cases, for example.

You can use a simple scale like high/medium/low, or the MoSCoW scale (Must, Should,
Could, or Won‟t be executed).

Priority should naturally be based on requirements, but if the requirements aren‟t

already prioritized, the test group should propose a prioritization that the client reviews
and approves.

Requirements Reference

This section refers to the requirement that the test case is testing (for example “14″ if
the test case tests requirement ID 14).

By using specific references to particular requirements, you can create a traceability

matrix that, among other things, can show you whether you have test cases that cover
all requirements.
With a test management tool it‟s easy to create and maintain references to requirements,
test cases, and defect reports.

The part(s) of the system related to the test case. Sometimes also called program or
component.

2. Fields which are not included in the test case

The following fields aren‟t normally included in the test case since they are typically
handled by a test management tool or manually documented in a test log if a tool is not
used.

The reason this information doesn‟t belong in a test case is that test cases contain static
information which doesn‟t change. The result of the test run is dynamic information
that changes every time the test case is run.
40
 Mixing static and dynamic information is a huge challenge, especially if you use Word
and Excel for test and requirements management. However, if you‟re using a test
management tool such as Retest, it will probably be able to integrate static and dynamic
information effectively.

g. Operation and Maintenance

e-business operations - website maintenance

Once a business has set up its website, it requires maintenance, just like any other part
of the firm‟s operations. Unless the website only offers the very minimum in
information, it will need to be refreshed, updated and corrected on a regular basis. How
this is done will partly depend on whether the business built its own website, or used
an external agency to do it.

External agency

If the firm used an external web agency to build its website, then it should consider
having a maintenance agreement with that agency to carry out such amendments and
modifications as are needed.

Internally-built website

If the business built its own website, then it will be necessary for someone internally to
allow time to keep the information up to date.

Whether managed internally or externally, the key areas that must be refreshed include:

o Changes in address or telephone numbers.

o New branding, logos and so on.

o The catalogue (if any) must be kept up to date, including new products and removing
any that are no longer offered - this can be helped by having a catalogue that shows
whether the product is in stock or not. Some potential customers will not bother to place
an order for something listed as out of stock, so some businesses choose not to disclose
this as long as they can get hold of stock quickly. o Businesses that use their website

41
 extensively will tend to keep it refreshed with news of new products, promotions, events
and so on.
o A key feature of many website packages is to have a message that states when the
website was last updated, so that loyal customers can look out for what‟s new.

o Another useful feature is the number of visitors counter, so that everyone can see how
popular the website is (or is not!).

o External links - it is worthwhile checking all links regularly to ensure that they are still
all current.

Website statistics & diagnostics

The ISP or the website package itself will provide a certain level of information about
usage levels of the various sections of the site. Typically, reports can also be provided
about „broken links‟ where links within the website or to external sits are no longer
working properly.

Monitoring service levels

The ISP will provide reports on any downtime that has affected the website, and it is
also possible to sign up for external services that regularly test the website across the
Internet to draw attention to any downtime.

Search Engines

See the note on promoting a business online. It will be necessary to re-advise search
engines of the website so that it keeps coming up on searches. It is possible to purchase
software that does this on the firm‟s behalf.

Review of Promotion

See the note on promoting a business online. Again, the promotional strategy should be
reviewed regularly in the light of performance – there are plenty of other possibilities
if the current strategy is not cost-effective.

42
 Finding and Suggestion
The primary objective of this project, Recommending Dynamic Web Design for the
my customer via Web 2.0 and dynamic web design. The way we did this was to
evaluate our website subjectively and objectively. With the results gathered from the
evaluation of the site, a template was created incorporating features we deemed
helpful to reaching our goal.

A survey was posted on the City‟s website, its Facebook fan page, allowing us to gain
user input on the website. Finally, online validation tools were used to verify if jikus
automobile was abiding by the W3C guidelines. This set of evaluations allowed us to
assess the City‟s website through a user‟s perspective, compare it to other government
websites, as well as making sure the website complies with W3C accessibility
regulations.
We then created a functional template with the combination of our research and
findings, incorporating the possible changes that we believe could be added to the
City‟s website. The creation of this template was to visually incorporate Web 2.0
features not yet implemented on the current website, along with the addition of
accessibility considerations. It was not made specifically as a direct replacement for
[Link], but instead as a visual representation of our findings and what could
theoretically be done. We recommend a gradual addition of our possible improvements
(as described in our findings section) along with polls to gauge feedback on each
change. If the features are implemented in this manner, the users will have a voice in
the new features being added and any unpopular changes can easily be modified or
removed. This allows a more democratic feel to the alterations of the website, leaving
users to measure the successes and failures of our recommendations.
The template that we created was then the focus of evaluations. Though the scope of
our project only allowed us to evaluate the template objectively, it was a critical part of
our project. The evaluations of the template allowed us to give Boston‟s
MIS department a template with credible evaluations. 71
Future work
In the future there are several things that could be done in order to build off of the work
that we completed for this project. By gaining more feedback from users and learning
from the successes and failures of the template that we created, jikus automobile could
become a more dynamic site that encourages civic engagement. To gain more feedback

43
 from users, another survey, with questions similar to the ones that we asked, could be
conducted. However, we recommend that this survey be completed over a longer period
of time as well as the promotion of its existence, thus allowing for more participation
than we had in our survey. By obtaining more feedback, it would be possible to obtain
a broader opinion of the user perspective of the current site. This would allow the MIS
Department to make decisions about changes in the site that would reflect a larger
portion of the population.

Bibilography Book

Websites

1. [Link]
2. [Link]
3. [Link]
4. [Link]
5. [Link]
6. [Link]
7. [Link]
8. [Link]

44