Software Engineering and Testing [20CS45]

]
MODULE 2

Requirements Engineering: Functional and non-functional requirements. Requirements

Engineering Processes. Requirements Elicitation. Requirements Specification. Requirements
validation. Requirements change.
System Modelling: Context models. Interaction models. Structural models. Behavioural models.
SLE: Model-driven architecture
Textbook 1: Ch. 4, Ch. 5

CHAPTER 4

REQUIREMENTS ENGINEERING

 The process of finding out, analyzing, documenting and checking the services (controlling a
device, placing an order or finding information) and constraints is called requirements
engineering (RE)
 The term requirement is not used consistently in the software industry. In some cases, a
requirement is simply a high-level, abstract statement. At the other extreme, it is a detailed,
formal definition of a system function
 Some of the problems that arise during the requirements engineering process are a result of
failing to make a clear separation between these different levels of description
 So, we distinguish between them by using the term user requirements to mean the high-level
abstract requirements and system requirements to mean the detailed description of what the
system should do
 User requirements and system requirements may be defined as follows
1. User requirements are statements, in a natural language plus diagrams, of what services the
system is expected to provide to system users and the constraints under which it must
operate. The user requirements may vary from broad statements of the system features
required to detailed, precise descriptions of the system functionality.
2. System requirements are more detailed descriptions of the software system’s functions,
services, and operational constraints. The system requirements document (sometimes called
a functional specification) should define exactly what is to be implemented. It may be part
of the contract between the system buyer and the software developers.
 The example from the mental health care patient information system (Mentcare), Figure 4.1

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 1

 Software Engineering and Testing [20CS45]
]
shows how a user requirement may be expanded into several system requirements

 You need to write requirements at different levels of detail because different types of readers
use them in different ways
 The Figure 4.2 shows the types of readers of the user and system requirements

 Requirements Engineering is usually presented as the first stage of the software engineering
process. However, some understanding of the system requirements may have to be
developed before a decision is made to go ahead with the procurement or development of a
system.
 This early-stage RE establishes a high-level view of what the system might do and the
benefits that it might provide. These may then be considered in a feasibility study, which
tries to assess whether or not the system is technically and financially feasible
 The results of that study help management decide whether or not to go ahead with the
procurement or development of the system.

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 2

 Software Engineering and Testing [20CS45]
]
4.1 Functional and non-functional requirements
 Software system requirements are often classified as functional requirements or non- functional
requirements
1. Functional requirements: These are statements of services the system should provide, how
the system should react to particular inputs, and how the system should behave in particular
situations.
2. Non-functional requirements: These are constraints on the services or functions offered by
the system. They include timing constraints, constraints on the development process, and
constraints imposed by standards.
4.1.1 Functional requirements
 The functional requirements for a system describe what the system should do
 These requirements depend on the type of software being developed, the expected users of the
software, and the general approach taken by the organization when writing requirement
 When expressed as user requirements, functional requirements are usually described in an
abstract way that can be understood by system users.
 Functional system requirements vary from general requirements covering what the system
should do to very specific requirements reflecting local ways of working or an organization’s
existing systems.
 Examples for functional requirements for Mentcare system includes
- A user shall be able to search the appointments lists for all clinics
- The system shall generate each day, for each clinic, a list of patients who are expected to
attend appointments that day
- Each staff member using the system shall be uniquely identified by his or her eight- digit
employee number
 The functional requirements specification of a system should be both complete and consistent.
- Completeness means that all services required by the user should be defined
- Consistency means that requirements should not have contradictory definitions
4.1.2 Non-functional requirements
 They are requirements that are not directly concerned with the specific services delivered by the
system to its users
 They may relate to emergent system properties such as reliability, response time, and store
occupancy
 Non-functional requirements, such as performance, security, or availability, usually specify or

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 3

 Software Engineering and Testing [20CS45]
]
constrain characteristics of the system as a whole
 Non-functional requirements are often more critical than individual functional requirement
 The implementation of these requirements may be diffused throughout the system. There are
two reasons for this:
- Non-functional requirements may affect the overall architecture of a system rather than the
individual components
- A single non-functional requirement, such as a security requirement, may generate a number
of related functional requirements that define new system services that are required. The
figure 4.3 shows the classification of non- functional requirements

Fig 4.3: Types of non-functional requirements

 The classification of non-functional requirements includes various types
1. Product Requirements
- These requirements specify or constrain the behavior of the software
- Examples include performance requirements on how fast the system must execute and
how much memory it requires, reliability requirements that set out the acceptable failure
rate, security requirements, and usability requirements
2. Organizational Requirements
- These requirements are broad system requirements derived from policies and procedures
in the customer’s and developer’s organization
- Examples include operational process requirements that define how the system will be

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 4

 Software Engineering and Testing [20CS45]
]
used, development process requirements that specify the programming language, the
development environment or process standards to be used, and environmental
requirements that specify the operating environment of the system
3. External requirements
- This broad heading covers all requirements that are derived from factors external to the
system and its development process
- These may include regulatory requirements that set out what must be done for the
system to be approved for use by a regulator, such as a central bank
 The fig 4.5 below shows the metric used for specifying non-functional requirements

Figure 4.5 Metrics for specifying nonfunctional requirements

4.2 Requirements Engineering Processes

 Requirements engineering processes may include four high-level activities

 These focus on assessing if the system is useful to the business (feasibility study), discovering
requirements (elicitation and analysis), converting these requirements into some standard form
(specification), and checking that the requirements actually define the system that the customer
wants (validation).

 Fig 4.6 shows this interleaving. The activities are organized as an iterative process around a
spiral, with the output being a system requirements document.

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 5

 Software Engineering and Testing [20CS45]
]

 The amount of time and effort devoted to each activity in each iteration depends on the stage of
the overall process and the type of system being developed

 This spiral model accommodates approaches to development where the requirements are
developed to different levels of detail

 The number of iterations around the spiral can vary so the spiral can be exited after some or all
of the user requirements have been elicited

4.3 Requirements elicitation

 After an initial feasibility study, the next stage of the requirements engineering process
isrequirements elicitation and analysis
 In this activity, software engineers work with customers and system end-users to find
out about the application domain, what services the system should provide, the required
performance of the system, hardware constraints, and so on
 A process model of the elicitation and analysis process is shown in fig 4.7

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 6

 Software Engineering and Testing [20CS45]
]

 The process activities are

1. Requirements discovery and understanding: This is the process of interacting with
stakeholders of the system to discover their requirements. Domain requirements from
stakeholders and documentation are also discovered during this activity.

2. Requirements classification and organization: This activity takes the unstructured

collection of requirements, groups related requirements, and organizes them into coherent
clusters. The most common way of grouping requirements is to use a model of the system
architecture to identify sub-systemsand to associate requirements with each sub-system.

3. Requirements prioritization and negotiation: This activity is concerned with

prioritizing requirements and finding and resolving requirements conflicts through
negotiation. Usually, stakeholders have to meet to resolve differences and agree on
compromise requirements.

4. Requirements documentation: The requirements are documented and input into the
next round of the spiral. Formal or informal requirements documents may be produced.
 Eliciting and understanding requirements from system stakeholders is a difficult process for
several reasons:
1. Stakeholders often don’t know what they want from a computer system except in the most
general terms; they may find it difficult to articulate what they want the system to do; they
may make unrealistic demands because they don’t know what is and isn’t feasible.
2. Stakeholders in a system naturally express requirements in their own terms and with
implicit knowledge of their own work. Requirements engineers, without experience in the
customer’s domain, may not understand these requirements.
3. Different stakeholders have different requirements and they may express these in different
Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 7
 Software Engineering and Testing [20CS45]
]
ways. Requirements engineers have to discover all potential sources of requirements and
discover commonalities and conflict.
4. Political factors may influence the requirements of a system. Managers may demand
specific system requirements because these will allow them to increase their influence in
the organization.
5. The economic and business environment in which the analysis takes place is dynamic. It
inevitably changes during the analysis process. The importance of particular requirements
may change. New requirements may emerge from new stakeholders who were not
originally consulted.
4.3.1 Requirements elicitation techniques
 Requirements elicitation involves meeting with stakeholders of different kinds to discover
information about the proposed system
 You may supplement this information with knowledge of existing systems and their
usage and information from documents of various kinds
 There are two fundamental approaches to requirements elicitation
- Interviewing, where you talk to people about what they do.
- Observation or ethnography, where you watch people doing their job to see what
artifacts they use, how they use them, and so on.

4.3.1.1 Interviewing

 In these interviews, the requirements engineering team puts questions to stakeholders about the
system that they currently use and the system to be developed.
Interviews may be of two types:
1. Closed interviews, where the stakeholder answers a pre-defined set of questions.
2. Open interviews, in which there is no pre-defined agenda. The requirements engineering
team explores a range of issues with system stakeholders and hence develops a better
understanding of their needs.
 It can be difficult to elicit domain knowledge through interviews for two reasons:
1. All application specialists use terminology and jargon that are specific to a domain. It is
impossible for them to discuss domain requirements without using this terminology.
2. Some domain knowledge is so familiar to stakeholders that they either find it difficult to
explain or they think it is so fundamental that it isn’t worth mentioning. For example, for a
librarian, it goes without saying that all acquisitions are catalogued before they are added
to the library. However, this may not be obvious to the interviewer, and so it isn’t taken into
Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 8
 Software Engineering and Testing [20CS45]
]
account in therequirements.
Effective interviewers have two characteristics:
1. They are open-minded, avoid pre-conceived ideas about the requirements, and are willing to
listen to stakeholders. If the stakeholder comes up with surprising requirements, then they
are willing to change their mind about the system.
2. They prompt the interviewee to get discussions going using a springboard question, a
requirements proposal, or by working together on a prototype system. They find it much
easier to talk in a defined context rather than in general terms

4.3.1.2 Ethnography
 Ethnography is an observational technique that can be used to understand operational processes
and help derive support requirements for these processes
 The value of ethnography is that it helps discover implicit system requirements that reflect the
actual ways that people work, rather than the formal processes defined by the organization
 Ethnography can be combined with prototyping as shown in figure 4.8

 Ethnography is particularly effective for discovering two types of requirements

1. Requirements that are derived from the way in which people actually work, rather than the
way in which process definitions say they thought to work.
2. Requirements that are derived from cooperation and awareness of other people’s activities.

4.3.2 Stories and scenarios

 They are descriptions of example interaction sessions
 Each scenario usually covers one or a small number of possible interactions
 Different forms of scenarios are developed and they provide different types of information at
different levels of detail about the system

 A scenario starts with an outline of the interaction. During the elicitation process, details are
added to create a complete description of that interaction. At its most general, a scenario may
include

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 9

 Software Engineering and Testing [20CS45]
]
1. A description of what the system and users expects when the scenario starts.
2. A description of the normal flow of events in the scenario.
3. A description of what can go wrong and how this is handled.
4. Information about other activities that might be going on at the same time.
5. A description of the system state when the scenario finishes.

4.4 Requirements specification

 Requirements specification is the process of writing down the user and system requirements in a
requirements document

 System requirements are expanded versions of the user requirements that are used by software
engineers as the starting point for the system design

 They add detail and explain how the user requirements should be provided by the system

 It is practically impossible to exclude all design information. There are several reasons for this
- You may have to design an initial architecture of the system to help structure the
requirements specification. The system requirements are organized according to the
different sub-systems that makeup the system
- In most cases, systems must interoperate with existing systems, which constrain thedesign
and impose requirements on the new system
- The use of a specific architecture to satisfy non-functional requirements may benecessary.
- The fig 4.11shows the different notations for writing system requirement.

Figure 4.11 Notations for writing system requirements

4.4.1 Natural language specification
 To minimize misunderstandings when writing natural language requirements, there are
some simple guidelines to be followed:
 Invent a standard format and ensure that all requirement definitions adhere to thatformat.
 Use language consistently to distinguish between mandatory and desirablerequirements.
Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 10
 Software Engineering and Testing [20CS45]
]
 Use text highlighting (bold, italic, or color) to pick out key parts of therequirement.
 Do not assume that readers understand technical software engineering language. It is
easy for words like ‘architecture’ and ‘module’ to be misunderstood. You should,
therefore, avoid the use of abbreviations, and acronyms.
 Whenever possible, you should try to associate a rationale with each userrequirement.
 Fig 4.12 illustrates how these guidelines may be used. It includes two requirements forthe
embedded software for the automated insulin pump.

Figure 4.12: Example requirements for the insulin pump software system
4.4.2 Structured specifications
 Structured natural language is a way of writing system requirements where the freedomof the
requirements writer is limited and all requirements are written in a standard way

 Structured language notations use templates to specify system requirements

 An example of a form-based specification, that defines how to calculate the dose of insulin to
be delivered when the blood sugar is within a safe band, as shown in fig 4.13

Figure 4.13 The structured specification of a requirement for an insulin pump

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 11

 Software Engineering and Testing [20CS45]
]
 When a standard form is used for specifying functional requirements, the following
information should be included:
 A description of the function or entity being specified.
 A description of its inputs and where these come from.
 A description of its outputs and where these go to.
 Information about the information that is needed for the computation or other entities in the
system that are used (the ‘requires’ part).
 A description of the action to be taken.
 If a functional approach is used, a pre-condition setting out what must be true before the
function is called, and a post-condition specifying what is true after the function is called.
 A description of the side effects (if any) of the operation.

Figure 4.14 The tabular specification of computation in an insulin pump

4.4.3 Use cases

 A use case identifies the actors involved in an interaction and names the type ofinteraction

 Use cases are documented using a high-level use case diagram

 The set of use cases represents all of the possible interactions that will be described in the
system requirements

 Actors in the process, who may be human or other systems, are represented as stickfigures.Each
class of interaction is represented as a named ellipse. Lines link the actors with the interaction.
Arrowheads may be added to lines to show how the interaction is initiated.

 Each use case should be documented with a textual description. These can then be linked to
other models in the UML that will develop the scenario in more detail.
 For example, a brief description of the Setup Consultation use case from fig 4.15 below
might be:

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 12

 Software Engineering and Testing [20CS45]
]

 Setup consultation allows two or more doctors, working in different offices, to view the same
record at the same time. One doctor initiates the consultation by choosing the people involved
from a drop-down menu of doctors who are online.
 The patient record is then displayed on their screens but only the initiating doctor can edit the
record. In addition, a text chat window is created to help coordinate actions. It is assumed that
a phone conference for voice communication will be separately set up.

4.4.4 The software requirements document

 The software requirements document (sometimes called the software requirements

specification or SRS) is an official statement of what the system developers should
implement

 It may include both the user requirements for a system and a detailed specification of the
system requirements

 The requirements document has a diverse set of users, ranging from the senior management
of the organization that is paying for the system to the engineers responsible for developing
the software

 The users of requirements document is as shown below in fig 4.16.

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 13

 Software Engineering and Testing [20CS45]
]

 Figure 4.17 shows one possible organization for a requirements document that is basedon
an IEEE standard for requirements documents

Fig 4.17: The Structure of a Requirements document

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 14

 Software Engineering and Testing [20CS45]
]
4.5 Requirements validation

 Requirements validation is the process of checking that requirements actually define thesystem
that the customer really wants
 It overlaps with analysis as it is concerned with finding problems with the requirements

 During the requirements validation process, different types of checks should be carriedout on
the requirements in the requirements document.

 These checks include:

1. Validity Checks: A user may think that a system is needed to perform certain functions.
2. Consistency Checks: Requirements in the document should not conflict. That is, there
should not be contradictory constraints or different descriptions of the same system
function.
3. Completeness Checks: The requirements document should include requirements that
define all functions and the constraints intended by the system user.
4. Realism Checks: Using knowledge of existing technology, the requirements should be
checked to ensure that they can actually be implemented.
5. Verifiability: To reduce the potential for dispute between customer and contractor, system
requirements should always be written so that they are verifiable. This means that you
should be able to write a set of tests that can demonstrate that the delivered system meets
each specified requirement.
 There are a number of requirements validation techniques that can be used individually or
in conjunction with one another:
1. Requirements Reviews: The requirements are analyzed systematically by a team of
reviewers who check for errors and inconsistencies.
2. Prototyping: In this approach to validation, an executable model of the system in question
is demonstrated to end-users and customers. They can experiment with this model to see if it
meets their real needs.
3. Test-Case Generation: Requirements should be testable. If the tests for the requirements
are devised as part of the validation process, this often reveals requirements problems.

4.6 Requirements change

 The requirements for large software systems are always changing.
 Once a system has been installed and is regularly used, new requirements inevitablyemerge.
 There are several reasons why change is inevitable:

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 15

 Software Engineering and Testing [20CS45]
]
1. The business and technical environment of the system always changes after installation.
New hardware may be introduced, it may be necessary to interface the system with other
systems, business priorities may change
2. The people who pay for a system and the users of that system are rarely the same people.
System customers impose requirements because of organizational and budgetary
constraints. These may conflict with end-user requirements and, after delivery, new
features may have to be added for user support if the system is to meet its goals.
3. Large systems usually have a diverse user community, with many users having
different requirements and priorities that may be conflicting or contradictory.

4.6.1 Requirements management planning

 Planning is an essential first stage in the requirements management process. The

planningstage establishes the level of requirements management detail that is required

 During the requirements management stage, a decision is to be taken on:

 Requirements Identification: Each requirement must be uniquely identified so that it can

be cross- referenced with other requirements & used in traceability assessments.

 A Change Management Process: This is the set of activities that assess the impact and
cost of changes.

 Traceability Policies: These policies define the relationships between each requirement
and between the requirements and the system design that should be recorded. The
traceability policy should also define how these records should bemaintained.

 Tool Support: Requirements management involves the processing of large amounts of

information about the requirements. Tools that may be used range from specialist
requirements managementsystems to spreadsheets and simple database systems.
Tool supports might be needed for:
 Requirements Storage: The requirements should be maintained in a secure, managed data
store that is accessible to everyone involved in the requirements engineering process.

 Change Management: The process of change management is simplified if active tool

support is available as shown in fig 4.19.
 Traceability Management: Tool support for traceability allows related requirements to be
discovered. Some tools are available which use natural language processing techniques to
help discover possible relationships between requirements.

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 16

 Software Engineering and Testing [20CS45]
]

4.6.2 Requirements change management

 There are three principal stages to a change management process:

a. Problem Analysis and Change Specification
- The process starts with an identified requirements problem or, sometimes,
with a specific change proposal.

- 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.
b. Change Analysis and Costing
- The effect of the proposed change is assessed using traceability information
and general knowledge of the system requirements.
c. Change Implementation
- The requirements document and, where necessary, the system design and
implementation, are modified.
- Requirements document will have to be organized so that changes can be
made to it without extensive rewriting or reorganization.

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 17

 Software Engineering and Testing [20CS45]
]
CHAPTER 5
SYSTEM MODELING

A Model is a simplified representation of either reality or vision. Since “a picture is worth a

thousand words,” most models use pictures to represent the reality or vision. Usually, the system
model becomes the blueprint for designing and constructing an improved system.

A Model is a simplified representation of a complex system

System Modeling

 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 has generally come to mean representing the system using some kind of
graphical notation, which is now almost always based on notations in the 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 engineers
implementing the system and after implementation to document the system‟s structure and
operation.

 Model-driven analysis is a problem-solving approach that emphasizes the drawing of graphical

or pictorial system models to document and validate both existing and/or proposed system.
 Benefits of System Modeling

1. Ease project management tasks.

2. Can provide complete views of a system, as well as detailed views of subsystems.
3. Clarify structures and relationships.
4. Offer a communication framework for ideas within and between teams.
5. Can generate new ideas and possibilities.
6. Allow quality assurance and testing scenarios to be generated.
7. Are platform independent.

 You may develop models of both existing system and the system to be developed.
1 Models of the existing system are used during requirements engineering. They help
classify what the existing system does and can be used as a basis for discussing its
strengths and weaknesses. These then lead to requirement for the new system.

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 18

 Software Engineering and Testing [20CS45]
]
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. In a
Model-driven Engineering process, it is possible to generate a complete or partial
system implementation from the system model.

 Types of Models: Different models may represent a system from different perspectives. For
example:
1 An external perspective model representing the context or environment of the system

2 An interaction perspective Model where the interactions between a system and its
environmentor between the components of a system is represented.

3 A structural perspective model showing the organization of a system or the structure of the
datathat is processed by the system.

4 A behavioral perspective model where the model shows the dynamic behavior of the system
andhow it responds to events.
How to represent a Model

 System Models are usually represented graphically and so are the software system Models.
Graphical models are very popular because they are easy to understand and construct.

 The Unified Modeling Language (UML) provides a standard for the artifacts of development
(semantic models, syntactic notation, and diagrams

 UML is a general-purpose, developmental, modeling language in the field of software

engineering,that is intended to provide a standard way to visualize the design of a system.

 The creation of UML was originally developed by Grady Booch, Ivar Jacobson and James
Rumbaugh at Rational Software in 1996.

 In 2005 UML was also published by the International Organization for Standardization (ISO)
as an approved ISO standard.

 The UML standard is being periodically revised

 The UML has many diagram types and so supports the creation of many different types of
systemmodel.
1. Activity Diagram, which show the activities involved in a process or in data processing.

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 19

 Software Engineering and Testing [20CS45]
]
2. Use case Diagram, which show the interaction between a system and its environment.
3. Sequence Diagram, which shows interaction between actors and the System and between system
components.
4. Class Diagram, which show the object classes in the system and the association between these
classes.
5. State Diagram, which show how the system reacts to internal and external events.

5.1 Context Models

 At an early stage in the specification of a system, it is necessary to decide on the system
boundaries.

 This involves working with system stakeholders to decide what functionality should be
included in the system and what is provided by the system’s environment.

 A decision might be taken about an automated support for some business processes should
be implemented but others should be manual processes or supported by different systems.

 Possible overlaps must also be noted in functionality with existing systems and decide where
new functionality should be implemented.

 These decisions should be made early in the process to limit the system costs and the time
needed for understanding the system requirements and design.

 Fig 5.1 is a simple context model that shows the patient information system and the other
systems in its environment. It is seen that the Mentcare System is connected to an
appointments system and a more general patient record system with which it shares data.

 The system is also connected to systems for management reporting and hospital bed allocation
and a statistics system that collects information for research. finally, it makes use of a
prescription system to generate prescriptions for patients Medication.

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 20

 Software Engineering and Testing [20CS45]
]
 Simple context models are used along with other models, such as business process models
 UML activity diagrams may be used to show the business processes in which systems are
used
 Figure 5.2 is a UML activity diagram that shows where the Mentcare system is used in an
important mental health care process—involuntary detention.

 Activity diagrams are intended to show the activities that make up a system process and
the flow of control from one activity to another.
 The start of a process is indicated by a filled circle; the end by a filled circle inside
another circle.
 Rectangles with round corners represent activities, that is, the specific sub-processes
that must be carried out.
 Objects can be included in activity charts.

Fig 5.2: Process model of involuntary detention

 In fig 5.2, it can be seen that guards showing the flows for patients who are dangerous and
not dangerous to society.

 Patients who are dangerous to society must be detained in a secure facility. However,
patients who are suicidal and so are a danger to themselves may be detained in an
appropriate ward in a hospital.

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 21

 Software Engineering and Testing [20CS45]
]
5.4 Behavioral models
 Behavioral models are models of the dynamic behavior of the system as it is executing.

 They show what happens or what is supposed to happen when a system responds to astimulus
from its environment.
 There are 2 types:

 Data: Some data arrives that has to be processed by the system

 Events: Some event happens that triggers system processing. Events may have associated
data but this is not always the case.

5.4.1 Data-driven modeling

 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-flow models are useful because tracking and documenting how the data associated
with a particular process moves through the system helps analysts and designers understand
what is going on.

 Data-flow diagrams (DFD‟s) are simple and intuitive and it is usually possible to explain
them to potential system users who can then participate in validating the model.

 Fig 5.14 shows the activity model of the insulin pump’s operation.

Figure 5.14 An activity model of the insulin pump’s operation

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 22

 Software Engineering and Testing [20CS45]
]
 Fig 5.15 illustrates the use of sequence model of the processing of an order and
sending it to a supplier.

 Sequence models highlight objects in a system, whereas data-flow diagrams highlight the
functions.

2.4.1 Event driven modeling

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 23

 Software Engineering and Testing [20CS45]

 Event-driven modeling 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.

 For example, a system controlling a valve may move from a state valve open to a state valve
closed when an operator command (the stimulus) is received.

 The UML supports event-based modeling using state diagrams, which were based on
Statecharts.

 State diagrams show system states and events that cause transitions from one state toanother.

 They do not show the flow of data within the system but may include additionalinformation
on the computations carried out in each state.
 The sequence of actions in using the microwave is:
 Select the power level (either half power or full power).
 Input the cooking time using a numeric keypad.
 Press Start and the food is cooked for the given time.
 From fig 5.16, it can be seen that the system starts in a waiting state and respondsinitially to
either the full-power or the half-power button.

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 24

 Software Engineering and Testing [20CS45]

 Users can change their mind after selecting one of these and press the other button.

 The time is set and, if the door is closed, the Start button is enabled. Pushing this button
starts the oven operation and cooking takes place for the specified time.

 This is the end of the cooking cycle and the system returns to the waiting state.

 Figure 5.18, shows a tabular description of each state and how the stimuli that forcestate
transitions are generated.

 The fig 5.17 below shows the microwave oven operation

 The Operation state includes a number of substates. It shows that operation starts with a
status check and that if any problems are discovered an alarm is indicated and operation is
disabled. Cooking involves running the microwave generator for the specified time; on
completion, a buzzer is sounded. If the door is opened during operation, the system moves to
the disabled state, as shown in Figure.

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 25

 Software Engineering and Testing [20CS45]

Prof. Anusha K S, Dept. of CS&E, VVCE, Mysuru. Page 26