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.
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
Lecture 8 & 9.pdf
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
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