Software Engineering (PCS31104)

Module 1
Software process modeling and software requirement engineering

Software vs. Hardware

Software is a general term used to describe a collection of computer programs, procedures, and
documentation that perform some task on a computer system. Practical computer systems divide
software systems into three major classes: system software, programming software, and
application software, although the distinction is arbitrary and often blurred. Software is an
ordered sequence of instructions for changing the state of the computer hardware in a particular
sequence. Software is typically programmed with a user-friendly interface that allows humans to
interact more efficiently with a computer system.
Hardware is best described as a device, such as a hard drive, that is physically connected to the
computer or something that can be physically touched. A CD-ROM, computer display monitor,
printer, and video card are all examples of computer hardware. Without any hardware, a
computer would not function, and software would have nothing to run on. Hardware and
software interact with one another: software tells hardware which tasks it needs to perform.
Software Products
There are three types of software:
1. System Software
2. Application Software
3. Utility Software (most of the people include this as a sub-category of application
software)
System Software
System software is a collection of one or more programs used to control and coordinate the
hardware and other application software. Generally the system software may perform the
following functions:
• Communicates with hardware devices. Controls and monitors the proper use of various
hardware resources like CPU, memory, peripheral devices like monitor, printer etc.
• Supports the execution and development of other application software.
Few examples of system software are:
• Operating system
• Programming language translators
Application Software
Application software is a collection of one or more programs used to solve a specific task.
Generally software used in banking industry, airline/railway reservation, generation of telephone
or electricity bills etc. all fall under application software.
Few examples of application software are:
• Word processing software

1
 Software Engineering (PCS31104)

• Spreadsheet software
• Database software
Utility Software
Utility software is a collection of one or more programs that helps the user in system
maintenance tasks and in performing tasks of routine nature. Utility programs help the users in
disk formatting, data compression, data backup, scanning for viruses etc.
Few examples of utility software are:
• Anti-virus
• Registry cleaners
Build and fix (Exploratory) Style
• The early programmers used an exploratory style called build and fix programming style
for coding.
• It is a very informal style of program development approach, and there is no set of rules
or recommendation that programmer adhere to.
• In this type, every programmer himself evolves his own software development techniques
solely guided by his own experience.
• This type of approach mainly used by the students or the novice programmers who do not
have the exposure to software engineering principle.
Issues related to exploratory style
Besides the exponential growth of effort, cost, and time with problem size:
• Exploratory style usually results in un-maintainable code: there is no proper coding in
this type of models and thus, if any change is needed to be carried out, it is very difficult
to update or maintain the details.
• It becomes very difficult to use the exploratory style in a team development environment:
In team development environment, a group of people develop the product together. But,
when there is no common thinking or approach to develop the product, the team work
mainly fails
Human memory can be thought to be made up of two distinct parts
• Short term memory : this is also known as working memory, i.e., till the time we are
associated with any product, we know all its details and as soon as we move towards
working in any other product, the knowledge about the previous one goes out of memory.
This effect the development of the software using this exploratory style as the
programmer only have the knowledge of product he is developing.
• Long term memory: In case of long term memory, we mostly store the information for a
longer time but in memory the information are stored in parts. Thus, in the development
process, if at all we have the information about the product but if it is not complete than it
may cause errors.

2
 Software Engineering (PCS31104)

Software Crisis
o Fail to meet user requirements : In build and fix method, only the developer has the
knowledge about the requirements. Thus, the probability of missing the requirements of
user is highly probable.
o Frequently crash: In build and fix method, the developer only concerned about the
development of the parts. Thus, the proper testing is not possible, which may cause the
crash of the software.
o Difficult to alter, debug, and enhance: There is no textual description of the product to be
developed using the build and fix method. So, in future if any alteration or enhancement
is needed it is very difficult to carry out the task.
o Often delivered late: When a single person work on a project, it is quite difficult to
measure the work done, which usually make the delivery of the product late.
o Use resources non-optimally: The process of software development is both time and
money concerned. Thus, the resources used must be handled optimally to obtained better
result within those but in build and fix method it is quite difficult to control due to the
single control.
Handling Complexity through Abstraction and Decomposition
The concept of software engineering uses different techniques to handle the complexity
such as abstraction and decomposition.

Abstraction:
● Simplify a problem by omitting unnecessary details.
– Focus attention on only one aspect of the problem and ignore irrelevant details.
● Suppose you are asked to develop an overall understanding of some country.
– No one in his right mind would meet all the citizens of the country, visit every
house, and examine every tree of the country, etc.
– You would possibly refer to various types of maps for that country.
A map, in fact, is an abstract representation of a country

Decomposition:

Decompose a problem into many small independent parts. The small parts are then taken up one
by one and solved separately. The idea is that each small part would be easy to grasp and can be
easily solved. The full problem is solved when all the parts are solved

Why to study SE

Ability to solve complex programming problems:

– How to break large projects into smaller and manageable parts?
– How to use abstraction?
● Also learn techniques of: Specification, design, user interface development, testing,
project management, etc

3
 Software Engineering (PCS31104)

Notable changes in software development practices

• The exploratory software development style is based on error correction while se techniques is based
on error prevention.
• The exploratory software development style coding is considered to be synonymous with software
development while se techniques coding is considered as a small part of software development
process.
• A lot of attention is now paid to requirement specification, which is not there is previous model.
• Now there is a distinct design phase where standard design techniques are employed.
• Periodic reviews are carried out during all stages of the development process to detect and correct error
as soon as possible.
• Software testing is carried out in systematic way.

Software Development Life Cycle Model (SDLC)

A software life cycle model (also called process model) is a descriptive and diagrammatic
representation of the software life cycle. A life cycle model represents all the activities required to make a
software product transit through its life cycle phases. It also captures the order in which these activities
are to be undertaken. In other words, a life cycle model maps the different activities performed on a
software product from its inception to retirement. Different life cycle models may map the basic
development activities to phases in different ways. Thus, no matter which life cycle model is followed,
the basic activities are included in all life cycle models though the activities may be carried out in
different orders in different life cycle models. During any life cycle phase, more than one activity may
also be carried out.
Need of SDLC

The development team must identify a suitable life cycle model for the particular project and then
adhere to it. Without using of a particular life cycle model the development of a software product would
not be in a systematic and disciplined manner. When a software product is being developed by a team
there must be a clear understanding among team members about when and what to do. Otherwise it would
lead to chaos and project failure.
A software life cycle model defines entry and exit criteria for every phase. A phase can start only
if its phase-entry criteria have been satisfied. So without software life cycle model the entry and exit
criteria for a phase cannot be recognized. Without software life cycle models (such as classical waterfall
model, iterative waterfall model, prototyping model, evolutionary model, spiral model etc.) it becomes
difficult for software project managers to monitor the progress of the project.

DIFFERENT SOFTWARE DEVELOPMENT LIFE CYCLE MODEL

1. CLASSICAL WATER FALL MODEL

The classical waterfall model is intuitively the most obvious way to develop software. Though the
classical waterfall model is elegant and intuitively obvious, it is not a practical model in the sense that it
cannot be used in actual software development projects. Thus, this model can be considered to be a
theoretical way of developing software. But all other life cycle models are essentially derived from the

4
 Software Engineering (PCS31104)

classical waterfall model. So, in order to be able to appreciate other life cycle models it is necessary to
learn the classical waterfall model.
Classical waterfall model divides the life cycle into the following phases as shown in the following figure

Feasibility Study

The main aim of feasibility study is to determine whether it would be financially and technically
feasible to develop the product. The feasibility study activity involves analysis of the problem and
collection of all relevant information relating to the product such as input data, processing required to
carry out on the input, output of the system.

Requirement Analysis and Specification

The aim of the requirements analysis and specification phase is to understand the exact
requirements of the customer and to document them properly. This phase consists of two distinct
activities, namely
• Requirements gathering and analysis
• Requirements specification
The goal of the requirements gathering activity is to collect all relevant information from the
customer regarding the product to be developed. This is done to clearly understand the customer
requirements so that incompleteness and inconsistencies are removed.
The requirements analysis activity is begun by collecting all relevant data regarding the product
to be developed from the users of the product and from the customer through interviews and discussions.
The data collected from a group of users usually contain several contradictions and ambiguities, since
each user typically has only a partial and incomplete view of the system. Therefore it is necessary to
identify all ambiguities and contradictions in the requirements and resolve them through further

5
 Software Engineering (PCS31104)

discussions with the customer. After all ambiguities, inconsistencies, and incompleteness have been
resolved and all the requirements properly understood, the requirements specification activity can start.
During this activity, the user requirements are systematically organized into a Software Requirements
Specification (SRS) document.

Design

The goal of the design phase is to transform the requirements specified in the SRS document into a
structure that is suitable for implementation in some programming language. In technical terms, during
the design phase the software architecture is derived from the SRS document. Two distinctly different
approaches are available: the traditional design approach and the object-oriented design approach.
• Traditional design approach
Traditional design consists of two different activities; first a structured analysis of the requirements
specification is carried out where the detailed structure of the problem is examined. This is followed by a
structured design activity. During structured design, the results of structured analysis are transformed into
the software design.
• Object-oriented design approach
In this technique, various objects that occur in the problem domain and the solution domain are first
identified, and the different relationships that exist among these objects are identified. The object
structure is further refined to obtain the detailed design.

Coding and Unit Testing

The purpose of the coding and unit testing phase (sometimes called the implementation phase) of
software development is to translate the software design into source code. Each component of the design
is implemented as a program module. The end-product of this phase is a set of program modules that have
been individually tested.
During this phase, each module is unit tested to determine the correct working of all the
individual modules. It involves testing each module in isolation as this is the most efficient way to debug
the errors identified at this stage.

Integration and System Testing

Integration of different modules is undertaken once they have been coded and unit tested. During
the integration and system testing phase, the modules are integrated in a planned manner. The different
modules making up a software product are almost never integrated in one shot. Integration is normally
carried out incrementally over a number of steps. During each integration step, the partially integrated
system is tested and a set of previously planned modules are added to it. Finally, when all the modules
have been successfully integrated and tested, system testing is carried out. The goal of system testing is to
ensure that the developed system conforms to its requirements laid out in the SRS document. System
testing usually consists of three different kinds of testing activities:

• α – testing: it is the system testing performed by the development team.

• β – Testing: it is the system testing performed by a friendly set of customers.
• Acceptance testing: it is the system testing performed by the customer himself after the
product delivery to determine whether to accept or reject the delivered product.
System testing is normally carried out in a planned manner according to the system test plan
document. The system test plan identifies all testing-related activities that must be performed,

6
 Software Engineering (PCS31104)

specifies the schedule of testing, and allocates resources. It also lists all the test cases and the
expected outputs for each test case.

Maintenance

Maintenance of a typical software product requires much more than the effort necessary to
develop the product itself. Many studies carried out in the past confirm this and indicate that the relative
effort of development of a typical software product to its maintenance effort is roughly in the 40:60 ratios.
Maintenance involves performing any one or more of the following three kinds of activities:
• Correcting errors that were not discovered during the product development phase. This is
called corrective maintenance.
• Improving the implementation of the system, and enhancing the functionalities of the
system according to the customer’s requirements. This is called perfective maintenance.
• Porting the software to work in a new environment. For example, porting may be
required to get the software to work on a new computer platform or with a new operating
system. This is called adaptive maintenance.
Advantages of Waterfall Model

1. Clear project objective

2. Stable project requirement
3. Progress of system is measureable
4. Strict sign-off requirement

Disadvantages of Waterfall Model

1. Time consuming
2. Never backward
3. Little room for iteration
4. Difficulty responding to changes

ITERATIVE WATERFALL MODEL

In the waterfall model it is found out that, it is not possible to strictly follow the steps of classical
water fall model. In case of interative water fall model we made necessary changes to clasical waterfall
model so that it is applicable to practical software developments projects. The main change to the clasical
water fall model is that in this model provide feed back path from every model to its proceeding model.
This feedback path provide the error correction in the same phase and if there is error in the next phase
due to previous phase than it is also handled by this feedback system.
Phase containment of errors
In waterfall model, we donot check whether the phases has any error or not, we finally check the
system and if any error found there than we have to trace back all the phases to find out in which phase
there is error. But in iterative waterfall model afetr complitation of the phase , the feed back is send and
the verification of the phase is done . if the phase contains any error that it is found there only and also
corrected. The phase containment of error gives the information that the particular phase has the error
and to clear this error, we only have to check that phase

7
 Software Engineering (PCS31104)

Iterative Water Fall Model

PROTOTYPE MODEL

This model is requires a working prototype of the system before carrying out the
development of the software. There are several advantages of building prototype before the
actual product is developed. The prototype model can illustrate the input data format, messages,
reports and interactive dialogues to the customer which can act as a valuable mechanism for
gaining better understanding of the customer needs. This method is preferred where the exact
technical solutions to be adopted are unclear to the development team. A developed prototype
would help to critically examine the technical issues associated with the product development.

The first phase of prototype model is prototype development and the second phase is
iterative development.

The prototype development is used to control risk. This model is first start with
requirement gathering, in this stage the requirement given by the customer is analyzed and more
etailed of the requirement is collected. In the next stage is quick design of the system is done
based on the requirement given by the customer. While doing the design there are some rules
taken into consideration and some exception also taken, these are the prototypes of the design.
So, in the third stage i.e. build prototype stage the prototypes is build and in the next stage the
prototype is send to the customer for evaluation and acceptance. If the customer accepts the
prototype then the next level of SDLC is according to the iterative waterfall model. If the
customer does not accept the prototype, he gives a refinement of the prototype. Then the
prototype is again build with the refinement given by the customer. This circle continues until
the customer approves the prototype.

8
 Software Engineering (PCS31104)

Prototyping model of software development

Advantages of prototype model

1. Strong Dialogue between users and developers

2. Missing functionality can be identified easily
3. Confusing or difficult functions can be identified
4. May generate specifications for a production application
5. Encourages innovation and flexible designs

Disadvantages of prototype model

1. Contract may be awarded without rigorous evaluation of Prototype

2. Requirements may frequently change significantly
3. Incomplete or inadequate problem analysis
4. Incomplete or inadequate problem analysis
5. Client may be unknowledgeable

EVOLUTIONARY MODEL

This lifecycle is also known as successive version model or sometimes called as incremental
model. In this model, first a simple working system is built which subsequently undergoes many
functional improvements until the desired system is realized. This model is also referred as
design a little, build a little, test a little and finally deploy a little. The following flowchart
describe the steps used in the evolutionary model.

9
 Software Engineering (PCS31104)

Evolutionary model of software development

In the first stage of evolutionary model, a rough requirement of the total system is first
made. Then depending upon the requirement the core module of the system is done and the other
parts of the system that is to be developed later is first decided. Then the core part of the system
is developed using the iterative waterfall model. Then the core module i.e. developed is send to
the customer for feedback.

If the customer feedback is positive then the next identified feature of the system is
carried out using iterative waterfall model. Again after that module is send back to the customer
for feedback, this procedure continues until the total system is completed. Then the system is
send for the maintenance.

If the customer feedback is negative than then the core part of the module is again
developed and send for the feedback until the feedback is positive.

This model is normally useful for very large product, where it is easier to find modules
for incremental implementation. This model is a very natural model to use in object-oriented
software development project.

Advantage of Evolutionary model

o The model can be used when the requirements cannot or will not be specified.
o The user can experiment with the system to improve the requirements.
Disadvantage of evolutionary model

10
 Software Engineering (PCS31104)

o Use of the method is exploratory in nature and therefore constitutes a high-risk endeavor.
Strong management is required.
o This method is used as an excuse for hacking to avoid documenting the requirements or
design, even if they are well understood.
SPIRAL MODEL

The spiral model is a software development process combining elements of both design
and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up
concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems
development method (SDM) used in information technology (IT). This model of development
combines the features of the prototyping model and the waterfall model. The spiral model is
intended for large, expensive and complicated projects.

Spiral model of software development

The diagrammatic representation of this model appears like a spiral with many loops. The exact
number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software
process. For example, the innermost loop might be concerned with feasibility study. The next loop with
requirements specification, the next one with design, and so on. Each phase in this model is split into four
sectors (or quadrants). The following activities are carried out during each phase of a spiral model.
First quadrant (Objective Setting)
• During the first quadrant, features of the products are identified based on severity of the
risk and how crucial are those to overall product development.
• Implementation of the identified features consists of the objective of the phase.
• Based on these, the risks involved in the phase objectives are identified and also alternate
solutions for the phase under construction are discussed.

11
 Software Engineering (PCS31104)

Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk and also the best possible
solution is find out among the alternate scenarios.
• Steps are taken to reduce the risks. For example, if there is a risk that the requirements
are inappropriate, a prototype system may be developed.
Third Quadrant (Development and Validation)
• Develop and validate the next level of the product after resolving the identified risks.
Fourth Quadrant (Review and Planning)
• Review the results achieved so far with the customer and plan the next iteration around
the spiral.
• Progressively more complete version of the software gets built with each iteration around
the spiral.
Advantages
• Avoidance of Risk is enhanced.
• Strong approval and documentation control.
• Implementation has priority over functionality.
• Additional Functionality can be added at a later date.
Disadvantages

• Highly customized limiting re-usability

• Applied differently for each application
• Risk of not meeting budget or schedule
• Possibility to end up implemented as the Waterfall framework

Comparison Of Different Life-Cycle Models

• The classical waterfall model can be considered as the basic model and all other life cycle
models as embellishments of this model. However, the classical waterfall model can not
be used in practical development projects, since this model supports no mechanism to
handle the errors committed during any of the phases.
• This problem is overcome in the iterative waterfall model. The iterative waterfall model
is probably the most widely used software development model evolved so far. This model
is simple to understand and use. However, this model is suitable only for well-understood
problems; it is not suitable for very large projects and for projects that are subject to
many risks.
• The prototyping model is suitable for projects for which either the user requirements or
the underlying technical aspects are not well understood. This model is especially popular
for development of the user-interface part of the projects.

12
 Software Engineering (PCS31104)

• The evolutionary approach is suitable for large problems which can be decomposed into a
set of modules for incremental development and delivery. This model is also widely used
for object-oriented development projects. Of course, this model can only be used if the
incremental delivery of the system is acceptable to the customer.
• The spiral model is called a meta model since it encompasses all other life cycle models.
Risk handling is inherently built into this model. The spiral model is suitable for
development of technically challenging software products that are prone to several kinds
of risks. However, this model is much more complex than the other models – this is
probably a factor deterring its use in ordinary projects.

What is RAD?
Rapid application development is a software development methodology that uses minimal
planning in favor of rapid prototyping. A prototype is a working model that is functionally
equivalent to a component of the product.
In RAD model the functional modules are developed in parallel as prototypes and are integrated
to make the complete product for faster product delivery.
Since there is no detailed preplanning, it makes it easier to incorporate the changes within the
development process. RAD projects follow iterative and incremental model and have small
teams comprising of developers, domain experts, customer representatives and other IT
resources working progressively on their component or prototype. The most important aspect for
this model to be successful is to make sure that the prototypes developed are reusable.
RAD Model Design
RAD model distributes the analysis, design, build, and test phases into a series of short, iterative
development cycles. Following are the phases of RAD Model:
• Business Modeling:
The business model for the product under development is designed in terms of flow of
information and the distribution of information between various business channels. A
complete business analysis is performed to find the vital information for business, how it
can be obtained, how and when is the information processed and what are the factors
driving successful flow of information.
• Data Modeling:
The information gathered in the Business Modeling phase is reviewed and analyzed to
form sets of data objects vital for the business. The attributes of all data sets is identified
and defined. The relation between these data objects are established and defined in detail
in relevance to the business model.
• Process Modeling:
The data object sets defined in the Data Modeling phase are converted to establish the
business information flow needed to achieve specific business objectives as per the
business model. The process model for any changes or enhancements to the data object
sets is defined in this phase. Process descriptions for adding , deleting, retrieving or
modifying a data object are given.

13
 Software Engineering (PCS31104)

• Application Generation:
The actual system is built and coding is done by using automation tools to convert
process and data models into actual prototypes.
• Testing and Turnover:
The overall testing time is reduced in RAD model as the prototypes are independently
tested during every iteration. However the data flow and the interfaces between all the
components need to be thoroughly tested with complete test coverage. Since most of the
programming components have already been tested, it reduces the risk of any major
issues.
RAD Model Vs Traditional SDLC
• The traditional SDLC follows a rigid process models with high emphasis on requirement
analysis and gathering before the coding starts. It puts a pressure on the customer to sign
off the requirements before the project starts and the customer does not get the feel of the
product as there is no working build available for a long time.
• The customer may need some changes after he actually gets to see the software, however
the change process is quite rigid and it may not be feasible to incorporate major changes
in the product in traditional SDLC.
• RAD model focuses on iterative and incremental delivery of working models to the
customer. This results in rapid delivery to the customer and customer involvement during
the complete development cycle of product reducing the risk of non conformance with
the actual user requirements.
RAD Model Application
• RAD model can be applied successfully to the projects in which clear modularization is
possible. If the project cannot be broken into modules, RAD may fail. Following are the
typical scenarios where RAD can be used:
• RAD should be used only when a system can be modularized to be delivered in
incremental manner.
• It should be used if there is high availability of designers for modeling.
• It should be used only if the budget permits use of automated code generating tools.
• RAD SDLC model should be chosen only if domain experts are available with relevant
business knowledge.
• Should be used where the requirements change during the course of the project and
working
• Prototypes are to be presented to customer in small iterations of 2-3 months.
Advantage
• Changing requirements can be accommodated.
• Progress can be measured.

14
 Software Engineering (PCS31104)

• Iteration time can be short with use of powerful RAD tools.

• Productivity with fewer people in short time.
• Reduced development time.
• Increases reusability of components
• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of integration issues.
Disadvantages
• Dependency on technically strong team members for identifying business requirements.
• Only system that can be modularized can be built using RAD.
• Requires highly skilled developers/designers.
• High dependency on modeling skills.
• Inapplicable to cheaper projects as cost of modeling and automated code generation is
very high.
• Management complexity is more.
• Suitable for systems that are component based and scalable.
• Requires user involvement throughout the life cycle.
Two agile software development methodologies

The most widely used methodologies based on the agile philosophy are XP and Scrum. These
differ in particulars but share the iterative approach described above.

XP

XP stands for extreme programming. It concentrates on the development rather than managerial
aspects of software projects. XP was designed so that organizations would be free to adopt all or
part of the methodology.

XP development

XP projects start with a release planning phase, followed by several iterations, each of which
concludes with user acceptance testing. When the product has enough features to satisfy users,
the team terminates iteration and releases the software.

Users write “user stories” to describe the need the software should fulfill. User stories help the
team to estimate the time and resources necessary to build the release and to define user
acceptance tests. A user or a representative is part of the XP team, so he or she can add detail to
requirements as the software is being built. This allows requirements to evolve as both users and
developers define what the product will look like.

15
 Software Engineering (PCS31104)

To create a release plan, the team breaks up the development tasks into iterations. The release
plan defines each iteration plan, which drives the development for that iteration. At the end of an
iteration, users perform acceptance tests against the user stories. If they find bugs, fixing the bugs
becomes a step in the next iteration.

Iterative user acceptance testing, in theory, can result in release of the software. If users decide
that enough user stories have been delivered, the team can choose to terminate the project before
all of the originally planned user stories have been implemented.

A simplified XP process

Figure 5 shows a simplified version of XP. Full XP includes many steps in release planning,
iteration, and acceptance testing that are not shown here.

XP rules and concepts

Here are the most important concepts:

• Integrate often. Development teams must integrate changes into the development
baseline at least once a day. This concept is also called continuous integration.

• Project velocity. Velocity is a measure of how much work is getting done on the project.
This important metric drives release planning and schedule updates.

• Pair programming. All code for a production release is created by two people working
together at a single computer. XP proposes that two coders working together will satisfy
user stories at the same rate as two coders working alone, but with much higher quality.

• User story. A user story describes problems to be solved by the system being built.
These stories must be written by the user and should be about three sentences long. User
stories do not describe a solution, use technical language, or contain traditional
requirements-speak, such as “shall” statements. Instead, a sample user story might go like

16
 Software Engineering (PCS31104)

this: Search for customers. The user tells the application to search for customers. The
application asks the user to specify which customers. After the user specifies the search
criteria, the application returns a list of customers meeting those criteria.

Because user stories are short and somewhat vague, XP will only work if the customer
representative is on hand to review and approve user story implementations. This is one of the
main objections to the XP methodology, but also one of its greatest strengths.

Scrum

In rugby, ‘scrum’ (related to “scrimmage”) is the term for a huddled mass of players engaged
with each other to get a job done. In software development, the job is to put out a release. Scrum
for software development came out of the rapid prototyping community because proto typers
wanted a methodology that would support an environment in which the requirements were not
only incomplete at the start, but also could change rapidly during development. Unlike XP,
Scrum methodology includes both managerial and development processes.

Scrum management

At the center of each Scrum project is a backlog of work to be done. This backlog is populated
during the planning phase of a release and defines the scope of the release (see Figure 6).

After the team completes the project scope and high-level designs, it divides the development
process into a series of short iterations called sprints. Each sprint aims to implement a fixed
number of backlog items (see Figure 6). Before each sprint, the team members identify the
backlog items for the sprint. At the end of a sprint, the team reviews the sprint to articulate
lessons learned and check progress.

During a sprint, the team has a daily meeting called a scrum. Each team member describes the
work to be done that day, progress from the day before, and any blocks that must be cleared. To
keep the meetings short, the scrum is supposed to be conducted with everyone in the same
room—standing up for the whole meeting.

When enough of the backlog has been implemented so that the end users believe the release is
worth putting into production, management closes development. The team then performs
integration testing, training, and documentation as necessary for product release.

Scrum development

The Scrum development process concentrates on managing sprints. Before each sprint begins,
the team plans the sprint, identifying the backlog items and assigning teams to these items.
Teams develop, wrap, review, and adjust each of the backlog items (See Figure 6).

During development, the team determines the changes necessary to implement a backlog item.
The team then writes the code, tests it, and documents the changes. During wrap, the team
creates the executable necessary to demonstrate the changes. In review, the team demonstrates

17
 Software Engineering (PCS31104)

the new features, adds new backlog items, and assesses risk. Finally, the team consolidates data
from the review to update the changes as necessary.

Following each sprint, the entire team including management, users, and other interested parties
demonstrates progress from the sprint and reviews the backlog progress. The team then reviews
the remaining backlog and adds, removes, or reprioritizes items as necessary to account for new
information and understanding gathered during the sprint.

Figure 6: The Scrum process

Scrum concepts
Here are a few of the most important concepts:

• Burn down chart. This chart, updated every day, shows the work remaining within the
sprint. The burn down chart is used both to track sprint progress and to decide when
items must be removed from the sprint backlog and deferred to the next sprint.

• Product backlog. Product backlog is the complete list of requirements—including bugs,

enhancement requests, and usability and performance improvements—that are not
currently in the product release.

• Scrum Master. The Scrum Master is the person responsible for managing the Scrum
project. Sometimes it refers to a person who has become certified as a Scrum Master by
taking Scrum Master training.

• Sprint backlog. Sprint backlog is the list of backlog items assigned to a sprint, but not
yet completed. In common practice, no sprint backlog item should take more than two
days to complete. The sprint backlog helps the team predict the level of effort required to
complete a sprint.

18
 Software Engineering (PCS31104)

Requirement Gathering and Analysis

The main activities that are carried out during requirement analysis and specification phrase are
of two types

• Requirement gathering and analysis

• Requirement specification

Requirement gathering and analysis

• The requirement is never available in the form of a single document from customer.
Therefore, it has to be gathered by the analyst from several sources.
• The requirement gathering and analysis activity is consists of two steps

1. Requirement gathering
• It is also called as requirement elicitation
• It starts with studying the existing documents to collect all possible information
about the system to be developed.
• The important ways the analyst collect the requirements are as follows:
i. Studying existing document: The analyst usually goes through all existing documents
about the project to be developed before visiting the customer for the details of the
project.
ii. Interview: Typically there are many different types of users of software. Different types
of users require different features of the software.

For example: in library system, one category of user, i.e., library member concern about
search, issue and return book. Another category of user concern about determining the
overdue, create and delete member account.

In order to systematize the method of requirement gathering, a Delphi technique is used.

In Delphi technology, analyst consolidates the requirements as understood by him and
then circulate it for the comments of users. Based on their feedback, he refines the
document. The process is continued until all users agree on the set of requirements.

iii. Task Analysis: The user usually views software as a black box that provides a set of
services. For each identified task, the analysis tries to formulate the different steps
necessary to realize the service n consult with the user.
iv. Scenario Analysis: A task has multiple scenarios. The scenarios of the task come in to
picture, when the task is invoked under different situations. Thus, the analyst finds out all
possible scenarios and finally, collects information about the way the problem can be
solved.

19
 Software Engineering (PCS31104)

v. Form analysis: In this type, the analyst designs different forms to collect the inform
about the requirements of users. The users fill the document and that information is
collected by the analyst and considered as the requirements.

Requirement analysis

Few basic questions related to the project should by clearly understood by the analyst to obtain
detailed information about the questions. The questions are as follows:

• What is the problem?

• Is it important to solve the problem?
• What exactly the data input and data output of the system?
• What are the possible procedures to solve the problem?
• What are the likely complexities that may be arise while solving the problem?
• If there is any external software or hardware needed for software development then how
the software will interface and what exactly the data interchange format.

Along with this, there are mainly three different types of problems in the requirements, which
must be identified by the analyst and must be resolve. Those are as follows:

• Ambiguity: When a requirement is anomalous, several interpretation of the requirement

is possible which may lead to any erroneous development of the software. For example:
the temperature is high and he is a good boy. The word high and good boy is most of the
time ambiguous.
• Inconsistency: The requirements are said to be inconsistent, if one of the requirements
contradict to other. For example: a clerk says that a student with F grade in three or more
subjects may have to repeat the whole semester while other say that there is no such
issue. This is called inconsistent.
• Incompleteness: An incomplete set of requirement is one, in which some requirements
have been overlooked. These requirements are later find out by the customer much later
after publish of the software. His is due to the inability of the customer to visualize the
system. An experience analyst can detect most of the features and send it to the customer
for consideration before the software development process start.

Functional and nonfunctional requirement

Software requirement specification (SRS) document usually contains information about all the
users in informal form. This is the outcome of the requirement analysis and specification phase.
The SRS document clearly specifies the following three aspects of a system.

• Functional requirements: In order to know about the function requirements, it is

important to know the high level functions clearly. Then the higher level functions are
divided into smaller sub-requirements. The functional requirements are often identified
either from an informal problem document or from a conceptual understanding of the

20
 Software Engineering (PCS31104)

problem. If the informal problem document is analyzed properly and the verbs present in
it are always a candidate for the function requirements for the software.

How to document the functional requirements?

The following example discusses about the cash withdraw from ATM. The functional
requirement document for that is as follows:

R.1: Withdraw Cash from ATM

Description: The withdraw cash function first checks the validity of the card inserted into
the ATM machine. After the card validation, the next phase is pin check. After the correct
pin entry, next select operation of withdraw from a specific type of account. Then finally
enter the amount to withdraw.
R.1.1: Card Validation
Input: A valid ATM card is enter to machine
Output: System validates the card and asks for the pin to enter
R.1.1.2: Pin Validation
Input: The correct pin for the ATM is entered
Output: System validates the pin and asks for the next option.
R.1.1.3: Select withdraw option
Input: withdraw amount option is chosen.
Output: System asks for the type of account.
R.1.1.4: Select account type
Input: User has to choose any one of the option: saving/ current/ deposit
Output: System asks for the amount to be withdraw
R.1.1.3: withdraw required amount
Input: The user withdraws an amount greater than 100 and multiple of 100.
Output: The requested amount is withdrawn and transaction statement is generated.

• Non-functional requirements: The non-functional requirements deal with the

characteristics of the system that cannot be expressed as function. This is deals with
maintainability, portability, usability, reliability and constraints on system
implementation etc. The IEEE 870 standard lists four broad categories of non function
requirements, i.e., external interface requirement, performance requirement, constrain and
software system attributes. The external interfaces are hardware, software and
communication interface, user interface, and report formats etc.

Unlike the functional model, there is only one non-functional requirement section for
software.

21
 Software Engineering (PCS31104)

Software requirement Specification (SRS)

After analyst gather all requirements, remove all issues like incompleteness, inconsistence and
anomalies, they start the systematic organization of the document in the form of SRS.

The important categories of users and their needs are as follows:

• User, customer and marketing personnel: The users are the end users, who are going
to use the software, so, they must know about the SRS is details. Customers are those
persons for whom the developer develops the software. Thus, they should have
knowledge about the product. Finally, the marketing personnel must know the features of
the software in details which help them to sell the product in the market.
• Software Developer: These people are going to develop the software and thus, they must
know all the details of SRS.
• Test Engineers: These people test the software whether they meet all the requirements of
the customer
• User document writer: These people must know all the details of SRS as they have to
generate the final user manual which is finally used by all end users.
• Project manager: He is the head of all the team. Thus, with all the information, he can
estimate the cost of the project easily.
• Maintenance engineer: These people maintain the software to be in the updated form
always and thus, they should know all the details of SRS.

IEEE guidelines for SRS

In general the definitions of terms used in this recommended practice conform to the definitions
provided in IEEE Std . The definitions below are key terms as they are used in this recommended
practice.

• Contract: A legally binding document agreed upon by the customer and supplier. This
includes the technical and organizational requirements, cost, and schedule for a product.
A contract may also contain informal but useful information such as the commitments or
expectations of the parties involved.
• Customer: The person, or persons, who pay for the product and usually (but not
necessarily) decide the requirements. In the context of this recommended practice the
customer and the supplier may be members of the same organization.
• Supplier: The person, or persons, who produce a product for a customer. In the context
of this recommended practice, the customer and the supplier may be members of the
same organization.
• User: The person, or persons, who operate or interact directly with the product. The
user(s) and the customer(s) are often not the same person(s).

22
 Software Engineering (PCS31104)

Considerations for producing a good SRS

This clause provides background information that should be considered when writing an SRS.
This includes the following:

a) Nature of the SRS;

b) Environment of the SRS;
c) Characteristics of a good SRS;
d) Joint preparation of the SRS;
e) SRS evolution;
f) Prototyping;
g) Embedding design in the SRS;
h) Embedding project requirements in the SRS.

a. Nature of the SRS

The SRS is a specification for a particular software product, program, or set of programs that
performs certain functions in a specific environment. The SRS may be written by one or more
representatives of the supplier, one or more representatives of the customer, or by both.

The basic issues that the SRS writer(s) shall address are the following:
• Functionality: What is the software supposed to do?
• External interfaces: How does the software interact with people, the system’s hardware,
other hardware, and other software?
• Performance: What is the speed, availability, response time, recovery time of various
software functions, etc.?
• Attributes: What are the portability, correctness, maintainability, security, etc.
considerations?
• 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.?

b. Environment of SRS

Since the SRS has a specific role to play in the software development process, the SRS writer(s)
should be careful not to go beyond the bounds of that role. This means the SRS

23
 Software Engineering (PCS31104)

a) Should correctly define all of the software 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.
b) Should not describe any design or implementation details. These should be described in
the design stage of the project.
c) Should not impose additional constraints on the software. These are properly specified in
other documents such as a software quality assurance plan.

Therefore, a properly written SRS limits the range of valid designs, but does not specify any
particular design.

c. Characteristics of a good SRS

An SRS should be

a) Correct;
b) Unambiguous;
c) Complete;
d) Consistent;
e) Ranked for importance and/or stability;
f) Verifiable;
g) Modifiable;
h) Traceable.

a. Correct : An 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 ensures correctness. The SRS
should be compared with any applicable superior specification, such as a system
requirements specification, with other project documentation, and with other applicable
standards, to ensure that it agrees. Alternatively the customer or user can determine if the
SRS correctly reflects the actual needs.
b. Unambiguous: An SRS is unambiguous if, and only if, every requirement stated therein
has only one interpretation. As a minimum, this requires that each characteristic of the
final product be described using a single unique term. 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.
• Natural language pitfalls: Requirements are often written in natural language (e.g.,
English). Natural language is inherently ambiguous. A natural language SRS should
be reviewed by an independent party to identify ambiguous use of language so that it
can be corrected.
• Requirements specification languages: One way to avoid the ambiguity inherent in
natural language is to write the SRS in a particular requirements specification
language. Its language processors automatically detect many lexical, syntactic, and
semantic errors.

24
 Software Engineering (PCS31104)

c. Completeness: An SRS is complete if, and only if, it includes the following elements:
• All significant requirements, whether relating to functionality, performance,
design constraints, attributes, or external interfaces. In particular any external
requirements imposed by a system specification should be acknowledged and treated.
• Definition of the responses of the software to all realizable classes of input data in
all realizable classes of situations. Note that it is important to specify the responses to
both valid and invalid input values.
• Full labels and references to all figures, tables, and diagrams in the SRS and
definition of all terms and units of measure.

d. Consistency: Consistency refers to internal consistency. If an SRS does not agree with
some higher-level document, such as a system requirements specification, then it is not
correct.
• Internal Consistency: An SRS is internally consistent if, and only if, no subset of
individual requirements described in it conflict. The three types of likely conflicts in an
SRS are as follows:
a) The specified characteristics of real-world objects may conflict. For example,
1) The format of an output report may be described in one requirement as tabular
but in another as textual.
2) One requirement may state that all lights shall be green while another may state
that all lights shall be blue.
b) There may be logical or temporal conflict between two specified actions. For example,
1) One requirement may specify that the program will add two inputs and another
may specify that the program will multiply them.
2) One requirement may state that “A” must always follow “B” while another
may require that “ A and B” occur simultaneously.
c) Two or more requirements may describe the same real-world object but use different
terms for that object. For example, a program’s request for a user input may be called a
“prompt” in one requirement and a “cue” in another. The use of standard terminology and
definitions promotes consistency.

e. Ranked for importance and/or stability

An SRS is ranked for importance and/or stability if each requirement in it has an identifier to
indicate either the importance or stability of that particular requirement. Typically, all of the
requirements that relate to a software product are not equally important. Some requirements
may be essential, especially for life-critical applications, while others may be desirable.

• Degree of stability : One method of identifying requirements uses the dimension of

stability. Stability can be expressed in terms of the number of expected changes to any

25
 Software Engineering (PCS31104)

requirement based on experience or knowledge of forthcoming events that affect the

organization, functions, and people supported by the software system.

• Degree of necessity : Another way to rank requirements is to distinguish classes of

requirements as essential, conditional, and optional.
1. Essential: Implies that the software will not be acceptable unless these requirements
are provided in an agreed manner.
2. Conditional: Implies that these are requirements that would enhance the software
product, but would not make it unacceptable if they are absent.
3. Optional: Implies a class of functions that may or may not be worthwhile. This gives
the supplier the opportunity to propose something that exceeds the SRS.

f. Verifiable: An SRS is verifiable if, and only if, every requirement stated therein is
verifiable. A requirement is verifiable if, and only if, there exists some finite cost-
effective process with which a person or machine can check that the software product
meets the requirement. In general any ambiguous requirement is not verifiable

g. Modifiable: An SRS is modifiable if, and only if, its structure and style are such that any
changes to the requirements can be made easily, completely, and consistently while
retaining the structure and style. Modifiability generally requires an SRS to
• Have a coherent and easy-to-use organization with a table of contents, an index, and
explicit cross referencing;
• Not be redundant (i.e., the same requirement should not appear in more than one
place in the SRS);
• Express each requirement separately, rather than intermixed with other requirements.

h. Traceable: An SRS is traceable if the origin of each of its requirements is clear and if it
facilitates the referencing of each requirement in future development or enhancement
documentation. The following two types of traceability are recommended:
• Backward traceability (i.e., to previous stages of development): This depends
upon each requirement explicitly referencing its source in earlier documents.
• Forward traceability (i.e., to all documents spawned by the SRS): This depends
upon each requirement in the SRS having a unique name or reference number.

C. Joint preparation of SRS

The software development process should begin with supplier and customer agreement on what
the completed software must do. This agreement, in the form of an SRS, should be jointly
prepared. This is important because usually neither the customer nor the supplier is qualified to
write a good SRS alone.
a) Customers usually do not understand the software design and development process
well enough to write a usable SRS.

26
 Software Engineering (PCS31104)

b) Suppliers usually do not understand the customer’s problem and field of endeavor well
enough to specify requirements for a satisfactory system.

Therefore, the customer and the supplier should work together to produce a well-written and
completely understood SRS.

D. SRS evolution

The SRS may need to evolve as the development of the software product progresses. It may be
impossible to specify some details at the time the project is initiated (e.g., it may be impossible to
define all of the screen formats for an interactive program during the requirements phase).
Additional changes may ensue as deficiencies, shortcomings, and inaccuracies are discovered in
the SRS. Two major considerations in this process are the following:

a) Requirements should be specified as completely and thoroughly as is known at the

time, even if evolutionary revisions can be foreseen as inevitable. The fact that they are
incomplete should be noted.
b) A formal change process should be initiated to identify, control, track, and report
projected changes. Approved changes in requirements should be incorporated in the SRS
in such a way as to
1) Provide an accurate and complete audit trail of changes;
2) Permit the review of current and superseded portions of the SRS.
E. Prototyping

Prototyping is used frequently during the requirements portion of a project. Many tools exist that
allow a prototype, exhibiting some characteristics of a system, to be created very quickly and
easily. Prototypes are useful for the following reasons:
a) The customer may be more likely to view the prototype and react to it than to read the SRS
and react to it. Thus, the prototype provides quick feedback.
b) The prototype displays unanticipated aspects of the systems behavior. Thus, it produces not
only answers but also new questions. This helps reach closure on the SRS.
c) An SRS based on a prototype tends to undergo less change during development, thus
shortening development time.

F. Embedding design in SRS

A requirement specifies an externally visible function or attribute of a system. A design

describes a particular subcomponent of a system and/or its interfaces with other subcomponents.
The SRS writer(s) should clearly distinguish between identifying required design constraints and
projecting a specific design. The SRS should not normally specify design items such as the
following:

27
 Software Engineering (PCS31104)

a) Partitioning the software into modules;

b) Allocating functions to the modules;
c) Describing the flow of information or control between modules;
d) Choosing data structures.

G. Embedding project requirements in the SRS

The SRS should address the software product, not the process of producing the software product.
Project requirements represent an understanding between the customer and the supplier about
contractual matters pertaining to production of software and thus should not be included in the
SRS. These normally include items such as

a) Cost;
b) Delivery schedules;
c) Reporting procedures;
d) Software development methods;
e) Quality assurance;
f) Validation and verification criteria;
g) Acceptance procedures.

Project requirements are specified in other documents, typically in a software development plan,
a software quality assurance plan, or a statement of work.

Decision tables and decision trees

There are two main techniques to analyze and represent complex processing logic is decision
table and decision tree. Once the decision making logic is captured in the form of trees or tables,
the test cases to validate these logics are automatically obtained.

Decision tree
A decision tree gives a graphical view of the processing logic involved in decision making and
corresponding action taken. It specifies which variables are to be tested, and based on that what
actions are to be taken depending upon the outcome of decision making logic and the order in
which the decision making is performed.
The edges of the tree represent the conditions and the leaf nodes represent the actions to be
performed depending upon testing condition. The following is an example of decision tree

Decision tree for Library management system

28
 Software Engineering (PCS31104)

Decision table
A decision table shows the decision making logic and the corresponding actions taken in a
tabular or matrix form. The upper rows of the table specify the variables or conditions to be
evaluated and the lower rows specify the actions to be taken when the evaluation test is satisfied.
A column in the table is called a rule.

Conditions
Valid Selection No Yes Yes Yes
New member - Yes No No
Renewal - No Yes No
Cancellation - No No Yes
Actions
Display error message x
Ask member's details x
Build member record x
print bill x x
Ask membership details x x
update expiry date x
print check x
delete record x

Decision table for Library management system

Decision Tree Vs. Decision table
Even though both decision tree and decision table can be used to represent complex program
logic, but the comparison can be carried out on three consideration:
1. Readability: Decision trees are easier to read and understand but decision table
causes the analyst to look for every possible combinations.
2. Explicit representation of the order of decision-making: Decision tree is useful
when multilevel decision making is required while decision table is a only represent a
single decision to select the appropriate action for execution.
3. Representing very complex decision logic: When the problem is very complex, the
decision table is more preferred ion compared to decision tree.

29