Contents

Preface xi

1. Introduction 1–31
1.1 What is Software Engineering? 2
1.1.1 Program vs. Software 3
1.1.2 Characteristics of Software 3
1.2 What is Object Orientation? 6
1.2.1 Classes and Objects 6
1.2.2 Messages, Attributes and Methods 8
1.2.3 Encapsulation 8
1.2.4 Inheritance 11
1.2.5 Polymorphism 13
1.2.6 Responsibility and Abstraction 15
1.2.7 Object Composition 15
1.3 Object-Oriented Methodologies 16
1.3.1 Coad and Yourdon Methodology 16
1.3.2 Booch Methodology 17
1.3.3 Rumbaugh Methodology 19
1.3.4 Jacobson Methodology 19
1.4 Object-Oriented Modelling 20
1.5 Some Terminologies 20
1.5.1 Customers, Developers and Users 21
1.5.2 Product and Process 21
1.5.3 Actor, Use Case, Use Case Model and Use Case Scenario 21
1.5.4 System and Subsystems 21
1.5.5 Class, Responsibility and Collaboration 22
1.5.6 Measures, Metrics and Measurement 22
1.5.7 Software Quality and Reliability 22
iii
iv  Contents

1.5.8 Quality Assurance and Quality Control 23

1.5.9 Verification and Validation 23
1.5.10 Fault, Error, Bug and Failure 24
1.5.11 States and Events 24
1.5.12 Traditional Approach and Object-Oriented Approach 24
Review Questions 25
Multiple Choice Questions 26
Further Reading 31

2. Software Development Life Cycle Models 32–61

2.1 Conventional Software Life Cycle Models 32
2.1.1 Build-and-Fix Model 33
2.1.2 Waterfall Model 34
2.1.3 Prototyping Model 36
2.1.4 Iterative Enhancement Model 37
2.1.5 Spiral Model 38
2.1.6 Extreme Programming 40
2.2 Object-Oriented Software Life Cycle Models 43
2.2.1 Fountain Model 44
2.2.2 Rational Unified Process 46
2.3 Selection of Software Development Life Cycle Models 54
Review Questions 56
Multiple Choice Questions 57
Further Reading 61

3. Software Requirements Elicitation and Analysis 62–122

3.1 Case Study: Library Management System 63
3.2 What is Software Requirement? 63
3.2.1 Identification of Stakeholders 64
3.2.2 Functional and Non-functional Requirements 65
3.2.3 Known and Unknown Requirements 65
3.3 Requirements Elicitation Techniques 65
3.3.1 Interviews 66
3.3.2 Brainstorming Sessions 69
3.3.3 Facilitated Application Specification Technique 70
3.3.4 Prototyping 71
3.4 Initial Requirements Document 71
3.5 Use Case Approach 73
3.5.1 Use Cases and Actors 73
3.5.2 Identification of Actors 74
3.5.3 Identification of Use Cases 74
3.5.4 Defining Relationships between Use Cases 75
3.5.5 Use Case Diagram 76
 Contents  v
3.5.6 Use Case Description 78
3.5.7 Generation of Scenario Diagrams 80
3.5.8 Creation of Use Case Scenario Matrix 81
3.6 Characteristics of a Good Requirement 82
3.6.1 Correct 83
3.6.2 Unambiguous 83
3.6.3 Complete 83
3.6.4 Consistent 84
3.6.5 Verifiable 84
3.6.6 Modifiable 85
3.6.7 Clear 85
3.6.8 Feasible 85
3.6.9 Necessary 85
3.6.10 Understandable 85
3.7 Software Requirements Specification Document 86
3.7.1 Nature of the SRS Document 86
3.7.2 Organization of the SRS Document 86
3.8 Requirements Change Management 111
3.8.1 Is Change Necessary? 112
3.8.2 Establishment of Baseline 112
3.8.3 Requirements Traceability 112
3.8.4 Change Control 114
Review Questions 114
Multiple Choice Questions 118
Further Reading 121

4. Object-Oriented Software Estimation 123–173

4.1 Need of Object-Oriented Software Estimation 124
4.2 Lorenz and Kidd Estimation Method 124
4.3 Use Case Points Method 126
4.3.1 Classification of Actors and Use Cases 127
4.3.2 Computing Unadjusted Use Case Points 128
4.3.3 Calculating Technical Complexity Factors 128
4.3.4 Calculating Environmental Complexity Factors 129
4.3.5 Calculating Use Case Points 130
4.4 Class Point Method 134
4.4.1 Identification of Classes 135
4.4.2 Classifying Class Complexity 135
4.4.3 Calculating Unadjusted Class Points 136
4.4.4 Calculating Technical Complexity Factor 137
4.4.5 Calculating Class Point and Effort 137
4.5 Object-Oriented Function Point 140
4.5.1 Relationship between Function Points and Object Points 141
4.5.2 Counting Internal Classes, External Classes and Services 142
vi  Contents

4.5.3 Calculating Unadjusted Object Points 144

4.5.4 Adjustment Factors 145
4.6 Risk Management 146
4.6.1 What is Risk? 147
4.6.2 Framework for Managing Risks 147
4.6.3 Risk Identification 148
4.6.4 Risk Analysis and Prioritization 149
4.6.5 Risk Avoidance and Mitigation Strategies 151
4.6.6 Risk Monitoring 151
4.6.7 Estimating Risk Based on Schedule 152
Review Questions 166
Multiple Choice Questions 170
Further Reading 173

5. Object-Oriented Analysis 174–202

5.1 Structured Analysis versus Object-Oriented Analysis 174
5.2 Identification of Classes 175
5.2.1 Entity Classes 175
5.2.2 Interface Classes 176
5.2.3 Control Classes 176
5.3 Identification of Relationships 180
5.3.1 Association 180
5.3.2 Aggregation 181
5.3.3 Multiplicity 182
5.3.4 Composition 182
5.3.5 Dependency 183
5.3.6 Generalization 183
5.3.7 Modelling Relationships 184
5.4 Identifying State and Behaviour 187
5.4.1 Attributes 187
5.4.2 Operations 189
5.4.3 Example: Issue Book in LMS 190
5.5 Case Study: LMS 194
5.6 Moving Towards Object-Oriented Design 194
Review Questions 195
Multiple Choice Questions 199
Further Reading 201

6. Object-Oriented Design 203–259

6.1 What is Done in Object-Oriented Design? 203
6.2 Interaction Diagrams 204
6.3 Sequence Diagrams 205
6.3.1 Objects, Lifeline and Focus of Control 205
 Contents  vii

6.3.2 Messages 205

6.3.3 Creating Sequence Diagrams 208
6.3.4 Creating Sequence Diagram of Use Cases with Extensions 214
6.4 Collaboration Diagrams 222
6.4.1 Objects, Links and Messages 222
6.4.2 Creating Collaboration Diagrams 223
6.5 Refinement of Use Case Description 226
6.6 Refinement of Classes and Relationships 232
6.7 Identification of Operations to Reflect the Implementation Environment 232
6.8 Construction of Detailed Class Diagram 234
6.9 Development of Detailed Design and Creation
of Software Design Document 234
6.10 Generating Test Cases from Use Cases 238
6.10.1 Commonly Used Testing Terminology 238
6.10.2 Deriving Test Cases from Use Cases: A Five-Step Process 239
6.11 Object-Oriented Design Principles for Improving Software Quality 244
Review Questions 254
Multiple Choice Questions 256
Further Reading 258

7. Moving Towards Implementation 260–286

7.1 Activity Diagrams 260
7.1.1 Activities and Transitions 261
7.1.2 Branching 262
7.1.3 Modelling Concurrency 262
7.1.4 Using Swimlanes 263
7.1.5 Uses of Activity Diagrams 265
7.2 Statechart Diagrams 268
7.2.1 States and State Transition 269
7.2.2 Event, Action and Guard Condition 270
7.2.3 Modelling Life Cycle of an Object 271
7.2.4 Creating Substates 272
7.3 Storing Persistent Data in Database 275
7.3.1 Mapping Entity Classes to Database Tables 276
7.3.2 Representing Inheritance in Tables 277
7.4 Implementing the Classes 280
7.4.1 Good Programming Practices 281
7.4.2 Coding Standards 281
7.4.3 Refactoring 282
7.4.4 Reusability 282
Review Questions 282
Multiple Choice Questions 284
Further Reading 286
viii  Contents

8. Software Quality and Metrics 287–347

8.1 What is Software Quality? 287
8.1.1 Software Quality Attributes 288
8.1.2 Elements of a Quality System 289
8.2 Software Quality Models 296
8.2.1 McCall’s Software Quality Model 296
8.2.2 Boehm’s Software Quality Model 297
8.2.3 ISO 9000 299
8.2.4 ISO 9126 300
8.2.5 Capability Maturity Model 301
8.3 Measurement Basics 303
8.3.1 What are Software Metrics? 304
8.3.2 Application Areas of Metrics 304
8.3.3 Categories of Metrics 305
8.3.4 Measurement Scale 307
8.3.5 Axiomatic Evaluation of Metrics on Weyuker’s Properties 308
8.4 Analysing the Metric Data 310
8.4.1 Summary Statistics for Preexamining Data 310
8.4.2 Metric Data Distribution 312
8.4.3 Outlier Analysis 313
8.4.4 Correlation Analysis 319
8.4.5 Exploring Analysis 319
8.5 Metrics for Measuring Size and Structure 320
8.5.1 Size Estimation 320
8.5.2 Halstead Software Science Metrics 321
8.5.3 Information Flow Metrics 324
8.6 Measuring Software Quality 324
8.6.1 Software Quality Metrics Based on Defects 324
8.6.2 Usability Metrics 326
8.6.3 Testing Metrics 327
8.7 Object-Oriented Metrics 328
8.7.1 Coupling Metrics 328
8.7.2 Cohesion Metrics 331
8.7.3 Inheritance Metrics 334
8.7.4 Reuse Metrics 335
8.7.5 Size Metrics 338
8.7.6 Popular Metric Suites 338
Review Questions 340
Multiple Choice Questions 343
Further Reading 346
 Contents  ix

9. Software Testing 348–413

9.1 What is Software Testing? 348
9.1.1 Verification 349
9.1.2 Validation 349
9.2 Software Verification Techniques 349
9.2.1 Peer Reviews 350
9.2.2 Walkthroughs 350
9.2.3 Inspections 350
9.3 Checklist: A Popular Verification Tool 352
9.3.1 SRS Document Checklist 352
9.3.2 Object-Oriented Analysis Checklist 354
9.3.3 Object-Oriented Design Checklist 355
9.4 Functional Testing 356
9.4.1 Boundary Value Analysis 356
9.4.2 Equivalence Class Testing 370
9.4.3 Decision Table-Based Testing 380
9.5 Structural Testing 385
9.5.1 Path Testing 385
9.6 Class Testing 393
9.7 State-Based Testing 395
9.7.1 Design of Test Cases 396
9.8 Mutation Testing 397
9.8.1 Mutation Testing and Mutants 398
9.8.2 Mutation Operators 400
9.8.3 Mutation Score 401
9.9 Levels of Testing 403
9.9.1 Unit Testing 403
9.9.2 Integration Testing 404
9.9.3 System Testing 404
9.9.4 Acceptance Testing 405
9.10 Software Testing Tools 405
9.10.1 Static Testing Tools 405
9.10.2 Dynamic Testing Tools 406
9.10.3 Process Management Tools 406
Review Questions 407
Multiple Choice Questions 409
Further Reading 412

10. Software Maintenance 414–434

10.1 What is Software Maintenance? 414
10.2 Categories of Software Maintenance 415
10.2.1 Corrective Maintenance 415
10.2.2 Adaptive Maintenance 415
x  Contents

10.2.3 Perfective Maintenance 416

10.2.4 Other Types of Maintenance Activities 416
10.3 Challenges of Software Maintenance 417
10.3.1 High Staff Turnover 417
10.3.2 Flexible Nature of Software 417
10.3.3 Poor Documentation and Manuals 418
10.3.4 Inadequate Budgetary Provisions 418
10.3.5 Emergency Fixing of Bugs 418
10.4 Maintenance of Object-Oriented Software 418
10.5 Software Rejuvenation 421
10.5.1 Reverse Engineering 421
10.5.2 Software Re-engineering 422
10.5.3 Redocumentation and Restructuring 423
10.6 Estimation of Maintenance Effort 424
10.6.1 Belady and Lehman Model 424
10.6.2 Boehm Model 425
10.7 Configuration Management 426
10.7.1 Configuration Identification 427
10.7.2 Configuration Control 427
10.7.3 Configuration Accounting 428
10.8 Regression Testing 428
Review Questions 430
Multiple Choice Questions 431
Further Reading 433

Appendix 435–467
References 469–472
Answers to Multiple Choice Questions 473–474
Index 475–479
Preface

The complexity, criticality and size of the software is increasing every day, and resulting in
a situation where the traditional approaches to software development may not be effectively
applicable. In the traditional approaches, there is a difficulty to produce reusable and low-cost
maintainable software. The popular approach to address such situations can be addressed using
object-oriented paradigm. Hence, the software industry is shifting towards development of
software using object-oriented concepts and practices at each phase of software development,
and object-oriented software engineering has emerged as a separate and important discipline.
Object-oriented software engineering emphasizes visual modelling based on real-world objects
and entities. Modelling helps in understanding the problems, developing proper documents and
producing well-designed programs. Modelling produces well-understood requirements, robust
designs, and high-quality and maintainable systems. The models must depict the various views
of the system and these models must be verified to check whether they capture the customer’s
requirements. In this book, we have used Unified Modelling Language (UML) notations for
constructing various models at various stages of object-oriented software development.
The worldwide universities and software industries have started realizing the importance of
object-oriented software engineering. Most of the universities are now offering a full course on
object-oriented software engineering for their undergraduate and postgraduate students in the
disciplines of computer science and engineering, software engineering, computer applications,
and information technology.
The book focuses on object-oriented software engineering in the context of an overall effort
to present object-oriented concepts, techniques and models that can be applied in software
estimation, analysis, design, testing and quality improvement. This book is designed for use as a
main textbook for a course in object-oriented software engineering and object-oriented analysis
and design, and as a useful resource for academicians and software practitioners.
The book is the result of our several years of experience of classroom teaching. It consists
of numerous solved examples, chapter-end review questions, multiple choice questions and case
studies. The concepts and the models explained and developed in this book are demonstrated
using a real-life case study of library management system (LMS).
xi
xii  Preface

The main features of this book are as follows:

 It focuses on the basic concepts, need and importance of object-oriented paradigm. It
presents the origin and benefits of visual modelling. The basic object-oriented software
methodologies are also given.
 It presents traditional and object-oriented software development life cycle models with a
special focus on Rational Unified Process model.
 It presents requirements gathering techniques and proposes the development of Initial
Requirement Document (IRD). These techniques may help to gather requirements
effectively and efficiently in the early phases of software development.
 It introduces object-oriented software estimation techniques which can be used in
practice in order to measure the effort of object-oriented software. It addresses important
issues of risk management, and two techniques for risk estimation such as Critical Path
Method and PERT are explained.
 It presents object-oriented analysis and explains the types of classes, their relationships
and structure using Unified Modelling Language (UML) notations.
 It presents object-oriented design including construction of sequence and collaboration
diagram as part of design activity. The development of detailed design of classes and
identification of operations from sequence diagram is also explained. It promotes the use
of use case testing, for generating test cases from use cases.
 It presents activity diagrams and statechart diagrams which are used to model dynamic
aspects of the system. These models will help the developers to better understand the
system under development.
 It addresses important issues of improving software quality and measuring various
object-oriented constructs using object-oriented metrics. In addition, the techniques for
cleaning and analysing the metric data are also explained.
 It signifies the importance of object-oriented testing and maintenance of software
developed using object-oriented software engineering techniques and methods.
We do acknowledge the significance of feedback of our readers for enriching the contents of
the book. We are waiting for microscopic analysis and critical assessment of the contents of the
book. Any suggestion for addition, deletion and modification shall be considered positively for
the improvement of the book. Every feedback will motivate us to work hard for the next edition
for our beloved readers. Till then goodbye!

Yogesh Singh
Ruchika Malhotra
 1
Introduction

The world has seen many inventions and discoveries in the last 250 years. Which one has affected
our civilization the most? Electricity may be the answer. It has become the reason for many
applications and comforts. After electricity, what is next? It may be computer and software.
Numerous applications are developed and more and more are in the line to change our way of
life. Social networking websites like Facebook, Twitter, etc., research scholar platforms like
Google Scholar, and email service providing websites like Hotmail, Gmail, Rediffmail, etc. are
adding various dimensions to our life. We cannot think of a day without using Internet, without
using cell phone, without using laptop for various activities, etc. Software is a driving force for
such applications. We may see a large number of software applications with more features and
versatility in coming times.
The size and complexity of software are increasing day by day. Conventional approaches
of software design and implementation may not be effectively applicable. To handle a large
size software development project, we may require different approaches, skill sets, tools and
mindsets. We have seen this in civil engineering where constructing a house in a 250 m2
plot requires different approaches and tools than constructing a 50-storeyed building. House
and multi-storeyed building constructions are handled differently by the architects, structural
engineers and civil contractors. The same analogy is valid for software development where
a large size software project requires more thorough and systematic approaches. We want to
simplify the development process and produce high-quality maintainable software. As we all
know, development may take a few years and the same may have to be maintained for many
years. A maintainable software may reduce the maintenance cost and high quality may enhance
the sustainability of the software.
The necessity of developing and maintaining a large size, complex and varied functionalities
software system has forced us to look for new approaches of software design and development.
The conventional approaches like “waterfall model” may not be very useful due to non-availability
of iterations, no provision of reuse and difficulty in incorporating changing requirements. We
1
2  Object-Oriented Software Engineering

may also build every software system from the scratch that results into a costly software system
including very high maintenance cost. An object-oriented paradigm may address such issues. It
is becoming popular to design, develop and maintain large size, complex and critical software
systems using the object-oriented paradigm. Due to its popularity and acceptability in customers,
companies are also releasing the object-oriented versions of their existing software products.
Many of the customers expect object-oriented software solutions and request the same for their
forthcoming projects.
In this chapter, a framework of object-oriented software engineering is given. The object-
oriented concepts are introduced and explained. The object-oriented methodologies are discussed
and key terms are defined.

1.1 What is Software Engineering?

The dependency on software is increasing every day and its correct operation is becoming a real
challenge for automated modern civilization. In order to handle this challenge, we must have
sound engineering principles and processes to produce a good quality software product and
such software should also be maintainable. There are two words ‘software’ and ‘engineering’.
Engineering forces us to focus on systematic, scientific and well-defined processes to produce
a good quality product. The early years’ debate on “whether software development is an
engineering discipline?” is over now. We all have realized that survival is not possible if it is not
taken as an engineering discipline. Engineering activities expect to produce proper documents
after every stage of software development. The development should be carried out as per well-
documented standards and guidelines and should be completed within time and within budget.
The same is expected in software development and all certifying agencies like SEI-CMM, ISO,
etc. are directing us to document all processes and produce meaningful documentation after
every stage of software development.
The term ‘software engineering’ was coined at the first conference on software engineering
held in 1968 where Fritz et al. (1968) defined software engineering as:
The establishment and use of sound engineering principles in order to obtain economically
developed software that is reliable and works efficiently on real machines.
IEEE Computer Society’s software engineering body of knowledge defines software engineering
as (Abren et al., 2004):
The application of a systematic, disciplined, quantifiable approach to the development, operation
and maintenance of software, and the study of these approaches, that is, the application of
engineering to software.
Wikipedia, the free encyclopedia has also defined software engineering as (Wikipedia 2010):
It is a profession dedicated to designing, implementing, and modifying software so that it is of
higher quality, more affordable, maintainable, and faster to build.
All the above definitions are popular and find places in software engineering literature and
practices. Our objective is to deliver good quality software to the customer and at a low cost.
The software engineering discipline helps us to achieve this objective and also increases the
probability of survival of the software during operation and maintenance.
 Introduction  3

1.1.1 Program vs. Software

Most of the times, we use these two terms, software and program interchangeably. Generally, we
say “write a program” and “develop a software”. How are these terms different? Are these terms
related? Program is a set of instructions written for a specific purpose. It may contain comment
instructions (statements) to enhance the readability and understandability of a program.
However, software is a combination of program(s), documentation (documents produced
during development) and operating procedure manuals (delivered with programs to the customer
at the time of release). Hence, a software project of any reasonable size and functionalities should
have associated documentations and operating procedure manuals. The various parts of software
are shown in Figure 1.1.

Figure 1.1 Parts of software.

We may produce many documents during software development. These documents are
used not only during software development but also for maintaining the software. Some of the
documents are given as:
(i) Software requirements and specification document
(ii) Software design document
(iii) Test plan document
(iv) Test suite document
(v) Source code
Operating procedure manuals are prepared to help the customer to install, operate and maintain
the software. They are delivered along with program(s) at the time of release. Some of the
operating procedure manuals are given as:
(i) Installation manual
(ii) System administration manual
(iii) Beginner’s guide tutorial
(iv) System overview
(v) Reference guide

1.1.2 Characteristics of Software

The software is different from other products in terms of its special characteristic that it does
not wear out. If it works correctly for a set of inputs in the specified environment, it is expected
4  Object-Oriented Software Engineering

to work in the same way after many years for the same set of inputs and environment. Some of
the important characteristics of software are discussed here.

Software Does Not Wear Out

There is no concept of ‘aging’ in software. Hardware parts of any product (say automobile) start
malfunctioning after the specified time due to aging of various parts. The same is true for every
hardware product. If we draw a graph between failure rate and time, we get a curve which is
similar to ‘bath tub’ and is known as bath tub curve. The curve has three phases, namely, burn-in
phase, useful life phase and wear-out phase as shown in Figure 1.2.

Figure 1.2 Bath tub curve.

In the initial phase (burn-in phase), the failure rate is high. When we start testing the product,
we detect faults. These faults are corrected which results into a drop in the failure rate. However,
the drop may stabilize after certain time of testing and the curve becomes stable. This is the end
of initial phase (burn-in phase) which is expected to be performed in the company itself. Hence,
after the completion, the product is released to the customer. The second phase where the failure
rate is more or less constant is called useful life of any product. After the completion of the
useful life phase, the failure rate again increases due to the effects of environmental conditions
(like temperature, humidity, pressure, etc.), rains dusts and rusting on various parts of product.
This means, various parts begin to wear out. This phase is called wear-out phase.
We do not have the wear-out phase in software. The curve for software is shown in
Figure 1.3.
As the testing progresses, many failures are experienced and the required corrective actions
are performed to remove faults. Hence, the software becomes reliable over time instead of wearing
out. It may become obsolete due to other reasons but not because of wear-out. Some of such
reasons are change in technologies, change in expectations, poor response time, deterioration in
the structure of the source code, complexity issues, etc.
 Introduction  5

Figure 1.3 Software curve.

Flexibility of Software
Flexibility of software may create confusion in stakeholders. They may feel that this unique
characteristic is a real strength of a software product in terms of making changes, incorporating
new functionalities, modifying source code and managing complexity. This confusion has
enhanced the expectation of stakeholders and propagated the theory of “any change possible at
any time without much difficulty”. A stakeholder is a person who is having direct or indirect
interest in the software system, including customers, software developers, managers, users,
testers and so on. As we all know, it is easy to modify the source code but it is very difficult to
manage the effect of changes in other parts of the source code. Addition of new functionality
at later stages always makes the life difficult for software developers. Many times, developers
may make compromises in terms of quality to accommodate the requests of changes. However,
making changes in software is easier as compared to hardware and such changes must be made
after proper study and analysis of its impact on other parts of the source code.

Reusability of Software
The concept of reusability of components is used in almost all disciplines of engineering. If
we have to manufacture a computer under a brand name of our company, we may purchase
monitor, keyboard, motherboard, microprocessor, switched-mode power supply (SMPS), etc.
from the market. We may also manufacture a few components, say cabinet, mouse, UPS, few I/O
cards, universal serial port, etc. in our company. Finally, we integrate all the components as per
specified design and guidelines, and test the product as per the testing standards. The product is
then released to the market under the brand name of the respective manufacturing companies.
We do not manufacture every component in the company. We purchase those components from
the market (like motherboard, UPS, SMPS, etc.) and reuse those components for manufacturing
of computers. The reusable components are very common and popular in practice and also
reduce the time and cost of manufacturing although maintaining the quality standards.
6  Object-Oriented Software Engineering

In software companies, most of the projects are developed for specific customers. Every
customer has unique requirements and expectations. The concept of reusability is rarely used
and that has resulted into the development of costly software with prolonged development
time. Reusability is the process of integrating the already built well-tested components in the
new software under development. By reusing the existing source code, the development effort
and cost of development and testing are reduced. Some attempts have been made in terms of
Microsoft Foundation Classes (MFC), Commercially off-the-shelf (COTS) components with a
very limited applicability. More effort is required to standardize the design principles, guidelines
and interfaces of COTS components. Reusability has introduced an emerging area of study
and that is known as “component-based-software-engineering (CBSE)”. Many popular COTS
components use the concept of object-oriented analysis and design to make it an independent
piece of software which can easily be plugged into other software to make an effective, reliable
and efficient software for its customers. The object-oriented concepts may fulfil the long-standing
desire of software engineering to produce libraries of standard software components which can
easily be integrated in order to produce a good quality product in time and within budget. It is a
very powerful and significant concept of object-oriented paradigm.

1.2 What is Object Orientation?

Why is object-oriented software development taking centre stage in software industry? Why is
object-oriented version of existing software products coming in the market? Some of us also
believe that conventional approaches of software engineering are old fashioned and shall not
be able to meet today’s challenges. We also feel that the real strength of the object-oriented
approach is its modelling ability to represent real-world situations. A model helps us to visualize
and understand a real situation along with its behaviour. Architects use models to demonstrate
their conceptual constructs which may also increase the confidence of their clients in terms of
design, aesthetics and feel of the proposed project. In object-oriented approaches, real-world
situations are effectively represented at any level of abstraction with a few basic building blocks
like objects, classes, messages, interfaces, inheritance and polymorphism.

1.2.1 Classes and Objects

Objects are the fundamental entities which are used to model any system. Anything and
everything may become an object. It is like a packet containing data and operations. All objects
have unique identification and are also distinguishable. Suppose there are 10 books in a library
of the same subject, language, publisher and author; but these books are distinguishable due
to their own title and accession number. All objects have unique identification like accession
number in case of a book in the library. In a library, book, student, faculty, employee, etc. are
the examples of objects. An object has attributes (information/state) and operations (behaviour).
The objects of the same attributes and operations are combined to form a class. All objects are
the instances of a class. A class defines the structure of the objects which include attributes
and operations. An object is assigned to them and it behaves like a structure of C and record of
Pascal programming language. A class ‘book’ is given in Figure 1.4 with eight attributes and
four operations along with its implementation in C++ language.
 Introduction  7

Figure 1.4 Class book with its C++ implementation.

A class represents a group of similar objects. There are three parts of a class as shown in
Figure 1.4. The first part consists of the name of the class, the second part consists of all the
attributes (or information) and the third part has all the operations (or behaviour). The source
code of book class is also shown in Figure 1.4. The access specifiers (private and public) are used
to specify the visibility of data and operations to the other objects. The private data/operations
will not be available to the outside world. Only the operations of the class can access this data,
whereas public data/operations are available to other classes. In class book, the data is declared
as private and the operations are declared as public. This supports the concept of data hiding.
The book class provides controlled access to its data attributes. In C++, three access specifiers—
private, public and protected—are used. If no access specifier is specified, then by default all the
members of the class are private.
A class has a name, list of attributes and operations. Jacobson et al. (1999) have defined a
class as:
A class represents a template for several objects and describes how these objects are structured
internally. Objects of the same class have the same definition both for their operations and for
their information structures.

In the object-oriented system, every object belongs to a class and is known as instance of
that class. An object is also defined by Jacobson et al. (1999) as:
8  Object-Oriented Software Engineering

An instance is an object created from a class. The class describes the (behaviour and information)
structure of the instance, while the current state of the instance is defined by the operations
performed on the instance.

For example, a book class may have many objects like software engineering book, software
testing book, software quality book, etc. as shown in Figure 1.5. As shown in C++ implementation
in Figure 1.5, the objects can be created in the same way as the variables are declared. For
example, the variables are declared as:
int x;
char str;
The objects can be declared as:
Book SE;
Each object has its own copy of attributes and operations as shown in Figure 1.5.

1.2.2 Messages, Attributes and Methods

In order to show the dynamic behaviour of any system, the objects are required to communicate
with each other by passing messages. A message is a request for performing an operation by any
object of the system. A message may consist of the identification of the target object, operation to
be performed and data to perform the request as shown in Figure 1.6. An object which generates
the message is called the sender and the object which receives a message can be sent to other
objects and to the object itself to perform an operation.
An attribute is the data of the class. Each class should define the attributes that store the
state of an object. For example, in the previous section, the book class contains eight attributes
accessiono, subjectdescriptor, ISBN, booktitle, language, authorfname, authorlname and
publisher. All these attributes are declared as private, which implies that they cannot be accessed
outside the class and are only available to the operations of the class book.
A method is the sequence of steps (or a set of operations) to be performed to complete the
designated work. There may be many methods available for the accomplishment of any work. It
is the responsibility of the receiver to select an appropriate method to fulfil the work efficiently.
In Figure 1.5, four methods addbook(), deletebook(), updatebook() and viewbook() are available
for the book class. In order to add a book in the database, addbook() method should be invoked.
The words methods, functions and operations are used interchangeably in the object-oriented
systems.

1.2.3 Encapsulation
Encapsulation is also known as information hiding concept. The data and operations are
combined into a single unit. The only way to access data is through operations which are
designed to operate on the data. The data is not available to the external world. This concept
may make the data safe and secure from external interventions. Accidental modifications from
the outside world are not possible as shown in Figure 1.7. If the data of any object is required
to be modified, it is possible through the specified functions. This process of encapsulating the
 Introduction  9

Figure 1.5 Instances of class book.

data and operations into a single unit simplifies the activities of writing, modifying, debugging
and maintaining the program.
The availability of data only for specified operations limits the scope of data and this may
help us to minimize the impact of any change in the program. In the class book of library
management system, all the attributes are private and only the operations can access the attributes
(see Figure 1.4). The private attributes are not accessible to the outside world. Thus, the private
10  Object-Oriented Software Engineering

Figure 1.6 Interactions of objects.

Figure 1.7 Data and operations are combined in a unit.

part in the implementation is hidden from the users. The outside world can only interact with the
class book through public interfaces, i.e. the operations. If we need to interact with the operation
addbook( ) the following syntax is used:

Book b1;
b1. addbook( );

In Wikipedia, encapsulation is defined as:

It means that the internal representation of an object is generally hidden from view outside
of the object’s definition. Typically, only the object’s own methods can directly inspect or
manipulate its field.

The encapsulation concept enhances the security and makes the program more maintainable and
sustainable.
 Introduction  11

1.2.4 Inheritance
Inheritance is a very important feature of object-oriented systems. When we define a class,
we may find common attributes and operations amongst the classes. In a library management
system, we may define classes like student, faculty and employee. All these classes have many
common attributes (say memberID, name, date of birth, phone, email, etc.) and operations (say
addmember(), deletemember()). The common characteristics can be extracted and a new class
“member” may be created with common attributes and operations. The member class contains
attributes and operations which are common to all three classes, namely, student, faculty and
employee as shown in Figure 1.8.

Figure 1.8 Member class with three subclasses student, faculty and employee.

The member class is called the base class and other classes are called subclasses. The
subclasses inherit the attributes and operations of the base class and have their own behaviour.
Every subclass may have specific attributes (like rollno and school in the case of student base
class) and operations which are not available to other subclasses of the same base class. This
type of specialization–generalization relationship is known as ‘is-a’ relationship. The C++
implementation is given in Figure 1.9.
12  Object-Oriented Software Engineering

class Member
{
private:
long int memberID;
char photograph [300];
char name[50];
char fname [50];
Date DOB;
long int phone;
char email [60];
Date memberdate;
Date validupto;

public:
addmember();
deletemember();
updatemember();
viewmember();
};

class employee : public Member //publicly derived class

{
long int employeeID;
char branch[60];
};

class faculty : public Member //public inheritance

{
long int facultyID;
char school[100];
};

class student : public Member //public inheritance

{
long int rollno;
char school[100];
char programme[100];
};
Figure 1.9 C++ implementation of class member with three subclasses.

All the attributes and operations of a base class become the part of its subclasses and we
may say that a subclass inherits the base class. If any change is made in the base class, that
will be equally applicable to all its subclasses. Inheritance property also helps to remove the
redundant information from the classes. This may reduce the size of the classes and they may
become easier to understand. In Figure 1.8, the class student inherits the class member and the
class student is called the derived the class and class member is called the base class. Inheritance
allows the developer to reuse a class and also modify the classes as per requirements with
minimizing their side effects into the rest of the class.
 Introduction  13

1.2.5 Polymorphism
The dictionary meaning of polymorphism is “many forms”. If we give an instruction to many
objects across classes, the objects’ responses may be different. For example, human, animal, bird,
etc. are subclasses of mammal class. When we give an instruction “come fast” to all mammals,
their responses will be different. Animals may run, birds may fly and humans may walk or take
an automobile in response to the given instruction. This concept is called polymorphism, where
the same instruction is given to many objects across the classes, but responses of objects may be
different. Objects interact with each other by sending messages. A sending object may not know
the class of a receiving object. Jacobson et al. (1999) have rightly said that:
Polymorphism means that the sender of a stimulus (message) does not need to know the receiving
instance’s class. The receiving instance can belong to an arbitrary class.

Polymorphism can be achieved through function overriding. For example, consider the
media class with two operations read and show. The publication media need to read and display
different attributes such as the number of pages and publisher, whereas videotapes also need
to read and display different attributes such as time. Thus, the class publication and the class
videotapes override the operations read and show of the base class media and provide their own
read and show operations. Function overriding involves replacement of the same operation in
the base class with the one in the derived class. An object of the derived class refers to its own
function if the same function is defined in its base class. The example is shown in Figure 1.10
and its C++ implementation is given in Figure 1.11.

Figure 1.10 Example of function overriding.

The read and show operations in media class are overridden by the operations in publication
and videotapes derived class. The read and show operations in the publication class read and
display their own specific attribute pages and pub in addition to the attributes in the base class.
Similarly, read and show operations in the videotapes class read and display their own specific
attribute time in addition to the attributes in the base class media. Thus, the same message is
sent to the media classes, and their behaviour is different depending upon which subclass of
media is used.
14  Object-Oriented Software Engineering

class media
{
private:
char title[MAX];
float price;
public:
void read()
{
cout<<”\n\tEnter title:”;
cin>>title;
cout<<”\n\n\tEnter price:”;
cin>>price;
}
virtual void show()
{
cout<<”\n\n\tTitle: ”<<title;
cout<<”\n\n\tPrice: ”<<price;
}
};
class publication : public media //Class to display information about books
{
private:
int pages;
char pub[MAX];
public:
void read()
{
media::read();
cout<<”\n\n\tEnter publication: ”;
cin>>pub;
cout<<”\n\n\tEnter number of pages:”;
cin>>pages;
getch();
}
void show()
{
media::show();
cout<<”\n\n\tPublication: ”<<pub;
cout<<”\n\n\tPages:”<<pages;
}
};
class videotapes:public media //Class to display information about videotapes
{
private:
int time;
public:
void read()
{
media::read();
cout<<”\n\n\tEnter time in seconds”;
cin>>time;
}
void show()
{
media::show();
cout<<”\n\n\tTime: ”<<time;
}
};
Figure 1.11 C++ implementation of classes in Figure 1.10.
 Introduction  15
When the object of the derived classes publication and videotapes will be created, the read
and show methods included in the derived classes will be called instead of the read and show
methods included in the base class media shown as follows:

publication p1;
p1.read(); //read method defined in publication class will be called instead of read
//method defined in media class

The concept of polymorphism is frequently used in object-oriented programming languages

like C++ and Java. An operator ‘+’ is used for the purpose of addition and in Boolean, the same
operator is used for logical ‘OR’ operation. Hence, the same operator has two (many) forms. We
also know that arithmetic operators like +, -, *, etc. are used on primary data types (int float) and
the same may be used in user-defined data types (objects) and is called operator overloading. An
operator may have many forms depending on its usage in the programming language.

1.2.6 Responsibility and Abstraction

Every object has responsibilities which are associated with its behaviour. In order to execute a
request, a receiver object decides a method out of a set of available methods. The selection of an
appropriate method is the responsibility of the receiver object. Hence, objects behave and work
which is a very important characteristic for solving any complex problem. The complexity may
also be managed using right level of abstraction. An abstraction is the elimination of irrelevant
and the amplification of the essential details. We learn driving a car without knowing the
internal details of the engine, batteries, control system, etc. The details may not be required
to know for a learner and may create unnecessary confusion. Hence, abstraction may improve
the understanding of the system. All complex details are not relevant for everyone. Levels of
abstraction may vary in different situations. We only show the necessary details which may
improve the understandability. We perform most of our works by knowing only the essential
details. We work on computers without knowing the architecture of motherboard and other
peripheral devices. These details are not required for any normal user. If we have to improve
the design of the motherboard, obviously, details of architectural design are important but not
otherwise. Such details are required only by the motherboard designers and not by the users.
Hence, the right level of abstraction is the key to success in all situations.

1.2.7 Object Composition

The use of objects as data members in another class is referred to as object composition. The
object is a collection of a set of objects represented through ‘has-a’ relationship. In object-oriented
systems, has-a relationship depicts that an object is declared as an attribute in another class. For
example, a CPU has-a motherboard, memory chip, CD-ROM and so on. In inheritance, there
is ‘is-a’ relationship between the base class and the derived class. In Figure 1.12, an example of
object composition between two classes along with their C++ implementation is shown. Class
B has-a member Oa of type class A. Thus, the object of type class A is used as data member in
class B.
16  Object-Oriented Software Engineering

Figure 1.12 Object composition.

1.3 Object-Oriented Methodologies

Methodology is a set of methods and principles that signify a systematic way of developing a
system using tools, techniques, processes and procedures. As a result of increase in keen interest
in object-oriented techniques, several object-oriented methodologies have been developed in the
literature. These methodologies include:
 Object-oriented analysis by Coad and Yourdon
 Object-oriented design by Booch
 Object modelling technique by Rumbaugh et al.
 Object-oriented software engineering by Jacobson et al.
Each methodology is discussed in the next subsections.

1.3.1 Coad and Yourdon Methodology

Coad and Yourdon’s methodology is popularly known as Object-Oriented Analysis (OOA) (Coad
and Yourdon, 1990). It was developed in the late 1980s. In OOA, an analysis model is developed
and it consists of five steps:
1. Identification of classes and objects
2. Identification of structures
3. Definition of subjects
4. Definition of attributes
5. Definition of services (methods)
Identification of classes and objects involves investigating the application domain and the
system’s environment. The behaviour of each object is found and this information is documented.
Identification of structures involves identification of is-a and whole-part relationships. The is-a
relationship captures class inheritance (known as Gen-Spec structure) and the the whole-part
relationship captures the information about how an object is a part of another object. Each
structure is classified into a subject. Attributes are the data members of the class. The attributes
for each object are defined and kept at the appropriate level in the inheritance hierarchy.
Defining services involves identification of operations in a class. This also involves identification
of interfaces amongst the objects through messages. Each message may contain parameters for
communication. The graphical notation of the analysis model is shown in Figure 1.13.
 Introduction  17

Figure 1.13 Coad and Yourdon’s methodology.

In the OOA methodology, there is no systematic way to identify classes and objects. The
interfaces are also not determined in this methodology.

1.3.2 Booch Methodology

Grady Booch proposed object-oriented methodology in his book Object-Oriented Design (OOD)
in 1991 (Booch, 1991). The primary aim of OOD was to establish a base for the implementation
of object-oriented systems. The Booch methodology considered identification of interfaces
at various levels. The main concern of the Booch methodology is the iterative process and
creativity of designer in order to develop OOD. The Booch methodology follows and incremental
and iterative life cycle. It combines analysis, design an implementation and provides a sound
object-oriented software engineering process for analysts, designers and developers. The Booch
methodology can be broadly divided into two processes: macro process and micro process.

Macro Process
It is a high-level process that describes the activities to be followed by the development team
throughout the life cycle as shown in Figure 1.14.
18  Object-Oriented Software Engineering

Figure 1.14 Macro process of Booch methodology.

In the first phase, the requirements are established using context diagrams and prototypes.
The outcomes of this phase are core requirements of the system. The analysis process involves
requirement capturing and understanding. It involves “what of the system”. This phase consists
of construction of use cases, identification and prioritization of risks. The design phase focuses
on the construction of architecture of the system and involves:
 Identifying horizontal layers
 Mapping classes to subsystems
 Release planning
 Attaching risks identified in the analysis phase to releases
The evolutionary phase involves implementation of the system and each release adds to the
functionality of the system. The maintenance phase consists of post-deployment activities.

Micro Process
It is the lower level process. The following recursive steps are followed in OOD micro process:
1. Identification of classes and objects
2. Identification of semantics of classes and objects
3. Identification of relationship amongst classes and objects
4. Specification of interfaces and implementation of classes and objects
Identification of classes and objects involves finding of classes and objects at specific level
of abstraction. The second step identifies the semantics of the classes and objects by finding
the meaning of the classes and objects in terms of attributes and operations. It also involves
determining the use of an object by another object. Identification of relationship involves
the process of determining the interaction amongst the classes and objects. The relationships
identified include inheritance, uses and instance of. The last step involves specification
of interface amongst classes and objects and their implementation. It identifies data type of
attributes and signature of operations.
In this methodology, no formal notations for constructing visual diagrams are given.
 Introduction  19

1.3.3 Rumbaugh Methodology

Rumbaugh developed a technique that focuses on analysis, design and implementation of the
system. This technique is popularly known as Object Modelling Technique (OMT) (Rumbaugh
et al., 1990). The OMT consists of four phases: analysis, system design, object design and
implementation.
 Analysis phase: Analysis phase is composed of three submodels given below:
1. Object model: It captures the static aspect of the system.
2. Dynamic model: It captures the behavioural aspects of the object models and
describes state of the objects.
3. Functional model: It represents the functional aspects of the system in terms of
operations defined in the classes.
In the object model, the requirements are stated in the problem statement. The relevant
classes along with inheritance relationships are extracted from this problem statement.
The dynamic model identifies states and events in the classes identified in object models.
The functional model depicts the functionality of the system by creating data flow
diagrams of the system in order to understand the processes (in the form of input and
output information).
 System design phase: In this phase, a high-level design is developed taking the
implementation environment including DBMS and communication protocols into
account.
 Object design phase: The goal of this phase is to define the objects in detail. The
algorithms and operations of the objects are defined in this phase. New objects may be
identified to represent the intermediate functionality.
 Implementation phase: Finally, the objects are implemented following coding
standards and guidelines.

1.3.4 Jacobson Methodology

All the methodologies described above still lack a comprehensive architecture to develop a
software project. The Jacobson’s methodology known as Object-Oriented Software Engineering
(OOSE) consists of five models (Jacobson et al., 1999):
1. The requirement model: The aim of this model is to gather software requirements.
2. The analysis model: The goal of this model is to produce ideal, robust and modifiable
structure of an object.
3. The design model: It refines the objects keeping the implementation environment in
mind.
4. The implementation model: It implements the objects.
5. The test model: The goal of the test model is to validate and verify the functionality of
the system.
20  Object-Oriented Software Engineering

The requirement model focuses on capturing functionality of the system through use cases and
actors and determining the interfaces amongst the use cases. In the analysis model, an ideal model
is developed while not considering the implementation environment. It involves the identification
of interface objects, database-related objects (entity objects) and objects representing control
between interface and database-related objects (control objects). The objects are grouped into
subsystems. In the design model the objects identified in the analysis model, are refined to the
actual implementation environment. These objects are called blocks. These blocks are converted
into modules in the implementation model and finally the modules are integrated and tested in
the test model.
All the methods discussed above have their own advantages and disadvantages. The OOA
method lacks the design of interfaces and notations. The OOD method is stronger in design but
weaker in analysis of the system. The OMT method is stronger in analysis part but weaker in
design part. The Jacobson’s methodology is stronger in behavioural areas as compared to the
other areas (Quatrani, 2003).

1.4 Object-Oriented Modelling

Object-oriented modelling is a way of constructing visual models based on real-world objects.
Modelling helps in understanding the problems, developing proper documents and producing
well-designed programs. Modelling produces well-understood requirements, robust designs, and
high-quality maintainable systems. The models must depict the various views of the system and
these models must be verified to check whether they capture the customer’s requirements. After
they represent the required details, these models may be transformed into source code. Due to
the increase in object-oriented techniques and complexity of the software, various challenges are
faced by the system designers. Modelling helps to visualize, organize, document and understand
complex relationships, and to produce well-designed systems.
As discussed in the previous section, three most popular methodologies were OOD (Booch),
OMT (Rumbaugh) and OOSE (Jacobson). All these methods are combined into the Unified
Modelling Language (UML). Thus, the UML represents the combination of the notations used
by Booch, Rumbaugh and Jacobson. The best concepts and processes were extracted from all the
methodologies till date and combined into UML. The UML was adopted by Object Management
Group (OMG) in November 1997.
The UML is defined as a language for visual modelling that allows to specify, visualize,
construct, understand and document the various artifacts of the system (Rumbaugh et al. 2004).
UML models the static and dynamic aspects of the system. The static aspect of the system
models the objects and relationship amongst these objects. The dynamic aspect of the system
models the events and states used for interaction amongst objects over time. Thus, modelling the
system from different aspects allows us to obtain a clear understanding of the system.

1.5 Some Terminologies

Some terminologies which are frequently used in object-oriented software engineering are
discussed in this section.
 Introduction  21

1.5.1 Customers, Developers and Users

Customers are persons who request the system, approve the system and pay for the system.
Developers are the persons at the supplier side who are responsible for the development of the
system. Users are the persons who actually use the system.
For example, in the library management system developed for a university, the customer is
the university, the developer is the one at the supplier side who develops the system and the users
are the persons in the library staff who will actually work on the system.

1.5.2 Product and Process

Product is what is delivered to the customer. It may include software requirement specification
(SRS) document, source code, test reports, user manuals and system guide.
Process is the way in which the software is produced. A process is like a tunnel through
which the project goes in order to produce a product as shown in Figure 1.15. It consists of a set
of activities that are combined to produce a product. An effective process is required to produce
a high-quality maintainable product.

Figure 1.15 Process and product.

1.5.3 Actor, Use Case, Use Case Model and Use Case Scenario
An actor represents the role of a user that interacts with the system. Some of the examples of
the actors used in “Library Management System” are administrator, data entry operator, student,
library staff and faculty.
A use case describes who (any user) does what (interaction) with the system, for what goal,
without considering the internal details of the system. A complete set of use cases explains the
various ways to use the system. The use case model depicts actors, use cases and the relationship
between them.
A use case scenario is an instance of a use case or a complete path through the use case. The
basic flow is one scenario and every alternative path gives another scenario.

1.5.4 System and Subsystems

A system is an organized and arranged structure as a whole that consists of interrelated and
well-defined procedures, processes and methods. All systems consist of inputs, outputs, feedback
mechanisms and boundaries.
The system may consist of several subsystems. Subsystems are a way of reducing complexity
of the system. For example, in a company, accounts, sales, marketing, etc. are different
subsystems. In object-oriented analysis, objects may be grouped together to form a subsystem.
22  Object-Oriented Software Engineering

1.5.5 Class, Responsibility and Collaboration

A class is a template that consists of attributes and operations. Responsibilities are attributes and
operations included in a class. Collaborations are the other classes that a class calls in order to
achieve the functionality.
The class, responsibility and collaboration are often combined together in object-oriented
analysis to depict the functionality of a class and the relationship between classes.

1.5.6 Measures, Metrics and Measurement

These terms are often used interchangeably. However, we should understand the difference
amongst these terms. Pressman (2005) explained this clearly as:
A measure provides a quantitative indication of the extent, amount, dimension, capacity or size
of some attributes of a product or process. Measurement is the act of determining a measure.
The metric is a quantitative measure of the degree to which a product or process possesses a
given attribute.

For example, a measure is the number of failures experienced during testing. Measurement is
the way of recording such failures. A software metric may be an average number of failures
experienced per hour during testing.
Fenton and Pfleeger (2004) have defined measurement as:
It is the process by which numbers or symbols are assigned to attributes of entities in the real
world in such a way as to describe them according to clearly defined rules.

Software metrics can be defined by Goodman (1993) as:

The continuous application of measurement-based techniques to the software development
process and its products to supply meaningful and timely management information, together
with the use of those techniques to improve that process and its products.

1.5.7 Software Quality and Reliability

Software reliability is one of the important factors of software quality. Other factors are
understandability, completeness, portability, consistency, maintainability, usability, efficiency,
etc. These quality factors are known as non-functional requirements for a software.
Software reliability is defined as “the probability of failure free operation for a specified
time in a specified environment” (ANSI, 1991). Although software reliability is defined as a
probabilistic function and comes with the notion of time, still it is not a direct function of time.
The software does not wear out like the hardware during the software development life cycle.
There is no aging concept in software and it will change only when we intentionally change or
upgrade the software.
Software quality determines how good the software designed is (quality of design), and how
good the software conforms to that design (quality of conformance).
Some software practitioners also feel that quality and reliability are the same thing. If we
are testing a program till it is stable, reliable and dependable, we are assuring a high-quality
 Introduction  23
product. Unfortunately, that is not necessarily true. Reliability is just one part of quality. To
produce a good quality product, a software tester must verify and validate throughout the
software development process.

1.5.8 Quality Assurance and Quality Control

The purpose of quality assurance (QA) activity is to enforce standards and techniques to improve
the development process and prevent the previous bugs from ever occurring. A good QA activity
enforces good software engineering practices which help to produce good quality software. The
QA group monitors and guides throughout the software development life cycle. This is a defect-
prevention technique and concentrates on the process of the software development. Examples are
reviews, audits, etc.
Quality control attempts to build a software and test it thoroughly. If failures are experienced,
remove the causes of failures and ensure the correctness of removal. It concentrates on specific
products rather than processes as in the case of QA. This is a defect-detection and correction
activity which is usually done after the completion of the software development. Example is
software testing at various levels.

1.5.9 Verification and Validation

These terms are used interchangeably and some of us may also feel that both are synonyms.
The Institute of Electrical and Electronics Engineers (IEEE) has given definitions which are
largely accepted by software testing community. Verification is a static activity often related to
static testing which is performed manually. We only inspect and review the document. However,
validation is a dynamic activity and requires the execution of the program.
Verification: As per IEEE (2001), “It is the process of evaluating the system or component to
determine whether the products of a given development phase satisfy the conditions imposed at
the start of that phase”. We apply verification activities from the early phases of the software
development and check/review the documents generated after the completion of each phase.
Hence, it is the process of reviewing the requirement document, design document, source code
and other related documents of the project. This is a manual testing and involves only looking at
the documents in order to ensure what comes out is that we expected to get.
Validation: As per IEEE (2001), “It is the process of evaluating a system or component during
or at the end of development process to determine whether it satisfies the specified requirements”.
It requires the actual execution of the program. It is a dynamic testing and requires computer for
execution of the program. Here, we experience failures and identify the causes of such failures.
Hence, testing includes both verification and validation. Thus,
Testing = Verification + Validation
Both are essential and complementary activities of software testing. If an effective verification is
carried out, it may minimize the need of validation and more number of errors may be detected
in the earlier phases of the software development. Unfortunately, primarily the validation-
oriented activity is followed while testing a software product.
24  Object-Oriented Software Engineering

1.5.10 Fault, Error, Bug and Failure

All these terms are used interchangeably, although the terms error, mistake and defect are
synonyms in software testing terminology. When we make an error during coding, we call this
‘bug’. Hence, error/mistake/defect in coding is called a bug.
A fault is the representation of an error, where the representation is the mode of expression,
such as data flow diagrams, entity-relationship (ER) diagrams, source code, use cases, etc. If the
fault is in the source code, we call it a bug.
A failure is the result of execution of a fault and is dynamic in nature. When the expected
output does not match with the observed output, we experience a failure. The program has to
execute for a failure to occur. A fault may lead to many failures. A particular fault may cause
different failures, depending on the inputs to the program.

1.5.11 States and Events

A state is an abstract situation in the life cycle of an entity that occurs in response to occurrence
of some event. An event is an input (a message or method call). Due to the occurrence of some
event, the system transits from one state to the other.

1.5.12 Traditional Approach and Object-Oriented Approach

A conventional approach is a function-centric approach where data is not given importance,
whereas an object-oriented approach is a data-centric approach where data and operations are
grouped into a single unit. In today’s world, the paradigm is being shifted towards object-oriented
systems. The summary of differences between a traditional approach and an object-oriented
approach is given in Table 1.1.

Table 1.1 Comparison between traditional and object-oriented approaches

S. No. Traditional approach Object-oriented approach
1 The system is viewed as a collection of processes. The system is viewed as a collection of objects.
2 Data flow diagrams, ER diagrams, data UML models including use case diagram,
dictionary and structured charts are used to class diagram, sequence diagrams, component
describe the system. diagrams, etc. are used to describe the system.
3 Reusable source code may not be produced. The aim is to produce reusable source code.
4 Data flow diagrams depicts the processes and Classes are used to describe attributes and
attributes. functions that operate on these attributes.
5 It follows a top-down approach for modelling the It follows a bottom-up approach for modelling
system. the system.
6 It is non-iterative. It is highly iterative.

Object-oriented software engineering is an upcoming area of research, practice and

industrial applications. All companies are making the processes compliant to object-oriented
paradigm. Developers are focusing these learning processes on object-oriented concepts and
programming languages like C++, Java, etc. Customers are also changing their mindsets towards
object-oriented software products.
 Introduction  25

Review Questions
1. What is software engineering? What is the aim of software engineering?
2. Describe the characteristics of software. How are the characteristics of software different
from those of hardware?
3. Explain the difference between program and software. What is the importance of
producing documents and operating manuals in software development?
4. Software does not wear out. Comment.
5. Give the characteristics of an object-oriented system. What are the main advantages of
object-oriented software development?
6. Describe attributes and operations with respect to an object with relevant example.
7. (a) What is object orientation? How is it close to real-life situations? Explain the basic
concepts which help us to model a real-life situation.
(b) Describe the following terms:
(i) Messages
(ii) Methods
(iii) Responsibility
(iv) Abstraction
8. (a) How is object-oriented software development different from traditional software
development?
(b) Discuss the following terms:
(i) Object
(ii) Class
(iii) Message
(iv) Inheritance
(v) Polymorphism
9. What is modelling? Explain how modelling can play an important role in designing a
system.
10. Explain the requirement and analysis model in the Jacobson methodology.
11. Compare and contrast the object-oriented methodology of Booch, Rumbaugh and
Jacobson.
12. Explain the macro and micro process of the Booch methodology.
13. Mention the models in the analysis phase of the Rumbaugh methodology and explain
their roles for describing the system.
14. Explain the following:
(a) Object modelling technique
(b) Object composition with an example
15. Give a brief description of the characteristics of object-oriented modelling.
16. Explain object model, dynamic model and functional model.
26  Object-Oriented Software Engineering

17. What is UML? Explain the objectives of modelling.

18. Differentiate between the following:
(a) Measure and metrics
(b) Program and software
(c) Verification and validation
(d) Object-oriented and structural approach
(e) Class and object
(f) Customer and user
(g) System and subsystem
(h) Fault, bug and failure
19. Define the following terms with examples:
(a) Class and object
(b) Polymorphism
(c) Object composition
(d) Inheritance
(e) Encapsulation
(f) Customer and user
20. Consider a result management system of a university. Identify the objects, classes,
attributes and methods. Give C++ code for all of them.

Multiple Choice Questions

Note: Select the most appropriate answer of the following questions:
1. Software engineering focuses on producing:
(a) Good quality product (b) Defect-free product
(c) High performance product (d) Reusable product
2. Software consists of:
(a) Programs
(b) Programs and documentations
(c) Set of instructions and operating system
(d) Programs, documentations and operating procedure manuals
3. Operating manuals help to:
(a) Understand the software (b) Operate the software
(c) Maintain the software (d) All of the above
4. Which is not a part of operating procedure manuals?
(a) Installation guide (b) Reference guide
(c) Test plan (d) System administration manual
5. Which of the following is not a part of documentations?
(a) Software requirement specification document
(b) System overview
(c) Test plan
(d) Source code
 Introduction  27
6. Which one is not a characteristic of software?
(a) Software does not wear out (b) Software is not flexible
(c) Software is enhanceable (d) Software is reusable
7. The full form of COTS is:
(a) Commercially off-the-shift components
(b) Commercially off-the-shelf classes
(c) Components off-the-shelf
(d) Commercially off-the-shelf components
8. Stakeholders consist of:
(a) Developers (b) Management
(c) Users (d) All of the above
9. The use of components promotes the concept of:
(a) Flexibility (b) Reusability
(c) Invisibility (d) Conformity
10. A class has:
(a) Attributes and operations (b) Attributes and states
(c) Operations and behaviour (d) State and information
11. An object is defined as:
(a) Information of a class (b) Instance of a class
(c) Attribute of a class (d) Operation of a class
12. The objects of the same class have:
(a) Different definitions for operations and information
(b) Same definition for operations and information
(c) Different operations
(d) Different formats
13. A class inherits information from
(a) Descendant classes (b) Same class
(c) Ancestor classes (d) Descendant and ancestor classes
14. Encapsulation is known as:
(a) Data sharing concept (b) Data retrieval concept
(c) Data hiding concept (d) Data transfer concept
15. A method is:
(a) The sequence of steps to be performed to fulfil the assigned task
(b) The set of operations for a particular task
(c) Both (a) and (b)
(d) None of the above
16. The literal meaning of polymorphism is:
(a) Few forms (b) Many forms
(c) No form (d) Different things with the same meaning
28  Object-Oriented Software Engineering

17. Function overriding is a type of:

(a) Encapsulation (b) Inheritance
(c) Polymorphism (d) Reusability
18. Abstraction is:
(a) Elimination of relevant details
(b) Elimination of irrelevant details
(c) Getting distracted by thoughts
(d) Reducing the understanding of the system
19. Object composition refers to:
(a) Use of object of one class as data type in another class
(b) Derived class inheriting attributes and operations from the base class
(c) Polymorphism
(d) Data hiding concept
20. Object-oriented methodologies include:
(a) Coad and Yourdon methodology (b) Booch methodology
(c) Rumbaugh methodology (d) All of the above
21. Object-oriented methodologies do not include:
(a) Coad and Yourdon methodology (b) Jacobson methodology
(c) Boehm methodology (d) Rumbaugh methodology
22. A class inherits data and operations from its:
(a) Subclass (b) Superclass
(c) Derived class (d) All of the above
23. What is encapsulation?
(a) Enforcement of data hiding concept
(b) Division of a module into submodules
(c) Including data members within a class
(d) Including operations within a class
24. What is the importance of data hiding?
(a) Preventing data from intentional modifications
(b) Making data available in correct format
(c) Preventing data from accidental modifications
(d) None of the above
25. What are the benefits of inheritance?
(a) Lowers the number of lines of code
(b) Lowers effort
(c) Removes redundancy
(d) All of the above
26. What is the relationship between a class A and another class B which includes the object
of type class A as its attribute?
(a) has-a (b) is-a
(c) uses-a (d) includes-a
 Introduction  29
27. Generalization and specialization relationship between two classes is known as:
(a) has-a relationship (b) uses-a relationship
(c) is-a relationship (d) includes-a relationship
28. The Booch methodology can be broadly divided into:
(a) Micro process and major process (b) Macro process and minor process
(c) Macro process and micro process (d) Macro process and mini process
29. The Rumbaugh methodology is popularly known as:
(a) Object method technique (b) Object-oriented design
(c) Object modelling technology (d) Object modelling technique
30. The analysis phase of the OMT method consists of:
(a) Class model, static model, functional model
(b) Object model, dynamic model, functional model
(c) Object model, static model, functional model
(d) Object model, static model, dynamic model
31. OOSE stands for:
(a) Object-oriented system engineering
(b) Object-oriented system evolution
(c) Object-oriented software evolution
(d) Object-oriented software engineering
32. The Jacobson methodology is popularly known as:
(a) Object modelling technique (b) Object-oriented software engineering
(c) Object-oriented design (d) Object-oriented analysis and design
33. Which of the following objects are identified in the analysis model?
(i) Analysis objects (ii) Entity objects
(iii) Control objects (iv) Interface objects
(a) (i), (iii), (iv)
(b) (i), (ii), (iv)
(c) (ii), (iii), (iv)
(d) All of the above
34. OMT stands for:
(a) Object modelling technique (b) Oriented modelling technique
(c) Object modelling technology (d) Object mobile technique
35. The Jacobson methodology is:
(a) Stronger in analysis part and weaker in design part
(b) Stronger in design part and weaker in analysis part
(c) Stronger in behavioural areas and weaker in other areas
(d) Stronger in both design and analysis part
36. Object-oriented modelling produces:
(a) Robust design (b) High-quality software
(c) Well-understood requirements (d) All of the above
30  Object-Oriented Software Engineering

37. UML combines methodologies given by:

(a) Rumbaugh and Jacobson (b) Rumbaugh and Booch
(c) Booch and Jacobson (d) Booch, Rumbaugh and Jacobson
38. Which one of the following is true?
(a) Customers are persons who approve and pay for the system and users are persons
who use the system
(b) Users are persons who approve and pay for the system and customers are persons
who use the system
(c) Customers are persons who develop the system and users are persons who use the
system
(d) Customers are persons who develop and use the system
39. Process is:
(a) The way in which software documents are developed
(b) The way in which software is produced
(c) The end product
(d) The procedure to measure the progress of the software
40. Use case scenario depicts:
(a) Functionality of the use case (b) Internal details of the use case
(c) Path of the use case (d) None of the above
41. What is a software metric?
(a) An ISO property
(b) Quantitative measure of the degree to which a product or process possesses a given
attribute
(c) Qualitative measure of the degree to which a product or process possesses a given
attribute
(d) Indication of the extent, amount or size of some attributes of a product or process
42. Software validation is also known as:
(a) Dynamic testing (b) Source code design
(c) Alpha testing (d) Static testing
43. Verification activities come under the category of:
(a) Dynamic testing (b) Source code design
(c) Alpha testing (d) Static testing
44. Which of the following is not a factor of software quality?
(a) Reliability (b) Maintainability
(c) Usability (d) Invisibility
45. A bug is a:
(a) Fault in source code (b) Fault in design
(c) Fault in requirement (d) Similar to fault
46. UML is related to:
(a) Object-oriented concepts (b) Operation-oriented concepts
(c) Procedure-oriented concepts (d) All of the above
 Introduction  31
47. CMM certification is related to:
(a) Product (b) Process
(c) Capability of a developer (d) Capability of a company
48. Reliability is related to:
(a) Objects (b) Classes
(c) Failures (d) Operations
49. Testing is related to:
(a) Verification (b) Validation
(c) Both (a) and (b) (d) None of the above
50. Object-oriented approach is:
(a) Non-iterative (b) Iterative
(c) Highly iterative (d) None of the above

Further Reading
A good number of concepts of software engineering are explained in the following books:
Pressman, R., Software Engineering: A Practitioner’s Approach. New York: Tata-McGraw-Hill,
2005.
Somerville, I., Software Engineering. Reading, MA: Addison-Wesley, 2004.
The object-oriented concepts are effectively addressed in:
Korson, T., and McGregor, J., Understanding object oriented: A unifying paradigm.
Communications of the ACM, 33(9), September 1990.
The basic concepts of object-oriented programming in a language-independent manner are
presented in:
Budd, T., An Introduction to Object-Oriented Programming. Pearson Education, India, 1997.
The definitions of object, class, inheritance and aggregation may be read from:
Berard, Edward V., Basic Object-Oriented Concepts, http://www.ipipan.gda.pl/~marek/objects/
TOA/oobasics/oobasics.html
The overview of object-oriented software engineering methodologies is presented in:
Jacobson, I.V. Object Oriented Software Engineering: A Use Case Driven Approach. New Delhi:
Pearson Education, 1999.
Some of the useful facts about software may be found in:
Glass, R.L., Facts and Fallacies of Software Engineering. Pearson Education, 2003.
The details about the methodologies described in this chapter can be obtained from:
Coad, P., and Yourdon, E., Object-Oriented Analysis, 2nd ed. Englewood Cliffs, NJ: Prentice-
Hall, 1990.
Jacobson, I.V., et al., Object Oriented Software Engineering. Pearson Education, 1999.
Booch, G., Object-Oriented Design with Applications. Redwood City, CA: Benjamin-Cummings,
1991.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W., Object-Oriented Modelling
and Design. Englewood Cliffs, NJ: Prentice-Hall, 1990.
 2
Software Development
Life Cycle Models

When we decide to develop a software product, many initial questions focusing on the need of
the software come into our mind, such as “Would it be better to electronically generate mark
sheets?,” or “Is there any market for the word processing system?,” or “Is it economically viable
if we electronically generate payroll of an employee?”. Once the needs are determined, the
software goes through a series of phases of development. These phases include analysis, design,
implementation, testing, maintenance and retirement. The software remains useful between the
analysis and maintenance phases and ends with the retirement phase. The period from which a
software development process starts till the retirement phase is known as life cycle of the software.
The life cycle period of one software differs from that of another. The software development
life cycle (SDLC) models depict the procedure used for development of the software in its life
cycle. A number of software development life cycle models are available in literature and are
based on the methods and techniques used for developing and maintaining the software. In
this chapter, we describe a variety of software development life cycle models. The three widely
used models are described which include waterfall model, prototyping model and iterative
enhancement model. We also present spiral model which has received attention in past few years.
In addition, an emerging model extreme programming is introduced. Finally, two object-oriented
software development models (fountain model and rational unified process model) are discussed.

2.1 Conventional Software Life Cycle Models

In software engineering, the conventional software development life cycle models are based on
methodology followed in the basic model popularly known as “waterfall” model. The software
32
 Software Development Life Cycle Models  33
development life cycle is generally viewed in terms of functions or processes. The software is
developed using functional decomposition techniques and the design is implemented in terms of
functions or operations. The final software is seen primarily in terms of functions or modules.
More importance is given to modules or functions as compared to data. A top-down analysis and
design methodology are followed. The methodologies used in conventional software development
life cycle for requirement analysis, design and implementation are shown in Figure 2.1.

Figure 2.1 Methodologies used in conventional software development life cycle.

In the next subsections, we describe six popular conventional software development life
cycle models.

2.1.1 Build-and-Fix Model

Some projects are built without conducting analysis and design. The product is simply built and
tested again and again until the customer’s needs are satisfied. This approach is termed build-
and-fix model and is shown in Figure 2.2.

Figure 2.2 Build-and-fix model.

The build-and-fix model may work well on small programs of approximately 50–200 lines
of source code, but it is not suitable for reasonable sized programs. The cost of correcting defects
increases exponentially if the defect is detected in the later phases of software development.
Hence, the cost of fixing defects of the program developed using build-and-fix model is higher
34  Object-Oriented Software Engineering

as compared to the cost of defect correction in any program which is developed using any
other specified software development life cycle model. The maintenance of the software also
becomes very difficult without any requirement or design documents. In addition, the source
code is modified a number of times using ad hoc build-and-fix approach which makes the
source code poorly structured and unenhancable after some period of time. Many a time even
a well-developed program does not match the customer’s requirements and thus is not useful
for the customer. This necessitates the need of effective requirement analysis phase before the
development of the source code. Hence, a mature approach must be followed and a life cycle
model with pre-defined phases such as requirement analysis, design, implementation, testing,
and maintenance must be selected.

2.1.2 Waterfall Model

A disciplined and organized approach for software development is used in waterfall model and
is shown in Figure 2.3. It has five phases: requirement analysis, design, implementation and unit
testing, integration and testing, and deployment and maintenance. The phases are completed in
sequential order and do not overlap with each other. Each phase defines its own set of functions
that are distinct from those of the other phases. Each phase should be completed before the
commencement of the next phase. The output from one phase goes as input into the next phase.
The relationship between phases is explained in Rovce (1970) as:
The ordering of steps is based on the following concept: that as each step progresses and the
design is further detailed, there is an iteration with the preceding and succeeding steps but
rarely with the more remote steps in the sequence. The virtue of all of this is that as the design
proceeds the change process is scoped down to manageable limits. At any point in the design
process after the requirements analysis is completed there exists a firm and closeup, moving
baseline to which to return in the event of unforeseen design difficulties.

Figure 2.3 Waterfall model.

 Software Development Life Cycle Models  35
The waterfall model begins with the requirement analysis phase which describes “what”
of a system. This phase gathers requirements from the customer. At the end of the requirement
analysis phase, software requirement specification (SRS) document and software project plan
are produced. The SRS document may act as a contract between the customer and the developer.
After this phase, the requirements are freezed. In the design phase, the software requirement
specifications given in the requirement analysis phase are transformed into design structure that
is suitable for implementation in a specified programming language. The design of the software
describes “how” of the system. The design phase first constructs the preliminary design and then
the detailed design. The software design description document and initial test plan are produced
at the end of the design phase.
During the implementation phase, the design is transformed into source code. In unit
testing, the small modules are tested in isolation and the overhead code is written for handling
communication amongst these modules. After implementation and unit testing, the modules
are integrated to form a complete system. Integration and testing are carried out to verify
the functioning of the software. Testing guarantees the functioning of the system as a whole.
Testing is an essential and expensive activity that ensures that a software with high quality,
lower maintenance costs and greater accuracy and reliability is delivered to the customer. After
adequate testing, the software is given to the customer for acceptance testing. The deliverables of
integration and testing phase are test plans, test cases and test results. Finally, if the software is
developed as per the customer’s requirement, then it is delivered to the customer and installed at
the customer’s site. Thus, the software goes into the deployment and maintenance phase. Software
maintenance is a very crucial activity that involves defect correction, quality improvements,
enhancements and changes. The operating manuals including user manuals and system guides
are outcome of this phase.
The advantages of the waterfall model include its simplicity, ease of understandability
and distinct phases with their own set of functions. It is highly suitable for the projects where
requirements are completely known in the beginning of the project. The waterfall model has the
following disadvantages:
1. A large number of documents are produced. The customer may not understand the
formal terminologies and notations used in these documents. The software is built on
the basis of written document that the customer may have partially understood.
2. It freezes the requirement at the end of the requirement analysis phase. The requirements
may not be well understood by the customer and the developer at the beginning. Thus, it
is unrealistic to determine all the requirements at the start of the project itself.
3. The customer does not get the opportunity to see the working product until late after the
implementation and testing is completed. The customer may find the software different
than what he/she actually wanted.
4. It may take years to complete the project, and at that point, technology may become old
and obsolete or the customer’s expectations may change.
5. Testing the system as a whole becomes difficult.
6. Real-life projects are rarely sequential.
7. This approach is particularly not useful in the case of interactive user application.
36  Object-Oriented Software Engineering

One of the disadvantages of the waterfall model is overcome by building prototypes to determine
the customer’s needs. The prototyping model is described next.

2.1.3 Prototyping Model

In prototyping model, a working prototype is constructed in order to determine and understand
the customer’s needs. The customer evaluates this prototype and then the final SRS document
is prepared on the basis of refined requirements. The prototyping model is shown in Figure 2.4.
Since the prototype will finally be discarded, it need not be flexible, maintainable and fault
tolerant.

Figure 2.4 Prototyping model.

A throwaway prototype is developed which undergoes design, coding and testing but these
phases are not carried out thoroughly and rigorously. The throwaway prototype is discarded
once the requirements are determined and the final system is developed from the scratch. This
prototype is generally built quickly to give the customer the feel of the system.
During the requirement analysis phase a “quick and dirty” prototype is constructed and
given to the customer to obtain feedback in order to determine the necessary and correct
requirements. The user interfaces are also validated. After obtaining the customer feedback,
 Software Development Life Cycle Models  37
the prototype is refined until the requirements are stabilized/finalized. After the requirements
have been determined, the prototype is thrown away. The final SRS document is prepared which
serves as input to the next phase similar to that of the waterfall model.
The advantages of the prototyping model are as follows:
1. Stable requirements: Requirements are stabilized by refining the prototype again
and again based on the customer’s feedback. Thus, the probability of change in the
requirements after developing the final SRS will be minimized.
2. High-quality system: The quality of the system will be high as the developers and
customers have gained a lot of experience while constructing the prototype.
3. Low cost: The cost of the actual system will be reduced.
The disadvantages of the prototyping model are that the customer may expect quick delivery of
the software, and the time for development may exceed in some cases.

2.1.4 Iterative Enhancement Model

In the waterfall model, the product is delivered after the completion of implementation and
testing phases. This problem of the waterfall model is overcome in the iterative enhancement
model. The iterative enhancement model combines the advantages of both the waterfall model
and the prototyping model. This model is recommended and discussed in Basili and Turner
(1975). The phases in the iterative enhancement model are the same as in the waterfall model,
but they are carried out in many cycles. A usable product is delivered at the end of each cycle.
This allows obtaining the customer’s feedback after each cycle. As the product is developed in
increments, the testing of the product also becomes easy.
In the requirement analysis phase, the requirements are gathered from the customers.
Customers and developers prioritize the requirements. Developers implement these requirements
in various cycles based on their priorities. A project control list is created consisting of a set
of tasks to be completed before the final delivery of the product. The project control list also
keeps track of the required work that needs to be completed before the system is ready for final
deployment.
The iterative enhancement model is shown in Figure 2.5. The model delivers an operational
product that partially satisfies the customer’s requirements at the end of each cycle, where each
cycle provides an additional functionality. The complete product is delivered after many releases
(see Figure 2.5). The iterative process is carried out till all the requirements of the control list
are implemented.
The iterative enhancement model broadly consists of three iterative phases—design,
implementation and analysis by customer. After the requirement analysis, these phases are
carried out repeatedly until complete functionality is delivered to the customer. After the final
release, the system goes into the maintenance phase as shown in Figure 2.5.
The iterative enhancement model allows to accommodate changing requirements and
adds new features to the software during each phase. Unlike the waterfall model, the iterative
process carried through various cycles permits the customer to see the progress of the software
continuously. This model is particularly useful when the partial portion of the software is to be
quickly delivered to the customer.
38  Object-Oriented Software Engineering

Figure 2.5 Iterative enhancement model.

In the iterative enhancement model, the later software increments may require modifications
in earlier ones which may increase costs.

2.1.5 Spiral Model

Spiral model is developed by Barry W. Boehm in 1986. The spiral model is a risk-driven model
that deals with uncertainty of the outcome of an activity. Risk measures the combined effect of
probability of occurrence of failure and the impact of that failure on the software operation. The
failure may be defined in terms of cost and schedule overrun, low quality, occurrence of defects,
programmatic risks, etc. High risk activities may cause threat to the project. The spiral model
incorporates “risk assessment” into the life cycle phases and is shown in Figure 2.6.
The radial dimension in Figure 2.6 shows the cumulative cost of the project and the angular
dimension shows the progress made in the completion of the final software. The spiral model is
divided into four phases: determine objectives, alternatives and constraints; evaluate alternatives,
identify and resolve risks; develop and verify next-level product; and plan next phases. Each
cycle of the spiral model begins with identification of objectives (functional and non-functional
requirements, etc.), determination of alternative means of implementing the specified part of
the product (design 1, design 2, reuse, buy, component, etc.) and identification of constraints
imposed on the completion of the portion of the product (resources, cost, schedule, etc.).
The next phase is to evaluate the alternatives in order to identify the significant project
risks. This includes identification of means to resolve the risks. This may apply risk resolution
techniques like prototyping, customer interviews, modelling, etc. The third phase involves the
development of next-level prototype by addressing all the major risk-related issues. When all
 Software Development Life Cycle Models  39

Figure 2.6 Spiral model.

the performance, development and interface-related risks are resolved, the waterfall approach
is followed incrementally in the next steps which includes concept of operations, software
requirements, software design, implementation and testing. Each level incorporates validation of
the activities by conducting reviews and preparing various plans for the next cycle.
The spiral model repeats the four phases to the following rounds as shown in Figure 2.6:
Round 0: Feasibility study
As recommended by Boehm (1986), the initial round 0 must be carried out in order to determine
the feasibility of the system in terms of resources, cost, schedule and productivity.
Round 1: Concept of operation
The output of this round is a basic requirement of the life cycle plan for the implementation of
the concepts emerged till now.
Round 2: Top-level requirements analysis
In this round, the requirements are specified and validated following the risk-driven approach.
The output produced is the development plan.
Round 3: Software design
A preliminary design is created, verified and validated. Integration and test plan is produced
after the completion of round 3.
40  Object-Oriented Software Engineering

Round 4: Design, implementation and testing

Round 4 constructs the detailed design of the product. This includes coding, unit testing,
integration testing and acceptance testing.
The spiral model incorporates validation and verification steps in order to reduce risks and
defects in early phases of software development. Thus, it embeds software quality in the life
cycle. The spiral model has some disadvantages that include lack of expertise to determine and
resolve risks and it is applicable only to large-sized projects. Sometimes the cost of performing
risk analysis may overweigh the returns of the spiral model.

2.1.6 Extreme Programming

Extreme programming (XP) project started in the middle of the 1990s. XP is based on the
principles of agile processes. Agile means the ability to move quickly and easily. The agile
process is both quick and easy. Agile processes are based on team cohesiveness, quick feedbacks,
incremental development, experienced developers and automated testing. The key features of
agile processes are shown in Figure 2.7.

Figure 2.7 Key features of agile processes.

The rules followed in the agile processes are given as follows:

 Team cohesiveness and the way in which a team works are given more importance than
any process.
 The customer (a domain expert) is always a part of the team and makes decisions related
to deadlines.
 Requirement changes are accepted unlike the traditional approaches where the
requirement specification was assumed to be rigid and complete.
 A working software is produced very early and shown to the customer within a few
weeks of development.
 The progress is measured by how much of the working software has been built rather
than by documents.
 Software Development Life Cycle Models  41

 Iterative planning is done instead of iterative development followed in traditional models.

Plans are changed based on the learned processes.
 Distributed leadership is a key feature of agile processes. Decisions are not taken by only
the project manager as done by traditional strategies of team build-up.
XP follows the methodology of agile processes and focuses on customer satisfaction. It
emphasizes on continuous customer involvement and testing. The importance of an XP case is
effectively given by Wake (2002) as:
Extreme programming (XP) is a new, lightweight approach to developing software. XP uses
rapid feedback and high-bandwidth communication to maximize delivered value, via an on-site
customer, a particular planning approach, and constant testing.

The features of XP include simple processes, continuous feedback, incremental growth, high
communication and courage. For this, the customer (a domain expert) is available at all the
times. This reduces the feedback time greatly as the solution to a problem is obtained in a
very short time (few minutes to few hours). The software is developed iteratively and the self-
organizing teams adapt to the changes in the methodologies easily. A typical life cycle of an XP
is shown in Figure 2.8 and the phases are discussed as follows:

Figure 2.8 A typical life cycle of XP.

1. User stories: XP begins with collection of requirements termed “user stories” from
the customer. These stories are short and written by the customer(s). User stories differ
with traditional requirement specification in the sense that they only provide details
for making an estimate of how much time it will take to implement a user story. The
detailed requirements are collected at the time of development from the customer. These
stories are used in release planning and to create acceptance test plans and test cases
(Figure 2.9).

Figure 2.9 User stories.

2. Release planning: In this phase, the developers estimate the time to implement the user
stories and the customer selects the order in which the stories will be implemented. In
42  Object-Oriented Software Engineering

this phase, the developer may do a quick exploration (spike) of a user story in order to
estimate its cost. The customer may also divide a user story into substories, when and
where required. The steps followed in release planning are shown in Figure 2.10. The
release date of each story is finalized. Finally, the customer sorts and extracts the high
ranked and high-risk stories.

Figure 2.10 Steps followed in release planning.

3. Iteration planning: In iteration planning, user stories to be implemented in current

iteration are broken into tasks and these tasks are assigned to the developers (selected
by their importance). A working product is produced after each iteration, rather
than producing a software product at the end of the life cycle as done in traditional
approaches. After the iteration planning, the acceptance test cases are generated from
the user stories.
4. Development and unit tests: In this phase, the most important tasks chosen by the
customers are implemented. In order to increase software quality, pair programming is
used in which two people work together on the same computer. Refactoring is carried out
throughout the development cycle by removing obsolete designs, unused functionality
and redundancy. Automated unit tests are created before the source code is developed.
Unit tests also enable to identify the need of refactoring. After each change, the developer
verifies through the unit tests any change in functionality. The unit testing enables
effective functionality and regression testing so that refactoring process is carried out
efficiently.
5. Acceptance testing: Acceptance test plans and test cases are created from user stories.
These tests are carried out to ensure that requirements given by the customer are met
and the software developed in current iteration is acceptable. During each development
iteration, the acceptance test plans and test cases are prepared from the user stories.
Acceptance test cases are created using black box testing techniques. In the acceptance
testing, the test cases are run by the customer and the actual result is compared with the
expected result. Automated acceptance tests are run and the failed tests are fixed.
6. Working product released: After the acceptance testing, the decision about the release
of the product is left to the customer. There are frequent releases in which a working
product is delivered to the customer in each release.
 Software Development Life Cycle Models  43
The XP rules are given as follows:
1. It follows the 80–20 rule which states that 80% of the profits come from 20% of the
development.
2. Computers must be placed in the middle of a big room.
3. Tasks which are longer than three days are further broken down and which are shorter
than one day are grouped together.
4. Pair programming should not be misinterpreted as a student–teacher relationship.
5. Each iteration must not last more than a few weeks.
6. The customer must always be present at the developer’s site.
7. Spikes are used for elaborating user stories.
8. Continuous refactoring is followed.
9. Class responsibility collaboration (CRC) cards are used to design the system. These are
used to determine classes and interactions between them.
10. The entire team is responsible for the system’s architecture.
11. Integration is done within every few hours.
12. The developer cannot do overtime for the second consecutive week.
The main drawback of XP is that it is “hard to do simple things”. XP is not suitable for
projects where high documentation is required by the customer. It is also not suitable in
cases where the customer cannot be involved continuously. XP may not be used where
technology is complex and/or the time to obtain feedback as a consequence of integration
becomes difficult.

2.2 Object-Oriented Software Life Cycle Models

As discussed in Chapter 1, object-oriented concepts include classes, objects, inheritance, and
polymorphism. Object-oriented system models deal with real-world objects. These objects may
include human entities, business objects, data and storage constructs. The bases of the object-
oriented methodology are objects incorporating attributes and functions that operate on these
attributes. For example, in the case of result management system, a student is an object, course
is an object and even subject is an object. Thus, the object-oriented methodology concerns with
real-world objects and interrelationships between these objects.
Although the phases of the object-oriented software life cycle are similar to the traditional
life cycle models, they follow different methodologies of analysis and design. The focus
of the object-oriented software life cycle is on objects rather than on processes as in the
case of traditional waterfall and other models. The object-oriented software life cycle models
enable the designers and coders to properly design the objects and the interrelationships between
these objects. This allows to produce a simple-to-understand, modular, flexible and reusable
design of the object-oriented software under development. Table 2.1 highlights the major
differences between the phases of traditional models and object-oriented software life cycle
models.
44  Object-Oriented Software Engineering

Table 2.1 Comparison between phases of traditional and object-oriented approaches

Traditional approach Object-oriented approach
Methodology Functional and process driven. Object driven.
Requirement analysis phase Data flow diagrams, data dictionary, Use case approach for requirement
ER diagrams. capturing.
Analysis phase Data flow diagrams, data dictionary, Object identification and description,
ER diagrams. attributes and functions that operate
on those attributes are determined.
Design phase Structured chart, flow chart, pseudo Class diagram, object diagrams,
code. sequence diagrams, collaboration
diagrams.
Implementation and testing Implementing processes, functions, Implementing objects and interactions
phase unit, integration and system testing. amongst the objects. Unit, integration
and system testing.
Documentation Many documents are produced at A document may or may not be
the end of each phase. produced at the end of each phase.

The object-oriented software development life cycle includes the following phases:
1. Object-oriented requirement analysis: In this phase, the use case approach is used for
capturing requirements from the customer. The SRS document containing the use case
description may be produced during this phase.
2. Object-oriented analysis: In this phase, the objects and the interrelationships between
these objects are identified. The functions of the objects are determined. An ideal
structure is created in order to build high-quality maintainable software.
3. Object-oriented design: In this phase, the objects are defined in detail keeping in mind
the implementation environment. All the objects identified during the object-oriented
analysis phase must be traced to the design phase.
4. Object-oriented programming and testing: The objects, the functions encapsulated
in these objects and interactions amongst the objects are implemented in terms of
source code. The existing developed and well-tested components may be used and
new components are created. This feature supports reusability of the source code. The
developed components are tested using object-oriented testing techniques.
A typical object-oriented life cycle model is depicted in Figure 2.11.

2.2.1 Fountain Model

The fountain model provides a clear representation of iterations and overlapping phases. The
model emphasizes the reusability of the source code. Figure 2.12 shows the fountain model. The
circles depict the overlapping phases and the arrows within the circles depict iterations within
the phases. The smallest circle represents the maintenance phase showing that the maintenance
phase is the smallest in the fountain model.
 Software Development Life Cycle Models  45

Figure 2.11 Object-oriented life cycle model.

Figure 2.12 Fountain model.

46  Object-Oriented Software Engineering

Changes can be easily made between class specification and requirement specification.
Thus, there is no need to freeze the requirements in the early phases of software development.
Since the system is developed in terms of classes, the phases of the software development life
cycle can be applied to individual classes rather than system as a whole (Henderson-Sellers and
Edwards, 1990).
The fountain model may follow an undisciplined approach in which the developer moves
randomly between phases.

2.2.2 Rational Unified Process

Rational unified process (RUP) is maintained by Rational Software. It provides a process
framework that may be adapted by organizations according to their needs. The RUP supports
iterative software development where the software goes through a series of short length mini
projects called iterations.
The RUP forms the basis for providing guidelines on the use of Unified Modelling Language
(UML). The UML is a popular standard for visually modelling elements of the system and is
governed by Object Management Group (OMG). The UML is a language for creating, visualizing
and documenting various diagrams that depict different aspects of the software.
The RUP emphasizes iterative software development, effective requirement capturing, visual
modelling, use and development of reusable components, ensuring quality of the software,
change control management and automated testing. Figure 2.13 depicts the key features of RUP,
which are discussed here.

Figure 2.13 Key features of rational unified process.

1. Iterative software development: The software is developed through a series of iterations.

This allows the customer to provide continuous feedback after each iteration and hence
reduces risk and increases quality of the software. The iterative development helps
monitoring the schedule and budget of the project and also makes easier to accommodate
changing requirements.
2. Effective requirement elicitation: The RUP promotes the use of an effective requirement
elicitation technique popularly known as use case approach. Every requirement is
 Software Development Life Cycle Models  47
verifiable and traceable and every piece of design may be traced back to one or more
requirements in the software. It ensures that effective testing is carried out by generating
test cases from use cases. These test cases are used in acceptance testing and ensure that
the final software produced fulfils the user’s requirements.
3. Visual modelling: Visual modelling creates models to solve problems around the
real world. Visual modelling provides abstraction by hiding non-essential details and
building models that portray different views of the system. Models are an efficient way
to understand, visualize and document the real-world objects. Modelling safeguards
the system by providing understandable and manageable requirements, better software
designs and flexible software. The UML is an industry acceptable standard that provides
the foundation for visual modelling by using notations, models and diagrams.
4. Use and development of reusable components: The RUP supports component-based
software engineering. A component is an independent subsystem that fulfils a goal in a
clear fashion. The well-coded and thoroughly tested existing components are used and
new well-designed components are created to promote reuse.
5. Ensuring quality of a system: The cost to fix defects increases drastically as one moves
from the requirement phase to the testing phase and finally to the maintenance phase as
shown in Figure 2.14. Hence, quality must be continuously assessed in order to produce
a flexible and manageable system.

Figure 2.14 Phase-wise cost of fixing a defect.

Software quality is composed of many attributes such as usability, reliability,

maintainability and portability. The RUP provides guidelines for continuous quality
assessments, product evaluation and process monitoring. It puts emphasis on building
quality into the system from its inception. Quality is assessed by using measurement-
based techniques and models through which the quality of the software is determined.
48  Object-Oriented Software Engineering

6. Change control and management: The RUP provides guidelines for managing, controlling
and tracking changes in order to enable effective iterative software development.
7. Automated testing: The RUP promotes the use of automated testing. The automated
testing does repetitive testing, unattended without any human intervention. Both
functional and non-functional requirements can be tested by using a tool. This saves
much of the effort, time and resources.

RUP Overview
The process can be divided into two structures:
1. Static structure: It provides the process description in terms of roles, activities,
artifacts, disciplines and workflows.
2. Dynamic structure: The dynamic aspect of the process can be viewed in terms of
iterative development.
The structure of an RUP is shown in Figure 2.15. The vertical dimension depicts the static
structure of the process and the time dimension depicts the dynamic structure of the
process Each activity on the time dimension is carried out iteratively. As it can be seen
from Figure 2.15, implementation is started much later in the software development. Most
of the requirements are predefined in the early phases, but some new requirements may
be added in the later stages of software development. Testing is carried out throughout
the software life cycle whereas deployment activities begin much later in the software
development. Although the focus on activities keeps on increasing and decreasing throughout
the software life cycle, they can be carried out at any time during the software life cycle.

Figure 2.15 Structure of an RUP.

 Software Development Life Cycle Models  49
Static structure of RUP: The static structure of the RUP describes who (roles) does how
(activities), what (artifacts) and when (workflows). Five major elements form the static structure
of the RUP: role, activities, artifacts, disciplines and workflows. Figure 2.16 presents the
relationship between roles, activities and artifacts.

Figure 2.16 Relationship between roles, activities and artifacts.

Roles: A role describes functions or position that a person is expected to have in a project. The
functions are known as activities that a person has to perform in order to achieve an artifact.
A person may have many roles. For example, as shown in Figure 2.17, Rita plays the role of a
designer and a use case creator simultaneously. The role of the person may keep on changing
depending on the project. For example, Ram may be a project manager at one time and a design
reviewer at the other time.
The roles of four persons involved in an example application are shown in Figure 2.17.
In the figure, each role is associated with the corresponding activities to be performed by the
role player. For example, Mary is a designer and is responsible for creating class design and
identification of attributes and functions of a class.
Activities: Activities are the work performed by a person in a specific role to produce the
required result from the system. Activity is expressed in terms of creation or design of an artifact
such as use case, object, state chart, etc. The following are examples of activities performed by
persons in different roles:
1. Estimation of effort and schedule
2. Design of classes
3. Review of SRS document
4. Verification of quality of system design
5. Creation of test plan and test cases
50  Object-Oriented Software Engineering

Figure 2.17 Roles and activities.

An activity may be further decomposed into various subactivities. For example, design of a class
may be decomposed into the following steps:
1. Identification of attributes
2. Identification of functions
3. Identification of interaction amongst functions
4. Description of functions
5. Description of relationship of a class with other classes in the class model
6. Evaluation of the relationship amongst classes
7. Development of a description of the class
8. Review of the results
Artifacts: Artifacts are the outputs produced during the development life cycle of the software.
They may be end products produced or inputs used by the activities while developing the software.
An activity is performed by a role to produce an artifact. The following are the examples of
artifacts:
1. Software requirement specification
2. Use case model
3. Class model
4. Test plan
5. Source code
6. User manual
 Software Development Life Cycle Models  51
Disciplines: Disciplines are used to organize a set of activities. An RUP consists of six major
disciplines: business modelling, requirements, analysis and design, implementation, testing and
deployment. These disciplines are traced again and again throughout the software development
life cycle.
Workflows: Workflows consist of a series of activities to produce a relevant output.
Dynamic structure of RUP: The dynamic structure of an RUP is organized along time as
shown in Figure 2.18. It consists of four phases as shown in the figure: inception, elaboration,
construction and transition. Each phase achieves a predefined milestone that ascertains the status
of the project.

Figure 2.18 Phases of the process.

The distribution of effort and schedule is different in all the phases and is shown graphically
for a medium-sized project in Figure 2.19.

Figure 2.19 Phase-wise distribution of resources.

The RUP follows an iterative development process as shown in Figure 2.20. The first pass
through inception, elaboration, construction and transition produces the first version of the
software. The user feedback is obtained along with defect reports and improvement needs. The
same process is repeated to evolve the next generation of the software.
52  Object-Oriented Software Engineering

Figure 2.20 Iterative RUP.

Inception: The inception phase begins with the following questions: How long would it take to
complete the project? How feasible is the project? What are the high-level requirements? In the
inception phase, business problem is defined, an actors (external entities that interact with the
system) and use cases are identified. The significant use cases are described.
Inception is basically a non-iterative process as compared to the other phases which are
highly iterative. An iteration plan is developed that describes during which iteration which use
case will be implemented. The essential activities of the inception phase are as follows:
1. Establishment of scope and boundary of the project.
2. Determination of cost and schedule of the project.
3. Identification of actors and use cases.
4. Development of initial iteration plan.
5. Determination of high-level risks.
The artifacts produced by the inception phase are shown in Figure 2.21. The vision document
addresses the scope and requirements of the project. The main constraints of the project are also
identified. Business case is defined and an initial list of risks involved in the project is prepared.
The objectives and durations of the initial phases are determined in software development plan.
The iteration plan consists of details of which use case to be covered during which iteration. The
required tools in the project are listed. An initial glossary consisting of definitions of important
terms is prepared. The initial use case model identifies important actors and use cases along
with flow of events for significant use cases. The environment for configuration management is
set up by establishment of project repository. Prototypes are very useful for the understanding of
the project (optional artifacts).
 Software Development Life Cycle Models  53

Figure 2.21 Fish bone diagram showing the artifacts produced.

Elaboration: The elaboration phase consists of planning and architectural design. This is the
most critical phase of RUP. As given in the iteration phase, the elaboration phase is followed
for each use case in the current iteration. In this phase, detailed description of use cases is
prepared. The requirements gathered in the form of use cases are documented in the software
requirement specification document. The other activities of the elaboration phase include review
of use case model and SRS document for the assessment of quality. The essential activities of
the elaboration phase are as follows:
1. Establishment and validation of architectural baselines.
2. Addressing significant risks.
3. Design of use case model.
4. Selection of components and formation of policies for their purchase and usage.
5. Creation of detailed iteration plans.
6. Development of prototypes.
The outcomes of the elaboration phase are given in Figure 2.21. Executable architectural
prototypes are created to explore significant functionality of the system. Revised and updated
54  Object-Oriented Software Engineering

risk list is prepared which primarily handles non-functional requirements. Software architecture
description document includes description of use cases and design elements. The design model
and data model are also designed. The implementation model consists of initial structure and
identifies significant components. The detailed iteration plan for the construction phase is
prepared. A use case model (approximately 80% complete) is designed. All the use cases along
with actors are identified and described. Test plan includes test cases to validate the system. Test
automation architecture is also designed.
Construction: On the basis of architecture and design developed in the elaboration phase, the
product is developed and tested in the construction phase. During this phase, the remaining
requirements are determined. The deployable products are produced from this phase. The
essential activities of the construction phase are as follows:
1. Optimization of resources by avoiding rework and unnecessary coding.
2. Assessment and verification of quality.
3. Testing all the functionalities of the product. Testing activities include unit, integration
and system testing.
The outcome includes the software product along with the user manuals. A completed and
reviewed iteration plan is produced for the transition phase. A design model with new and
updated design elements is prepared. The test outline and test suite are also preserved as they
may be required during the maintenance phase.
Transition: The transition phase is started when a usable product with sufficient quality has
been built. The objective of this phase is to hand over the software product to the customer. This
phase includes delivering, training users and maintaining the software. Elaboration involves beta
releases, bug fixes and enhancement releases.
Product release produces the product that conforms to the customer’s requirements. The
outcome of the transition phase includes various reports and documents such as beta test reports,
release notes, training material and end-user support material.
The RUP is iterative in nature and thus has many advantages. It allows to develop flexible,
low-risk, reusable and maintainable software. Hence, a good quality software product is expected
to be produced from the RUP.

2.3 Selection of Software Development

Life Cycle Models
The selection of software development life cycle models depends on various parameters such as
nature and type of projects, customers, developers, nature of requirements, associated risks, etc.
Table 2.2 summarizes the applications, strengths and weaknesses of six conventional and two
object-oriented software development life cycle models discussed in previous sections. The table
may help the developers in selecting the right kind of software development life cycle model for
their project.
 Software Development Life Cycle Models  55
Table 2.2 Summary of conventional and object-oriented software development life cycle
models
Model Applications Strengths Weaknesses
Build-and-fix Very small sized Simple and easy to understand. Only applicable to very small
applications (50–200 sized programs.
lines of source code). Produces unenhancable source
code.
Requirements are not
predetermined.
Resultant product is difficult
to maintain.
Frequent changes produce
unstructured source code.
Waterfall Small and medium-sized Simple and easy to understand. Software is built on the basis
projects. Separation of functionalities in of written documents that may
Requirements are the form of phases. be partially understood.
completely known and System progress is measurable. Working product is not
understood initially. produced until late in the life
cycle.
Unrealistic to determine all
the requirements at the start of
the project.
Lack of iterations.
Prototyping Projects where complete Stable requirements. Customer expects quick
requirements are not High-quality system. delivery of the software.
known initially. Actual cost of developing Less applicable to existing
User interactive projects software is less as compared systems as compared to new
where human–computer to waterfall model. systems.
interface is desirable. Missing and confusing Time for implementing
requirements can be identified prototype may exceed.
easily.
Iterative Projects where important Customer does not request for Later software increments may
enhancement functionalities are unnecessary requirements— require modifications in earlier
delivered quickly. avoids requirements bloating. ones which may increase costs.
Customer gets to see results May result in poor structure
quickly. due to frequent changes made
Additional functionality can be in the source code.
added in the later phases.
Early delivery of important
functionalities.
Spiral Suitable for real-time, Combines characteristics of Experts for risk assessment
mission critical, risk- most of the models. and resolution may not be
oriented applications. Includes risk management. easily available.
Suitable for large sized No particular start or end of Usable for only large-sized
software. the project. systems.
Can be a costly model.
Limits reusability.

(Contd.)
56  Object-Oriented Software Engineering

Table 2.2 Summary of conventional and object-oriented software development life cycle
models (Contd.)
Model Applications Strengths Weaknesses
Extreme Small and medium-sized Creates software fast with few Hard to implement.
programming projects that require quick defects. Customers may not like to be
development. Less meetings. involved in every activity.
Works good for high-risk Emphasizes team work and Less challenging for
projects. communication. professionals.
Continuous measurement Lack of documentation.
reviews. Not suitable for larger projects.
Fountain Object-oriented projects. Overlapping phases. Undisciplined software
Short maintenance cycle. development approach may be
Can easily accommodate followed in which developer
changing requirements. moves randomly between
Supports reusability. phases.
Rational unified Object-oriented large- Complete methodology. Complex process.
process sized projects. Closer to real-world. Designers should be expert to
Support for visual modelling utilize this methodology.
using UML. Reuse not possible in the case
Test plans and test cases are of a project built using new
constructed directly from use technology.
cases in the early phases of
software development.
Supports reusability in the
form of use cases and design
of components. This helps
to improve the quality of
the system and also reduces
development time.
Can easily accommodate
changing requirements.
Reduced time and effort on
integration as it follow iterative
process.
Online training and tutorials
available.

Review Questions
1. Explain the build-and-fix model. What are the disadvantages of such a model?
2. What is software development life cycle? Discuss the waterfall model.
3. List the advantages and disadvantages of the waterfall model.
4. Explain the prototyping model. What is the effect of using prototyping model on the
overall cost of the software?
5. What is a throwaway prototype? List the advantages of the prototyping model.
 Software Development Life Cycle Models  57
6. Discuss the iterative enhancement model with the help of a block diagram. In what
conditions is this type of model suitable?
7. Discuss the spiral model with the help of a neat diagram.
8. Compare waterfall model and prototyping model.
9. How is “risk factor” analysed and handled in the spiral model?
10. What are the limitations of the spiral model?
11. What is the significance of rounds in the spiral model?
12. What are agile processes? Explain their key features.
13. Discuss the life cycle of extreme programming. What are the limitations of such an
approach?
14. What steps are involved in release planning of the extreme programming approach?
What is the purpose of refactoring in extreme programming?
15. Differentiate between release planning and iteration planning.
16. List and explain the extreme programming rules.
17. What is pair programming? Explain its significance in extreme programming.
18. Define the following terms:
(a) Spike
(b) Agile process
(c) 80-20 rule
(d) Pair programming
(e) Refactoring
19. What is the role of a customer in the extreme programming model?
20. Differentiate between the conventional approach and the object-oriented approach of
software development.
21. Explain the fountain model with the help of a diagram. What is the significance of
arrows within circles in this model? List the advantages and disadvantages of this model.
22. What is RUP? Explain the various phases of RUP along with their outcomes.
23. Differentiate between the static structure and dynamic structure of RUP.
24. Establish the relationships between roles, activities and artifacts in RUP.
25. Discuss the parameters based on which we may select a software development life cycle
model.

Multiple Choice Questions

Note: Select the most appropriate answer of the following questions:
1. Which is the most popular model for student programs?
(a) Waterfall model (b) Build-and-fix model
(c) Spiral model (d) Rational unified model
58  Object-Oriented Software Engineering

2. Which of the following is not an object-oriented model?

(a) Fountain model (b) Rational unified process
(c) Extreme programming (d) None of the above
3. Which model produces a large number of documents?
(a) Extreme programming (b) Waterfall model
(c) Build-and-fix model (d) None of the above
4. Which of the following is an advantage of the waterfall model?
(a) Large number of documents are produced
(b) Separation of life cycle phases
(c) Both (a) and (b)
(d) None of the above
5. Which model is suitable for stable and known requirements?
(a) Spiral model (b) Prototyping model
(c) Waterfall model (d) Iterative enhancement model
6. How many phases are there in the build-and-fix model?
(a) Two phases (b) Three phases
(c) Four phases (d) Five phases
7. Prototyping model is most suitable for projects with:
(a) Stable requirements (b) Defined and understandable requirements
(c) Small size (d) Changing requirements
8. In which model is high user participation required?
(a) Waterfall model (b) Prototyping model
(c) Build-and-fix model (d) All of the above
9. SDLC stands for:
(a) Software development life cycle (b) Software design life cycle
(c) System development life cycle (d) Sequential design life cycle
10. In which model are requirements implemented by priority?
(a) Waterfall model (b) Prototyping model
(c) Iterative enhancement model (d) Build and fix model
11. In which model is a usable product produced at the end of each cycle?
(a) Prototyping model (b) Waterfall model
(c) Extreme programming model (d) Iterative enhancement model
12. The spiral model is developed by:
(a) Barry W. Boehm (b) L. Briand
(c) Victor Basili (d) B. Henderson-Sellers
13. If user feedback and involvement are not available, which model is suitable?
(a) Waterfall model (b) Iterative enhancement model
(c) Prototyping model (d) None of the above
14. The spiral model is suitable for:
(a) Small-sized projects (b) Low-budget projects
(c) Simple projects (d) Large-sized projects
 Software Development Life Cycle Models  59
15. The spiral model primarily deals with:
(a) Non-functional requirements (b) Risk management
(c) Quality assurance (d) Defect management
16. The radial dimension of the spiral model shows:
(a) Progress made in the completion of the final software
(b) Schedule of the project
(c) Cumulative cost of the project
(d) None of the above
17. The angular dimension of the spiral model shows:
(a) Progress made in the completion of the final software
(b) Schedule of the project
(c) Cumulative cost of the project
(d) None of the above
18. The disadvantage of the spiral model is:
(a) It is not suitable for large-sized projects
(b) It produces low-cost software
(c) It requires expertise to determine and resolve risks
(d) All of the above
19. The extreme programming is based on:
(a) Ad hoc approach (b) Agile processes
(c) Formal methods (d) Stochastic processes
20. The key features of agile processes include:
(a) Working software is produced very early
(b) Iterative planning
(c) The customer is always present at the developer’s site
(d) All of the above
21. Which of the following is not a rule of agile processes?
(a) Working software is produced very early
(b) Iterative planning
(c) The customer is always present at the developer’s site
(d) None of the above
22. Spikes are:
(a) Quick exploration of user stories
(b) Detailed exploration of user stories
(c) Ranking of user stories
(d) Used to identify risky user stories
23. XP is suitable for:
(a) Small and medium-sized projects
(b) Large-sized projects
(c) Non-changing requirements
(d) All of the above
60  Object-Oriented Software Engineering

24. XP is not suitable for applications where:

(a) Documentation is required
(b) Continuous customer involvement cannot be achieved
(c) Technology is simple
(d) Pair programming is suitable
25. Object-oriented life cycle models deal with:
(a) Changing requirements (b) Real-world projects
(c) Business objects (d) All of the above
26. In the fountain model, arrows with circles depict:
(a) Overlapping phases (b) Iterations
(c) Sequential phases (d) Reusability
27. In the fountain, model circles depict:
(a) Overlapping phases (b) Iterations
(c) Sequential phases (d) Reusability
28. RUP stands for:
(a) Risk-oriented unified process (b) Resource uniform process
(c) Rational unified process (d) Rational uniform process
29. RUP is maintained by:
(a) Microsoft (b) TCS
(c) Alcatel (d) IBM Rational Software
30. UML stands for
(a) Unified Model Link (b) Uniform Modelling Language
(c) Unified Modelling Language (d) Uniform Microsoft Language
31. The team of unified process development includes
(a) I. Jacobson (b) B. Boehm
(c) Victor Basili (d) L. Briand
32. How many phases are included in the RUP model?
(a) Two phases (b) Four phases
(c) Five phases (d) Six phases
33. The major elements of the static structure of RUP are:
(a) Workflows (b) Artifacts
(c) Disciplines (d) All of the above
34. Which of the following is not an activity of elaboration phase?
(a) Design of use case model
(b) Prototyping
(c) Execution of detailed iteration phase
(d) Establishment of scope and boundary of the project
35. The outcome of the construction phase includes:
(a) Software product (b) Use case product
(c) Software development plan (d) Initial project glossary
 Software Development Life Cycle Models  61

Further Reading
The experiences and suggestions of Royce on the waterfall mode are written in:
Royce, W., Managing the development of large software systems. IEEE WESCON, August 1970.
The classic approach of iterative enhancement was proposed by Basili and can be further read in:
Basili, V. and Turner, A., Iterative enhancement: A practical technique for software development.
IEEE Transactions on Software Engineering, 1(4): 390–396, 1975.
The overview of object-oriented life cycle is given in:
Henderson-Sellers, B. and Edwards, J., Object-oriented systems life cycle. Communications of
the ACM, 33(9), September 1990.
An overview of agile processes may be obtained from:
Cockburn, A., Agile Software Development. Boston, MA: Addison-Wesley, 2000.
William explains XP with the perspective of programmer, customer and manager in his book:
Wake, W.C., Extreme Programming Explored. Boston, MA: Addison-Wesley, 2001.
Beck gives stories, methodology, myths and applications of XP in his book:
Beck, K., Extreme Programming Explained. Boston, MA: Addison-Wesley, 2004.
The details on rational unified process can be obtained from:
Rational Software, Rational Unified Process Version, 2002.
 3
Software Requirements Elicitation
and Analysis

Whenever we get a request for software development from a customer, we would like to first
understand the project. This understanding may compel us to think about the feasibility of the
project. Some projects are very good conceptually, but may not be feasible due to limitations of
technology, time, cost, market or appropriate skilled manpower. The decision about feasibility
also depends upon our understanding of requirements. The non-feasibility of a project must
be realized as early as possible, otherwise cancellation of a project in later stages may lead to
embarrassment and huge wastage in terms of time, cost and manpower.
The key issue is the capturing of requirements. This is a very difficult and challenging phase
of software development life cycle. Most of the requirements are in the minds of the people and
extracting them is not an easy task for any developer. After extraction, such requirements should
be documented in a specified format. Brooks (1995) has rightly mentioned that:
The hardest part of building a software system is deciding precisely what to build. No other part
of conceptual work is as difficult as establishing the detailed technical requirements. No other
part of the work so cripples the resulting system if done wrong. No other part is more difficult
to rectify later.
So, if requirements are elicited properly and documented rightly, then it is presumed that
effective foundations of the project are laid. In this chapter, we present requirements elicitation
techniques. After the requirements are captured, the initial requirements document is prepared.
The use case approach widely being used in object-oriented software engineering is explained
and the characteristics of a good requirement are defined. Finally, the contents of the SRS
are explained. In order to explain the concepts, a case study of library management system is
considered throughout this book.
62
 Software Requirements Elicitation and Analysis  63

3.1 Case Study: Library Management System

The problem statement for a Library Management System (LMS) case study is presented in this
section. The examples from this case study are used to illustrate object-oriented analysis and
design techniques throughout this book. The problem statement is prepared by the customer who
gives us broad outline of the expectations from the proposed system. The problem statement of
the LMS as prepared by the customer is given here.

A software product is to be developed for automating the functioning of a university library.

There are three types of members in the library, i.e. students, faculty and employees. There is an
upper limit in terms of maximum number of books issued to a member and duration for which
a book is issued. This limit may vary from one type of members to other types of members. The
LMS performs the following functions:
1. Issue of books
(a) Books are issued to students, faculty members and employees as per their specified
limits of duration and number of books.
(b) The current date is used as issue date for a book.
(c) The due date of return of a book is calculated as per specified limit of duration.
(d) The due date is stamped on the book.

2. Return of books
(a) Any person can return the issued books.
(b) If a book is returned after the due date, a fine is charged from the students for each day
delayed. The charges may vary from time to time. However, faculty and employees are
not charged any fine for late return of a book.

3. Maintenance of information
The LMS maintains the following information:
(a) Details of all members with their name, address, designation (wherever applicable),
phone number and unique identification code.
(b) Details of all books with their author name(s), publisher, price, number of copies, and
ISBN number.
(c) Details of books issued to every member.

3.2 What is Software Requirement?

Requirements describe the ‘what’ of a system and not the ‘how’. ‘What’ is related to expectations
from a system. A requirement is defined as “a condition or capability to which a system must
conform”. Who will provide us these conditions or capabilities? It depends on the type of project.
If the project is the enhancement of an existing system or automation of an existing system, then
64  Object-Oriented Software Engineering

the existing system may become the source of information, along with the people involved in
the system. A generic term is used for the people who are affected directly or indirectly by the
system that is being developed and is called stakeholders.

3.2.1 Identification of Stakeholders

Identification of stakeholders is a very important task. Every affected person (directly or
indirectly) is a stakeholder of the system. All such persons should be identified carefully and
a list should be prepared along with their roles in the present system (if available) and also
in the system under development. There are many categories of stakeholders and some are
discussed here.

Internal People of Customer’s Organization

This category contains the internal people of the organization where the new system will be
deployed and used. There are two types of stakeholders, i.e. customers and users. Customers
request for the development of the system, approve the changes in the system, accept the
system and finally pay for the system. Users use the system after its deployment. Both types
of stakeholders are important but their expectations may be different. In case of conflict, the
customer’s expectations are given preference the over user’s expectations. For example, in the
Library Management System (LMS) discussed earlier, the university is the customer and may be
represented by a librarian or any other person deputed by the Vice Chancellor. Some of the users
of the LMS are faculty, students, employees and data entry operators (DEOs). In the LMS, a
librarian (customer) may like to obtain a list of mistakes made by a DEO during entry of data in
a day. However, any DEO may not like to have such a provision because it will be a reflection on
their performance in terms of mistakes made during data entry. Hence, in the case of conflicting
situations, the customer’s expectation will prevail over the user’s expectations.

External People of Customer’s Organization

This category contains the external people of the customer’s organization. This may include
consultants, domain experts (if engaged only for the project), maintenance persons (if
maintenance activities are outsourced) and any outside agency persons responsible for providing
rules, regulations and guidelines. All such people are considered as stakeholders.

Internal People of Developer’s Organization

Everyone involved in the development of the system are the stakeholders. This may include
developers, programmers, requirement writers, testers, project managers, use case writers,
graphic designers, etc.

External People of Developer’s Organization

This category contains the external people engaged directly or indirectly in the development
of the system. This may include consultants, outside domain experts, third party testers and
any outside agency persons responsible for providing development and testing guidelines and
standards.
 Software Requirements Elicitation and Analysis  65

3.2.2 Functional and Non-functional Requirements

Requirements are classified into two categories, i.e. functional and non-functional given as
follows:
1. Functional requirements: They describe ‘what’ the software will do. This ‘what’ part
gives us the functional requirements which are nothing but the expectations from the
system. Functional requirements are also called product features. Sometimes, functional
requirements also specify what the software will not do. They are captured from the
stakeholders and related only to the functionality of the system.
2. Non-functional requirements: They are nothing but the attributes of software quality.
They signify that how well the software does what it has to do. Non-functional
requirements are important for the sustainability of the system and some of them are
reliability, usability, maintainability, availability, portability, flexibility and testability.
These non-functional requirements may make the users happy and satisfied. They help
us to measure the quality of the software and are also called quality attributes.

3.2.3 Known and Unknown Requirements

Known requirements are the expectations of the stakeholders and may make stakeholders happy
if implemented correctly. Unknown requirements are forgotten by the stakeholders because
they may not require now or due to limitation of domain expertise and facilities of available
technology. If such unknown requirements are identified, they may add value to the system and
may increase the chances of acceptability and sustainability of the system.
Every requirement (known and unknown) may be functional or non-functional. As discussed
in the previous section, functional requirements are also called product features and non-
functional requirements are called quality attributes.

3.3 Requirements Elicitation Techniques

Requirements are in the minds of the stakeholders. Therefore, it is extremely challenging to find
out what they really expect from the proposed system. Wiegers (1999) has rightly said:
Requirements elicitation is perhaps the most difficult, most critical, most error prone, and most
communication intensive aspect of software development. Elicitation can succeed only through
an effective customer developer partnership.

The objective of effective customer developer partnership is not easy to achieve. Both groups
have different mindsets, educational background, vocabulary, communication skills and domain
expertise. All such things lead to communication gap which further increases the probability of
conflicts, misunderstanding and ambiguities. However, both groups want success of the project.
There are many techniques for requirements elicitation. We may use one or more techniques to
capture the requirements. One technique may not be sufficient to capture enough details of the
expectations. The selection of a technique may be based on the following:
66  Object-Oriented Software Engineering

1. It is the only technique that we know.

2. It is our favourite technique.
3. We believe that a particular technique is the best for this project.
The third reason of selection may be the best way to proceed for capturing of requirements.
However, in practice, the first two reasons are used to select one or more technique(s) for
requirements elicitation.

3.3.1 Interviews
The most popular, simple and conventional requirements elicitation technique is to conduct
interviews with the customer. After receiving the request for software development, we would
like to understand the project. Hence, we may like to meet the customer to discuss his/her
expectations from the project. The interview of the customer may be informal (non-structured) or
formal (structured). The first such meeting/interview may help to understand broad expectations.
In the informal interview, there is no fixed agenda and open discussions for free flow of view are
encouraged. For example, for an LMS described in Section 3.1, we may ask:
(i) Who is the librarian?
(ii) Why do you feel the requirement of library management system?
(iii) How many members are regular visitors?
(iv) What are the limitations of the present manual library system?
(v) How many types of memberships are offered?
(vi) Who is the most conversant with the present system?
(vii) Is there any opposition of the project?
(viii) How many persons of library staff are computer friendly?
These types of questions may become instrumental in the understanding of the present manual
system. In the structured interview, a proper agenda is prepared along with a questionnaire. The
various steps of structured interviews are given in Figure 3.1.

Figure 3.1 Steps of structured interview.

 Software Requirements Elicitation and Analysis  67

Selection of Stakeholders
There are many stakeholders of any system. All cannot be interviewed. The representatives from
a group of stakeholders may be selected on the basis of experience, qualification, intelligence,
domain knowledge, credibility, loyalty, etc. There are many groups like entry-level personnel,
mid-level personnel, managers, users of the software, top-level management, developers, quality
assurance personnel, related vendors, maintenance personnel, etc. Every group has different
view points and expectation from the proposed system. One or more persons from every group
should be selected and interviewed to understand and capture the requirements.

Design and Distribution of Questionnaire Prior to Interview

We may prepare a list of questions which should be simple and short. Questionnaire should
be well drafted and may be distributed to select group of stakeholders prior to interview.
During interview, any point may be discussed, clarifications are obtained, and ambiguities are
minimized. We may also encourage free flow of ideas and document them properly. A sample
questionnaire is given in Table 3.1.

Table 3.1 Sample questionnaire for conducting interviews

Section I
Name of the stakeholder
Organization
Group
Project
Date of interview

Section II
Please specify your name and role in this project: .......................................
S. No. Questions
1 Are you satisfied with the manual/present system?
2 What are the problems with the current system?
3 What are the strengths of the present system?
4 What are the limitations of the present system?
5 What are the possible benefits of automating the present system?
6 Are you satisfied with current processes and policies?
7 How are you maintaining the present records?
8 List a few important objectives of the proposed automation.
9 List a few problems which you want to resolve through automation.
10 List point-wise the scope of the project in order of priority.
11 Do you expect additional functionality to improve efficiency and performance
of the system?
(Contd.)
68  Object-Oriented Software Engineering

Table 3.1 Sample questionnaire for conducting interviews (Contd.)

Section II
Please specify your name and role in this project: .......................................
S. No. Questions
12 List a few stakeholders which must be interviewed.
13 Any specific problem faced in the previous years?
14 List essential expectations from the new system.
15 List essential functional and non-functional requirements.
16 Can you give system diagram that will provide an overview of the system?
17 What information will be stored in the proposed system?
18 What are various threats to the new project?
19 Any suggestions for the success of the project?
20 What mechanism would you like to suggest for the prevention of unauthorized
access and protection of your data?

Preparation of List of Requirements of Every Stakeholder

A list of requirements is prepared on the basis of discussion during interview and filled
questionnaire. The list is analysed by experts and redundant requirements are removed.

Preparation of Consolidated List and Review of the List

A team of experts should combine the captured requirements. Redundancy should be removed.
All requirements are reviewed to remove inconsistencies and ambiguities. A long consolidated
list of requirements may help us to understand the expectations from the new system and
may become the basis for the design of document. This document may help the developers
to know what to build, customers to know what to expect and become a fundamental
document to provide foundation to the project. This document is known as initial requirements
document (IRD).

EXAMPLE 3.1 Consider the case study of LMS given in Section 3.1. Develop a questionnaire
containing a list of questions that may be distributed to the librarian before conducting an
interview.
Solution We may frame specific questions for a project. For example, the following questions
may be distributed to the librarian before conducting an interview. The questions that may
be discussed by the requirement analyst with the librarian during the interview are shown in
Table 3.2.
The questionnaire will discipline stakeholders and structure the interview process. All
points of the questionnaire will be discussed freely and the questionnaire will be analysed and
reviewed to improve the quality of the document.
 Software Requirements Elicitation and Analysis  69

Table 3.2 List of questions for library management system

Librarian
S. No. Questions
1 Do you want to have an automated library management system?
2 What are the problems with the existing manual system of the library?
3 What do you think is the best solution to the problems faced in the existing system?
4 How often are the new members registered?
5 How many users are there in the library?
6 Do you have different types of members? If yes, how many?
7 How many books are present in the library?
8 Do you need a facility to reserve a book in advance?
9 How are the books categorized?
10 What are the reports prepared in the present system?
11 Do you have any format for the reports? Do you want the format of the reports to
remain the same?
12 How many books are issued to each type of member and for how many days?
13 Do you have any fine system to penalize the users who return books late?
14 The search procedures should be categorized by: book title, author, publisher or
any other.
15 What member and book information do you store in your records?

3.3.2 Brainstorming Sessions

This is also a popular requirements elicitation technique. A group of various stakeholders
is constituted to discuss the requirements. The group discussions may encourage new views
and ideas quickly and also promotes creative thinking. Group may be heterogeneous where
stakeholders from various levels are invited. They may be from entry-level personnel, middle-
level managements, project managers, developers, top-level management, actual users, etc. The
size of the group may be from 5 to 15 persons. The sessions should be conducted in a conference
room with at least two whiteboards and other presentation devices like projector. A facilitator
(normally author of the document) explains the purpose of the meeting and presents an already
prepared document to sanitize everyone about the purpose. Every stakeholder is allowed to give
his/her views using the projector and whiteboard. All views are documented. The idea is to
create an environment for free flow of views. No one is allowed to criticize each other.
Brainstorming sessions are very useful for capturing requirements and are used by most of
the software companies. These encourage creative thinking, promote new idea and provide a
platform to share views, apprehensions and expectations. A long list of requirements is prepared
which can further be categorized, prioritized and pruned.
The role of the facilitator is very important. He/she may handle group bias and conflicts
carefully. The facilitator is also responsible to handle individual egos and to ensure the conduct
of the meeting smoothly. Every idea is written in such a way that everyone can see it. After
the session, a detailed report is prepared and the same may be reviewed by the facilitator. All
ideas are written in a simple and easy language so that they convey the same meaning to every
stakeholder. Incomplete ideas are also documented and must be discussed at any later date
70  Object-Oriented Software Engineering

to make these ideas complete, if possible. Finally, an initial requirement document (IRD) is
prepared to document the requirements.

3.3.3 Facilitated Application Specification Technique

This is a team-oriented approach and works on the pattern of brainstorming sessions. A joint
team of customers and developers is constituted to frame the requirements. All meetings are
conducted under the chairpersonship of a facilitator. A facilitator may be appointed from the
developers or customers. Sometimes an outsider may also be appointed for this work and is
called third party facilitator. The objective is to understand the requirements and bridge the gap
between expectations and requirements. Facilitated application specification technique (FAST)
is more formal than brainstorming sessions. All members of the team are required to follow the
set procedures and guidelines.

Guidelines for Conducting FAST Session

(i) FAST session must be conducted at neutral site. All members of the joint team (developers
and customers) travel to that site. This may help to get their maximum involvement and
focus on the requirements capturing.
(ii) Rules for participation are framed and circulated to all members in advance.
(iii) All members are made comfortable to encourage free flow of ideas.
(iv) The facilitator gives the overview of the project.
(v) A display mechanism like projector, wall strickers, flip charts, whiteboards, etc. should
be available in the committee room where the meeting is conducted.
(vi) All members should be directed to give only their views. Unnecessary prolonged debates
and criticisms should be avoided.

Preparation of FAST Session

Each member is required to make a list of objects that are (i) a part of the environment that
surrounds the system, (ii) produced by the system and (iii) used by the system. Each member
also makes a list of services (processes or functions) that manipulate or interact with the objects.
Finally, a list of constraints (e.g. cost, size, etc.) and performance criteria (e.g. speed, accuracy,
etc.) is also developed. The attendees are informed that the lists are not expected to be exhaustive
but are expected to reflect each person’s perception of the system.

Activities of FAST Session

(i) Each member presents his/her lists of objects, constraints, services and performance for
discussion. A list may be displayed using any display mechanism (say projector) or may
be written on the whiteboard in such a way that it is visible to every team member of
the team.
(ii) A small group is constituted to prepare a consolidated list after removing redundant
entries.
(iii) The convener of the small group presents the consolidated list. Discussions take place
under the directions of the facilitator. The list is further modified, if required, in order
to prepare a consensus list.
 Software Requirements Elicitation and Analysis  71
(iv) A few small groups are constituted to draft mini-specifications for one or more entries
of the consensus list.
(v) Each subteam presents mini-specifications to all FAST attendees. After thorough
discussions, modifications are carried out in mini-specifications.
(vi) Some issues may not be resolved during the meeting. A list of such issues is prepared
for consideration at any later stage.
(vii) A validation criterion is also decided for every requirement.
(viii) A subteam for drafting the specification is constituted. The final draft is prepared
considering all inputs of FAST meeting.
FAST is a popular traditional technique for requirements elicitation. It helps us to prepare the
IRD in limited time frame under the leadership of a facilitator. Neutral site may help the members
to devote more quality time in the requirements capturing and drafting process, although it is an
expensive activity as compared to interviews and brainstorming sessions.

3.3.4 Prototyping
Prototyping is one of the expensive but powerful ways to capture requirements. A prototype is a
simplified version of the system. When it is shown to the customers, they get an idea about the
final system. At this point, their feedback and views are very important and may help us to read
their minds. We generally use prototype to understand the requirements. After finalization of the
requirements, the purpose of a prototype is over and it is discarded. Hence, we should use the
prototype and the final system should be built around the existing prototype. Prototyping is the
rapid development of a system for the purpose of understanding requirements. Customers and
users can use the prototype to see how the system will look and behave finally. This may reduce
the chances of misunderstanding between customers/users and developers. Missing expectations
may be highlighted and ambiguous areas may be discussed to make it unambiguous. Initially,
prototyping may cost us more but the overall development cost may be reduced. Developers
generally use this prototype to refine the requirements and prepare the final specification
document. Through prototyping, views of customers are easily incorporated in the IRD. In most
of the situations, the source code of the prototype is thrown away; however, experience and
feedback gathered from developing and using the prototype helps in developing the actual system.
Schach (1999) has rightly mentioned, “The developers should develop the prototype as early as
possible to speed up the software development process. After all, sole use of this is to determine
the customer’s real needs. Once this has been determined, the prototype is discarded. For this
reason, the internal structure of the prototype is not very important”. However, there are people
in some organizations who do not believe in this throwaway approach of prototyping. They feel
that the prototype provides foundations for the system and huge effort is already invested.

3.4 Initial Requirements Document

After the requirements are captured, the initial requirements document (IRD) may be prepared.
The IRD is used to document and list the initial set of requirements gathered through various
stakeholders. The template of the IRD is given in Figure 3.2 and the IRD for the LMS is given
in Figure 3.3.
72  Object-Oriented Software Engineering

Title of the project

Stakeholders involved in capturing requirements
Techniques used for requirement capturing
Name of the persons along with designations
Date
Version
Consolidated list of initial requirements:

Figure 3.2 Template for initial requirements document.

Title of the project Library management system

Stakeholders involved in capturing requirements Librarian, library staff, project leader, students
Techniques used for requirement capturing Interviewing and brainstorming
Name of the persons along with designations –
Date November, 2010
Version 1.0
Consolidated list of initial requirements:
1. A system is to be implemented which can run on the university’s library LAN.
2. A bar code reader should be used to facilitate the process of issue and return of books.
3. The system shall be able to generate login ID and password to the system operator.
4. There are three types of members in the library: students, faculty and employee.
5. The administrator shall be able to maintain details of all the books.
6. The administrator shall be able to maintain details of all the members of the library.
7. The library staff shall be able to issue the books to each of its members.
8. The library staff shall be able to accept the issued books from each of its members.
9. The maximum number of books that can be issued to the student is 5 and to faculty and
employees is 10.
10. The system shall calculate fine for late return of books only for students.
11. The library staff shall be able to reserve a book for 24 h.
12. The student/faculty/employee shall access LMS on the university’s library LAN to search
the availability of a book from the library.
13. The system shall be able to provide the availability of a particular book.
14. The system shall be able to provide the availability of number of copies of a particular book.
15. The system should also be able to generate reports like:
(i) Details of all books in the library
 Author-wise
 Publisher-wise
 Title-wise
 Subject-wise
(ii) Details of all members.
(iii) Details of books issued to members.
(iv) Status of fine, member-wise, wherever applicable.
Figure 3.3 Initial requirement document for library management system.
 Software Requirements Elicitation and Analysis  73

3.5 Use Case Approach

The use case approach is primarily designed for object-oriented systems. However, the same may
also be used for traditional systems to represent and analyse requirements and for modelling
them in a systematic way. For many years, requirement writers used to write stories to specify
the expected behaviour of the proposed software system and its interactions with the external
world. Jacobson et al. (1999) formalized this story-writing approach into a more systematic and
disciplined use case approach. They designed a UML for the software development of object-
oriented systems. The use cases address only the functional requirements which explain the
expectations of users sitting outside the system. Functional requirements express “what do we
expect from the system” without bothering about “how it will be implemented”. The use cases
capture the expectations in terms of achieving goals and interactions of the users with the system.
Many persons are not able to differentiate amongst the use case, use case scenario and use case
diagram, and use these terms interchangeably. However, all the three terms are different. Use
cases are structured outlines or templates for the description of requirements, written in a natural
language like English. A use case scenario is an instance of a use case. It represents a path
through a use case. Use case diagrams are graphical representations that may be decomposed
into further level of abstraction.

3.5.1 Use Cases and Actors

Use cases and actors are used to define the scope of the system we are planning to build. Use
cases incorporate anything that is within the system, but and actors include anything that is
external to the system. We identify actors and use cases for the system under development. To
do this, a proper understanding of the system is essential. A use case is a description of a system
in terms of a sequence of actions.
A use case is initiated by an actor with a specific purpose in mind and completes successfully
when that purpose is achieved. The use case describes the sequence of interactions between actors
and the system to fulfil the desired purpose. It is nothing but a high-level piece of functionality
that the system will provide. It includes a main sequence which a system will follow when an
actor interacts with the system. It also includes possible alternative sequences which may occur
depending on the interaction and input conditions. Fournier (2009) has rightly given his views
about use cases as:
The real value of a use case is the dynamic relationship between the actor and the system. A
well written use case clarifies how a system is used by the actor for a given goal or reason. If
there are any questions about what a system does to provide some specific value to someone or
something outside the system, including conditional behaviour and handling conditions of when
something goes wrong, the use case is the place to find the answer.

A use case describes who (any user) does what (interaction) with the system, for what goal,
without considering the internal details of the system. The use cases are written in a simple
language which should be understandable to every stakeholder. There is no standard outline for
a use case. However, a few templates are available in the literature. Requirements are captured
in a systematic way and discipline the requirement writers to follow a specified format.
74  Object-Oriented Software Engineering

An actor is someone or something that interacts with the system and lies outside the system.
The actor may be users of the system, customers, persons giving information to the system or
any external system providing data. All stakeholders on the customer’s site may be treated as
actors if they wish to interact with the system. Hence, everything that is outside the system and
wishes to interact with the system is known as an actor.

3.5.2 Identification of Actors

An actor interacts with the system with a particular purpose. The actor may be a person or
external system. We should not confuse the actors with devices they use. Devices may help the
actors to interact with the system and they are not the actors themselves. We use computers with
the help of a keyboard, but the keyboard is not a user (actor), we are the user. Bittner and Spence
(2003) have explained the concept as:
The purpose of devices is to support some required behaviors of the system, but devices do
not define the requirements of the system. Often systems must produce a printed report of
information that it contains. We may want to show printer as an actor that then forwards the
report to the real actor. This is not correct, printer is not an actor, it is just a mechanism for
conveying information.

We consider the LMS and identify the following actors:

(i) Administrator
(ii) Data entry operator
(iii) Librarian
(iv) Library staff
(v) Faculty
(vi) Student
(vii) Employee
There are two types of actors—primary actors and secondary actors. Primary actors are the
persons who will use the system. Customers are the primary actors for whom the system is
built. Secondary actors are the persons who will maintain or monitor the system. For example,
administrator is a secondary actor.
The identification of actors with their specified roles may define the scope of the system for
every actor and expected actions. An actor may interact with one or more use cases depending
on its defined role in the system.

3.5.3 Identification of Use Cases

Use cases describe the functionality of the system. To achieve that functionality, actors interact
with the system with a defined purpose. An actor acts from the outside and provides some
input(s) to the system. One or more output may be generated by the system after such interaction
of actors. From the IRD, we create use cases for the system. Some guidelines for the creation of
use cases are given as:
 Software Requirements Elicitation and Analysis  75
(i) Every specified functionality should have a use case.
(ii) A unique name is assigned to a use case. The name should be meaningful and should
be able to indicate the purpose of a use case.
(iii) One or more actors may interact with a use case.
(iv) The use case should describe the sequence of actions.
(v) The use case is initiated by an actor with a specified purpose.
(vi) Role of actors must be defined clearly.
(vii) The use case should represent a complete and meaningful flow of events.
As explained earlier, we should always remember that use cases describe who (actor) does what
(interaction) with the system, for what goal, without considering the internal details of the system.
In the LMS, we may identify the following use cases from the IRD:
 Maintain book details
 Maintain student details
 Maintain faculty/employee details
 Maintain login details
 Issue book
 Return book
 Fine calculation
 Reserve book
 Query book
 Search book
 Report generation

3.5.4 Defining Relationships between Use Cases

The use case diagram may model two kinds of relationships, namely, extend and include.

Extend Relationship
Extend relationship is used to model the occurrence of some optional, alternative or special part
of the use case. This relationship is used to extend the functionality of the original use cases.
The new use case is inserted into the original use case. The procedure when the extended use
case is inserted into the original is as follows:
1. The original use case executes in usual manner to the point where the new use case has
to be inserted.
2. At this point, the new use case is inserted and executed.
3. After the inserted use case completes, the original use case resumes again.
For example, in the LMS, the concept of extend can be observed when a student returns the
book after the due date. The fine is calculated for late return of the book. We can represent fine
calculation use case as a new use case that extends return book use case. The fine calculation
use case is called whenever the book is returned after the due date by the student. The example
of extend relationship for the LMS is shown in Figure 3.4.
76  Object-Oriented Software Engineering

Figure 3.4 Extend relationship.

Include Relationship
The redundant and repeated functionalities amongst use cases can be modelled into include
relationship. Thus, the redundancies can be grouped into a single use case. In order to use
include relationship, there must be common text in two or more use cases. As in the case of
extend relationship, the new use case is inserted into the original use case. The procedure when
the included use case is inserted into the original is the same as given in the extend relationship.
For example, in employee management system, print use case is required by three use cases—
salary generation, appraisal and generate reports (see Figure 3.5).

Figure 3.5 Include relationship.

3.5.5 Use Case Diagram

Use case diagram represents the top view of the system. The use cases reside within the system
and the actors act from outside the system. The use case diagram is also used to present
functionality of the system, but for proper explanation, it should read along with use cases. The
use case diagram may also be decomposed into further level of abstraction. It also shows the
relationship of use cases and actors. It also explains what happens when an actor interacts with
the system. The components of the use case diagram are given in Figure 3.6.
An actor is represented by a stick figure (even non-human one) and a use case by an oval
labelled with the name of the use case. The relationship between an actor and a use case is
shown by an arrow. For small systems, one use case diagram may be sufficient to represent the
 Software Requirements Elicitation and Analysis  77

Figure 3.6 Components of use case.

whole system. However, for a large system, we may have to draw many use case diagrams to
represent various portions of the system. The use case diagram of the LMS is given in Figure 3.7.

Figure 3.7 Use case diagram for library management system.

78  Object-Oriented Software Engineering

3.5.6 Use Case Description

Actors may interact with one or more use cases for specific purposes. Each actor gives some
input to the system and expects the system to respond accordingly. All steps which are required
to achieve the purpose constitute a flow. There are two types of flows:
1. Basic flow: It is the main flow and describes the sequence of events that takes place
most of the time between actor and the system to achieve the purpose of the use case.
2. Alternative flows: If the basic flow is not successful due to any condition, the system
takes an alternative flow. An alternative flow may occur due to failure of an expected
service because of occurrence of exceptions/errors. There may be more than one
alternative flow of a use case, which may not occur most of the time. Any alternative
flow takes place under certain conditions in order to fulfil the purpose of a use case.
There is no standard template for writing use case description. Jacobson et al. (1999) have given
a template for writing use cases which is given in Table 3.3. This captures the requirements in
a disciplined and effective way and has become a popular format. Another similar template is
also given in Table 3.4 which is also used by many software organizations (Cockburn, 2001;
Quatrani, 2003).

Table 3.3 Jacobson’s use case template

1. Brief description: Describe a quick background of the use case.
2. Actors: List the actors that interact and participate in this use case.
3. Flow of events:
3.1. Basic flow: List the primary events that will occur when this use case is executed.
3.2. Alternative flows: Any subsidiary events that can occur in the use case should be separately
listed. List each such event as an alternative flow. A use case can have as many alternative flows
as required.
4. Special requirements: Business rules for the basic and alternative flow should be listed as special
requirements in the use case narration. These business rules will also be used for writing test cases.
Both success and failure scenarios should be described here.
5. Precondition: Preconditions that need to be satisfied for the use case to perform.
6. Postcondition: Define the different states in which we expect the system to be in, after the use
case executes.
7. Extension points: List of related use cases, if any.

Table 3.4 Alternative use case template

1. Introduction: Describe the brief purpose of the use case.
2. Actors: List the actors that interact and participate in this use case.
3. Precondition: Condition that need to be satisfied for the use case to execute.
4. Postcondition: After the execution of the use case, different states of the systems are defined
here.
5. Flow of events:
5.1. Basic flow: List the primary events that will occur when this use case is executed.
5.2. Alternative flow: Any other possible flow in this use case, if there, should be separately
listed. A use case may have many alternative flows.
6. Special requirements: Business rules for the basic and alternative flows should be listed as
special requirements. Both success and failure scenarios should be described.
7. Associated use cases: List the related use cases, if any.
 Software Requirements Elicitation and Analysis  79
In the template, we have to list the actors that interact and participate in the use case.
Preconditions, if any, are required to be specified for the use case to perform. If the precondition
is not true, the use case cannot start its function. Similarly, postconditions are also important and
are to be specified in the use case template. They define the different states in which we expect
the system to be in, after the execution of the use case. Basic and alternative flows are required
to be written step by step and with simple and short sentences. We should write the basic flow
independent of the alternative flows and no knowledge of alternative flows is considered. The
basic flow must be competed in itself without reference to the alternative flows. The alternative
flow knows the details of when and where it is applicable which is opposite to the basic flow. It
inserts into the basic flow when a particular condition is true (Bittner and Spence, 2003).
Special requirements are specified in the use case. This may include business rules for the
basic and alternative flow execution. All possible conditions need to be specified. We also have
to write related use cases which may give an idea about the use case relationships with other
associated use cases. The issue book use case of the LMS is given in Table 3.5.

Table 3.5 Use case descriptions of issue book use case

Introduction: This use case documents the steps that must be followed in order to get a book issued.
Actors
Administrator
Library staff
Librarian
Precondition: The administrator/library staff/librarian must be logged onto the system before the use case
begins.
Postcondition: If the use case is successful, a book is issued to the student/faculty/employee and the
database is updated, else the system state remains unchanged.
Event Flow
Basic Flow
1. The student/faculty/employee membership number is read through the bar code reader.
2. The system displays information about the student/faculty/employee.
3. Book information is read through the bar code reader.
4. The book is issued for the specified number of days and the return date of the book is calculated and
stamped on the book.
5. The book and student/faculty/employee information is saved into the database.
Alternative Flow 1: Unauthorized student/faculty/employee
If the system does not validate the student/faculty/employee membership number (due to membership expiry or
any other reason), then an error message is flagged and the use case returns to the beginning of the basic flow.
Alternative Flow 2: Account is full
If the student/faculty/employee has requested a book and the account is full, i.e. he/she has already maximum
number of books issued on his/her name, then the request for issue is denied and the use case ends.
Alternative Flow 3: User exits
This allows the user to exit at any time during the use case. The use case ends.
Special requirement
None
Associated use case
Login
80  Object-Oriented Software Engineering

EXAMPLE 3.2 Consider the case study of the LMS given in Section 3.1. Give use case
description of return a book use case.
Solution The use case description of return book is given in Table 3.6.

Table 3.6 Use case description of return book use case

Introduction: This use case documents the steps that must be followed in order to return a book.
Actors
Administrator
Library staff
Precondition: The administrator/library staff must be logged onto the system before the use case begins.
Postcondition: If the use case is successful, the book is returned back to the library and if needed, the
“fine calculation” use case is called, otherwise the system state is unchanged.
Event Flow
Basic Flow
1. The book information is read from the bar code of the book through the bar code reader.
2. The student/faculty/employee detail on whose name the books were issued is displayed on the
system. The date of issue and return is also displayed.
3. The administrator/library staff checks the stamp on the book to check the duration of issue of
the book.
4. The database is updated and the book status is updated.
5. The date stamp on the book is cancelled.
Alternative Flows
Alternative Flow 1: Late return of book
If the duration for which the book has been kept by the student is more than 15 days, then a fine
calculation use case is called. After the execution of fine calculation use case, the original use case
resumes the basic flow.
Alternative Flow 2: User exits
This allows the user to exit at any time during the use case. The use case ends.
Special requirement
None
Associated use case
Login, fine calculation

3.5.7 Generation of Scenario Diagrams

A use case scenario is an instance of a use case. This is nothing but a path through a use case. A
use case may have many paths. A basic flow is a path which is expected to be traversed most of
the time and becomes a scenario of the use case. Every alternative path also generates a scenario.
We may have various combinations of basic and/or alternative flows and every combination leads
to a path in a use case. The basic and alternative flows for a use case are shown in Figure 3.8.
The basic flow is represented by a straight arrow and the alternative flows by the curves.
Some alternative flows return to the basic flow, while others end the use case. Preconditions and
postconditions are checked at start and end points of a use case, respectively. We consider the
issue a book use case, and its basic and alternative flows are shown in Figure 3.9.
 Software Requirements Elicitation and Analysis  81

Figure 3.8 Basic and alternative flows with pre- and postconditions.

Figure 3.9 Basic and alternative flows for issue book use case.

3.5.8 Creation of Use Case Scenario Matrix

Many scenarios are generated using the use case scenario diagram due to basic flow(s), alternative
flows and various combinations of basic and alternative flows. A scenario matrix represents
all scenarios of the use case scenario diagram. The scenario matrix of the use case scenario
diagram given in Figure 3.8 is given in Table 3.7.
82  Object-Oriented Software Engineering

Table 3.7 Scenario matrix for the flow of events shown in Figure 3.8
Scenario 1 Basic flow
Scenario 2 Basic flow Alternative flow 1
Scenario 3 Basic flow Alternative flow 1 Alternative flow 2
Scenario 4 Basic flow Alternative flow 3
Scenario 5 Basic flow Alternative flow 3 Alternative flow 4
Scenario 6 Basic flow Alternative flow 3 Alternative flow 1
Scenario 7 Basic flow Alternative flow 3 Alternative flow 1 Alternative flow 2

The scenario matrix shows all instances of a use case. It represents all possible paths that
may be generated in a use case. These instances (paths) may help us to generate test cases. After
identification of inputs for a use case and its instances (using scenario matrix), test cases are
generated. Hence, scenarios help us to generate test cases from the use cases.

EXAMPLE 3.3 Consider the use case of return book of the LMS case study given in
Section 3.1. Draw the use case scenario diagram for it.
Solution Use case scenario diagram for the return book use case is given in Figure 3.10.

Figure 3.10 Basic and alternative flows for return book use case.

3.6 Characteristics of a Good Requirement

A requirement should be considered as a good requirement if it has the following characteristics:
 Correct
 Unambiguous
 Software Requirements Elicitation and Analysis  83

 Complete
 Consistent
 Verifiable
 Modifiable
 Clear (concise, terse, simple, precise)
 Feasible (realistic, possible)
 Necessary
 Understandable
Each of the above-mentioned characteristics is discussed here as per details given in IEEE
(2001), Thayer and Dorfman (1997) and Young (2001).

3.6.1 Correct
If a requirement addresses a factual situation(s), then such situation(s) must be factually correct.
Requirement 1: A member of a library gets five books issued for one month.
There are different types of members in a library like faculty, students and employees.
Hence, five books figure and issued duration may depend on the type of member. So, five books
and one month figures are incorrect.

3.6.2 Unambiguous
The requirement should have only one interpretation. If the requirement is shown to many
people, all should have the same interpretation. If there are more than one interpretation, then
that requirement is probably ambiguous. Sometimes acronyms are used in a requirement and
may become a reason for ambiguity. Consider the following requirement:
Requirement 2: Login ID shall be alphanumeric of length in the range of 4 to 15
characters. Special characters and blank spaces are not allowed.
There is an ambiguity in the above requirement; it is not clear what will the system do.
(i) Do not allow the user to enter blank spaces or special characters.
(ii) Display an error message if the user enters special characters or blank spaces.
(iii) Automatically it will not include special characters and blank spaces.
Hence, the modified requirement shall be given as:
Requirement 2: Login ID shall be alphanumeric of length in the range of 4 to 15
characters. Special characters and blank spaces are not allowed. The system will not
allow the user to enter blank spaces or special characters.
Requirements are written in natural languages (e.g. English) which are inherently ambiguous.
Care should be taken, while writing requirements, in order to minimize the ambiguities.

3.6.3 Complete
A requirement should specify all conditions that may occur.
84  Object-Oriented Software Engineering

Requirement 3: The student shall access the LMS on the university’s library LAN to
search the availability of a book from the library.
What will happen to the other members of the library? Will they be able to search a book using
the university’s library LAN? If yes, the sentence should be as follows:
Requirement 3: The student/faculty/employee shall access the LMS on the university’s
library LAN to search the availability of a book from the library.
If we do not want to extend this facility to the other members (faculty/employee), then the
sentence should be as follows:
Requirement 3: The student shall access the LMS on the university’s library LAN to
search the availability of a book from the library. However, the faculty and employees
shall not access this search facility on the university’s library LAN.

3.6.4 Consistent
There shall not be any conflicts between the requirements.
Requirement 4: New Password: Alphanumeric of length in the range of 4 to 15
characters. Blank spaces are not allowed. However, special characters are allowed.
Requirement 5: Confirm Password: Alphanumeric of length in the range of 4 to 15
characters. Blank spaces are allowed. However, special characters are not allowed.
There are inconsistencies between Requirement 4 and Requirement 5. Requirement 4 does
not allow blank spaces and does allow special characters in password format, whereas
Requirement 5 does allow blank spaces and does not allow special characters in the password
format. Consistencies should be maintained amongst requirements and conflicting requirements
must be corrected immediately.

3.6.5 Verifiable
A requirement should be verifiable. It should not use words like “works well”, “good human
interface” and “shall usually happen”. Requirements using these words are not verifiable because
the terms good, well and usually are not quantifiable. These terms have different meanings to
different persons. Consider the following requirement:
Requirement 6: Every member should be able to quickly search a book using the
university’s library LAN.
The word “quickly” is not verifiable. It has different meanings for different persons. This
requirement is not verifiable. The modified requirement may be given as:
Requirement 6: Every member should be able to search a book within 5 seconds using
the university’s library LAN.
Ambiguous words like robust, safe, accurate, flexible, reliable, safely, quickly, etc. should be
avoided in framing requirements. These words are not verifiable and also make the sentence
ambiguous.
 Software Requirements Elicitation and Analysis  85

3.6.6 Modifiable
A requirement is modifiable if changes can be made easily, completely and consistently while
retaining its structure and style. The requirement should also be non-redundant. Redundancy
itself is not an error, but it can easily lead to errors. If a change is made at one place and
the other place is ignored, it leads to inconsistency of requirements. Whenever redundancy is
necessary, it should be written in a table so that changes shall be made at all places.

3.6.7 Clear
A requirement should be written clearly, precisely and in simple short sentences. Consider the
following requirement:
Requirement 7: Login ID should be of specified range of 4 to 15 and alphabets, numeric
letters should be used in a login ID. Special characters should not be used however we
should be able to differentiate between alphabets and special characters, blank spaces
which are sometimes treated as special characters should also not be allowed.
A simple requirement may be written clearly as:
Requirement 7: Login ID: Alphanumeric of length in the range of 4 to 15 characters.
Special characters and blank spaces are not allowed.
Hence, sentences should be simple, short, clear, precise and unambiguous.

3.6.8 Feasible
A requirement shall be feasible if and only if it is implementable within given time, resources,
money and technology.
Requirement 8: A library management system shall provide smart card with web-
enabled services to every member. Digital versions of books shall be available to every
member at any time and from any place using smart card.
This requirement is technically feasible but difficult to implement within short time and limited
budget.

3.6.9 Necessary
A requirement is unnecessary if it is not requested by any stakeholder. Moreover, removing such
a requirement should also not affect the present system.
This type of requirement may be added by developers with the assumption that it may be
needed by stakeholders. If there is no use of such a requirement and if it is not important for the
system, that requirement may be removed from the list.

3.6.10 Understandable
Requirements should be written in simple, short and clear sentences. Standard style and
conventions should be used. The word “shall” should be used instead of “will”, “must” or “may”.
86  Object-Oriented Software Engineering

Sentences should also be grammatically correct and unambiguous. Difficult words should be
avoided and their simple synonyms should be used.

3.7 Software Requirements Specification Document

After requirements elicitation, we prepare the IRD. This document gives an overview of the
system. Now a detailed document is prepared on the basis of the IRD and is called software
requirements specification (SRS) document. This document is used as a legal document which
acts as a contract between customers and developers. On the basis of this document, the
developers know what to build, and the customers know what to expect, and this document
may also be used to validate that the built system satisfies the requirements. We use IEEE
recommended practice for software requirements specifications—IEEE standard 830-1998 for
preparing the SRS document.

3.7.1 Nature of the SRS Document

The following issues shall be addressed by the SRS writer:
1. Functionality: What functions the software is supposed to perform?
2. External interfaces: With what all external entities does the system interact? This may
include the number of users, response time, recovery time, processing time, etc.
3. Performance: How does the software address performance issues? This may include
people, hardware, external databases, etc.
4. Quality attributes: What are the considerations for non-functional requirements? These
may include availability, correctness, maintainability, portability, reliability, security,
testability, etc. These non-functional requirements should also be properly placed in the
SRS document.
5. Design constraints imposed on implementation: All constraints should be highlighted
which have an impact on implementation. This may include limitations of the operating
environment, programming language, database, resources, policies for database
integrity, etc.
The SRS writer(s) should not include design and implementation details. It should be written in
a simple, clear and unambiguous language which may be understandable to all developers and
customers.

3.7.2 Organization of the SRS Document

We have used IEEE recommended practice for SRS which is known as IEEE Std. 830-1998.
The standard was approved on June 25, 1998. The document is used to specify requirements of
the software which is to be developed. It helps the customers to know what they want from the
proposed software system. It also helps the developer to understand exactly what the customer
wants. There are four sections of the SRS document and are given in Table 3.8 (IEEE, 1998).
The first two sections are the same for all projects, but Section 3 provides special tailoring as
mentioned “specific requirements” for different projects.
 Software Requirements Elicitation and Analysis  87
Table 3.8 SRS document outline as per IEEE Std 830-1998
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective
2.1.1 System interfaces
2.1.2 User interfaces
2.1.3 Hardware interfaces
2.1.4 Software interfaces
2.1.5 Communications interfaces
2.1.6 Memory constraints
2.1.7 Operations
2.1.8 Site adaptation requirements
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
2.6 Apportioning of requirements
3. Specific requirements
3.1 External interfaces
3.2 Functions
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design constraints
3.5.1 Standards compliance
3.6 Software system attributes
3.6.1 Reliability
3.6.2 Availability
3.6.3 Security
3.6.4 Maintainability
3.6.5 Portability
3.7 Organizing the specific requirements
3.7.1 System mode
3.7.2 User class
3.7.3 Objects
3.7.4 Feature
3.7.5 Stimulus
3.7.6 Response
3.7.7 Functional hierarchy
3.8 Additional comments
4. Supporting information

These sections are discussed below along with their section numbers as in Table 3.8. The
concepts are also explained with the help of the case study of the LMS. The complete SRS is
given in the Appendix.
88  Object-Oriented Software Engineering

1. Introduction
This section gives the overview of the complete SRS document.
1.1 Purpose
We should describe the purpose of the SRS document and also list the intended audience for the
document. The purpose of the LMS is given as:

1.1 Purpose
The library management system (LMS) maintains the information about various books available
in the library. The LMS also maintains records of all the students, faculty and employees in
the university. These records are maintained in order to provide membership to them.

1.2 Scope
The task of this subsection is to:
(i) Assign a name to the software under development.
(ii) List the functions which will be provided and also those functions which the software
will not do.
(iii) Explain the applications of the software along with possible benefits and objectives.
(iv) Maintain consistency amongst statements.
The scope of the LMS is given as:

1.2 Scope
The name of the software is library management system (LMS). The system will be referred
to as LMS in rest of the SRS. The proposed LMS must be able to perform the following
functions:
Dos
1. Issue of login ID and password to system operators.
2. Maintain details of books available in the library.
3. Maintain details of the students in the university to provide student membership.
4. Maintain details of the faculty and employees in the university to provide faculty and
employees membership.
5. Issue a book.
6. Bring a book back, and calculates fine if the book is being returned after the specified
due date.
7. Reserve a book.
8. Provide search facility to check the availability of a book in the library.
9. Generate the following reports:
(a) List of books issued by a member.
(b) Details of books issued and returned on daily basis.
(c) Receipt of fine.
 Software Requirements Elicitation and Analysis  89

(d) Total available books in the library.

(e) List of library members along with issued books.
(f) List of available books in the library:
 Author-wise
 Book title-wise
 Publisher-wise
 Subject-wise
Don’ts
1. Periodicals section is not covered.
2. Book bank (if any) is not covered.
3. Records of digital books are not available.
4. Purchase of books facility is not available.
Benefits
The LMS provides the following benefits:
1. Easy searching of books.
2. Efficient issue and return of books.
3. Accurate and automated fine calculation.
4. Printing of reports.

1.3 Definitions, Acronyms and Abbreviations

Define all terms, acronyms and abbreviations. This may help to make the SRS document more
readable, understandable and clear to all the stakeholders. The definitions and acronyms used in
the LMS are given as:

1.3 Definitions, Acronyms and Abbreviations

SRS: Software requirement specification
LMS: Library management system
System operator: System administrator, library staff, data entry operator
RAM: Random access memory
Accession number: It is a unique sequence number allocated to each book in the catalog.
Student: Any candidate admitted in a programme offered by a school.
System administrator/Administrator: User having all the privileges to operate the LMS.
Data entry operator (DEO): User having privileges to maintain book, student and faculty/
employee details.
Library staff: User having privilege to issue, return, reserve and query books.
Faculty: Teaching staff of the university—Professor, Associate Professor, Assistant Professor
School: Academic unit that offers various programmes
90  Object-Oriented Software Engineering

1.4 References
This subsection provide a list of all documents including books and research papers referenced
anywhere in the SRS document. The referenced material used in LMS is given as:

1.4 References
(a) Software Engineering by K.K. Aggarwal & Yogesh Singh, New Age Publishing House,
3rd Edition, 2008.
(b) IEEE Recommended Practice for Software Requirements Specifications— IEEE
Std 830-1998.
(c) IEEE Standard for Software Test Documentation—IEEE Std. 829-1998.

1.5 Overview
This subsection of the SRS gives the overview of the software system. Explain what the rest of
the SRS contains and also gives details about the organization of the SRS document.
2. Overall Description
This section discusses the general factors which affect the requirements, and the final product
specific requirements are not discussed. This section may help to write specific requirements of
section 3 of the SRS document. The overview of the LMS is given as:

2. Overall Description
The LMS maintains records of books in the library and membership details of students,
faculty and employees in the university. It is assumed that approved books have already been
purchased by the acquisition section. It is also assumed that the student has already been
admitted in the university for a specific programme. The system administrator will receive
lists of the admitted students (school-wise and programme-wise) from the academic section.
The establishment section will provide the list of the faculty and employees appointed in the
university.
The LMS issues books to students, faculty and employees and brings the same back from
them. The LMS generates fine if the book is returned by a student after the due date. It also
allows students, faculty and employee to reserve a book. The student/faculty/employee can
access LMS on the university’s library LAN in order to search the availability of the book
from the library.
The administrator/DEO will have to maintain the following information:
 Book details
 Student membership details
 Faculty and employee membership details
The administrator/library staff will perform the following functions:
 Issue a book
 Return a book
 Reserve a book
 Query a book
 Software Requirements Elicitation and Analysis  91

 Generate reports
List of books issued to a member
Details of books issued and returned on daily basis
Receipt of fine
Total available books in the library
List of library members along with issued books
The administrator/student/faculty/employee requires the following information from the
system:
 List of available books in the library:
Author-wise
Book title-wise
Publisher-wise
Subject-wise

2.1 Product Perspective

This subsection puts the product into perspective with other related products. We should specify
the environment which may be web-enabled, stand-alone system, or usage of local area network.
A block diagram showing the major components of the large system, interconnections and
external interfaces can be helpful. The product perspective of LMS is given as:

2.1 Product Perspective

The LMS shall be developed using client/server architecture and will be compatible with
Microsoft Windows Operating System. The front-end of the system will be developed using
Visual Basic 6.0 and the back-end will be developed using MS SQL Server 2005.

2.1.1 System Interfaces

System interfaces are addressed which are required by the product during its usage.
2.1.2 User Interfaces
This subsection should specify:
(i) Logical characteristics of each interface between the product and its users.
(ii) How the system can be best used by the user. A list of dos and don’ts for the user may
also be specified.
92  Object-Oriented Software Engineering

The user interfaces of the LMS are given as:

2.1.2 User Interfaces

The LMS will have the following user-friendly and menu-driven interfaces:
(a) Login: to allow the entry of only authorized users through valid login ID and password.
(b) Book details: to maintain book details.
(c) Student membership details: to maintain student membership details.
(d) Faculty/employee membership details: to maintain faculty/employee membership
details.
(e) Issue book: to allow library staff to issue a book from the library.
(f) Return book: to allow library staff to bring a book back to the library.
(g) Reserve book: to allow library staff to reserve a book.
(h) Query book: to check availability of a book in the library.
The software should generate the following information:
(a) Details of books issued and returned on daily basis.
(b) Details of books available in the library.
(c) Details of books issued to a student.
(d) List of library members with issued books.
(e) Receipt of fine

2.1.3 Hardware Interfaces

Logical characteristics of each interface between the software product and the hardware
component is to be specified. For example, issues such as screen resolution, support for printer,
single user/multi-user system, etc. should be addressed. These issues for the LMS are shown as
follows:

2.1.3 Hardware Interfaces

(a) Screen resolution of at least 640 × 480 or above.
(b) Support for printer (dot matrix, deskjet, laserjet).
(c) Computer systems will be in the networked environment as it is a multi-user system.

2.1.4 Software Interfaces

This subsection should specify the interface of the software product with other software
applications. For example, operating system, front end tools, back end tools, the specification
and version number of the software, etc. should also be specified. The software interfaces for
the LMS are given as:

2.1.4 Software Interfaces

(a) MS-Windows Operating System (NT/XP/Vista)
(b) Microsoft Visual Basic 6.0 for designing front-end
(c) MS SQL Server 2005 for back-end
 Software Requirements Elicitation and Analysis  93
2.1.5 Communication Interfaces
This subsection specifies the various interfaces to communication such as local network,
protocol, etc. For example, whether the software product will use LAN, web-enabled services or
stand-alone system. In the LMS, communication is via local area network (LAN).
2.1.6 Memory Constraints
Any constrains related to primary and secondary memories are specified. For example, for the
LMS, we may specify “At least 512 MB RAM and 500 MB space of hard disk will be required
to run the software”.
2.1.7 Operations
Various operations in the user’s organization are specified. This may include data processing
support functions, backup and recovery operations.
2.1.8 Site Adaptation Requirements
Any specific requirements related to the hardware and software interfaces at site are to be
specified in this subsection. In the LMS, the terminal at the client site will have to support the
hardware and software interfaces specified in sections 2.1.3 and 2.1.4, respectively.
2.2 Product Functions
This section should list the summary of all functions that the software shall perform. Functions
should be listed in a simple and clear language and must be understandable to the customer. The
product functions for the LMS are given as:

2.2 Product Functions

The LMS will allow access only to the authorized users with specific roles (system administrator,
library staff, DEO and student). Depending upon the user’s role, he/she will be able to access
only specific modules of the system.
A summary of major functions that the LMS shall perform includes:
 A login facility for enabling only authorized access to the system.
 The system administrator/DEO will be able to add, modify, delete or view book,
student, faculty/employee and login information.
 The system administrator/library staff will be able to issue, bring back, and reserve
book.
 The system administrator/library staff will be able to query a book in order to check
the availability of the book in the library.
 The system administrator/students/faculty/employee will be able to search a book from
the library catalogue (author-wise, title-wise and publisher-wise).
 The system administrator/library staff will be able to generate various reports from the
LMS.

2.3 User Characteristics

Characteristics of users in terms of their qualification, skills sets and experience should be
specified in this subsection. The user characteristics for the LMS are given as:
94  Object-Oriented Software Engineering

2.3 User Characteristics

Qualification: At least matriculation and comfortable with English.
Experience: Should be well versed/informed about the processes of the university library.
Technical experience: Elementary knowledge of computers.

2.4 Constraints
We may list constraints that may limit the developer’s implementation options. These constraints
may include:
(i) Regulatory policies
(ii) Hardware limitations
(iii) Interface to other applications
(iv) Parallel operations
(v) Audit functions
(vi) Control functions
(vii) Higher-order language requirements
(viii) Protocols
(ix) Reliability requirements
(x) Safety, security and criticality of the application
The constraints for the LMS are given as:

2.4 Constraints
 The software does not maintain records of periodicals.
 There will be only one administrator.
 The delete operation is available to the administrator and DEO. To reduce the complexity
of the system, there is no check on delete operation. Hence, the administrator/DEO
should be very careful before deletion of any record and he/she will be responsible for
data consistency.
 The user will not be allowed to update the primary key.
2.5 Assumptions and Dependencies
This subsection includes assumptions and dependencies for the implementation of the software
product. These assumptions may be very important and may become input for the design and
implementation of the software system.

2.5 Assumptions and Dependencies

 The acquisition section of the library will provide the list of the books purchased by
the library.
 The academic section will provide the list of the admitted students (school-wise and
programme-wise).
 The establishment section will provide the list of the faculty members in various
schools of the university. It will also provide the list of employees working in various
branches such as examination, academics, establishment and schools of the university.
 The login ID and password must be created by the system administrator and communi-
cated to the concerned user confidentially to avoid unauthorized access to the system.
 Software Requirements Elicitation and Analysis  95
2.6 Apportioning of Requirements
This subsection list those requirements that can be delayed and may be incorporated in the
future version of the software system. For the LMS, there is no such requirement.
3. Specific Requirements
All requirements stated in section 2 must be written in detail and at a level sufficient for the
designers to understand and design the system. The testers should test that the requirements are
met by the system. All requirements should conform to the guidelines of good requirements
as discussed in Section 3.6. Some of the characteristics of good requirements are correctness,
completeness, unambiguity, consistence, verifiability, modifiability, traceability, etc.
In addition to the basic format given by IEEE 830-1998, we may also construct Section 3
according to any one of the following additional templates given in Section 3.7 of the SRS.
System Mode
Depending on the mode of operation, we may choose either of the two outlines given in Tables 3.9
and 3.10.

Table 3.9 Template of SRS section 3 organized by mode

3. Specific requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Functional requirements
3.2.1 Mode 1
3.2.1.1 Functional requirement 1.1
.
.
.
3.2.1.n Functional requirement 1.n
3.2.2 Mode 2
.
.
.
3.2.m Mode m
3.2.m.1 Functional requirement m.1
.
.
.
3.2.m.n Functional requirement m.n
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements
96  Object-Oriented Software Engineering

Table 3.10 Another template of SRS section 3 organized by mode

3. Specific requirements
3.1 Functional requirements
3.1.1 Mode 1
3.1.1.1 External interfaces
3.1.1.1.1 User interfaces
3.1.1.1.2 Hardware interfaces
3.1.1.1.3 Software interfaces
3.1.1.1.4 Communications interfaces
3.1.1.2 Functional requirements
3.1.1.2.1 Functional requirement 1
.
.
.
3.1.1.2.n Functional requirement n
3.1.1.3 Performance
3.1.2 Mode 2
.
.
.
3.1.m Mode m

3.2 Design constraints

3.3 Software system attributes
3.4 Other requirements

User Class
Some systems provide different sets of functions to different classes of users. The outline is
given in Table 3.11.

Table 3.11 Template of SRS section 3 organized by user class

3. Specific requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Functional requirements
3.2.1 User class 1
3.2.1.1 Functional requirement 1.1
.
.
.
3.2.1.n Functional requirement 1.n

(Contd.)
 Software Requirements Elicitation and Analysis  97
Table 3.11 Template of SRS section 3 organized by user class (Contd.)
3.2.2 User class 2
.
.
.
3.2.m User class m
3.2.m.1 Functional requirement m.1
.
.
.
3.2.m.n Functional requirement m.n
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements

Objects
The outline of arranging section 3 by objects is given in Table 3.12.

Table 3.12 Template of SRS section 3 organized by object

3. Specific requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Classes/Objects
3.2.1 Class/Object 1
3.2.1.1 Attributes (direct or inherited)
3.2.1.1.1 Attribute 1
.
.
.
3.2.1.1.n Attribute n
3.2.1.2 Functions (services, methods, direct or inherited)
3.2.1.2.1 Functional requirement 1.1
.
.
.
3.2.1.2.m Functional requirement 1.m
3.2.1.3 Messages (communications received or sent)
3.2.2 Class/Object 2
.
.
.
3.2.p Class/Object p
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements
98  Object-Oriented Software Engineering

Feature
A feature is an externally desired service by the system that may require a sequence of inputs to
affect the desired result. Each feature is generally described as a sequence of stimulus response
pairs. The outline is given in Table 3.13.

Table 3.13 Template of SRS section 3 organized by feature

3. Specific requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 System features
3.2.1 System feature 1
3.2.1.1 Introduction/Purpose of feature
3.2.1.2 Stimulus/Response sequence
3.2.1.3 Associated functional requirements
3.2.1.3.1 Functional requirement 1
.
.
.
3.2.1.3.n Functional requirement n
3.2.2 System feature 2
.
.
.
3.2.m System feature m
.
.
.
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements

Stimulus
Some systems are best organized by describing their functions in terms of stimuli. The outline
is given in Table 3.14.

Table 3.14 Template of SRS section 3 organized by stimulus

3. Specific requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces

(Contd.)
 Software Requirements Elicitation and Analysis  99
Table 3.14 Template of SRS section 3 organized by stimulus (Contd.)
3.2 Functional requirements
3.2.1 Stimulus 1
3.2.1.1 Functional requirement 1.1
.
.
.
3.2.1.n Functional requirement 1.n
3.2.2 Stimulus 2
.
.
.
3.2.m Stimulus m
3.2.m.1 Functional requirement m.1
.
.
.
3.2.m.n Functional requirement m.n
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements

Response
Some systems are best organized by describing their functions in support of the generation of a
response. The outline is the same as given in Table 3.14 (stimulus is replaced by response).
Functional Hierarchy
Functions are organized in terms of their hierarchy with respect to either common inputs,
common outputs or common internal data access. Data flow diagrams and data dictionaries
may be used to show the relationships amongst the functions and data. The outline is given in
Table 3.15.

Table 3.15 Template of SRS section 3 organized by functional hierarchy

3. Specific requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Functional requirements
3.2.1 Information flows
3.2.1.1 Data flow diagram 1
3.2.1.1.1 Data entities
3.2.1.1.2 Pertinent processes
3.2.1.1.3 Topology

(Contd.)
100  Object-Oriented Software Engineering

Table 3.15 Template of SRS section 3 organized by functional hierarchy (Contd.)

3.2.1.2 Data flow diagram 2
3.2.1.2.1 Data entities
3.2.1.2.2 Pertinent processes
3.2.1.2.3 Topology
.
.
.
3.2.1.n Data flow diagram n
3.2.1.n.1 Data entities
3.2.1.n.2 Pertinent processes
3.2.1.n.3 Topology
3.2.2 Process descriptions
3.2.2.1 Process 1
3.2.2.1.1 Input data entities
3.2.2.1.2 Algorithm or formula of process
3.2.2.1.3 Affected data entities
3.2.2.2 Process 2
3.2.2.2.1 Input data entities
3.2.2.2.2 Algorithm or formula of process
3.2.2.2.3 Affected data entities
.
.
.
3.2.2.m Process m
3.2.2.m.1 Input data entities
3.2.2.m.2 Algorithm or formula of process
3.2.2.m.3 Affected data entities
3.2.3 Data construct specifications
3.2.3.1 Construct 1
3.2.3.1.1 Record type
3.2.3.1.2 Constituent fields
3.2.3.2 Construct 2
3.2.3.2.1 Record type
3.2.3.2.2 Constituent fields
.
.
.
3.2.3.p Construct p
3.2.3.p.1 Record type
3.2.3.p.2 Constituent fields
3.2.4 Data dictionary
3.2.4.1 Data element 1
3.2.4.1.1 Name
3.2.4.1.2 Representation
3.2.4.1.3 Units/Format
3.2.4.1.4 Precision/Accuracy
3.2.4.1.5 Range
3.2.4.2 Data element 2
3.2.4.2.1 Name
3.2.4.2.2 Representation
(Contd.)
 Software Requirements Elicitation and Analysis  101
Table 3.15 Template of SRS section 3 organized by functional hierarchy (Contd.)
3.2.4.2.3 Units/Format
3.2.4.2.4 Precision/Accuracy
3.2.4.2.5 Range
.
.
.
3.2.4.q Data element q
3.2.4.q.1 Name
3.2.4.q.2 Representation
3.2.4.q.3 Units/Format
3.2.4.q.4 Precision/Accuracy
3.2.4.q.5 Range
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements

3.1 External Interfaces

External interfaces provide mechanisms to enter data into the system. Sometimes, we may also
specify the outputs from the software system. We may use different types of forms for the entry
of the data. A few forms of the LMS are given that are used to enter data into the LMS. Formats
for various fields are also defined.
The specific requirements for issuing book in the LMS following the basic format of SRS
given in IEEE Std 830-1998 are given as follows:

3. Specific Requirements
This section contains the software requirements in detail along with the various forms to be
developed.
Issue Book
This form will be accessible only to the system administrator and library staff. It will allow
him/her to issue existing book(s) to the student(s).
102  Object-Oriented Software Engineering

Various fields available on this form will be:

 Membership ID: Numeric and will have value from 100 to 19999. The system shall
not allow the user to enter non-numeric characters and out of range values.
 Accession number: Numeric and will have value from 10 to 199999. The system shall
not allow the user to enter non-numeric characters and out of range values.
 Title: Alphanumeric of length 3 to 100 characters. Special characters (except brackets)
are not allowed. Numeric data will be allowed. The system shall not allow the user to
enter special characters and out of range values.
 Issue status (the following member information will be displayed):
Accession number: Numeric and will have value from 10 to 199999. The system
shall not allow the user to enter non-numeric characters and out of range values.
Title: Alphanumeric of length 3 to 100 characters. Special characters (except
brackets) are not allowed. Numeric data will be allowed. The system shall not
allow the user to enter special characters and out of range values.
Expected: Date of return. It will be of mm/dd/yyyy format and will have 10
alphanumeric characters. The system shall not allow the user to enter any other
format.
 Reservation status (the following fields will be displayed):
Accession number: Numeric and will have value from 10 to 199999. The system
shall not allow the user to enter non-numeric characters and out of range values.
Title: Alphanumeric of length 3 to 100 characters. Special characters (except
brackets) are not allowed. Numeric data will be allowed. The system shall not
allow the user to enter special characters and out of range values.
Reservation date: It will be of mm/dd/yyyy format. It will have 10 alphanumeric
characters. The system shall not allow the user to enter any other format.
Expected: Date of return. It will be of mm/dd/yyyy format and will have 10
alphanumeric characters. The system shall not allow the user to enter any other
format.

3.2 Functions
Functional requirements define the fundamental actions that must take place in the software
when inputs are accepted, and processed, and outputs are accordingly generated. Generally,
the most popular way to implement this process is to write use case description. The use case
description addresses all actions when an actor interacts with the system for a specified purpose.
We may also include validity checks on inputs, sequencing information about operations, and
error handling/response to abnormal situations. A few use case descriptions of LMS are given
below in the specified template. The validity check and error handling information is also
provided.
 Software Requirements Elicitation and Analysis  103

MAINTAIN BOOK DETAILS

A. Use Case Description
Introduction
This use case documents the steps that the administrator/DEO must follow in order to maintain
book details and add, update, delete and view book information.
Actors
Administrator
Data entry operator
Precondition
The administrator/DEO must be logged onto the system before this use case begins.
Postcondition
If the use case is successful, then the book information is added, updated, deleted or viewed.
Otherwise, the system state is unchanged.
Flow of Events
Basic Flow
This use case starts when the administrator/DEO wishes to add/update/delete/view book
information.
1. The system requests that the administrator/DEO specify the function he/she would like
to perform (either add a book, update a book, delete a book or view a book).
2. Once the administrator/DEO provides the requested information, one of the subflows
is executed.
 If the administrator/DEO selects “Add a Book”, the Add a Book subflow is
executed.
 If the administrator/DEO selects “Update a Book”, the Update a Book subflow is
executed.
 If the administrator/DEO selects “Delete a Book”, the Delete a Book subflow is
executed.
 If the administrator/DEO selects “View a Book”, the View a Book subflow is
executed.
Basic Flow 1: Add a Book
The system requests that the administrator/DEO enter the book information. This includes:
 Accession number (book barcode ID)
 Subject descriptor
 ISBN
 Title
 Language
 Author
 Publisher
Once the administrator/DEO provides the requested information, the book is added to the
system.
Basic Flow 2: Update a Book
1. The system requests that the administrator/DEO enter the accession number.
104  Object-Oriented Software Engineering

2. The administrator/DEO enters the accession number.

3. The system retrieves and displays the book information.
4. The administrator/DEO makes the desired changes to the book information. This
includes any of the information specified in the Add a Book subflow.
5. Once the administrator/DEO updates the necessary information, the system updates
the book information with the updated information.
Basic Flow 3: Delete a Book
1. The system requests that the administrator/DEO specify the accession number.
2. The administrator/DEO enters the accession number. The system retrieves and displays
the required information.
3. The system prompts the administrator/DEO to confirm the deletion of the book record.
4. The administrator/DEO verifies the deletion.
5. The system deletes the record.
Basic Flow 4: View a Book
1. The system requests that the administrator/DEO specify the accession number.
2. The system retrieves and displays the book information.
Alternative Flows
Alternative Flow 1: Invalid Entry
If in the Add a Book or Update a Book flow, the actor enters invalid accession number/ISBN/
title/author/publisher/language/subject descriptor or leaves the accession number/ISBN/title/
author/publisher/language/subject descriptor empty, the system displays an appropriate error
message. The actor returns to the basic flow and may reenter the invalid entry.
Alternative Flow 2: Book Already Exists
If in the Add a Book flow, a book with a specified accession number already exists, the
system displays an error message. The administrator returns to the basic flow and may reenter
the book.
Alternative Flow 3: Book Not Found
If in the Update a Book or Delete a Book or View a Book flow, the book information with
the specified accession number does not exist, the system displays an error message. The
administrator returns to the basic flow and may reenter the accession number.
Alternative Flow 4: Update Cancelled
If in the Update a Book flow, the administrator/DEO decides not to update the book, the
update is cancelled and the Basic Flow is restarted at the beginning.
Alternative Flow 5: Delete Cancelled
If in the Delete a Book flow, the administrator/DEO decides not to delete the book, the delete
is cancelled and the Basic Flow is restarted at the beginning.
Alternative Flow 6: Deletion Not Allowed
If in the Delete a Book flow, issue/return/reserve details of the book selected exist, then the
system displays an error message. The administrator returns to the basic flow and may reenter
the student membership number.
Alternative Flow 7: User Exits
This allows the user to exit at any time during the use case. The use case ends.
 Software Requirements Elicitation and Analysis  105

Special Requirements
None
Associated Use Cases
Login
B. Validity Checks
(i) Only the administrator/DEO will be authorized to access the Book Details module.
(ii) Every book will have a unique accession number.
(iii) Accession number cannot be blank.
(iv) Accession number can only have value from 10 to 199999 digits.
(v) Subject descriptor cannot be blank.
(vi) ISBN number cannot be blank.
(vii) Length of ISBN number for any user can only be equal to 11 digits.
(viii) ISBN number will not accept alphabets, special characters and blank spaces.
(ix) Title cannot be blank.
(x) Length of title can be of 3 to 100 characters.
(xi) Title will only accept alphabetic characters, brackets, numeric digits and blank spaces.
(xii) Language cannot be blank.
(xiii) Author (first name and last name) cannot be blank.
(a) Length of first name and last name can be of 3 to 100 characters.
(b) First name and last name will not accept special characters and numeric digits.
(xiv) Publisher cannot be blank.
(xv) Length of first name and last name can be of 3 to 300 characters.
(xvi) Publisher will not accept special characters and numeric digits.
C. Sequencing Information
None
D. Error Handling/Response to Abnormal Situations
If any of the validation flows does not hold true, an appropriate error message will be prompted
to the user for doing the needful.

MAINTAIN STUDENT MEMBERSHIP DETAILS

A. Use Case Description
Introduction
This use case documents the steps that the Administrator/DEO must follow in order to
maintain student membership details. This includes adding, updating, deleting and viewing
student information.
Actors
Administrator
DEO
Precondition
The administrator/DEO must be logged onto the system before this use case begins.
106  Object-Oriented Software Engineering

Postcondition
If the use case is successful, then student information is added/updated/deleted/viewed from
the system. Otherwise, the system state is unchanged.
Flow of Events
Basic Flow
This use case starts when the administrator/DEO wishes to add, update, delete or view student
information from the system.
1. The system requests that the administrator/DEO specify the function he/she would like
to perform (either add a student, update a student record, delete a student record).
2. Once the administrator/DEO provides the requested information, one of the subflows
is executed.
 If the administrator/DEO selects “Add a Student”, the Add a Student subflow is
executed.
 If the administrator/DEO selects “Update a Student”, the Update a Student
subflow is executed.
 If the administrator/DEO selects “Delete a Student”, the Delete a Student subflow
is executed.
 If the administrator/DEO selects “View a Student”, the View a Student subflow is
executed.
Basic Flow 1: Add a Student
The system requests that the administrator/DEO enter the user information. This includes:
 Membership number
 Photograph
 Roll No.
 Name
 School
 Programme
 Father’s name
 Date of birth
 Address
 Telephone
 Email
 Membership date
 Valid up to
 Password
Once the administrator/DEO provides the requested information, the system checks that
student membership number is unique. The student is added to the system.
Basic Flow 2: Update a Student
1. The system requests that the administrator/DEO enter the student’s membership
number.
2. The administrator/DEO enters the student’s membership number.
 Software Requirements Elicitation and Analysis  107

3. The system retrieves and displays the student’s information.

4. The administrator/DEO makes the desired changes to the student information. This
includes any of the information specified in the Add a Student subflow.
5. Once the administrator/DEO updates the necessary information, the system updates
the student record with the updated information.
Basic Flow 3: Delete a Student
1. The system requests that the administrator/DEO specify the membership number of
the student.
2. The administrator/DEO enters the membership number. The system retrieves and
displays the student information.
3. The system prompts the administrator/DEO to confirm the deletion of the student
record.
4. The administrator/DEO verifies the deletion.
5. The system deletes the record.
Basic Flow 4: View a Student
1. The system requests that the administrator/DEO specify the membership number.
2. The system retrieves and displays the student information.
Alternative Flows
Alternative Flow 1: Invalid Entry
If in the Add a Student or Update a Student flow, the actor enters invalid photograph/
Roll No./Name/School/Programme/Father’s name/Date of birth/Address/Telephone/Email/
Membership date/Valid up to/Password or leaves the photograph/Roll No./Name/School/
Programme/Father’s name/Date of birth/Address/Telephone/Email/Membership date/Valid up
to/Password empty, the system displays an appropriate error message. The actor returns to the
basic flow and may reenter the invalid entry.
Alternative Flow 2: Student Already Exists
If in the Add a Student flow, a student with a specified membership number already exists,
the system displays an error message. The administrator returns to the basic flow and may
reenter the student information.
Alternative Flow 3: Student Not Found
If in the Update a Student or Delete a Student or View a Student flow, the student information
with the specified membership number does not exist, the system displays an error message.
The administrator returns to the basic flow and may reenter the membership number.
Alternative Flow 4: Update Cancelled
If in the Update a Student flow, the administrator decides not to update the student, the
update is cancelled and the Basic Flow is restarted at the beginning.
Alternative Flow 5: Delete Cancelled
If in the Delete a Student flow, the administrator decides not to delete the student, the delete
is cancelled and the Basic Flow is restarted at the beginning.
108  Object-Oriented Software Engineering

Alternative Flow 6: Deletion Not Allowed

If in the Delete a Student flow, issue/return/reserve details of the student selected exist, then
the system displays an error message. The administrator returns to the basic flow and may
reenter the membership number.
Alternative Flow 7: User Exits
This allows the user to exit at any time during the use case. The use case ends.
Special Requirements
None
Associated Use Cases
Login
B. Validity Checks
(i) Only the administrator/DEO will be authorized to access the Student Membership
Details module.
(ii) Every student will have a unique membership number.
(iii) Membership number can only have value from 100 to 5999 digits.
(iv) Membership number will not accept alphabets, special characters and blank spaces.
(v) Every student will have a unique membership number.
(vi) Roll no. cannot be blank.
(vii) Length of Roll no. for any user can only be equal to 11 digits.
(viii) Roll no. cannot contain alphabets, special characters and blank spaces.
(ix) Student name cannot be blank.
(x) Length of student name can be of 3 to 50 characters.
(xi) Student name will only accept alphabetic characters and blank spaces.
(xii) School name cannot be blank.
(xiii) Programme name cannot be blank.
(xiv) Father’s name cannot be blank.
(xv) Father’s name cannot include special characters and digits, but blank spaces are
allowed.
(xvi) Father’s name can have length 3 to 50 characters.
(xvii) Date of birth cannot be blank.
(xviii) Address cannot be blank.
(xix) Address can have length up to 10 to 200 characters.
(xx) Phone cannot be blank.
(xxi) Phone cannot include alphabets, special characters and blank spaces.
(xxii) Phone can be up to 11 digits.
(xxiii) Email cannot be blank.
(xxiv) Email can have up to 50 characters.
(xxv) Email should contain @ and . characters
(xxvi) Email cannot include blank spaces.
(xxvii) Password cannot be blank (initially autogenerated of 8 digits).
 Software Requirements Elicitation and Analysis  109

(xxviii) Password can have length from 4 to 15 characters.

(xxix) Alphabets, digits and hyphen, underscore characters are allowed in password field.
However, blank spaces are not allowed.
C. Sequencing Information
None
D. Error Handling/Response to Abnormal Situations
If any of the validations/sequencing flow does not hold true, an appropriate error message will
be prompted to the administrator for doing the needful.

3.3 Performance Requirements

Static and dynamic numerical requirements are addressed. Static numerical requirements may
include:
(i) The number of terminals to be supported.
(ii) The number of simultaneous users to be supported.
(iii) Amount and type of information to be handled.
Dynamic requirements may include the amount of data to be processed within certain time
periods for both normal and peak load conditions, response time for transactions etc. We may
specify “75% of transactions shall be processed in less than 2 seconds”. Hence, response time for
all operations shall be specified. Broadly, it covers those requirements that affect the performance
of the software system. For the LMS, we may specify performance requirements as:

3.3 Performance Requirements

(a) Should support at least 8 terminals.
(b) Should support at least 7 users simultaneously.
(c) Should run on 500 MHz, 512 MB RAM machine.
(d) Responses should be within 2 seconds.

3.4 Logical Database Requirements

We may specify logical requirements for any information that is to be placed into a database.
We may include:
(i) Frequency of use
(ii) Accessing capabilities
(iii) Data entities and their relationships
(iv) Integrity constraints
(v) Data retention policy
The logical database requirements for the LMS are given in Appendix.
3.5 Design Constraints
If there are any specific design constraints due to some standards, hardware and networking
limitations, then those constraints should be specified to help the designers. This may include
any deviation from standard (if any) report format, data naming, accounting procedures, audit
tracing, etc.
110  Object-Oriented Software Engineering

3.6 Software System Attributes

Non-functional requirements such as reliability, availability, security, maintainability, usability,
etc. are specified in this subsection. Definitions of some quality attributes are given in Table 3.16.

Table 3.16 Software quality attributes

S. No. Attribute Description
1 Reliability The extent to which a software product performs its intended functions
without failure.
2 Correctness The extent to which the software meets its specifications.
3 Consistency and precision The extent to which the software is consistent and gives results with
precision.

4 Robustness The extent to which the software tolerates the unexpected problems.
5 Simplicity The extent to which the software is simple in its operations.
6 Traceability The extent to which an error is traceable in order to fix it.
7 Usability The extent of effort required to learn, operate and understand the
functions of the software.
8 Accuracy Meeting specifications with precision.
9 Clarity and accuracy of The extent to which documents are clearly and accurately written.
documentation
10 Conformity of operational The extent to which the software is in conformity of operational
environment environment.
11 Completeness The extent to which the software has specified functions.
12 Efficiency The amount of computing resources and code required by the software
to perform a function.
13 Testability The effort required to test the software to ensure that it performs its
intended functions.
14 Maintainability The effort required to locate and fix an error during maintenance
phase.
15 Modularity It is the extent of ease to implement, test, debug and maintain the
software.
16 Readability The extent to which the software is readable in order to understand.
17 Adaptability The extent to which the software is adaptable to new platforms and
technologies.
18 Modifiability The effort required to modify the software during maintenance phase.
19 Expandability The extent to which the software is expandable without undesirable
side effects.
20 Portability The effort required to transfer a program from one platform to another
platform.
 Software Requirements Elicitation and Analysis  111
The quality considerations in the LMS are given as follows:

3.6 Software System Attributes

Usability
The application will be user-friendly and easy to operate, and the functions will be easily
understandable.
Reliability
The applications will be available to the students throughout the registration period and have
a high degree of fault tolerance.
Security
The application will be password protected. Users will have to enter correct login ID and
password to access the application.
Maintainability
The application will be designed in a maintainable manner. It will be easy to incorporate new
requirements in the individual modules.
Portability
The application will be easily portable on any windows-based system that has SQL Server
installed.

IEEE Std 830-1998 has given various ways to organize section 3 and depending on the project,
customer’s expectations and developers expertise, we may choose one way for the organization
of the SRS document.
3.7 Organizing the Specific Requirements
The details are given in the beginning of section 3.
3.8 Additional Comments
We may choose any one organization and the selection is dependent on the developer’s expertise,
previous experience, customer’s expectations, available technologies, etc. Sometimes, more than
one organization may also be used for organizing section 3 of the SRS document.
4. Supporting Information
Supporting information makes the SRS easier to use. It may include table of contents, index,
appendixes, etc.

3.8 Requirements Change Management

Requirements change management is a new area which has been rapidly adopted by the software
industry. As we all know, changes in requirements are inevitable. Many times, we make changes
due to factors beyond our control. Every change is difficult and requires a systematic way to
handle. Developers keep on getting requests for changes in the requirement before and also after
release of the software system. Sometimes, requests for addition of new requirements come,
which are equally difficult to handle and incorporate in the present set of requirements. Managing
112  Object-Oriented Software Engineering

change includes activities such as establishing a baseline, determining which dependencies are
important to trace, establishing traceability between different items and change control (Rational
Software, 2002).
Requirements change management is a systematic process of understanding and controlling
changes in requirements. Any change in the requirements is not an independent activity and may
have impact on other requirements, which make the area much more difficult and challenging.
The various steps for change management are given in the next subsections.

3.8.1 Is Change Necessary?

After receiving a change request, a study is carried out to know whether a change is necessary
or not. Hence, all changes must be considered by a committee and action is taken on the merits
of every change. The committee may not accept every change request.

3.8.2 Establishment of Baseline

After the approval of a change by the committee, it is communicated to all the stakeholders.
They may give their views about the change and the same may be considered by the committee.
Important views are noted and an appropriate action is recommended. If the change is finally
approved, it is implemented and tested. Baseline is the tested version of a set of requirements
representing a conceptual milestone, and serves as the basis for further development. A particular
version of the software becomes the baseline when a responsible group decides to designate it
as such (Aggarwal and Singh, 2008). Baselining is nothing but labelling a set of requirements at
specific versions and freezing them before proceeding to the next phase of development. History
of changes must be maintained. All documents should also be updated after incorporation of
any change.

3.8.3 Requirements Traceability

Requirements traceability is a well-proven technique that extends from initial requirements to
use cases and from there to design, implementation and testing. The ability to keep track of these
relationships is a key to produce high-quality software development. It is particularly important
in mission-critical projects. Requirements traceability is essential to ensure the correctness of
each step of software development process. In IEEE (1998), traceability is defined as:
The degree to which a relationship can be established between two or more products of the
development process, especially products having a predecessor-successor or master-subordinate
relationship to one anther, for example, the degree to which the requirements and design of a
given software component match.

The purpose of traceability is to:

 Understand the origin of the requirements.
 Manage the change.
 Assess the impact of change in any requirement on the software system.
 Verify that all the requirements have been implemented.
 Verify the functionality of the software.
 Software Requirements Elicitation and Analysis  113
The traceability relationship can be established between any two elements in the project.
Figure 3.11 shows the traceability relationship between two elements X and Y.

Figure 3.11 Requirements traceability.

A traceability relationship tells that if there is a change in one element (for example initial
requirements), it may affect another element (for example use cases).
The use cases may be traced to the requirements in the IRD as shown in Figure 3.12.

Figure 3.12 Use case traced to requirements.

The traceability relationship may also be represented by a traceability table or matrix.

Table 3.17 shows the traceability matrix for representing relationships between initial requirements
stated in IRD and use case. If an element X in a column fails to identify an element Y in a row,
it means that extra functionality in the form of use case has been made that was not defined in
IRD. Similarly, if an element X in a row does not corresponds to an element Y in a column, it
implies that no use case has been yet defined for initial requirements.

Table 3.17 Requirements traceability matrix

Use case 1 Use case 2 Use case 3
Requirement 1
Requirement 2
Requirement 3

For example, in the LMS, the IRD specifies:

The library staff shall be able to issue the books to each of its members.

The above requirement can be traced from use case “Issue book”:
This use case documents the steps that must be followed in order to get a book issued.
114  Object-Oriented Software Engineering

3.8.4 Change Control

A change in requirements is a regular activity. How do we manage and control such changes?
There are two important issues; one is proper documentation of change and impact of the change.
Change control activity is initiated with a change request form as given in Figure 3.13.

Change Request Form

(i) Title of the project:
(ii) Name of change request:
(iii) Date of change request:
(iv) Requested change description:
(v) Affected parts of source code:
(vi) Estimated cost of change:
(vii) Priority of change:
(viii) Assessment of change:
(ix) Date of submission of change request to change control authority (CCA):
(x) Decision of CCA with date:
(xi) Name of change implemented:
(xii) Date of implementation:
(xiii) Date of submission to QA:
(xiv) Decision of QA:
(xv) Submission to configuration team with date:
(xvi) Action of configuration management team:
Figure 3.13 Change request form.

The change request form documents the description of change. Its impact on other parts
is also analysed and documented. Cost of change is estimated and priority is assigned. All
these information is submitted to the change control authority (CCA) to take a decision about
acceptance of change request. If decision of the CCA is in favour of accepting a change, then the
CCA issues an approval of change. After this, the change is implemented. The revised software
is handed over to the software quality assurance (SQA) team for revalidation and also to ensure
that the change has not adversely affected other parts of the software. The modified software
is handed over to the software configuration team and is incorporated in a new version of the
system.

Review Questions
1. “The goal of requirements analysis is to develop a model of what the system will do.”
Explain this statement with the help of the steps that a requirements analyst will follow
throughout the analysis.
2. Who are the important stakeholders in software projects? Identify.
3. Discuss the key strategies in eliciting information about the user’s requirement.
4. Explain the importance of requirements. How many types of requirements are possible
and why?
 Software Requirements Elicitation and Analysis  115
5. List out requirements elicitation techniques. Which one is most popular and why?
6. What is software prototyping? Explain with the help of an example.
7. A university wishes to develop a software system for the student result management
of its M.Tech. programme. A problem statement is to be prepared for the software
development company. The problem statement may give an overview of the existing
system and broad expectations from the new software system.
8. What are the characteristics of a good software requirement specification (SRS)
document?
9. Consider the problem of result preparation automation system of B.Tech. courses (or
MCA program) of any university and design the following:
(i) Identification of use cases and actors
(ii) Use case diagram
10. Requirements analysis is unquestionably the most communication intensive step in
the software engineering process. Why does the communication path frequently break
down?
11. What is the purpose of extension and inclusion association between use cases? Explain
with the help of an example.
12. Compare and contrast various requirements elicitation methods.
13. Which requirements elicitation is most popular? Explain.
14. Consider the following Transport Company Automation (TCA) software. A transport
company requires to automate its various operations. The company has a fleet of
vehicles. Currently, the company has the following vehicles:
Ambassadors: 10 Non-AC, 2 AC
Tata Sumo: 5 Non-AC, 5 AC
Maruti Omni: 10 Non-AC
Maruti Esteem: 10 AC
Mahindra Armada: 10 Non-AC
The company rents out vehicles to customers. When a customer requests for a car,
the company lets them know what types of vehicles are available and the charges for
each car. For every car, there is a per-hour charge and a per-kilometer charge. A car
can be rented for a minimum of 4 hours. The amount chargeable to a customer is the
maximum of (per-hour charge for the car times the number of hours used, and per-
kilometer charge times the number of kilometers run) subject to a minimum amount
decided by the charge for 4-hour use of the car. An AC vehicle of a particular category
is charged 50% more than a non-AC vehicle of the same category. There is a charge of
` 150 for every night halt regardless of the type of the vehicle.
When a customer books a car, he has to deposit an advance amount. The customer
also informs the company when he expects to return the car. When the car is returned,
depending on the usage, either the customer is refunded some amount, or he has to pay
additional amount to cover the cost incurred.
116  Object-Oriented Software Engineering

In addition to automating the above activities, the company wants to collect statistics
about various types of vehicles such as average amount of money spent on repairs for
the car, average demand, revenue earned by renting out the car, and fuel consumption of
the car. Based on these statistics, the company may take a decision about which vehicles
are more profitable. The statistics can also be used to decide the charge for different
types of vehicles.
Draw the following using standard notations. If necessary, you can make suitable
assumptions regarding the details of various features of TCA software, but you must
clearly write down the assumptions you make.
(i) Draw use case diagram for the TCA software.
(ii) Write use case description of any two use cases.
15. What is software requirements specification (SRS)? List five desirable characteristics
of a good SRS document. Discuss the relative advantages of formal requirement
specifications. List the important issues which an SRS must address.
16. Write the use case description for Cash Withdrawal from an ATM machine
17. Discuss the role of use cases in object-oriented requirements analysis.
18. Consider the following bookshop automation system (BAS) software.
BAS should enable the shop clerk to enter the details of various books the shop
deals with and change the inventory level of various books when new stocks arrive.
BAS should help the customers query whether a book is in stock. The users can
query the availability to a book either by using the book’s title or by using a partial
name of the author. If a book is in stock, the exact number of copies available and
the rack number in which the book is located should be displayed. If a book is not in
the stock, the query for the books is used to increment a request field for the book. The
manager can periodically view the request field of the books to roughly estimate the
current demand for different out-of-stock books.
BAS should maintain the price of various books. As soon as a customer selects a
book to purchase, the sales clerk would enter the ISBN number of the book. BAS should
decrement the stock to reflect the book sale and generate the sales receipt for the book.
Upon request, BAS should generate sales statistics (viz. book name, publisher, ISBN
number, number of copies sold and the sales revenue) for any period. BAS should enable
the manager to view publisher-wise sales (e.g. sale of all books of any given publishing
house) over a period.
A software system is required to be developed to maintain telephone directory and
billing system. The software should be able to update/modify billing system and be able
to maintain the directory of the subscribers.
(i) Identify actors and use cases.
(ii) Draw the use case diagram for the BAS software.
(iii) Write the use case description of any two use cases.
19. The subscriber should be able to view the directory and search for a specific phone
number according to the phone number, address and name.
 Software Requirements Elicitation and Analysis  117
A bill should be calculated on a monthly basis. Out of the total metered calls,
150 calls are free and rest all calls are called chargeable calls. The bill is calculated at
` 1.50 per call. The subscriber is given 10 days to pay the bill, if he fails to do so, he
has to pay a fine of ` 500. The bill should show the status of the previous month’s bill,
that is, whether the last month bill was paid or not. The fine should be calculated if the
bill is not paid within the due time (within 10 days from the date of issue of the bill). If
the fine is paid within the due time, then no more action needs to be taken. But if the
fine and the total payable amount is not paid within the due date, then that subscriber
should be marked as not to be given any further services (only incoming is allowed).
The subscriber can pay this amount at any time and reinitialize the services. If the total
amount is not paid for 2 years, then the phone line should be disconnected.
A report is to be generated which analyses the total number of subscribers under
an exchange area, revenue generated and total revenue generated for all the areas, on a
monthly or yearly basis.
(i) Identify actors and use cases.
(ii) Draw the use case diagram for the above software.
20. Air ticket reservation (ATR) system is a software required to automate the reservation
system for an airline at an airport or elsewhere. The primary task deals with the
following functionalities:
 Maintenance of user account
 Maintenance of flight database, i.e. flight number, timing, number of seats, etc.
 Reservation of air tickets
 Cancelling of air tickets
 Enquiry about flight schedules, fares, timings, etc.
 Reports regarding day-to-day bookings, ticket availability, passengers database, etc.
Air ticket may be issued on demand for any flight to and from any destination for any
date and in any class as desired by the passenger depending on the availability.
After any issue or cancellation of the ticket, the corresponding information has to
be updated so that the ticket availability shows the status of the seats actually available/
unavailable. Enquiries made by the passenger also need to be furnished disclosing
the timing and availability of flight and air tickets in particular classes for the dates
provided by the enquirer.
For the sale of an air ticket or for its cancellation, money will be paid or refunded
and thus there will be a need for account maintenance, which may include ledger, sale
book receipt, etc.
The system is expected to be able to help in the running of the air ticket reservation
counter at an airport or elsewhere, thus helping in the overall functioning of any airlines
government or private.
There will also be a detailed account of all the passenger list for all flights, thus
aiding in cross checking any information that may be of use to the airline or any other
authorities.
(i) Identify actors and use cases.
(ii) Draw the use case diagram for the ATR software.
(iii) Write the use case description of reservation of airlines.
118  Object-Oriented Software Engineering

21. The proposed software product is the Hospital Patient Management System (HPMS).
The system will be used to allocate beds to patients on a priority basis, and to assign
doctors to patients in designated wards as need arises. Doctors will also use the system
to keep track of the patients assigned to them. Nurses who are in direct contact with the
patients will use the system to keep track of available beds, the patients in the different
wards, and the types of medication required for each patient. The current system in use
is a paper-based system. It is too slow and cannot provide updated lists of patients within
a reasonable time frame. Doctors must make rounds to pick up patients’ treatment cards
in order to know whether they have cases to treat or not. The intentions of the system
are to reduce over-time pay and increase the number of patients that can be treated
accurately.
(i) Identify actors and use cases.
(ii) Draw the use case diagram for the above software.
(iii) Write the use case description of reservation of airlines.
22. Consider the case where Mr. A gives a call to Mr. B. Identify and discuss the use cases
for the same.
23. Draw a use case diagram for e-shopping system.
24. A simple flight simulator is to be built/developed, using a bit-mapped display. Present a
perspective view from the cockpit of a small airplane, periodically updated to reflect the
motion of the plane. The world in which flights take place includes mountains, rivers,
lakes, roads, bridges, a radio tower and of course a runaway. Control inputs are from
two joysticks. The left operates the radar and engine. The right one controls ailerons and
elevator. Draw the use case diagram.
25. We can apply use case analysis as early as requirements analysis. Comment.
26. Draw a use case diagram for “Point-of-sale” terminal for the sale and payment of the
customer.
27. Identify different use cases for a tea/coffee/soup vending machine.
28. What is a use case model? Why is the use case modelling useful in analysis?
29. Describe the use case-driven approach by Ivar Jacobson.
30. What is the significance of requirements change management in software development?
Why is requirements traceability becoming important? Explain the change control
process.

Multiple Choice Questions

Note: Select the most appropriate answer of the following questions:
1. The hardest part of software development is:
(a) Requirement gathering (b) Software design
(c) Software implementation (d) None of the above
 Software Requirements Elicitation and Analysis  119
2. Requirements are described as:
(a) How of a system (b) What of a system
(c) When of a system (d) All of the above
3. Which is not a stakeholder?
(a) Customer (b) User
(c) Developer (d) Operating system
4. Which of the following is not a non-functional requirement?
(a) Correctness (b) Functionality
(c) Reliability (d) Portability
5. Requirements elicitation means:
(a) Requirements capturing (b) Requirements prioritization
(c) Requirements management (d) Requirements traceability
6. The best reason to select a requirements elicitation technique is:
(a) It is the only technique we know
(b) It is our favourite technique
(c) We believe that a particular technique is suitable for our project
(d) None of the above
7. The structured interview method includes the creation of:
(a) Use case diagram (b) Data flow diagram
(c) Prototype (d) Questionnaire
8. The size of a group in brainstorming session is:
(a) 15–30 persons (b) 5–15 persons
(c) 1–5 persons (d) >30 persons
9. The role of a facilitator is to:
(a) Handle conflicts (b) Ensure smooth conduct of meeting
(c) Prepare detailed report (d) All of the above
10. FAST stands for:
(a) Frequent application specification technique
(b) Facilitated application specification technique
(c) Facilitated approximate specification technique
(d) Facilitated application specification technology
11. Which one of the following is true?
(a) FAST is not a popular technique
(b) FAST session is conducted at customer’s site
(c) FAST is more formal than brainstorming session
(d) FAST is a low-cost activity
12. Prototyping is:
(a) Less costly
(b) A process that may increase the cost of the system
(c) A complex version of the system
(d) A process of developing source code
120  Object-Oriented Software Engineering

13. A use case scenario is:

(a) An instance of a class (b) An instance of a use case
(c) An instance of an actor (d) A path through a process
14. A use case addresses:
(a) Functional requirements (b) Non-functional requirements
(c) Both (a) and (b) (d) None of the above
15. A use case diagram consists of:
(a) Actors and classes (b) Actors and objects
(c) Classes and use cases (d) Actors and use cases
16. Actors include anything that is:
(a) External to the system (b) Internal to the system
(c) Functionality of the system (d) Both (a) and (b)
17. Which one of the following is not an actor?
(a) External system (b) Customers
(c) Users (d) Keyboard
18. In a use case diagram, a use case is represented by:
(a) A triangle (b) A rectangle
(c) An oval (d) A square
19. In a use case diagram, actors are represented by:
(a) Triangles (b) Stick figures
(c) Ovals (d) Squares
20. The POPULAR template for writing use case description is given by:
(a) I. Jacobson (b) V. Basili
(c) B. Boeham (d) J. Rumbaugh
21. A requirement should be:
(a) Correct (b) Unambiguous
(c) Verifiable (d) All of the above
22. IRD stands for:
(a) Initial Request Document
(b) Initial Required Document
(c) Initial Requirements Document
(d) Interactive Requirements Document
23. The IEEE recommended practice for SRS is:
(a) IEEE std. 829–1998 (b) IEEE std. 1026–1998
(c) IEEE std. 830–1999 (d) IEEE std. 830–1998
24. The IEEE std. 830–1998 was approved on:
(a) August 25, 1998 (b) July 30, 1998
(c) June 25, 1998 (d) June 25, 1999
25. Which one is not a characteristic of a good requirement?
(a) Detailed (b) Complete
(c) Verifiable (d) Unambiguous
 Software Requirements Elicitation and Analysis  121
26. Performance requirements do not include:
(a) Number of terminals support (b) Data entities and their relations
(c) Number of simultaneous users (d) Type of information handled
27. A popular object-oriented technique for representing requirements is:
(a) Data flow diagram (b) Flow chart
(c) Questionnaire (d) Use case approach
28. User characteristics exclude:
(a) Qualification (b) Technical knowledge
(c) Hardware limitations (d) Experience
29. The purpose of requirements traceability is to:
(a) Understand origin of requirements (b) Access impact of change
(c) Identify requirements (d) Verify functionalities
30. CCA stands for:
(a) Change committee authority (b) Change control audit
(c) Change control arrangement (d) Change control authority
31. Which is not a component of a use case diagram?
(a) Actor
(b) Use case
(c) Relationship between actor and use case
(d) Test case
32. Which are not included in a use case template?
(a) Actors (b) Preconditions and postconditions
(c) Test cases (d) Flow of events
33. Every use case may have:
(a) At least one actor (b) At most one actor
(c) No actor (d) None of the above
34. A use case scenario may generate:
(a) At most one test case (b) At least one test case
(c) No test case (d) None of the above
35. Use cases and use case diagrams are used to define:
(a) Complexity of a system (b) Criticality of a system
(c) Stability of a system (d) Behaviour of a system

Further Reading
Jacobson provides a classic introduction on use case approach in:
Jacobson, I.V., Object Oriented Software Engineering: A Use Case Driven Approach.
New Delhi: Pearson Education, 1999.
Cockburn provides guidance for writing and managing use cases. This may help to reduce
common problem associated with use cases:
122  Object-Oriented Software Engineering

Cockburn, A., Writing Effective Use Cases. New Delhi: Pearson Education, 2001.
Hurlbut’s paper provides a survey on approaches for formalizing and writing use cases:
Hurlbut, R., A Survey of Approaches for Describing and Formalizing Use-Cases, Technical
Report 97–03, Department of Computer Science. Illinois Institute of Technology, USA,
1997.
Fournier has discussed the relationship between actor and system in:
Fournier, G., Essential Software Testing—A Use Case Driven Approach. New York CRC Press,
2009.
Other useful texts are available at:
Booch, G., Rumbaugh, J. and Jacobson, I.V., The Unified Modeling Language User Guide.
Boston: Addison-Wesley, 1999.
Rational Requisite Pro, User’s Guide, Rational Software Corporation, 2003.
Rational Rose User’s Guide. IBM Corporation, 2003.
Tague, N.R., The Quality Toolbox. Milwaukee, WI: ASQ Quality Press, 2004.
The most current information about UML can be found at:
http://www.rational.com
http://www.omg.org