SOFTWARE ENGINEERING

III Year B.Tech AIML/CS-AIML -I SEM

Objectives:
The students will be able:
1. To comprehend the various software process models.
2. To understand the types of software requirements and SRS document.
3. To know the different software design and architectural styles.
4. To learn the software testing approaches and metrics used in software development.
5. 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,

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

Software Engineering
 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, 6thedition.
McGraw Hill 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
5. edition, 2006.
6. Software Engineering2: Specification of systems and languages, Diner Bjorner,
7. Springer International edition 2006.
8. Software Engineering Principles and Practice, Hans Van Vliet, 3rd edition,
John Wiley & Sons Ltd.
9. Software Engineering3: Domains, Requirements, and Software Design, D. Bjorner,
Springer International Edition.
10. Introduction to Software Engineering, R. J. Leach, CRC Press.

Course Outcomes:
Students will have the ability:
1. To compare and select a process model for a business system.
2. To identify and specify the requirements for the development of an application.
3. To develop and maintain efficient, reliable and cost effective software solutions.
To critically think and evaluate assumptions and arguments

Software Engineering
 INDEX

S. No Topic Page no
Unit

1 Introduction to Software Engineering 5

I

2 Evolving Role of Software 5

I

3 I A Generic view of process 7

4 I Process models 11

5 II Software Requirements 21

6 II Requirements engineering process 24

7 II System models 29

Software Engineering Page 4

 UNIT - I

INTRODUCTION:

Software Engineering is a framework for building software and is an engineering approach to software
development. Software programs can be developed without S/E principles and methodologies but they are
indispensable if we want to achieve good quality software in a cost effective manner.
Software is defined as:
Instructions + Data Structures + Documents

Engineering is the branch of science and technology concerned with the design, building, and use of
engines, machines, and structures. It is the application of science, tools and methods to find cost effective
solution to simple and complex problems.

SOFTWARE ENGINEERING is defined as a systematic, disciplined and quantifiable approach for

thedevelopment, operation and maintenance of software.

The Evolving role of software

The dual role of Software is as follows:
1. A Product- Information transformer producing, managing and displaying information.
2. A Vehicle for delivering a product- Control of computer(operating system),the communication of
information(networks) and the creation of other programs.

Characteristics of software
• Software is developed or engineered, but it is not manufactured in the classical sense.
• Software does not wear out, but it deteriorates due to change.
• Software is custom built rather than assembling existing components.

THE CHANGING NATURE OF SOFTWARE

The various categories of software are
1. System software
2. Application software
3. Engineering and scientific software
4. Embedded software
5. Product-line software
6. Web-applications
7. Artificial intelligence software

• System software. System software is a collection of programs written to service other programs
• Embedded software-- resides in read-only memory and is used to control products and systems for
the consumer and industrial markets.
• Artificial intelligence software. Artificial intelligence (AI) software makes use of nonnumeric
algorithms to solve complex problems that are not amenable to computation or straightforward analysis
• Engineering and scientific software. Engineering and scientific software have been characterized

Software Engineering Page 5

by "number crunching" algorithms.

LEGACY SOFTWARE

Legacy software are older programs that are developed decades ago. The quality of legacy software is
poor because it has inextensible design, convoluted code, poor and nonexistent documentation, test cases
and results that are not achieved.
As time passes legacy systems evolve due to following reasons:
 The software must be adapted to meet the needs of new computing environment or technology.
 The software must be enhanced to implement new business requirements.
 The software must be extended to make it interoperable with more modern systems or database
 The software must be rearchitected to make it viable within a network environment.

SOFTWARE MYTHS
Myths are widely held but false beliefs and views which propagate misinformation and confusion.
Three types of myth are associated with software:
- Management myth
- Customer myth
- Practitioner’s myth

MANAGEMENT MYTHS
• Myth(1)-The available standards and procedures for software are enough.
• Myth(2)-Each organization feel that they have state-of-art software development tools since they
have latest computer.
• Myth(3)-Adding more programmers when the work is behind schedule can catch up.
• Myth(4)-Outsourcing the software project to third party, we can relax and let that party build it.

CUSTOMER MYTHS
• Myth(1)- General statement of objective is enough to begin writing programs, the details can be
filled in later.
• Myth(2)-Software is easy to change because software is flexible

PRACTITIONER’S MYTH
• Myth(1)-Once the program is written, the job has been done.
• Myth(2)-Until the program is running, there is no way of assessing the quality.
• Myth(3)-The only deliverable work product is the working program
• Myth(4)-Software Engineering creates voluminous and unnecessary documentation and invariably
slows down software development.

SOFTWARE ENGINEERING- A LAYERED TECHNOLOGY

Software Engineering Page 6

 Fig: Software Engineering-A layered technology

SOFTWARE ENGINEERING - A LAYERED TECHNOLOGY

• Quality focus - Bedrock that supports Software Engineering.
• Process - Foundation for software Engineering
• Methods - Provide technical How-to’s for building software
• Tools - Provide semi-automatic and automatic support to methods

A PROCESS FRAMEWORK
• Establishes the foundation for a complete software process
• Identifies a number of framework activities applicable to all software projects
• Also include a set of umbrella activities that are applicable across the entire software process.

A PROCESS FRAMEWORK comprises of :

Common process framework Umbrella activities Framework activities
Tasks, Milestones, deliverables SQA points

Software Engineering Page 7

 A PROCESS FRAMEWORK
Used as a basis for the description of process models Generic process activities
• Communication
• Planning
• Modeling
• Construction
• Deployment

A PROCESS FRAMEWORK
Generic view of engineering complimented by a number of umbrella activities
 Software project tracking and control
 Formal technical reviews
 Software quality assurance
 Software configuration management
 Document preparation and production
 Reusability management
 Measurement
 Risk management

CAPABILITY MATURITY MODEL INTEGRATION(CMMI)

• Developed by SEI(Software Engineering institute)
• Assess the process model followed by an organization and rate the organization with different levels
• A set of software engineering capabilities should be present as organizations reach different levels of
process capability and maturity.

Software Engineering Page 8

 CMMI process meta model can be represented in different ways
1.A continuous model
2.A staged model

Continuous model:
-Lets organization select specific improvement that best meet its business objectives and minimize risk-
Levels are called capability levels.
-Describes a process in 2 dimensions
-Each process area is assessed against specific goals and practices and is rated according to the
following capability levels.

CMMI
• Six levels of CMMI
– Level 0:Incomplete
– Level 1:Performed
– Level 2:Managed
– Level 3:Defined
– Level 4:Quantitatively managed
– Level 5:Optimized

CMMI
• Incomplete -Process is adhoc . Objective and goal of process areas are not known
• Performed -Goal, objective, work tasks, work products and other activities of software process are
carried out
• Managed -Activities are monitored, reviewed, evaluated and controlled
• Defined -Activities are standardized, integrated and documented
• Quantitatively Managed -Metrics and indicators are available to measure the process and quality
• Optimized - Continuous process improvement based on quantitative feed back from the user
-Use of innovative ideas and techniques, statistical quality control and other methods for process
improvement.

Software Engineering Page 9

 CMMI - Staged model
- This model is used if you have no clue of how to improve the process for quality software.
- It gives a suggestion of what things other organizations have found helpful to work first
- Levels are called maturity levels

PROCESS PATTERNS
Software Process is defined as collection of Patterns.Process pattern provides a template. It comprises of
• Process Template
-Pattern Name
-Intent
-Types
-Task pattern
- Stage pattern
-Phase Pattern
• Initial Context
• Problem
• Solution
• Resulting Context
• Related Patterns

PROCESS ASSESSMENT
Does not specify the quality of the software or whether the software will be
delivered on time or will it stand up to the user requirements. It attempts to keep a check on the current
state of the software process with the intention of improving it.
PROCESS ASSESSMENT
Software Process
Software Process Assessment Software Process improvement Motivates Capability determination
APPROACHES TO SOFTWARE ASSESSMENT
• Standard CMMI assessment (SCAMPI)
• CMM based appraisal for internal process improvement
• SPICE(ISO/IEC 15504)
• ISO 9001:2000 for software
Personal and Team Software Process
Personal software process
 PLANNING
 HIGH LEVEL DESIGN
 HIGH LEVEL DESIGN REVIEW
 DEVELOPMENT
 POSTMORTEM

Personal and Team Software Process

Team software process Goal of TSP
- Build self-directed teams
- Motivate the teams
- Acceptance of CMM level 5 behavior as normal to accelerate software process improvement
- Provide improvement guidance to high maturity organization

Software Engineering Page 10

 PROCESS MODELS

• Help in the software development

• Guide the software team through a set of framework activities
• Process Models may be linear, incremental or evolutionary

THE WATERFALL MODEL

• Used when requirements are well understood in the beginning

• Also called classic life cycle
• A systematic, sequential approach to Software development
• Begins with customer specification of Requirements and progresses through planning, modeling,
construction and deployment.

Communication
Planning
Modeling
Construction
Deployment

This Model suggests a systematic, sequential approach to SW development that begins at the system
level and progresses through analysis, design, code and testing

PROBLEMS IN WATERFALLMODEL
• Real projects rarely follow the sequential flow since they are always iterative
• The model requires requirements to be explicitly spelled out in the beginning, which is often
difficult
• A working model is not available until late in the project time plan

THE INCREMENTAL PROCESS MODEL

• Linear sequential model is not suited for projects which are iterative in nature
• Incremental model suits such projects
• Used when initial requirements are reasonably well-defined and compelling need to provide limited
functionality quickly
• Functionality expanded further in later releases
• Software is developed in increments
The Incremental Model
 Communication
 Planning
 Modeling
 Construction
 Deployment

Software Engineering Page 11

 INCREMENT 1

Communication
Planning
Modeling
Construction
Deployment

INCREMENT 2

Communication
Planning
Modeling
Construction
: Deployment
:
:
:

INCREMENT N

Communication
Planning
Modeling
Construction
Deployment

THE INCREMENTAL MODEL

• Software releases in increments
• 1st increment constitutes Core product
• Basic requirements are addressed
• Core product undergoes detailed evaluation by the customer
• As a result, plan is developed for the next increment. Plan addresses the modification of core
product to better meet the needs of customer
• Process is repeated until the complete product is produced

THE RAD (Rapid Application Development) MODEL

• An incremental software process model

• Having a short development cycle
• High-speed adoption of the waterfall model using a component based construction approach
• Creates a fully functional system within a very short span time of 60 to 90 days

Software Engineering Page 12

 The RAD Model consists of the following phases:
Communication Planning Construction
Component reuses automatic code generation testing
Modeling
Business modeling Data modeling Process modeling
Deployment integration delivery feedback

THE RAD MODEL

• Multiple software teams work in parallel on different functions
• Modeling encompasses three major phases: Business modeling, Data modeling and process
modeling
• Construction uses reusable components, automatic code generation and testing

Problems in RAD
• Requires a number of RAD teams
• Requires commitment from both developer and customer for rapid-fire completion of activities
• Requires modularity
• Not suited when technical risks are high

EVOLUTIONARY PROCESSMODEL

• Software evolves over a period of time

• Business and product requirements often change as development proceeds making a straight-line
path to an end product unrealistic
• Evolutionary models are iterative and as such are applicable to modern day applications

Software Engineering Page 13

 Types of evolutionary models
– Prototyping
– Spiral model
– Concurrent development model

PROTOTYPING

• Mock up or model( throw away version) of a software product

• Used when customer defines a set of objective but does not identify input, output, or processing
requirements
• Developer is not sure of:
– efficiency of an algorithm
adaptability of an operating system
– human/machine interaction

Communication Quick Plan

Quick Design

Build Prototype Deployment & Delivery

STEPS IN PROTOTYPING
• Begins with requirement gathering
• Identify whatever requirements are known
• Outline areas where further definition is mandatory
• A quick design occur
• Quick design leads to the construction of prototype
• Prototype is evaluated by the customer

Software Engineering Page 14

 • Requirements are refined
• Prototype is turned to satisfy the needs of customer
LIMITATIONS OF PROTOTYPING
• In a rush to get it working, overall software quality or long term maintainability are generally
overlooked
• Use of inappropriate OS or PL
• Use of inefficient algorithm

THE SPIRAL MODEL

An evolutionary model which combines the best feature of the classical life cycle and
the iterative nature of prototype model. Include new element : Risk element. Starts in middle and
continually visits the basic tasks of communication, planning, modeling, construction and deployment

THE SPIRAL MODEL

• Realistic approach to the development of large scale system and software
• Software evolves as process progresses
• Better understanding between developer and customer
• The first circuit might result in the development of a product specification

Software Engineering Page 15

 • Subsequent circuits develop a prototype
• And sophisticated version of software

THE CONCURRENT DEVELOPMENT MODEL

• Also called concurrent engineering

• Constitutes a series of framework activities, software engineering action, tasks and their associated
states
• All activities exist concurrently but reside in different states
• Applicable to all types of software development
• Event generated at one point in the process trigger transitions among the states

A FINAL COMMENT ON EVOLUTIONARY PROCESS

• Difficult in project planning
• Speed of evolution is not known
Does not focus on flexibility and extensibility (more emphasis on high quality)
• Requirement is balance between high quality and flexibility and extensibility

THE UNIFIED PROCESS

Evolved by Rumbaugh, Booch, Jacobson. Combines the best features their OO models. Adopts
additional features proposed by other experts. Resulted in Unified Modeling Language (UML). Unified
process developed Rumbaugh and Booch. A framework for Object-Oriented Software
Engineering using UML

PHASES OF UNIFIED PROCESS

• INCEPTION PHASE
• ELABORATION PHASE
• CONSTRUCTION PHASE
• TRANSITION PHASE

The Unified Process (UP)

Software Engineering Page 16

 UNIFIED PROCESS WORK PRODUCTS
Tasks which are required to be completed during different phases
1. Inception Phase
*Vision document
*Initial Use-Case model
*Initial Risk assessment
*Project Plan

2. Elaboration Phase
*Use-Case model
*Analysis model
*Software Architecture description
*Preliminary design model
*Preliminary model

3. Construction Phase
*Design model
*System components
*Test plan and procedure
*Test cases
*Manual

4. Transition Phase
*Delivered software increment
*Beta test results
*General user feedback

Software Engineering Page 17

 UNIT II
SOFTWARE REQUIREMENTS

IEEE defines Requirement as :

1. A condition or capability needed by a user to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a system or a system component to
satisfy constract, standard, specification or formally imposed document
3. A documented representation of a condition nor capability as in 1 or 2

SOFTWARE REQUIREMENTS
• Encompasses both the User’s view of the requirements( the external view ) and the Developer’s
view( inside characteristics)
User’s Requirements
--Statements in a natural language plus diagram, describing the services the system is expected to
provide and the constraints
• System Requirements --Describe the system’s function, services and operational condition

SOFTWARE REQUIREMENTS
• System Functional Requirements
--Statement of services the system should provide
--Describe the behavior in particular situations
--Defines the system reaction to particular inputs
• Nonfunctional Requirements
- Constraints on the services or functions offered by the system
--Include timing constraints, constraints on the development process and standards
--Apply to system as a whole
• Domain Requirements
--Requirements relate to specific application of the system
--Reflect characteristics and constraints of that system

FUNCTIONAL REQUIREMENTS
• Should be both complete and consistent
• Completeness
-- All services required by the user should be defined
• Consistent
-- Requirements should not have contradictory definition
• Difficult to achieve completeness and consistency for large system

NON-FUNCTIONALREQUIREMENTS

Types of Non-functional Requirements 1.Product Requirements

-Specify product behavior
-Include the following

Software Engineering Page 18

Software Engineering Page 19
 • Usability
• Efficiency
• Reliability
• Portability
2. Organizational Requirements
--Derived from policies and procedures
--Include the following:
• Delivery
• Implementation
• Standard
3. External Requirements
-- Derived from factors external to the system and its development process
--Includes the following
• Interoperability
• Ethical
• Legislative
PROBLEMS FACED USING THE NATURAL LANGUAGE
1. Lack of clarity-- Leads to misunderstanding because of ambiguity of natural language
2. Confusion-- Due to over flexibility, sometime difficult to find whether requirements are same or
distinct.
3. Amalgamation problem-- Difficult to modularize natural language requirements

STRUCTURED LANGUAGE SPECIFICATION

• Requirements are written in a standard way
• Ensures degree of uniformity
• Provide templates to specify system requirements
• Include control constructs and graphical highlighting to partition the specification

SYSTEM REQUIREMENTS STANDARD FORM

• Function
• Description
• Inputs
• Source
• Outputs
• Destination
• Action
• Precondition
• Post condition
• Side effects

Interface Specification
• Working of new system must match with the existing system
• Interface provides this capability and precisely specified

Three types of interfaces

1. Procedural interface-- Used for calling the existing programs by the new programs 2.Data structures-
-Provide data passing from one sub-system to another 3.Representations of Data
-- Ordering of bits to match with the existing system
--Most common in real-time and embedded system

Software Engineering Page 20

 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

The Software Requirements document

Suggests that there are 6 requirements that requirement document should satisfy. It should
• specify only external system behavior
• Specify constraints on the implementation.
• Be easy to change
• Serve as reference tool for system maintainers
• Record forethought about the life cycle of the system.
• Characterize acceptable responses to undesired events

Purpose of SRS
• Communication between the Customer, Analyst, system developers, maintainers,
• firm foundation for the design phase
• support system testing activities
• Support project management and control
• controlling the evolution of the system

IEEE requirements standard

Defines a generic structure for a requirements document that must be instantiated for each specific
system.
– Introduction.
– General description.
– Specific requirements.
– Appendices.
– Index.

IEEE requirements standard 1.Introduction

Purpose
Scope
Definitions, Acronyms and Abbreviations
References
Overview
2. General description
Product perspective
Product function summary
User characteristics
General constraints
Assumptions and dependencies
3. Specific Requirements
- Functional requirements

Software Engineering Page 21

 -External interface requirements
- Performance requirements
- Design constraints
- Attributes eg. security, availability, maintainability, transferability/conversion
- Other requirements
• Appendices
• Index
REQUIREMENTS ENGINEERING PROCESS
To create and maintain a system requirement document. The overall process includes four high level
requirements engineering sub-processes:
1. Feasibility study
--Concerned with assessing whether the system is useful to the business 2.Elicitation and analysis
--Discovering requirements 3.Specifications
--Converting the requirements into a standard form 4.Validation
-- Checking that the requirements actually define the system that the customer wants

SPIRAL REPRESENTATION OF REQUIREMENTSENGINEERING PROCESS

Process represented as three stage activity. Activities are organized as an iterative process around a
spiral. Early in the process, most effort will be spent on understanding high-level business and the use
requirement. Later in the outer rings, more effort will be devoted to system requirements engineering
and system modeling
Three level process consists of: 1.Requirements elicitation
2. Requirements specification
3. Requirements validation

Software Engineering Page 22

 FEASIBILITY STUDIES
Starting point of the requirements engineering process
• Input: Set of preliminary business requirements, an outline description of the system and how the
system is intended to support business processes
• Output: Feasibility report that recommends whether or not it is worth carrying out further Feasibility
report answers a number of questions:
1. Does the system contribute to the overall objective
2. Can the system be implemented using the current technology and within given cost and schedule
3. Can the system be integrated with other system which are already in place.

REQUIREMENTS ELICITATION ANALYSIS

Involves a number of people in an organization.

Stakeholder definition-- Refers to any person or group who will be affected by the system directly or
indirectly i.e. End-users, Engineers, business managers, domain experts.

Reasons why eliciting is difficult

1. Stakeholder often don’t know what they want from the computer system. 2. Stakeholder expression of
requirements in natural language is sometimes difficult to Understand.
3. Different stakeholders express requirements differently
4. Influences of political factors Change in requirements due to dynamic environments.

REQUIREMENTS ELICITATION PROCESS

Process activities
1. Requirement Discovery -- Interaction with stakeholder to collect their requirements including
domain and documentation
2. Requirements classification and organization -- Coherent clustering of requirements from
unstructured collection of requirements
3. Requirements prioritization and negotiation -- Assigning priority to requirements
--Resolves conflicting requirements through negotiation
4. Requirements documentation -- Requirements be documented and placed in the next round of spiral

Software Engineering Page 23

 The spiral representation of Requirements Engineering

REQUIEMENTS DICOVERY TECHNIQUES

1. View points --Based on the viewpoints expressed by the stake holder

--Recognizes multiple perspectives and provides a framework for discovering conflicts in the
requirements proposed by different stakeholders
Three Generic types of viewpoints
1. Interactor viewpoint--Represents people or other system that interact directly with the system
2. Indirect viewpoint--Stakeholders who influence the requirements, but don’t use the system 3.Domain
viewpoint--Requirements domain characteristics and constraints that influence the requirements.

2. Interviewing--Puts questions to stakeholders about the system that they use and the system to be
developed. Requirements are derived from the answers.
Two types of interview
– Closed interviews where the stakeholders answer a pre-defined set of questions.
– Open interviews discuss a range of issues with the stakeholders for better understanding their needs.

Software Engineering Page 24

 Effective interviewers
a) Open-minded: no pre-conceived ideas
b) Prompter: prompt the interviewee to start discussion with a question or a proposal

3. Scenarios --Easier to relate to real life examples than to abstract description. Starts with an outline of
the interaction and during elicitation, details are added to create a complete description of that
interaction
Scenario includes:
• 1. Description at the start of the scenario
• 2. Description of normal flow of the event
• 3. Description of what can go wrong and how this is handled
• 4.Information about other activities parallel to the scenario
• 5.Description of the system state when the scenario finishes

LIBSYS scenario
• Initial assumption: The user has logged on to the LIBSYS system and has located the journal
containing the copy of the article.
• Normal: The user selects the article to be copied. He or she is then prompted by the system to either
provide subscriber information for the journal or to indicate how they will pay for the article.
Alternative payment methods are by credit card or by quoting an organizational account number.
• The user is then asked to fill in a copyright form that maintains details of the transaction and they
then submit this to the LIBSYS system.
• The copyright form is checked and, if OK, the PDF version of the article is downloaded to the
LIBSYS working area on the user’s computer and the user is informed that it is available. The user is
asked to select a printer and a copy of the article is printed

LIBSYS scenario
• What can go wrong: The user may fail to fill in the copyright form correctly. In this case, the form
should be re-presented to the user for correction. If the resubmitted form is still incorrect then the user’s
request for the article is rejected.
• The payment may be rejected by the system. The user’s request for the article is rejected.
• The article download may fail. Retry until successful or the user terminates the session..
• Other activities: Simultaneous downloads of other articles.
• System state on completion: User is logged on. The downloaded article has been deleted from
LIBSYS workspace if it has been flagged as print-only.

4. Use cases -- scenario based technique for requirement elicitation. A fundamental feature of UML,
notation for describing object-oriented system models. Identifies a type of interaction and the actors
involved. Sequence diagrams are used to add information to a Use case

Article printing use-case Article printing

LIBSYS use cases Article printing Article search

User administration Supplier Catalogue services Library

Software Engineering Page 25

 User Library Staff

REQUIREMENTS VALIDATION
Concerned with showing that the requirements define the system that the customer wants. Important
because errors in requirements can lead to extensive rework cost
Validation checks
1. Validity checks --Verification that the system performs the intended function by the user 2.Consistency
check --Requirements should not conflict
3. Completeness checks --Includes requirements which define all functions and constraints intended
bythe system user
4. Realism checks --Ensures that the requirements can be actually implemented
5. Verifiability -- Testable to avoid disputes between customer and developer.

VALIDATION TECHNIQUES 1.REQUIREMENTS REVIEWS

Reviewers check the following:
(a) Verifiability: Testable
(b) Comprehensibility
(c) Traceability
(d) Adaptability 2.PROTOTYPING

3. TEST-CASE GENERATION

Requirements management
Requirements are likely to change for large software systems and as such requirements management
process is required to handle changes.
Reasons for requirements changes
(a) Diverse Users community where users have different requirements and priorities
(b) System customers and end users are different
(c) Change in the business and technical environment after installation Two classes of requirements
(a) Enduring requirements: Relatively stable requirements
(b) Volatile requirements: Likely to change during system development process or during operation

Requirements management planning

An essential first stage in requirement management process. Planning process consists of the following
1. Requirements identification -- Each requirement must have unique tag for cross reference and
traceability
2. Change management process -- Set of activities that assess the impact and cost of changes
3.Traceability policy -- A matrix showing links between requirements and other elements of software
development
4. CASE tool support --Automatic tool to improve efficiency of change management process.
Automatedtools are required for requirements storage, change management and traceability management

Traceability
Maintains three types of traceability information.
1. Source traceability--Links the requirements to the stakeholders
2. Requirements traceability--Links dependent requirements within the requirements document
3. Design traceability-- Links from the requirements to the design module

Software Engineering Page 26

 A traceability matrix Requirements change management
consists of three principal stages:
1. Problem analysis and change specification-- Process starts with a specific change proposal and
analysed to verify that it is valid
2. Change analysis and costing--Impact analysis in terms of cost, time and risks
3. Change implementation--Carrying out the changes in requirements document, system design and its
implementation

SYSTEM MODELS
Used in analysis process to develop understanding of the existing system or new system. Excludes
details. An abstraction of the system
Types of system models 1.Context models
2. Behavioural models 3.Data models 4.Object models 5.Structured models

CONTEXT MODELS
A type of architectural model. Consists of sub-systems that make up an entire system First step: To
identify the subsystem.
Represent the high level architectural model as simple block diagram
• Depict each sub system a named rectangle
• Lines between rectangles indicate associations between subsystems Disadvantages
--Concerned with system environment only, doesn't take into account other systems, which may take
data or give data to the model

The context of an ATM system consists of the following Auto-teller system

Security system Maintenance system Account data base Usage database
Branch accounting system Branch counter system

Behavioral models
Describes the overall behaviour of a system. Two types of behavioural model
1.Data Flow models 2.State machine models

Data flow models --Concentrate on the flow of data and functional transformation on that data. Show the
processing of data and its flow through a sequence of processing steps. Help analyst understand what is
going on

Software Engineering Page 27

 Advantages
-- Simple and easily understandable
-- Useful during analysis of requirements

State machine models

Describe how a system responds to internal or external events. Shows system states and events that
cause transition from one state to another. Does not show the flow of data within the system. Used for
modeling of real time systems
Exp: Microwave oven
Assumes that at any time, the system is in one of a number of possible states. Stimulus triggers a
transition from on state to another state
Disadvantage
-- Number of possible states increases rapidly for large system models

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.

Software Engineering Page 28

 Library semantic model

Data dictionary entries

Software Engineering Page | 31

 OBJECT MODELS
An object oriented approach is commonly used for interactive systems
development. Expresses the systems requirements using objects and
developing the system in an object oriented PL such as C++ A object
class: An abstraction over a set of objects that identifies common
attributes. Objects are instances of object class. Many objects may be
created from a single class.
Analysis process
-- Identifies objects and object classes Object class in UML
--Represented as a vertically oriented rectangle with three sections
(a) The name of the object class in the top section
(b) The class attributes in the middle section
(c) The operations associated with the object class are in lower section.

OBJECT MODELS INHERITANCE MODELS

A type of object oriented model which involves in object classes attributes.
Arranges classes into aninheritance hierarchy with the most general object
class at the top of hierarchy Specialized objects inherit their attributes and
services
UML notation
-- Inheritance is shown upward rather than downward
--Single Inheritance: Every object class inherits its attributes and operations from a
single parent class
--Multiple Inheritance: A class of several of several parents.

OBJECT MODELS OBJECT AGGREGATION

Some objects are grouping of other objects. An aggregate of a set of other objects.
The classes representing these objects may be modeled using an object
aggregation model A diamond shape on thesource of the link represents the
composition.

OBJECT-BEHAVIORAL MODEL
-- Shows the operations provided by the objects
-- Sequence diagram of UML can be used for behavioral modeling

Software Engineering Page | 31

Software Engineering Page | 31