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. Interviews are helpful to separately elicit
requirements from people in preparation for workshops where those people come
together to resolve any conflicts.

➢ 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 (Gottesdiener 2002). Such workshops
are sometimes called Joint Application Design, or JAD, sessions (Wood and Silver
1995).

➢ Questionnaires: Questionnaires are a way to survey large groups of users to

determine what they need. Questionnaires are useful with any large user
population but are particularly helpful with distributed groups. If questions are well
written, questionnaires can help you quickly determine analytical information
about needs. 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. They describe what the developers must
implement to enable users to accomplish their tasks (user requirements), thereby satisfying
the business requirements. 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.” (ref:SRE 3rd edition Book )

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. Non functional requirements could describe important characteristics or properties
of the system. 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. For example, design and
implementation constraints are also nonfunctional requirements, as are external interface
requirements.
(ref: Software Requirements book 3rd Edition)

(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.
(ref: from Google)
4. Use Cases:

( Pic courtesy : http://www.math-cs.gordon.edu/ )

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 to
inquire about from a menu of possible accounts.
• No further action is required once the transaction is approved by the bank
before 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 sent
to the bank again.