Requirement Engineering

Introduction and Process

Dr. Huma Hayat

Agenda
Understanding Requirements
Cont..
Requirement Engineering
Cont…
Requirement Engineering Tasks
Inception
Elicitation
Why Requirement Elicitation is
Difficult?
Cont…
Elaboration
Negotiation
Specification
Validation
Requirement Management
Types of Requirements
Functional Requirements
IEEE defines functional requirements as
• ‘a function that a system or component must be able to perform.’
• These requirements describe the interaction of software with its
environment and specify the inputs, outputs, external interfaces,
and the functions that should be included in the software.
• Also, the services provided by functional requirements specify the
procedure by which the software should react to particular inputs
or behave in particular situations.
Types of Requirements
Functional Requirements (EXAMPLE)-Online Banking
System
1.The user of the bank should be able to search the desired
services from the available ones.
2.There should be appropriate documents’ for users to read. This
implies that when a user wants to open an account in the bank, the
forms must be available so that the user can open an account.
3.After registration, the user should be provided with a unique
acknowledgement number so that he can later be given an
account number.
Types of Requirements
Non-Functional Requirements

• The non-functional requirements (also known as quality requirements) are

related to system attributes such as reliability and response time.

• Non-functional requirements arise due to user requirements, budget

constraints, organizational policies, and so on.

• These requirements are not related directly to any particular function

provided by the system.
Types of Non-Functional Requirements
The description of different types of non-functional requirements is listed below.
• Product requirements: These requirements specify how software product performs. Product requirements
comprise the following.
• Efficiency requirements: Describe the extent to which the software makes optimal use of resources, the
speed with which the system executes, and the memory it consumes for its operation. For example, the
system should be able to operate at least three times faster than the existing system.
• Reliability requirements: Describe the acceptable failure rate of the software. For example, the software
should be able to operate even if a hazard occurs.
• Portability requirements: Describe the ease with which the software can be transferred from one platform
to another. For example, it should be easy to port the software to a different operating system without the
need to redesign the entire software.
• Usability requirements: Describe the ease with which users are able to operate the software. For
example, the software should be able to provide access to functionality with fewer keystrokes and mouse
clicks.
 Requirement Elicitation/Gathering
Techniques
There are a number of requirements elicitation methods. Few of them are
listed below –
1.Interviews
2.Brainstorming Sessions
3.Facilitated Application Specification Technique (FAST)
4.Quality Function Deployment (QFD)
5.Use Case Approach

The success of an elicitation technique used depends on the maturity of the

analyst, developers, users, and the customer involved.
 Cont…
1. Interviews:
Objective of conducting an interview is to understand the customer’s expectations from the
software.

It is impossible to interview every stakeholder hence representatives from groups are

selected based on their expertise and credibility.

Interviews maybe be open-ended or structured.

• In open-ended interviews there is no pre-set agenda. Context free questions may be asked
to understand the problem.
• In structured interview, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.
Cont..
2. Brainstorming Sessions:
• It is a group technique
• It is intended to generate lots of new ideas hence providing a platform
to share views
• A highly trained facilitator is required to handle group bias and group
conflicts.
• Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists of the list of
requirements and their priority if possible.
Cont…
3. Facilitated Application Specification Technique (FAST):
It’s objective is to bridge the expectation gap – difference between what the developers think they are
supposed to build and what customers think they are going to get.

A team oriented approach is developed for requirements gathering.

Each attendee is asked to make a list of objects that are-

1.Part of the environment that surrounds the system

2.Produced by the system
3.Used by the system

Each participant prepares his/her list, different lists are then combined, redundant entries are eliminated,
team is divided into smaller sub-teams to develop mini-specifications and finally a draft of specifications is
written down using all the inputs from the meeting.
Cont…
4. Quality Function Deployment (QFD):
In this technique customer satisfaction is of prime concern, hence it emphasizes on the requirements which
are valuable to the customer.
3 types of requirements are identified –
• Normal requirements –
In this the objective and goals of the proposed software are discussed with the customer. Example –
normal requirements for a result management system may be entry of marks, calculation of results, etc
• Expected requirements –
These requirements are so obvious that the customer need not explicitly state them. Example – protection
from unauthorized access.
• Exciting requirements –
It includes features that are beyond customer’s expectations and prove to be very satisfying when present.
Example – when unauthorized access is detected, it should backup and shutdown all processes.
QFD - Cont…

The major steps involved in this procedure are –

1.Identify all the stakeholders, eg. Users, developers, customers etc
2.List out all requirements from customer.
3.A value indicating degree of importance is assigned to each
requirement.
4.In the end the final list of requirements is categorized as –
• It is possible to achieve
• It should be deferred and the reason for it
• It is impossible to achieve and should be dropped off
Use Case Approach

• This technique combines text and pictures to provide a better

understanding of the requirements.

• The use cases describe the ‘what’, of a system and not ‘how’.
Hence, they only give a functional view of the system.

• The components of the use case design includes three major

things – Actor, Use cases, use case diagram.
 Use Case Diagram Notations

Use Case
Cont.…
• Use Case
• A use case is the specification of a set of actions performed by a system, which
yields an observable result that is typically of value for one or more actors or other
stakeholders of the system.

• Association
• An Actor and use case can be associated to indicate that the actor participates in
that use case. Therefore, an association correspond to a sequence of actions
between the actor and use case in achieving the use case.

• Actor
• Actors are the entities that interact with a system. Although in most cases, actors
are used to represent the users of system, actors can actually be anything that
needs to exchange information with the system. So, an actor may be people,
computer hardware, other systems, etc.
Cont.…

• System
• The scope of a system can be represented by a system (shape), or sometimes
known as a system boundary. The use cases of the system are placed inside the
system shape, while the actor who interact with the system are put outside the
system. The use cases in the system make up the total requirements of the
system.

• Include
• An include relationship specifies how the behavior for the inclusion use case is
inserted into the behavior defined for the base use case.

• Extend
• An extend relationship specifies how the behavior of the extension use case can
be inserted into the behavior defined for the base use case.
Cont.…
• Generalization
• A generalization relationship is used to represent inheritance relationship
between model elements of same type. The more specific model element share
the same specification with the more general model element but carries more
details in extra.
Writing a Use Case
• Name – A clear verb/noun or actor/verb/noun descriptor that communicates the
scope of the use case.
• Brief Description – A brief paragraph of text describing the scope of the use case.
• Actors – A list of the types of users who can engage in the activities described in the
use case.
• Preconditions – Anything the solution can assume to be true when the use case
begins.
• Basic Flow – The set of steps the actors take to accomplish the goal of the use case. A
clear description of what the system does in response to each user action.
• Alternate Flows – Capture the less common user/system interactions, such as being
on a new computer and answering a security question.
• Post Conditions – Anything that must be true when the use case is complete.
 Use Case – ATM Example
• Actors:
• ATM Customer
• ATM Operator
• Use Cases:
• The customer can
• withdraw funds from a checking or savings account
• query the balance of the account
• transfer funds from one account to another
• The ATM operator can
• Shut down the ATM
• Replenish the ATM cash dispenser
• Start the ATM
Use Case – ATM Example
 Use Case – ATM Example

• Validate PIN is an Inclusion Use Case

• It cannot be executed on its own
• Must be executed as part of a Concrete Use Case

• On the other hand, a Concrete Use Case can be executed

Use Case – Validate PIN (1)
• Use case name: Validate PIN

• Brief Description/Summary: System validates customer PIN

• Actor: ATM Customer

• Precondition: ATM is idle, displaying a Welcome message.

Use Case – Validate PIN (2)
• Main sequence:
1. Customer inserts the ATM card into the card reader.
2. If system recognizes the card, it reads the card number.
3. System prompts customer for PIN.
4. Customer enters PIN.
5. System checks the card's expiration date and whether the
card has been reported as lost or stolen.
6. If card is valid, system then checks whether the user-entered
PIN matches the card PIN maintained by the system.
7. If PIN numbers match, system checks what accounts are
accessible with the ATM card.
8. System displays customer accounts and prompts customer
for transaction type: withdrawal, query, or transfer.
Use Case – Validate PIN (3)
• Alternative sequences:
• Step 2: If the system does not recognize the card, the system
ejects the card.
• Step 5: If the system determines that the card date has
expired, the system confiscates the card.
• Step 5: If the system determines that the card has been
reported lost or stolen, the system confiscates the card.
• Step 7: If the customer-entered PIN does not match the PIN
number for this card, the system re-prompts for the PIN.
• Step 7: If the customer enters the incorrect PIN three times,
the system confiscates the card.
• Steps 4-8: If the customer enters Cancel, the system cancels
the transaction and ejects the card.
• Postcondition: Customer PIN has been validated.
Use Case – Withdraw Funds
(1)
• Use case name: Withdraw Funds

• Summary: Customer withdraws a specific amount

of funds from a valid bank account.

• Actor: ATM Customer

• Dependency: Include Validate PIN use case.

• Precondition: ATM is idle, displaying a Welcome

message.
Use Case – Withdraw Funds
(2)
• Main sequence:
1. Include Validate PIN use case.
2. Customer selects Withdrawal, enters the amount,
and selects the account number.
3. System checks whether customer has enough funds
in the account and whether the daily limit will not be
exceeded.
4. If all checks are successful, system authorizes
dispensing of cash.
5. System dispenses the cash amount.
6. System prints a receipt showing transaction number,
transaction type, amount withdrawn, and account
balance.
7. System ejects card.
8. System displays Welcome message.
Use Case – Withdraw Funds
(3)
• Alternative sequences:
• Step 3: If the system determines that the account
number is invalid, then it displays an error message and
ejects the card.
• Step 3: If the system determines that there are
insufficient funds in the customer's account, then it
displays an apology and ejects the card.
• Step 3: If the system determines that the maximum
allowable daily withdrawal amount has been exceeded,
it displays an apology and ejects the card.
• Step 5: If the ATM is out of funds, the system displays an
apology, ejects the card, and shuts down the ATM.
• Post condition: Customer funds have been withdrawn.