Lecture_three_Requirements_analysis.pptx

Software Requirements analysis
and Negotiation
Course code: SWE 2102
MBARARA UNIVERSITY OF SCIENCE AND
TECHNOLOGY
Course Facilitators: Dr. Angella Musiimenta
(PhD) & Wilson Tumuhimbise (MSc)
1
7/22/2022 Requirements Analysis

Introduction
• After an initial set of requirements has been discovered, you
should analyze them for conflicts, overlaps, omissions and
inconsistencies.
• Analysis is the refinement of stakeholder needs into formal
product specifications.
• When information from this analysis is available, system
stakeholders then negotiate to agree on a set of system
requirements.
• Concerned with the high-level statement of requirements elicited
from stakeholders.
2

However
• Many projects fail:
– Because they start implementing the system
– Without determining whether they are building what the
customer really wants
3

The objective of requirements analysis
• To establish an agreed set of requirements which are
complete and consistent.
• Should be unambiguous so that they can be used as a
basis for further system development.
4

7/22/2022 Requirements Analysis 5
Requirements Analysis
 What is it?
 The process by which customer needs are understood and
documented.
 Expresses “what” is to be built
 Example 1:
 The system shall allow users to withdraw cash. [What?]

Requirements Analysis [2]
 C- and D-Requirements
 C-: Customer wants and needs; expressed in language
understood by the customer.
 D-: For the developers; may be more formal.

 Roadmap:
 Identify the customer.
 Interview customer representatives.
 Write C-requirements, review with customer, and update
when necessary.
 Write D-requirements; check to make sure that there is no
inconsistency between the C- and the D-requirements.

 C-requirements:
 Use cases expressed individually and with a use case diagram. A use case
specifies a collection of scenarios.
 Sample use case: Process sale.
 Data flow diagram:
 Explains the flow of data items across various functions. Useful for explaining
system functions. [Example on the next slide.]
 State transition diagram:
 Explains the change of system state in response to one or more operations.
[Example two slides later.]
 User interface: Generally not a part of requirements analysis though may be
included.

Data Flow Diagram
Pay rate
Overtime
rate
Total pay
Pay
Net pay
Get employee
file
Weekly
pay
Overtime
pay
Deduct
taxes
Issue
paycheck
Employee Record
Company records
Worker
ID
Regular
hours
Overtime
hours
Check
Tax rates
*
*
*

State Transition Diagram (STD)
EBOFF (e,f) EBON (e,f)
EBP(e,f)
EBP(e,f)
EBOFF (e,f): Elevator e button OFF at floor f.
EBON (e,f): Elevator e button ON at floor f.
EBP(e,f): Elevator e button f is pressed.
EAF(e,f): Elevator e arrives at floor f.
Elevator example (partial):

Use cases [1]
 Excellent technique for improving the understanding of requirements
 Narrative in nature
 Use cases are dependent on having some understanding of the
requirements (expressed in functional specifications document).

Use Cases [2]
 Use case - narration of the sequence of events of an
actor using a system
 UML icon for use case

Actors [1]
 Actor - an entity external to the
system that in some way participates
in the use case
 An actor typically stimulates the
system with input events or receives
outputs from the system or does
both.
 UML notation for actor:
Cust
om er

Actors [2]
 Primary Actor - an entity external to the system
that uses system services in a direct manner.
 Supporting Actor- an actor that provides services
to the system being built.
 Hardware, software applications, individual
processes, can all be actors.

Point of Sale Example- Actors
 Actors:
 Cashier
 Customer
 Supervisor
 Choosing actors:
 Identify system boundary
 Identify entities, human or otherwise, that will interact with the system, from
outside the boundary.
 Example: A temperature sensing device is an actor for a temperature monitoring
application.

Point of Sale - Use Cases
 Cashier
 Log In
 Cash out
 Customer
 Buy items
 Return items

Use Case Diagram - Example
Use Case Diagram: illustrates a set of use cases for a system.
Process sale
Payment
Authorization
service
Manage security
System administrator
Cashier Handle returns
Process rental <<actor>>
Tax calculator
Manage users
<<actor>>
Accounting
system

A sample Use Case
Use case: Buy Items
Actors: Customer, Cashier
Type: Primary, Essential
Description: A customer arrives at a checkout with
items to purchase. The cashier records
the purchase items and collects payment.

Guidelines for requirements analysis
• Define System Boundaries.
• Use Checklists for Requirements Analysis.
• Provide Software to Support Negotiations.
• Plan for Conflicts and Conflict Resolution.
• Prioritise Requirements.
• Classify Requirements Using a Multi-dimensional Approach.
• Use Interaction Matrices to Find Conflicts and Overlaps.
• Assess Requirements Risks.
19

1. Define System Boundaries.
• Assess the initial set of requirements to define the boundaries of the
system to be developed.
• Determine:
– System requirements
– Requirements for the operational processes
– Requirements should be outside the scope of the system
Benefit: Eliminates outside of scope requirements
Implementation: Examine each requirement and classify it as either a
system requirement, a process requirement or a requirement which
should be rejected.
20

2. Use Checklists for Requirements Analysis.
• A checklist is a list of questions which the analyst uses to
assess each requirement.
• Develop checklists of requirements problems based on your
experience and use them to analyze requirements
systematically.
• Each requirement should be analyzed against this checklist.
• Reuses knowledge of the requirements analysis across
projects.
Benefit: Reduces the probability of errors and accidental
omission of some requirements.
21

Implementation
• Analysts should check items on this list as they read
through the requirements document.
• When potential problems are discovered, these should be
noted either in the margins of the document
22

Sample checklist questions
Checklist Item Description
Premature design Does the requirement include premature design or implementation
information?
Combined requirements Does the description of a requirement describe a single requirement or
could it be broken down into several different requirements?
Unnecessary
requirements
Is the requirement 'gold plating'? That is, is the requirement a cosmetic
addition to the system which is not really necessary.
Use of non-standard
hardware
Does the requirement mean that non-standard hardware or software must
be used?
Conformance with
business goals
Is the requirement consistent with the business goals defined in the
introduction to the requirements document?
Requirements ambiguity Is the requirement ambiguous i.e. could it be read in different ways by
different people? What are the possible interpretations of the
requirement?
Requirements realism Is the requirement realistic given the technology which will be used to
implement the system?
Requirements testability Is the requirement testable, that is, is it stated in such a way that test 23

3. Provide Software to Support Negotiations.
• Use electronic systems such as emails, telephone calls,
to exchange information about requirements and to
support the negotiation of agreed requirements.
• Encouraging electronic discussion of the requirements
breaks down barriers between stakeholders and makes it
easier and faster to arrive at agreements about
requirements.
24

4. Plan for conflict and conflict resolution
• Conflicts, overlaps and omissions may come up in any set of
requirements.
• Need to anticipate these conflicts and plan requirements
negotiation meetings to discuss the requirements and resolve
the problems discovered during the analysis.
• Benefits:
– Reduces the time required to arrive at an agreed set of
requirements.
– Reduces the probability of omitting critical requirements from
important stakeholders.
– Convinces stakeholders that their views have been considered.
25

5. Prioritize requirements
• Priorities should be assigned to individual requirements
which reflect their importance to stakeholders and to the
overall success of the system.
Benefit:
– Helps stakeholders to decide on the core requirements for the
system.
– Helps designers to decide on the system architecture Helps to
resolve design conflicts which may arise
26

6. Classify Requirements using a multi
dimensional approach
• Classify your requirements so that you can identify related
requirements.
• Classifying requirements is a basis for discovering
commonalities and unexpected relationships between them.
• Classifying requirements improves the traceability of the
requirements document.
• Classification can help find the missing requirements.
• If you find that there are no requirements in some class which
is part of your normal classification scheme, this may mean
that important requirements have been left out.
27

Possible keywords used to classify requirements
• System. This should be applied to requirements which
affect the entire system such as performance or reliability
requirements
• User interface. This should be applied to requirements
which are concerned with user interaction.
• Database. This should be applied to requirements which
are concerned with the data managed by the system.
28

Key words..
• Communications. This should be requirements which
are concerned with the external communication facilities
in the system.
• Security. This should be applied to requirements which
are likely to have security implications.
After deciding on an initial set of classification terms, you
should then go through the requirements, associating one
or more of these keywords with each of them.
29

Key words..
• Therefore, a requirement which states that 'A graphical
user interface to the account data should be provided'
would be classified as 'User interface', 'Database' and
'Security'.
30

7. Use Interaction Matrices to Find Conflicts and
Overlaps.
• An interaction matrix is a matrix where the rows and
columns are labelled with requirements identifiers.
• This is a systematic approach to checking requirements
which ensures that the interactions between all
requirements in the system or in an identified class of
requirements are considered.
31

• Use a spreadsheet program and label the rows and the
columns with the requirement identifiers
• Each requirement is then considered and compared with
other requirements. You can then fill in values in the
spreadsheet cells 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.
32

8. Assess the requirements risk
• Carry out a risk analysis for each requirement in which
you suggest possible problems which may arise in the
implementation of that requirement.
• Explicit risk assessment helps identify requirements which
are likely to cause particular difficulties to the system
developers. If these can be identified at this stage, it may
be possible to modify the requirement to reduce the risks
to the development process.
33

Types of risks to be considered
• Performance risks. Implementing the requirement may
adversely affect the overall performance of the system.
• Safety and security risks. Implementing the requirement
may cause problems in meeting overall system requirements
for safety and security.
• Process risks. Implementing a requirement may require
changes to the normal development process, such as the
introduction of mathematical specifications and proof (for a
safety requirement) or the use of unfamiliar prototyping
systems (for a user interface requirement).
34

Risks..
• Implementation technology risks. Implementing a
requirement may require the use of unfamiliar implementation
technology, such as AI techniques, the use of N-version
programming for fault tolerance, etc.
• Database risks. Implementing a requirement may involve
non-standard data which is not available in an existing system
database.
• Schedule risks. Implementing a requirement may be
technically difficult and may threaten the planned
development schedule for the system.
35

Risks..
• External risks. Implementing a requirement involves
external contractors.
• Stability risks. The requirement may be volatile and
subject to evolution during the development process.
Need to decide on the appropriate risks for each system
being specified and assess each requirement against these
risks.
36

Software Requirements analysis tool
QVScribe software tool
Writing requirements using natural language processing
https://qracorp.com/qvscribe/

Guiding Questions
1a). Define Requirements analysis
b). Why is requirements analysis phase important during the
requirements engineering life cycle?
c). Explain at least eight guidelines for requirements analysis
d). Explicit risk assessment helps identify requirements which
are likely to cause particular difficulties to the system
developers. As a requirements engineer, please elucidate any
eight types of risks that should be considered during
requirements analysis.

Questions
39

Lecture_three_Requirements_analysis.pptx

Recommended

Recommended

More Related Content

Similar to Lecture_three_Requirements_analysis.pptx

Similar to Lecture_three_Requirements_analysis.pptx (20)

Recently uploaded

Recently uploaded (20)

Lecture_three_Requirements_analysis.pptx