Software Requirements

Specification
for

<Project>

Version 1.0

Prepared by <author>

<organization>

<date created>
Software Requirements Specification for <Project> Page ii

Table of Contents

Table of Contents...........................................................................................................................ii
1. Introduction..............................................................................................................................1
1.1 Purpose...........................................................................................................................................1
1.2 Document Conventions..................................................................................................................1
1.3 Intended Audience and Reading Suggestions.................................................................................1
1.4 Product Scope.................................................................................................................................1
1.5 References.......................................................................................................................................1
2. Overall Description..................................................................................................................2
2.1 Product Perspective........................................................................................................................2
2.2 Product Functions...........................................................................................................................2
2.3 User Classes and Characteristics.....................................................................................................2
2.4 Operating Environment...................................................................................................................2
2.5 Design and Implementation Constraints.........................................................................................2
2.6 User Documentation.......................................................................................................................2
2.7 Assumptions and Dependencies......................................................................................................3
3. External Interface Requirements...........................................................................................3
3.1 User Interfaces................................................................................................................................3
3.2 Hardware Interfaces........................................................................................................................3
3.3 Software Interfaces.........................................................................................................................3
3.4 Communications Interfaces............................................................................................................3
4. System Features.......................................................................................................................4
4.1 System Feature 1............................................................................................................................4
4.2 System Feature 2 (and so on)..........................................................................................................4
5. Other Nonfunctional Requirements.......................................................................................4
5.1 Performance Requirements.............................................................................................................4
5.2 Safety Requirements.......................................................................................................................5
5.3 Security Requirements....................................................................................................................5
5.4 Software Quality Attributes............................................................................................................5
5.5 Business Rules................................................................................................................................5
6. Other Requirements................................................................................................................5
Appendix A: Analysis Models.......................................................................................................5
Software Requirements Specification for <Project> Page 1

1. Introduction

1.1 Purpose
The purpose of this document is to define the requirements of credit card fraud detection. In detail,
this document will provide a general description of our project, including user requirements,
product perspective, and overview of requirements, general constraints. In addition, it will also
provide the specific requirements and functionality needed for this project - such as interface,
functional requirements and performance requirements.

1.2 Document Conventions

<Describe any standards or typographical conventions that were followed when writing this SRS,
such as fonts or highlighting that have special significance. For example, state whether priorities
for higher-level requirements are assumed to be inherited by detailed requirements, or whether
every requirement statement is to have its own priority.>

1.3 Intended Audience and Reading Suggestions

<Describe the different types of reader that the document is intended for, such as developers,
project managers, marketing staff, users, testers, and documentation writers. Describe what the
rest of this SRS contains and how it is organized. Suggest a sequence for reading the document,
beginning with the overview sections and proceeding through the sections that are most pertinent
to each reader type.>

1.4 Product Scope

The scope of this SRS document persists for the entire life cycle of the project. This document
defines the final state of the software requirements agreed upon by the customers and designers.
Finally at the end of the project execution all the functionalities may be traceable from the SRS to
the product. The document describes the functionality, performance, constraints, interface and
reliability for the entire life cycle of the project.

1.5 References
<List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document. Provide enough information so that the reader could
access a copy of each reference, including title, author, version number, date, and source or
location.>
Software Requirements Specification for <Project> Page 2

2. Overall Description

2.1 Product Perspective

<Describe the context and origin of the product being specified in this SRS. For example, state
whether this product is a follow-on member of a product family, a replacement for certain existing
systems, or a new, self-contained product. If the SRS defines a component of a larger system,
relate the requirements of the larger system to the functionality of this software and identify
interfaces between the two. A simple diagram that shows the major components of the overall
system, subsystem interconnections, and external interfaces can be helpful.>

2.2 Product Functions

The project is guaranteed to provide reliable results and the functionality of the product to detect
the fraud transactions effectively and provide flexibility to the user in a secured and accurate
manner.

2.3 User Classes and Characteristics

The user of the system are classified as customers and administrator,
Customers are those who make the transaction through any means.
Administrator who computes on the transaction and reports about the fraud usage

2.4 Operating Environment

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

2.5 Design and Implementation Constraints

The application is completely written Java. This enables the credit card issuers to use this
application across wide variety of devices independent of the vendor of the devices. We use oracle
as a back end for storing database.
The above architecture describes the work structure of the system. The customer data in the data
warehouse is subjected to the rules engine which consists of the fraud rule set. The filter and
priority module sets the priority for the data and then sends it to the genetic algorithm which
performs its functions and generates the output.

2.6 User Documentation

<List the user documentation components (such as user manuals, on-line help, and tutorials) that
will be delivered along with the software. Identify any known user documentation delivery formats
or standards.>
Software Requirements Specification for <Project> Page 3

2.7 Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated
in the SRS. These could include third-party or commercial components that you plan to use,
issues around the development or operating environment, or constraints. The project could be
affected if these assumptions are incorrect, are not shared, or change. Also identify any
dependencies the project has on external factors, such as software components that you intend
to reuse from another project, unless they are already documented elsewhere (for example, in the
vision and scope document or the project plan).>

3. External Interface Requirements

3.1 User Interfaces

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

3.2 Hardware Interfaces

Processor type : Pentium III-compatible processor or faster.
Processor speed : Minimum: 1.0 GHz, Recommended: 2.0 GHz or faster
RAM : 512 MB or more
HARD DISK : 20GB or more
Monitor : VGA or higher resolution 800x600 or higher resolution
Pointing device : Microsoft Mouse or compatible pointing device
CD-ROM : Actual requirements will vary based on system configuration and the applications and
features chosen to install.

3.3 Software Interfaces

Application software Framework : Java
Back End : SQL Server
Operating System : Windows XP Professional or more

3.4 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.>
Software Requirements Specification for <Project> Page 4

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

4.1 System Feature 1

<Don’t really say “System Feature 1.” State the feature name in just a few words.>
4.1.1 Description and Priority
<Provide a short description of the feature and indicate whether it is of High, Medium, or
Low priority. You could also include specific priority component ratings, such as
benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 to a
high of 9).>
4.1.2 Stimulus/Response Sequences
<List the sequences of user actions and system responses that stimulate the behavior
defined for this feature. These will correspond to the dialog elements associated
with use cases.>
4.1.3 Functional Requirements
<Itemize the detailed functional requirements associated with this feature. These are the
software capabilities that must be present in order for the user to carry out the
services provided by the feature, or to execute the use case. Include how the
product should respond to anticipated error conditions or invalid inputs.
Requirements should be concise, complete, unambiguous, verifiable, and
necessary. Use “TBD” as a placeholder to indicate when necessary information is
not yet available.>

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

tag of some kind.>

REQ-1:
REQ-2:

4.2 System Feature 2 (and so on)

5. Other Nonfunctional Requirements

5.1 Performance Requirements

Performance requirements tells about the software capability to respond on users’ action such as:
Upon running the application, it shouldn’t take more than 3 seconds. Data validation shouldn’t take
above 5 seconds. Result generation should be achieved within 5 seconds.
Software Requirements Specification for <Project> Page 5

5.2 Safety Requirements

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

5.3 Security Requirements

The project provides a security to different kind of customers by means of authentication level. The
authorization mechanism of the system will block the unwanted attempts to the server

5.4 Software Quality Attributes

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

5.5 Business Rules

<List any operating principles about the product, such as which individuals or roles can perform
which functions under specific circumstances. These are not functional requirements in
themselves, but they may imply certain functional requirements to enforce the rules.>

6. Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the
project, and so on. Add any new sections that are pertinent to the project.>

Appendix A: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>