1. Muhammad Ahmad Kahloon

2. Example: Software Design Specifications Auto teller machine

3. 1. Introduction
1.1 A bank has several automated teller machines (ATMs), which are geographically distributed and connected via a wide area network to a central server. Each ATM machine has a card reader, a cash dispenser, a keyboard/display, and a receipt printer. By using the ATM machine, a customer can withdraw cash from either checking or savings account, query the balance of an account, or transfer funds from one account to another. A transaction is initiated when a customer inserts an ATM card into the card reader. Encoded on the magnetic strip on the back of the ATM card are the card number, the start date, and the expiration date. Assuming the card is recognized, the system validates the ATM card to determine that the expiration date has not passed, that the user-entered PIN (personal identification number) matches the PIN maintained by the system, and that the card is not lost or stolen. The customer is allowed three attempts to enter the correct PIN; the card is confiscated if the third attempt fails. Cards that have been reported lost or stolen are also confiscated.

4. Introduction
1.2 If the PIN is validated satisfactorily, the customer is prompted for a withdrawal, query, or transfer transaction. Before withdrawal transaction can be approved, the system determines that sufficient funds exist in the requested account, that the maximum daily limit will not be exceeded, and that there are sufficient funds available at the local cash dispenser. If the transaction is approved, the requested amount of cash is dispensed, a receipt is printed containing information about the transaction, and the card is ejected. Before a transfer transaction can be approved, the system determines that the customer has at least two accounts and that there are sufficient funds in the account to be debited. For approved query and transfer requests, a receipt is printed and card ejected. A customer may cancel a transaction at any time; the transaction is terminated and the card is ejected. Customer records, account records, and debit card records are all maintained at the server.

5. Introduction
1.3 An ATM operator may start up and close down the ATM to replenish the ATM cash dispenser and for routine maintenance. It is assumed that functionality to open and close accounts and to create, update, and delete customer and debit card records is provided by an existing system and is not part of this problem.

6. 2. Specific Requirements
2.1 The XYZ Bank Inc. can have many automated teller machines (ATMs), and the new software system shall provide functionality on all ATMs.
2.2 The system shall enable the customers of XYZ Bank Inc., who have valid ATM cards, to perform three types of transactions;
2.2.1 Withdrawal of funds,
2.2.2 Query of account balance, and
2.2.3 Transfer of funds from one bank account to another account in the same bank.

7. 2. Specific Requirements
2.3 An ATM card usage shall be considered valid if it meets the following conditions:
The card was issued by an authorized bank.
The card is used after the start date, i.e., the date when the card was issued.
The card is used before the expiration date, i.e., the date when the card expires.
The card has not been reported lost or stolen by the customer, who had been issued that card.
The customer provides correct personal identification number (PIN), which matches the PIN maintained by the system.

8. 2. Specific Requirements
2.4 The system shall confiscate the ATM card if it detects that a lost or stolen card has been inserted by a customer. (The system shall also display an apology to the customer).
2.5 The system shall allow the customer to enter the correct PIN in no more three attempts.
2.6 The failure to provide correct PIN in three attempts shall result in the confiscation of the ATM card.

9. 2. Specific Requirements
2.7 The system shall ask for the transaction type after satisfactory validation of the customer PIN.
2.8 The customer shall be given three options, as type of transaction: withdrawal transaction, or query transaction, or transfer transaction.
2.9 If a customer selects withdrawal transaction, the system shall prompt the customer to enter account number and amount to be dispensed.

10. 2. Specific Requirements
2.10 For a withdrawal transaction, the system shall determine:
a). that sufficient funds exist in the requested account,
b).that the maximum daily limit has not be exceeded, and
c). that there are sufficient funds available at the local cash dispenser.

11. 2. Specific Requirements
2.11 If a withdrawal transaction is approved, the requested amount of cash shall be dispensed.
A receipt shall be printed containing information about the transaction, and the card shall be ejected.
The information printed on the receipt includes:
a). transaction number,
b). transaction type,
c).amount withdrawn, and
d).account balance.

12. 2. Specific Requirements
2.12 If a customer selects query transaction, the system shall prompt the customer to enter account number.
2.13. If a query transaction is approved, the system shall print a receipt and eject the card.
4.13.1The information contained on the receipt includes:
a). Transaction number,
b). Transaction type, and
c). Account balance.

13. 2. Specific Requirements
2.14. If a customer selects transfer transaction, the system shall prompt the customer to enter “From Account” number, “To Account” number, and amount to be transferred.
2.15. The system shall check if there are enough funds available in the “From Account”, which are being requested for transfer to the “To Account”.

14. 2. Specific Requirements
2.16. If the transfer transaction is approved, a receipt shall be printed and card shall be ejected.
The information printed on the receipt includes:
a). Transaction number,
b). Transaction type,
c). Amount transferred, and
d). Account balance.
2.17. The system shall cancel any transaction:
if it has not been completed
if the customer presses the Cancel button

15. 2. Specific Requirements
2.18. The customer records, account records, and debit card records will all be maintained at the server and shall not be the responsibility of the system.
2.19. The system shall enable an ATM operator to shutdown or start up an ATM for routine maintenance.

16. 2. Specific Requirements
2.20. The system shall enable an ATM operator to add cash to the cash dispenser.
2.21.The system shall not be responsible for opening or closing of accounts, and to create, update, and delete customer and debit card records. These tasks are performed elsewhere by a bank.

17. 2. Specific Requirements
2.22. The system shall be linked with the bank server through communication systems, which are beyond the scope of the current system. It is assumed that this facility is always available.
2.23.The system shall not be responsible for the maintenance of the hardware devices of the ATM or network facilities.

18. Requirements Analysis
Analysis and
Negotiation
Requirements
Elicitation
Requirements
Specification
Requirements
Validation
User Needs,
Domain Information,
Existing System
Information, Regulations,
Standards, Etc.
Agreed
Requirements
Requirements
Document

19. Characteristics of Requirements IEEE 803
Eight Characteristics of Good User Requirements
Verifiable
Clear and concise
Complete
Consistent
Traceable
Viable
Necessary
Implementation free
Think of these characteristics as a series of filters.
A good requirement will pass through all eight filters.
Muhammad Ahmad Kahloon

20. Muhammad Ahmad Kahloon
Verifiable
A verifiable requirement is stated in such a way that it can be tested by: -
Inspection, Analysis, or Demonstration.
makes it possible to evaluate whether the system met the requirement, and
is verifiable by means that will not contaminate the product or compromise the data integrity.
A verifiable requirement is stated in such a way that it can be Bad example:
The system must be user friendly.
How should we measure user friendliness?
Good Example:
The user interface shall be menu driven. It shall provide dialog boxes, help screens, radio buttons and dropdown list boxes for user inputs.
Muhammad Ahmad Kahloon

21. Muhammad Ahmad Kahloon
Clear & Concise
A clear & concise requirement:
Must consist of a single requirement
Should be no more than words in length
Must be easily read and understood by non technical people,
Must be unambiguous and not susceptible to multiple interpretations,
Must not contain definitions, descriptions of its use, or reasons for its need, and
must avoid subjective or open-ended terms.
Good example:
When the user accesses any screen, it must appear on the monitor within 2 seconds.
Bad example:
All screens must appear on the monitor quickly.
How long is quickly?
Muhammad Ahmad Kahloon

22. Requirement imprecision
lack of exactness or accuracy.
Problems arise when requirements are not precisely stated
Ambiguous requirements may be interpreted in different ways by developers and users
Example:
The user shall be able to search either all of the initial set of databases or select a subset from it.
The system shall provide appropriate viewers for the user to read documents in the document store.
Consider the term ‘appropriate viewers’
User intention - special purpose viewer for each different document type
Developer interpretation - Provide a text viewer that shows the contents of the document
Muhammad Ahmad Kahloon

23. Muhammad Ahmad Kahloon
Completeness
A complete requirement:
Contains all the information that is needed to define the system function,
leaves no one guessing (For how long?, 50 % of what?), and
includes measurement units (inches or centimeters? ).
Bad example:
On loss of power, the battery backup must support normal operations.
For how long?
Good example:
On loss of power, the battery backup must support normal operations for 20 minutes.
Muhammad Ahmad Kahloon

24. Muhammad Ahmad Kahloon
Consistent
A consistent requirement:
Does not conflict with other requirements in the requirement specification,
Uses the same terminology throughout the requirement specification, and
Does not duplicate other Urs or create redundancy in any way.
Good example:
The pdf document will be opened on single click in desktop applications and double click on web applications..
Bad example:
The pdf document will be opened on single or doubble click.
Muhammad Ahmad Kahloon

25. Muhammad Ahmad Kahloon
Traceable
A traceable requirement:
Has a unique identity or number,
Cannot be separated or broken into smaller requirements,
Can easily be traced through to specification, design, and testing.
Good example:
The system must generate a batch end report when a batch is aborted.
The system must generate a discrepancy report when a batch is completed or aborted.
Bad example:
The system must generate a batch end report and a discrepancy report when a batch is aborted.
How is this uniquely identified?
If the requirement is changed later so that it does not require a discrepancy report, how will you trace it back so you can delete it?
Muhammad Ahmad Kahloon

26. Muhammad Ahmad Kahloon
Traceability
At a very minimum, a good traceability matrix will provide links, or cross references showing the associations between the following elements:
From the requirements to the stakeholders who first proposed these requirements, with the dates they were first proposed.
The associations between any dependent requirements listed.
From the requirements through to the system design, or functional specification document.
From the design to the relevant code segments. (oftentimes referencing the technical specification document).
From the requirements to the test plan document.
From the test plan to the relevant test cases.
Muhammad Ahmad Kahloon

28. Muhammad Ahmad Kahloon
Traceability
Backward traceability (i.e., to previous stages of development).
This depends upon each requirement explicitly referencing its source in earlier documents.
b) Forward traceability (i.e., to all documents spawned by the SRS).
This depends upon each requirement in the SRS having a unique name or reference number.
Muhammad Ahmad Kahloon

29. Muhammad Ahmad Kahloon
Ambiguity
Ambiguity occurs when a word or statement has multiple meanings or there is doubt about the meaning. These problems (and others) create ambiguity:
Vagueness
Subjectivity
Optionality
Under-specification
Under-reference
Ambiguity leads to differences in interpretation amongst various stakeholders for a requirement.
Muhammad Ahmad Kahloon

30. Ambiguous/imprecise requirement
The database shall only support the generation and control of configuration objects; that is, objects which are themselves groupings of other objects in the database. The configuration control facilities shall allow access to the objects in a version group by the use of an incomplete name.
What about non-configuration objects?
What about other database functionality?
What about level of service other than support?
Something else?
Muhammad Ahmad Kahloon

31. Muhammad Ahmad Kahloon
Weak Words in NL
Weak words are subjective or lack a common or precise definition. Examples include:
Quick, Quickly
Easy, Easily
Timely
Fast
Normal
Reliable
State-of-the-art
Effortless
Fast
Frequently
Intuitive
Feel, Feeling
Effortless
Friendly, User-friendly
Secure
Immediate
This is just a partial list. Don’t use weak words – define what you mean using precise, measurable terms
Muhammad Ahmad Kahloon

32. Muhammad Ahmad Kahloon
Un bounded List
An unbounded list is one that lacks a starting point, an end point, or both, Examples include:
At least
Including, but not limited to
Or later
Such as
Unbounded lists are impossible to design for or to test against
For example, how would you design and test a system that “must maintain a list of at least 250 users”?
Or, how would you test software that “must install on Windows Vista or later in under 5 seconds”?
Muhammad Ahmad Kahloon

33. Results – Real World Applications
Therac 25
Insulin Pump
Muhammad Ahmad Kahloon

34. Muhammad Ahmad Kahloon
Acknowledgment
• Chapter 6 Software Engineering by Ian Sommerville
• SWEBOK
IEEE
Michael Jackson’s book : Software Engineering & Specifications
Muhammad Ahmad Kahloon