socio-organizational issues and stakeholder requirements –Part 1 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 Socio Technical 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. Several issues 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? rosy=blushing

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

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 solution – increase zero point benefit .. but little benefit for early users

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, Identify business 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. It is 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

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: all stakeholders 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. 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.

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.

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.

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.

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

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

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.

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.