Lecture 18

socio-organizational
issues and stakeholder
requirements –Part 1
Today’s Topics
 Introduction to Social Aspects of system
 What are Requirements?
 Organizational Issues
 Capturing Requirements
 SocioTechnical Model
 Custom Method
 Open System Task Analysis
Introduction
 The different people affected by the
introduction of a system are known as
stakeholders and their needs can be both
complex and conflicting.
 Introduction of a new system effect the
organizational and work practices in any
organization.
 Severalissues can effect the acceptance of
new technology.
Introduction
 Requirement engineering mostly focus on
functional requirements.
 what the system must be able to do

 Mostly less emphasis is given on non-

functional human issues such as usability
and acceptability.
Requirements?
 Requirements are statements of
 what the system must do,
 how it must behave,
 the properties it must exhibit,
 the qualities it must possess, and
 the constraints that the system and its
development must satisfy.
Requirement Engineering
 Requirements engineering emphasizes
the use of systematic and repeatable
techniques that ensure the completeness,
consistency, and relevance of the system
requirements [Sommerville 1997a].
Requirement Engineering
Functional Requirement
 A functional requirement describes what a
software system should do
 For example, functional requirement would be
that a system must send an email whenever a
certain condition is met (e.g. an order is
placed, a customer signs up, etc).
Usability
 Usability is the measure of a product's
potential to accomplish the goals of the
user.
Acceptance
 Typical scenarios under which user will
use the accepted system.
 Real world testing of user acceptance or beta
testing corresponds to the acceptance of
software system.
Organization issues
 There are several organizational issues
that effect the acceptance and relevance
of information and communication
systems.
Organizational Issues
 These mainly includes
 Cooperation or conflict?
 Changing Power Structures
 The Invisible Worker
 The beneficiaries
 Free Rider Problem
 Critical Mass
 Automating Process Workflow and (BPR) Business
Process Reengineering
 Benefits Evaluation
Cooperation or Conflict?
 The term ‘computer-supported cooperative
work’ (CSCW) seems to assume that
groups will be acting in a cooperative
manner.
 People in organizations and groups have
conflicting goals, and systems that ignore
this are likely to fail spectacularly.
An Example
Imagine that an organization is already highly
computerized, the different departments all have their
own systems and the board decides that an integrated
information system is needed. The production manager
can now look directly at stocks when planning the
week’s work, and the marketing department can
consult the sales department’s contact list to send out
marketing questionnaires. All is rosy and the company
will clearly run more efficiently – or will it?
Conflicting Requirements
 If the user requirements are not fully
understood,
 The system will gradually lose respect as the
data it holds is incorrect,
 Confidence in the organization suffers and
productivity drops.
Changing power structures
 The identification of stakeholders will uncover
information transfer and power relationships
that cut across the organizational structure.
 However, the official lines of authority and
information tend to flow up and down through line
management.
 New communications media may challenge
and disrupt these formal
managerial structures.
Changing Power Structures
 The physical layout of an organization
often reflects the formal hierarchy:
 Each department is on a different floor, with
sections working in the same area of an
office.
 If someone from sales wants to talk to
someone from marketing then one of them
must walk to the other’s office.
Changing Power Structures
 The ‘levelling’ effect even makes it
possible for subordinates to direct
messages ‘diagonally’ across the
hierarchy, to their manager’s peers, or,
even worse, to their manager’s manager!
 Email messaging helps doing so!
Changing Power Structures
 Technology can be an important vector of
social change, but if violent reaction is
to be avoided, the impact of the
technology must be assessed before it is
introduced.
 In the short term, solutions must be carefully
matched to the existing social and
organizational structures.
The invisible worker
 The ability to work and collaborate at a
distance can allow functional groups
to be distributed over different sites.
 For example, cross-functional neighborhood
centers, where workers from different
departments do their jobs in electronic contact
with their functional colleagues.
The Invisible Workers -- Problems
 Management by Presence
 If the approach in an organization is ‘management by
presence’, that is someone is working because they
are in the office, then there is no way a remote worker
is going to be trusted.
 Management by Objectives
 Ifthe style is ‘management by objectives’, that is the
subordinates are working because they are doing
their jobs and producing results. Then there will be no
problem.
The Beneficiaries
 Main problem is people who get benefited from
the system are different from people who work in
the system.
 For example, a shared calendar system, Manager is a
beneficiary of meeting schedules but personal
secretary works to enter schedules.
 Chaos is resulted when a meeting is
automatically arranged and the subordinates may
have to rearrange commitments that have not been
recorded on the system.
Symmetry in IS
 Information systems should aim for some
level of symmetry.
 “If
you have to do work for the system, you
should obtain some benefit from it.”
Free Rider Problem
 This occurs when people can enjoy a good
service without paying anything (or making a
small contribution less than their benefit.
 This issue is termed as free rider problem.
 A few free riders in a system are often not a
problem, as the danger is more likely from
too much activity.
 This problem can be managed by increasing
the visibility of participants.
Critical Mass
 It is a very important or crucial stage in a
company's development, where the business
activity acquires self-sustaining capability.
 When a company reaches critical mass, it is
thought that they can remain viable without
having to add any more investment.
 Free rider problem solutions need to develop
critical mass for a technology.
Critical Mass
 The beneficiaries of the technology
increases its pervasiveness.
 More people talk about technology, the more
it will be common.
Critical mass
strong benefit when
lots of users

.. but little benefit

for early users

solution – increase
zero point benefit
Automating processes Workflow
and BPR
 A major problem in many organizations is
“paper work”.
 Workflow systems aim to automate such
work.
 Workflow systems aim to automate much
of the process using electronic forms,
which are forwarded to the relevant person
based on pre-coded rules.
Business Process Reengineering
 Business Process Reengineering (BPR) is
defined as the fundamental rethinking and
radical redesign of business processes to
achieve dramatic improvements in critical
contemporary measures of performance
such as cost, quality and speed.
Business Process Reengineering
 BPR aims to make the structure of an
organization serve the flow of
products/services and result in the
production of leaner and fitter
organizations.
BPR
 It posses,
 Identifybusiness processes
 Review, update & analyze as-is business processes
 Design to-be business processes
 Test & implement to-be business processes
Evaluating the benefits
 After successful installation of system,
benefits in term of cost should be
calculated.
 Some benefits may be in terms of job
satisfaction.
 For example email facility.
 Some other benefits are difficult to
quantify.
Capturing Requirements
 Problems can arise when a system is
introduced without a full understanding of all
the people who will be affected by it.

 In order to better understand and support

complex organizational structures,
workgroups and potentially conflicting
stakeholder needs, we capture and analyze
information
Capturing Requirements
 There are several approaches:
 Socio-technical modeling,
 Soft systems methodology,
 Participatory design,
 Ethnographic methods and
 Contextual inquiry.
 All are aimed at understanding the reality of
work contexts and the perspectives of
different stakeholders.
Stakeholders?
 Anyone who is affected by the success or
failure of the system is a stakeholder.
 Understanding stakeholders is key to
many of the approaches to requirements
capture.
Stakeholders
 Types
a)Primary stakeholders -people who actually use the system –
the end-users.
b) Secondary stakeholders - people who do not directly use the
system, but receive output from it or provide input to it.
c) Tertiary stakeholders - people who do not fall into either of
the first two categories but who are directly affected by the
success or failure of the system
d) Facilitating stakeholders - people who are involved with the
design, development and maintenance of the system.
Who are the stakeholders?
Example: Classifying stakeholders – an airline booking
system
An international airline is considering introducing a new
booking system for use by associated travel agents to sell flights
directly to the public.
Primary stakeholders: travel agency staff, airline booking staff
Secondary stakeholders: customers, airline management
Tertiary stakeholders: competitors, civil aviation authorities,
customers’ travelling companions, airline shareholders
Facilitating stakeholders: design team, IT department staff
Who are the stakeholders?
 Designers need to meet as many
stakeholder needs as possible
 usually in conflict so have to prioritise
 often priority decreases as move down
categories e.g. primary most important
 not always e.g. life support machine
Socio Technical Model
 Early in the twentieth century, studies of work
focused on how humans needed
to adapt to technical innovations.
 The socio-technical stress that work systems were
composed of both human and machine elements and
that it was the interrelationship between these that
should be central.
Socio-Technical Model
 Socio-technical models for interactive
systems are therefore concerned with
 technical,
 social,
 organizational
and
 human aspects of design.
Socio Technical Model
 Recognizes the fact that technology is not
developed in isolation but as part of a
wider organizational environment.
 Itis important to consider social and technical
issues side by side so that human issues are
not overruled by technical considerations.
Socio-Technical Models
 The key focus of the socio-technical
approach is to describe and document the
impact of the introduction of a specific
technology into an organization.

 Information gathered using interviews,

document analysis etc.
Socio-Technical Models
 Identify and describe:
 organizational context
 primary goals, historical background
 stakeholders
 motivation, job satisfaction, knowledge, skills, power,
tasks, needs for training
 workgroups
 role, characteristics, relationships within/without the
organization

43
Socio-Technical Models
 Try to capture:
 The problem being addressed
 There is a need to understand why the technology
is being proposed and what problem it is intended
to solve.
 The stakeholders affected
 Including primary, secondary, tertiary and
facilitating, together with their objectives, goals and
tasks.
Socio-Technical Model
 Socio Technical model captures
 Workgroups
 The workgroups within the organization, both
formal and informal.
 Change
 The changes or transformations that will be
supported.
 Proposed technology and how it’ll work
 External constraints
Custom Methodology
 CUSTOM is a socio-technical
methodology designed to be practical to
use in small organizations.

 It is based on the User Skills and Task

Match (USTM) approach, developed to
allow design teams to understand and fully
document user requirements.
CUSTOM Methodology
 CUSTOM focuses on establishing
stakeholder requirements:
 allstakeholders are considered, not just the
end-users.
 Applied to initial stage of design.
 Provides useful framework for considering
stakeholder requirements.
Custom Methodology
 Six key stages to carry out.
1. Describe the organizational context, including its
primary goals, physical characteristics, political and
economic background.
2. Identify and describe stakeholders.
 All stakeholders are named, categorized (as
primary, secondary, tertiary or facilitating) and described
with regard to personal
issues, their role in the organization and their job.
Custom Methodology
3. Identify and describe work-groups.
 A work-group is any group of people who
work together on a task, whether formally
constituted or not.
 Work-groups are described in terms of their
role within the organization and their
characteristics.
CUSTOM Methodology
4. Identify and describe task–object pairs.
 These are the tasks that must be performed,
coupled with the objects that are used to
perform them or to which they are applied.
CUSTOM Methodology
5. Identify stakeholder needs.
 Stages 2–4 are described in terms of both the
current system and the proposed system.
 Stakeholder needs are identified by
considering the differences between the two.
 For example, if a stakeholder is identified as
currently lacking a particular skill that is required in
the proposed system then a need for training
identified.
CUSTOM Methodology
6. Consolidate and check stakeholder
requirements.
 Here the stakeholder needs list is checked
against the criteria determined at earlier
stages.
CUSTOM Stakeholder Analysis
 CUSTOM questions investigate a range of
stakeholder characteristics, such as the following,
 What does the stakeholder have to achieve? How is
success measured?
 What knowledge and skills does the stakeholder have?
 What attitude towards computer technology does the
stakeholder have?
 Does the stakeholder have to consider issues of
responsibility, security, or privacy?
 etc.

53
Open System Task Analysis (OSTA)
 An alternative socio-technical approach.
 attempts to describe what happens when a technical
system is introduced into an organizational work
environment.
 Like CUSTOM, OSTA specifies both social and
technical aspects of the system.
 However, whereas in CUSTOM these aspects are
framed in terms of stakeholder perspectives, in OSTA
they are captured through a focus on tasks.
OSTA Stages
 Eight main stages
1. The primary task which the technology must
support is identified in terms of users’ goals.
2. Task inputs to the system are identified. These
may have different sources and forms that may
constrain the design.
3. The external environment into which the
system will be introduced is described,
including physical, economic and political
aspects.
OSTA Stages
4. The transformation processes within the
system are described in terms of actions
performed on or with objects.
5. The social system is analyzed, considering
existing work-groups and relationships
within and external to the organization.
6. The technical system is described in terms
of its configuration and integration
with other systems.
OSTA Stages
 Performance satisfaction criteria are
established, indicating the social and
technical requirements of the system.
 The new technical system is specified.

 OSTA uses notations familiar to designers,

such as data flow diagrams and textual
descriptions.
Summary of Today’s Topics
 There are several organizational issues
that affect the acceptance of technology
by users and that must therefore be
considered in system design: systems
may not take into account conflict and
power relationships.
 Those who benefit may not do the work
 Not everyone may use systems.
Summary
 In addition to generic issues, designers
must identify specific stakeholder
requirements within their organizational
context.
 Socio-technical models capture both
human and technical requirements.