Overview of the system:
Now a day the usage of credit cards has dramatically
increased. As credit card becomes the most popular mode of payment for both
online as well as regular purchase, cases of fraud associated with it are also
rising. In this paper, we model the sequence of operations in credit card
transaction processing using a Hidden Markov Model (HMM) and show how it can be
used for the detection of frauds. An HMM is initially trained with the normal
behavior of a cardholder. If an incoming credit card transaction is not
accepted by the trained HMM with sufficiently high probability, it is
considered to be fraudulent. At the same time, we try to ensure that genuine
transactions are not rejected. We present detailed experimental results to show
the effectiveness of our approach and compare it with other techniques
available in the literature
Areas of
Selections:
Front
End: Visual Studio 2005(VB.NET 2.0)
Back
End: MS SQL SERVER 2005.
Functional requirements:
The
functional requirement describes the interaction between the system and its
environment independent of its implementation. The environment includes the
user and any other external system with which the system interacts.
2.3.1 Actors:
Actors are external
entities that interact with the system. Actors typically include a user role or
another system. They have unique names and descriptions.
Server
Client
2.3.2 Use
cases:
Use case used
during requirements elicitation and analysis to represent the functionality of
the system. Use case describes a function provided by the system that yields a
visible result for an actor.
The identification of actors and Usecase results in the
definition of the boundary of the system that is, differentiating the tasks
accomplished by the system and the tasks accomplished by its environment. The
actors are outside the boundary of the system, where as the Usecase are inside
the boundary of the system.
Use cases describe the
behavior of the system as seen from the actor’s point of view. It describes the
function provided by the system as a set of events that yield a visible result
for the actors.
Actors initiate the use
cases for accessing system’s functionality. When actors and use cases exchange
information, they are said to Communicate. To describe a use case we use
a template composed of six fields:
Use Case Name: The name of the use case
Participating Actors: The actors participating in the particular
use case
Entry Condition: Condition for initiating the use case.
Flow of events: Sequence of steps
describing the functioning of use case.
Exit Condition: Condition for terminating the use case.
Quality
Requirements: Requirements that do not belong to the use case but Constraint
the functionality of the system
Use case diagrams include four types of
relations. They are as follows:
Communication Relationships
Inclusion Relationships
Extension Relationships
Inheritance Relationships
No comments:
Post a Comment