Week4-5: Unit Learning Outcomes(ULO): At the end of the unit, you are expected to

a. Understand how to extract software and user requirements from relevant sources
using various method requirement discovery.
b. Discuss the processes involved in discovering and documenting these
requirements.
a. Big Picture in Focus: ULOa Understand how to extract
software and user requirements from relevant sources
using various method requirement discovery.

Metalanguage
• CIM-Computation Independent Model
• PIM-platform independent model
• PSM- Platform Specific Model
• UML- Unified Modeling Language
• MDA - Multiple platform-specific models
• OCL -Object Constraint Language

Essential Knowledge

In today’s age and time, software has been an important part in the economies of all
developed nations. It is a known fact that most systems are software-controlled hence,
there is an increasing demand to develop a good, maintainable, dependable and usable
software that could deliver the functionality and performance required by the users.

Essentially, in developing a software, one must familiarize and understand the

requirements needs to be fulfilled to create a functional software that meets user
specifications. In this module, students will learn how to skillfully elicit software
requirements from relevant sources using various methods of requirements discovery,
assess the requirements and prioritize it based on the level of significance, and assure
the requirements and requirement specification’s quality and requirements.
Introduction Requirements, by definition, are the descriptions on how the system will
function in terms of the services it provides as well as the constraints on its operation. As
these requirements will be used to develop a software that meets the needs of the users,
it is very critical to understand what are the requirements needs to be reflected for
systems that functions for a certain purpose. The process of finding out, analyzing and
establishing the services and constraints that the user would like to see in a developed
system is the main focus of requirements engineering. To know more about requirements
and requirements engineering, you will find the details as you go on to this module.

There are two (2) types of requirements:

1. User Requirements
• Defined as statements in natural language plus diagrams of the services
the system provides and its operational constraints. This requirement is
written for customers.
• Usually the readers of user requirements are client managers, system end-
users, client engineers, contractor managers and system architectures.
They are not usually concerned with how the system will be implemented.

Example:

The Mental Health Care Patient Management System (MHC-PMS) shall

generate monthly management reports showing the cost of drugs
prescribed by each clinic during that month.

2. System Requirements
• Defined as a more detailed descriptions of the software system’s functions,
services, and operational constraints. The system requirements document
is a structured document which should define exactly what must be
implemented since these system requirements may be part of the contract
between the system buyer and the software developer.
• The readers of the system requirements are system end-users, client
engineers, system architects and software developers. Since they are
involved in the implementation, they have to know the details on what the
system will do. They are also more concerned on how these requirements
will support the business.

Example:

1.1 On the last working day of each month, a summary of the drugs
prescribed, their cost and the prescribing clinics shall be generated.
1.2 The system shall automatically generate the report for printing after
17.30 on the last working day of the month.
1.3 A report shall be created for each clinic and shall list the individual drug
names, the total number of prescriptions, the number of doses
prescribed and the total cost of the prescribed drugs.

1.4 If drugs are available in different dose units (e.g. 10mg, 20mg, etc.)
separate reports shall be created for each dose unit. 1.5 Access to all
cost reports shall be restricted to authorized users listed on a
management access control list.
Figure 1.0 Readers of different types of requirements specification

Software system requirements are often classified as either functional or non-

functional requirement:

• Functional requirement

o These are requirements which refers to statements of services the system

should provide, how the system should react to particular inputs, and how
the system should behave in particular situations. It may also explicitly state
what the system should not do.

o When expressed as user requirement, it is described in an abstract way that

can be understood by users however in a more specific functional system
requirement, it describes the system functions, its inputs and outputs,
exceptions, etc., in detail.

Example of Functional Requirements:

In MHC-PMS system which is used to maintain information about patients

receiving treatment for mental health problems, the following are the
sample functional requirements:

1. A user shall be able to search the appointments lists for all clinics.
2. The system shall generate each day, for each clinic, a list of patients
who are expected to attend appointments that day.
3. Each staff member using the system shall be uniquely identified by his
or her eight-digit employee number.
Figure 1.0 Types of nonfunctional requirement

• Non-functional requirements
o These are constraints on the services or functions offered by the system.
These include timing constraints, development process constraints and
constraints imposed by standards.
o These are requirements that are not directly concerned with the specific
services delivered by the system to its users.
o Often applied as a whole instead of individual system features or services.
It may affect the overall architecture of a system rather than the individual
components.
o A single non-functional requirement may generate a number of related
functional requirements that may define a required new system service.
o As shown in Figure 1 (Sommerville,2011), the non-functional requirements
have several types. These requirements may come from either of these
three, namely, product requirements, organizational requirements and
external requirements:

Non-functional classifications

▪ Product requirements
o Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability,
etc.
▪ Organisational requirements
o Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
▪ External requirements
 o Requirements which arise from factors which are external to
the system and its development process e.g. interoperability
requirements, legislative requirements, etc.

Examples of non-functional requirements in the MHC-PMS

▪ Product requirement
The MHC-PMS shall be available to all clinics during normal
working hours (Mon–Fri, 0830–17.30). Downtime within normal
working hours shall not exceed five seconds in any one day.
▪ Organizational requirement
Users of the MHC-PMS system shall authenticate themselves using
their health authority identity card.
▪ External requirement
The system shall implement patient privacy provisions as set out in
HStan-03-2006-priv.
▪ Goals and requirements
o Non-functional requirements may be very difficult to state
precisely and imprecise requirements may be difficult to
verify.
o Goal
o A general intention of the user such as ease of use.
o Verifiable non-functional requirement
o A statement using some measure that can be
objectively tested.
o Goals are helpful to developers as they convey the
intentions of the system users.
▪ Usability requirements
o The system should be easy to use by medical staff and should
be organized in such a way that user errors are minimized.
(Goal)
o Medical staff shall be able to use all the system functions after
four hours of training. After this training, the average number of
errors made by experienced users shall not exceed two per
hour of system use. (Testable non-functional requirement)

Metrics for specifying nonfunctional requirements

▪ Domain requirements
o The system’s operational domain imposes requirements on the
system.
o For example, a train control system has to take into
account the braking characteristics in different weather
conditions.
o Domain requirements be new functional requirements,
constraints on existing requirements or define specific
computations.
o If domain requirements are not satisfied, the system may be
unworkable.

Train protection system

o This is a domain requirement for a train protection system:

o The deceleration of the train shall be computed as:
▪ Dtrain = Dcontrol + Dgradient
▪ where Dgradient is 9.81ms2 * compensated
gradient/alpha and where the values of 9.81ms2 /alpha
are known for different types of train.
o It is difficult for a non-specialist to understand the implications of
this and how it interacts with other requirements.

Domain requirements problems

o Understand ability
▪ Requirements are expressed in the language of the
application domain;
▪ This is often not understood by software engineers
developing the system.
o Implicitness
 ▪ Domain specialists understand the area so well that they
do not think of making the domain requirements explicit

The software requirements document

 The software requirements document is the official statement of what is required
of the system developers.
 Should include both a definition of user requirements and a specification of the
system requirements.
 It is NOT a design document. As far as possible, it should set of WHAT the
system should do rather than HOW it should do it.

Agile methods and requirements

 Many agile methods argue that producing a requirements document is a waste of
time as requirements change so quickly.
 The document is therefore always out of date.
 Methods such as XP use incremental requirements engineering and express
requirements as ‘user stories’ (discussed in Chapter 3).
 This is practical for business systems but problematic for systems that require a
lot of pre-delivery analysis (e.g. critical systems) or systems developed by
several teams
Requirements document

Figure 2.0 Users of a requirements document

Requirements document variability

▪ Information in requirements document depends on type of system and the

approach to development used.
 ▪ Systems developed incrementally will, typically, have less detail in the
requirements document.
▪ Requirements documents standards have been designed e.g. IEEE standard.
These are mostly applicable to the requirements for large systems engineering
projects.

The structure of a requirements document

Requirements specification

▪ The process of writing don the user and system requirements in a requirements
document.
▪ User requirements have to be understandable by end-users and customers who
do not have a technical background.
▪ System requirements are more detailed requirements and may include more
technical information.
▪ The requirements may be part of a contract for the system development
▪ It is therefore important that these are as complete as possible
Ways of writing a system requirements specification

Requirements and design

▪ In principle, requirements should state what the system should do and the design
should describe how it does this.
▪ In practice, requirements and design are inseparable
o A system architecture may be designed to structure the requirements;
o The system may inter-operate with other systems that generate design
requirements;
o The use of a specific architecture to satisfy non-functional requirements
may be a domain requirement.
o This may be the consequence of a regulatory requirement.

Natural language specification

▪ Requirements are written as natural language sentences supplemented by

diagrams and tables.
▪ Used for writing requirements because it is expressive, intuitive and universal.
This means that the requirements can be understood by users and customers.

Guidelines for writing requirements

▪ Invent a standard format and use it for all requirements.

▪ Use language in a consistent way. Use shall for mandatory requirements, should
for desirable requirements.
▪ Use text highlighting to identify key parts of the requirement.
 ▪ Avoid the use of computer jargon.
▪ Include an explanation (rationale) of why a requirement is necessary.

Problems with natural language

▪ Lack of clarity
o Precision is difficult without making the document difficult to read.
▪ Requirements confusion
o Functional and non-functional requirements tend to be mixed-up.
▪ Requirements amalgamation
o Several different requirements may be expressed together.

Example requirements for the insulin pump software system

Structured specifications

▪ An approach to writing requirements where the freedom of the requirements

writer is limited and requirements are written in a standard way.
▪ This works well for some types of requirements e.g. requirements for embedded
control system but is sometimes too rigid for writing business system
requirements.

Form-based specifications

▪ Definition of the function or entity.

▪ Description of inputs and where they come from.
▪ Description of outputs and where they go to.
▪ Information about the information needed for the computation and other entities
used.
▪ Description of the action to be taken.
▪ Pre and post conditions (if appropriate).
▪ The side effects (if any) of the function.
Tabular specification

 Used to supplement natural language.

 Particularly useful when you have to define a number of possible alternative
courses of action.
 For example, the insulin pump systems bases its computations on the rate of
change of blood sugar level and the tabular specification explains how to
calculate the insulin requirement for different scenarios

Tabular specification of computation for an insulin pump

Requirements engineering processes

▪ The processes used for RE vary widely depending on the application domain, the
people involved and the organisation developing the requirements.
▪ However, there are a number of generic activities common to all processes
o Requirements elicitation;
o Requirements analysis;
o Requirements validation;
o Requirements management.
▪ In practice, RE is an iterative activity in which these processes are interleaved.

Figure 3.0 A spiral view of the requirements engineering process

Requirements elicitation and analysis

▪ Sometimes called requirements elicitation or requirements discovery.

▪ Involves technical staff working with customers to find out about the application
domain, the services that the system should provide and the system’s
operational constraints.
▪ May involve end-users, managers, engineers involved in maintenance, domain
experts, trade unions, etc. These are called stakeholders.
Problems of requirements analysis

▪ Stakeholders don’t know what they really want.

▪ Stakeholders express requirements in their own terms.
▪ Different stakeholders may have conflicting requirements.
▪ Organisational and political factors may influence the system requirements.
▪ The requirements change during the analysis process. New stakeholders may
emerge and the business environment may change.

Requirements elicitation and analysis

• Software engineers work with a range of system stakeholders to find out about
the application domain, the services that the system should provide, the required
system performance, hardware constraints, other systems, etc.
• Stages include:
o Requirements discovery,
o Requirements classification and organization,
o Requirements prioritization and negotiation,
o Requirements specification.

Requirements elicitation and analysis

• Sometimes called requirements elicitation or requirements discovery.

• Involves technical staff working with customers to find out about the application
domain, the services that the system should provide and the system’s
operational constraints.
• May involve end-users, managers, engineers involved in maintenance, domain
experts, trade unions, etc. These are called stakeholders

Problems of requirements analysis

• Stakeholders don’t know what they really want.

• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the system requirements.
• The requirements change during the analysis process. New stakeholders may
emerge and the business environment may change.
Figure 4.0 The requirements elicitation and analysis process

Process activities

• Requirements discovery
o Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.
• Requirements classification and organisation
o Groups related requirements and organises them into coherent clusters.
• Prioritisation and negotiation
o Prioritising requirements and resolving requirements conflicts.
• Requirements specification
o Requirements are documented and input into the next round of the spiral.

Problems of requirements elicitation

• Stakeholders don’t know what they really want.

• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the system requirements.
• The requirements change during the analysis process. New stakeholders may
emerge and the business environment change.

Key points

• The software requirements document is an agreed statement of the system

requirements. It should be organized so that both system customers and
software developers can use it.
• The requirements engineering process is an iterative process including
requirements elicitation, specification and validation.
• Requirements elicitation and analysis is an iterative process that can be
represented as a spiral of activities – requirements discovery, requirements
 classification and organization, requirements negotiation and requirements
documentation.

Requirements discovery

• The process of gathering information about the required and existing systems and
distilling the user and system requirements from this information.
• Interaction is with system stakeholders from managers to external regulators.
• Systems normally have a range of stakeholders.

Stakeholders in the MHC-PMS

• Patients whose information is recorded in the system.

• Doctors who are responsible for assessing and treating patients.
• Nurses who coordinate the consultations with doctors and administer some
treatments.
• Medical receptionists who manage patients’ appointments.
• IT staff who are responsible for installing and maintaining the system.
• A medical ethics manager who must ensure that the system meets current
ethical guidelines for patient care.
• Health care managers who obtain management information from the system.
• Medical records staff who are responsible for ensuring that system information
can be maintained and preserved, and that record keeping procedures have
been properly implemented.

Interviewing

• Formal or informal interviews with stakeholders are part of most RE processes.

• Types of interview
o Closed interviews based on pre-determined list of questions
o Open interviews where various issues are explored with stakeholders.
• Effective interviewing
o Be open-minded, avoid pre-conceived ideas about the requirements and
are willing to listen to stakeholders.
o Prompt the interviewee to get discussions going using a springboard
question, a requirements proposal, or by working together on a prototype
system.

Interviews in practice

• Normally a mix of closed and open-ended interviewing.

 • Interviews are good for getting an overall understanding of what stakeholders do
and how they might interact with the system.
• Interviews are not good for understanding domain requirements
o Requirements engineers cannot understand specific domain terminology;
o Some domain knowledge is so familiar that people find it hard to articulate
or think that it isn’t worth articulating.

Scenarios

• Scenarios are real-life examples of how a system can be used.

• They should include
o A description of the starting situation;
o A description of the normal flow of events;
o A description of what can go wrong;
o Information about other concurrent activities;
o A description of the state when the scenario finishes.

Scenario for collecting medical history in MHC-PMS

Use
cases

• Use-cases are a scenario based technique in the UML which identify the actors in
an interaction and which describe the interaction itself.
 • A set of use cases should describe all possible interactions with the system.
• High-level graphical model supplemented by more detailed tabular description
(see Chapter 5).
• Sequence diagrams may be used to add detail to use-cases by showing the
sequence of event processing in the system.

Figure 5.0 Use cases for the MHC-PMS

Ethnography

• A social scientist spends a considerable time observing and analysing how

people actually work.
• People do not have to explain or articulate their work.
• Social and organisational factors of importance may be observed.
• Ethnographic studies have shown that work is usually richer and more complex
than suggested by simple system models.

Scope of ethnography

• Requirements that are derived from the way that people actually work rather than
the way I which process definitions suggest that they ought to work.
• Requirements that are derived from cooperation and awareness of other people’s
activities.
o Awareness of what other people are doing leads to changes in the ways in
which we do things.
• Ethnography is effective for understanding existing processes but cannot identify
new features that should be added to a system.

Focused ethnography
 • Developed in a project studying the air traffic control process
• Combines ethnography with prototyping
• Prototype development results in unanswered questions which focus the
ethnographic analysis.
• The problem with ethnography is that it studies existing practices which may
have some historical basis which is no longer relevant.

Figure 6.0 Ethnography and prototyping for requirements analysis

Requirements validation

• Concerned with demonstrating that the requirements define the system that the
customer really wants.
• Requirements error costs are high so validation is very important
o Fixing a requirements error after delivery may cost up to 100 times the
cost of fixing an implementation error.

Requirements checking

• Validity. Does the system provide the functions which best support the
customer’s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the customer included?
• Realism. Can the requirements be implemented given available budget and
technology?
• Verifiability. Can the requirements be checked?

Requirements validation techniques

• Requirements reviews
o Systematic manual analysis of the requirements.
• Prototyping
o Using an executable model of the system to check requirements. Covered
in Chapter 2.
• Test-case generation
o Developing tests for requirements to check testability.

Requirements reviews
 • Regular reviews should be held while the requirements definition is being
formulated.
• Both client and contractor staff should be involved in reviews.
• Reviews may be formal (with completed documents) or informal. Good
communications between developers, customers and users can resolve
problems at an early stage.

Review checks

• Verifiability
o Is the requirement realistically testable?
• Comprehensibility
o Is the requirement properly understood?
• Traceability
o Is the origin of the requirement clearly stated?
• Adaptability
o Can the requirement be changed without a large impact on other
requirements?

Requirements management

• Requirements management is the process of managing changing requirements

during the requirements engineering process and system development.
• New requirements emerge as a system is being developed and after it has gone
into use.
• You need to keep track of individual requirements and maintain links between
dependent requirements so that you can assess the impact of requirements
changes. You need to establish a formal process for making change proposals
and linking these to system requirements.

Changing requirements

• The business and technical environment of the system always changes after
installation.
o New hardware may be introduced, it may be necessary to interface the
system with other systems, business priorities may change (with
consequent changes in the system support required), and new legislation
and regulations may be introduced that the system must necessarily abide
by.
• The people who pay for a system and the users of that system are rarely the same
people.
o 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.

Changing requirements
• Large systems usually have a diverse user community, with many users having
different requirements and priorities that may be conflicting or contradictory.
o The final system requirements are inevitably a compromise between them
and, with experience, it is often discovered that the balance of support
given to different users has to be changed.

Figure 7.0 Requirements evolution

Requirements management planning

• Establishes the level of requirements management detail that is required.

• Requirements management decisions:
o Requirements identification Each requirement must be uniquely identified
so that it can be cross-referenced with other requirements.
o A change management process This is the set of activities that assess the
impact and cost of changes. I discuss this process in more detail in the
following section.
o Traceability policies These policies define the relationships between each
requirement and between the requirements and the system design that
should be recorded.
o Tool support Tools that may be used range from specialist requirements
management systems to spreadsheets and simple database systems.

Requirements change management

• Deciding if a requirements change should be accepted

o 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.
o Change analysis and costing
 ▪
The effect of the proposed change is assessed using traceability
information and general knowledge of the system requirements.
Once this analysis is completed, a decision is made whether or not
to proceed with the requirements change.
o Change implementation
▪ The requirements document and, where necessary, the system
design and implementation, are modified. Ideally, the document
should be organized so that changes can be easily implemented.

Figure 8.0 Requirements change management

Key points

• You can use a range of techniques for requirements elicitation including

interviews, scenarios, use-cases and ethnography.
• Requirements validation is the process of checking the requirements for validity,
consistency, completeness, realism and verifiability.
• Business, organizational and technical changes inevitably lead to changes to the
requirements for a software system. Requirements management is the process
of managing and controlling these changes.

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 now come to mean representing a system using some kind
of graphical notation, which is now almost always based on notations in the
Unified Modeling Language (UML).
• System modelling helps the analyst to understand the functionality of the system
and models are used to communicate with customers.

Existing and planned system models

• 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.
• 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.

System 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.

UML diagram types

• 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.

Use of graphical models

• As a means of facilitating discussion about an existing or proposed system

o Incomplete and incorrect models are OK as their role is to support
discussion.
• As a way of documenting an existing system
o Models should be an accurate representation of the system but need not
be complete.
• As a detailed system description that can be used to generate a system
implementation
o Models have to be both correct and complete.

Context models

• Context models are used to illustrate the operational context of a system - they
show what lies outside the system boundaries.
• Social and organisational concerns may affect the decision on where to position
system boundaries.
• Architectural models show the system and its relationship with other systems.
System boundaries

• System boundaries are established to define what is inside and what is outside
the system.
o 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
o There may be pressures to develop system boundaries that increase /
decrease the influence or workload of different parts of an organization.

Figure 9.0 The context of the MHC-PMS

Process perspective

• 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.
Figure 10 Process model of involuntary detention

Interaction models

• 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 case diagrams and sequence diagrams may be used for interaction modelling.

Use case modeling

• 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.
• Represented diagrammatically to provide an overview of the use case and in a
more detailed textual form.

Figure 11 Transfer-data use case

 • A use case in the MHC-PMS

Tabular description of the ‘Transfer data’ use-case

Figure 12 Use cases in the MHC-PMS involving the role ‘Medical Receptionist’
Sequence diagrams

• Sequence diagrams are part of the UML and 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.
Figure 13 Sequence diagram for View patient information

Figure 14 Sequence diagram for Transfer Data

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.
Class diagrams

• 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.

Figure 15 UML classes and association

Figure 16 Classes and associations in the MHC-PMS

Figure 17 The Consultation class

Key points

• A model is an abstract view of a system that ignores system details.

Complementary system models can be developed to show the system’s context,
interactions, structure and behavior.
• Context models show how a system that is being modeled is positioned in an
environment with other systems and processes.
• Use case diagrams and sequence diagrams are used to describe the interactions
between users and systems in the system being designed. Use cases describe
interactions between a system and external actors; sequence diagrams add
more information to these by showing interactions between system objects.
• Structural models show the organization and architecture of a system. Class
diagrams are used to define the static structure of classes in a system and their
associations.

Generalization

• Generalization is an everyday technique that we use to manage complexity.

• Rather than learn the detailed characteristics of every entity that we experience,
we place these entities in more general classes (animals, cars, houses, etc.) and
learn the characteristics of these classes.
• This allows us to infer that different members of these classes have some
common characteristics e.g. squirrels and rats are rodents.
• In modeling systems, it is often useful to examine the classes in a system to see
if there is scope for generalization. If changes are proposed, then you do not
have to look at all classes in the system to see if they are affected by the change.
• 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 super classes. These lower-level classes then add more specific attributes
and operations.

Figure 18 A generalization hierarchy

Figure 19 A generalization hierarchy with added detail

Object class aggregation models

• 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.
Figure 20 The aggregation association

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.
• You can think of these stimuli as being of two 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, although this is not always the case.

Data-driven modeling

• 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.

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

Figure 22 Order processing

Event-driven modeling

• 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 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.

State machine models

• These model the behaviour of the system in response to external and internal
events.
• They show the system’s responses to stimuli so are often used for modelling
real-time systems.
• State machine models show system states as nodes and events as arcs between
these nodes. When an event occurs, the system moves from one state to
another.
• Statecharts are an integral part of the UML and are used to represent state
machine models.
Figure 23 State diagram of a microwave oven

States and stimuli for the microwave oven (a)

States and stimuli for the microwave oven (b)

Figure 24 Microwave oven operation

Model-driven engineering
 • Model-driven engineering (MDE) is an approach to software development where
models rather than programs are the principal outputs of the development
process.
• The programs that execute on a hardware/software platform are then generated
automatically from the models.
• Proponents of MDE argue that this raises the level of abstraction in software
engineering so that engineers no longer have to be concerned with programming
language details or the specifics of execution platforms.

Usage of model-driven engineering

• Model-driven engineering is still at an early stage of development, and it is

unclear whether or not it will have a significant effect on software engineering
practice.
• Pros
o Allows systems to be considered at higher levels of abstraction
o Generating code automatically means that it is cheaper to adapt systems
to new platforms.
• Cons
o Models for abstraction and not necessarily right for implementation.
o Savings from generating code may be outweighed by the costs of
developing translators for new platforms.

Model driven architecture

• Model-driven architecture (MDA) was the precursor of more general model-

driven engineering
• MDA is a model-focused approach to software design and implementation that
uses a subset of UML models to describe a system.
• Models at different levels of abstraction are created. From a high-level, platform
independent model, it is possible, in principle, to generate a working program
without manual intervention.

Types of model
• A computation independent model (CIM)
o These model the important domain abstractions used in a system. CIMs
are sometimes called domain models.
• A platform independent model (PIM)
o These model the operation of the system without reference to its
implementation. The PIM is usually described using UML models that
show the static system structure and how it responds to external and
internal events.
• Platform specific models (PSM)
 o These are transformations of the platform-independent model with a
separate PSM for each application platform. In principle, there may be
layers of PSM, with each layer adding some platform-specific detail.

Figure 25 MDA transformations

Figure 26 Multiple platform-specific models

Agile methods and MDA

• The developers of MDA claim that it is intended to support an iterative approach

to development and so can be used within agile methods.
• The notion of extensive up-front modeling contradicts the fundamental ideas in
the agile manifesto and I suspect that few agile developers feel comfortable with
model-driven engineering.
• If transformations can be completely automated and a complete program
generated from a PIM, then, in principle, MDA could be used in an agile
development process as no separate coding would be required.

Executable UML

• The fundamental notion behind model-driven engineering is that completely

automated transformation of models to code should be possible.
• This is possible using a subset of UML 2, called Executable UML or xUML.
Features of executable UML

• To create an executable subset of UML, the number of model types has

therefore been dramatically reduced to these 3 key types:
o Domain models that identify the principal concerns in a system. They are
defined using UML class diagrams and include objects, attributes and
associations.
o Class models in which classes are defined, along with their attributes and
operations.
o State models in which a state diagram is associated with each class and is
used to describe the life cycle of the class.
• The dynamic behavior of the system may be specified declaratively using the
object constraint language (OCL), or may be expressed using UML’s action
language

Key points

• Behavioral models are used to describe the dynamic behavior of an executing

system. This behavior can be modeled from the perspective of the data
processed by the system, or by the events that stimulate responses from a
system.
• Activity diagrams may be used to model the processing of data, where each
activity represents one process step.
• State diagrams are used to model a system’s behavior in response to internal or
external events.
• Model-driven engineering is an approach to software development in which a
system is represented as a set of models that can be automatically transformed
to executable code.

Self Help: You can also refer to the sources below to help you further
understand the lesson:

Sommerville, I. (2016). Software Engineering. 10th Ed. Singapore: Pearson Education

South Asia Pte Ltd.

Irlbeck, M., Peled, D., & Pretschner, A. (Eds.). (2015). Dependable software systems
engineering. Retrieved from https://ebookcentral.proquest.com

Stephens, R. (2015). Beginning software engineering. Retrieved from

https://ebookcentral.proquest.com

Waern, Y. Cooperative Process Management., (2014) Retrieved from

http://site.ebrary.com/lib/uniofmindanao/docDetail.action?docID=10056166
 •

b. Big Picture in Focus: ULOb Discuss the processes involved

in discovering and documenting these requirements

Metalanguage

• PRS-Patient Record System

• OOP-Object Oriented Programming
• DFD-Data Flow Diagram
• MDE-Model Driven Engineering
• MDA-Model Driven Architecture
• CIM-Computation Independent Model
• PIM-platform independent model
• PSM- Platform Specific Model
• UML- Unified Modeling Language

Essential Knowledge

Software architecture

Architectural design is concerned with understanding how a system should be

organized and designing the overall structure of that system. In the model of the
software development process and architectural design is the first stage in the software
design process.

It is the critical link between design and requirements engineering, as it identifies the
main structural components in a system and the relationships between them. The
output of the architectural design process is an architectural model that describes how
the system is organized as a set of communicating components.

• The design process for identifying the sub-systems making up a system and the
framework for sub-system control and communication is architectural design.
• The output of this design process is a description of the software architecture.
Architectural design

• An early stage of the system design process.

• Represents the link between specification and design processes.
• Often carried out in parallel with some specification activities.
• It involves identifying major system components and their communications.

Figure 1.0 The architecture of a packing robot control system

Architectural abstraction

• Architecture in the small is concerned with the architecture of individual

programs. At this level, we are concerned with the way that an individual program
is decomposed into components.
• Architecture in the large is concerned with the architecture of complex enterprise
systems that include other systems, programs, and program components. These
enterprise systems are distributed over different computers, which may be owned
and managed by different companies.

Advantages of explicit architecture

• Stakeholder communication
o Architecture may be used as a focus of discussion by system
stakeholders.
• System analysis
o Means that analysis of whether the system can meet its non-functional
requirements is possible.
 • Large-scale reuse
o The architecture may be reusable across a range of systems
o Product-line architectures may be developed.

Architectural representations

• Simple, informal block diagrams showing entities and relationships are the most
frequently used method for documenting software architectures.
• But these have been criticized because they lack semantics, do not show the
types of relationships between entities nor the visible properties of entities in the
architecture.
• Depends on the use of architectural models. The requirements for model
semantics depends on how the models are used.

Box and line diagrams

• Very abstract - they do not show the nature of component relationships nor the
externally visible properties of the sub-systems.
• However, useful for communication with stakeholders and for project planning.

Use of architectural models

• As a way of facilitating discussion about the system design

o A high-level architectural view of a system is useful for communication
with system stakeholders and project planning because it is not cluttered
with detail. Stakeholders can relate to it and understand an abstract view
of the system. They can then discuss the system as a whole without being
confused by detail.
• As a way of documenting an architecture that has been designed
o The aim here is to produce a complete system model that shows the
different components in a system, their interfaces and their connections.

Architectural design decisions

• Architectural design is a creative process so the process differs depending on the

type of system being developed.
• However, a number of common decisions span all design processes and these
decisions affect the non-functional characteristics of the system.

Architectural design decisions

• Is there a generic application architecture that can be used?

• How will the system be distributed?
• What architectural styles are appropriate?
• What approach will be used to structure the system?
 • How will the system be decomposed into modules?
• What control strategy should be used?
• How will the architectural design be evaluated?
• How should the architecture be documented?

Architecture reuse

• Systems in the same domain often have similar architectures that reflect domain
concepts.
• Application product lines are built around a core architecture with variants that
satisfy particular customer requirements.
• The architecture of a system may be designed around one of more architectural
patterns or ‘styles’.
o These capture the essence of an architecture and can be instantiated in
different ways.
o Discussed later in this lecture.

Architecture and system characteristics

• Performance
o Localized critical operations and minimize communications. Use large
rather than fine-grain components.
• Security
o Use a layered architecture with critical assets in the inner layers.
• Safety
o Localized safety-critical features in a small number of sub-systems.
• Availability
o Include redundant components and mechanisms for fault tolerance.
• Maintainability
o Use fine-grain, replaceable components.

Architectural views

• What views or perspectives are useful when designing and documenting a

system’s architecture?
• What notations should be used for describing architectural models?
• Each architectural model only shows one view or perspective of the system.
o It might show how a system is decomposed into modules, how the run-
time processes interact or the different ways in which system components
are distributed across a network. For both design and documentation, you
usually need to present multiple views of the software architecture.
4 + 1 view model of software architecture

• A logical view, which shows the key abstractions in the system as objects or object
classes.
• A process view, which shows how, at run-time, the system is composed of
interacting processes.
• A development view, which shows how the software is decomposed for
development.
• A physical view, which shows the system hardware and how software components
are distributed across the processors in the system.
• Related using use cases or scenarios (+1)

Architectural patterns

• Patterns are a means of representing, sharing and reusing knowledge.

• An architectural pattern is a stylized description of good design practice, which
has been tried and tested in different environments.
• Patterns should include information about when they are and when the are not
useful.
• Patterns may be represented using tabular and graphical descriptions.

The Model-View-Controller (MVC) pattern

Figure 2.0 The organization of the Model-View-Controller

Figure 3.0 Web application architecture using the MVC pattern

Layered architecture

• Used to model the interfacing of sub-systems.

• Organises the system into a set of layers (or abstract machines) each of which
provide a set of services.
• Supports the incremental development of sub-systems in different layers. When
 a layer interface changes, only the adjacent layer is affected.
• However, often artificial to structure systems in this way.

The Layered architecture pattern

Figure 4.0 A generic layered architecture

Figure 5.0 The architecture of the LIBSYS system

Key points

• A software architecture is a description of how a software system is organized.

• Architectural design decisions include decisions on the type of application, the
distribution of the system, the architectural styles to be used.
• Architectures may be documented from several different perspectives or views
such as a conceptual view, a logical view, a process view, and a development
view.
• Architectural patterns are a means of reusing knowledge about generic system
architectures. They describe the architecture, explain when it may be used and
describe its advantages and disadvantages.

Repository architecture

• Sub-systems must exchange data. This may be done in two ways:

o Shared data is held in a central database or repository and may be
accessed by all sub-systems;
o Each sub-system maintains its own database and passes data explicitly to
other sub-systems.
• When large amounts of data are to be shared, the repository model of sharing is
most commonly used a this is an efficient data sharing mechanism.
The Repository pattern

Figure 6.0 A repository architecture for an IDE

Client-server architecture

• Distributed system model which shows how data and processing is distributed
across a range of components.
o Can be implemented on a single computer.
• Set of stand-alone servers which provide specific services such as printing, data
management, etc.
• Set of clients which call on these services.
• Network which allows clients to access servers.
The Client–server pattern

Figure 7.0 A client–server architecture for a film library

Pipe and filter architecture

• Functional transformations process their inputs to produce outputs.

• May be referred to as a pipe and filter model (as in UNIX shell).
• Variants of this approach are very common. When transformations are
sequential, this is a batch sequential model which is extensively used in data
processing systems.
• Not really suitable for interactive systems.
The pipe and filter pattern

Figure 8.0 An example of the pipe and filter architecture

Application architectures

• Application systems are designed to meet an organizational need.

• As businesses have much in common, their application systems also tend to
have a common architecture that reflects the application requirements.
• A generic application architecture is an architecture for a type of software system
that may be configured and adapted to create a system that meets specific
requirements.
Use of application architectures

• As a starting point for architectural design.

• As a design checklist.
• As a way of organizing the work of the development team.
• As a means of assessing components for reuse.
• As a vocabulary for talking about application types.

Examples of application types

• Data processing applications

o Data driven applications that process data in batches without explicit
user intervention during the processing.
• Transaction processing applications
o Data-centered applications that process user requests and update
information in a system database.
• Event processing systems
o Applications where system actions depend on interpreting events from
the system’s environment.
• Language processing systems
o Applications where the users’ intentions are specified in a formal
language that is processed and interpreted by the system.

Application type examples

• Focus here is on transaction processing and language processing systems.
• Transaction processing systems
o E-commerce systems;
o Reservation systems.
• Language processing systems
o Compilers;
o Command interpreters.

Transaction processing systems

• Process user requests for information from a database or requests to update
the database.
• From a user perspective a transaction is:
o Any coherent sequence of operations that satisfies a goal;
o For example - find the times of flights from London to Paris.
• Users make asynchronous requests for service which are then processed by
a transaction manager.
Figure 9.0 The structure of transaction processing applications

Figure 10. The software architecture of an ATM system

Information systems architecture

• Information systems have a generic architecture that can be organized as a

layered architecture.
• These are transaction-based systems as interaction with these systems
generally involves database transactions.
• Layers include:
o The user interface
o User communications
o Information retrieval
o System database

Figure 11.0 Layered information system architecture

Figure 12.0 The architecture of the MHC-PMS

Web-based information systems

• Information and resource management systems are now usually web-based

systems where the user interfaces are implemented using a web browser.
• For example, e-commerce systems are Internet-based resource management
systems that accept electronic orders for goods or services and then arrange
delivery of these goods or services to the customer.
• In an e-commerce system, the application-specific layer includes additional
functionality supporting a ‘shopping cart’ in which users can place a number of
items in separate transactions, then pay for them all together in a single
transaction.

Server implementation

• These systems are often implemented as multi-tier client server/architectures

(discussed in Chapter 18)
o The web server is responsible for all user communications, with the user
interface implemented using a web browser;
o The application server is responsible for implementing application-specific
logic as well as information storage and retrieval requests;
o The database server moves information to and from the database and
handles transaction management.

Language processing systems

• Accept a natural or artificial language as input and generate some other

representation of that language.
• May include an interpreter to act on the instructions in the language that is being
processed.
• Used in situations where the easiest way to solve a problem is to describe an
algorithm or describe the system data
 o Meta-case tools process tool descriptions, method rules, etc and generate
tools.

Figure 13.0 The architecture of a language processing system

Compiler components

• A lexical analyzer, which takes input language tokens and converts them to an
internal form.
• A symbol table, which holds information about the names of entities (variables,
class names, object names, etc.) used in the text that is being translated.
• A syntax analyzer, which checks the syntax of the language being translated.
• A syntax tree, which is an internal structure representing the program being
compiled.

Compiler components

• A semantic analyzer that uses information from the syntax tree and the symbol
table to check the semantic correctness of the input language text.
• A code generator that ‘walks’ the syntax tree and generates abstract machine
code.

Figure 14 A pipe and filter compiler architecture

Figure 15 A repository architecture for a language processing system

Key points
• Models of application systems architectures help us understand and compare
applications, validate application system designs and assess large-scale
components for reuse.
• Transaction processing systems are interactive systems that allow information in
a database to be remotely accessed and modified by a number of users.
• Language processing systems are used to translate texts from one language into
another and to carry out the instructions specified in the input language. They
include a translator and an abstract machine that executes the generated
language.

Self Help: You can also refer to the sources below to help you further
understand the lesson:

Sommerville, I. (2016). Software Engineering. 10th Ed. Singapore: Pearson Education

South Asia Pte Ltd.

Irlbeck, M., Peled, D., & Pretschner, A. (Eds.). (2015). Dependable software systems
engineering. Retrieved from https://ebookcentral.proquest.com

Stephens, R. (2015). Beginning software engineering. Retrieved from

https://ebookcentral.proquest.com

Waern, Y. Cooperative Process Management., (2014) Retrieved from

http://site.ebrary.com/lib/uniofmindanao/docDetail.action?docID=10056166