SOFTWARE

ENGINEERING
 Introduction to Software
Engineering l
The nature and complexity of software have changed significantly in the last 30 years. In the
1970s, applications ran on a single processor, produced a~phanumeric output, and received
their input from a linear source. Toqay's applications are far more complex; typically have
graphical user intocface and client-server architecture. They frequently run on two or more
processors, under d~fferent operating systems, and on geographically distributed machines.
Rarely, in history has a field of endeavor evolved as rapidly as software development.
The struggle to stay, abreast of new technology, deal with accumulated development backlogs,
and cope with people issues has become a treadmill race, as software groups work as hard as
they can, just to stay in place. The initial concept of one "guru", indispensable to a project and
hostage to its continued maintenance has changed. The Software Engineering Institute (SEI)
and group of"gurus" advise us to improve our development process. Improvement means "ready
to change". Not every member of an organization feels the need to change. It is too easy to
dismiss process improvement efforts as "just the latest management fad. Therein lie the seeds
of conflict, as some members of a team embrace new ways of working, while others mutter
"over- my dead body" [WIEG94].
Therefore, there is an urgent need to adopt software engineering concepts, strategies,
practices to avoid conflict, and to improve the software development process in order to deliver
good quality maintainable software in time and within budget.

1.1 THE EVOLVING ROLE OF SOFTWARE

The software has seen many changes since its inception. After all, it has evolved over the
period of time against all odds and adverse circumstances. Computer industry has also pro-
gressed at a break-neck speed through the computer revolution, and recently, the network
revolution triggered and/or accelerated by the explosive spread of the internet and most re-
cently the web. Computer industry h as been delivering exponential improvement in price-
performance, but the problems with software have not been decreasing. Software still come
late, exceed budget and are full of residual faults_ As per the latest IBM report, "31% of the
projects get cancelled before they are completed, 53% over-run their cost estimates by an aver-
age of 189% and for every 100 projects, there are 94 restarts" [IBMG2K].

1.1.1 Some Software Failures

A major problem of software industry is its inability to develop bug free software. If software
developers are asked to certify that the developed software is bug free, no software would have
1
 4 Software Engineering

developers who could not understand the importance of detecting and removing faults before
the customer experiences them as failures. It belongs to the legal system that has given a free
pass to software developers on bug related damages. It also belongs to universities and other
higher educational institutions that stress on programming over software engineering princi-
ples and practices.

1.2 WHAT IS SOFTWARE ENGINEERING?

Software has become critical to advancement in almost all areas of human endeavour. The art
of programming only is no longer sufficient to construct large programs. There are serious
problems in the cost, timeliness, maintenance and quality of many software products.
Software engineering has the objective of solving these problems by producing good
quality, maintainable software, on time, within budget. To achieve this objective, we have to
focus in a disciplined manner on both the quality of the product and on the process used to
develop the product.

1.2.1 Definition
At the first conference on software engineering in 1968, Fritz Bauer [FRIT68] 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". Stephen
Schach [SCHA90] defined the same as ''A discipline whose aim is the production of quality
software, software that is delivered on time, within budget, and that satisfies its requirements".
Both the definitio_n s are popular and acceptable to majority. However, due to increase in
cost of maintaining software, objective is now shifting to produce quality software that is
maintainable, delivered on time, within budget, and also satisfies its requirements.

1.2.2 Program Versus Software

Software is more than programs. It consists of programs, documentation of any facet of the
program and the procedures used to setup and operate the software system. The components
of the software systems are shown in Fig. 1.1.

Operating
procedures

Software = Program + Documentation + Operating Procedures

Fig. 1.1: Components of software
 Introduction to Software Engineering 5

Any program is a subset of software and it becomes software only if documentation and
operating procedure man1,1als are prepared. Program is a combination of source code and object
code. Documentation consists of different types of manuals as shown in Fig. 1.2.

Formal specification

Analysis\ Context-Diagram
Specification

Data flow diagrams

Flow charts

Design

Entity-Relationship diagrams

Documentation
manuals
Source code listings

Implementation

Cross-Reference listing

Test data

Testing

Test results

Fig. 1.2: List of documentation manuals

Operating procedures consist of instructions to setup and use the software system and
instructions on how to react to system failure. List of operating procedure manuals/docume::.:5
is given in Fig. 1.3.
 Software Engineering

System overview

- User manuals Beginner's guide tutorial

Reference guide

Installation guide

- Operational manuals

System administration guide

Fig. 1.3: List of operating procedure manuals

1.2.3 Software Process

The software process is the way in which we produce software. This differs from organization
to organization. Surviving in the increasingly competitive software business r equires more
than hiring smart, knowledgeable developers and buying the latest development tools. We
also need to use effective software development processes, so that developers can systematically
use the best technical and managerial practices to successfully complete their pr oject s. Many
software organizations are looking at software process improvement as a way to improve the
quality, productivity, predictability of their software development, and maintenance efforts
[WIEG96].
It seems straight forward, and the literat ure has a number of success stories of compa-
nies that substantially improved their software development and project management capa-
bilities. However, many other organizations do not manage to achieve significant and lasting
improvements in the way they conduct their projects. Here we discuss few reasons why is it
difficult to improve software process [HUMP89, WIEG99]? •-:;,;
1. Not enough time: Unrealistic schedules leave insufficient time to do the essential
project work. No software groups a re sitting around with plenty of spare time to devote to
exploring what is wrong with their current development processes and what they should be
doing differently. Customers and senior managers are demanding more software, of higher
quality in minimum possible time. Therefore, there is always a shortage of time. One conse-
quence is that software organizations may deliver release 1.0 on time, but then they have to
ship release 1.01 almost immediately thereafter to fix the recently discovered bugs.
2. Lack of knowledge: A second obstacle to widespread process improvement is that
many software developers do not seem to be familiar with industry best practices. Normally,
software developers do not spend much time reading the literature to find out about the best-
known ways of software development. Developers may buy books on Java, Visual Basic or
ORACLE, but do not look for anything about process, testing or quality on their bookshelves.
 Introduction to Software Engineering 7

The industry awareness of process improvement frameworks such as the capability

maturity model and ISO 9001 for software (discussed in Chapter 7) have grown in recent
years, but effective and sensible application still is not that common. Many r ecognized best
practices available in literature simply are not in widespread use in the software development
world.
3. Wrong motivations: Some organizations launch process improvement initiatives
for the wrong reasons. May be an external entity~ such as a contractor, demanded that the
development organization should achieve CMM level X by date Y. Or perhaps a senior manager
learned just enough about the CMM and directed his organization to climb on the CMM
bandwagon.
The basic motivation for software process improvement should be to make some of th e
current difficulties we experience on our projects to go away. Developers are rarely motivated
by seemingly arbitrary goals of a chieving a higher maturity level or an external certification
(ISO 9000) just because someone has decreed it. However, most people should be motivated by
the prospect of meeting their commitments, improving customer satisfaction, and delivering
excellent products that meet customer expectations. The developers have resisted many process
improvement initiatives when t hey were directed to do "the CMM thing", without a clear
explanation of the reasons why improvement was needed and the benefits the team expected
to achieve.
4. Insufficient commitment: Many times, the software process improvement fails,
despite best of intentions, due to lack of true commitment. It starts with a process assessment
but fails to follow through with actual changes. Management sets no expectations from the
development community around process improvement; they devote insufficient resources, write
no improvement plan, develop no roadmap, and pilot no new processes.
The inyestment we make in process improvement will n ot have an impact on current
productivity; because the time we spend developing better ways to work tomorrow is not
available for today's assignment . It can be tempting to abandon the effort when skeptics see
the energy they want to be devoted to immediate demands being siphoned off in the hope of
a better future (Fig. 1.4). Software organizations should not give up, but should take motiva-
tion from the very real, long-term benefits that many companies (including Motorola, Hewlett-
Packard, Boeing, Microsoft etc.) have enjoyed from sustained software process improvement
initiatives. Improvements will t ake place over time and organizations should not expect and
promise miracles [WIEG2K] and should always remember the learning curve.
Improved future state
Process improvement
begins
Initial sta/
t
Productivity

I
Learning curve
'
Do not quit here!

- - Time -----
Fig. 1.4: The process improvement learning curve
 8 Software Engineering

1.2.4 Software Characteristics

The software has a very special characteristic e.g., "it does not wear out". Its beh aviour and·
nature is quite different than (?ther products of human life. A comparison ,.,ith one such case,
i.e., constructing a bridge vis-a-vis writing a program is given in Table 1.1. Both activities
require different processes and have different ch aracteristics.
Table 1.1: A comparison of constructing a bridge and writing a program

Sr. No. Constructing a bridge Writing a program

1. The problem is well understood. Only some parts of the proh!e:n are under-
stood, others are not.

2. There are many existing bridges. Every program is differen: .. ~i ce.signed for
special applications .

3. The requirements for a bridge typically do Requirements typically chz.::ge d uring all
not chan ge mu ch during construction. phases of development.

4. The strength and stability of a bridge can be Not possible to calculate au_ec:.:es.; of a pro-
calculated with reasonable precision. gram with existing me~

5. When a bridge collapses, there is a detailed When a prngram fails, the . - a...---e often
investigation and report. unav~able or even de ~ _ re=aled.
6. Engineers have been constructing bridges for Developers have been wr. ~ for
thousands of years. 50 years or so.

7. Materials (wood, stone, iron, steel) a n d tech- Hardware and software ~ ~dJy.
_niques (making joints in wood, carving stone,
casting iron) change slowly. •

Some of th e important ch ara cteristics are discussed below:

(i) Software does not wear out: There is a well-known "bath tt.b __ _,. - ::-eriability
studies for h ardware products. Th e curve is given in Fig. 1.5. The shape
''bath tub"; and is known as bath t ub curve.

Burn-in ,
phase :
i - - -- ,
~ Useful life phase ~
: Wear out
phase

'

- - -- - Time - - - --

Fig. 1.5: Bath tub curve

 - 1

12 Software Engineering

been computerized. Back in the days of manual accounting systems, human error was a fact of
life. Now, we have software error as well.
3. Testing software or 'proving' software correct can remove all the errors:
Testing can only show the presence of errors. It cannot show the absence of errors. Our aim is
to design effective test cases in order to find maximum possible errors. The more we test, the
more we are confident about our design.
4. Reusing software increases safety: This myth is particularly troubling because of
the false sense of security that code re-use can create. Code re-use is a very powerful tool that
can yield dramatic improvement in development efficiency, but it still requires analysis to
determine its suitability and testing to determine if it works.
5. Software can work right the first time: If we go to an aeronautical engineer, and
ask him to build a jet fighter craft, he will quote us a price. Ifwe demand that it is to be put in
production without building a prototype, he will laugh and may refuse the job. Yet, software
engineers are often asked to do precisely this sort of work, and they often accept the job.
6. Software can be designed thoroughly enough t o avoid most integration
problems: There is an old saying among software designers: "Too bad, there is no complier for
specifications": This points out the fundamental difficulty with detailed specifications. They
always have inconsistencies, and there is no computer tool to perform consistency checks on
these. Therefore, special care is required to understand the specifications, and if there is an
ambiguity, that should be resolved before proceeding for design.
7. Software with more features is better software: This is, of course, almost the
opposite of the truth. The best, most enduring programs are those which do one thing well.
8. Addition of more software engineers will make up the delay: This is not true
in most of the cases. By the process of adding more software engineers during the project, we
may further delay the project. This does not serve any purpose here, although this may be true
for any civil engineering work.
9. Aim is to develop working programs: The aim has been shifted from developing
working programs to good quality, maintainable programs. Maintaining software has _become
a very critical and crucial area for software engineering community.
This list is endless. These myths, poor quality of software, increasing cost and delay in
the delivery of the software have been the driving forces behind the emergence of software
engineering as a discipline. In addition, following are the contributing factors:
• Change in ratio of hardware to software cost s
• Increasing importance of maintenance
• Advances in software techniques
• Increased demand for software
• Demand for larger and more complex software systems.

1.5 SOME TERMINOLOGIES

Some terminologies are discussed in this section which are frequently used in the field of
Software Engineering.
 SOFTWARE ARCHITECTURE & DESIGN
We can segregate Software Architecture and Design into two distinct phases: Software
Architecture and Software Design. In Architecture, nonfunctional decisions are cast and
separated by the functional requirements. In Design, functional requirements are accomplished.

SOFTWARE ARCHITECTURE

Software architecture refers to the fundamental structures of a software system and the
discipline of creating such structures and systems. Each structure comprises software elements,
relations among them, and properties of both elements and relations. The architecture of a
software system is a metaphor, analogous to the architecture of a building. It functions as a
blueprint for the system and the developing project, laying out the tasks necessary to be executed
by the design teams.

Software architecture is about making fundamental structural choices that are costly to change
once implemented. Software architecture choices include specific structural options from
possibilities in the design of the software. For example, the systems that controlled the Space
Shuttle launch vehicle had the requirement of being very fast and very reliable. Therefore, an
appropriate real-time computing language would need to be chosen. Additionally, to satisfy the
need for reliability the choice could be made to have multiple redundant and independently
produced copies of the program, and to run these copies on independent hardware while cross-
checking results.
 Softvvare Life Cycle
2 Models
The ultimate objective of software engineering is to produce good quality maintainable
software within reasonable time frame and at affordable cost. This is achievable only if we
have matured processes to produce it. For a mature process, it should be possible to determine
in advance how much time a nd effort will be required to produce the final product. This can
only be done using data from past experience, which requires that we must measure the soft-
ware process.
Software development organizations follow some process when developing a software
product. In immature organizations, the process is usually not written down. In mature
organizations, the process is in writing and is actively managed. A k ey component of any
software development process is the life cycle model on which the process is based. The particular
life cycle model can significantly affect overall life cycle costs associated with a software product
[RAKI97]. Life cycle of the software starts from concept exploration and ends at the retirement
of the software.
In the IEEE standard Glossary of software Engineering Terminology, the software life
cycle is:
"The period of time that starts when a software product is conceived and ends when the
product is no longer available for use. The software life cycle typically includes a requirement
phase, design phase, implementation phase, test phase, installation and check out phase, op-
eration and maintenance phase, and sometimes retirement phase".
A software life cycle model is a particular abstraction that represents a software life
cycle. A software life cycle model is often called a software development life cycle (SDLC). A
variety of life cycle models h ave been proposed and ar e based on tasks involved in developing
a nd maintaining software. Few well known life cycles models are discussed in this chapter.

2.1 BUILD AND FIX MODEL

Sometimes a product is constructed without specifications or any attempt at design. Instead,
the developer simply builds a product that is reworked as many times as necessary to satisfy
-..... ~ the client [SCHA96].
This is an adhoc approach and not well defined: Basically, it is a simple two-phase model.
The first phase is to write code and the next phase is to fix it as shown in Fig. 2.1. Fixing in this
COJ).text may be error correction or addition of further functionality [TAKA96].

20
 Software Life Cycle Models 21

Build
code

Fix

Fig. 2.1: Build and fix model

Although this approach may work well on small programming exercises 100 or 200 lines
long, this model is totally unsatisfactory for software of any reasonable size. Code soon becomes
unfixable and unenhanceable. Th ere is no room for design or any aspect of development process
to be carried out in a structured or detailed way. The cost of the development using this approach
is actually very high as compared to the cost of a properly specified and carefully designed
. product. In addition, maintenance of the product can be extremely difficult without specification
or design documents.

2.2 THE WATERFALL MODEL

The most familiar model is the waterfall model, which is given in Fig. 2.2. This model has five
phases: Requirements analysis and specification, design, implementation and unit testing,
integration and system testing, and operation and maintenance. The phases always occur in
this order and do not overlap. The developer must complete each phase before the next phase
begins. This model is named "Waterfall Model", because its diagrammatic representation
resembles a cascade of waterfalls.
1. Requirement analys is and specification phase: The goal of this phase is to
understand the exact requirements of the customer and to document them properly. This activity
is usually executed together with the customer, as th e goal is to document all functions ,
performance and interfacing r equirements for the software. The requirements describe the
"what" of a system, not the "how". This phase produces a large document, written in a natural
language, contains a description of what the system will do without describing how it will be
done. The resultant document is known as software requirement specification (SRS) document.

. ,
The SRS document may act as contract between the developer and customer. If developer
fails to implement full set ofrequirements, it may amount to failure to implement the contracted
system. /

/
 Software Engineering

Requirement analysis
& Specification

~ - -o_e_s_ig_n_ _ ~
Implementation &
Unit testing

Integration & System

testing

Operation &
Maintenance

Fig. 2.2: Waterfall model

2. Design phase: The SRS document is produced in the previous phase, which contains
the exact requirements of the customer. The goal of this phase is to transform the requirements
specification into a structure that is suitable for implementation in some programming language.
Here, overall software architecture is defined, and the high level and detailed design work is
performed. This work is documented and known as software design description (SDD) document.
The information contained in the SDD should be sufficient to begin the coding phase.
3. Implementation and unit testing phase: During this phase, design is implemented.
If the SDD is complete, the implementation or coding phase proceeds smoothly, because all the
information needed by the software developers is contained in the SDD.
During testing, the major activities are centered around the examination and modifica-
tion of the code. Initially, small modules are tested in isolation from the rest of the software
product. There are problems associated with testing a module in isolation. How do we run a
module without anything to call it, to be called by it or, possibly, to output intermediate values
obtained during execution? Such problems are solved in this phase and modules are tested
after writing some overhead code.
4. Integration and system testing phase: This is a very important phase. Effective
testing will contribute to the delivery of higher quality software products, more satisfied users,
lower maintenance costs, and more accurate and reliable results. It is a very expensive activity
and consumes one-third to one half of the cost of a typical development project.
As we know, the purpose of unit testing is to determine that each independent module is
correctly implemented. This gives little chance to determine that the interface between modules
is also correct, and for this reason integration testing is performed. System testing involves
the testing of the entire system, whereas software is a part of the system. This is essential to
build confidence in the developers before software is delivered to the customer or r eleased in
the market.
5. Operation and maintenance phase: Software maintenance is a task that every
development group has to face, when the software is delivered to the customer's site, installed
and is operational. Therefore, release of software inaugurates the operation and maintenance
phase of the life cycle. The time spent and effort required to keep the software operational
 Software Life Cycle Models

after release is very significant. Despite the fact that it is a very important and challenging
task; it is routinely the poorly managed headache that nobody wants to face.
Software maintena nce is a very broad activity that includes error correction, enhance-
ment of capabilities, deletion of obsolete capabilities, and optimization. The purpose of this
phase is to preserve the value of the software over time. This phase may span for 5 to 50 years
whereas development may be 1 to 3 years.
This model is easy to understand and reinforces the notion of "define before design" and
"design before code". This model expects complete and accurate requirements early in the
process, which is unrealistic. Working software is not available until relatively late in the
process, thus delaying the discovery of serious errors. It also does not incorporate any kind of
risk assessment.
Problems of waterfall model
(i) It is difficult to define all requirements at the beginning of a project.
(ii) This model is not suitable for accomodating any change.
(iii) A working version of the system is not seen until late in the project's life.
(iv) It does not scale up well to large projects . .
(u) Real projects are rarely sequential.
Due to these weaknesses, the application of waterfall model should be limited to situa-
tions where the requirements and their implementation are well understood. For example, if
an organisation has experience in developing accounting systems then building a new accounting
system based on existing designs could be easily managed with the waterfall model.

2.3 INCREMENT PROCESS MODELS

Increment process models are effective in the situations where requirements are defined
precisely and there is no confusion about the functionality of the final product. (Although,
functionality can be delivered in phases as per desired priorities). After every cycle, a useable
product is given to the customer. For example, in the university automation software library
automation module may be delivered in the first phase and examination automation module
in the second phase and as so on. Every new cycle will have an additional functionality.
Increment process models are popular particularly when we have to quickly deliver a limited
functionality system.

2.3.1 Iterative Enhancement Model

This model has the same phases as the waterfall model, but with fewer restrictions. Generally
the phases occur in the same order as in the waterfall model, but these may be conducted in
several cycles. A useable product is released at the end of the each cycle, with each release
providing additional functionality [BASI75].
During the first r equirements analysis phase, customers and developers specify as many
requirements as possible and prepare a SRS document. Developers and customers then prioritize
these requirements. Developers implement the specified requirements in one or more cycles of
design, implementation and test based on the defined priorities. The model is given in Fig. 2.3.
 24

The aim of the waterfall and prototyping models is the deli\·ery o: a co:::. ..e..
tional and good quality product. In contrast, this model does deliver an ope!'a~
product at each release, but one that satisfies only a subset of the cu tome'!'"·5 ~:P::::r£:~':'.:!::...
The complete product is divided into releases, and the developer deliver- ilie p:-oo~ .
by release. A typical product will usually have many releases as shown in F:~. 2 3 ..\:
release, customer has an operational quality product that does a portion of v.r,a: ~ ~-ed.
The customer is able to do some useful work after first r elease. With this mode:. fus. ..-....~...,.
may be available within few weeks or months, whereas t he customer generaUy v.a:-'= IDC::::t:..s
or years to receive a product u sing the waterfall and prototyping model.

Implementation & Integration & Operation

Requirements Design System
Unit testing (Install)
testing

Release I

Implementation & Integration & Operation

Design Unit testing System (Install)
testing

Release II

Implementation & Integration & Operation

Design · Unit testing System (Install)
testing

Release Ill

Fig. 2.3: Iterative enhancement model

2.3.2 The Rapid Application Development (RAD) Model

This model is an incremental process model and was developed by IBM in the 19 Os a::?ci
described in the book of James Martin entitled "Rapid Application Development". Here. 1:.Se'!'"
involvement is essential from requirement phase to delivery of the product. The continuou.5
user participation ensures the involvement of user's expectations and perspective in require-
ments elicitation, analysis and design of the system.
The process is started with building a rapid prototype and is given to user for e\·alua-
tion. The u ser feedback is obtained and prototype is refined. The process continues, till the
requirements are finalised. We may use any grouping technique (like FAST, QFD, Brainsto:r.:::::-
ing Sessions; for details refer chapter 3) for requirements elicitation. Software requireme:.:
and specification (SRS) and design documents are prepared with the association of users.
There are four phases in this model and these are shown in Fig. 2.4.
With active participation of users

Requirements User
planning description Construction Cut over

Fig. 2.4: RAO model

-
'
I Software Life Cycle Models 25

(i ) Requirements planning phase: Requirements are captured using any group

elicitation technique. Some techniques are discussed in chapter 3. Only issue is the active
involvement of users for understanding the project.
(ii) User description: Joint teams of developers and users are constituted to prepare,
ur.derstand and review the requirements. The team may use automated tools to capture
information from the other users.
(iii ) Construction phase: This phase combines the detailed design, coding and testing
phase of waterfall model. Here, we release the product to customer. It is expected to use code
generators, screen generators and other types of productivity tools.
(iv) Cut over phase: This phase incorporates acceptance testing by the users, installation
of the system, and user training.
In this model, quick initial views about th e product are possible due to delivery ofrapid
prototype. The development time of the product may be reduced due to u se of powerful
development tools. It may use CASE tools and frameworks to increase productivity. Involvement
of user may increase the acceptability of the product.
If user cannot be involved through out the life cycle, this may not be an appropriate
model. Development time may not be reduced very significantly, if reusable components are
not available. Highly specialized and skilled developers are expected and such developers may
not be available very easily. It may not be effective, if system can not be properly modularised.

2.4 EVOLUTIONARY PROCESS MODELS

Evolutionary process model resembles iterative enhancement model. The same phases as de-
fined for the waterfall model occur h ere in a cyclical fashion. This model differs from iterative
enhancement model in the sense that this does not require a useable product at the end of each
cycle. In evolutionary development, requirements are implPmented by category rather than
by priori ty.
For example, in a simple database application, one cycle might implement the graphical
user interface (GUI ); anotht'r file manipulation; another queries; and another updates. All
four cycles must complete before there is working product available. GUI allows the users to
inter'.3-ct with th e system; file manipulation allows data to be saved and r etrieved; queries
allow users to get data out of the system; and updates allow user s to put data into the system.
With any one of those parts missing, the system would be unusable.
In contrast, an iter ative enhancement model would st art by developing a very simplistic,
but usable database. On the completion of each cycle, the system would become more
sophisticated. It, would, however , provide all the critical functionality by the end of the first
cycle. Evolutiona ry development and iterative enhancement are somewhat interchangeable.
Evolutionary development should be used when it is not necessary to provide a minimal version
of the system quickly.
These models are useful for projects using n ew technology that is not well understood.
This is also used for complex projects where all functionality must be delivered at one time,
but the r equirements are unstable or not well understood at the beginning.
 ■

Software Engineering

2.4.1 Prototyping Model

A disadvantage of waterfall model as discussed in the last section is that the working software
is not available until late in the process, thus delaying the discovery of serious errors. An
alternative to this is to first develop a working prototype of the software instead of developing
the actual software. The working prototype is developed as per current available requirements.
Basically, it has limited functional capabilities, low reliability, and unt ested performance
(usually low).
The developers use this prototype to refin e the requirements and prepare the final
specification document. Because the working prototype has been evaluated by the customer, it
is reasonable to expect that the resulting specification document will be correct. When the
prototype is created, it is reviewed by the customer. Typically this review gives feedback to the
developers that helps to remove uncertainties in the requirements of the software, and starts
an iteration of refinement in order to further clarify requirements as shown in Fig. 2.5.

Requirements

Quick design

Refinement of
requirements as
per suggestions
Implement

Customer Evaluation
Not accepted by customer

Accepted by customer

Design

Implementation and Unit testing

Integration & System testing

Operation & Maintenance

Fig. 2.5: Prototyping model

The prototype may be a usable program, but is not suitable as the final software product.
The reason may_be poor performance, maintainability or overall quality. The cod for the
prototype is thrown away; however the experience gathered from developing the prototype
helps in developing the actual system. Therefore, the development of a prototype migh. involve
 27

c . but overall cost might t urnout to be lower than that of an equivalent system developed
_ :!le waterfall model.
The developers should develop prototype as early as possible to s peed up the software
· y:nent process. After all, t he sole use of this is to determine the customer 's r eal needs.
+;s has been determined, the prototype is discarded. For this reason, the internal structure
~ prototype is not very important [SCHA96].
After t he finalization of software requirement and specification (SRS) document, the
- type is discarded and actual system is then developed using the waterfall approach. Thus,
- !!.Serl as an input t o waterfall model and produces maintainable and good quality software.
~ :nod.el requires extensive participation and involvement of th e customer, which is not
~- possible.

- ,.2 Spiral Model

iJroblem with traditional soft war e process models is that they do not deal sufficiently with
~ rtainty, which is inherent to software projects. Important software projects h ave failed
l:e::a::..:.e project risks were neglected and n obody was prepared wh en something unforeseen
=--pened. Barry Boehm recognized this and tried to incorporate the "project risk" factor into
::re e;·cle model. The result is the spiral m odel, which was presented in 1986 [BOEH86] and
~ in Fig. 2.6.

-::-ne radial dimension of the model represents the cumulative costs. Each path around
:p=_..-ai is indicative of increased costs. The angular dimension represents the progress made
_.,:::p!eting each cycle. Each loop of t he spiral from X-a xis clockwise through 360° r epresents
¢:age. One phase is split roughly into four sectors of major a ctivities:
• Planning: Determination of objectives, alternatives and constraints
• Risk analysis: Analyze alternatives a nd attempts t o identify and resolve the risks in-
volved
• Development: Product development a nd testing product
• Assessment: Customer eva luation
During t h e first phase, planning is performed, risks are analyzed, prototypes are built,
~ ~ mers evaluate the prototype. During t he second phase, a more r efined prototype is
:.. requirements are document ed and validated, and cu stomers are involved in assessing
_ :iew prototype. By the time third phase begins, risks are known, and a somewhat more
=.c:::onal development approach is taken IRAKI97].
The focus is the identification of problems and the classification of these into different
le\-e·- of risks, the aim being to eliminate high-risk problems before they t hreaten the software
cperarion or cost.
An important feature of the spiral model is that each phase is completed with a review
. ::he people concerned with the project (designer s and programmers). This review consists of
re.iew of all the products developed up to that point and includes the plans for the n ext cycle.
!!bese plans may include a partition of the product in smaller portions for development or
ci=:.ponents that are implemented by individual groups or persons. If the plan for the develop-
~ : fails, then the spiral is termin ated. Otherwise, it terminates with the initiation of new or
c:o:Ef:.ed software.
 28 Software Engineering

Cumulative cost

Progress
through
steps

Evaluate alternatives;
identify, resolve risks
Determine
objectives,
alternatives,
constraints

Benchmarks
Software
product Detailed
design design
Requirements - r--- --
validation 1 : Code
I I

: Unit :
Design validation , test 1
I I
and verification , Integration :
: and test
Plan Acceptance;
next phases Implemen-
tation test

Develop, verify
t next-level product - t
IV Ill

Fig. 2.6: Spiral model

The advantage of this model is the wide range of options to accommodate t he good
features of other life cycle models. It becomes _equivalent to another life cycle model in a ppro-
priate situations. It also incorporates software quality objectives into software development.
The risk analysis and validation steps eliminate errors in the early phases of development .
The spiral model has some difficulties that need to be r esolved before it can be a univer-
sally applied life cycle model. These difficulties include lack of explicit process guida nce in
determinin g objectives, constraints, alternatives; relying on risk assessment experfo;e; and
providing more flexibility than required for many applications.

2.5 THE UNIFIED PROCESS

The unified process is described by I. Jacobson, G. Booch and J . Rumbaugh in their book "The
unified software development process" [JACO 98). It is a software engineering process with
the goal of producing good quality maintainable software within specified time and budget.
The unified process supports iterative development wh ere project is developed through a series
of short, fixed length minipr ojects called iterations. The outcome of each iteration is a tested,
integrated and executable system. Each iteration h as its own requir ements analysis, design,
 30 Software E.~ ~

feedback of the users in terms of additional functionality, failure reports etc. may mon va:e...:
to work for second version. The same process through inception, elaboration, constructior? a=rl
transition phases will repeat to evolve the next generation of the software produ.~- -:::-r.e5e
cycles are known as evolution cycles as shown in figure 2.8. With several evolution cycies. ne
generations of the product are produced. This process will continue upto the retire~ :
software product.
Vers,:;,:',
L Inception
►I Elaboration I ►[construction Transition

_ ~ tia~evelopment eye~

.. Inception - -{ Elaboration] ►~ onstruction] ►I Transition ~ e~ 2

Evolution cycle
, - - - - - , Version 3
• ' • ~ Inception 1 ~ ►I Construction}- -t>j Transitionj : : : ; ►
Evalution cycle ~
Continue till
the product is
retired.

Fig. 2.8: Initial development and evolution cycles

The phases are not of equal lengths. The length may vary depending on the type, speci-
fications and environment of the project. In each phase, we progress iteratively and each phase
may consist .of one or several iterations as shown in Figure 2.9.
...
L Inception :- ....,...- : Elaboration :1--- -..~-: Construction ~
'
Time

lteration-1 lteration-2 lteration-3 ltera- ltera- ltera- lteration-7 lteration-8

tion-4 tion-5 tion-6

lnteral First external Final release

release release (beta
release)

Fig. 2.9: Iterations within a phasP

Each iteration follows a pattern which is similar to waterfall model. Hence, the work-flow
contains the activities of requirements elicitation and analysis, design, implementation and
testing. However, from one iteration to the next and from one phase to the next, the emphasis
on various activities will change. Figure 2.10 shows the relative emphasis of the various types
of activities over time [KRUC 99]. These l:lCtivities are noLseparated in time. Rather, they are
executed concurrently throughou t the lifetime of the project. As we have seen in figure 2.10,
not much code is written early, in the project life cycle ; but the amount is not zero. Late in the
projected, most of the requirements are knowri, but some new ones are still 1dentified. Thus, as
the project, matures, the emphasis on certain activities increases or decreases, but activities
are allowed to execute at any time throughout the lifetime of the project [BOOC 98].
 Software Life Cycle Models

The inception phase is primarily dedicated to the requirements elicitation and analysis.
The scope of the work is defined and some planning work is also carried out. The ·elaboration
phase has the focus on requirements with some emphasis on design and implementation. During
the construcLion phase, focus is mostly on design and implementation. We produce first
operational product after this phase.
The focus of transition phase is on training, installation and customer interaction. The
feedback of customer helps us to improve and enhance the product. We p;oduce and deliver
the final product here.

Phases

Core workflows ~
Inception }
_ __ ~r
I
I
Elaboration
-- ~I
I
L 1

I I
I I

I -- -~ I

Requirements
elicitation and
~ I
!
::i'- I
ti
I
I
analysis I I I

:
I
t
I
:
I

Design
- - - - -~ ,-
I
: ~
I ___..-t - - - .
I
I
=------=
jlJ

I
I
I I I
I I I
I I I
I I I
I I I
I I -..--~- I

Implementation ~l
I
I
I
I
I
I
~ I
I
I
I
I I I I I
l I I I I
I I I I I
I I I I :
I I I l I
I I I I
I I I I •
I 1 I I I I
I I I I I I

Test I I I
~
I I I
: lteration-1 : lteration-2 1 lter<1t- : ltera- : ltera- : ltera- : ltera-
Priliminary ,_ , , ion-n , tion-n , tion-n , tion-m ,: tion-m + 1
iteration
: : : : + 1 : +2 ! :
Fig. 2.10: Iterations and workflow of unified process

2.5.2 Unified Process Work Products

All four phases produce different work products a s per outcome of the phases. The
inception phase has the following objectives :
• Gathering and analysing the requirements.
• Planning and preparing a business case and evaluating alternatives for risk manage-
ment, scheduling resources, etc.
• Estimating the overall cost and schedule for the project.
• Studing the feasibility and calculating profitability of the project.
Many documents are prepared and are shown in Fig. 2.11.
 32 Software Engineering

Prototypes Project plan

Initial risk
assessment

Inception
Business
model
Initial busmess
case

Vision Initial project

document Initial use glossary
case model

Fig. 2.11: The outcomes of Inception phase

Th~ vision document's emphasis is on requirements and scope of the project. It gives us
an idea about overall objective and expectations from the project. Initial use case model gives
use case diagram alongwith actors etc. It may also consist of use cases that can be identified at
this early stage.
Initial business case may include revenue model, market con ditions, business difficul-
ties and financial forecast etc. Project plan document may include phases and iterations for
the development of the project. Prototypes are very useful for the understanding of the project
(optional item). A business model may be required to provide idea about "time to market".
marketing strategies, cash flows and threats.
The elaboration phase has the focus on the analysis of problem domain, establishes a
sound architectural foundation, develops project plans and eliminat es the risk elements. Some
of the objectives and activities are :
• Establishing architectural foundations
• Design of use case model
• Elaborating the process, infrastructure and development environment
• Selecting component, if possiple, for the project
• Demonstrating that architecture supports the vision at reasonable cost and with speci-
fied time.
The outcomes are given in Fig. 2.12.

A development Revised risk

plan document

An executable
Priliminary Elaboration architectural
user manual prototype

Architecture
Use case description
model Supplementary document
requirements with
nonfunctional
requirements

Fig. 2.12: The outcomes of elaboration phase

 Software Life Cycle Models 33

A use case model (at least 80% complete) is pr epared. All use cases are identified
alongwith associated actors. Supplementary requirements document (with nonfunctional
requirements) and softwar e architecture description document are also prepared. A prototype
is also designed for the customer to give an idea about the final product. A development plan
with iterations, workflows etc. is a lso prepared. A preliminary user manual, although optional,
may also be prepared in this phase and will r efine in the subsequent phases.
The construction phase produces the product for the customer. The objectives and
activities are :
• Implementing the project
• Minimising development cost
• Managing and optimizing resources
• Testing the product
• Assessing the product releases against acceptance criteria.
The outcome of this phase is a product ready to use for the customers and is shown in
Fig. 2.13.

Test outline
Operational manuals

Documentation
--- -+. Test suite
manuals

A description
Software of the current
product User release
manuals

Fig. 2.13: The outcomes of construction phase

The outcomes are various operational and documentation manuals alongwith software
product. The test suite documents are also preserved carefully because they are required during
the maintenance of the software product.
The transition phase lays focus on successful delivery and installa tion of the software
product. The phase includes the following : ~
• Commencement of beta testing
• Analysis of u ser's views
• Training of users
• Tuning activities including bug fixing and enhancement for performance and usability
• Assessing the customer satisfaction
The outcomes are given in Fig. 2.14.
 Software Engineering

Product
release
/ Beta test
User
feedback

reports

Fig. 2.14: The 0I1tcomes of transition phase

The-unified process has many advantages due to its iterative and incremental nature.
Changes can be accomodated, risks can be minimised, reusability can be ensured and learning
alongwith project evolution is possible. Hence, the product that results from unified process
will be of good quality. The system has been tested several times, improving the quality of
testing. The requirements have been refined and are more closely related to the customer's
actual expectations.

2.6 SELECTION OF A LIFE CYCLE MODEL

The selection of a suitable model is based on the following characteristics/categories:
(i) Requirements
(ii) Development team
(iii) Users
(iv) Project type and associated risk.

2.6.1 Characteristics of Require'!lents

Requirements are very important for the selection of an appropriate model. There are number
of situations and problems during requirements capturing and analysis. The details are given
in Table 2.1.
Table 2.1: Selection of a model based on characteristics of requirements

Requirements Waterfall Prototype Iterative Evolutionary Spiral RAD

enhancement development
Are requirements easily Yes No No No No Yes
understandable and defined?
Do we change requirements No Yes No No Yes No
quite often?
Can we define requirements Yes No Yes Yes No Yes
early in the cycle?
Requirements are indicating No Yes Ye(! Yes Yes No
a complex system to be built
 Software Requirements :
3 Analysis and Specifications

When we receive a request for a new software project from the customer, first of all, we would
like to understand the project. The new project may replace the existing system such as
preparation of students semester results electronically rather than manually. Sometimes, the
new project is an enhancement or extension of a current (manual or automated) system. For
example, a web enabled student result declaration system that would enhance the capabilities
of the current result declaration system. No matter, whether its functionality is old or n ew,
each project has a purpose, usually expressed in what the system can do. Hence, goal is to
understand the requirements of the customer and document them properly. A requiremen t is
a feature of the system or a description of something the system is capable of doing in order to
fulfil the system's purpose.
The hardest part of building.a software system is deciding precisely what to build. No
other part of the conceptual work is so 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 r ectify later [BROO95]. Throughout software industry's history,
we have struggled with this truth. Defining and applying good, complete requiremen~ is hard
to work, and success in this endeavor has eluded many ofus. Yet, we continue to make progress.

3.1 REQUIREMENTS ENGINEERING

Requirements describe the "what" of a system, not the "how". Requiremen ts engineering
produces one large document, written in a natural language, cont ains a description of what
the system will do without describing how it will do. The input to requirements engineering is
the problem statement prepared by the customer. The problem stat ement may give an overview
of the existing system alongwith broad expections from the new system.

3.1.1 Crucial Process Steps

The quality of a software product is only as good as the process th at creates it . Requirements
engineering is one of the most crucial activity in this creation process. Without well-written
requirements specifications, developers do not know what to build, customers do not know
what to expect, and there is no way to validate that the built system satisfies th e requirements.
Requirements engineering is the disciplined application of proven principles, methods,
tools, and notations to describe a proposed system's intended behaviour a nd its associated
constraints [HSIA93]. This process consists of four steps as shown in Fig. 3.1.

40
 Software Requirements : Analysis and Specifications 41

Problem
statement

Requirements
elicitation

Requirements
analysis J
h i
Requirements
documentation

Requirements
review
SRS

Fig. 3.1: Crucial process steps of requirement engineering

(i ) Requirements elicitation: This is also known as gathering ofrequirements. Here,

requirements are identified with the help of customer and existing systems processes, if
available.
(ii) Requirements analysis: Analysis of requirements starts with requirement
elicitation. The requirements are analysed in order to identify inconsistencies, defects, omissions
\
etc. We describe requirements in terms of relationships and also resolve conflicts, if a ny.
(iii) Requirements documentation: This is the end product of requirements elicitation
and analysis. The documentation is very important as it will be the foundation for the design
of the software. The document is known as software requirements specification (SRS).
(iv) Requirements review: The review process is carried out to improve the quality of
the SRS. It may also be called as r equirements verification. For maximum benefits, review
and verification should not be treated as a discret e activity to be done only at the end of the
preparation of SRS. It sh ould be treated as continuous activity that is incorporated into the
elicitation, analysis, and documentation.
The primary output of requirements engineering is requirements specifications. If it
describes both hardware and software, it is a system requirements specification. Ifit describes
only software, it is a software requirements specification. In either case, a requirements
specification must treat the system as a black box. It must delineate inputs, outputs, the
functional requirements that show external behaviour in terms of input , output, and their
relationships, and non-functional requirements and their constraints, including performance,
portability, and reliability.
The software requirements specification (SRS) should be internally consistent; consistent
with existing documents; correct and complete with r~spect to satisfying needs; understandable
j 42 Software Engineering

to users, customers, designers, and testers; and capable of serving as a basis for both design
and test. This SRS document may act as contract between the developer and customer. If
developer fails to implement full set ofrequirements, it may amount to failure in implementing
the contracted system.

3.1 .2 Present State of Prartice

Most software development organizations agree to the fact that there should be a set of activities
called requirements engineering and their success is vital to the success of the entire project.
So why is the state of the practice no better than it is? There are several reasons, not all of
them obvious [BERR98, DAV194, HSIA93]; and some are discussed below:
1. Requirements are difficult to uncover: Today we are automating virtually every
kind of task-some that were previously done manually and some that have never been done
before. In either kind of application, it is difficult, if not impossible to identify all
the requirements, regardless of the techniques we use. No one can see a brand new system in
its entirety. Even if someone could, the description is always incomplete l'J.t start. Users and
developers must resort to trial and error to identify problems and solutions.
2. Requirements change: Because no user can come up with a complete list of
requirements at the outset, the requirements get added and changed as the user begins to
understand the system and his or her real needs. That is why we always have requirement
changes. But, project schedule is seldom adjusted to reflect these modifications. Fluid
requirements make it difficult to establish a baseline from which to design and test. Finally, it
is hard to justify spending resources to make a requirement specification "perfect", because it
will soon change anyway. This is the biggest problem, and there is as yet no technology to
overcome it. This problem is often used as an excuse to either eliminate or scale back
requirements engineering effort.
3. Over-reliance on CASE tools: Computer Aided Software Engineering (CASE) tools
are often sold as panaceas. These exaggerated claims, have created a false sense of trust,
which could inflict untold damage on the Software Industry. CASE tools are as important to
developers (including requirement writers) as word processors are to authors. However, we
must not rely on requirements engineering tools without first understanding and establishing
requirements engineering principles, techniques and processes. Furthermore, we must have
realistic expectations from the tools.
4. Tight project schedule: Because of either lack of planning or unreasonable customer
demand, many projects start with insufficient time to do a decent job. Sometimes, even the
allocated time is reduced while the project is under way. It is also customary to reduce time set -1
apart to analyze requirements, for early start of designing and coding, which frequently leads
to disaster.
5. Communication barriers: Requirement engineering is communication intensive
activity. Users and developers have different vocabularies, professional backgrounds, and
tastes. Developers usually want more precise specifications while users prefer natural
language. s·electing either results in misunderstanding and confusion.
 Software Requirements : Analysis and Specifications 43

6. Market-driven software development: Many of the software development is today

market driven, developed to satisfy anonymous customers and to keep them coming back to
buy upgrades.
7. Lack of resources: There may not be enough resources to build software that can do
everything the customer wants. It is essential to rank requirements so that, in the face of
pressure to release the software quickly, the most important can be implemented first.
Requirement problems are expensive and plague almost all systems and software
development organizations. In most cases, the best we can hope for it is to detect errors in the
requirements in time to contain them before the software is released [SAWY99]. Because of
the concern for public safety, reputation and capital investments; developers began to recognize
the need for clear, concise and complete requirements [COUN99].
Example 3.1: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 p roblem statement may give an overview of the existing system and broad
expectation from the new software system.
Solution: The problem statement is prepared by the Examination division of the
University and is given below:
"A University conducts a 4-semester M. Tech programme. The students are offered four
theory papers and two Lab papers (practicals) during 1st, Ilnd and Illrd semesters. The theory
papers offered in these semesters a re categorized as aither 'Core' or 'Elective'. Core p~pers do
not have an alternative subject, whereas elective papers may have two or more alternative
subjects. Thus a student can study any subject out of the choices available for an elective
paper.
In 1st, Ilnd and Illrd semesters, 2 core papers and 2 elective papers are offered to each
student. The students are also required to submit a term paper minor project in Ilnd and Illrd
semesters each. In IVth semester the students have to give a seminar and submit a dissertation
on a topicJsubject area of their interest.
The evaluation of each subject is done out of 100 marks. During the semester, minor
exams are conducted for each semester. Students are also required to submit assignments as
directed by the corresponding faculty and maintain Lab r ecords for practicals. Based on the
students' performance in minor exams, assignments, Lab records and their attendance, marks
out of 40 are given in each theory paper and practical paper. These marks out of 40 account for
internal evaluation of the students. At the end of each semester, major exams are conducted in
each subject (theory as well as practical). These exams are evaluated out of 60 marks and
account for external evaluation of the students. Thus, the total marks of a student in a subject
are obtained by adding the marks obtained in internal and external evaluation.
Every subject has some credit points assigned to it. If the total marks ofa student are>
= 50 in a subject, he/she is considered 'Pass' in that subject otherwise the student is considered
'Fail' in that subject. If a student passes in a subject he/she earns all the credit points assigned
to that subject, but if the students fails in a subject he/she does not earn any credit point in
that subject. At any time, the l?ttest information about subjects being offered in various semesters
and their credit points can be obtained from University Website.
144 Software Eng.nee~n;

It is required to develop a system that will manage information about subjects offered :.::
various semesters, students enrolled in various semesters, elective (s) opted by various studen::.s
in different semesters, marks and credit points obtained by students in different semesters_
The system should also have the ability to generate printable mark-sheets for each studen_:.
Semester-wise detailed mark-lists and student performance reports also need to be generated.
Example 3.2:A university wishes to develop a software system for library management activities.
Design the problem statement for the software company.
Solution: The problem statement prepared by the library staff of the university is given
below. Here activities are explained point wise rather than paragraph wise.
A software has to be developed for automating the manual library system of a Uni,·er-
sity. The system should be standalone in nature. It should be designed to provide functionalities
as explained below:
1. Issue of books
(a) A student of any course should be able to get books issued.
(b) Books from General section are issued to all but Book bank books are issued only
for their respective courses.
(c) A limitation is imposed on the number of books a student can be issued.
(d) A maximum of 4 books from book bank and 3 books from general section per student
is allowed.
(e) The books from book bank are issued for entire semester while books from general
section are issued for 15 days only.
(f) The software takes the current system date as the date of issue and calculates the
corresponding date of return.
(g) A bar code detector is used to save the student information as well as book information.
(h) The due date for return of the book is stamped on the book.

2. Return of books
(a) Any person can return the issued books.
(b) The student information is displayed using the bar code detector.
(c) The system displays the student details on whose name the books were issued as
well as the date of issue and return of the book .
(d) The system operator verifies the duration for the issue and if the book is being returned
after the specified due date, a fine of Re 1 is charged for each day.
(e) The information is saved and the corresponding updations take place in the database.
3. Query processing
(a) The system should be able to provide informat ion like:
(i) Availability of a particular book
(ii) Availability of books of any particular author.
(iii) Number of copies available of the desired book.
(b) The system should be able to reserve a book for a particular student for 24 hrs if that
book is not currently available.
 Software Requirements : Analysis and Specifications 45

The system should also be able to generate reports regarding the details of the books
available in the library at any given time.
The corresponding printouts for each entry (issue/return) made in the system should be
generated.
Security provisions like the login authenticity should be provided. Each user should
have a user id and a password. Record of the users of the system should be kept in the log file.
Provision should be made for full backup of the system.

3.2 TYPE OF REQUIREMENTS

There are different types of requirements such as:
(i) Known requirements-Something a stakeholder believes to be implemented.
(ii) Unknown requirements-Forgotten by the stakeholder because they are not needed
right now or needed only by another stakeholder.
(iii) Undreamt requirements-Stakeholder may not be able to think of new requirements
due to limited domain knowledge.
The term stakeholder is used to refer to any one who may have some direct or indirect
influence on the system requirements. Stakeholder includes end-users who will interact with
the system and every one else in an organisation who will be affected by it [SOMM0l).
A known, unknown, or undreamt requirement may be functional or non-functional. Func-
tional requirements describe what the software has to do. They are often called product fea-
tures.
Non-functional requirements are mostly quality requirements that stipulate how well
the software does what it has to do. Non-functional quality requirements that are especially '
important to users include specifications of desired performance, availability, reliability, us-
ability and flexibility. Non-functional. requirements for developers are maintainability,
portability, and testability.
Some requirements are architectural, such as component-naming compatibility,
interfaceability, upgradability, etc. Other requirements are constraints, such as system design
constraints, standards .conformance, legal issues and organisational issues. Constraints can
come from users or organisations and may be functional or non-functional [ROBE02).

3.2.1 Functional and Non-functional Requirements

Software requirements are broadly classified as functional and non-functional requirements.
(i) Functional requirements: These are related to the expectations from the intended
software. They describe what the software has to do. They are also called product features.
Sometimes, functional requirements may also specifiy what the software should not do.
(ii) Non-Functional requirements: Non-functional requirements are mostly quality
requirements that stipulate how well the software does what it has to do. Non-functional
requirements that are especially important to users include specifications of desired
performance, availability, reliability, usability and flexibility. Non-functional requirements
for developers are maintainability, portability and testability.
7/
46 Software Engineering

The functional requirements are directly related to customer's expectations and are
essential for the acceptance of product. However, non-functional requirements may make the
customer happy and satisfied. These requirements are important for the success of any product.
Sometimes, distinction between functional and non-functional may not be easy. If we 'Yant to
develop a secure system, security becomes crucial to us. It is a non-functional requirements
apparently, but when design is carried out, it may have serious implications. These implications
may also be reflected in functional requirements and sh ould therefore find a place in the
functional requirements category of SRS document.
The term stakeholder is used to refer to anyone who may have some direct or indirect
influence on the system requirements. "Stakeholder" includes end-users who will interact with
the system and everyone else in an organisation who will be affected by it [SOMM0l].
Some requirements are known requirements wh ich a stakeholder believes to be
implemented. Some are unknown to one stakeholder but may be required by another. Some
requirements may be undreamt requirements for the stakeholder due to limited domain
knowledge. However, a known, unknown, or undreamt requirement may be functional or non-
functional depending upon its nature.

3.2.2 User and System Requirements

User requirements are written for the users and inclu de functional and non-functional
requirements. Users may not be the experts of the software field ; hence simple language
_should be used. The software terminologies, notations etc. should be avoided. User requirements
should specify the external behaviour of the system with some constraints and quality
parameters. However, design issues should be avoided. Hence, we should only highlight the
overview of the system without design characteristics. System requirements are derived from
user requirements. They are expanded form of user requirements. They may be used as input
to the designers for the preparation of software design document. The user and system
requirements are the parts of software requirements and specification (SRS) document. There
are various ways of writing these requirements ; however IEEE std. 830- 1998 (for SRS)
frarr,,ework is very popular and used by many software organisations.

3.2.3 Interface Specification

Interface issues are very important for the customers. A good software may not be appriciated
if interfaces are not as per expectations of the customers. The types of interfaces are :
(i) Procedural interfaces: Some services are offered by calling interface procedures.
These interfaces are called Application Programming Interfaces (APis).
(ii) Data structures: Data structures are used to tra nsfer information from one module
to another module. This can be represented using graphical data models. ·
(iii) Representations of data: The issues related to ordering of bits are established
here. Some are common in embedded systems and microprocessor applications. One of the
methods to describe these is to use a diagram of the structure with annotations explaining the
function of each group [SUMM0l,].
 Software Requirements : Analysis and Specifications 47

Some formal notations are available in the literature with some strengths and
weaknesses.

3.3 FEASIBILITY STUDIES

Is cancellation of a project a bad news ? As per IBM report, "31% projects get cancelled before
they are completed, 53% over-run their cost estimates by an average of 189% and for every 100
projects, there are 94 restarts" [IBMG2K]. Caper Jones reports that the average cancelled
project in the US is about a year behind schedule and has' consumed 200% of its expected
budget by the time it is cancelled [CAPE94]. He further estimates that the work on cancelled
projects comprises about 15% of the total US software efforts.
In spite of these statistics, cancelling a project is, in itself, neither good nor bad. Cancelling
a project later than necessary is bad. The trick is to perform the minimum amount of work
necessary to determine whether the project should be cancelled.
How do we cancel a project with the least work ? One of the most effective ways is to
conduct a feasibility study to determine whether the full scale project is workable. This study
culminates in a feasibility report, which enables project team, customer, or upper manage-
ment make a go/no go decision about rest of the project. Feasibility studies are a time tested
practice, but they are not used very much. One reason might be the term "feasibility study"
itself. The term sometimes relates to technical feasibility and question of technical feasibility
rarely enters in the minds of software developers. If we know that project is technically feasi-
ble, why should we conduct a feasibility study ?
For few projects , technical feasibility may be very important and significant. Is it
technically feasible to provide direct communication connectivity through space from one
location of globe to another location ? It is technically feasible to design a programming language
using "Sanskrit" (Ancient Indian Language) ? However, for most of the projects, feasibility
depends on non-technical issue-s Hke-:
- Are the project's cost and schedule assumptions realistic ?
- Is the business model realistic ?
- Is there any market for the product ?

3.3.1 Purpose of Feasibility Studies

The decision to implement any new project or program must be based on a thorough analysis
of the proposed project/program.
A feasibility study is defined as an evaluation or analysis of the potential impact of a'
proposed project or program. It is conducted to assist decision makers in determining whether
or not to implement a project/program. It is based on extensive research on both the current
practices and the proposed project or program and its impact .on the system as a whole. It
should also contain extensive data analysis related to financial and operational impact and
should include advantages and disadvantages of both the current situation and the proposed
project.
 48 Software Engineering

3.3.2 Focus of Feasibility Studies

Steve McConnel [SIEV98] has given the following points on which a feasibility study
should focus and give proper emphasis to get good results:
(i ) Is the product concept viable ?
(ii) Will it be possible to develop a product that matches the project's vision statement ?
(iii ) What are the current estimated cost and schedule for the project?
(iv) How big is the gap between the original cost and schedule targets and cm;rent
estimates?
(v) Is the business model for software justified when the current cost and schedule esti-
mates are considered ?
(vi) Have the major risks to the project been identified and can they be surmounted?
(vii) Are the specifications complete and stable enough to support re1haining development
work?
(viii) Have users and developers been able to agree on a detailed user interface prototype ?
If not, are the requirements really stable ?
(ix) Is the software development plan complete and adequate to support further
development work ?
The work done during the first 10 to 20 percent of the project should sufficiently answer
these questions and give the client or top management enough information to decide whether
to fund the rest of the project.
Breaking a software project into a feasibility study phase and a main development phase
(starting from requirements elicitation) helps software organisations in at least three ways:
(i ) Some people view any cancelled project as a failure. But a project cancelled at 10
to 20 percent level vis-a-vis completion point should not be considered a failure. Can-
celling one project that ultimately goes no where after it is only 10 to 20 percent
complete instead of 80 to 90 percent complete should always be a good decision.
(ii ) Feasibility study can be conducted with marginal funds. After the final decision about
project, more accurate and realistic estimate can be prepared. This may help us to
reduce the cost variations.
(iii ) The project team will complete 10 to 20 percent of a project before requesting funding
for the rest of it forces a focus on upstream activities that are critical to a project's
success. Otherwise these activities are often ignored, and the damaging consequences
of such neglect would not become apparent until late in the project.

3.4 REQUIREMENTS ELICITATION

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 [WIEG99].
The real requirements actually reside in user's min d. Hence the most important goal of
requirement engineering is to find out what users really need. Users need can be identified
only if we understand the expectations of the users from the desired software.
 Software Requirements : Analysis and Specifications 49

It is the activity that helps to understand the problem to be solved. Requirements are
gathered by asking questions, writing down the answers, asking. other questions, etc. Hence,
requirements gathering is the most communications intensive activity of software develop-
ment. Developers and Users have different mind set, exper tise and vocabularies. Due to com-
munication gap, there are chances of conflicts that may lead t o inconsistencies, misunder-
standing and omission of requirements.
Therefore, requirements elicitation requires the collaboration of several groups of par-
ticipants who have different background. On the one hand, customers and users have a solid
background in their domain and have a general idea of what the software should do. However,
they may have little knowledge of solfware development processes. On the other hand, the
developers have experience in developing software but may have little knowledge of everyday
environment of the users. Moreover each group may be using incompatible terminologies.
There are number ofrequirements elicitation methods and few of them are discussed in
the following sections. Some people think that one methodology is applicable to all situations,
however, generally speaking, one methodology cannot possibly be sufficient for all conditions
[MACA96]. We select a particular methodology for the following reason(s):
(i ) It is the only method that we know.
(ii) It is our favorite method for all situations.
(i ii) We understand intuit ively that the method is effective in the present circumstances.
Clearly, third reason demonstrates the most maturity and leads to improved under-
standing of stakeholder's needs and thus resulting system will satisfy those nefds. Unfortu-
nately, most of us do not have the insight necessary to make such an informed decision, and
therefore rely on the first two reasons [HICK03].

3.4.1 Interviews
After receiving the problem statement from the customer, the first step is t o arrange a meeting
with the customer. During the meeting or interview, both the parties would like to understand
each other. Normally specialised developers, often called 'requirement engineers' interact with
the customer. The objective of conducting an interview is to understand the customer's
expectations from the softwa re. Both parties have different feelings, goals, opinions,
vocabularies, understandings, but one thing is common, both want the project to be a success.
With this in mind, requirement engineers normally arrange interviews. Requirement engineers
must be open minded and should not approach the interview with pre-conceived notions about
what is required.
Interview may be open-ended or structured. In open-ended interview, there is no pre-set ag~nda.
Context free questions may be asked to understand the problem and to have an overview of
the situation. For example, for a "result management system", requirement engineer may ask:
• Who is the controller of examination ?
• Who has requested for such a software ?
• How many officers are placed in the examination division ?
• Who will use the software ?
• Who will explain the manual system ?
 50 Software Engineering

• Is there any opposition for this project ?

• How many stakeholders are computer friendly ?
Such questions help to identify all stakeholders who-will have interest in the software to
be developed.
In structured inter view, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview. Interview may be started with simple questions to
set people at ease. After making atmosphere comfortable and calm, specific questions may be
asked to understand the requirements. The customer may be allowed to voice his or her
perceptions about a possible solution.
Selection of stakeholder: It will be impossible t o interview every stakeholder. Thus,
representatives from groups must be selected based on their technical expertise, domain
knowledge, credibility, and accessibility. There are several groups to be considered for conducting
interviews:
(i) Entry level personnel: They may not have s ufficient domain knowledge and
experience, but may be very useful for fresh ideas and different views.
(ii ) Mid-level stakeholders: They have better domain knowledge and experience of the
project. They know the sensitive, complex and critical areas of the project. Hence,
requirement engineers may be able to extract meaningful and useful information.
Project leader should always be interviewed.
(iii) Managers or other Stakeholders: Higher level management officers like Vice-
Presidents, General Managers, Managing Directors should also be interviewed. Their
expectations may provide different but rich information for the software development.
(iv) Users of the software: This group is perhaps the most important because they will
spend more time interacting with the software than any one else. Their information
may be eye opener and may be original at times. Only caution required is that they
may be biased towards existing systems.
Types of questions: Questions should be simple and short. Two or three questions
rolled into one can lead to compound requirements statements that are difficult to interpret
and test. It is important _to prepare questions, but reading from the questionnaire or only
sticking to it is not desirable. We should be open for any type of discussion and any direction of
the interview. For the "result management system" we may ask:
• Are there any problems with the existing system ?
• Have you faced calculation errors i~ past ?
• What are the possible reasons of malfunctioning ?
• How many students are enrolled presently ?
• What are the possible benefits of computerising this system ?
• Are you satisfied with current processes and policies ?
• How are you maintaining the records of previous students ?
• What data, required by you, exists in other systems ?
• What problems do you want this system to solve ?
 Software Requirements : Analysis and Specifications ,51

• Do you need additional functionality for improving the performance of the system ?
• What should be the most important goal of the proposed development ?
These questions will help to start the communication that is essential for understand-
ing the requirements. At the end of this, we may have wide variety of expectations from the
proposed software.

3.4.2 Brainstormtng Sessions

Brainstorming is a group technique that may be used during requirements elicitation t o
understand the requirements. The group discussions may lead to new ideas quickly and help
to promote creative thinking.
It is intended to generate lots of ideas, with full understanding that they may not be
useful. The theory is that having a long list of requirements from which to choose is far superior
to starting with a blank slate. Requirements in the long list can be categorized, prioritized,
and pruned [ROBE02].
Brainstorming has become very popular and is being used by most of the companies. It
promotes creative thinking, generates new ideas and provides plateform to share views,
apprehensions expectations and difficulties of implementation. All participants are encouraged
to say whatever ideas come to mind, whether they seem relevant or not. No one will be criticized
for any idea, no matter how goofy it seems, as the responsibility of the participant is to generate
views and not to vet them.
This group technique may be carried out with specialised groups like actual users, middle
level managers etc., or with total stakeholders. Sometimes unnatural groups are created that
may not be appriciat ed and are uncomfortable for participants. At times, only superficial
responses may be gathered to technical questions. In order to handle such situations, a highly
trained facilitator may be required. The facilitator may handle group bias and group conflicts
carefully. The facilita tor should also be cautious about individual egos, dominance and will be
responsible for smooth conduct of brainstorming sessions. He or she will encourage the
participants, ensure proper individual and group behaviour and help to capture the ideas. The
facilitator will follow a published agenda and restart the creati_;e process if it falters.
Every idea will be documented in such a way that everyone can see it. White boards,
overhead transparencies or a computer projection system can be used to make it visible to
every participant. Aft er the session, a detailed report will be prepared and facilitator will
review the report. Every id~a will be written in simple english so that it conveys same meaning
to every stakeholder. Incomplete ideas may be listed separately and should be discussed at
length to make them complete ideas, if possible. Finally, a document will be prepared which
will h ave list of requirements and their priority, if possible.

3.4.3 Facilitated Application Specification Technique

This approach is similar to brainstorming sessions and the objective is to bridge the expectation
gap - a difference between what developers think they are supposed to build and what customers
think they are going to get. In order to reduce expectation gap, a team oriented approach i.s
developed for requirements gathering and is called Facilitated Application Specification
Technique (FAST).
 Software Engineering

This approach encourages the creation of a joint team of customers and developers who
work together to understand the expectations and propose a set of requirements. The basic
guidelines for FAST are given below:
• Arrange a meeting at a n eutral site for developers and customers.
• Establishment of rules for preparatjon and participation.
• Prepare an informal agenda that encourages free flow of ideas.
• Appoint a facilitator to control the meeting. A facilitator may be a developer, a
customer, or an outside expert.
• Prepare a definition mechan~sm-board, flip charts, worksh eets, wall stickies, etc.
• Participants should not criticize or debate.
FAST session preparations
Each FAST attendee is asked to make a list of objects that ar e:
(i ) part of the environment that surrounds the system
(ii) produced by the system
(iii) used by the system.
In a ddition, each attendee is asked to make another list of services (processes or functions)
that manipulate or interact with the objects. Finally, lists of constraints (e.g., cost, size) and
performance criteria (e.g., speed, accuracy) are a lso 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 [PRES2K).
Activities of FAST session
The activities during FAST session may have the following steps:
• Each participant presents his or h er lists of object s, services, constraints, and
performance for discussion. Lists may be displayed in the meeting by using board,
large sh eet of paper_or any other mechanism, so th at they are visible to all the
participants.
• The combined lists for each topic are prepared by eliminating redundant enteries and
adding new ideas.
• The combined lists are again discussed and consensus lists are finalised by the
facilitator.
• Once the consensus lists have been completed, the team is divided into smaller
subteams, each works to develop mini-specifications for one or more enteries of the
lists.
• Each subteam then presents mini-specifications to all FAST attendees. After discus-
sion, additions or deletions are made to the lists. We may get new objects, services,
constraints, or performance requirements to be added to original lists.
• During all discussions, the team may raise an issue th at cannot be resolved during
the meeting. An issues list is prepared so that these ideas will be considered later.
• Each attendee prepares a list of validation criteria for the product/system and presents
the list to the team. A consensus list of validation criter ia is then created.
 Software Requirements : Analysis and Specifications 57

C)
Actor Use case Relationship between
actors and use case and/or
between the use cases

Fig. 3.2: Components of use case diagram

\
Actors appear outside of the rectangle since they are external to the system. Use cases
appear within the rectangle, providing functionality. A relationship or association is a solid
line between an actor and each use case in which actor participates- the involvement can be
any kind, not necessarily one of the actor initiating t h e use case functionality.
Fig. 3.2 shows an example of a use case diagra m whose "Problem statement" is given in
Table 3.2.
Table 3.2: Problem statement for railway reservation system

PROBLEM STATEMENT FOR RAILWAY RESERVATION SYSTEM

A software has to be developed for automating the manual railway reservation system. The system
should be distributed in nature. It should be designed to provide functionalities as explained
below:
1. Reserve Seat: A pa ssenger should be able to reserve seats in the train. A r eservation
form is filled by the passenger and given to the clerk, who then checks for the availability
of seats for the specified date of journey. If seats are available, then the entries are made
in the system regarding the train name, train number, date of journey, boarding station,
destination, person name, sex and total fare. Passenger is asked to pay the required fare
and the tickets are printed. It the seats are not available then the passenger is informed.
2. Cancel Reservation: A passenger wishing to cancel a reservation is required to fill a
form. The passenger then submits the form and the ticket to the clerk. The clerk then
deletes the entries in the system and changes in the r eservation status of that train. The
clerk crosses the ticket by hand to mark as cancelled.
3. Update Train Information: Only the administrator enters any changes related to the
train information like change in the train name, train number, train route etc. in the
system.
4. Report Generation: Provision for generation of different reports should be given in the
system. The system should be able to generate r eservation chart, monthly train report etc.
5. Login: For security reasons all the users of the system are given a user id and a password.
Only if the id and password are correct the user is allowed to enter the system.
6. View Reservation Status: All the users should be able to see the r eservation status of
the train online. The user needs to enter the train number and the pin number printed on
his ticket so that the system can display his current reservation status like confirmed,
RAC or Wait listed.
7. View Train Schedule: Provision should be given to see information related to the train
schedules for the entire train network. The user should be able to see the train name,
train number, boarding and destination stations, duration of journey etc.

Use cases should not be used to capture all the details of system. The granularity to
which we define use cases in a diagram should be enough to keep the use case diagram
uncluttered and readable, yet, be complete without missing significant aspects of the required
 58 Software Engineering

functionality. Design issues should not be discussed at all. Use cases are meant to capture
"what" the system is, and not ''how" the system will be designed or built. Hence use cases
should be free of any design characteristics. If we end up defining design characteristics in a
use case, we need to go back to the drawing board and start again .

.---<=)
Update train informations

Report generation
Admin

Login

~
Passenger

~
View train schedules

Reserve seat

Cacellations

Fig. 3.3: Use case diagram for railway reservation system

3.5 REQUIREMENTS ANALYSIS

Requirements analysis is very important and essential activity after elicitation. We analyze,
refine and scrutinize the gathered requirements in order to make consistent and unambiguous
requirements. This activity reviews all requirements and may provide a graphical view of the
Draw the
context diagram

Develop prototypes
(optional)

Model the
requirements

Fig. 3.4: Requirements analysis steps

/

72 Software Engineering

the actual system or even later into maintenance, should the r equirements change; the prototype
is enhanced and agreed to before the actual changes become confirmed.

3.6 REQUIREMENTS DOCUMENTATION

Requirements documentation is very important activity after the requirements elicitation and
analysis. This is the way to represent requirements in a consistent format. Requirements docu-
ment is called Software Requirements Specification (SRS).
The SRS is a specification for a particular software product, program or set of programs
that performs certain functions in a specific environment. It serves a number of purposes
depending on who is writing it. First, the SRS could be written by the customer of a system.
Second, the SRS could be written by a developer of the system. The two scenarios create entirely
different situations and establish entirely different purposes for the document. First case, SRS
is used to define the needs and expectations of the users. The second case, SRS is written for
different purpose and serve as a contract document between customer and developer.
This reduces the probability of the customer being disappointed with the final product.
The SRS written by developer (second case) is of our interest a nd discussed in the subsequent
sections.

3.6.1 Nature of the SRS

The basic issues that SRS writer (s) shall address are the following:
1. Functionality: What the software is supposed to do?
2. External interfaces: How does the software interact with people, the system's hard-
ware, other hardware, and other software?
3. Performance: What is the speed, availability, response time, recovery time, etc. of
various software functions?
4. Attributes: What are the considerations for portability, correctness, maintainability,
security, reliability etc.?
5. Design constraints imposed on an implementation: Are there any required
standards in effect, implementation language, policies for database integrity, resource
limits, operating environment (s) etc.?
Since the SRS has a specific role to play in the software development process, SRS
writer(s) should be careful not to go beyond the bounds of that role. This means the SRS
1. should correctly define all the softw?Ie requirements. A software requirement may
exist because of the nature of the task to be solved or because of a special characteristic
of the project.
2. should not describe any design or implementation details. These should be described
in the design stage of the project.
3. should not impose additional constraints on the software. These are properly specified
in other documents such as a software quality assurance plan.
Th erefore, a properly written SRS limits the range of valid designs, but does not specify
any particular design.
 Software Requirements : Analysis and Specifications 73

3.6.2 Chc!racteristics of a good SRS

The SRS should be:
- Correct
- Unambiguous
- Complete
- Consistent
- Ranked for importance and/or stability
- Verifiable
- Modifiable
- Traceable
Each of the above mentioned characteristics is discussed below: [THAY97, IEEE87,
IEEE97).
Correct
The SRS is correct if, and only if; every requirement stated therein is one that the software
_shall meet. There is no tool or procedure that assures correctness. If the software must respond
to all button- presses within 5 seconds and the SRS stated that "the software shall respond to
all buttons presses within 10 second", then that requirement is incorrect.
Unambiguous
The SRS is unambiguous if, and only if; every requirement stated therein h~s only one interpretation.
Each sentence in ·the SRS should have the unique interpretation. Imagine that a sentence is
extracted from the SRS, given to ten people who are asked for their interpretation. If there is
more than one such interpretation, then that sentence is probably ambiguous.
In cases, where a term used in a particular context could have multiple meanings, the
term should be included in a glossary where its meaning is made more specific. The SRS
should b e unambiguous to both those who create it and to those who use it. However, these
groups often do not have the same background and therefore do not tend to describe software
requirements iri the same way.
Requirements are often written in n atural language (for example, english ). Natural
language is inherently ambiguous. A natural language SRS should be reviewed by an inde-
pendent party to identify ambiguous use of a language so that it can be corrected. This can be
avoided by using a particular requirement specification language. Its language processors
automatically detect many lexical, syntactic, and semantic errors. Disadvantage is the time
required to learn the la nguage which may also not be understandable to the customers/users.
Moreover, these languages tend t o be better at expressing only certain types of requirements
and addressing certain types of systems.
Complete
The SRS is complete if, and only if; it includes the following elements :
1. All significant requirements, wheth er relating to functionality, performance, design
constraints, attr ibutes or external interfaces.
1234 Software Engineering

(d) Generalizations are used to show an inheritance relationship between two classes.
----1C>
We may design the class diagram of a complete system. Obviously, this may become
very huge, for complex systems. In such a case, one class diagram is made for each use case.
This restricts the size of the class diagram and is useful when delegating/assigning the task to
a software developer ; since he/she would only need to see the related class diagram of the
assigned use case; rather than looking at the complete class diagram and then filtering out the
concepts related to his/her use-case. We may also draw object diagram, which shows a set of
objects and their relationships. They represent static snapshots of instances of the things found
in class diagrams, from the perspective of real cases.
( u) Design of state chart diagrams: A state chart diagram is used to show the state
space of a given class, the event that cause a transition from one state to another, and the
actions that result from a state change. It shows the changing behaviour of an object in re-
sponse to different events. State transition diagrams are made only for the objects that are
either very complicated or have a very dynamic behaviour with respect to various events.
Normally, we would not need to make state diagrams. A state transition diagram for a "book"
in the library system is given in Fig. 5.28.

Purchase Book is numbered

New
book & stamped

Book is Book is
returned issued
Book is
Disposed - ~ o=ld~ o
=r~ Issued
damaged

Fig. 5.28: Transition chart for 'book' in a library system

(vi ) Draw component and development diagram: Component diagrams address the
static implementation view of a system they are related to class diagrams in that a component
typically maps to one or more classes, interfaces or collaboration. Deployment diagram captures
relationship between physical components and the hardware.
After the completion of above mentioned steps, we will have many documents and com-
plete understanding of flow of data, control and relationships of classes. These things are the
foundations for implementing an object oriented system.

5.6.3 Case Study of Library Management System

The problem statement for library management system is given below:

Problem statement
A software has to be developed for automating the manual library of a University. The system
should be stand alone in nature. It should be designed to provide functionality's as explained
below:
j Software Design

Issue of books
• A student of any course should be able to get books issued.
• Books from general section are issued to all but book bank books are issued only for
their respective cou rses.
• A limitation is imposed on the number of books a student can issue.
• A maximum of 4 books from book bank and 3 books from general section is issued for
15 days only.
• The software takes the current system date as the date of issue and calculates date of
return.
• A bar code detector is used to save the student as well as book information.
• The due date for r eturn of t he book is stamped on the book.
Return of books
• Any person can return the issued books.
• The student information is displayed using the bar code detector.
• The system displays the student details on whose name the books were issued as well
as the date ·of issue and return of the book.
• The system operator verifies the duration for the issue.
• The information is saved and the corresponding updating take place in the database.
Query processing
The system should be able to provide information like:
• Availability of a particular book.
• Availability of book of any particular author.
• Number of copies available of the desired book.
The system should also be able to generate reports regarding the details of the books
available in the library at any given time. The corresponding printouts for each entry (issue/
return) made in the system should be generated. Security provisions like the 'login authentic-
ity should be provided. Each user should have a user id and a password. Record of the users of
the system should be kept in t he log file. Provision should be m a de for full backup of the
system.

Use cases
From the problem description , we can see t hat the system has four actors.
1. Librarian
2. Operator
3. Bar Code Reader
4. User
To define system's functionalities, we can view the. system as a collection of following
use cases:
1. Login 2. Issue Book
3. Return Book _4. Query Book
1236 Software Engineering I
5. Maintain Catalog 6. Generate Report
7. Maintain Login 8. Maintain student Details

1. Login

8. Maintain student detail

-----c_)
2. Issue book

Bar code
reader

Librarian

User

Use case diagram for library management system

USE CASE DESCRIPTION

I. LOGIN
I.I. Introduction_
This use case documents the procedure for logging into the Library Management
System based on user privileges.
• Operator (Issue Book, Return Book, Query a Book, Maintain Catalogue, Main-
tain Student Detail)
• Librarian (Generate Reports, Maintain Login)
1.2 Actors
Operator, Librarian
 Software Design
5
Software design is more creative process than analysis because it deals with the development
of the actual mechanics for a new workable system. While analysing, it is possible to produce
the correct model of an existing system. However, there is, no such thing as correct design.
Good design is always system dependent and what is good design for one system may be bad
for another.
The design of the new system must be done in great detail as it will be the basis for
future computer programmin g and system implementation. Design is a problem-solving activity
and as such, very much a matter of trial and error. The designer, together with users, has to
search for a solution using his/her professional wisdom until there is an agreement that a
satisfactory solution has been found.
For small projects (such as student's projects), one can sit with the specifications and
simply write a program. For larger projects, it is necessary to bridge the gap between specifi-
cations and the coding with something more concrete. This bridge is the software design.

5.1 WHAT IS DESIGN?

Design is the highly significant phase in the software development where the designer plans
"how" a software system sh ould be produced in order to make it functional, reliable and
reasonably easy to understand, modify and maintain. A software requirements specifications
(SRS) document tells us "what" a system does, and becomes input to the design process, which
tells us "how" a software system works. Designing software systems means determining how
requirements are realized and result is a software design document (SDD). Thus, the purpose
of design phase is to produce a solution to a problem given in SRS document.
A framework of the design is given in Fig. 5.1. It starts with initial requirements and
ends up with the final design. Here, data is gathered on user requirements and analysed
accordingly. A high level design is prepared after answering questions of requirements.
Moreover, design is validated against requirements on regular basis. Design is refined in every
cycle and finally it is documented to produce software design document. Fig. 5.1 shows the
design framework.

203
j 204 Software Engineering

Initial requirements

~ *
ther data on user requirement - - - - - - - - - - ,

r---L--- c
Analyze the requirements data

Validate the design against Obtain answers to

the requirements requirement questions

~ ive of a high-level design

- -- - - -
- ~i --=---=
Refine and document the desig~r - --- - - -

Completed design

Fig.' 5.1 : Design framework

5.1.1 Conceptual and Technical Designs

The process of software design involves the transformation of ideas into detailed implementa-
tion descriptions, with the goal of satisfying the soi'ftw{re requirements. To transform require-
ments into a working system, designers must satisfy both customers and the system builders
(coding persons). The customers understand what the system is to do. At the same time, the
system builders must understand how the system is to work. For this reason, design is really
a two part, iterative process. First, we produce conceptual design that tells the customer ex-
actly what the system will do. Once the customer approves the conceptual design, we translate
the conceptual design into a much more detailed document, the technical design, that allows
system builders to understand the actual hardware and software needed to solve the custom-
er's problem. This two part design process is shown in Fig. 5.2.

D
conceptual
design
/ :i
g
n
e
r
s \

Customers [-;stem builders

Fig. 5.2: A two-part design process

 Software Design 205

The two design documents describe the same system, but in differen t ways because of
:he different audiences for the document s. The conceptual design answers the following ques-
::ons [PFLE98].
• Where will the data come from?
• What will happen to the data in the system?
• How will the system look to users?
• What choices will be offered to users?
• What is the timing of events?
• How will the reports and screens look like?
The conceptual design describes the system in language understandable to the cus-
w mer. It does not contain any technical jargons and is independent of implementation.
By contrast , the technical design describes the hardware configuration, the software
needs, the communications interfaces, the input and output of the system, the network archi-
tectur e, and anything else that translates the requirements into a solution to t he customer's
problem.
Sometimes customers are very sophisticated and they can understand the "what" and
""now" together. This can happen when customers are themselves software developers and
may not require conceptual design . In such a cases comprehensive design document may be
produced.

5.1.2 Objectives of Design

The specification (i.e. the "outside" view) of a program should obviously be as free as possible of
aspects imposed by "how" the program will work (i .e. the "inside" view). It is seldom a docu-
ment from which coding can directly be done. So design fills the gap between specifications
and coding; taking the specifications, deciding how the program will be organized, and the
methods it will use, in sufficient detail as to be directly codeable.
If the specification calls for a large or complex program (or both), then the design is
quite likely to work down through a numb~r oflevels. At each level, breaking the implementa-
tion problem into a combination of smaller and simpler problems. Filling a large gap will
involve a number of stepping-stones! The wider the gap, the larger the number of stepping-
stones. The design needs to be
• Correct and complete
• Understandable
• At the right level
• Maintainable, and to facilitate maintenance of the produced code.
Software designers do not arrive at a finished design document immediately but develop
the design iteratively through a number of different phases. The design process involves adding
details as the design is developed with constant backtracking to con-ect earlier, less formal,.
designs. The starting point is an informal design which is refined by adding infor mation to
make it consistent and complet e and this is shown in Fig. 5.3 [SOMM2K].
1 206 Software Engineering J

r r -
Informal
I More
design ►I Informal
design
- ► formal ►
Finished
design
outline design

Fig. 5.3: I hP trnr> ,formation of an informal design to a cJeta1led design

5.1.3 Why Design is Important?

A good design is the key to successful product. Almost 2000 years ago Roman Architect
Vitruvious recorded the following attributes of a good design:
• Durability
• Utility and
• Charm
A well-designed system is easy to implement, understandable and reliable and allows
for smooth evolution. Without design, we risk building an unstable system:
• One that will fail when small changes are made
• One that will be difficult to maintain
• One whose quality cannot be assessed until late in the software process.
Therefore, software design should contain a sufficiently complete, accurate and precise
solution to a problem in order to ensure its quality implementation.
There are three characteristics that serve as a guide for the evolution of a good design.
• The design must implement all of the explicit requirements contained in the analysis
model a nd it must accommodate all of the implicit requirements desired by the
customer.
• The design must be readable, understandable guide for those who generate code and
for those who test and subsequently support the software.
• The design should provide a complete picture of the software, addressing the data,
functional and behavioural domain from an implementation perspective.

5.2 MODULARITY
There are many definitions of the term "module". They range from "a module is a FORTRAN
subroutine" to "a module is an Ada package" to "procedures and functions of PASCAL and C",
to "C++ / Java Classes", to "Java packages" to "a module is a work assignment for an individual
programmer" [FAIR2K]. All of these definitions are correct. A modular system consist of well
defined, manageable units with well defined interfaces among the units. Desirable properties
of a modular system include:
I Software Design
• Each module is a well defined subsystem that is potentially useful in other applica-
tions
• Each module has a single, well defined purpose
• Modules can be separately compiled and stored in a library
• Modules can use other modules
• Modules should be easier to use than to build
• Modules should be simpler from the outside than from the inside
Modularity is the single attribute of software that allows a program to be intellectually
manageable [MYER78]. It enhances design clarity, which in turn eases implementation, de-
bugging, testing, documenting, and maintenance of the software product.
A system is considered modular if it consists of discreet components so that each compo-
nent can be implemented separately and a change to one component has minimal impact on
other components. Here, one important question arises is to what extent we shall modularize.
As the number ,of modules grows, the effort associated with integrating the module also grows.
Fig. 5.4 establishes the relationship between cost/effort and number of modules in a software.

Total software
cost -.:.___

- ··... cost .•· Cost to

~
0
Q) · · · . . . . ."·. . . . .:. . . . . .r·. . . .·· ····/ ;ntegrate

iii I
0 I
0 I

-- - -
I

I
I

eL- -

Number of modules
_

Fig. 5 .4: Modularity and software cost

I
L___ - - - -
-.

- -+

It can be observed that a software system cannot be made modular by simply chopping
it into a set of modules. Each module needs to support a well defined abstraction and should
have a clear interface through which it can interact with other modules. Thus, it is felt that
under modularity and over modularity in a software should be avoided.

5.2.1 Module Coupling

Coupling is the measure of the degree of interdependence between modules. Two module's
with high coupling are strongly interconnected and thus, dependent on each other. Two modules
with low coupling are not depe1.dent on one another. "Loosely coupled" systems are made up of
 208 Software Engineering

modules which are r elatively independent. "Highly coupled" systems share a great deal of
dependence between modules. For example, if modules make use of shared global variables.
'Uncoupled' modules have no interconnections at all; they are completely independent as shown
in Fig. 5.5.

() 0
00
Uncoupled: no dependencies
(a)

Loosely coupled : some dependencies Highly coupled: many dependencies

(b) (c)

Fig. 5.5: Module coupling

A good design will have low coupling. Thus, interfaces should be carefully specified in
order to keep low value of coupling.
Coupling is measured by the number of interconnections between modules. For exam-
ple, coupling increases as the number of calls between modules increases, or the amount of
shared data increases. The hypothesis is that design with high coupling will have more error~.
Loose coupling, on the other hand, minimizes the interdependence amongst modules. This can
be achieved in the following ways:
° Controlling the number of parameters passed amongst modules
eAvoid passing undesired data to calling module
• Maintain parent/child relationship between calling and called modules
• Pass data, not the control information
Fig. 5.6 demonstrates two alternative design for editing a student record in a "Student
Information System".
The first design demonstrates tight coupling wherein unnecessary information as stu-
dent name, student address, course is passed to the calling module. Passing superfluous infor-
mation unnecessary increases the overhead, reducing the system performance/efficiency.
[ 214 Software Engineering ]

5.3 STRATEGY OF DESIGN

A good system design strategy is to organize the program modules in such a way that are easy
to develop and later to, change. Structured design techniques help developers to deal with the
size and complexity of programs. Analysts create instructions for the developers about how
code should be written and how pieces of code should fit together to form a program. It is
important for two reasons:
• First, even pre-existing code, if any, needs to be understood, organized and pieced
together.
• Second, it is still common for the project team to have to write some code and produce
original programs that support the application logic of the system.
In early days, if any design was done, it was just "writing down the flowchart in words".
Many people feel that flowcharts are too detailed, so leading to the detail often being decided
too early, and too far from the specifications. Hence, there is a sudden jump from specifications
to flow chart that leads to the cause of many errors. Flowcharts are at a low level. As a result,
errors in flow-charts could only be found by coding them, seeing that the code ran wrongly,
diagnosing that the error is in the flow chart, then diagnosing where in the flowchart, then
fixing it, modifying code and recording. Repeated surgery on the flow chart sometimes lead to
the final flow chart where further errors can not be fixed and the project may fail.
So writers of large and complex software now seldom use flow charts for design. The
result is that we have designed other notations for expressing designs, and they are at a "higher
level" than flow charts. This helps us to minimize the length of jumps from specifications to
design and design to code. These notations usually permit multiple levels of design, and many
small jumps in place of one or two massive jumps.
There are many strategies or techniques for performing system design. They include
bottom up approach, top down approach, and hybrid approach.

5.3.1 Bottom-Up Design

A common approach is to identify modules that are required by many programs. These mod-
ules are collected together in the form of a "library". These modules may be for match func-
tions, for input-output functions, for graphical functions etc. We may have collections of mod-
ules for result preparation system like "maintain student detail", "maintain subject details",
"marks entry" etc.
This approach lead to a style of design where we decide how to combine these modules
to provide larger ones; to combine those to provide even larger ones, and so on, till we arrive at
one big module which is the whole of the desired program. The set of these modules form a
hierarchy as shown in Fig. 5.13. This is a cross-linked tree structure in which each module is
subordinate to those in which it is used.
Since the design progressed from bottom layer upwards, the method is called bottom-up
design. The main argument for this design is that if we start coding a module soon after its
design, the chances of recoding is high; but the coded module can be tested and design can be
validated sooner than a module whose sub modules have not yet been designed.
This method has one terrible weakness; we need to use a lot of intuition to decide ex-
actly what functionality a module should provide.
I Software Design

Fig. 5.13: Bottom-up tree structure

Ifwe get it wrong, then at a higher level, we will find that it is not as per requirements;
then we have to redesign at a lower level. If a system is to be built from an existing system, this
approach is more suit able, as it starts from some existing modules.

5.3.2 Top-Down Design

The essential idea of top-down design is that the specification is viewed as describing a black
box for the program? The designer should decide how the internals of the black box is constructed
from smaller black boxes; and that those inner black boxes be specified. This process is then
repeated for those inner boxes, and so on till the black boxes can be coded directly.
A top down design approach starts by identifying the major modules of the system,
decomposing them into their lower level modules and iterating until the desired level of detail
is achieved. This is stepwise refinement; starting from an abstract design, in each step the
design is refined to a more concrete level, until we reach a level where no more refinement is
needed and the design can be implemented directly. Most design methodologies are based on
this approach and this is suitable, if the specifications are clear and development is from the
scratch. If coding of a part starts soon after it's design, nothing can be tested until all its
subordinate modules are coded.

5.3.3 Hybrid Design

Pure top-down or pure bottom-up approaches are often not practical. For a bottom-up ap-
proach to be successful, we must have a good notion of the top to which the design should be
heading. Without a good idea about the operations needed at the higher layers, it is difficult to
determine what operations the current layer should support [JAL098].
For top-down approach to be effective, some bottom-up (mostly in the lowest design
levels) approach is essential for the following reasons: ·
• To permit common sub modules
• Near the bottom of the hierarchy, where the intuition is simpler, and the need for
bottom-up testing is greater, because there are more numbers of modules at low levels
than at high levels.
• In the use of pre-written library modules, in particular, reuse of modules.
1216 Software Engineering I
Hybrid approach has really become popular after the acceptance of reusability of mod-
ules. Standard libraries, microsoft foundation classes (MFCs), object oriented concepts are the
steps in this direction. We may soon have internationally acceptable standards for reusability.

5.4 FUNCTION ORIENTED DESIGN

The design activity begins when the SRS document for the software to be developed is avail-
able. The design process for software systems often has two levels. At the first level the focus
is on deciding which modules are needed for the system, their specifications of these modules,
and how the modules should be interconnected.
Function oriented design is an approach to software design where the design is decom-
posed into a set of interacting units where each unit has a clearly defined function. Thus,
system is designed from a functional viewpoint.
One of the best-known advocates of this method is Niklaus Wirth, the creator of PASCAL
and a number of other languages. His special variety is called stepwise refinement, and it is a
top down design method. We start with a high level description of what the program does.
Then, in each step, we take one part of our high level description and refine it, i.e. specify in
somewhat greater detail what that particular part does.
This method works fine for small programs. For large programs its value is more
questionable. The main problem is that it is not easy to know what a large program does. For
instance, what does UNIX do? Or an airline reservation system? Or a scheme interpreter?
The answer is that it depends on what the user types at the terminal. Still, one can usually
come up with some kind of high-level function. The risk is that this function is a highly artificial
description of reality. ·
Consider the example of scheme interpreter. Top-level function may look like:
While (not finished)
{
Read an expression from the terminal;
Evaluate the expression;
Print the value;

We thus get a fairly natural division of our interpreter into a "read" module, an "evalu-
ate" module and a "print" module. Now we consider the "print" module and is given below:
Print (expression exp)

Switch (exp ➔ type)

Case integer: /*print an integer*/
Case real: /*print a real*/
Case list: /*print a list*/
I Software Design
The other modules are structured in a similar way. We notice that the different kinds of
objects that are to be manipulated by the scheme interpreter (integer, real, etc.) need to be
known by every module. Thus, if we need to add a type, every module needs to be altered.
Needless to say, we would like to avoid that.
We continue the refinement of each module until we reach the statement level of our
programming language. At that point, we can describe the structure of our program as a tree
of refinements as in design top-down structure as shown in Fig. 5.14.

Fig. 5.14: Top-down strur:ture

Unfortunately, if a program is created top-down, the modules become very specialized.

As one can easily see in top down design structure, each module is used by at most one other
module, its parent. For a module to be reusable, however, we must require that several other
modules as in design-reusable structure as shown Fig. 5.15.

Fig. 5.15: Design reusable structure

It is, of course, not necessary to create a program top-down, even though its structure is
function-oriented. However, ifwe want to delay the decision of what the system is supposed to
do as long as possible, a better choice is to structure the program around the data rather than
around the actions taken by the program.

5.4.1 Design Notations

During the design phase there are two things of interest: the design of the system, and the
process of designing itself. It is for the latter that principles and methods are needed.
Design notations are largely meant to be used during the process of design and are used
to represent design or design decisions. For a function oriented design, the design can be rep-
resented graphically or mathematically by the following:
[ 218 Software Engineering

• Data flow diagrams .

• Data Dictionaries
• Structure Charts
• Pseudocode
The first two techniques have been discussed in chapter 3 and other two are discussed
in this section.
Structure chart
The structure chart is one of the most commonly used method for system design. It partition a
system into black boxes. A black box means that functionality is known to th e user without the
knowledge of internal design. Inputs are given to black box and appropriate outputs are gen-
erated by the black box. This concept reduces the complexity because details are hidden from
those whose have no need or desire to know. Thus, systems are easy to construct and easy to
maintain. Here, black boxes are arranged in hierarchical format as shown in Fig. 5.16.

q
o/ 4 ~

Fig. 5.16: Hierarchical format of a structure chart

b
In a structure chart, each program module is represented by a rectangular box. Modules
at the top level call the modules at the lower level. The connection between modules are repre-
sented by lines between the rectangular boxes. The components are generally read from top to
bottom, left to right. Modules are numbered in hieratical numbering scheme.
When a module calls another, it views the called module as a black box, passing param-
eters needed for the called module's functionality and receiving answers. Control data passed
between modU:les on a structure chart are represented by labelled directed arrow with filled in
circle and data is depicted with an open circle. When a module is used by many other modul~s,
it is put into the library of modules. The diamond symbol is used to represent the fact that one
module out of several modules comiected with the diamond symbol is used depending on the
outcome of the condition attached to the diamond symbol. A loop aro~nd the control flow ar-
rows denotes that the respective modules are used repeat edly and is called repetition symbol.
Fig. 5.17 shows the notations used in structure chart: