Requirement Engieering & Analysis

1
Requirement Engineering

The broad spectrum of tasks and techniques

that leads to an understanding of requirements

is called requirement engineering.

 Requirements Engineering-I
 Inception—ask a set of questions that establish …

 basic understanding of the problem

 the people who want a solution

 the nature of the solution that is desired, and

 the effectiveness of preliminary communication and

collaboration between the customer and the
developer
 Elicitation—elicit requirements from all stakeholders

 Elaboration—create an analysis model that identifies

data, function and behavioral requirements
 Negotiation—agree on a deliverable system that is
realistic for developers and customers
2
 Requirements Engineering-II
 Specification—can be any one (or more) of the following:

 A written document

 A collection of user scenarios (use-cases)

 A prototype

 Validation—a review mechanism that looks for

 errors in content or interpretation

 areas where clarification may be required

 missing information

 inconsistencies (a major problem when large

products or systems are engineered)
 Requirements management
3
 Inception
 Identify stakeholders

 “who else do you think I should talk to?”

 Recognize multiple points of view

 Work toward collaboration

 The first questions

 Who is behind the request for this work?

 Who will use the solution?

 What will be the economic benefit of a successful solution

 Is there another source for the solution that you need?

4
 Eliciting Requirements
 meetings are conducted and attended by both software
engineers and customers
 rules for preparation and participation are established

 a "facilitator" (can be a customer, a developer, or an

outsider) controls the meeting
 a "definition mechanism" (can be work sheets, or wall
stickers or an electronic bulletin board, chat room or
virtual forum) is used
 the goal is
 to identify the problem

 propose elements of the solution

 negotiate different approaches, and

 specify a preliminary set of solution requirements

5
 Quality Function Deployment

Normal Requirements

Expected Requirements

Exciting Requirements

6
 Elicitation Work Products
 a statement of need and feasibility.

 a bounded statement of scope for the system or product.

 a list of customers, users, and other stakeholders who

participated in requirements elicitation
 a description of the system’s technical environment.

 a list of requirements (preferably organized by function

 a set of usage scenarios that provide insight into the use

of the system or product under different operating
conditions.
 any prototypes developed to better define requirements.

7
 Negotiating Requirements
Identify the key stakeholders
These are the people who will be involved in the
negotiation

Determine each of the stakeholders “win

conditions”
Win conditions are not always obvious

Negotiate
Work toward a set of requirements that lead to
“win-win”

8
 Validating Requirements-I
 Is each requirement consistent with the overall objective

for the system/product?

 Have all requirements been specified at the proper level

of abstraction? That is, do some requirements provide a

level of technical detail that is inappropriate at this
stage?
 Is the requirement really necessary or does it represent

an add-on feature that may not be essential to the

objective of the system?
 Is each requirement bounded and unambiguous?

9  Do any requirements conflict with other requirements?

 Validating Requirements-II
 Is each requirement achievable in the technical

environment that will house the system or product?

 Is each requirement testable, once implemented?

 Does the requirements model properly reflect the

information, function and behavior of the system to

be built.
 Has the requirements model been “partitioned” in a

way that exposes progressively more detailed

information about the system.
10
 Prioritizing requirements (Kano
model)
 Must-be: dissatisfied when -, at most neutral

 One-dimensional: satisfaction proportional to

number
 Attractive: more satisfied if +, not less satisfied

if –
 Indifferent: don’t care

 Reverse: opposite of what analyst thought

 Questionable: preferences not clear

11
 Kano Model
 Must be

 Performance

 Attractive

5
 Kano Model
satisfied

Performance
attractive

dysfunctional functional
must-be

6
 Kano Model
 Must be Requirement Prioritization

Register Must be
 Performance
Login Must be

 Attractive Book Ticket Must be

Seat Selection Performance

Make Payment Performance

Buy Attractive
Refreshment

7
 Kano Model

How to identify the category

Ask Customer

How would you feel if product has the feature?

How would you feel if product doesn’t has the feature?

8
 Kano Model

Customer Negative Questions / Dysfunctional

Requirements
Like Must be Neutral Live with Dislike

Positive Like Q A A A O
questions/
Must be R I I I M
Functional
Neutral R I I I M

Live R I I I M
with
Dislike R R R R Q

9
 Kano Model
 Must be

 One-Dimensional

 Attractive

 Indifferent

 Reverse

 Questionable

10
 Agile Requirements User-stories

User of customer need

Product description

Used for Planning

Conversation

20
 User Stories
Easy to Understand

Written by the Customer

Small and Estimable

Testable

Becomes more detailed over the time

21
 User story template

As a <type of user>,

I want <to perform some task>
so that I can <achieve some goal/
benefit/value>.

22
 User story example

User story title: Customer

withdraws cash.

As a customer,
I want to withdraw cash from an
ATM
So that I don't have to wait in line
at the bank.

23
 User story example

24
 User story example

25
 User Stories Acceptance Criterion

Acceptance Criterion 1:
Given that the account is creditworthy
And the card is valid
And the dispenser contains cash,
When the customer requests the cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned.

26
 User Stories Acceptance Criterion

Acceptance Criterion 2:

Given that the account is overdrawn

And the card is valid,
When the customer requests the cash
Then ensure the rejection message is displayed
And ensure cash is not dispensed.

27
 User Stories board

Source: https://age-of-product.com/wp-content/uploads/Agile-Transition-How-Create-Offline-Board-1024-1024x768-1.jpg
12
 User stories board (Software)

13 Source: https://www.atlassian.com/software/jira
 3 C’s of User-Stories

Card

Conversation

Confirmation

28
 Software Requirement Specification

14
15
 Requirement Analysis

16
Requirement Model

Source: Software Engineering A Practitioner’s Approach, Roger S. Pressman

Requirement Model- Analysis Rules of Thumb

 The model should focus on requirements that are visible within the problem

or business domain. The level of abstraction should be relatively high

 Each element of the requirements model should add to an overall

understanding of software requirements and provide insight into the
information domain, function, and behavior of the system

 Delay consideration of infrastructure and other nonfunctional models until

design

 Minimize coupling throughout the system

 Be certain that the requirements model provides value to all stakeholders

 Keep the model as simple as it can be. Don’t create additional diagrams

when they add no new information.

Requirement Model

Ref: Software Engineering A Practitioner’s Approach, Roger S. Pressman

Use-Cases
 A collection of user scenarios that describe the thread of usage of a
system

 Each scenario is described from the point-of-view of an “actor”—a

person or device that interacts with the software in some way

 Each scenario answers the following questions:

 Who is the primary actor, the secondary actor (s)?

 What are the actor’s goals?

 What preconditions should exist before the story begins?

 What main tasks or functions are performed by the actor?

 What information does the actor desire from the system?

 Does the actor wish to be informed about unexpected changes?

Use Case Diagram

 Creating Preliminary Use Case

 Refining Preliminary Use Case

 Writing Formal Use Case

Crating Preliminary Use Case

To begin developing a set of use cases, list the

functions or activities performed by a specific actor
 Log in

 Change Pin

 Withdraw Cash

 Fund Transfer

 Check Balance
Refining Preliminary Use Case
A description of alternative interactions is essential
for a complete understanding of the function that is
being described by a use case.

 Can the actor take some other action at this point?

 Is it possible that the actor will encounter some error condition at this point? If so,

what might it be?

 Is it possible that the actor will encounter some other behavior at this point
Writing Formal Use Case

 Use Case: ATM Operations

 Primary Actor: Customer

 Goal in Context:

 Preconditons:

 Scenarios:

 Exceptions:

 Secondary Actor:
Use Case- ATM
Use Case- ATM
Requirement Model
Scenario-based Elements
Objectives

 Activity Diagram

 Swimlane Diagram
Activity Diagram

 The UML activity diagram supplements the use case by providing a

graphical representation of the flow of interaction within a specific scenario

 Each A UML activity diagram represents the actions and decisions that

occur as some function is performed.

Activity Diagram- Notations/ Symbols
Activity Diagram-Overall ATM Operations

 Insert Card

 If card is valid then ask for the pin

 If pin is valid the ask to select the operation

 Once operation is selected, perform the selected operation

 If no more operations is to be performed take out the card and end the

process
Activity Diagram-
Overall ATM Operations

 Insert Card

 If card is valid then ask for the pin

 If pin is valid the ask to select the operation

 Once operation is selected, perform the selected

operation

 If no more operations is to be performed take out the

card and end the process

Activity
Diagram-
Withdrawal Operation
Swimlane
Diagram-
Withdrawal Operation
 Requirement Model
Behavioral & Class based Elements
Objectives

 State Diagram

 Class Diagram
State Diagram
 The UML state machine diagrams depict the various states that an object

may be in and the transitions between those states.

 Statechart diagram describes the flow of control from one state to another

state. States are defined as a condition in which an object exists and it

changes when some event is triggered.

 The most important purpose of Statechart diagram is to model lifetime of

an object from creation to termination.

State Diagram
 The UML state machine diagrams depict the various states that an object

may be in and the transitions between those states.

 Statechart diagram describes the flow of control from one state to another

state. States are defined as a condition in which an object exists and it

changes when some event is triggered.
State Diagram
 The UML state machine diagrams depict the various states that an object

may be in and the transitions between those states.

 Statechart diagram describes the flow of control from one state to another

state. States are defined as a condition in which an object exists and it

changes when some event is triggered.

 The most important purpose of Statechart diagram is to model lifetime of

an object from creation to termination.

State Diagram- Notations / Symbols
State Diagram- Photocopy Machine

Source: https://courses.cs.ut.ee/2010/sm/uploads/Main/Fall2009Exam.pdf
Class Diagram
 In software engineering, a class diagram in the Unified Modeling Language

(UML) is a type of static structure diagram that describes the structure of a

system by showing the system's classes, their attributes, operations (or
methods), and the relationships among objects.

 A UML class diagram is made up of:


A set of classes and


A set of relationships between classes
Class Diagram- Class Notations..

 Class Name

 Class Attributes

 Class Operations

 Visbility of Class Attributes


+ denotes public attributes or operations


- denotes private attributes or operations


# denotes protected attributes or operations


~ denotes package attributes or operations
Class Diagram- Class Relationships..

 Generalization


inheritance

 Simple Associtation


Associtation between two classes


Shown with simple line
Class Diagram- Class Relationships..

 Aggregation


Class 2 is part of class 1

 Dependency


Class 1 depends on class2


Any chagne to class 2 may initiate the
change to class 1
Class Diagram- Library System

Source: http://www.programsformca.com/2012/03/uml-diagrams-for-library-management.html
Thank You