Socio technical system

Software Engineering
SWETA KUMARI BARNWAL 1
SOFTWARE ENGINEERING
UNIT: 2
SOCIO-TECHNICAL SYSTEM
SYSTEM:
• A system is a purposeful collection of inter-related components working together to
achieve some common objective.
• A system may include software, mechanical, electrical and electronic hardware and be
operated by people.
• System components are dependent on other system components
• The properties and behavior of system components are inextricably (can’t escape)
intermingle
System Classifications:
• Technical computer-based systems
– Systems that include hardware and software but where the operators and operational
processes are not normally considered to be part of the system. The system is not self-aware.
E.g.: TV, Mobile phone
• Socio-technical systems
– Systems that include technical systems but also operational processes and people who use
and interact with the technical system. Socio-technical systems are governed by
organisational policies and rules. E.g.: Book publication
Socio-Technical System:
Software and hardware are interdependent. Without the hardware, a software is an
abstraction. When you put hardware and software togather, you create a system. This system
will be able to carry out multiple complex computations and return the result to its
environment.
This illustrates one of the fundamental characteristics of the system. Socio-technical system
is basically a study of how any technology is used and produced. This help us to identify the
ethical errors in technical and social aspects of the systems. Socio-technical system is a
mixture of people and technology. It consists of many items. These items are difficult to
distinguish from each other because they all have close inter-relationships. Some of the items
are shown in figure:

Socio-technical systems include:
• People: People can be individuals or in groups. We also need to consider their roles
and agencies. An organization employs the people, who build and make use of
hardware and software, operate within law and regulations, and share and maintain
the data.
• Hardware: The classical meaning if the technology is hardware. It involves
mainframe, workstations, peripheral, connecting devices. There is no way for a socio-
technical system to be without any kind of hardware component.
• Softwares: Software is nothing but an executable code. Softwares include operating
system, utilities, application programs. Software is an integral part of the socio-
technical system. Software often incorporates social rules and procedures as a part of
the design, i.e. optimize these parameters, store the data in these format, ask for these
data, etc.
• Law and regulations: There might be laws about the protection of privacy, or
regulations of chips testing in military use, etc. Laws and regulations set by
organization and government need to be followed. They carry special societal
sanctions if the violators are caught.
• Data: The design of the socio-technical systems design involve what data are
collected, to whom the data should be available and in which formats the data should
be stored.
These Systems have properties that are perceptible when all the components are integrated
and operate together.
Example: Let’s say, Software engineers in Silicon Valley may build software with all sorts of
bells and whistles expecting everyone to be tech savy and without even considering the basic
configuration of system requirement. If a large scale of people are in fact elderly and
unaccustomed to the interface and have traditional systems operating on old technology then
again the whole system will significantly reduce.

That’s the reason we are interested not only in technical dimension but also domain of Socio-
technical systems. The system include non-technical elements such as people, processes,
regulations, goals, culture, etc., as well as technical components such as computers, software,
infrastructure, etc.
To understand socio-technical systems as a whole, you have to know the various layers, as
shown in figure.
These systems can be impossible to understand. So, we refer to these 7 layers. These layers
make up the Socio-technical systems stack.
1. The equipment layer:
It contains set of hardware devices some of which may be computer, laptops, phones,
etc. Most of the devices include embedded system of some kind.
2. The operating system layer:
This layer provides a set of common facilities for higher software layers in the system.
This layer acts as an bridge to the hardware as it allows interaction between software
and hardware.
3. The communications and data management layer:
This layer extends the operating system facilities and provides an interface that allows
interaction with more extensive functionality, such as access to remote systems, access
to a system database, etc. This is sometimes called middleware, as it is in between the
application and the operating system.
4. The application layer:
This layer provides more specific functionality to meet some organization requirements.
There may be many different application programs in this layer.
5. The business process layer:
This layer consists a set of processes involving people and computer systems that
support the activities of the business. The use of software system, are defined and
enacted.
6. The organizational layer:
At this level, the business rules, regulations, policies along with high-level strategic
processes are defined and are to be followed when using the system.

7. The social layer:
Laws, regulations and culture that govern the operation of te system are defined.
Socio-technical system characteristics
• Emergent properties: Properties of the system of a whole that depend on the
system components and their relationships.
• Non-deterministic: They do not always produce the same output when
presented with the same input because the system’s behaviour is partially
dependent on human operators.
• Complex relationships with organisational objectives: The extent to which the
system supports organisational objectives does not just depend on the system
itself.
Emergent Property
• Properties of the system as a whole rather than properties that can be derived from the
properties of components of a system
• Emergent properties are a consequence of the relationships between system
components
• They can therefore only be assessed and measured once the components have been
integrated into a system
Property Description
Volume The volume of a system (the total space occupied) varies depending on how the
component assemblies are arranged and connected.
Reliability System reliability depends on component reliability but unexpected interactions
can cause new types of failure and therefore affect the reliability of the system.
Security
The security of the system (its ability to resist attack) is a complex property that cannot be
easily measured. Attacks may be devised that were not anticipated by
the system designers and so may defeat built-in safeguards.
Repairability This property reflects how easy it is to fix a problem with the system once it has
been discovered. It depends on being able to diagnose the problem, access the components
that are faulty and modify or replace these components.
Usability This property reflects how easy it is to use the system. It depends on the technical
system components, its operators and its operating environment.
Types of Emergent Property:

• Functional emergent properties: These appear when all the parts of a system work
together to achieve some objective. For example, a bicycle has the functional property of
being a transportation device once it has been assembled from its components.
• Non-functional emergent properties: These relate to the behavior of the system in its
operational environment. Examples are reliability, performance, safety, and security. They
are often critical for computer-based systems as failure to achieve some minimal defined
level in these properties may make the system unusable.
Systems Engineering
• It is a activity of specifying, designing, implementing, validating, deploying and
maintaining socio-technical systems.
• Concerned with the services provided by the system, constraints on its construction
and operation and the ways in which it is used.
System objective
• Should also define overall organizational objectives for the system.
• Should define why a system is being procured for a particular
environment.
• Functional objectives: To provide a fire and intruder alarm system for the building
which will provide internal and external warning of fire or unauthorized intrusion.
• Organisational objectives: To ensure that the normal functioning of work carried out
in the building is not seriously disrupted by events such as fire and unauthorized intrusion.
Critical Systems
If the system failure results in significant economic losses, physical damages or threats to
human life than the system is called critical systems.
(Objectives)
• To explain what is meant by a critical system where system failure can have severe
human or economic consequence.
• To explain four dimensions of dependability - availability, reliability, safety and
security.
• To explain that, to achieve dependability, you need to avoid mistakes, detect and
remove errors and limit damage caused by failure.
There are 3 types of CS:
• Safety-critical systems
– Failure results in loss of life, injury or damage to the environment;

– Chemical plant protection system;
• Mission-critical systems
– Failure results in failure of some goal-directed activity;
– Spacecraft navigation system;
• Business-critical systems
– Failure results in high economic losses;
– Customer accounting system in a bank;
System of Dependability in CS
• The most important emergent property of a critical system is its dependability. It
covers the related system attributes of availability, reliability, safety & security.
• Importance of dependability
– Systems that are unreliable, unsafe or insecure are often rejected by their
users(refuse to the product from the same company).
– System failure costs may be very high.(reactor / aircraft navigation)
– Untrustworthy systems may cause information loss with a high
consequent recovery cost.
Development methods for CS
• Trusted methods and technique must be used.
• These methods are not cost-effective for other types of system.
• The older methods strengths & weaknesses are understood
• Formal methods reduce the amount of testing required. Example :
– Formal mathematical method
Socio-technical critical systems Failures
• Hardware failure
– Hardware fails because of design and manufacturing errors or because components
have reached the end of their natural life.
• Software failure
– Software fails due to errors in its specification, design or implementation.
• Human Operator failure

– Fail to operate correctly.
– Now perhaps the largest single cause of system failures.
A Simple safety Critical System
• Example of software-controlled insulin pump.
• Used by diabetics to simulate the function of insulin, an essential hormone that
metabolises blood glucose.
• Measures blood glucose (sugar) using a micro- sensor and computes the insulin dose
required to metabolise the glucose.
Availability & Reliability
• Availability: The probability that a system, at a point in time, will be operational and
able to deliver the requested services
• Reliability: The probability of failure-free system operation over a specified time in a
given environment for a specific purpose
#Note: Both of these attributes can be expressed quantitatively
• It is sometimes possible to include system availability under system reliability
– Obviously if a system is unavailable it is not delivering the specified system services
• However, it is possible to have systems with low reliability that must be available. So
long as system failures can be repaired quickly and do not damage data, low reliability may
not be a problem
• Availability takes repair time into account
Reliability Terminology

Term Description
System failure
An event that occurs at some point in time when the system does not deliver
a service as expected by its users
System error
An erroneous system state that can lead to system behavior that is
unexpected by system users.
System fault
A characteristic of a software system that can lead to a system error. For
example, failure to initialize a variable could lead to that variable having
the wrong value when it is used.
Human error or
mistake
Human behavior that results in the introduction of faults into a system.
Safety in CS
• Safety is a property of a system that reflects the system should never damage people
or the system’s environment
• For example control & monitoring systems in aircraft
• It is increasingly important to consider software safety as more and more devices
incorporate software-based control systems
• Safety requirements are exclusive requirements i.e. they exclude undesirable
situations rather than specify required system services
Safety critical software are 2 types
• Primary safety-critical systems: Embedded software systems whose failure can cause
hardware malfunction which results inhuman injury or environmental damage.
• Secondary safety-critical systems: Systems whose failure indirectly results in injury.
Eg. Medical Database holding details of drugs
Safety & Reliability
• Safety and reliability are related but distinct
– In general, reliability and availability are necessary but not sufficient conditions for
system safety
• Reliability is concerned with conformance to a given specification and delivery of
service
• Safety is concerned with ensuring system cannot cause damage irrespective of
whether or not it conforms to its specification.
Safety Terminology

How to achieve Safety
• Hazard avoidance
– The system is designed so that hazard simply cannot arise.
– Eg. Press 2 buttons at the same time in a cutting machine to start
• Hazard detection and removal
– The system is designed so that hazards are detected and removed before they result in
an accident.
– Eg. Open relief valve on detection over pressure in chemical plant.
• Damage limitation
– The system includes protection features that minimise the damage that may result
from an accident
– Automatic fire safety system in aircraft.
Security
• Security is a system property that reflects the ability to protect itself from accidental
or deliberate external attack.
• Security is becoming increasingly important as systems are networked so that external
access to the system through the Internet is possible
Term Definition
Accident (or mishap)
An unplanned event or sequence of events which results in human death or injury,
damage to property or to the environment. A computer-controlled machine injuring its
operator is an example of an accident.
Hazard
A condition with the potential for causing or contributing to an accident. A failure of the
sensor that detects an obstacle in front of a machine is an example of a hazard.
Damage
A measure of the loss resulting from a mishap. Damage can range from many people
killed as a result of an accident to minor injury or propertydamage.
Hazard severity
An assessment of the worst possible damage that could result from a particular hazard.
Hazard severity can range from catastrophic where many people are killed to minor
where only minor damage results.
Hazard
probability
The probability of the events occurring which create a hazard. Probability values tend to
be arbitrary but range from probable (say 1/100 chance of a hazard occurring) to
implausible (no conceivable situations are likely where the hazard couldoccur).
Risk
This is a measure of the probability that the system will cause an accident. The risk is
assessed by considering the hazard probability, the hazard severity and the probability
that a hazard will result in an accident.

• Security is an essential pre-requisite for availability, reliability and safety
• Example : Viruses, unauthorised use of service/data modification
Security Terminology
Term Definition
Exposure
Possible loss or harm in a computing system. This can be loss or damage to data or
can be a loss of time and effort if recovery is necessary after a security breach.
Vulnerability
A weakness in a computer-based system that may be exploited to cause loss or harm.
Attack
An exploitation of a system vulnerability. Generally, this is from outside the system
and is a deliberate attempt to cause some damage.
Threats
Circumstances that have potential to cause loss or harm. You can think of these as a
system vulnerability that is subjected to an attack.
Control
A protective measure that reduces a system vulnerability. Encryption would be an
example of a control that reduced a vulnerability of a weak access control system.
The software requirements are description of features and functionalities of the target
system. Requirements convey the expectations of users from the software product. The
requirements can be obvious or hidden, known or unknown, expected or unexpected from
client’s point of view.
Requirement Engineering
The process to gather the software requirements from client, analyze and document them is
known as requirement engineering.
The goal of requirement engineering is to develop and maintain sophisticated and
descriptive ‘System Requirements Specification’ document.
Requirement Engineering Process
It is a four step process, which includes –
• Feasibility Study
• Requirement Gathering
• Software Requirement Specification
• Software Requirement Validation
Let us see the process briefly -
Feasibility study
When the client approaches the organization for getting the desired product developed, it
comes up with rough idea about what all functions the software must perform and which all
features are expected from the software.

Referencing to this information, the analysts does a detailed study about whether the desired
system and its functionality are feasible to develop.
This feasibility study is focused towards goal of the organization. This study analyzes
whether the software product can be practically materialized in terms of implementation,
contribution of project to organization, cost constraints and as per values and objectives of
the organization. It explores technical aspects of the project and product such as usability,
maintainability, productivity and integration ability.
The output of this phase should be a feasibility study report that should contain adequate
comments and recommendations for management about whether or not the project should be
undertaken.
Requirement Gathering
If the feasibility report is positive towards undertaking the project, next phase starts with
gathering requirements from the user. Analysts and engineers communicate with the client
and end-users to know their ideas on what the software should provide and which features
they want the software to include.
Software Requirement Specification
SRS is a document created by system analyst after the requirements are collected from
various stakeholders.
SRS defines how the intended software will interact with hardware, external interfaces,
speed of operation, response time of system, portability of software across various
platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations
etc.
The requirements received from client are written in natural language. It is the responsibility
of system analyst to document the requirements in technical language so that they can be
comprehended and useful by the software development team.
SRS should come up with following features:
• User Requirements are expressed in natural language.
• Technical requirements are expressed in structured language, which is used inside the
organization.
• Design description should be written in Pseudo code.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.
Software Requirement Validation
After requirement specifications are developed, the requirements mentioned in this
document are validated. User might ask for illegal, impractical solution or experts may
interpret the requirements incorrectly. This results in huge increase in cost if not nipped in
the bud. Requirements can be checked against following conditions -
• If they can be practically implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities

• If they are complete
• If they can be demonstrated
Requirement Elicitation Process
Requirement elicitation process can be depicted using the folloiwng diagram:
• Requirements gathering - The developers discuss with the client and end users and
know their expectations from the software.
• Organizing Requirements - The developers prioritize and arrange the requirements
in order of importance, urgency and convenience.
• Negotiation & discussion - If requirements are ambiguous or there are some
conflicts in requirements of various stakeholders, if they are, it is then negotiated and
discussed with stakeholders. Requirements may then be prioritized and reasonably
compromised.
The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements are
compromised reasonably.
• Documentation - All formal & informal, functional and non-functional requirements
are documented and made available for next phase processing.
Requirement Elicitation Techniques
Requirements Elicitation is the process to find out the requirements for an intended software
system by communicating with client, end users, system users and others who have a stake
in the software system development.
There are various ways to discover requirements
Interviews
Interviews are strong medium to collect requirements. Organization may conduct several
types of interviews such as:
• Structured (closed) interviews, where every single information to gather is decided in
advance, they follow pattern and matter of discussion firmly.
• Non-structured (open) interviews, where information to gather is not decided in
advance, more flexible and less biased.
• Oral interviews
• Written interviews
• One-to-one interviews which are held between two persons across the table.
• Group interviews which are held between groups of participants. They help to
uncover any missing requirement as numerous people are involved.

Surveys
Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.
Questionnaires
A document with pre-defined set of objective questions and respective options is handed
over to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.
Task analysis
Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is studied
and requirements of proposed system are collected.
Domain Analysis
Every software falls into some domain category. The expert people in the domain can be a
great help to analyze general and specific requirements.
Brainstorming
An informal debate is held among various stakeholders and all their inputs are recorded for
further requirements analysis.
Prototyping
Prototyping is building user interface without adding detail functionality for user to interpret
the features of intended software product. It helps giving better idea of requirements. If there
is no software installed at client’s end for developer’s reference and the client is not aware of
its own requirements, the developer creates a prototype based on initially mentioned
requirements. The prototype is shown to the client and the feedback is noted. The client
feedback serves as an input for requirement gathering.
Observation
Team of experts visit the client’s organization or workplace. They observe the actual
working of the existing installed systems. They observe the workflow at client’s end and
how execution problems are dealt. The team itself draws some conclusions which aid to
form requirements expected from the software.
Software Requirements Characteristics
Gathering software requirements is the foundation of the entire software development
project. Hence they must be clear, correct and well-defined.
A complete Software Requirement Specifications must be:
• Clear
• Correct
• Consistent
• Coherent

• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source
Software Requirements
We should try to understand what sort of requirements may arise in the requirement
elicitation phase and what kinds of requirements are expected from the software system.
Broadly software requirements should be categorized in two categories:
Functional Requirements
Requirements, which are related to functional aspect of software fall into this category.
They define functions and functionality within and from the software system.
Examples -
• Search option given to user to search from various invoices.
• User should be able to mail any report to management.
• Users can be divided into groups and groups can be given separate rights.
• Should comply business rules and administrative functions.
• Software is developed keeping downward compatibility intact.
Non-Functional Requirements
Requirements, which are not related to functional aspect of software, fall into this category.
They are implicit or expected characteristics of software, which users make assumption of.
Non-functional requirements include -
• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility
Requirements are categorized logically as
• Must Have : Software cannot be said operational without them.

• Should have : Enhancing the functionality of software.
• Could have : Software can still properly function with these requirements.
• Wish list : These requirements do not map to any objectives of software.
While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of
debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for
software updates.
User Interface requirements
UI is an important part of any software or hardware or hybrid system. A software is widely
accepted if it is -
• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface
User acceptance majorly depends upon how user can use the software. UI is the only way
for users to perceive the system. A well performing software system must also be equipped
with attractive, clear, consistent and responsive user interface. Otherwise the functionalities
of software system cannot be used in convenient way. A system is said be good if it provides
means to use it efficiently. User interface requirements are briefly mentioned below -
• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of color and texture.
• Provide help information
• User centric approach
• Group based view settings.
Software System Analyst
System analyst in an IT organization is a person, who analyzes the requirement of proposed
system and ensures that requirements are conceived and documented properly & correctly.
Role of an analyst starts during Software Analysis Phase of SDLC. It is the responsibility of
analyst to make sure that the developed software meets the requirements of the client.
System Analysts have the following responsibilities:
• Analysing and understanding requirements of intended software
• Understanding how the project will contribute in the organization objectives
• Identify sources of requirement

• Validation of requirement
• Develop and implement requirement management plan
• Documentation of business, technical, process and product requirements
• Coordination with clients to prioritize requirements and remove and ambiguity
• Finalizing acceptance criteria with client and other stakeholders
Software Metrics and Measures
Software Measures can be understood as a process of quantifying and symbolizing various
attributes and aspects of software.
Software Metrics provide measures for various aspects of software process and software
product.
Software measures are fundamental requirement of software engineering. They not only
help to control the software development process but also aid to keep quality of ultimate
product excellent.
According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot
measure.” By his saying, it is very clear how important software measures are.
Let us see some software metrics:
• Size Metrics - LOC (Lines of Code), mostly calculated in thousands of delivered
source code lines, denoted as KLOC.
Function Point Count is measure of the functionality provided by the software.
Function Point count defines the size of functional aspect of software.
• Complexity Metrics - McCabe’s Cyclomatic complexity quantifies the upper bound
of the number of independent paths in a program, which is perceived as complexity of
the program or its modules. It is represented in terms of graph theory concepts by
using control flow graph.
• Quality Metrics - Defects, their types and causes, consequence, intensity of severity
and their implications define the quality of product.
The number of defects found in development process and number of defects reported
by the client after the product is installed or delivered at client-end, define quality of
product.
• Process Metrics - In various phases of SDLC, the methods and tools used, the
company standards and the performance of development are software process metrics.
• Resource Metrics - Effort, time and various resources used, represents metrics for
resource measurement.
System Modelling
is the process of developing abstract models of a system with model presenting a different view or
perspective of that system.
or
A System Model represent aspects of a system and its environment.

or
System Modelling is a mean of representing a world view a detailed view of the system using same
kind of Graphical Notation.
FeaturesofaSystemModel:
• define the processes that serve the needs of the view under consideration.
• represent the behaviour of the processes and the assumptions on which the behaviour is based.
• explicitly define both a exogenous and endogenous input to the model.
• represent all linkages(input/output) that will enable engineer to better understand the view.
To construct a model, the engineers should consider a number of restraining factors-
assumptions- simplifications - limitations - constraints - preferences
• Assumptions:
It enables a model to reflect the problem in a reasonable manner by reducing the number of
possible permutations and variations.
Example: Representation of 3D human forms
In this input domain maybe that the system engineer makes certain assumptions about the range of
allowable human movements. (leg cannot be wrapped around torso) so that range of Input and
processing can be Limited.
• Simplifications:
That enables the model to be created in a timely manner. Example: A System Engineer is
modelling the needs of the service organisational and is working to understand the flow of information
that spawns a service order. Although a service order can be derived from many origins, the
engineer categorises only two sources.
Internal Demand and External Request
This enables a simplified partitioning of input that is required to generate the service order.
• Limitations: That help to bound the system.
Example: An aircraft avionics system is being modelled for future aircraft. Is the aircraft will be a two-

engine design, the monitoring domain for propulsion will be modelled to accommodate a maximum of
two engines and associative redundant system.
• Constraints: That will guide the manner in which the model is created and the approach taken when
the model is implemented.
Example: Suppose a system for the 3D-rendering describes previously is a singleG4 based processor
so computational complexity of problems must be constrained to fit within processing bounds imposed
by the processor.
• Preferences: It indicates the preferred architecture for all data, functions and technology.
System modeling is the process of developing abstract models of a system, with each model presenting a different
view or perspective of that system. It is about representing a system using some kind of graphical notation, which is
now almost always based on notations in the Unified Modeling Language (UML). Models help the analyst to
understand the functionality of the system; they are used to communicate with customers.
Models can explain the system from different perspectives:
• An external perspective, where you model the context or environment of the system.
• An interaction perspective, where you model the interactions between a system and its environment, or
between the components of a system.
• A structural perspective, where you model the organization of a system or the structure of the data that
is processed by the system.
• A behavioral perspective, where you model the dynamic behavior of the system and how it responds to
events.
Five types of UML diagrams that are the most useful for system modeling:
• Activity diagrams, which show the activities involved in a process or in data processing.
• Use case diagrams, which show the interactions between a system and its environment.
• Sequence diagrams, which show interactions between actors and the system and between system
components.
• Class diagrams, which show the object classes in the system and the associations between these classes.
• State diagrams, which show how the system reacts to internal and external events.
Models of both new and existing system are used during requirements engineering. Models of the existing
systems help clarify what the existing system does and can be used as a basis for discussing its strengths and
weaknesses. These then lead to requirements for the new system. Models of the new system are used during
requirements engineering to help explain the proposed requirements to other system stakeholders. Engineers use these
models to discuss design proposals and to document the system for implementation.
Context & Process Model
Context models are used to illustrate the operational context of a system - they show what lies outside the system
boundaries. Social and organizational concerns may affect the decision on where to position system boundaries.
Architectural models show the system and its relationship with other systems.
System boundaries are established to define what is inside and what is outside the system. They show other systems
that are used or depend on the system being developed. The position of the system boundary has a profound effect on
the system requirements. Defining a system boundary is a political judgment since there may be pressures to develop
system boundaries that increase/decrease the influence or workload of different parts of an organization.
Context models simply show the other systems in the environment, not how the system being developed is used in that
environment. Process models reveal how the system being developed is used in broader business processes. UML
activity diagrams may be used to define business process models.

The example below shows a UML activity diagram describing the process of involuntary detention and the role of
MHC-PMS (mental healthcare patient management system) in it.
Interaction models
Types of interactions that can be represented in a model:
• Modeling user interaction is important as it helps to identify user requirements.
• Modeling system-to-system interaction highlights the communication problems that may arise.
• Modeling component interaction helps us understand if a proposed system structure is likely to deliver
the required system performance and dependability.
Use cases were developed originally to support requirements elicitation and now incorporated into the UML. Each use
case represents a discrete task that involves external interaction with a system. Actors in a use case may be people or
other systems. Use cases can be represented using a UML use case diagram and in a more detailed textual/tabular
format.
Simple use case diagram:
Use case description in a tabular format:
Use case title Transfer data
Description
A receptionist may transfer data from the MHC-PMS to a general patient record database that is
maintained by a health authority. The information transferred may either be updated personal
information (address, phone number, etc.) or a summary of the patient's diagnosis and treatment.
Actor(s) Medical receptionist, patient records system (PRS)
Preconditions
Patient data has been collected (personal information, treatment summary);
The receptionist must have appropriate security permissions to access the patient information and
the PRS.
Postconditions PRS has been updated
Main success
scenario
1. Receptionist selects the "Transfer data" option from the menu.
2. PRS verifies the security credentials of the receptionist.
3. Data is transferred.
4. PRS has been updated.

Extensions
2a. The receptionist does not have the necessary security credentials.
2a.1. An error message is displayed.
2a.2. The receptionist backs out of the use case.
UML sequence diagrams are used to model the interactions between the actors and the objects within a system. A
sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance.
The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these.
Interactions between objects are indicated by annotated arrows.
Structural models
Structural models of software display the organization of a system in terms of the components that make up that
system and their relationships. Structural models may be static models, which show the structure of the system
design, or dynamic models, which show the organization of the system when it is executing. You create structural
models of a system when you are discussing and designing the system architecture.
UML class diagrams are used when developing an object-oriented system model to show the classes in a system and
the associations between these classes. An object class can be thought of as a general definition of one kind of system
object. An association is a link between classes that indicates that there is some relationship between these classes.
When you are developing models during the early stages of the software engineering process, objects represent
something in the real world, such as a patient, a prescription, doctor, etc.

Generalization is an everyday technique that we use to manage complexity. In modeling systems, it is often useful to
examine the classes in a system to see if there is scope for generalization. In object-oriented languages, such as Java,
generalization is implemented using the class inheritance mechanisms built into the language. In a generalization, the
attributes and operations associated with higher-level classes are also associated with the lower-level classes. The
lower-level classes are subclasses inherit the attributes and operations from their superclasses. These lower-level
classes then add more specific attributes and operations.

An aggregation model shows how classes that are collections are composed of other classes. Aggregation models are
similar to the part-of relationship in semantic data models.
Behavioral models
Behavioral models are models of the dynamic behavior of a system as it is executing. They show what happens or
what is supposed to happen when a system responds to a stimulus from its environment. Two types of stimuli:
• Some data arrives that has to be processed by the system.
• Some event happens that triggers system processing. Events may have associated data, although this is
not always the case.
Many business systems are data-processing systems that are primarily driven by data. They are controlled by the data
input to the system, with relatively little external event processing. Data-driven models show the sequence of actions
involved in processing input data and generating an associated output. They are particularly useful during the analysis
of requirements as they can be used to show end-to-end processing in a system. Data-driven models can be created
using UML activity diagrams:
Data-driven models can also be created using UML sequence diagrams:

Real-time systems are often event-driven, with minimal data processing. For example, a landline phone switching
system responds to events such as 'receiver off hook' by generating a dial tone. Event-driven models shows how a
system responds to external and internal events. It is based on the assumption that a system has a finite number of
states and that events (stimuli) may cause a transition from one state to another. Event-driven models can be created
using UML state diagrams:

Socio technical system

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Socio technical system

Similar to Socio technical system (20)

More from Sweta Kumari Barnwal

More from Sweta Kumari Barnwal (20)

Recently uploaded

Recently uploaded (20)

Socio technical system