Lecture 10.pdf

Lecture No 10
1
SOFTWARE REQUIREMENTS ENGINEERING

RE Process (Phase 1: Requirement Elicitation)
 Requirements Elicitation Techniques Continue…
3: Observations and Social Analysis
 People often find it hard to describe what they do because it is
so natural to them. Sometimes, the best way to understand it is
to observe them at work.
 Actual work processes often differ formal, prescribed
processes.
Use the Ethnography technique.
 Ethnography, Simply stated, is the study of people in their
own environment using methods such as participant
observation and face-to-face interviewing.
2

4: Requirement Reuse
 Reuse involves taking the requirements which have been
developed for one system and using them in a different system.
 Requirement reuse saves time and effort as reused requirements
have already been analyzed and validated in other systems.
 Requirement reuse is an informal process but more systematic
reuse could lead to larger cost savings.
3

Requirement Reuse possibilities
 When the applications or software systems fall in the same
category.
 When the requirement reflect the company policies.
 Reuse of requirements reflects the consistency of style across
the different application of the same domain.
4

RE Process (Phase 2: Requirement Analysis)
Requirement Analysis
 Analysts read the requirements, highlight problems, and
discuss them in requirements review meetings.
 It is not possible to make this activity a structured and
systematic process.
 It depends on the judgment and experience of process
participants.
 This is a time-consuming and expensive activity.
5

Stages of Requirement Analysis
1. Necessity checking
2. Consistency and Completeness Checking
3. Feasibility Checking
6

Stages of Requirement Analysis
1. 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.
7

2. Consistency and Completeness checking
 The requirements are cross-checked for consistency and
completeness.
 Consistency mean that no requirements should be
contradictory.
 Completeness means that no services or constraints which are
needed have been missed out.
8

3. 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.
Process of Requirement Analysis
9

Analysis Techniques:
Requirement Analysis is the 2nd phase in the RE process.
To perform this phase, we always need some techniques those
techniques are known as Analysis techniques.
Analysis techniques are actually based on a analysis check list.
10

Analysis Checklist:
 A checklist is a list of questions which analysts may use to
assess each requirement.
 Each requirement may be assessed against the checklist.
 When potential problems are discovered, these should be noted
carefully.
 We can make checklist using excel spread sheet.
11

Checklist Items:
 Premature Design
 Combined Requirements
 Unnecessary Requirements
 Use of non-standard hardware
 Conformance with business goals
 Requirement‟s ambiguity
 Requirement‟s testability
12

Requirement Interactions
 A very important objective of requirements analysis is to
discover the interactions between requirement 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 requirement which conflict, fill in a 1
For requirement which overlap, fill in a 1000
For requirements which are independent, fill in a 0
13

Example of Requirement Interaction Matrix
14

 If you can‟t decide whether requirements conflict, you should assume
that a conflict exists. If an error is made it usually fairly cheap to fix;
it can be much more expensive to resolve undetected conflicts.
 In the example we are considering, we can see that R1 overlaps with
R3 and conflicts with R5 and R6.
 R2 is an independent requirement.
 R3 overlaps with R1, R4 and R6
 Large number of conflicts or overlaps means that any changes to that
requirement will probably have a major impact of the rest of the
requirements.
 Interaction matrix work only when there is relatively small number
of requirements. 15

Requirement Negotiation
 Disagreement about requirements are inevitable when a system
has many stakeholders. Conflicts are not „Failures‟ but reflect
different stakeholders needs and priorities.
 Requirements negotiation is the process of discussing
requirements conflicts and reaching a compromise that all
stakeholders can agree too.
 In planning a requirements engineering process, it is important
to leave enough time for negotiation. Finding an acceptable
compromise can be time-consuming.
16

Requirement 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
Solution 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.
17

Comments on Requirement Negotiation
 A strong personality may force their priorities on their
stakeholders.
 End-users may be resist the change.
 Conflicts should not be viewed as “failures”, they are natural.
18

Requirements Validation
Requirements Validation Objectives
 Certifies that the requirements documents is an acceptable
description of the system to be implemented.
 Checks for a Requirements Document
 Completeness and consistency
 Conformance to Standers
 Requirements Conflicts
 Technical Errors
19

Requirements Analysis and Validation
 Analysis works with raw requirements as elicited from the
system stakeholders
 Have we got the right requirements is the key question to be
answered at this stage.
 Validation works with a final draft of the requirements
document i.e, with negotiated and agreed requirements.
 Have we got the requirements rights is the key questioned to be
answer at this stage.
20

Requirements Analysis and Validation
Inputs Outputs
Requirements Documents List of Problems
Organizational Knowledge
Requirement Validation
Organizational Standards Agreed Action
21

Requirements Reviews
A group of people read and analyze the requirements, look for
problems, meet and discuss the problems and agree on actions to
address these problems.
22

Requirements Reviews Process
23

Requirements Validation Through Prototyping
Prototyping
 Prototyping for requirements validation
 Demonstrate the requirements
 Help stakeholders discover problems
 Validation Prototypes
 Should be complete
 Reasonably efficient
 Robust
 It should be possible to use that prototype in same way as
required system 24

Requirements Validation Through Prototyping
Prototyping for Validation
25

Requirements Management
Requirement Management
 Requirement Management is the Process of Managing
Changes.
 In this topic of Requirement Management, we will talk about
the reason for changing in the requirements and how to manage
them.
26

Requirement Management and Traceability
 Requirements can‟t be managed effectively without
requirement traceability.
 A requirement is traceable if you can discover who suggested
the requirement.
 What requirements are related to it and how that requirement
relates to other information.
27

Changing Requirements
 All stakeholders want to change requirements, due to different
reasons.
 Studies have shown that very significant percentage of delivered
defects can be traced back to changing user requirements.
 A major issue in requirements engineering is the rate at which
requirements change once the requirement phase officially ended.
 This rate is average 3% per month in the subsequent design phase,
and should go down after that.
 This rate should come down to 1% per month during coding.
 Ideally, this should come down to no change in testing, however, this
is very rare. 28

Requirements Changing Factor
 Requirement conflicts
 When we detect some conflict in requirements these conflicts trigger the change.
 Evolving Customer/end-user Knowledge of the system
 As we start developing the system knowledge of the customer develop as well
about the system and the get clear and clear with time about what they want, and
this thing trigger the changes.
 Schedule or cost problems
 When some requirements are talking too long to implement, or they are too
expensive.
29

Requirements Changing Factor Continue…
 Changing Customer Priorities
 Customers priorities change during system development.
 Environment Changes
 The environment in which the system is to be installed may change so that the
system requirements have to change to maintain compatibility.
 Organizational Changes
 The organization which intend to use the system may change its structure and
processes resulting in new system requirements
30

Volatile Requirements
 All the requirements which changes during the system
development or even after the system development are known
as the volatile requirements.
Enduring Requirements
 These requirements are just opposite to the volatile
requirements and these requirements are actually the core
functionalities of the system. They never change. 31

Requirements Identification System
 It is very important for requirement management system that
every requirement should have a unique identification.
 We have a basic way in computer science to uniquely
identify things is providing a unique number to every thing.
We can implement that system to requirement identification
system as well.
32

Identification Techniques
Database Record Identification
 When ever the new requirement get identified it should be entered into
the database and new record identifier should be implemented to the
record.
Symbolic Identification
 We can make symbolic representation in the requirement management
system to uniquely identify the record.
 For Example: To represent all the Nonfunctional Requirements of
system efficiency we can make the symbol system like NF_E1, NF_E2
where NF means Non-Functional and E after underscore representing
the efficiency and further the number is uniquely identifying each NF
efficiency requirement. 33

Identification Techniques Continue…
Using Word Processor
 It is also a recommended way to use any word processor or spread
sheet.
Requirement Storing
 Requirements are the things which everyone will be accessing relevant
to the system. So, these requirements should be easy to access.
 As I said in last slide word processing technique is recommended
because every person have these tools in their computer system.
34

Lecture 10.pdf

More Related Content

Similar to Lecture 10.pdf

More from RaoShahid10

Recently uploaded

Lecture 10.pdf