Download as pdf or txt
Download as pdf or txt
You are on page 1of 8

Software Engineering Laboratory

(BITCSC492)

Lab Report Submitted to


Maulana Abul Kalam Azad University of Technology,
West Bengal
for

Department of Information Technology

B.Sc.
In
IT (Cyber Security)

Submitted by

Trisha Sarkar
(Roll no.: 30085320013)

Course Faculty
Ms. Dipanwita Ghosh

Maulana Abul Kalam Azad University of Technology, West Bengal


Simhat, Haringhata, Nadia, Pin-741249
Assignment – 1

Experiment name -- Identifying the Requirements from


Problem Statements.

Objectives – Here our Problem Statement is Online Auction


System.
1) Learn about the three different aspects that have to be taken
care of while writing requirements specification.
2) Identifying different functionaries to be obtained from a
system.

3) Identifying characteristics that a system should have, but not


done by the system itself.

Introduction -- Requirement’s identification is the first step of


any software development project. Until the requirements of a
client have been clearly identified, and verified, no other task
(design, coding, testing) could begin. Usually, business analysts
having domain knowledge on the subject matter discuss with
clients and decide what features are to be implemented. In this
experiment we will learn how to identify functional and non-
functional requirements from a given problem statement.
Functional and non-functional requirements are the primary
components of a Software Requirements Specification.

Experiment 1 -- New users can register to the system through


an online process. By registering a user agrees to abide by
different pre-defined terms and conditions as specified by the
system. Any registered user can access the different features of
the system authorized to him / her, after he authenticates
himself through the login screen. An authenticated user can put
items in the system for auction. Authenticated users can place
bid for an item. Once the auction is over, the item will be sold
to the user placing the maximum bid. Payments are to be made
by third party payment services, which, of course, is guaranteed
to be secure. The user selling the item will be responsible for its
shipping. If the seller thinks he's getting a good price, he can,
however, sell the item at any point of time to the maximum
bidder available.
Experiment 1 results –

Conclusion –
In experiment 1,
a. We can see that there’s no specification when an auction
gets over which is the reason of unclearness. The fact it
therefore possibly causes confusion by having more than
one possible meaning.
b. Now another thing that we’ve learnt, is that an item is said
to be sold to the max bidder after auction is over, or it can
be sold before the auction is over which is unpredictable.
That means it doesn’t stay the same throughout.
c. And lastly, this experiment isn’t having necessary parts
because of no mention of how a new user registers, no
mention of any dispute regarding the sold product and no
mention of what kind of products could be part of auction.

Experiment 2 – New users can register to the system through


an online process. By registering a user agrees to abide by
different pre-defined terms and conditions as specified by the
system. Any registered user can access the different features of
the system authorized to him / her, after he authenticates
himself through the login screen. An authenticated user can put
items in the system for auction. Authenticated users can place
bid for an item. Once the auction is over, the item will be sold to
the user placing the maximum bid. Payments are to be made by
third party payment services, which, of course, is guaranteed to
be secure. The user selling the item will be responsible for its
shipping. If the seller thinks he's getting a good price, he can,
however, sell the item at any point of time to the maximum
bidder available.
Experiment 2 results –

Conclusion –
In experiment 2,
a. We learnt that, functional requirements could be obtained
from the requirements specifications:
i. Registration
ii. User Login
iii. Upload item for auction
iv. Auction item
v. Bid for item
vi. Win Auction
vii. Ship Item
viii. Remove item
ix. Remove auctioned item
Experiment 3 -- New users can register to the system through
an online process. By registering a user agrees to abide by
different predefined terms and conditions as specified by the
system. Any registered user can access the different features of
the system authorized to him / her, after he authenticates
himself through the login screen. An authenticated user can put
items in the system for auction. Authenticated users can place
bid for an item. Once the auction is over, the item will be sold
to the user placing the maximum bid. Payments are to be made
by third party payment services, which, of course, is guaranteed
to be secure. The user selling the item will be responsible for its
shipping. If the seller thinks he's getting a good price, he can,
however, sell the item at any point of time to the maximum
bidder available.

Experiment 3 result –
Conclusion –
In experiment 3,
a. We learnt that, possible non-functional requirements
could be identified from the requirements specifications
i. The system should remain up and running throughout
its working hours.
ii. Sessions of different users mustn’t affect each other.
iii. System should maintain privacy of their users and
should not leak their information to third parties.
iv. System could remain unavailable for up to 2 hours for
maintenance once in a quarter with 36 hour prior
notice.

-----------

You might also like