IMS1805 Systems Analysis

1. IMS1805Systems Analysis Topic 3 (revisited and continued): Doing analysis – a ‘soft’ systems perspective

2. Agenda; relationship to previous weeks • Aim: To introduce the key concepts to the use of ‘soft’ systems analysis in IS • We have looked at process and data-oriented approaches to analysis and their implementation through FDDs, DFDs and ERDs • We have focussed on logical models which focus purely on data/information elements and exclude physical details of who does things, how they do them, etc • Now we reverse this emphasis!

3. 1. Background and rationale to soft systems thinking • Information systems are designed and built to process (transform) data and information for people • Information systems are designed and built to process (transform) data and information for people • Information systems are designed and built to process (transform) data and information for people

4. Need for soft systems thinking • Under what circumstances do the nature and characteristics of the people involved in an IS need to be explicitly considered and analysed? • Soft systems approaches try to formalise methods/techniques for: • identifying who has an interest in a system; and • describing what that interest is

5. Historical digression • In the beginning: IT/IS involved: • simple technology; which performed • limited tasks; for a • narrow range of system functions; affecting • a small number of people • (eg consider a calculator) • Therefore, potentially limited range of stakeholders and limited need for soft systems thinking • Now: IT/IS involves • complex technology; which performs • a wide range of tasks; for • a wide range of systems functions; affecting • a large number of people • (eg consider the web) • Therefore, potentially a very wide range of stakeholders and increased need for soft systems thinking

6. 2. Stakeholders – the core of soft systems thinking • Stakeholder: "a group or individual who is affected by or is in some way accountable for the outcome of an undertaking.“ http://www.sei.cmu.edu/cmmi/faq/term-faq.html • “The stakeholder requirements identify the parties involved with the system throughout its life cycle and express their needs, wants, desires and expectations, together with the constraints they and the operational environment impose.” Taken from ISO15288; see http://www.15288.com/

7. Identifying stakeholders • “Identify the individual stakeholders or stakeholder classes who have a legitimate interest in the system throughout its life cycle. This includes, but is not limited to, users, supporters, developers, producers, trainers, maintainers, disposers, acquirer and supplier organizations, regulatory bodies and members of society. Where direct communication is not practicable, e.g., consumer products and services, representatives or designated proxy stakeholders are selected, e.g. marketing Taken from ISO15288; see http://www.15288.com

8. Types of stakeholders (1) • People who supply data to a system • May raise issues of convenience, confidentiality, privacy, etc • Balancing the rights of external data providers with the needs of systems • Possible consequences of not taking adequate account?

9. Types of stakeholders (2) • People who perform processing tasks within a system • May raise issues of division of labour, organisational power/authority/responsibility, job satisfaction, etc • Balancing the rights of workers with the needs of the system • Possible consequences of not taking adequate account?

10. Types of stakeholders (3) • People who need information from a system • May raise issues of security, reliability, accessibility, timeliness, etc • Balancing the rights of information recipients with the constraints of the system • Possible consequences of not taking adequate account?

11. Types of stakeholders (4) • People who don’t do any of 1-3 on previous slides, but who are otherwise affected by the operation of the system • Examples: • People who operate the basic infrastructure on which the system operates • People who will be responsible for future possible maintenance/modification • People with an over-riding interest in general matters which affect systems of this sort (eg standards, data integrity, privacy, etc)

12. Relevant stakeholders • A subset of the overall group of system stakeholders • “Since ‘stakeholder’ may describe a very large number of people, a lot of time and effort would be consumed by attempting to deal with all of them. For this reason, ‘relevant stakeholder’ is used in most practice statements to describe the people identified to contribute to a specific task.” http://www.sei.cmu.edu/cmmi/faq/term-faq.html

13. Representative stakeholders • Stakeholders usually comprise groups or classes of people, rather than specific individuals • If a stakeholder group/class is too large to consult all its members, how do we choose a sub-set to be representative of that group/class’s views? • How do we test to ensure that this selected sub-set is truly representative?

14. Drawing the boundary around stakeholders, relevant stakeholders, representative stakeholders • Many people may be physically involved in a system or potentially affected by its operations • Where do we draw the line on which groups need to be explicitly considered? • This is a problem which rests on your judgement as an analyst! • Subjective elements • Situational elements • Need to examine it in the context of the objectives and priorities of the system

15. 3. Soft systems thinking – how do we use it/do it? • Identifying stakeholders • Deciding whether (and which) stakeholders matter • Identifying relevant stakeholders in regard to: • Processes • Data • Each other • ?? • Identifying specific features of each stakeholder’s connection to the system • Developing diagrammatic representations of findings

16. Methods/techniques for soft systems analysis • Hard to find anything as clearly-defined and specified as DFD/ERD/FDD, etc • Some ideas for formal techniques have been proposed: • rich pictures • CATWOE diagrams • Etc • Inherently more conceptual in nature than other methods (feelings/attitudes/motivations/ expectations vs data/processes/data flows) and therefore difficult to draw • Inherently more variable in application (every person/system is different)

17. Your knowledge of methods/techniques for soft systems analysis • Not concerned about teaching any specific techniques for soft systems analysis in this unit; leave it up to you to think about the issue and the need for soft systems approaches • Will expect an ability to identify the relevant aspect of a problem and sketch some form of representation of it • Example in next lecture

18. Summary • Soft systems approaches are driven by the need to deal with people issues in the design and construction of an IS • Based around identification of system stakeholders and their interests in the system • Techniques are poorly-defined, but this reflects the variability of the problems, not its relative importance