SOFTWARE ENGINEERING

LECTURE NOTES

B.TECH III YEAR

SEM-I

DEPARTMENT OF COMPUTER
SCIENCE AND ENGINEERING
II Year B. Tech CSE - I Sem L T/P/D C
3 -/-/- 3
(R18A0511) SOFTWARE ENGINEERING

OBJECTIVES:
 To comprehend the various software process models.
 To understand the types of software requirements and SRS document.
 To know the different software design and architectural styles.
 To learn the software testing approaches and metrics used in software development.
 To know about quality control and risk management.

UNIT - I:
Introduction to Software Engineering: The evolving role of software, Changing Nature of
Software, Software myths.
A Generic view of process: Software engineering- A layered technology, a process
framework, Process patterns, process assessment.
Process models: The waterfall model, Incremental process models, Evolutionary process models, The Unified
process, Agility and Agile Process model, Extreme Programming, Other process models of Agile Development
and Tools

UNIT - II:
Software Requirements: Functional and non-functional requirements, User requirements, System
requirements, Interface specification, the software requirements document.
Requirements engineering process: Feasibility studies, Requirements elicitation and
analysis, Requirements validation, Requirements management.
System models: Context Models, Behavioral models, Data models, Object models, structured methods. UML
Diagrams.

UNIT - III:
Design Engineering: Design process and Design quality, Design concepts, the design model.
Creating an architectural design: Software architecture, Data design, Architectural styles
and patterns, Architectural Design.
Object-Oriented Design: Objects and object classes, An Object-Oriented design process,
Design evolution.
Performing User interface design: Golden rules, User interface analysis and design,
interface analysis, interface design steps, Design evaluation.

UNIT - IV:
Testing Strategies: A strategic approach to software testing, test strategies for conventional software, Black-
Box and White-Box testing, Validation testing, System testing, the art of Debugging.
Product metrics: Software Quality, Metrics for Analysis Model, Metrics for Design Model, Metrics for source
code, Metrics for testing, Metrics for maintenance.
Metrics for Process and Products: Software Measurement, Metrics for software
quality.

UNIT - V:
Risk management: Reactive vs. Proactive Risk strategies, software risks, Risk identification,
Risk projection, Risk refinement, RMMM, RMMM Plan.
Quality Management: Quality concepts, Software quality assurance, Software Reviews,
Formal technical reviews, Statistical Software quality Assurance, The Capability Maturity
Model Integration (CMMI), Software reliability, The ISO 9000 quality standards.

TEXT BOOKS :
1. Software Engineering A practitioner’s Approach, Roger S
Pressman, 6th edition. McGrawHill International Edition.
2. Software Engineering, Ian Sommerville, 7th edition, Pearson education.

REFERENCE BOOKS :
1. Software Engineering, A Precise Approach, Pankaj Jalote, Wiley India, 2010.
2. Software Engineering: A Primer, Waman S Jawadekar, Tata McGraw-Hill,
2008
3. Software Engineering, Principles and Practices, Deepak Jain,
Oxford University Press.
4. Software Engineering1: Abstraction and modelling, Diner
Bjorner, Springer International edition, 2006.
5. Software Engineering2: Specification of systems and languages,
Diner Bjorner, Springer International edition 2006.
6. Software Engineering Principles and Practice, Hans Van Vliet,
3rd edition, John Wiley & Sons Ltd.
7. Software Engineering3: Domains, Requirements, and
Software Design, D. Bjorner, Springer International Edition.
8. Introduction to Software Engineering, R. J. Leach, CRC Press.

OUTCOMES:
At the end of the course the students are able to:
 To compare and select a process model for a business system.
 To identify and specify the requirements for the development of
an application.
 To develop and maintain efficient, reliable and cost effective
software solutions.
 To critically think and evaluate assumptions and arguments of the client.
 UNIT-II

SOFTWARE REQUIREMENTS

Software requirements are necessary

To introduce the concepts of user and system requirements
To describe functional and non-functional requirements
To explain how software requirements may be organised in a requirements document
What is a requirement?
The requirements for the system are the description of the services provided by the system and
its operational constraints
It may range from a high-level abstract statement of a service or of a system constraint to
a detailed mathematical functional specification.
This is inevitable as requirements may serve a dual function
o May be the basis for a bid for a contract - therefore must be open to interpretation;
o May be the basis for the contract itself - therefore must be defined in detail;
Both these statements may be called requirements
Requirements engineering:
The process of finding out, analysing documenting and checking these services and constraints is
called requirement engineering.
The process of establishing the services that the customer requires from a system and the
constraints under which it operates and is developed.
The requirements themselves are the descriptions of the system services and constraints that are
generated during the requirements engineering process.

Requirements abstraction (Davis):

If a company wishes to let a contract for a large software development project, it must define its
needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be
written so that several contractors can bid for the contract, offering, perhaps, different ways of
meeting the client organisation’s needs. Once a contract has been awarded, the contractor must
write a system definition for the client in more detail so that the client understands and can
validate what the software will do. Both of these documents may be called the requirements
document for the system.”

Types of requirement:
User requirements
Statements in natural language plus diagrams of the services the system provides and
its operational constraints. Written for customers.
System requirements
A structured document setting out detailed descriptions of the system‘s functions,
services and operational constraints. Defines what should be implemented so may be
part of a contract between client and contractor.

Definitions and specifications:

User Requirement Definition:

The software must provide the means of representing and accessing external files created by other
tools.

Page 23
 System Requirement specification:
The user should be provided with facilities to define the type of external files.
Each external file type may have an associated tool which may be applied to the file.
Each external file type may be represented as a specific icon on the user‘s display.
Facilities should be provided for the icon representing an external file type to be defined by
the user.
When an user selects an icon representing an external file, the effect of that selection is to apply the
tool associated with the type of the external file to the file represented by the selected icon.
Requirements readers:

Functional and non-functional

requirements: Functional requirements
Statements of services the system should provide how the system should react
to particular inputs and how the system should behave in particular situations.
Non-functional requirements
Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
Domain requirements
Requirements that come from the application domain of the system and that
reflect characteristics of that domain.

1.1) FUNCTIONAL REQUIREMENTS:

Describe functionality or system services.
Depend on the type of software, expected users and the type of system where the software
is used.
Functional user requirements may be high-level statements of what the system should do
but functional system requirements should describe the system services in detail.
The functional requirements for The LIBSYS system:
A library system that provides a single interface to a number of databases of articles in
different libraries.
Users can search for, download and print these articles for personal study.
Examples of functional requirements
The user shall be able to search either all of the initial set of databases or select a subset from it.
The system shall provide appropriate viewers for the user to read documents in the
document store.

Page 24
 Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able
to copy to the account‘s permanent storage area.
Requirements imprecision
Problems arise when requirements are not precisely stated.
Ambiguous requirements may be interpreted in different ways by developers and users.
Consider the term ‗appropriate viewers‘
o User intention - special purpose viewer for each different document type;
o Developer interpretation - Provide a text viewer that shows the contents of the
document.
Requirements completeness and consistency:
In principle, requirements should be both complete and consistent.
Complete
They should include descriptions of all facilities
required. Consistent
There should be no conflicts or contradictions in the descriptions of the system facilities. In
practice, it is impossible to produce a complete and consistent requirementsdocument.

NON-FUNCTIONAL REQUIREMENTS
These define system properties and constraints e.g. reliability, response time and
storage requirements. Constraints are I/O device capability, system representations, etc.
Process requirements may also be specified mandating a particular CASE system,
programming language or development method.
Non-functional requirements may be more critical than functional requirements. If these are
not met, the system is useless.
1.2) Non-functional requirement types:

Non-functional requirements :
Product requirements

Page 25
 Requirements which specify that the delivered product must behave in a particular
way e.g. execution speed, reliability, etc.
Eg:The user interface for LIBSYS shall be implemented as simple HTML without
frames or Java applets.
Organisational requirements
Requirements which are a consequence of organisational policies and procedures
e.g. process standards used, implementation requirements, etc.
Eg: The system development process and deliverable documents shall conform to
the process and deliverables defined in XYZCo-SP-STAN-95.
External requirements
Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements, etc.
Eg: The system shall not disclose any personal information about customers apart
from their name and reference number to the operators of the system.

Goals and requirements:

Non-functional requirements may be very difficult to state precisely and imprecise
requirements may be difficult to verify.
Goal
A general intention of the user such as ease of use.
The system should be easy to use by experienced controllers and should be organised in
such a way that user errors are minimised.
Verifiable non-functional requirement
A statement using some measure that can be objectively tested.
Experienced controllers shall be able to use all the system functions after a total of two hours
training. After this training, the average number of errors made by experienced users shall
not exceed two per day.
Goals are helpful to developers as they convey the intentions of the system users.

Requirements measures:
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size M Bytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of
unavailability Rate of
failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing
failure
Probability of data corruption on failure

Page 26
 Portability Percentage of target dependent statements
Number of target systems

Requirements interaction:
Conflicts between different non-functional requirements are common in complex systems.
Spacecraft system
To minimise weight, the number of separate chips in the system should be
minimised.
To minimise power consumption, lower power chips should be used.
However, using low power chips may mean that more chips have to be used. Which is the
most critical requirement?
A common problem with non-functional requirements is that they can be difficult to verify. Users
or customers often state these requirements as general goals such as ease of use, the ability of the system
to recover from failure or rapid user response. These vague goals cause problems for system developers as
they leave scope for interpretation and subsequent dispute once the system is delivered.

1.3) DOMAIN REQUIREMENTS

Derived from the application domain and describe system characteristics and features that
reflect the domain.
Domain requirements be new functional requirements, constraints on existing requirements
or define specific computations.
If domain requirements are not satisfied, the system may be unworkable.

Library system domain requirements:

There shall be a standard user interface to all databases which shall be based on the
Z39.50 standard.
Because of copyright restrictions, some documents must be deleted immediately on arrival.
Depending on the user‘s requirements, these documents will either be printed locally on the
system server for manually forwarding to the user or routed to a network printer.

Domain requirements problems

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

USER REQUIREMENTS
Should describe functional and non-functional requirements in such a way that they
are understandable by system users who don‘t have detailed technical knowledge.
User requirements are defined using natural language, tables and diagrams as these can
be understood by all users.

Problems with natural language

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

Requirement problems
Database requirements includes both conceptual and detailed information
• Describes the concept of a financial accounting system that is to be included
in LIBSYS;

Page 27
28 SOFTWARE ENGINEERING – Material

SOFTWARE ENGINEERING

However, it also includes the detail that managers can configure this system - this is
unnecessary at this level.
Grid requirement mixes three different kinds of requirement
Conceptual functional requirement (the need for a grid);
Non-functional requirement (grid units);
Non-functional UI requirement (grid switching).
Structured presentation
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.

SYSTEM REQUIREMENTS
More detailed specifications of system functions, services and constraints than user requirements.
They are intended to be a basis for designing the system.
They may be incorporated into the system contract.
System requirements may be defined or illustrated using system models

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
A system architecture may be designed to structure the requirements;
The system may inter-operate with other systems that generate design requirements;
The use of a specific design may be a domain requirement.
Problems with NL(natural language) specification
Ambiguity
The readers and writers of the requirement must interpret the same words in the
same way. NL is naturally ambiguous so this is very difficult.
Over-flexibility
The same thing may be said in a number of different ways in the
specification. Lack of modularisation
NL structures are inadequate to structure system requirements.

Alternatives to NL specification:
Notation Description

Structured natural This approach depends on defining standard forms or templates to express the
language requirements specification.

Design description This approach uses a language like a programming language but with more abstract
languages features to specify the requirements by defining an operational model of the
system.
This approach is not now widely used although it can be useful for interface
specifications.

Page 28
29 SOFTWARE ENGINEERING – Material

SOFTWARE ENGINEERING

Graphical A graphical language, supplemented by text annotations is used to define the functional
notations requirements for the system. An early example of such a graphical language was SADT.
Now, use-case descriptions and sequence diagrams are commonly used .

Mathematical These are notations based on mathematical concepts such as finite-state machines or
specifications sets. These unambiguous specifications reduce the arguments between customer
and
contractor about system functionality. However, most customers don‘t understand
formal specifications and are reluctant to accept it as a system contract.

3.1) Structured language specifications

The freedom of the requirements writer is limited by a predefined template for requirements.
All requirements are written in a standard way.
The terminology used in the description may be limited.
The advantage is that the most of the expressiveness of natural language is maintained but
a degree of uniformity is imposed on the specification.

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.
Indication of other entities required.
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.

Graphical models
Graphical models are most useful when you need to show how state changes or where you need
to describe a sequence of actions.

Sequence diagrams
These show the sequence of events that take place during some user interaction with a system.
You read them from top to bottom to see the order of the actions that take place.
Cash withdrawal from an ATM
Validate card;
Handle request;
Complete transaction.

Page 29
 30 SOFTWARE
ENGINEERING
SOFTWARE ENGINEERING

Sequence diagram of ATM withdrawal

System requirement specification using a standard form:

Function
Description
Inputs
Source
Outputs
Destination
Action
Requires
Pre-condition
Post-condition
Side-effects

When a standard form is used for specifying functional requirements, the following information should be
included:
Description of the function or entity being specified
Description of its inputs and where these come from
Description of its outputs and where these go to
Indication of what other entities are used
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

Page 30
 31 SOFTWARE
ENGINEERING
SOFTWARE ENGINEERING

Description of the side effects of the operation.

INTERFACE SPECIFICATION
Most systems must operate with other systems and the operating interfaces must be specified
as part of the requirements.
Three types of interface may have to be defined
Procedural interfaces where existing programs or sub-systems offer a range of services
that are accessed by calling interface procedures. These interfaces are sometimes called
Applicatin Programming Interfaces (APIs)
Data structures that are exchanged that are passed from one sub-system to
another. Graphical data models are the best notations for this type of description
Data representations that have been established for an existing sub-system
Formal notations are an effective technique for interface specification.

5) THE SOFTWARE REQUIREMENTS DOCUMENT:

The 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

Users of a requirements document:

Page 31
 32 SOFTWARE
ENGINEERING
SOFTWARE ENGINEERING

IEEE requirements standard defines a generic structure for a requirements document that must
be instantiated for each specific system.
Introduction.
Purpose of the requirements document
Scope of the project
Definitions, acronyms and abbreviations
References
Overview of the remainder of the document
General description.
Product perspective
Product functions
User characteristics
General constraints
Assumptions and dependencies
Specific requirements cover functional, non-functional and interface requirements. The
requirements may document external interfaces, describe system functionality and performance,
specify logical database requirements, design constraints, emergent system properties and
quality characteristics.
Appendices.
Index.

REQUIREMENTS ENGINEERING PROCESSES

The goal of requirements engineering process is to create and maintain a system requirements document.
The overall process includes four high-level requirement engineering sub-processes. These are
concerned with
Assessing whether the system is useful to the business(feasibility study)
Discovering requirements(elicitation and analysis)
Converting these requirements into some standard form(specification)
Checking that the requirements actually define the system that the customer wants(validation) The
process of managing the changes in the requirements is called requirement management.

The requirements engineering process

Requirements engineering:

Page 32
 33 SOFTWARE
ENGINEERING
SOFTWARE ENGINEERING

The alternative perspective on the requirements engineering process presents the process as a three-stage
activity where the activities are organized as an iterative process around a spiral. The amount of time and
effort devoted to each activity in iteration depends on the stage of the overall process and the type of system
being developed. Early in the process, most effort will be spent on understanding high-level business and
non-functional requirements and the user requirements. Later in the process, in the outer rings of the spiral,
more effort will be devoted to system requirements engineering and system modeling.

This spiral model accommodates approaches to development in which 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.

Some people consider requirements engineering to be the process of applying a structured analysis method
such as object-oriented analysis. This involves analyzing the system and developing a set of graphical
system models, such as use-case models, that then serve as a system specification. The set of models
describes the behavior of the system and are annotated with additional information describing, for example,
its required performance or reliability.
Spiral model of requirements engineering processes

1) FEASIBILITY STUDIES
A feasibility study decides whether or not the proposed system is worthwhile. The input to the
feasibility study is a set of preliminary business requirements, an outline description of the system and how
the system is intended to support business processes. The results of the feasibility study should be a report
that recommends whether or not it worth carrying on with the requirements engineering and system
development process.
A short focused study that checks
– If the system contributes to organisational objectives;
– If the system can be engineered using current technology and within budget;

Page 33
 34 SOFTWARE
ENGINEERING
SOFTWARE ENGINEERING

– If the system can be integrated with other systems that are used.

Feasibility study implementation:

A feasibility study involves information assessment, information collection and report writing.
Questions for people in the organisation
– What if the system wasn‘t implemented?
– What are current process problems?
– How will the proposed system help?
– What will be the integration problems?
– Is new technology needed? What skills?
– What facilities must be supported by the proposed system?
In a feasibility study, you may consult information sources such as the managers of the
departments where the system will be used, software engineers who are familiar with the type of system
that is proposed, technology experts and end-users of the system. They should try to complete a feasibility
study in two or three weeks.
Once you have the information, you write the feasibility study report. You should make a
recommendation about whether or not the system development should continue. In the report, you may
propose changes to the scope, budget and schedule of the system and suggest further high-level
requirements for the system.

2) REQUIREMENT ELICITATION AND ANALYSIS:

The requirement engineering process is 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 change.

The requirements spiral

Page 34
 35 SOFTWARE
ENGINEERING
SOFTWARE ENGINEERING

Process activities
Requirements discovery
– Interacting with stakeholders to discover their requirements. Domain requirements are
also discovered at this stage.
Requirements classification and organisation
– Groups related requirements and organises them into coherent
clusters. Prioritisation and negotiation
– Prioritising requirements and resolving requirements
conflicts. Requirements documentation
– Requirements are documented and input into the next round of the spiral.
The process cycle starts with requirements discovery and ends with requirements documentation. The
analyst‘s understanding of the requirements improves with each round of the cycle.
Requirements classification and organization is primarily concerned with identifying overlapping
requirements from different stakeholders and grouping related requirements. The most common way of
grouping requirements is to use a model of the system architecture to identify subsystems and to associate
requirements with each sub-system.
Inevitably, stakeholders have different views on the importance and priority of requirements, and
sometimes these view conflict. During the process, you should organize regular stakeholder negotiations so
that compromises can be reached.
In the requirement documenting stage, the requirements that have been elicited are documented in such a
way that they can be used to help with further requirements discovery.

2.1) REQUIREMENTS DISCOVERY:

Requirement discovery is the process of gathering information about the proposed and existing
systems and distilling the user and system requirements from this information.
Sources of information include documentation, system stakeholders and the specifications
of similar systems.
They interact with stakeholders through interview and observation and may use scenarios
and prototypes to help with the requirements discovery.
Stakeholders range from system end-users through managers and external stakeholders such as
regulators who certify the acceptability of the system.
For example, system stakeholder for a bank ATM include
Bank customers
Representatives of other banks
Bank managers
Counter staff
Database administrators
Security managers
Marketing department
Hardware and software maintenance engineers
Banking regulators
Requirements sources( stakeholders, domain, systems) can all be represented as system viewpoints, where
each viewpoints, where each viewpoint presents a sub-set of the requirements for the system.

Viewpoints:
Viewpoints are a way of structuring the requirements to represent the perspectives of different
stakeholders. Stakeholders may be classified under different viewpoints.
This multi-perspective analysis is important as there is no single correct way to analyse system
requirements.
•
Types of viewpoint:
Interactor viewpoints
– People or other systems that interact directly with the system. These viewpoints provide
detailed system requirements covering the system features and interfaces. In an ATM, the
customer‘s and the account database are interactor VPs.
Indirect viewpoints

Page 35
 36 SOFTWARE
ENGINEERING
SOFTWARE ENGINEERING

– Stakeholders who do not use the system themselves but who influence the requirements.
These viewpoints are more likely to provide higher-level organisation requirements and
constraints. In an ATM, management and security staff are indirect viewpoints.
Domain viewpoints
– Domain characteristics and constraints that influence the requirements. These viewpoints
normally provide domain constraints that apply to the system. In an ATM, an example
would be standards for inter-bank communications.
Typically, these viewpoints provide different types of requirements.

Viewpoint identification:
Identify viewpoints using
– Providers and receivers of system services;
– Systems that interact directly with the system being specified;
– Regulations and standards;
– Sources of business and non-functional requirements.
– Engineers who have to develop and maintain the system;
– Marketing and other business viewpoints.

LIBSYS viewpoint hierarchy

Interviewing
In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they
use and the system to be developed.
There are two types of interview
Closed interviews where a pre-defined set of questions are answered.
Open interviews where there is no pre-defined agenda and a range of issues are explored
with stakeholders.
-
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
– Requirements engineers cannot understand specific domain terminology;

Page 36
 37 SOFTWARE
ENGINEERING
SOFTWARE ENGINEERING

– Some domain knowledge is so familiar that people find it hard to articulate or think that it
isn‘t worth articulating.

Effective interviewers:
Interviewers should be open-minded, willing to listen to stakeholders and should not have pre-
conceived ideas about the requirements.
They should prompt the interviewee with a question or a proposal and should not simply expect
them to respond to a question such as ‗what do you want‘.
•
Scenarios:
Scenarios are real-life examples of how a system can be used.
They should include
– A description of the starting situation;
– A description of the normal flow of events;
– A description of what can go wrong;
– Information about other concurrent activities;
– A description of the state when the scenario finishes.

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.
Sequence diagrams may be used to add detail to use-cases by showing the sequence of
event processing in the system.
•
Article printing use-case:

LIBSYS use cases:

Page 37
 38 SOFTWARE
ENGINEERING
SOFTWARE ENGINEERING

Article printing sequence:

Social and organisational factors

Software systems are used in a social and organisational context. This can influence or even
dominate the system requirements.
Social and organisational factors are not a single viewpoint but are influences on all viewpoints.
Good analysts must be sensitive to these factors but currently no systematic way to tackle
their analysis.

2.2) ETHNOGRAPHY:
A social scientists 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.

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.

Ethnography and prototyping

Page 38
 39 SOFTWARE
ENGINEERING
SOFTWARE ENGINEERING

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.

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
– 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
– Systematic manual analysis of the
requirements. Prototyping
– Using an executable model of the system to check requirements. Covered in Chapter 17.
Test-case generation
– 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: Is the requirement realistically testable?
Comprehensibility: Is the requirement properly understood?
Traceability: Is the origin of the requirement clearly stated?
Adaptability: 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.
Requirements are inevitably incomplete and inconsistent
– New requirements emerge during the process as business needs change and a
better understanding of the system is developed;
– Different viewpoints have different requirements and these are often contradictory.

Requirements change
The priority of requirements from different viewpoints changes during the development
process. System customers may specify requirements from a business perspective that conflict
with end- user requirements.
The business and technical environment of the system changes during its development.

Page 39
40

SOFTWARE ENGINEERING

Requirements evolution:

4.1) Enduring and volatile requirements:

Enduring requirements: Stable requirements derived from the core activity of the customer
organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain
models
Volatile requirements: Requirements which change during development or when the system is in
use. In a hospital, requirements derived from health-care policy
Requirements classification:
Requirement Description
Type
Mutable Requirements that change because of changes to the environment in which the
requirements organisation is operating. For example, in hospital systems, the funding of patient
care may change and thus require different treatment information to be collected.
Emergent Requirements that emerge as the customer's understanding of the system develops
requirements during the system development. The design process may reveal new emergent
requirements.
Consequential Requirements that result from the introduction of the computer system. Introducing
requirements the computer system may change the organisations processes and open up new ways
of working which generate new system requirements
Compatibility Requirements that depend on the particular systems or business processes within an
requirements organisation. As these change, the compatibility requirements on the commissioned
or delivered system may also have to evolve.

4.2) Requirements management planning:

During the requirements engineering process, you have to plan:
– Requirements identification
How requirements are individually identified;
– A change management process
The process followed when analysing a requirements change;
– Traceability policies
The amount of information about requirements relationships that is maintained;
– CASE tool support
The tool support required to help manage requirements change;

Traceability:
Traceability is concerned with the relationships between requirements, their sources and the system design
Source traceability
– Links from requirements to stakeholders who proposed these
requirements; Requirements traceability
– Links between dependent requirements;
Design traceability - Links from the requirements to the design;

Page 40
41

SOFTWARE ENGINEERING

CASE tool support:

Requirements storage
– Requirements should be managed in a secure, managed data store.
Change management
– The process of change management is a workflow process whose stages can be defined
and information flow between these stages partially automated.
Traceability management
– Automated retrieval of the links between requirements.

4.3) Requirements change management:

Should apply to all proposed changes to the requirements.
Principal stages
– Problem analysis. Discuss requirements problem and propose change;
– Change analysis and costing. Assess effects of change on other requirements;
– Change implementation. Modify requirements document and other documents to
reflect change.

Change management:

SYSTEM MODELLING
System modelling helps the analyst to understand the functionality of the system and models
are used to communicate with customers.
Different models present the system from different perspectives
o Behavioural perspective showing the behaviour of the system;
o Structural perspective showing the system or data architecture.
Model types
Data processing model showing how the data is processed at different stages.
Composition model showing how entities are composed of other entities.
Architectural model showing principal sub-systems.
Classification model showing how entities have common characteristics.
Stimulus/response model showing the system‘s reaction to events.

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.

Page 41
42

SOFTWARE ENGINEERING

The context of an ATM system:

Process models:
Process models show the overall process and the processes that are supported by the system.
Data flow models may be used to show the processes and the flow of information from
one process to another.

BEHAVIOURAL MODELS:
Behavioural models are used to describe the overall behaviour of a system.
Two types of behavioural model are:
o Data processing models that show how data is processed as it moves through the
system;
State machine models that show the systems response to events.
These models show different perspectives so both of them are required to describe the
system‘s behaviour.

2.1) Data-processing models:

Data flow diagrams (DFDs) may be used to model the system‘s data processing.
These show the processing steps as data flows through a system.
DFDs are an intrinsic part of many analysis methods.
Simple and intuitive notation that customers can
understand. Show end-to-end processing of data.

Order processing DFD:

Page 42
43

SOFTWARE ENGINEERING

Data flow diagrams:

DFDs model the system from a functional perspective.
Tracking and documenting how the data associated with a process is helpful to develop an
overall understanding of the system.
Data flow diagrams may also be used in showing the data exchange between a system and
other systems in its environment.

2.2) 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.

Statecharts:
Allow the decomposition of a model into sub-models (see following slide).
A brief description of the actions is included following the ‗do‘ in each
state. Can be complemented by tables describing the states and the stimuli.

Microwave oven model:

Microwave oven state description:

State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ‗Half power‘.
Full power The oven power is set to 600 watts. The display shows ‗Full power‘.
Set time The cooking time is set to the user‘s input value. The display shows the cooking time
selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on. Display shows ‗Not
ready‘.
Enabled Oven operation is enabled. Interior oven light is off. Display shows ‗Ready to cook‘.

Page 43
44

SOFTWARE ENGINEERING

Operation Oven in operation. Interior oven light is on. Display shows the timer countdown. On
completion of cooking, the buzzer is sounded for 5 seconds. Oven light is on. Display
shows ‗Cooking complete‘ while buzzer is sounding.

Microwave oven stimuli:

Stimulus Description
Half power The user has pressed the half power button
Full power The user has pressed the full power button
Timer The user has pressed one of the timer buttons
Number The user has pressed a numeric key
Door open The oven door switch is not closed
Door closed The oven door switch is closed
Start The user has pressed the start button
Cancel The user has pressed the cancel button

SEMANTIC DATA MODELS:

Used to describe the logical structure of data processed by the system.
An entity-relation-attribute model sets out the entities in the system, the relationships
between these entities and the entity attributes
Widely used in database design. Can readily be implemented using relational databases.
No specific notation provided in the UML but objects and associations can be used.

Data dictionaries
Data dictionaries are lists of all of the names used in the system models. Descriptions of
the entities, relationships and attributes are also included.
Advantages
o Support name management and avoid duplication;
Store of organisational knowledge linking analysis, design andimplementation;
Many CASE workbenches support data dictionaries.

OBJECT MODELS:
Object models describe the system in terms of object classes and their associations.
An object class is an abstraction over a set of objects with common attributes and the
services (operations) provided by each object.
Various object models may be produced
Inheritance models;
o Aggregation models;
Interaction models.
Natural ways of reflecting the real-world entities manipulated by the system
More abstract entities are more difficult to model using this approach
Object class identification is recognised as a difficult process requiring a deep understanding of
the application domain
Object classes reflecting domain entities are reusable across systems

4.1) Inheritance models:

Organise the domain object classes into a hierarchy.
Classes at the top of the hierarchy reflect the common features of all classes.
Object classes inherit their attributes and services from one or more super-classes. these may
then be specialised as necessary.

Page 44
45

SOFTWARE ENGINEERING

Class hierarchy design can be a difficult process if duplication in different branches is to

be avoided.

Object models and the UML:

The UML is a standard representation devised by the developers of widely used object-
oriented analysis and design methods.
It has become an effective standard for object-oriented modelling.
Notation
o Object classes are rectangles with the name at the top, attributes in the middle section
and operations in the bottom section;
Relationships between object classes (known as associations) are shown as lines
linking objects;
Inheritance is referred to as generalisation and is shown ‗upwards‘ rather than
‗downwards‘ in a hierarchy.

Library class hierarchy:

User class hierarchy:

Page 45
46

SOFTWARE ENGINEERING

Multiple inheritance:
Rather than inheriting the attributes and services from a single parent class, a system which
supports multiple inheritance allows object classes to inherit from severalsuper-classes.
This can lead to semantic conflicts where attributes/services with the same name in
different super-classes have different semantics.
Multiple inheritance makes class hierarchy reorganisation more complex.

Multiple inheritance

Object aggregation:
An aggregation model shows how classes that are collections are composed of otherclasses.
Aggregation models are similar to the part-of relationship in semantic data models.

4.2) Object aggregation

Object behaviour modelling

Page 46
47

SOFTWARE ENGINEERING

A behavioural model shows the interactions between objects to produce some particular
system behaviour that is specified as a use-case.
Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction
between objects.

STRUCTURED METHODS:
Structured methods incorporate system modelling as an inherent part of the method.
Methods define a set of models, a process for deriving these models and rules and guidelines
that should apply to the models.
CASE tools support system modelling as part of a structured method.

Method weaknesses:
They do not model non-functional system requirements.
They do not usually include information about whether a method is appropriate for a
given problem.
The may produce too much documentation.
The system models are sometimes too detailed and difficult for users to understand.

CASE workbenches:
A coherent set of tools that is designed to support related software process activities such
as analysis, design or testing.
Analysis and design workbenches support system modelling during both requirements
engineering and system design.
These workbenches may support a specific design method or may provide support for a
creating several different types of system model.

An analysis and design workbench

Page 47
 97 SOFTWARE ENGINEERING –
Material
SOFTWARE ENGINEERING

Analysis workbench components:

Diagram editors
Model analysis and checking tools
Repository and associated query language
Data dictionary
Report definition and generation
tools Forms definition tools
Import/export translators
Code generation tools

Page 49