What Is System Analysis systems analysis: The analysis of the role of a proposed system and the identification of a set of requirements that the system should meet, and thus the starting point for system design. The systems analysts are responsible for identifying a set of requirements (i.e. systems analysis) and producing a design. The design is then passed to the programmers, who are responsible for actual implementation of the system.

Structured Systems Analysis and Design Methodology (SSAD) structured systems analysis A specific technique for systems analysis that covers all activities from initial understanding of the problem through to specification and high-level design of the software system. is a methodology (Def. a system of ways of doing things especially regular and orderly procedures), used in the analysis and design stages of systems development.

Structured Systems Analysis and Design Methodology (SSAD) The success of SSADM may lie in the fact that it does not rely on a single technique. Each of the three system models provides a different viewpoint of the same system, each of which are required to form a complete model of the system. SSADM revolves around the use of three key techniques, namely –Logical Data Modeling, – Data Flow Modeling – Entity/Event Modeling.

Structured System Analysis Logical Data Modeling; This is the process of identifying, modeling and documenting the data requirements of a business information system. A Logical Data Model consists of a Logical Data Structure (LDS - The SSADM terminology for an Entity-Relationship Model) and the associated documentation. LDS s represent Entities (things about which a business needs to record information) and Relationships (necessary associations between entities).

Structured System Analysis Data Flow Modeling; This is the process of identifying, modeling and documenting how data flows around a business information system A Data Flow Model consists of a set of integrated Data Flow Diagrams supported by appropriate documentation. DFDs represent processes (activities which transform data from one form to another), data stores (holding areas for data), external entities (things which send data into a system or receive data from a system and finally data flows (routes by which data can flow)

Structured System Analysis Entity Event Modeling; This is the process of identifying, modeling and documenting the business events which affect each entity and the sequence in which these events occur. An Entity/Event Model consists of a set of Entity Life Histories (one for each entity) and appropriate supporting documentation.

Data Modeling Logical Versus Physical Database Modeling After all business requirements have been gathered for a proposed database, they must be modeled. Models are created to visually represent the proposed database so that business requirements can easily be associated with database objects to ensure that all requirements have been completely and accurately gathered. Different types of diagrams are typically produced to illustrate the business processes, rules, entities, and organizational units that have been identified. These diagrams often include entity relationship diagrams, process flow diagrams, and server model diagrams. Two types of data modeling are as follows: Logical modeling Physical modeling

Data Modeling Logical modeling deals with gathering business requirements and converting those requirements into a model. The logical model revolves around the needs of the business, not the database, although the needs of the business are used to establish the needs of the database. Logical modeling involves gathering information about business processes, business entities (categories of data), and organizational units. After this information is gathered, diagrams and reports are produced including entity relationship diagrams, business process diagrams, and eventually process flow diagrams.

Data Modeling Logical modeling(cont) The diagrams produced should show the processes and data that exists, as well as the relationships between business processes and data. Logical modeling should accurately render a visual representation of the activities and data relevant to a particular business. Typical deliverables of logical modeling include –Entity relationship diagrams –Business process diagrams (hierarchical view of processes) –User feedback documentation Note Logical modeling affects not only the direction of database design, but also indirectly affects the performance and administration of an implemented database. When time is invested performing logical modeling, more options become available for planning the design of the physical database.

Data Modeling Physical modeling involves the actual design of a database according to the requirements that were established during logical modeling Logical modeling mainly involves gathering the requirements of the business, with the latter part of logical modeling directed toward the goals and requirements of the database. Physical modeling deals with the conversion of the logical, or business model, into a relational database model. When physical modeling occurs, objects are being defined at the schema level. A schema is a group of related objects in a database. A database design effort is normally associated with one schema. During physical modeling, objects such as tables and columns are created based on entities and attributes that were defined during logical modeling. Constraints are also defined, including primary keys, foreign keys, other unique keys, and check constraints.

Data Modeling Physical modeling(cont) The implementation of the physical model is dependent on the hardware and software being used by the company. Some database software might only be available for Windows NT systems, whereas other software products such as Oracle are available on a wider range of operating system platforms, such as UNIX. Typical deliverables of physical modeling include the following: –Server model diagrams The server model diagram shows tables, columns, and relationships within a database. –User feedback documentation –Database design documentation

Hard vs Soft Systems Analysis Hard systems – Easy to define – concerned with how we deal with the problem(s) Soft system – Not well defined – Concerned with what shall we do – Organizations and businesses are typically soft systems

Hard Systems Analysis Hard systems (HS) involves simulations, often using computers and the techniques used in operations research. Hard systems look at the “How?” meaning, how to best achieve and test the selected option of development and analysis HS have an explicit objective governed by fixed rules such as those encountered in decision making. Operational Research is a hard, well defined system. Examples of areas that apply hard systems methodology are: Project Management Forecasting Simulation Mathematical Programming Decision Theory Another characteristic of hard systems that it is: Stochastic – Statistically based on probability. Deterministic – fixed inputs and known outputs

Soft System Analysis Soft systems methodologies (SSM) are used to tackle systems that cannot easily be quantified, especially those involving people interacting with each other or with "systems". Useful for understanding motivations, viewpoints, and interactions but, naturally, it doesn't give quantified answers. Soft systems looks at the “What?” of the system; What to do to achieve an improvement, Usually analysis before application or implementation SSM Considers the following: Systems that could be envisaged Human activity Clarification of the problem Improve the understanding Based on Ideas: Examine Learn about and Study Understand Select and Focus

Hard And Soft System Analysis In summary, hard systems analysis addresses those parts of enterprise that have a tangible form. These techniques address those problems: Identify cost/savings Improve methods Develop User Requirements whereas soft system analysis attempts to: Understanding complexity Promote learning Identifying weakness Understanding relationships

Soft Systems Methodology Soft Systems Methodology (SSM) was developed by Peter Checkland in the late 60 ’ s at the University of Lancaster in the UK. The real world is usually complex and messy. Many different factors may contribute to an issue, and there may be many different perspectives to consider while resolving it. This means that it's often difficult to understand the real problem or find the root cause. With so much confusion often surrounding problems, determining an appropriate solution can sometimes seem almost impossible. To deal with issues like these, you need a problem-solving approach that first lets you clearly see what's happening - and then helps you think about how the situation could be improved. Soft Systems Methodology (SSM) is just such an approach.

Soft Systems Methodology Although SSM develops models, the models are not supposed to represent the “ real world ”, but by using systems rules and principles allow you to structure your thinking about the real world. The models are neither descriptive or normative, though they may carry elements of both. One of the interesting things about SSM is that it constrains your thinking in order for you to expand your thinking.

Key Features of SSM The primary focus of SSM is on THE PEOPLE INVOLVED WITH THE PROBLEM and the secondary focus is on THE PROBLEM. It is a User-Centered Design Approach. SSM supports analysis of the problem from different perspectives. Technical problems are dynamic over time. The idea is to keep the project vague and wide ranging for as long as possible.

Seven Stages Of SSM 1. Examination of the problem situation the researcher is immersed in the problem situation 2. Problem situation expressed - Analysis of the ingredients (using a rich picture method) the problem systems and their immediate context are defined 3. Relevant systems and Root definitions are defined coming to a root definition of significant facets of the system of interest 4. Conceptualization and modeling the conceptual models of the systems, intended as improvements, are developed 5. Comparison of models the conceptual models of the system are compared to reality 6. Debate about change - definition and selection of options feasible and desirable changes are identified 7. Design of action program the actions required to improve the situation are outlined

SSM – overview (seven stage model) situation considered problematic problem situation expressed real world systems thinking about real world conceptual models of systems described in root definitions 4 comparison of models and real world 5 6 changes: systemically desirable, culturally feasible 7 action to improve the problem situation 3 root definition of relevant systems 2 1 source: Checkland: Systems Thinking, Systems Practice

Stage 1 of 7 Stage 1: The problem situation unstructured So first we decide what it is we are actually exploring. At this stage we don ’ t define the problem but assess the general area that interests us. Find about the problem situation, Who are the key players? What is their perception of the situation? What processes are going on and how? What the organizational structures are?

Stage 2 In Stage Two the issue is “ expressed ” in some way. Checkland calls this a rich picture for two reasons. Firstly the situation needs to be expressed in all its richness. Checkland provides some guidelines as to what should be included. These are Structures Processes Climate People Issues expressed by people Conflicts Secondly, Checkland suggests that the best way of doing this is in a picture form.

Stage 2 (cont.): Tools used to gather information about the problem situation Workplace Observations identify tasks performed produce logs “ day in the life of ” descriptions video recording Workshops and Discussions future workshops review workshops conflict resolution workshops mock ups and simulations Interviewing unstructured interviews, informal interviews semi-structured interviews, highly structured interviews audio recording, critical incidents

Stage 2 All the information collected in stage 1 and stage 2 is put in pictorial format called Rich Pictures. Rich pictures should show Power structure within the system Power hierarchy within the system Reporting system within the system Pattern of communication

Stage 2 Graphical representation of the organization or work area Self explanatory and easy to understand A subjective process: there is no “ correct ” picture “ Hard ” facts: e.g. activities, departmental boundaries, physical and geographical layout, product types, resources, “ Soft ” facts: e.g. concerns, conflicts, socio-organizational roles, political issues, relationships, employee needs, Rich pictures help: - to identify what is really important in the situation - people understand their role in the organization - to define aspects of the organization to be addressed by the information system

Stage 2

Rich Pictures – People involved – Problem areas – Controlling bodies – And sources of conflicts The rich pictures can also include detail about the system environment such as human activities, like processes, cross-organizational boundaries.

Stage 2 (cont.): Warnings: pitfalls to avoid during early stages of SSM Don't narrow the scope of investigation down too early Assemble richest picture without imposing a particular structure and solution on the problem situation People have difficulty to interpret the world in a loose way and often show the over-urgent desire for action Should realize that there will be many possible versions of the system

Stage 3 : Selection of Relevant Systems and Root Definitions “‘The root definition is a concise, tightly constructed description of a human activity system which states what the system is’ (Checkland 1981)” A relevant system is one which is thought to be helpful in learning about the situation - for any situation there may (will) be several possible relevant systems A Root Definition is the name of a relevant system. The core of a relevant system is the transformation it performs Input T Output

Stage3 Root definitions of the relevant systems are defined Who is doing what for whom? Whom are they answerable to? What assumptions are being made? What environment is it happening? One root definition might be ‘to provide a service which gives the highest possible safety standards whilst balancing the need for customer care with annual spending’

Stage3 Root definitions of the relevant systems are defined Transformation The input must be transformed by the process and the output must be a product of the transformation – e.g. for a public library unread books books read need for knowledge need met unspent budget spent budget but not repository of knowledge educated public

Stage3 Root definitions of the relevant systems are defined CATWOE (1) C Customer(s) beneficiary(s)/victim(s) of the system A Actor(s) those who do T T Transformation of input to output W Weltanschauung the specific “world view” that makes T meaningful (assumptions) O Owner(s) those who could stop (or change the nature of) T E Environment constraints on the system that are outside its scope How do you know if your Root Definition is “complete”? CATWOE is a useful mnemonic for structuring or manufacturing root definitions

Stage3 Root definitions of the relevant systems are defined Root Definitions Short textual statements which define the important elements of the relevant system being modeled - rather like mission statements a system to do X by (means of) Y in order to do Z what the system does - X how it does it - Y why it ’ s being done - Z

Stage3 Root definitions of the relevant systems are defined Root definition examples A university owned and operated system to award degrees and diplomas to suitably qualified candidates (X), by means of suitable assessment (Y), (in conformance with national standards), in order to demonstrate the capabilities of candidates to potential employers (Z). Express the RD as "a system to do X, by Y, in order to achieve Z" A university owned and operated system to implement a quality service (X), by devising and operating procedures to delight its customers and control its suppliers (Y), in order to improve its educational products (Z).

Stage3 Root definitions of the relevant systems are defined C candidate students A university staff T candidate students transformed into degree holders W the belief that awarding degrees and diplomas is a good way of demonstrating the qualities of candidates to potential employers O the University governing body E national educational

Stag4 Conceptualization and modeling Conceptual Model Is a human activity model which rigorously matches the root definition The activities can be derived from the verbs in the root definition The model shows the dependencies between these activities

activity models - symbols verb + noun phrase A B activity - ‘do something’ logical dependency arrow - activity A must come before B, or if activity A is done badly - so will B example use boundary

Stag4 Conceptualization and modeling Guidelines for building Conceptual Model Select activities from the root definition which would have to take place, in order for the described system to function properly Express each of these functions as a single phrase using a single verb Incorporate the activities into a conceptual model, showing where each activity is dependent on another Incorporate the three E ’ s (see later)

Stag4 Conceptualization and modeling E1 - efficacy (does the system work, is the transformation effected)? E2 - efficiency (the relationship between the output achieved and the resources consumed to achieve it) E3 - effectiveness (is the longer term goal (Z) achieved)

Stage 4 (cont.): Evaluation / monitoring: example (university) E1 (efficacy) - are degrees and diplomas awarded? E2 (efficiency) - how many degrees and diplomas, of what standard, are awarded for the resource consumed? E3 (effectiveness) - do employers find the degrees and diplomas a useful way of assessing the qualities of potential employees?

activity model - example A university owned and operated system to award degrees and diplomas to suitably qualified candidates (X), by means of suitable assessment (Y), (in conformance with national standards), in order to demonstrate the capabilities of candidates to potential employers (Z).

the complete conceptual model From Stag 1 to 4 root definition CATWOE activity model measures of performance

The complete conceptual model From Stag 1 to 4 example enroll students design education programmes appreciate national standards educate students allot resources design and carry out assessment award degrees + diplomas to students reaching acceptable levels monitor for E1, E2, E3 take control action E1 (efficacy) - are degrees and diplomas awarded? E2 (efficiency) - how many degrees and diplomas, of what standard, are awarded for the resource consumed? E3 (effectiveness) - do employers find the degrees and diplomas a useful way of assessing the qualities of potential employees?

Stage 5: Comparison with real world The activities in the conceptual model are now compared with what happens in the real world. For each activity, the following questions are asked: Is this activity carried out in the real world? How is it done? How is performance measured? Is the activity carried out effectively?

Stage 6 (cont.): Guidelines for identifying feasible and desirable changes Take the possibilities for changing the situation generated in stage 5 For each proposed change write down as clearly as possible The reason for change The nature of the change The means of bringing about the change Asses the political feasibility by considering From whose point of view the expected outcome will be positive The individuals likely to oppose the change and why they oppose it The relative power of the individuals or groups for and against the change Asses the feasibility of the proposed changes by examining Cost implications of implementation, relative to the other options Expected

Stage 7: Recommended Actions to Improve the Situation The purpose of this stage is to recommend changes and tactics for implementation of those changes Guidelines From the list of options from stage 6, select the one which is expected to have the greatest positive effect Be clear as to whose point of view the ‘ positive effect is from ’ Make notes about how likely the opposition to changes should be dealt with Present the findings to the client in the form of report

Rules for SSM Tactical Rules 1. Each stage, 2 - 6, has a defined output. – Stage 2 - Rich pictures, Relevant Systems – Stage 3 - Root Definitions (CATWOE) – Stage 4 - Conceptual Models built from Root Definitions – Stage 5 - Agenda for possible changes derived from comparisons – Stage 6 - Agreement on desirable and feasible change 2. Conceptual Models should be derived from Root Definitions and from nothing else 3. Conceptual Models should be checked against Root Definitions 4. Conceptual Models are not descriptions of systems to be engineered 5. Don't look for systems in the problem situation - the systems are created as (conceptual) tools for learning