2. 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 like1. 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.
3. Records are not to be maintained for a long time.
2
3. 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.
ii.
iii.
iv.
For help in keeping the record of customer.
For help in make awareness in online purchasing.
For help in reduce the time and money.
For easily day-to-day new products updating.
(c)Scope of work
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.
3
5. 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.
i.
ii.
iii.
iv.
Provide fully computerized purchasing system.
Dynamic search engine.
Complete day-to-day stock status.
Complete day-to-day registered customer‟s report.
5
7. 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.
(b) 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.
7
8. (c) Hardware and software requirements
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
8
10. 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 software.At 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.
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 testing.But for a significant size software development trial and error
method will be expensive.This 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 developers.The 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..etc.etc. 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.
10
11. 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
met.Concept 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.
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
11
12. 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.
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:
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.
12
13. The actual amount of steps varies according to the person describing them, but
they always cover the same steps.
1.
2.
3.
4.
5.
6.
7.
Specify the Requirement
Data Analysis
Problem Analysis
Algorithm
Coding
Testing
Maintenance
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.
13
14. 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.
14
15. The different phases of software life cycle development are:
Types of Software developing life cycles (SDLC)
1.Waterfall 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.
15
16. Following is a diagrammatic representation of different phases of waterfall model.
fgreg
rrggs
gs
16
17. 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.
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.
2.Spiral Model The spiral model combines the idea of iterative development with
the systematic, controlled aspects of the waterfall model.
17
18. 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 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:
18
19. Based on the customer evaluation, software development process enters into the
next iteration and subsequently follows the linear approach to implement the
feedback 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.
19
20. 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 extent of taking change requests is very important to develop and deploy
the product successfully.
20
21. (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?
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.
21
22. 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.
22
23. Example of an Operational Feasibility Study
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?
23
24. (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
• 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
iii.Technical 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.
iv.Legal 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.
24
25. 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
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.
25
26. 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
26
27. Overview
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.
27
28. 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.
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.
28
29. 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.
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.
29
30. 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.
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.
30
31. 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.
31
32. Provide online Tax Calculations
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.
32
33. Offer financing options.
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.
33
34. Accessibility
The system shall provide handicap access.
The system shall provide multi language support.
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.
34
35. 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.
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.
35
36. 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
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.
36
37. Interfaces
There are many types of interfaces as such supported by the E-Store software
system namely; User Interface, Software Interface and Hardware Interface.
The protocol used shall be HTTP.
The Port number used will be 80.
There shall be logical address of the system in IPv4 format.
User Interfaces
The user interface for the software shall be compatible to any browser such
as Internet Explorer, Mozilla or Netscape Navigator by which user can
access to the system.
The user interface shall be implemented using any tool or software package
like Java Applet, MS Front Page, EJB etc.
Hardware Interfaces
Since the application must run over the internet, all the hardware shall
require to connect internet will be hardware interface for the system. As for
e.g. Modem, WAN – LAN, Ethernet Cross-Cable.
Software Interfaces
1. The e-store system shall communicate with the Configurator to identify
all the available components to configure the product.
2. The e-store shall communicate with the content manager to get the
product specifications, offerings and promotions.
3. The e-store system shall communicate with billPay system to identify
available payment methods , validate the payments and process payment.
4. The e-store system shall communicate to credit management system for
handling financing options.
5. The e-store system shall communicate with CRM system to provide
support.
37
38. 6. The e-store system shall communicate with Sales system for order
management.
7. The e-store system shall communicate with shipping system for tracking
orders and updating of shipping methods.
8. The e-store system shall communicate with external Tax system to
calculate tax.
9. The e-store system shall communicate with export regulation system to
validate export regulations.
10. The system shall be VeriSign like software which shall allow the users to
complete secured transaction. This usually shall be the third party software
system which is widely used for internet transaction.
Communications Interfaces
The e-store system shall use the HTTP protocol for communication over the
internet and for the intranet communication will be through TCP/IP protocol
suite.
Licensing Requirements
Not Applicable
Legal, Copyright, and Other Notices
E-store should display the disclaimers, copyright, word mark, trademark and
product warranties of the JIKUS AUTOMOBILE.
Applicable Standards
It shall be as per the industry standard.
38
39. 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 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.
39
40. 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.
The model's linguistic aspect described above is utilized in
the declarative database query
language ERROL,
which
mimics natural
language constructs. ERROL's semantics and implementation are based
on reshaped relational algebra (RRA), a relational algebra which is adapted to the
entity–relationship model and captures its linguistic aspect.
40
41. Entities and relationships can both have attributes. Examples: an employee entity
might have a Social Security Number (SSN) attribute; the proved relationship may
have a date attribute.
Every entity (unless it is a weak entity) must have a minimal set of uniquely
identifying attributes, which is called the entity's primary key.
Entity–relationship diagrams don't show single entities or single instances of
relations. Rather, they show entity sets and relationship sets. Example: a
particular song is an entity. The collection of all songs in a database is an entity set.
The eaten relationship between a child and her lunch is a single relationship. The
set of all such child-lunch relationships in a database is a relationship set. In other
words, a relationship set corresponds to a relation in mathematics, while a
relationship corresponds to a member of the relation.
Certain cardinality constraints on relationship sets may be indicated as well.
41
43. 1st LEVEL DATAFLOW DIAGRAM
REGISTER
CUSTOMER NAME
&PASSWORD
UESR
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.
e. Physical Design (Coding):
43
48. (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.
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.
2.
3.
4.
5.
The identification of functions that the software is expected to perform
The creation of input data based on the function's specifications
The determination of output based on the function's specifications
The execution of the test case
The comparison of actual and expecte
48
49. (ii).Structural Testing
The structural testing is the testing of the structure of the system or component.
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.
49
50. (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
50
51. 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.
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.
51
52. 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 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.
52
53. 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
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.
53
54. With a test management tool it‟s easy to create and maintain references to
requirements, test cases, and defect reports.
Version
The field for Version contains the test case version number (not the system version
number!). It‟s used because the conditions for the test case may change when the
test case changes.
A defect might not be caused by a problem in the system, but by the tester using an
outdated version of the test case.
Author
The (first and last) name of the person who wrote the test case. People reading the
test case may want to contact the author to ask questions or get clarification.
Subsystem/functional area
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.
54
55. 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.
Actual results (outcome)
Either “Approved” or the ID number of the defect report.
Name or signature
Details about which tester conducted the test case.
Date
Date the test case was performed.
55
56. 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 extensively will tend to keep it refreshed
with news of new products, promotions, events and so on.
56
57. 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.
57
59. 5.Conclusion and Future Work
Conclusions
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 CityOfBoston.gov, 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
59
60. 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 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.
60
