1. socio-organizational issues and stakeholder requirements –Part 1
Lecture 18
socio-organizational issues and stakeholder requirements –Part 1

2. Today’s Topics Introduction to Social Aspects of system
What are Requirements?
Organizational Issues
Capturing Requirements
Socio Technical Model
Custom Method
Open System Task Analysis

3. 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.
Several issues can effect the acceptance of new technology.

4. 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.

5. 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.

6. 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].

7. Requirement Engineering

8. Functional Requirement
A functional requirement describes what a software system should do
For example, functional requirement would be that a system must send an whenever a certain condition is met (e.g. an order is placed, a customer signs up, etc).

9. Usability
Usability is the measure of a product's potential to accomplish the goals of the user.

10. 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.

11. Organization issues
There are several organizational issues that effect the acceptance and relevance of information and communication systems.

12. 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

13. 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.

14. 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?
rosy=blushing

15. 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.

16. 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.

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

18. 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!
messaging helps doing so!

19. 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.

20. 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.

21. 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
If the 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.

22. 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.

23. 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.”

24. 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.

25. 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.

26. Critical Mass
The beneficiaries of the technology increases its pervasiveness.
More people talk about technology, the more it will be common.

27. Critical mass strong benefit when lots of users
solution – increase
zero point benefit
.. but little benefit for early users

28. 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.

29. 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.

30. 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.

31. BPR It posses, Identify business processes
Review, update & analyze as-is business processes
Design to-be business processes
Test & implement to-be business processes

32. 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 facility.
Some other benefits are difficult to quantify.

33. 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

34. 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.

35. 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.

36. 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.

37. 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

38. 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

39. 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.

40. Socio-Technical Model
Socio-technical models for interactive systems are therefore concerned with
technical,
social,
organizational and
human aspects of design.

41. Socio Technical Model
Recognizes the fact that technology is not developed in isolation but as part of a wider organizational environment.
It is important to consider social and technical issues side by side so that human issues are not overruled by technical considerations.

42. 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.

43. 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

44. 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.

45. 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

46. 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.

47. CUSTOM Methodology
CUSTOM focuses on establishing stakeholder requirements:
all stakeholders are considered, not just the end-users.
Applied to initial stage of design.
Provides useful framework for considering stakeholder requirements.

48. Custom Methodology Six key stages to carry out.
Describe the organizational context, including its primary goals, physical characteristics, political and economic background.
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.

49. Custom Methodology 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.

50. CUSTOM Methodology 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.

51. CUSTOM Methodology 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.

52. CUSTOM Methodology Consolidate and check stakeholder requirements.
Here the stakeholder needs list is checked against the criteria determined at earlier stages.

53. 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.

54. 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.

55. OSTA Stages Eight main stages
The primary task which the technology must support is identified in terms of users’ goals.
Task inputs to the system are identified. These may have different sources and forms that may constrain the design.
The external environment into which the system will be introduced is described, including physical, economic and political aspects.

56. OSTA Stages
The transformation processes within the system are described in terms of actions performed on or with objects.
The social system is analyzed, considering existing work-groups and relationships within and external to the organization.
The technical system is described in terms of its configuration and integration with other systems.

57. 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.

58. 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.

59. 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.