Assignment 1: Software Requirement Development

2. Software Requirement Engineering Process :-

(1) The four main activities in the requirements engineering process is -

 Requirement Elicitation
 Requirement Analysis
 Requirement Specification
 Requirement Validation

(2) Three requirement elicitation are-

 Interviews : Interviews can be performed one-on-one or with a small group of
stakeholders. They are an effective way to elicit requirements without taking too
much stakeholder time because you meet with people to discuss only the specific
requirements that are important to them.

 Workshops : Facilitated requirements-elicitation workshops that permit

collaboration between analysts and customers are a powerful way to explore user
needs and to draft requirements documents. Such workshopsare sometimes
called Joint Application Design, or JAD, sessions. 

 Questionnaires: Questionnaires are useful with any large user population but are
particularly helpful with distributed groups. Additional elicitation efforts can then
be focused according to the questionnaire results.

3. Functional and Non-functional Requirements:

(1) Functional Requirements:- Functional requirements specify the behaviors the

product will exhibit under specific conditions.
 This alignment among the three levels of requirements is essential for project success.
Functional requirements often are written in the form of the
traditional “shall” statements: “The Passenger shall be able to print boarding passes for all
flight segments for which he has checked in” or “If the Passenger’s profile does not indicate
a seating preference, the reservation system shall assign a seat.”

Non-Functional Requirements:- A description of a property or characteristic that a

system must exhibit or a constraint that it must respect. Other-than-functional
requirements might specify not what the system does, but rather how well it does those
things. These include the system’s availability, usability, security, performance, and many
other characteristic. Some people consider nonfunctional requirements to be synonymous
with quality attributes, but that is overly restrictive.

(2) Four functional requirements:-

 When the user presses the start button, a menu should be displayed.
 Send the message to user to select a destination.
 After the order is placed, the ticket fare should be shown on the screen.
 The ticket is issued after the payment is completed.

(3) Four non-functional requirements for the ticket-issuing system:-

 After the customer presses a button on the machine, the display should
be updated within 0.5 seconds.
 The ticket issuing time after credit card validation has been received
should not exceed 10 seconds.
 When validating credit cards, the display should provide a status message
for customers indicating that activity is taking place.
 The maximum acceptable failure rate for ticket issue requests is 1: 10000.
4. Use Cases:

1) System startup use case:

 The system is started up when the operator turns the operator switch to the
"on" position.
 The operator will be asked to enter the amount of money currently in the
cash dispenser, and a connection to the bank will be established. Then the
servicing of customers can begin.
2) System Shutdown Use Case:
 The system is shut down when the operator makes sure that no customer is
using the machine, and then turns the operator switch to the "off" position.
 The connection to the bank will be shut down. Then the operator is free to
remove deposited envelopes, replenish cash and paper, etc.

3) Session Use Case:

 A session is started when a customer inserts an ATM card into the card
reader slot of the machine.
 The ATM pulls the card into the machine and reads it.

4) Transaction Use Case:

 A transaction use case is started within a session when the customer chooses
a transaction type from a menu of options.
 The customer will be asked to furnish appropriate details (e.g. account(s)
involved, amount). The transaction will then be sent to the bank, along with
information from the customer's card and the PIN the customer entered.

5) Withdrawal Transaction Use Case:

 A withdrawal transaction asks the customer to choose a type of account to
withdraw from.
 The system verifies that it has sufficient money on hand to satisfy the request
before sending the transaction to the bank.

6) Deposit Transaction Use Case:

 A deposit transaction asks the customer to choose a type of account to
deposit from a menu of possible accounts, and to type in a dollar amount on
the keyboard.
 The transaction is initially sent to the bank to verify that the ATM can accept a
deposit from this customer to this account. If the transaction is approved, the
machine accepts an envelope from the customer containing cash and/or
checks before it issues a receipt.

7) Transfer Transaction Use Case:

 A transfer transaction asks the customer to choose a type of account to
transfer from a menu of possible accounts, to choose a different account to
transfer to, and to type in a dollar amount on the keyboard.
 No further action is required once the transaction is approved by the bank
before printing the receipt. A transfer transaction can be cancelled by the
customer pressing the Cancel key any time prior to entering a dollar amount.
8) Inquiry Transaction Use Case:
 An inquiry transaction asks the customer to choose a type of account
toinquire about from a menu of possible accounts.
 No further action is required once the transaction is approved by the
bankbefore printing the receipt.

9) Invalid PIN Extension:

 An invalid PIN extension is started from within a transaction when the
bank reports that the customer's transaction is disapproved due to an
invalid PIN.
 The customer is required to re-enter the PIN and the original request is
sentto the bank again.