Perspective-based reading (PBR) focuses on reviewing requirements documents from different stakeholder perspectives. PBR identifies key perspectives like tester, developer, and user. Reviewers follow procedures tailored to each perspective to systematically identify defects. PBR benefits include being systematic, focused, goal-oriented, and the procedures can be transferred through training. Requirements engineering involves social and cultural issues as it requires interaction between clients, engineers, and other stakeholders who may have different backgrounds. Key social issues include managing relationships and communication between different teams and organizations involved in requirements development.

1. Lecture No 8 & 9
1
SOFTWARE REQUIREMENTS ENGINEERING

2. Perspective-Based Reading (PBR)
 What is perspective Based Reading?
 Perspective-based reading (PBR) focuses on the point of view or
needs of the customers or consumers of a document. For example,
one reader may read from the point of view of the tester, another
from the point of view of the developer, and yet another from the
point of view of the user of the system.
 Different Perspective
 PBR operates under the premise that different information in the
requirements is more or less important for the different uses of the
document.
 Each user of the requirements document find different aspects of the
requirements important for accomplish a particular task. 2

3. Perspective-Based Reading (PBR)
 Different Perspective Continue…
 PBR provides a set of individuals reviews, each from a particular
requirements user’s point of view, that collectively cover the
documents relevant aspect, this process is similar to constructing
system use cases, which require identifying who will use the system
and in what way
3

4. Perspective-Based Reading (PBR)
 Steps in PBR
 Selecting a set of perspectives for reviewing the requirements
documents
 Creating a procedures for each perspective usable for building a
model of the relevant requirements information
 Enhance each procedure with questions for finding defects while
creating the model
 Applying procedure to review the documents
4

5. Perspective-Based Reading (PBR)
 Benefits of Different Perspectives
 Systematic
-Explicitly identifying the different uses for the requirements gives reviewers a
definite procedure for verifying whether those uses are achievable
 Focused
-PBR helps reviewers concentrate more effectives on certain types of defects,
rather then having to look for all types.
 Goal-Oriented and Customizable
-Reviewers can tailor perspectives based on the current goals of the
organization
 Transferable via Training
-PBR works follow a procedure, not the reviewer’s own experience with
recognizing defects. New reviewers can receive training in the procedure's
steps.
5

6. Social Issues in Requirement Engineering
 Requirements engineering is a social process, as it involves
interaction among clients, engineers and other systems.
 Requirements engineering is not an entirely formal process, because
it involves discovering client needs and reconciling them with
technical possibilities.
6

7. Social Issues in Requirement Engineering
Areas of Social Issues
1. Within the client organization
2. Within the requirement team
3. Between the client and the requirements team
4. Between the development and requirements teams
5. Within the development team
7

8. Social Issues in Requirement Engineering
1. Issues Within the client organization
 Users of the system may be different people from the ones who
interact with the requirement team.
 The requirement process reveals the problems within the client
organization, which must be addressed by facilitating communication
among different stakeholders
 The Problem within the client organization must not be buried, as
they effect the implementation of the project.
 Success of the project requires that every group within the
organization understand different aspects of the new system. 8

9. Social Issues in Requirement Engineering
2. Issues Within the requirement Team.
 How work is organized?
 What methods and notations are used?
 What team members think about organization and how jelled
requirement team is?
9

10. Social Issues in Requirement Engineering
3. Issues between the Client and Requirement Team.
 Financial arrangements
 Personal Relationship
 Ethical obligation
 Management of changes
10

11. Social Issues in Requirement Engineering
4. Issues between Development and Requirement Team.
 Development team needs to work very closely with the requirements
team to resolve inconsistencies and to get details.
 In some cases, requirements team may be disbanded or assigned
other tasks.
11

12. Social Issues in Requirement Engineering
5. Issues of Development Team.
 Team members may be demoralized
 The Deadline may slip
 Developers dislike documentation
 Development teams may have to communicate with clients directly,
to gain better understanding of the projects possibilities and
limitations, both for initial development and maintenance.
12

13. Cultural Issues in Requirement Engineering
 Advances in the internet and communication technologies has
enabled customers and developers to collaborate with each other in
geographically and temporally dispersed environments.
 There may be
 Time Zones Differences
 Language and Terminology differences
 Religious and racial differences
 Political differences
 Differences in business environment
13

14. Cultural Issues in Requirement Engineering
1. Time Zones Differences
 Working hours of clients and developers may differ by eight hours
or more
 Arranging phone calls and video conferences become a hassle as
one party has to come to office very early or stay very late.
14

15. Cultural Issues in Requirement Engineering
2. Language and Terminology differences
 Clients and developers may speak different languages.
 Requirements errors are introduced by not understanding other
partner’s language and terminology properly.
 Use of the word “hockey” in Pakistan and US means two different
sports: “field hockey” and “ice hockey” respectively.
15

16. Cultural Issues in Requirement Engineering
3. Religious and racial differences
 Insensitive comments on religious and racial backgrounds of
people involved in software engineering projects can become a
major hindrance in the successful execution of the requirements
engineering process.
4. Political differences
 Differences in political ideologies and personal convictions can
also lead to unprofessional environment in the execution of the
requirements engineering process.
16

17. Cultural Issues in Requirement Engineering
5. Differences in Business environment
 Every society has its own culture within the business community,
which must be understood for successful execution of the
requirement engineering process.
17

18. RE Process (Phase 1: Requirement Elicitation)
Requirement Elicitation
 Elicit means to gather, acquire, extract and obtain etc
 Requirements elicitation means gathering requirements or
discovering requirements
 Different activities are involved in discovering the requirements
for the system
18

19. RE Process (Phase 1: Requirement Elicitation)
Basics of Knowledge Acquisition
There are the source of knowledge acquisition
 Reading
 Asking
 Listening
 Observing
19

20. RE Process (Phase 1: Requirement Elicitation)
Requirements Elicitation Technique
 Individual
 Modeling
 Group
 Cognitive (Thinking, understanding through thought)
20

21. RE Process (Phase 1: Requirement Elicitation)
Problems in Requirements Elicitation
 Problems of scope
 The boundary of the system is ill-defined
 Unnecessary design information may be given
 Problems of understanding
 Users have incomplete understanding of their needs
 Conflicting views of different users
 Problems of volatility
 Requirements evolve over time and hence there are some
requirements which are bound to change during the system
development process due to one reason or the other. 21

22. RE Process (Phase 1: Requirement Elicitation)
Requirements Elicitation Stages
 Objective Setting
 Background Knowledge acquisition
 Knowledge organization
 Stakeholders requirements collection
22

23. RE Process (Phase 1: Requirement Elicitation)
1. Objective Setting
 Overall organizational objectives should be established at this
stage
 These include general goals of business, an outline description
of the problem to be solved and why the system may be
necessary, and constraints on the system such as budget and
schedule.
23

24. RE Process (Phase 1: Requirement Elicitation)
2. Background Knowledge
 Requirements engineers gather and understand background
information.
 This include information about the organization where the
system is to be installed, information about the application
domain of the system, and information about any existing
systems which are in use and which may be replaced.
24

25. RE Process (Phase 1: Requirement Elicitation)
3. Knowledge Organization
 The Large amount of knowledge which has been collected in
previous stage must be organized and collated.
 Identifying system stakeholders and their roles in the
organization, prioritizing the goals of the organization and
discording domain knowledge which does not contributing
directly to the system requirements.
25

26. RE Process (Phase 1: Requirement Elicitation)
4. Stakeholders Requirements Collection
 It involves consulting system stakeholders to discover their
requirements and deriving requirements which comes from the
application domain and the organization which is acquiring the
system.
26

27. RE Process (Phase 1: Requirement Elicitation)
A General Requirement Elicitation Process
27

28. RE Process (Phase 1: Requirement Elicitation)
Elicitation Techniques
• Interviews
• Scenarios
• Observations and social analysis
• Requirements Reuse
28

29. RE Process (Phase 1: Requirement Elicitation)
1. Interviews
• The requirements engineer or analyst discusses the system with
different stakeholders and builds up an understanding of their
requirements.
• Interviews are less effective for understanding the application
domain and the organizational issues due to terminology and
political factors.
29

30. RE Process (Phase 1: Requirement Elicitation)
Types of Interviews
1. Closed interviews
• The requirements engineer looks for answers to a pre-defined
set of questions
2. Open interviews
• There is no predefined agenda and the requirements engineer
discusses, in an open-ended way, what stakeholders want from
the system
30

31. RE Process (Phase 1: Requirement Elicitation)
Interviewing Essentials
• Interviewers must be open-minded and should not approach the
interview with preconceived notions about what is required.
• Stakeholders must be given a starting point for discussion.
This can be a question, a requirements proposal or an existing
system
31

32. RE Process (Phase 1: Requirement Elicitation)
Interview Steps
1. Prepare
2. Conduct
3. Follow through
32

33. RE Process (Phase 1: Requirement Elicitation)
Prepare for the Interview
• Define the purpose and objectives
• Determine whether the interview should be conducted by
one person or a team
• Obtain background information
33

34. RE Process (Phase 1: Requirement Elicitation)
Conduct the Interview
• Introduce yourself (and your team); provide information
about role(s) in the interview process.
• Clarify purpose, time frame, and key objectives
• Identify interviewee’s main concerns
• Ask for and obtain relevant documentation
• Summarize findings and link to purpose
34

35. RE Process (Phase 1: Requirement Elicitation)
Follow Through
•Immediately after the interview, fill in your notes; be sure to note
down impressions and important ideas.
• Review any documentation received from the interviewee
• Write an interview report, if necessary
35

36. RE Process (Phase 1: Requirement Elicitation)
Scenarios
• Scenarios are stories which explain how a system might be used.
• They should include:
• A description of the system state before entering the scenario
• The normal flow of events in the scenario
• Exceptions to the normal flow of events
• Information about concurrent activities
• A description of the system state at the end of the scenario 36

37. RE Process (Phase 1: Requirement Elicitation)
Scenarios Continue…
• Scenarios are examples of interaction sessions which
describe how a user
interacts with a system.
• Discovering scenarios exposes possible system interactions
and reveals system facilities which may be required.
• Important Point:
• We can represent a scenario using use case as well.
• Use case is used to represent the specific case of system
usage. 37

38. RE Process (Phase 1: Requirement Elicitation)
Scenarios Example
We are creating a Real Life
Scenario related to the ATM Machine.
38

39. RE Process (Phase 1: Requirement Elicitation)
Scenarios Writing customer perspective.
39
Actor: Customer
Precondition: The ATM machine is in idle state waiting for the
customer to insert Card
Scenario:
• Customer will insert the card to the ATM machine
• ATM machine read the Card and allow to insert PIN
• ATM machine read the PIN and allow for Transaction
• Customer will pick the payment from the payment tray.
Post Condition: The ATM machine is idle again and waiting for the
new customer or same customer to insert the card.

40. RE Process (Phase 1: Requirement Elicitation)
Scenarios with Use case.
Customer ATM Manager
40
Insert ATM Card
Transactions
Eject Card or
Report