Software

Engineering
UNIT 2 : Socio-technical system , Critical system
Requirements Engineering Process , System Models

Compiled By: Asst Prof. Kimaya K Shelar

Vidyalankar School Of
Information Technology kimaya.shelar@vsit.edu.in
Wadala(E),Mumbai.
www.vsit.edu.in
 Certificate

This is to certify that the e-book titled “software engineering” comprises all elementary
learning tools for a better understating of the relevant concepts. This e-book is comprehensively compiled as per the
Predefined eight parameters and guidelines.

Signature
Ms. Kimaya K. Shelar
Date: 03-02-2021
Assistant Professor
Department of IT

DISCLAIMER: The information contained in this e-book is compiled and distributed for
educational purposes only. This e-book has been designed to help learners understand relevant
concepts with a more dynamic interface. The compiler of this e-book and Vidyalankar School
of Information Technology give full and due credit to the authors of the contents, developers
and all websites from wherever information has been sourced. We acknowledge our gratitude
towards the websites YouTube, Wikipedia, and Google search engine. No commercial benefits
are being drawn from this project.
Unit II

Contents:

1) Socio-technical system:
Essential characteristics of socio technical systems, Emergent System Properties, Systems
Engineering, Components of system such as organization, people and computers, Dealing
Legacy Systems.

2) Critical system:
Types of critical system, A simple safety critical system, Dependability of a system,
Availability and Reliability, Safety and Security of Software systems.

3) Requirements Engineering Processes:

Feasibility study, Requirements elicitation and analysis, Requirements Validations,
Requirements Management.

4) System Models:
Models and its types, Context Models, Behavioural Models, Data Models, Object Models,
Structured Methods.

Recommended Books:
Sr.
Title Author/s Publisher Edition
No.

Pearson
Ian
1 Software Engineering Education Ninth
Somerville
Pankaj Narosa
2 Software Engineering
Jalote Publication
Software engineering, a Roger Tata
3 Seventh
practitioner’s approach Pressman Mcgraw-hill
Pearson
4 Software Design D.Budgen 2nd
education
5 Software Engineering KL James PHI IEEE
Software Engineering WS Tata
6
principles and practice Jawadekar Mcgraw-hill
Software EngineeringA S.A
7 PHI India.
Concise Study Kelkar
Software Engineering Concept Subhajit OxfordHigher
8
and Applications Datta Education

Prerequisites and Linking

Unit 2 Prerequisites Linkages
Sem 1 Sem II Sem III Sem Sem V Sem VI
IV
Socio- Operating Object Database - Software Software Quality
Technical System Oriented Management Project Assurance,
System Programming System,Computer Management, Project
Networks Project Implementation
Dissertation
Unit II
Socio-technical system
Essential characteristics of socio technical systems
 Sociotechnical systems have defined operational processes and people (the operators)
are inherent parts of the system. Socio-technical systems are systems that are intended
to help deliver a business goal. This might be to increase sales, reduce material used in
manufacturing, collect taxes, maintain a safe airspace, etc. Because they are embedded
in an organizational environment, the procurement, development, and use of these
systems are influenced by the organization’s policies and procedures, and by its
working culture.
 Sociotechnical systems have three characteristics that are particularly important when
considering security and dependability:
1. They have emergent properties that are properties of the system as a whole, rather than
associated with individual parts of the system. Emergent properties depend on both the
system components and the relationships between them. Given this complexity, the
emergent properties can only be evaluated once the system has been assembled.
Security and dependability are emergent system properties.
2. They are often nondeterministic. This means that when presented with a specific input,
they may not always produce the same output. The system’s behavior depends on the
human operators and people do not always react in the same way. Furthermore, use of
the system may create new relationships between the system components and hence
change its emergent behavior. System faults and failures may therefore be transient,
and people may disagree about whether or not a failure has actually occurred.
3. The extent to which the system supports organizational objectives does not just depend
on the system itself. It also depends on the stability of these objectives, the relationships,
and conflicts between organizational objectives and how people in the organization
interpret these objectives. New management may reinterpret the organizational
objectives that a system was designed to support so that a ‘successful’ system may then
be seen as a ‘failure’.

Emergent System Properties

 It has properties that are properties of the system as a whole.
  The emergent properties cannot be attributed to any specific part of the system. Rather,
they only emerge once the system components have been integrated.
 There are two types of emergent properties:

1. Functional emergent properties when the purpose of a system only emerges after its
components are integrated. For example, a bicycle has the functional property of being a
transportation device once it has been assembled from its components.
2. Non-functional emergent properties, which relate to the behavior of the system in its
operational environment. Reliability, performance, safety, and security are examples of
emergent properties. These are critical for computer-based systems, as failure to achieve a
minimum defined level in these properties usually makes the system unusable. Some users may
not need some of the system functions, so the system may be acceptable without them.
However, a system that is unreliable or too slow is likely to be rejected by all its users.

SYSTEMS ENGINEERING

 Systems engineering encompasses all of the activities involved in procuring,

specifying, designing, implementing, validating, deploying, operating, and maintaining
sociotechnical systems. Systems engineers are not just concerned with software but also
with hardware and the system’s interactions with users and its environment. They must
think about the services that the system provides, the constraints under which the
 system must be built and operated, and the ways in which the system is used to fulfill
its purpose or purposes.

 There are three overlapping stages in the lifetime of large and complex
Socio technical systems:

Source – System Engineering

https://www.youtube.com/watch?v=JKUycuyGj7I

1. Procurement or acquisition: - During this stage, the purpose of a system is decided; high-
level system requirements are established; decisions are made on how functionality will be
distributed across hardware, software, and people, and the components that will make up the
system are purchased.

2. Development: - During this stage, the system is developed. Development processes include
all of the activities involved in system development such as requirements definition, system
design, hardware and software engineering, system integration, and testing. Operational
processes are defined and the training courses for system users are designed.

3. Operation: - At this stage, the system is deployed, users are trained, and the system is brought
into use. The planned operational processes usually then have to change to reflect the real
working environment where the system is used. Overtime, the system evolves as new
requirements are identified. Eventually, the system declines in value and it is decommissioned
and replaced.

System procurement process

The initial phase of systems engineering is system procurement (sometimes called system
acquisition). At this stage, decisions are made on the scope of a system that is to be purchased,
system budgets and timescales, and the high-level system requirements.
Using this information, further decisions are then made on whether to procure
a system, the type of system required, and the supplier or suppliers of the system.
The drivers for these decisions are:
1. The state of other organizational systems: - If the organization has a mixture of systems that
cannot easily communicate or that are expensive to maintain, then procuring a replacement
system may lead to significant business benefits.
2. The need to comply with external regulations: - Increasingly, businesses are regulated and
have to demonstrate compliance with externally defined regulations This may require the
replacement of noncompliant systems or the provision of new systems specifically to monitor
compliance.
3. External competition :-If a business needs to compete more effectively or maintain a
competitive position, investment in new systems that improve the efficiency of business
processes may be advisable. For military systems, the need to improve capability in the face of
new threats is an important reason for procuring new systems.
4. Business reorganization: - Businesses and other organizations frequently restructure with
the intention of improving efficiency and/or customer service.
Reorganizations lead to changes in business processes that require new systems support.
5. Available budget: -The budget available is an obvious factor in determining the scope of
new systems that can be procured.
The above figure shows a simplified model of the procurement process for both COTS system
components and system components that have to be specially designed and developed.
Important points about the process shown in this diagram are:
1. Off-the-shelf components do not usually match requirements exactly, unless the
requirements have been written with these components in mind. Therefore, choosing a system
means that you have to find the closest match between the system requirements and the
facilities offered by off-the-shelf systems. You may then have to modify the requirements. This
can have knock-on effects on other subsystems.
2. When a system is to be built specially, the specification of requirements is part of the contract
for the system being acquired. It is therefore a legal as well as a technical document.
3. After a contractor has been selected, to build a system, there is a contract negotiation period
where you may have to negotiate further changes to the requirements
and discuss issues such as the cost of changes to the system. Similarly,
once a COTS system has been selected, you may negotiate with the supplier on
costs, license conditions, possible changes to the system, etc.
System development

 The goals of the system development process are to develop or acquire all of the
components of a system and then to integrate these components to create the final
system. The requirements are the bridge between the procurement and the development
processes.

 However, there are essentially six fundamental activities in systems development:

1. Requirements development: - The high-level and business requirements identified

during the procurement process have to be developed in more detail. Requirements may
have to be allocated to hardware, software, or processes and prioritized for
implementation.

2. System design: -This process overlaps significantly with the requirements development
process. It involves establishing the overall architecture of the system, identifying the
different system components and understanding the relationships between them.

3. Subsystem engineering: - This stage involves developing the software components of

the system; configuring off-the-shelf hardware and software, designing, if necessary,
special-purpose hardware; defining the operational processes for the system; and
redesigning essential business processes.

4. System integration: - During this stage, the components are put together to create a new
system. Only then do the emergent system properties become apparent.
 5. System testing: -This is usually an extensive, prolonged activity where problems are
discovered. The subsystem engineering and system integration phases are re-entered to
repair these problems, tune the performance of the system, and implement new
requirements. System testing may involve both testing by the system developer and
acceptance/user testing by the organization that has procured the system.

6. System deployment: - This is the process of making the system available to its users,
transferring data from existing systems, and establishing communications with other
systems in the environment. The process culminates with a ‘go live’ after which users
start to use the system to support their work.

System operation
 Operational processes are the processes that are involved in using the system for its
defined purpose. For example, operators of an air traffic control system follow specific
processes when aircraft enter and leave airspace, when they have to change height or
speed, when an emergency occurs, and so on. For new systems, these operational
processes have to be defined and documented during the system development process.
Operators may have to be trained and other work processes adapted to make effective
use of the new system. Undetected problems may arise at this stage because the system
specification may contain errors or omissions. Although the system may perform to
specification, its functions may not meet the real operational needs.

 Consequently, the operators may not use the system as its designers intended.

 The key benefit of having system operators is that people have a unique capability of
being able to respond effectively to unexpected situations, even when they have never
had direct experience of these situations. Therefore, when things go wrong, the
operators can often recover the situation although this may sometimes mean that the
defined process is violated. Operators also use their local knowledge to adapt and
improve processes.
 Consequently, you should design operational processes to be flexible and adaptable.
The operational processes should not be too constraining, they should not require
operations to be done in a particular order, and the system software should not rely on
 a specific process being followed. Operators usually improve the process because they
know what does and does not work in a real situation.

Components of system such as organization, people and computers

• Socio technical systems are enterprise systems that are intended to help deliver some
organizational or business goal.
• Because they are embedded in the organizational environment, the, development and
the use of these systems is influenced by the organization’s policies and procedures by
its working culture.
• The users of the system are the people who are influenced by the way the organization
is managed and by their interaction with other people inside and outside the
organization.
• Human and organizational factors from the system’s environment that affect the system
design include:

• PROCESS CHANGES:-
1) Does the system require changes to the work processes in the environment?
2) If changes happen in the process then training is mandatory.

• JOB CHANGES:-
1) Does the system de-skill the users in the environment or cause them to change the
way they work ?
2)If the job changes are resented in the organization, than the employee has to be well
trained to be accepted by the introduction of the system in the organization.

• ORGANISATIONAL CHANGES: -
1) Does the system change the structure in an organization?
2) Depending upon the complexity of the organization, the changes has to be accepted
in the organization.
Legacy Systems

• Legacy system are Socio-technical computer based systems that have been developed
in the past using an obsolete technology.
• These system includes various sub-systems, processes and procedures which are
working on older ways and rely on legacy systems that are difficult to change.
• These systems are crucial to the operation of a business and it is often too risky to be
discarded such as bank customer accounting system and aircraft maintenance system
etc.
• Legacy systems constrains new business processes and consume a high proportion of
company budgets.
Various issues are:-
1) Do we throw away and restart or continue to maintain ?
2) What are the economics (cost and risk) of each approach.
3) If system depends on other COTS, will upgrades to those be available?

LEGACY SYSTEM COMPONENTS

• System hardware – Legacy systems have been written for mainframe hardware that is
no longer available, that is expensive to maintain and that may not be compatible with
current organizational IT purchasing policies
• Support software – The legacy system may rely on a range of support software from
the operating system and utilities provided by the hardware manufacturer through to
the compilers used for system development
• Application software – The application system that provides the business services is
usually composed of a number of separate programs that have been developed at
different times.
• Application Data – These are the data that are processed by the application system. In
many legacy systems, an immense volume of data has accumulated over the lifetime of
the system. This data may be inconsistent and may be duplicated in several files
• Business process – These are processes that are used in the business to achieve some
business objective. Business processes may be designed around a legacy system and
constraint by the functionality that it provides
• Business policies and rules – These are definitions of how the business should be carried
out and constraints on the business

Source- Legacy System

https://www.youtube.com/watch?v=lm1V49D1Z-s

Critical Systems
• Systems failure that can result insignificant economic losses, physical damage or threats
to human life.
• They are technical or socio technical systems that people depend on
• If these systems fail to deliver their services as expected, then serious problems and
significant loses may result.

Types Of Critical Systems

• Safety-critical system – System whose failure may result in injury, loss of life or serious
environmental damage. Example Control system for a chemical manufacturing plant
• Mission-critical system – System whose failure may result in the failure of some goal
directed activity. Example Navigational system for a spacecraft
 • Business-critical system – System whose failure may result in very high costs for the
business using that system. Example Customer accounting system in a bank.
Simple Safety-critical system

The system is an insulin system as a safety-critical system. A software-controlled insulin pump

is used by diabetics to simulate the function of the pancreas which manufactures insulin , an
essential hormone that metabolises blood glucose. It measures blood glucose(sugar) using a
micro-sensor and computes the insulin dose required to metabolize the glucose.
A common condition where the human pancreas is unable to produce sufficient quantities of a
hormone is called insulin.
1) Insulin metabolizes glucose in the blood.
2) Low levels of blood glucose (too much insulin).
3) Temporary brain malfunctioning, unconsciousness and death.
4) High level of blood glucose (too little insulin).
5) Eye damage, kidney damage and heart problems.
6) Miniaturized sensors.
7) Automated insulin delivery system.
8) Monitor blood sugar level.
9) Deliver appropriate dose of insulin when required.
 System Dependability

• It is the property of the system that equals to its trustworthiness. Trustworthiness means
the degree of user confidence that will operate as they expect and will not fail. Four
principal dimensions to dependability are
– Availability – The ability of the system to deliver services when required.
– Reliability – The ability of the system to deliver services as specified.
– Safety – The ability of the system to operate without Catastrophic failure.
– Security –– The ability of the system to protect itself against accidental or
deliberate interruption.

Other system properties that can be considered as Dependability properties are: -

1) Reparability: - System failures are inevitable, but the disruption caused by failure can
be minimized if the system can be repaired quickly. For that to happen, it must be
possible to diagnose the problem, access the component that has failed, and make
changes to fix that component.
2) Maintainability: - As system are used, new requirements emerge and it is important to
maintain the usefulness of a system by changing it to accommodate these new
requirements.
 3) Survivability: - It is the ability of a system to continue to deliver service while under
attack or when the part of the system is disabled.
4) Error Tolerance:-It is the extent to which the system has been designed so that user
input errors are avoided and tolerated.

Availability and Reliability

• System availability and reliability are closely related properties that can both be
expressed as numerical probabilities.
• The availability of a system is the probability that the system will be up and running to
deliver these services to users on request.
• The reliability of a system is the probability that the systems services will be correctly
delivered as specified.
• Reliability and availability are closely related but sometimes one is more important than
the other. If user expect continuous service from a system, then the system has a high
available requirement. It must be available whenever a demand is made. However, if
the losses that result from a system failure are low and the system can recover quickly
then failures don’t seriously affect the system users. In such systems, the reliability
requirements may be relatively low.
• Reliability and availability are compromised by system failures like a failure to deliver
a service etc.
• It is helpful to distinguish between the terms fault, error and failure

Reliability Terminology

Source : Reliabilty
https://www.youtube.com/watch?v=apRKaqBiNQg
Safety

• Safety-critical systems are systems where it is essential that system operation is always
safe, that is the system should never damage people or the system’s environment even
if the system fails. Eg include control and monitoring systems in aircraft, process
control systems in chemical and pharmaceutical plants and automobile control systems.
• Safety critical software falls in two classes:
• Primary safety critical software – Embedded as a controller in a system. Malfunctioning
of such software can cause hardware malfunction which results in human injury or
environmental damage.
• Secondary safety critical software – Indirectly results in injury. Example is medical
database holding details of drugs administered to patients error in this could result in
wrong dosage of drugs

Source : Safety System

https://www.youtube.com/watch?v=mVP69RUtyFU
 • The key to assuring safety is to ensure that accidents do not occur or that the
consequences of an accident are minimal. This can be achieved by
• Hazard avoidance – System is designed so that hazards are avoided.
• Hazard detection and removal – System is designed so that hazards are detected
and removed before they result in an accident.
• Damage limitation – The system may include protection features that minimize
the damage that may result from the accident.
Security

• Security is ability of a system to protect itself from external accidental or deliberate

attacks which may be accidental or deliberate.
• As more systems get connected to Internet it can be attacked by people with unfriendly
intentions.
• Examples of attacks might be the installation of viruses and Trojan horses, unauthorized
use of system services or unauthorized modification of a system or its data.
• For some systems, security is the most important dimension of system dependability.
Military systems, system for electronic commerce and systems that involve the
processing and interchange of confidential information must be designed so that they
achieve a high level of security.
 • If an airline reservation system is unavailable, this causes inconveniences and some
delays in issuing tickets. However, if the system is insecure then the attacker could
delete all bookings and it would be practically impossible for normal airline operations
to continue.

SECURITY TERMINILOGY

Source :Requirements Engineering Processes

https://www.youtube.com/watch?v=_llqRnlrzWw

• The goal of this process is to create and maintain a system requirements document.
• Requirement engineering process includes four high level activities:
1) If the system is useful to the business (Feasibility study).
2) Discovering requirements (Elicitations and Analysis).
3) Converting these requirements into some standard form (Specification).
4) Checking that the requirements actually define the system that the customer wants
(Validation).
 Feasibility Studies
• For all new systems the requirement engineering process should start with feasibility
study.
• The input to the feasibility study is preliminary requirements, an outline description of
how the system is intended to support business process.
• The results is the report that recommends whether or not it is worth carrying on with
the project.
• Thus a feasibility study is a short focused study that aims to answer a number of
questions like system contribution, system implementation and system integration.
• If the system does not support the business objectives it has no real value to the
business.
• Carrying out a feasibility study involves information assessment, information collection
and report writing.
• The information assessment phase identifies the information that is required and once
the information is gathered discussion with various sources can be done.

Elicitations and Analysis

• In this activity software engineers work with customers and system end users to find
about their application domain
• This activity may involve a variety of people in the organization
• The term stakeholder is used to refer to an person or group who will be directly or
indirectly affected by the system
• Eliciting and understanding stakeholder requirements is difficult because
– Stakeholders often don’t know what they want from the computer system hence
they may make unrealistic demands
– Stakeholders naturally express requirements in their own terms and with
implicit knowledge of their own work. Requirements engineers without
experience of customer domain must understand these requirements
– Different stakeholders have different requirements which they may express in
different ways. Requirement engineers have to consider all potential sources of
requirements and discover commonalities and conflict
– Political factors may influence the requirements of the system
– The economic and the business environment in which the analysis takes place
is always changing. Hence the need for new requirements may arise from
various stakeholders
• The activities used in the elicitation and analysis process are:

– Requirements discovery – This is the process on interacting with stakeholders

in the system to collect their requirement. Domain requirements from the
stakeholders and documentation are discovered during this activity.
– Requirements classification and organization – This activity takes the
unstructured collection of requirements and organizes them into clear clusters.
 – Requirement prioritization and negotiation – This activity is concerned with
prioritizing requirements and finding an resolving requirements conflicts
through negotiation.
– Requirements documentation – The requirements are documented and input
into next round of spiral .

Requirements Discovery
• It is the process of gathering information about the proposed and existing system and
filtering the user requirements from it. Sources of information during the requirements
discovery phase includes documentation, system stakeholders and specification of
similar systems. The different ways of gathering information are
• Viewpoints – It can be used to classify stakeholders and other sources of requirements.
There are three different types of viewpoints.
– Interactor viewpoints represent people or other systems that interact directly
with the system
– Indirect viewpoints represent stakeholders who do not use the system
themselves but who influence the requirements in some way
– Domain viewpoints represents domain characteristics and constraints that
influence the system requirements.
• Viewpoints provide different types of requirements. Interactor viewpoints provide
detailed system requirements where as indirect viewpoints are more likely to provide
higher level organizational requirements and constraints and domain viewpoints
normally provide domain constraints that apply to the system. The initial identification
of viewpoints that are relevant to a system can sometimes be difficult. Viewpoints that
provide requirements may come from the marketing and external affairs departments.
For a non-trivial system there is huge number of viewpoints
• Interviewing – In this portion questions are put to the stakeholders about the system.
Interviews can be of open type (no predefined set of questions) or closed type
(predefined set of questions).
• Interviews are good for getting an overall understanding of what the stakeholders do,
how they might interact with the system and the difficulties that they face with current
systems.
 • Interviews are not so good for understanding the requirements from the application
domain because there are subtle power and influence relationships between the
stakeholders in the organization
• Effective interviews have two characteristics
– They are open minded avoid perceived ideas about the requirements and are
willing to listen to stakeholders
– They prompt the interviewee to start discussion with a question
• Information from interviews supplements other information about the system from
documents, user observations and so on
• Sometimes interviews may be the only source of information but still it may miss an
important thing and hence it should be used alongside other requirements techniques
• Scenarios – They are particularly useful for adding detail to an outline requirements
description.
• Several form of scenarios provide different types of information at different levels of
detail about the system.
• The scenario starts with an outline of the interaction and during elicitation details are
added to create a complete description of that interaction
• Scenario based elicitation can be carried out informally where the requirements
engineer works with stakeholders to identify scenarios
• Scenarios may be written as text, supplemented by diagrams, screen shots etc.
• Use-cases – They are scenario based technique for requirements elicitation.
• They have now become a fundamental feature of the UML notation for describing
object oriented system models.
• Use-cases identify the individual interactions with the system
• They can be documented with text or linked with UML models
• The UML is a de facto standard for object oriented modeling so use cases and use case
based elicitation is increasingly used for requirements elicitation

Requirements Validation
• It is concerned with showing that the requirements actually define the system that the
customer wants
• It overlaps analysis in that it is concerned with finding problems with the requirements
• It is important because errors in requirements documentation can lead to extensive
rework costs when they are discovered during development process
 • The cost of fixing a requirements problems is much greater than repairing design or
coding errors
• Various checks carried out on requirements in requirements document are
– Validity checks – A system is needed to perform certain functions
– Consistency checks – Requirements should not be contradictory or of the same
system function
– Completeness checks – Requirements document should include all functions
and constraints
– Realism checks – Requirements should be checked to ensure that they could
actually be implemented
– Verifiability – Requirements should always be written so that they are verifiable
Requirements Validation Technique

• Requirements reviews – The requirements are analysed systematically by a team of

reviewers
• Prototyping – In this approach to validation an executable model of the system is
demonstrated to end users and customers
• Test case generation – Tests for the requirements are devised as a part of validation
process. Developing tests from the user requirements before any code is written in an
integral part of extreme programming
• Requirement review is a manual process that involves people from both client and
contractor organizations.
• They check the requirements document for irregularities and errors.
• Requirements reviews can be informal (involves contractors discussing requirements
with stake holders) and formal (the development team walks through the system
requirements)
• Reviewers may also check for
– Verifiability
– Comprehensibility
– Traceability
– Adaptability

Requirements Management
 • Requirements for the large system keeps on changing due to which stakeholders
understanding of problem is constantly changing.
• It is hard for the users and system customers to anticipate what effects the new system
will have on organization
• New needs and priorities are discovered
– Large systems have different users having different requirements and priorities
– After delivery new features may be added for user support if the system is to
meet its goal
– Business and technical environment changes after installation and these changes
must be reflected in the system
• Hence it is the process of understanding and controlling changes to system
requirements. The process of requirement process should start after draft version of
requirement is available but planning of managing the changing requirements must start
during requirements elicitation process
Requirements Management Planning
• Planning is an essential first stage in the requirements management process.
• During the requirement management stage ,following are decided:-
– Requirements Identification – Each requirement must be uniquely identified
– Change management process – Set of activities that assess the impact and cost
of changes
– Traceability policies – Define relationships between requirements and between
requirements and system
– Tool support- Tools that may be used range from specialist requirement
management systems to spreadsheets and simple data base systems.
Requirements management needs automated support and the software tools and this
should be chosen during the planning phase. The needed tool support are:-
1) Requirements storage:- The requirements should be maintained in a secure ,
managed data store that is accessible to everyone involved in the requirements
engineering process.
2) Change management:- The process of change management is simplified if
active tool support is available.
3) Traceability management:- some tools are available which use natural
language processing techniques to help discover possible relationship
between requirements.
Requirements change managements

Change management is essential because you need to decide if the benefits of implementing
new requirements are justified by the costs of implementation. The advantage of using a formal
process for change management is that all change proposals are treated consistently and
changes to the requirements document are made in a controlled way.

There are three principal stages to a change management process:

1. Problem analysis and change specification :-During
this stage, the problem or the change proposal is analyzed to check that it is
valid. This analysis is fed back to the change requestor who may respond with a
more specific requirements change proposal, or decide to withdraw the request.
2. Change analysis and costing:-The cost of making the change is estimated both in terms of
modifications to the requirements document and, if appropriate, to the system design and
implementation. Once this analysis is completed, a decision is made whether or not to proceed
with the requirements change.
3. Change implementation The requirements document and, where necessary, the system
design and implementation, are modified. You should organize the
requirements document so that you can make changes to it without extensive
rewriting or reorganization

System Models
System modeling is the process of developing abstract models of a system, with each model
presenting a different view or perspective of that system. System modeling uses some kind of
graphical notation, Unified Modeling Language (UML).

Models are used during the requirements engineering process to help derive the requirements
for a system, during the design process to describe the system to engineer implementing the
system and after implementation to document the system’s structure and operation. You may
develop models of both the existing system and the system to be developed:
1. Models of the existing system are used during requirements engineering. They 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.
2. 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.

The UML has many diagram types and so supports the creation of many
different types of system model.
UML five diagram types could represent the essentials of a system:
1. Activity diagrams, which show the activities involved in a process or in data
processing.
2. Use case diagrams, which show the interactions between a system and its environment.
3. Sequence diagrams, which show interactions between actors and the system and between
system components.
4. Class diagrams, which show the object classes in the system and the associations between
these classes.
5. State diagrams, which show how the system reacts to internal and external events.

Context Models
• At an early stage in the requirements elicitation and analysis process boundaries of the
system must be decided involving system stakeholders
• In some cases the boundary between a system and its environment is relatively clear.
For example where an automated system is replacing an existing manual or
computerized system the environment of the new system is usually the same as the
existing system where as in other cases the stakeholders decide the boundary. For
example in the library system the user decides the boundary whether to include library
catalogues for accessing or not
• Once some decisions on the boundaries of the system has been made part of the activity
is definition of that context. Producing a simple architectural model is the first activity
 • In the above figure each ATM is connected to account database, local branch
accounting system, a security system and a system to support machine maintenance.

• The system is also connected to usage database that monitors how the networks of ATM
is used and to a local branch counter system.

• This counter system provides services such as backup and printing.

• These therefore need not be included in the ATM system itself.

• Architectural models describes the environment of the system but do not show the
relationships between the other systems in the environment and the system that is being
specified

• Simple architecture models are supplemented by other models such as process models
that show the process activities by the system

Behavioural Model
• Used to describe the overall behavior of the system
• These are of two types
 – Data Flow Models which model the data processing in the system
– State Machine Models which model how the system reacts to events
• Some systems are driven by data so data flow model is enough to represent their
behavior
• Real time systems are often driven with minimal data processing and hence state
machine model is most effective

Data Flow Models

• An intuitive way of showing how data is processed by a system
• At the analysis level they should be used to model the way in which data is processed
in the existing system
• Notations used in this model represents functional processing (rounded rectangles) data
stores (rectangles) and data movements between functions (labeled arrows)
• Used to show how data flows through a sequence of processing steps
• The data is transformed or processed before moving to the next step which are known
as software processes or functions
• Data flow models are valuable because tracking and documenting how the data
associated with a particular process moves through the system.
• They are simple and intuitive and is usually possible to explain them to potential system
users.
• Following are two data flow models of Order Processing and Insulin Pump

Data Flow Model For Order Processing

State Machine Models

• It describes how a system responds to internal or external events and shows the system
states and events that cause transitions from one state to another but does not show the
flow of data within the system
• This type of model is often used for modelling real time systems
• These models are an integral part of real time design methods and assumes that at any
time the system is in one of the number of possible states
• The problem with the state machine approach is that the number of possible states
increases rapidly and therefore some structuring is needed
• The following figure shows the state machine model of a simple microwave oven
Data Models

• An important part of system modeling is defining the logical form of data processed by
the system. These are called as semantic data models.
• The most widely used data modeling technique is ERA (Entity-Relation-Attribute)
modeling
• The relationship models devised from this system are in 3NF and hence they been
widely used
• Because of the explicit typing and the recognition of the subtypes and super types it is
also straight forward to implement these models using object oriented databases
• Data models lack detail and more descriptions of ERA must be maintained by using
data dictionaries
• Data dictionaries are used to develop system models
• It is simply an alphabetical list of names included in model
• The advantages of data dictionary are it checks for the uniqueness and warns against
name duplications and it stores all data in a single place
• The following figure is an example of data model
Object Model
• Expressing the system requirements using object model, designing using objects and
developing using languages like C++ and Java
• Object models developed during requirements analysis are used to represent both data
and its process. They combine some uses of dataflow and semantic models
• They are also useful for showing how entities in the system may be classified and
composed of other entities. Objects are executable entities with attributes and services
of the object class and many objects can be created from a class
• The following diagram shows an object class in UML as a vertically oriented rectangle
with three sections – name of the object, class attributes, operations associated with the
object
Structured Methods
• Systematic way of producing models of an existing system or proposed system
• Provide a framework for detailed system modeling as part of requirements elicitation
and analysis
• Have their own preferred set of system models and usually define a process that are
used to derive these models and set of rules and guidelines that apply to the models
• CASE tools usually used support model editing, coding, report generation and some
model checking capabilities
• Have been applied in many large projects because they use standard notations and
ensure standard design documentation
• Suffer from following weakness
– Do not provide effective support for understanding non-functional requirements
– Do not include guidelines whether a method is appropriate nor do they advice
on how they can be adapted for a particular project
– Produce too much documentation
 – Models produced are very detailed hence difficult to understand

Module 1 Introduction to Software engineering

 MULTIPLE CHOICE QUESTIONS

1) Socio-technical systems are systems that are intended to help deliver a __________.
a) Business Goals
b) Organizational policies
c) Working culture
d) Procedures

2) Socio-technical systems have __________ properties that are properties of the system
as a whole rather than associated with individual parts of the system.
a) Security
b) Dependability
c) Reliability
d) Emergent

3) The initial phase of system engineering is ______________.

a) Operation
b) System acquisition
c) Management
d) Development

4) _________ diagrams, shows the interaction between a system and its environment.
a) Sequence
b) Activity
c) Use case
d) State

5) _________ is the process of gathering information about the proposed and existing
system and filtering the user requirements from it.
a) Requirement specification
b) Requirement classification
c) Requirement negotiation
d) Re quirement discovery
6) The measure of the probability that the system will cause an accident is called
_______.
a) Risk
b) Hazard probability
c) Hazard severity
d) Damage

7) An event that occurs at some point in time when the system does not deliver a service
as expected by its users is ____________.
a) System error
b) System failure
 c) Human error
d) System fault

8) System availability and ________ are closely related properties that can both be
expressed as numerical probabilities.
a) Dependability
b) Safety
c) Security
d) Reliability

9) The ability of a system to continue to deliver service while under attack or when the
part of the system is disabled is called___________.
a) Maintainability
b) Survivability
c) Error tolerance
d) Reliability

10) System whose failure may result in the failure of some goal directed activities are
___________ system.
a) Business critical
b) Technical
c) Safety critical
d) Mission critical

11) The __________ of a system varies depending on how the component assemblies
are arranged and connected.
a) Reliability
b) Volume
c) Security
d) Repairability

12) System _________ depends on component .

a) Reliability
b) Repairability
c) Security
d) Usability

13) ______________ is the process of defining the elements of the system such as
architecture, components and modules and their interaction of how the data goes through the
system.

a) System Engineering
b) System Design
c) System Modelling
d) System, Development

13) ____________ system whose failure results in a very high cost .

 a) Business Critical
b) Mission Critical
c) Safety Critical
d) Security Critical

14) _____________ system whose failure may cause a failure in business operations.
a) Business Critical
b) Mission Critical
c) Safety Critical
d) Security Critical

15) ______ identifies risks from the systems environment .

a) Preliminary risk analysis
b) Life Cycle risk analysis
c) Operational risk analysis
d) Business risk analysis
16) __________ identifies risks that emerge during design and development .
a) Preliminary risk analysis
b) Life Cycle risk analysis
c) Operational risk analysis
d) Business risk analysis

17) ________________ associated with the system user interface and operator errors.
a) Preliminary risk analysis
b) Life Cycle risk analysis
c) Operational risk analysis
d) Business risk analysis

18) __________ Reflects the extent to which the system can be repaired in the event of a
failure
a) Reparability
b) Maintainability
c) Survivability
d) Error Tolerance

19) ________ reflects the extent to which user input errors can be avoided and tolerated.
a) Reparability
b) Maintainability
c) Survivability
d) Error Tolerance

20) ________ reflects the extent to which the system can be adapted to new
requirements.
a) Reparability
b) Maintainability
c) Survivability
d) Error Tolerance