Software Requirements Engineering

Requirements Analysis and Negotiation

 Requirements Analysis
• The aim of requirements analysis is to discover
problems with the system requirements,
especially incompleteness and inconsistencies
• Analysis is inter-leaved with requirements
elicitation as problems are sometimes obvious as
soon as a requirement is expressed
• Analysis is also linked with Software Architecture
• Detailed analysis usually takes place after the
initial draft of the requirements document is
specified i.e., SRS
• Analysis is also concerned with incomplete set of
requirements, which has not been discussed by
stakeholders
 Requirement Analysis
• Requirement Analysis bridges the gap b/w
Elicitation and requirement specification

Requirement Requirement Requirement

Elicitation Analysis Specification

Software Architecture
 Iterative Aspects of Elicitation,
Analysis, and Negotiation
Draft
Statement of
Requirements
Requirements
Elicitation

Requirements
Analysis

Requirements Requirements
Documents Problems

Requirements
Negotiation
Goal-oriented RE
 Problems of Requirement Analysis
• Stakeholders don’t know what they really
want.
• Stakeholders express requirements in their
own terms.
• Different stakeholders may have conflicting
requirements.
• Organisational and political factors may
influence the system requirements.
• The requirements change during the analysis
process. New stakeholders may emerge and
the business environment change
 Requirements Analysis Process

Consistency and Feasibility

Necessity
completeness checking
checking
checking

Conflicting and
Unnecessary incomplete Infeasible
requirements requirements requirements
 Necessity Checking
• The need for the requirement is analyzed. In
some cases, requirements may be proposed
which don’t contribute to the business goals of
the organization or stakeholder goals or to the
specific problem to be addressed by the system
 Consistency and Completeness
Checking
• The requirements are cross-checked for
consistency and completeness. Consistency
means that no requirements should be
contradictory; Completeness means that no
services or constraints which are needed have
been missed out
 Feasibility Checking
• The requirements are checked to ensure that
they are feasible in the context of the budget
and schedule available for the system
development
• Understanding the architecture of potential
software product plays a key role
Requirement Analysis Techniques
• Goal Oriented Analysis
– Business goals, Stakeholder goals
• Model requirements
– UML models, Formal models (e.g., Z-notations)
• Draw context diagram and detail diagrams
– E.g., DFDs, ERD
• Create prototypes
– Evolutionary, Throwaway, Simulations (Telecom solution), Experimentations (Machine learning and data
mining solutions)
• Analyze feasibility
– Cost, Time, Technologies
• Prioritize requirements
– AHP, hundred dollar
• Create data dictionary
– Glossaries, meta-data (input values, range of values, data format, output values)
• Decision Trees and Decision Tables
• Allocate requirements to subsystems
– Modularization
• Analysis checklists
– Based on experiences in previous projects (Covered in previous slides)
• Requirements Interactions
• Traceability metrics
 Model requirements
• Data model
– shows relationships among system objects
• DFDs, ERD
• Functional model
– description of the functions that enable the
transformations of system objects. E.g., state
diagram
• Behavioral model
– manner in which software responds to events
from the outside world
• Interaction diagrams
Model Requirements
 Modeling Methods
• Structured Analysis
– Abstraction and Modularity
• Object-Oriented Analysis
• Formal Methods
– Using predicate calculus (MCRL2) and set theory
(Z-notations)
– Visual depictions (Petri-nets)
Analyze Requirements
Context DFD
Data Flow Diagram
Entity Relationship Diagram
Dialog Map
UML
 Data Dictionary
• Data dictionary binds the various requirements
representations and integration problems are
reduced
• Data dictionary makes it easy to find the
information you need, and it avoids redundancy
and inconsistencies
• Example:
– Requested Chemical = Chemical ID
                                + Number of Containers
                                + Grade
                                + Amount
                                + Amount Units
                                + (Vendor)
Requirement Analysis Outsourcing

– www.outsource2india.com
– https://www.progress.com/
– https://www.getsmartcoders.com/
 Requirements Interactions
• An important objective of requirements analysis
is to discover the interactions between
requirements and to highlight requirements
conflicts and overlaps
• A requirements interaction matrix shows how
requirements interact with each other, which can
be constructed using a spreadsheet
• Each requirement is compared with other
requirements, and the matrix is filled as follows:
– For requirements which conflict, fill in a 1
– For requirements which overlap, fill in a 1000
– For requirements which are independent, fill in a 0
An Interaction Matrix
 Requirements Negotiations
• Disagreements about requirements are inevitable
when a system has many stakeholders. Conflicts
are not ‘failures’ but reflect different stakeholder
needs and priorities
• Requirements negotiation is the process of
discussing requirements conflicts and reaching a
compromise that all stakeholders can agree to
• In planning a requirements engineering process, it is
important to leave enough time for negotiation.
Finding an acceptable compromise can be time-
consuming
• The final requirements will always be a compromise
 Requirements Negotiation Stages
• Requirements discussion
– Requirements which have been highlighted as
problematic are discussed and the stakeholders
involved present their views about the
requirements
• Requirements prioritization
– Disputed requirements are prioritized to identify
critical requirements and to help the decision
making process
• Requirements agreement
– Solutions to the requirements problems are
identified and a compromised set of requirements
are reached. Generally, this will involve making
changes to some of the requirements
Requirements Negotiation Process
Conflicting and
Unnecessary Infeasible
incomplete
requirements requirements
requirements

Requirements Requirements Requirements

discussion prioritization agreement

Requirements Negotiation
Resolution of Requirements Conflicts
• Meetings are the most effective way to
negotiate requirements and resolve
requirements conflicts
• All requirements which are in conflict should
be discussed individually
 Requirement Errors
• Errors of omission
– Domain experts easily forget to convey domain
knowledge to requirements engineers, because
they consider that to be obvious and implicit
• Errors of clarity and ambiguity
– Primarily, because natural languages (like English)
are used to state requirements, while such
languages are themselves ambiguous
• Errors of speed and capacity
– These occur due to conflicting understanding or
competing needs of different stakeholders
 Addressing Requirements Errors
• Prevention
• Removal
• For requirements errors, prevention is usually
more effective than removal
• Requirements inspections and prototyping
play an important role in defect removal
 Use Cases
• Business Use case
• System use case

09/01/22 33
 Use Case – Ivar Jacobson, 1994
• Modeling technique used to describe what a new
system should do or what an existing system already
does.
• Captures a discussion process between the system
developer and the customer
• Comparatively easy to understand intuitively – even
without knowing the notation.
• Can be easily discussed with the customer who may not
be familiar with UML.
• Leads to a requirement specification on which all agree

09/01/22 34
 Use Case Model
• Use Case
– Boundaries of the system are defined by functionality that
is handled by the system.
– Each use case specifies a complete functionality (from its
initiation by an actor until it has performed the requested
functionality).
• Actor
– An entity that has an interest in interacting with the
system – a human or some other device or system.

09/01/22 35
 Use Case Principles
• Describes required functionality in terms of
the user – system
• Identifies external actors
• Identifies system boundary
• Describes scenarios of use
• Describes pre/post conditions
• Describes variants/exceptions

09/01/22 36
 Use Case Notation (Basic)

System
Boundary
(often
implied)
Use Case
Actor

“Participates-In”
Association

09/01/22 37
 Use Diagram for a Library System
Reserve
Book
Browse
Borrow
Book
Browser
Return
Book
Books
Borrower
Borrow
Extend Journal
loan

Return
Update
Journal
Catalog Journal
Borrower
Librarian
Library System
09/01/22 38
 Use Case Model
• Represents a use case view of the system – how the
system is going to be used
• System is treated as a black box
• Aid to the user
– decide and describe the functional requirements of the system
• Aid to the developer
– give a clear and consistent description of what the system should
do – model is used throughout the development process.
• Aid to the tester
– Provide a basis for performing system tests that verify the system
• Traceability
– Provide the ability to trace functional requirements into actual
classes and operations in the system

09/01/22 39
 Creating the Use Case Model

• In an iterative cycle
– Finding the actors
– Finding the use cases
– Defining the system
– Defining the relationship between use cases
• Validating the model

09/01/22 40
 Relationship in Use Cases
• Extends
• Uses

09/01/22 41
 Use Cases (Advanced)
Base Use Case

Actor <<extend>>

Extending Use
Case

Base Use Case

<<include>>
Special Special
Actor Actor Included Use
Case
09/01/22 42
 Credit Card Validation
System

Perform Card
Transaction

Customer Process Retail

Customer Bill Institution

Reconcile
Transactions

Individual Corporate
Customer Customer Manage
Customer Acct Sponsoring
Financial
Extended User Institution
09/01/22 43
 Use Case (Advanced) Example

Place
Order
Customer
<<include>>
<<extend>>

Validate
Handle User
Rush Order

Commercial Residential
Customer Customer
09/01/22 44
 Use Case Descriptions
• Pre and Post Conditions

Preconditions:
True

Postconditions:
If customer fails validation:
customer exits system
If customer passes validation:
customer order processed

09/01/22 45
 Use Case Descriptions
• Exceptions

1. User fails validation

2. User cancels order
3. User orders invalid item
4. User requests invalid quantity
5. User order exceeds available credit

09/01/22 46
 Use Case Hints
• Use language of user
• Avoid implementation
• Get good scenarios
• Names single, identifiable and reasonably
atomic behavior
• Describes flow of events clearly enough so
outsider can follow

09/01/22 47
 Use Case Hints
• Specify actor names by specific roles
• Use top level diagram to show context
• Decompose top-level use cases to show
requirements
• Group common use cases into
packages/modules

09/01/22 48
 Components Of An Elaborated Use
Case

• Priority
– E.g., using Likert scale very-low(1), low (2),
normal(3), high(4), very-high(5)
• Actor
• Summary
• Precondition
• Post-Condition

09/01/22 49
 Delete Information
• Priority: 3
• Actors: User
• Summary: Deleting information allows the user to
permanently remove information from the system.
Deleting information is only possible when the information
has not been used in the system.
• Preconditions: Information was previously saved to the
system and a user needs to permanently delete the
information.
• Post-Conditions: The information is no longer available
anywhere in the system.
• Includes: Cancel Action
• Extends: None
09/01/22 50
 Delete Information – Cont.
Normal Course of Events:
1. The use case starts when the user wants to get delete an entire
set of information such as a user, commission plan, or group.
2. The user selects the set of information that they would like to
delete and directs the system to delete the information.
3. Exception 1, 2
4. The system responds by asking the user to confirm deleting the
information.
5. The user confirms deletion.
6. Alternative Path: Cancel Action
7. A system responds by deleting the information and notifying the
user that the information was deleted from the system.
8. This use case ends.

09/01/22 51
 Delete Information – Cont.
• Alternative Path - The user does not confirm Deletion
1. If the user does not confirm deletion, the information does not
delete.
2. Include: Cancel Action

• Exceptions:
1. The system will not allow a user to delete information that is being
used in the system.
2. The system will not allow a user to delete another user If he/she
does not have privilege.
Assumptions:
1. Deleted information is not retained in the system.
2. Deleting information covers a permanent deletion of an entire set
of data such as a commission plan, user, group etc. Deleting a
portion of an entire set constitutes modifying the set of data.

09/01/22 52
 Elaborated Use Cases
• Different formats
• Two-column format
– user action
– software reaction

09/01/22 53
 Limitations of Use Cases
• Use cases alone are not sufficient.
• There are kinds of requirements (mostly non-functional) that need
to be understood.
• Domain (Business) Rules are not documented
• Legal Issues

09/01/22 54
 Limitations of Use Cases
• Non-Functional/Quality requirements can not be depicted with use cases
– Usability
• Color blind people should not have any difficulty in using the system – color coding
should take care of common forms of color blindness.
– Reliability
• The system needs to support 7 x 24 operation
– Performance
• Authorization should be completed within 1 minute 90% of the time.
• Average authorization confirmation time should not exceed 30 seconds.
– Portability
• The system should run on Windows 98 and above as well as Sun Solaris 7.0 and above.

09/01/22 55