Software Requirement Specification Template

Table of Contents

1. Introduction
1.1 Purpose
1.2 Scope of Project
1.3 Intended Audience
1.4 References
2. Overall description
2.1 Product Perspective
2.2 User Classes and Characteristics
2.3 Operating Environment
2.4 Design and Implementation Constraints
2.5 Assumptions and dependencies
3. Requirement Specification
3.1 Functional Requirements
4. Nonfunctional Requirements
4.1 Performance requirements
4.2 Safety requirements
4.3 Security Requirements
4.4 Software Quality Attributes
4.5 User Documentation

5. External Interface Requirements

5.1 User Interfaces
5.2 Hardware Interfaces
5.3 Software Interfaces
5.4 Communications Interfaces

6. Other Requirements
Appendix A: Glossary
Appendix B: To-Be-Determined List

Revision History
Requirement ID Date Of Reason For Changes Version
revision
1.Introduction:

1.1 Purpose

To build a content based semantic search engine to produce accurate and specific
search results and to reduce the ambiguity involved in the search results produced by
the normal search engine.

1.2 Scope of the project

Our project has its scope across various fields of business and technology like
accountancy, medical applications, news reports, real property systems, television
applications, video gaming applications, multimedia applications, mapping applications, etc..

1.3 Intended Audience

The intended audience for our SRS report are we (the implementers of semantic search
engine), the intended users of our product ( day-to-day internet users, business analysts,
research people, professionals in various fields, etc.), our project guide, our project
evaluators and listeners of our project demonstration ( fellow-mates of our project lab), etc.

1.4 References

Reference: 1) Semantic search engine – Wolfram Alpha, Kngine, Hakia, Kosmix,

DuckDuckGo, etc..
2) Link for reference: http://www.wolframalpha.com/,
http://www.wolframalpha/examples/Math.html.
3) Mobile wolfram alpha that gives you access to the world’s facts without
searching ( http://m.wolframalpha.com/).

2. Overall description

2.1 Product Perspective

Tim Berners Lee introduced the idea of semantic search in the web. We are collecting ideas
from the semantic search engine – wolfram alpha (current version). This idea is not a completely
new idea, but, it is the introduction of a semantic search engine that provides content-based,
accurate and specific search results as compared to the normal search engine (google, etc.). We
are implementing a part of the huge semantic search engine (topics like mathematics, physics,
chemistry, geography and so on).

2.2 User Classes and Characteristics

The end users of the proposed system are the people in general who query the
search engine to obtain their required search results, the database administrators who
administer the database by adding, deleting, updating, replacing and changing the
properties related to the data, etc.
2.3 Operating Environment

For our project, we require the internet facility as one of the most essential operating
environment. Apart from that, we require hardware facility such as computer (desktop, laptop or
palmptop, etc.), modem for connecting to the internet, hard disk (160 GB), RAM (2 GB) and
speakers if necessary.
Software requirements include an operating system, specifically Windows XP and other essential
components like Visual Studio for .NET programming, mysql database, data mining tool and so
on.

2.4 Design and Implementation Constraints

• Vastness: Existing technology of semantic web has not been able to eliminate all
semantically duplicated terms.
• Uncertainty: These are precise concepts with uncertain values. E.g. A patient might
present a set of symptoms which might correspond to a different diagnosis with different
probabilities.
• Doubling output formats: Another criticism of the semantic web is that it would be much
more time-consuming to create and publish content because there would need to be two
formats for one piece of data: one for human viewing and one for machines.

2.5 Assumptions and dependencies

2.5.1 Assumptions

The data stored in the database will be confined by us to some areas of our
interest unlike the already existing semantic search engines in the web.

2.5.2 Dependencies

1. Our project basically relies on the data mining concept.

2. During the implementation of our project, we have to rely on some ideas
related to the data mining concepts from already implemented data mining
projects or ones who are carrying out their project on this concept.

3. Requirement Specification

3.1 Functional Requirements

• User shall be able to get specific and accurate output for a given input specified.
• User shall be able to easily access the required results without having to search
through a huge number of pages.
• User shall be able to access their results in a page ranked fashion according to
priority.
• User shall be able to obtain content based search instead of keyword (tag-line)
based search.
4. Nonfunctional Requirements

4.1 Performance requirements

1. Dealing with complex queries: In contrast with existing semantic-based

keyword search engines which answer only simple queries, our search engine
allows end users to ask simple queries and provide the end users with specific
results.
2. Quick response: Our semantic search engine should provide as quick response
to user queries, thus encouraging ordinary end users to harvest the benefits of
semantic web technology. This requires that we make the mechanism of the
semantic search as simple as possible.
3. Precise and self-explanatory results: Our semantic search engine precise
search results that on the one hand satisfy user queries, and on the other hand
are self-explanatory. Thus, ordinary end users can understand the results (e.g.
what they are and why they are) without having to consult the back end semantic
data repositories or their underlying ontologies.

4.2 Security Requirements

1. Any external person (user) should not be able to access, alter or manipulate
the database apart from the database administrator.
4.3 Software Quality Attributes

1. Low barrier to access for ordinary end users: Our semantic search should be
able to overcome the problem of knowledge overhead and ensure that ordinary end
users are able to use it without having to know the vocabulary or structure of the
ontology or having to master a special query language.
2. The ontology serves as the control vocabulary to make semantic suggestions such as
synonyms, related concepts to facilitate query and search.

4.4 User Documentation

In semantic search engine, end user is able to obtain precise and accurate results for
his search. This is achieved by content-based search facility provided by the semantic
search engine. As compared to the normal search engine, this is comparatively better
because it avoids the routine tag-line based searching engine that displays junk
(unnecessary) results.
As you can see in the figures above, the specifity of the search results obtained by
the semantic search engine as compared to the normal search engine.

5. External Interface Requirements

5.1 User Interfaces

The user interface provided by us includes a text box for the user to enter the query,
search button for the user to query his search results. The user also should be provided with
suggesion links in case of multiple occurrences of results in the database for a single query.
The user also should be provided with the textbox for sending feedback to us so that further
improvement could be done.

5.2 Software Interfaces

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

5.3 Communications Interfaces

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

6. Other Requirements

Define any other requirements that are not covered elsewhere in the SRS, such as
internationalization requirements or legal requirements. You could also add sections on
operations, administration, and maintenance to cover requirements for product installation,
configuration, startup and shutdown, recovery and fault tolerance, and logging and
monitoring operations. Add any new sections to the template that are pertinent to your
project. If you don’t have to add any other requirements, omit this section.

Appendix A: Glossary

Define all the terms necessary for a reader to properly interpret the SRS, including
acronyms and abbreviations. You might wish to build a separate glossary that spans
multiple projects for the entire organization and include only terms that are specific to a
single project in each SRS.

Appendix B: To-Be-Determined List

Compile a numbered list of the TBD (to be determined) references that remain in the SRS
so that they can be tracked to closure.