REQUIREMENTS ANALYSIS Week 6

& MODELLING
Instructor: Saima
REQUIREMENTS
ANALYSIS
REQUIREMENTS ANALYSIS
 Requirement Analysis - Understand the problem before you begin to
create requirements specification
 Don’t solve the wrong problem
 The process of reasoning about the requirements that have been
elicited
 Examining requirements for Conflicts, Inconsistencies, Omissions,
Ambiguity
REQUIREMENTS ANALYSIS
 Combining related requirements
 Categorizing requirements
 Organizing requirements into related subsets
 Analyzing requirement feasibility
 Exploring relationship between requirements
 Prioritizing requirements according to the needs of users
REQUIREMENTS ANALYSIS AND NEGOTIATION
Requ irements analysis

Necessity Consistency and Feasibility

checking completeness checking
checking

Conflicting and Infeasible

Unnecessary incomplete
requirements requirements
requirements

Requirements Requirements Requirements

discussion prioritisation agreement

Requ irements negotiation

CHARACTERISTICS OF GOOD
REQUIREMENTS
Complete
Correct
Feasible (realistic, possible)
Necessary
Prioritized
Unambiguous
Testable (verifiable)
 INCONSISTENT
REQUIREMENT
Some part of the requirement:
 contradicts with some other part.

Example:
One customer says Turn off heater and open water shower when
temperature > 100 C
Another customer says Turn off heater and turn ON cooler when
temperature > 100 C

7
EXAMPLE 2
 Different requirements must be consistent.

R1.2: The speed of the vehicle will never exceed 250 mph.

R5.4: When the vehicle is cruising at a speed greater than

300 mph, a special “watchdog” safety mechanism will
be automatically activated.
8
AMBIGUOUS REQUIREMENTS
Ambiguity is the property of being ambiguous, where a word, term,
notation, sign, symbol, phrase, sentence, or any other form used for
communication, is called ambiguous if it can be interpreted in more
than one way.
Not, "The system will allow the user to easily add a new order."
But "The system will allow the user to add a new order in five clicks or
less."
Not, "The report will be generated quickly."
But "The report will generate in less than 10 seconds."
 INCOMPLETE REQUIREMENT

Some requirements have been omitted:

due to oversight.

Example:
heater should be turned ON
water shower turned OFF.

The analyst has not recorded:

when temperature falls below 9 degree celcius
10
MISSING REQUIREMENTS –
DISCOVERY TECHNIQUES
 Expressing requirements in different formats
 Look at similar systems in use
 Scenarios
 Structured Walkthrough
 Search for omission indicators: e.g. tbd, etc, and so on, not limited to
and as a minimum
 Clarify your assumptions and risks.
 The CRUD Technique
CRUD TECHNIQUE
1. The sales manager (actor) reads a report on sales (entity) and creates
the customer account (entity)
2. The warehouse personnel (actor) review the orders (entity), assemble
the pens (entity) for shipment and update the inventory system (entity)
REQUIREMENTS
MODELING
REQUIREMENTS MODELING
 Diagrams communicate certain types of information more efficiently than text
can.
 Pictures help bridge language and vocabulary barriers among team members
 The BA initially might need to explain the purpose of the models and the
notations used to other stakeholders.
 BA might hope to find one technique that pulls everything together.
Unfortunately, there is no such all-encompassing diagram.
 Analysis models should augment—rather than replace—a requirements
specification written in natural language.
 Visual requirements models can help you identify missing, extraneous, and
inconsistent requirements
REQUIREMENTS MODELING
TECHNIQUES
 Business Process Modeling Notation
 Unified Modeling Language
 Flowchart Technique
 Data Flow Diagram
 Role Activity Diagram
BUSINESS PROCESS MODELING &
NOTATION (BPMN)
BPMN is a graphical representation of your business
process using simple objects, which helps the organization to
communicate in a standard manner.
Various objects used in BPMN includes
 Flow objects
 Connecting objects
 Swim lanes
 Artifacts
BPMN
A well designed BPMN model should be able to give the
detail about the activities carried out during the process
like,
 Who is performing these activities?
 What data elements are required for these activities?
The biggest benefit of using BPMN is that it is easier to
share and most modeling tools support BPMN.
BPMN EXAMPLE
UNIFIED MODELING
LANGUAGE
UML is a modelling standard primarily used for specification,
development, visualization and documentation of software system.
To capture important business process and artifacts UML provides
objects like
 State diagram
 Object diagram
 Activity diagram
 Class diagram
EXAMPLE
FLOW CHART TECHNIQUE
 A flowchart is a visual representation of the sequential flow and control
logic of a set of related activities or actions.
 There are different formats for flowcharts which include Linear, Top-
down and cross-functional (swim lanes).
 A flow chart can be used for different activities like representing data
flows, system interactions, etc.
 The advantage of using Flowchart is that it can be easy to read and
write even for non-technical team members.
EXAMPLE
DATA FLOW DIAGRAM
 DFDs show how data is processed by a system in terms of inputs and
outputs.
 Components of DFD includes
 Process
 Flow
 Store
 Terminator
 A DFD can be designed early in the requirement analysis phase to
define the project scope.
 For easy analyzing a DFD can be drilled down into its sub-processes
known as "levelled DFD".
SYMBOLS
EXAMPLE
ROLE ACTIVITY DIAGRAMS
Role activity diagram is similar to flowchart type notation.
In Role Activity Diagram, role instances are process participants,
which has start and end state.
RAD requires a deep knowledge of process or organization to identify
roles.
The components of RAD includes
 Activities
 Roles
 Decision points
 States
EXAMPLE
QUESTIONS ?