ANALYSIS OF VIPANI
Analysis is a process of
identifying the conceptual items and properties necessary for a solution to be
both correct and proper. Our approach partitions the analysis process into two
phases:
Requirements Analysis and Domain Analysis: During the requirements analysis, we
reformulate and expand an informal set
of requirements into a more formal description. This transformation is done gradually
through use cases. Use cases offer a systematic and intuitive way to capture
the functional requirements with particular focus on the value added to each
individual user or to each external system. Use cases play a key role in
driving the rest of the development work and that is the important reason for
their acceptance in most approaches to modern software engineering.
We expect VIPANI to have the following
stakeholders:
· Buyer
· Supplier
· Administrator
SR3.1.1.1
Buyers
must be able to login, change passwords, and browse ‘relevant’ parts of the system.
SR3.1.1.2
They
should be able to check the status of ongoing auctions created by them.
SR3.1.1.3
They
should be able to create new auctions, and modify the rules of a predefined auction
before it has started.
SR3.1.1.4
They
should be able to close the auction.
SR3.1.1.5
They
should be able to define new auction formats.
SR3.1.1.6
They
should be able to browse a vendor catalogue and select vendors who could be
invited to participate in an auction.
SR 3.1.2
Buying Agent
SR 3.1.2.1
A
buying agent is a software agent capable of carrying out some of the actions on
behalf of the buyer. Specifically, the
buying agent should be able to check the status of an auction created by a
buyer; query the bids submitted to the auction; and query the interim
allocations and final allocations of the auction.
SR 3.1.2.2
The
services should be offered via secure, authenticated means.
SR 3.1.3
Seller
SR3.1.3.1
Supplier
should be able to register for an auction, browse the list of auctions he/she
is permitted to see by the buyer, change access passwords, and submit bids for
registered auctions.
SR3.1.3.2
The
supplier should be able to respond to an RFQ either through an online interaction
or by means of a message.
SR3.1.3.3
She
should be able to submit various types of bids based upon the auction type.
SR3.1.3.4
She
should be able to check the status of the auctions that she is registered for.
SR 3.1.3
System
Administrator
SR3.1.3.1
The
System Admin sets up profiles for buyers and sellers (market participants).
SR3.1.3.2
He
should be able to add new products to the existing Catalogue.
SR3.1.3.3
He
should be able to remove products from the Catalogue.
3.2 USE CASE MODEL
A
use case model describes what the system does for each type of user and
provides the essential input for analysis, design, and testing. It is a
top-level view of the system and shows the actors, use cases, and their
relationships. The actors are entities that interact with the system. From an
understanding of the users of the system, we have identified the following
actors: Buyer,
Seller, Monitor. The use cases are complete functionalities as perceived by an actor.