1

Software Engineering
NMCA 512
Unit-1
Contents:

Software Engineering Concepts, Components, & Software Characteristics

Software Crisis, Software Engineering Processes
Comparison Conventional Engineering Processes, Software Quality Attributes
Software Development Life Cycle (SDLC): Waterfall Model
SDLC: Prototype Model, and Spiral Model
SDLC: Evolutionary Development Models
SDLC: Iterative Enhancement Models.
Comparison of all SDLC Models

Software Engineering concepts:

Software

Instructions (Computer Programs) that when executed provide desired function and
performance
Data structures that enable the programs to adequately manipulate information.
Documents that describe the operation and use of the programs
IEEE Definition of Software
Software is the collection of computer programs, procedure rules and associated
documentation and data.
Program vs. Software

Program A set of instructions written in a proper syntax to solve a specific problem .

Software It consists of programs, set of documentations and the procedures used to setup and
operate the software system

Prepared By Neelam Rawat

2
So,

Software = Programs + Documentation + Operating Procedures.

Program = Source Code + Object Code
Program is a subset of software.
Operating Procedure - consists of instructions to setup and use the software system and
instructions on how to react to system failure. Some sample list is given as

Note Documentation consists of different types of manuals.

What is oftware & Engineering

The Ne We ster s Di tio ary, 1981, reworded the definition, orienting it completely to
o puters: oft are is the progra s a d progra
i g support e essar to put a o puter
through its assig ed tasks, as disti guished fro the a tual a hi e.
Engineering New Intercollegiate We ster s Di tio ar , 9 9, defi es the ter e gi eeri g as
the appli atio of s ie e a d athe ati s
hi h the properties of atter a d the sour es
of energy in nature are made useful to man in structures, machines, products, systems and
pro esses. Thus, engineering denotes the application of scientific knowledge for practical
problem solving.
Software Engineering Definition

IEEE Comprehensive Definition: -- Software Engineering is the application of a systematic,

disciplined, quantifiable approach to the development, operation and maintenance of software,
i.e., the application of engineering to software.
Software Engineering deals with cost-effective solutions to practical problems by applying
scientific knowledge in building software arti-facts in the service of mankind
Software Engineering is the application of methods and scientific knowledge to create practical
cost-effective solutions for the design, construction, operation and maintenance of software

Software Characteristics:

Software does not wear out Like hardware

Software may be retired due to environmental changes , new requirements, new expectations

Prepared By Neelam Rawat

Software is not manufactured

Software is logical rather than physical.
Reusability of components.
Software is flexible.
Most software is custom built, rather than being assembled from existing components.

Software Crisis:

The situation, where catastrophic failures have occurred, is known as Software Crisis. The major
causes of software crisis are the problems associated with poor quality software such as
malfunctioning of software systems, inefficient development of software, and the most
important, dissatisfaction amongst the users of the software.
o the ter oft are E gi eeri g first i trodu ed at a o fere e i late 9 s to dis uss the
software crisis.
Software maintenance cost has been rising and has surpassed the development cost.
Software is almost always delivered late and exceeds the budgeted cost, indicating time and
cost overruns
It lacks transparency and is difficult to maintain
Software quality is often less than adequate
It often does not satisfy the customers
Productivity of software people has not kept pace with the demand of their services
Progress on software development is difficult to measure

Software Engineering Processes:

Software Process defines a framework for a set of Key Process Areas (KPAs) that must be
established for effective delivery of software engineering technology. This establishes the
context in which technical methods are applied, work products such as models, documents,
data, reports, forms, etc. are produced, milestones are established, quality is ensured, and
change is properly managed.
(Webster) A system of operations in producing something; a series of actions, changes, or
functions that achieve an end or a result
(IEEE) A sequence of steps performed for a given purpose

Prepared By Neelam Rawat

4
Software Engineering vs. Comparison Conventional Engineering Processes:

Software is intangible
oft are does t degrade ith ti e as hard are does. oft are failures are caused by design
and implementation error, not by degradation over time
In classical engineering disciplines, the engineer is equipped with tools and the mathematical
maturity to specify the properties of the product separately from those of design. The typical
software engineering relies much more on experience and judgment rather than mathematical
formula.

Process, Methods, and Tools

A process framework establishes the foundation for a complete software process by identifying a small
number of framework activities that are applicable to all software projects, regardless of size or
complexity. It also includes a set of umbrella activities that are applicable across the entire software
process. Some most applicable framework activities are described below.

Prepared By Neelam Rawat

5
Communication:
This activity involves heavy communication with customers and other stakeholders in order to gather
requirements and other related activities.
Planning:
Here a plan to be followed will be created which will describe the technical tasks to be conducted, risks,
required resources, work schedule etc.
Modeling:
A model will be created to better understand the requirements and design to achieve these
requirements.
Construction:
Here the code will be generated and tested.
Deployment:
Here, a complete or partially complete version of the software is represented to the customers to
evaluate and they give feedbacks based on the evaluation.
Software Process
A structured set of activities required to develop a software system

Specification;
Design;
Validation;
Evolution.

A software process model is an abstract representation of a process. It presents a description of a

process from some particular perspective
Software Quality is conformance to:

explicitly stated functional and performance requirements,

explicitly documented development standards,
implicit characteristics that are expected of all professionally developed software.

Note:

Quality management is not just about reducing defects!

Quality attributes apply both to the product and the process.
o product: delivered to the customer
o process: produces the software product

Prepared By Neelam Rawat

Software Quality Attributes

The difference between an amateur product and a carrier grade product is not much in functionality; it
is in Quality. For any serious business to depend on a piece of software to continue to function and
evolve as needed a long list of quality attributes or 'abilities' are required. The list seems to be long, but
each ability is vital. If you get stuck with something that doesn't have any one of the required abilities,
that inability manifests itself in different problematic ways.
To take examples, just imagine working with a product that isn't scalable? Or isn't reliable? Or isn't easily
usable? Or isn't upgradeable? Or isn't Interoperable with something new that you want to put in? Or
isn't configurable with your network changes? Or isn't always available? Or isn't auditable? Or isn't
secure? ....

Correctness

A system is correct if it behaves according to its specification

A a solute propert i.e., a s ste a ot e al ost orre t
... in theory and practice undecidable

The user may rely on the system behaving properly

Reliability is the probability that the system will operate as expected over a
specified interval
A relative property (a system has a mean time between failure of 3 weeks)

Reliability

Robustness

A system is robust if it behaves reasonably even in circumstances that were not

specified

Prepared By Neelam Rawat

Efficiency (Performance)
Use of resources such as computing time, memory
Affects user-friendliness and scalability
Hardware technology changes fast!
First do it, then do it right, then do it fast

A vague property (once you specify the abnormal circumstances they become
part of the requirements)

For process, resources are manpower, time and money

relates to the produ ti it of a pro ess

Usability (User Friendliness, Human Factors)

The degree to hi h the hu a users fi d the s ste pro ess oth eas to use
and useful
Depends a lot on the target audience (novices vs. experts)
Often a system has various kinds of users (end-users, operators, installers)
T pi all e pressed i a ou t of ti e to lear the s ste
Maintainability
How easy it is to change a system after its initial release
software entropy
e
Repairability
How much work is needed to correct a defect

Evolvability (Adaptability)
How much work is needed to adapt to changing requirements (both system and
process)

Portability
How much work is needed to port to new environment or platforms
Verifiability
How easy it is to verify whether desired attributes are there?
internally: e.g., verify requirements, code inspections
externally: e.g., testing, efficiency

Understandability
How easy it is to understand the system
internally: contributes to maintainability
externally: contributes to usability
Productivity
Amount of product produced by a process for a given number of resources
productivity among individuals varies a lot
often:
produ ti it i di iduals < produ ti it i di iduals

Prepared By Neelam Rawat

Timeliness: Ability to deliver the product on time

i porta t for arketi g short ti e to arket
often a reason to sacrifice other quality attributes
incremental development may provide an answer
Visibility (Transparency): Current process steps and project status are accessible
important for management
also deal with staff turn-over

SDLC: Software Development Life Cycle

SDLC, Software Development Life Cycle is a process used by software industry to design, develop and
test high quality software. The SDLC aims to produce high quality software that meets or exceeds
customer expectations, reaches completion within times and cost estimates.

SDLC is the acronym of Software Development Life Cycle.

It is also called as Software development process.

The software development life cycle (SDLC) is a framework defining tasks performed at each
step in the software development process.

ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the
standard that defines all the tasks required for developing and maintaining software.

What is SDLC?
SDLC is a process followed for a software project, within a software organization. It consists of a detailed
plan describing how to develop, maintain, replace and alter or enhance specific software. The life cycle
defines a methodology for improving the quality of software and the overall development process.
The following figure is a graphical representation of the various stages of a typical SDLC.

Prepared By Neelam Rawat

Phases of the Software Development Lifecycle

SDLC starts with the analysis and definition phases, where the purpose of the software or system should
be determined, the goals of what it needs to accomplish need to be established, and a set of definite
requirements can be developed.
During the software construction or development stage, the actual engineering and writing of the
application is completed. The software is designed and produced, while attempting to accomplish all of
the requirements that were set forth within the previous stage.
Next in the software development lifecycle is the testing phase. Code produced during construction
should be tested using static and dynamic analysis, as well as manual penetration testing to ensure that
the application is not easily exploitable to hackers, which could result in a critical security breach. The
advantage of using Veracode during this stage is that by using state of the art binary analysis (no source
code required), the security posture of applications can be verified without requiring the use of any
additional hardware, software or personnel.
SDLC Implementation
There are two different types of SDLC that can be used: waterfall and agile. The major difference
between the two is that the waterfall process is more traditional and begins with a well thought-out
plan and defined set of requirements, whereas agile SDLC begins with less stringent guidelines and then
makes adjustments as needed throughout the process. Agile development is known for its ability to
quickly translate an application that is in development to a full release at nearly any stage, making it well
suited for applications that are updated frequently.
SDLC Models

Prepared By Neelam Rawat

10

There are various software development life cycle models defined and designed which are followed
during software development process. These models are also referred as "Software Development
Process Models". Each process model follows a Series of steps unique to its type, in order to ensure
success in process of software development.
Following are the most important and popular SDLC models (which will discuss in this syllabus) followed
in the industry:
1.
2.
3.
4.
5.

SDLC:
SDLC:
SDLC:
SDLC:
SDLC:

Waterfall Model
Prototype Model
Spiral Model
Evolutionary Development Models
Iterative Enhancement Models.

Waterfall Model
The Waterfall Model was first Process Model to be introduced. It is also referred to as a linearsequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase
must be completed before the next phase can begin and there is no overlapping in the phases.
Waterfall model is the earliest SDLC approach that was used for software development .
The waterfall Model illustrates the software development process in a linear sequential flow; hence it is
also referred to as a linear-sequential life cycle model. This means that any phase in the development
process begins only if the previous phase is complete. In waterfall model phases do not overlap.
In "The Waterfall" approach, the whole process of software development is divided into separate
phases. In Waterfall model, typically, the outcome of one phase acts as the input for the next phase
sequentially.
Following is a diagrammatic representation of different phases of waterfall model.

The sequential phases in Waterfall model are:

Prepared By Neelam Rawat

11

Requirement Gathering and analysis: All possible requirements of the system to be developed
are captured in this phase and documented in a requirement specification doc.

System Design: The requirement specifications from first phase are studied in this phase and
system design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.

Implementation: With inputs from system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and tested
for its functionality which is referred to as Unit Testing.

Integration and Testing: All the units developed in the implementation phase are integrated into
a system after testing of each unit. Post integration the entire system is tested for any faults and
failures.

Deployment of system: Once the functional and non functional testing is done, the product is
deployed in the customer environment or released into the market.

Maintenance: There are some issues which come up in the client environment. To fix those
issues patches are released. Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards
(like a waterfall) through the phases. The next phase is started only after the defined set of goals are
achieved for previous phase and it is signed off, so the name "Waterfall Model". In this model phases do
not overlap.
Waterfall Model Application
Every software developed is different and requires a suitable SDLC approach to be followed based on
the internal and external factors. Some situations where the use of Waterfall model is most appropriate
are:

Requirements are very well documented, clear and fixed.

Product definition is stable.
Technology is understood and is not dynamic.
There are no ambiguous requirements.
Ample resources with required expertise are available to support the product.
The project is short.

Pros & Cons of Waterfall Model:

Pros
Simple and easy to understand and use

Prepared By Neelam Rawat

Cons
No working software is produced until late
during the life cycle.

12

Easy to manage due to the rigidity of the

model. Each phase has specific deliverables High amounts of risk and uncertainty.
and a review process.
Phases are processed and completed one at a Not a good model for complex and objecttime.
oriented projects.
Works well for smaller projects where
Poor model for long and ongoing projects.
requirements are very well understood.
Not suitable for the projects where
requirements are at a moderate to high risk of
Clearly defined stages.
changing. So risk and uncertainty is high with
this process model.
It is difficult to measure progress within
Well understood milestones.
stages.
Easy to arrange tasks.
Process and results are well documented.

Cannot accommodate changing requirements.

Adjusting scope during the life cycle can end a
project.
Integration is done as a "big-bang. at the very
end, which doesn't allow identifying any
technological or business bottleneck or
challenges early.

V-Shaped Model
It is an extension for waterfall model, Instead of moving down in a linear way, the process steps are bent
upwards after the coding phase, to form the typical V shape. The major difference between v-shaped
model and waterfall model is the early test planning in v-shaped model.

The usage

Software requirements clearly defined and known

Software development technologies and tools is well-known

Pros & Cons of V-Model

Prepared By Neelam Rawat

13
Pros
Simple and easy to use. Each phase has specific
deliverables. Higher chance of success over the
waterfall model due to the development of test plans
early on during the life cycle. Works well for where
requirements are easily understood. Verification and
validation of the product in early stages of product
development

Cons
Very inflexible, like the waterfall model. Little
flexibility and adjusting scope is difficult and
expensive. Software is developed during the
implementation phase, so no early prototypes
of the soft are are produ ed. Model does t
provide a clear path for problems found
during testing phases. Costly and required
more time, in addition to detailed plan

Prototype Model
The Software Prototyping refers to building software application prototypes which display the
functionality of the product under development but may not actually hold the exact logic of the original
software.
Software prototyping is becoming very popular as a software development model, as it enables to
understand customer requirements at an early stage of development. It helps get valuable feedback
from the customer and helps software designers and developers understand about what exactly is
expected from the product under development.
What is Software Prototyping?

Prototype is a working model of software with some limited functionality.

The prototype does not always hold the exact logic used in the actual software application and is
an extra effort to be considered under effort estimation.

Prototyping is used to allow the users evaluate developer proposals and try them out before
implementation.

It also helps understand the requirements which are user specific and may not have been
considered by the developer during product design.

Prepared By Neelam Rawat

14

Following is the stepwise approach to design a software prototype:

Basic Requirement Identification: This step involves understanding the very basics product
requirements especially in terms of user interface. The more intricate details of the internal
design and external aspects like performance and security can be ignored at this stage.

Developing the initial Prototype: The initial Prototype is developed in this stage, where the very
basic requirements are showcased and user interfaces are provided. These features may not
exactly work in the same manner internally in the actual software developed and the
workarounds are used to give the same look and feel to the customer in the prototype
developed.

Review of the Prototype: The prototype developed is then presented to the customer and the
other important stakeholders in the project. The feedback is collected in an organized manner
and used for further enhancements in the product under development.

Revise and enhance the Prototype: The feedback and the review comments are discussed during
this stage and some negotiations happen with the customer based on factors like , time and
budget constraints and technical feasibility of actual implementation. The changes accepted are
again incorporated in the new Prototype developed and the cycle repeats until customer
expectations are met.

Prototypes can have horizontal or vertical dimensions. Horizontal prototype displays the user interface
for the product and gives a broader view of the entire system, without concentrating on internal
functions. A vertical prototype on the other side is a detailed elaboration of a specific function or a sub
system in the product.
The purpose of both horizontal and vertical prototype is different. Horizontal prototypes are used to get
more information on the user interface level and the business requirements. It can even be presented in
the sales demos to get business in the market. Vertical prototypes are technical in nature and are used
to get details of the exact functioning of the sub systems. For example, database requirements,
interaction and data processing loads in a given sub system.

Prepared By Neelam Rawat

15
Software Prototyping Types
There are different types of software prototypes used in the industry. Following are the major software
prototyping types used widely:

Throwaway/Rapid Prototyping: Throwaway prototyping is also called as rapid or close ended

prototyping. This type of prototyping uses very little efforts with minimum requirement analysis
to build a prototype. Once the actual requirements are understood, the prototype is discarded
and the actual system is developed with a much clear understanding of user requirements.

Evolutionary Prototyping: Evolutionary prototyping also called as breadboard prototyping is

based on building actual functional prototypes with minimal functionality in the beginning. The
prototype developed forms the heart of the future prototypes on top of which the entire system
is built. Using evolutionary prototyping only well understood requirements are included in the
prototype and the requirements are added as and when they are understood.

Incremental Prototyping: Incremental prototyping refers to building multiple functional

prototypes of the various sub systems and then integrating all the available prototypes to form a
complete system.

Extreme Prototyping : Extreme prototyping is used in the web development domain. It consists
of three sequential phases. First, a basic prototype with all the existing pages is presented in the
html format. Then the data processing is simulated using a prototype services layer. Finally the
services are implemented and integrated to the final prototype. This process is called Extreme
Prototyping used to draw attention to the second phase of the process, where a fully functional
UI is developed with very little regard to the actual services.

Pros & Cons of Prototype Model:

Pros

Cons

Increased user involvement in the product Risk of insufficient requirement analysis owing to
even before implementation
too much dependency on prototype
Since a working model of the system is
Users may get confused in the prototypes and
displayed, the users get a better
actual systems.
understanding of the system being developed.
Practically, this methodology may increase the
Reduces time and cost as the defects can be
complexity of the system as scope of the system
detected much earlier.
may expand beyond original plans.
Developers may try to reuse the existing prototypes
Quicker user feedback is available leading to
to build the actual system, even when its not
better solutions.
technically feasible
Missing functionality can be identified easily

Prepared By Neelam Rawat

The effort invested in building prototypes may be

too much if not monitored properly

16
Prototype Model
The spiral model combines the idea of iterative development with the systematic, controlled aspects of
the waterfall model.
Spiral model is a combination of iterative development process model and sequential linear
development model i.e. waterfall model with very high emphasis on risk analysis.
It allows for incremental releases of the product, or incremental refinement through each iteration
around the spiral.
Spiral Model design
The spiral model has four phases. A software project repeatedly passes through these phases in
iterations called Spirals.

Identification: This phase starts with gathering the business requirements in the baseline spiral.
In the subsequent spirals as the product matures, identification of system requirements,
subsystem requirements and unit requirements are all done in this phase.

This also includes understanding the system requirements by continuous communication

between the customer and the system analyst. At the end of the spiral the product is deployed
in the identified market.

Design: Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and final design in the
subsequent spirals.

Construct or Build: Construct phase refers to production of the actual software product at every
spiral. In the baseline spiral when the product is just thought of and the design is being
developed a POC (Proof of Concept) is developed in this phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a working
model of the software called build is produced with a version number. These builds are sent to
customer for feedback.

Evaluation and Risk Analysis: Risk Analysis includes identifying, estimating, and monitoring
technical feasibility and management risks, such as schedule slippage and cost overrun. After
testing the build, at the end of first iteration, the customer evaluates the software and provides
feedback.

Following is a diagrammatic representation of spiral model listing the activities in each phase:

Prepared By Neelam Rawat

17

Based on the customer evaluation, software development process enters into the next iteration and
subsequently follows the linear approach to implement the feedback suggested by the customer. The
process of iterations along the spiral continues throughout the life of the software.
Spiral Model Application
Spiral Model is very widely used in the software industry as it is in synch with the natural development
process of any product i.e. learning with maturity and also involves minimum risk for the customer as
well as the development firms. Following are the typical uses of Spiral model:

When costs there is a budget constraint and risk evaluation is important.

For medium to high-risk projects.
Long-term project commitment because of potential changes to economic priorities as the
requirements change with time.

Customer is not sure of their requirements which is usually the case.

Requirements are complex and need evaluation to get clarity.
New product line which should be released in phases to get enough customer feedback.
Significant changes are expected in the product during the development cycle.

Pros& Cons of Spiral Model:

Pros
Changing
requirements
accommodated.

Prepared By Neelam Rawat

Cons
can

be

Management is more complex.

18
Allows for extensive use of prototypes

End of project may not be known early.

Not suitable for small or low risk

Requirements can be captured more
projects and could be expensive for
accurately.
small projects.
Users see the system early.

Process is complex

Development can be divided into smaller

parts and more risky parts can be
Spiral may go indefinitely.
developed earlier which helps better risk
management.
Large number of intermediate stages
requires excessive documentation.

SDLC: Evolutionary Development Models:

Evolutionary software models are iterative. They are characterized in manner that enables the software
engineers to develop increasingly more complete version of software.
This models are applied because as the requirements often change so the end product will be
unrealistic, where a complete version is impossible due to tight market deadlines it is better to
introduce a limited version to meet the pressure. Thus the software engineers can follow a process
model that has been explicitly designed to accommodate a product that gradually complete over time.

Prepared By Neelam Rawat

19

Iterative Enhancement Model

In Iterative model, iterative process starts with a simple implementation of a small set of the software
requirements and iteratively enhances the evolving versions until the complete system is implemented
and ready to be deployed.
An iterative life cycle model does not attempt to start with a full specification of requirements. Instead,
development begins by specifying and implementing just part of the software, which is then reviewed in
order to identify further requirements. This process is then repeated, producing a new version of the
software at the end of each iteration of the model.
Iterative Model design
Iterative process starts with a simple implementation of a subset of the software requirements and
iteratively enhances the evolving versions until the full system is implemented. At each iteration, design
modifications are made and new functional capabilities are added. The basic idea behind this method is
to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental).
Following is the pictorial representation of Iterative and Incremental model:

Prepared By Neelam Rawat

20
Iterative and Incremental development is a combination of both iterative design or iterative method and
incremental build model for development. "During software development, more than one iteration of
the software development cycle may be in progress at the same time." and "This process may be
described as an "evolutionary acquisition" or "incremental build" approach."
In incremental model the whole requirement is divided into various builds. During each iteration, the
development module goes through the requirements, design, implementation and testing phases. Each
subsequent release of the module adds function to the previous release. The process continues till the
complete system is ready as per the requirement.
The key to successful use of an iterative software development lifecycle is rigorous validation of
requirements, and verification & testing of each version of the software against those requirements
within each cycle of the model. As the software evolves through successive cycles, tests have to be
repeated and extended to verify each version of the software.
Iterative Model Application
Like other SDLC models, Iterative and incremental development has some specific applications in the
software industry. This model is most often used in the following scenarios:

Requirements of the complete system are clearly defined and understood.

Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
There is a time to the market constraint.
A new technology is being used and is being learnt by the development team while working on
the project.
Resources with needed skill set are not available and are planned to be used on contract basis
for specific iterations.
There are some high risk features and goals which may change in the future.

Pros & Cons of Iterative Enhancement Model:

Pros
Cons
Some working functionality can be
More resources may be required.
developed quickly and early in the life cycle.
Although cost of change is lesser but it is not very suitable
Results are obtained early and periodically.
for changing requirements.
Parallel development can be planned.

More management attention is required.

System architecture or design issues may arise because

not all requirements are gathered in the beginning of the
Progress can be measured.
entire life cycle.
Less
costly
to
change
the Defining increments may require definition of the
scope/requirements.
complete system.
Testing and debugging during smaller
Not suitable for smaller projects.
iteration is easy.

Prepared By Neelam Rawat

21
Risks are identified and resolved during
iteration; and each iteration is an easily Management complexity is more.
managed milestone.
Easier to manage risk - High risk part is done
End of project may not be known which a risk is.
first.
With every increment operational product is
Highly skilled resources are required for risk analysis.
delivered.
Issues, challenges & risks identified from
Projects progress is highly dependent upon the risk
each increment can be utilized/applied to
analysis phase.
the next increment.
Risk analysis is better.
It supports changing requirements.
Initial Operating time is less.
Better suited for large and mission-critical
projects.
During life cycle software is produced early
which facilitates customer evaluation and
feedback.

Prepared By Neelam Rawat

1
Software Engineering
NMCA 512
Unit-2
Contents:

Requirement Engineering Process: Elicitation, Analysis, Documentation, Review.

Management of User Needs, Feasibility Study, Information Modeling, Data Flow Diagrams,
Entity Relationship Diagrams, Decision Tables, SRS Document, IEEE Standards for SRS.
Software Quality Assurance (SQA): Verification and Validation, SQA Plans
Software Quality Frameworks, ISO 9000 Models, SEI-CMM Model.

Software Requirements
Descriptions a d specificatio s of a syste

The software requirements are description of features and functionalities of the target system.
Requirements convey the expectations of users from the software product. The requirements can be
obvious or hidden, known or unknown, expected or unexpected from clie t s poi t of ie .
Types of Software Requirements:
Software requirement fall into five categories
1.
2.
3.
4.
5.

Functional Requirements
Non-functional Requirements
Interface Requirements
Inverse Requirements
Design and Constraints Requirements

Functional Requirements

A functional requirement document defines the functionality of a system or one of its

subsystems. It also depends upon the type of software, expected users and the type of system
where the software is used.

Functional user requirements may be high-level statements of what the system should do but
functional system requirements should also describe clearly about the system services in detail.
A functional requirement describes what a software system should do, while non-functional
requirements place constraints on how the system will do so.
An example of a functional requirement would be: A system must send an email whenever a
certain condition is met (e.g. an order is placed, a customer signs up, etc).

Prepared By Neelam Rawat

A related non-functional requirement for the system may be: Emails should be sent with a
latency of no greater than 12 hours from such an activity.

Note: The functional requirement is describing the behavior of the system as it relates to the system's
functionality. The non-functional requirement elaborates a performance characteristic of the system.
Non-Functional Requirements
In systems engineering and requirements engineering, a non-functional requirement is a requirement
that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.
They are contrasted with functional requirements that define specific behavior or functions. The plan for
implementing functional requirements is detailed in the system design. The plan for implementing nonfunctional requirements is detailed in the system architecture, because they are usually Architecturally
Significant Requirements.
Whereas, Architecturally Significant Requirements (ASRs) are those requirements that have a
measurable effect on a software systems architecture. They are subset of requirements, the subset that
affects the architecture of a system in measurably identifiable ways.
Note: Broadly, functional requirements define what a system is supposed to do and non-functional
requirements define how a system is supposed to be.
Functional vs. Non-functional Requirements

Interface Requirements
Systems must operate with other systems and the operating interfaces must be specified as part of
requirements. It includes:
1. User Interface

Prepared By Neelam Rawat

3
2. Communication Interface
3. Software Interface
4. Hardware Interface
User Interface: Describe the logical characteristics of each user interface that the system needs. Example
includes GUI, CLI (Command line Interface), API (Application Program Interface) etc.
Communication Interface: State the requirements for any communication functions the product will use,
including e-mail, Web browser, network communications protocols, and electronic forms. Define any
pertinent message formatting. Specify communication security or encryption issues, data transfer rates,
and synchronization mechanisms.
Software Interface: Describe the connections between this product and other software components
(identified by name and version), including databases, operating systems, tools, libraries, and integrated
commercial components. State the purpose of the messages, data, and control items exchanged
between the software components. Describe the services needed by external software components and
the nature of the inter-component communications. Identify data that will be shared across software
components. If the data-sharing mechanism must be implemented in a specific way, such as a global
data area, specify this as a constraint.
Hardware Interface: Describe the characteristics of each interface between the software and hardware
components of the system. This description might include the supported device types, the data and
control interactions between the software and the hardware, and the communication protocols to be
used.
Inverse Requirements
Inverse requirements specify the constraints on allowable behavior. Software safety and security
requirements are usually stated in this manner. Inverse requirements can be functional and non
functional. For example: When a customer specifies that something must not be done. For example,
User ID should only contain digits.
Design and Implementation Requirements
Design constraints and implementation constraints are boundary conditions on how the required
software is to be constructed and implemented. Examples of design constraints include the fact that the
software must run using a certain database system or that the software must fit into the memory of a
512 Kbyte machine.
Requirement Engineering

The process to gather the software requirements from client, analyze and document them is
known as requirement engineering.
The goal of requirement engineering is to develop and maintain sophisticated and descriptive
ste e ui e e ts pe ifi atio do u e t.

Prepared By Neelam Rawat

4
According to Pohl i 1993, it a e defi ed as the p o ess of de elopi g e ui e ents through an
interactive, co-operative process of analyzing the problem, documenting the resulting observations in a
a iet of ep ese tatio fo ats, a d he ki g the a u a of the u de sta di g gai ed .

Requirement Engineering Activities:

The Requirements Engineering Process involves the following activities.
1.
2.
3.
4.
5.

Requirements Elicitations
Requirements Analysis
Requirements Specification
Requirements Validation
Requirements Management

Requirement Elicitation Process

Requirement elicitation process can be depicted using the following diagram:

Requirements gathering - The developers discuss with the client and end users and know their
expectations from the software.
Organizing Requirements - The developers prioritize and arrange the requirements in order of
importance, urgency and convenience.

Prepared By Neelam Rawat

Negotiation & discussion - If requirements are ambiguous or there are some conflicts in
requirements of various stakeholders, if they are, it is then negotiated and discussed with
stakeholders. Requirements may then be prioritized and reasonably compromised.
The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements are
compromised reasonably.
Documentation - All formal & informal, functional and non-functional requirements are
documented and made available for next phase processing.

Requirement Analysis

Requirements analysis is the process of determining user expectations for a new or modified
product. These features, called requirements, must be quantifiable, relevant and detailed. In
software engineering, such requirements are often called functional specifications.
Requirements analysis is an important aspect of project management.
Requirement analysis encompasses those tasks that go into determining the needs or conditions
to meet for a new or altered product, taking account of the possibly conflicting requirements of
the various stakeholders, such as beneficiaries or users.
Requirements analysis is critical to the success of a development project. Requirements must be
actionable, measurable, testable, related to identified business needs or opportunities, and
defined to a level of detail sufficient for system design. Requirements can be functional and nonfunctional.

Requirements Specification

The purpose of the requirements analysis is to identify requirements for the proposed system.
The emphasis is on the discovery of user requirements. Each requirement (or problem) must be
defined and documented in the requirements catalogue. Each requirement is recorded in the
requirements catalogue on a requirements catalogue entry form.
Requirements specification is the activity during which requirements are recorded in one or
more forms, usually in a Software Requirement Specification Document (SRS)

SRS:
A software requirements specification (SRS) is a document that captures complete description about
how the system is expected to perform. It is usually signed off at the end of requirements engineering
phase.
Qualities of SRS:
1. Correct: An SRS is correct if every requirement included in the SRS represents something
required in the final system. Correctness ensures that what is specified done correctly.

Prepared By Neelam Rawat

6
2. Unambiguous: An SRS is unambiguous if and only if every requirement stated has one and only
one interpretation. So instead of natural language some formal languages can be used to reduce
ambiguity
3. Complete: An SRS is complete if everything the software is supposed to do and the responses of
the software to all classes of input data are specified in the SRS. Completeness ensures that
everything is indeed specified.
4. Consistent: An SRS is consistent if there is no requirement that conflicts with other. Ex
Suppose a requirement states that an event e is to occur before another event f. But then
another set of requirements states that event f should occur before event e.
5. Ranked for importance and/or stability: An SRS is ranked for importance and /or stability if for
each requirement the importance and the stability of the requirement is indicated. Stability of a
requirement reflects the chances of it changing in future.
6. Modifiable: An SRS is modifiable if its structure and style are such that any necessary change can
be made easily while preserving completeness and consistency.
7. Traceable: Each requirement in SRS must be uniquely identified to a source ( e.g. Use Case,
government requirement, Design, Industry Standard etc.)
SRS Format

Prepared By Neelam Rawat

7
Requirements Validation

Requirements validation is an iterative process which takes place throughout the lifecycle of the
project. During elicitation, analysis and specification you should constantly be questioning and
clarifying the data given to you in order to check its validity. This will ensure that the SRS that
you produce is complete, consistent and ready for the formal validation process.
During the formal requirements validation process you are aiming to ensure that the SRS is
complete, consistent, modifiable and traceable. You are also testing to makes sure that the
requirements statements themselves are complete, correct, feasible, necessary, prioritized,
unambiguous and verifiable. This may seem like a lofty task but it is essential to pick up any gaps
or errors at this stage in order to minimize defects later.
The costs associated with rectifying defects later in the process are exorbitant. Ironing out as
much possible at this stage should be your priority. There are many techniques available to help
you with the process. Most the techniques involve all the stakeholder representatives reading
the requirements; carrying out problem analysis; meeting; discussing, resolving issues and
collaboration that will result in consensus and the requirements baseline being set.

Requirement Validation Techniques

Review and Inspection Review and inspection is the most rigorous process. It can also be the
most time consuming as it generally involves all the stakeholder representatives. The SRS is
reviewed collaboratively. Any issue arising are captured in an issues log. Some will be resolved
on the spot others will need to be referred to specialists for clarification. This means that this
process is iterative and may go through a few iterations before all the issues are resolved.
Prototyping One of the most effective ways to ensure that the developers are on the same
page as the users. Prototyping is generally used to test validity and completeness of the
requirements. A prototype brings the SRS to life by providing the users with a visual model. The
developers will choose the most appropriate approach to prototyping depending on the
situation.
Traceability This should be carried out for every single project, unless the project is very small.
Completing a traceability matrix will ensure that the SRS is complete, that nothing has fallen
through the gaps. It will also ensure that all the requirements elicited can be traced back and
justified to business requirements as well as functional requirements. This matrix lays the
foundation for checking bidirectional traceability between the requirements, test cases, source
code and design.
Testing All requirements must be testable /verifiable so putting together the test scripts for
the project as early as possible will highlight missing information or information that is
ambiguous. If you are using use cases this is not an onerous task. This is an ideal method for
testing functional requirements but can be tricky to adopt for non-functional requirements.

Prepared By Neelam Rawat

8
Requirement Management

Requirements management is the process of managing changing requirements during the

requirements engineering process and system development.
Requirements management is the process of documenting, analyzing, tracing, prioritizing and
agreeing on requirements and then controlling change and communicating to relevant
stakeholders.
It is a continuous process throughout a project. A requirement is a capability to which a project
outcome (product or service) should conform.
The purpose of requirements management is to ensure that an organization documents,
verifies, and meets the needs and expectations of its customers and internal or external
stakeholders
Requirements management begins with the analysis and elicitation of the objectives and
constraints of the organization. Requirements management further includes supporting
planning for requirements, integrating requirements and the organization for working with
them (attributes for requirements), as well as relationships with other information delivering
against requirements, and changes for these.
Requirements traceability is concerned with documenting the life of a requirement. It
should be possible to trace back to the origin of each requirement and every change made to
the requirement should therefore be documented in order to achieve traceability. Even the use
of the requirement after the implemented features have been deployed and used should be
traceable

Prepared By Neelam Rawat

9
Feasibility Study
The purpose of feasibility study is not to solve the problem, but to determine whether the problem is
worth solving
A feasibility study is carried out to select the best system that meets performance requirements.
The main aim of the feasibility study activity is to determine whether it would be financially and
technically feasible to develop the product. The feasibility study activity involves the analysis of the
problem and collection of all relevant information relating to the product such as the different data
items which would be input to the system, the processing required to be carried out on these data, the
output data required to be produced by the system as well as various constraints on the behaviour of
the system.

Types of Feasibility Study

Prepared By Neelam Rawat

10
1.
2.
3.
4.

Operational Feasibility
Technical Feasibility
Economic Feasibility
Schedule Feasibilty

Technical Feasibility
This is concerned with specifying equipment and software that will successfully satisfy the user
requirement. The technical needs of the system may vary considerably, but might include:

The facility to produce outputs in a given time.

Response time under certain conditions.
Ability to process a certain volume of transaction at a particular speed.
Facility to communicate data to distant locations.

In examining technical feasibility, configuration of the system is given more importance than the actual
ake of ha d a e. The o figu atio should gi e the o plete pi tu e a out the s ste s
requirements:
How many workstations are required, how these units are interconnected so that they could operate
and communicate smoothly?
What speeds of input and output should be achieved at particular quality of printing.
Economic Feasibility
Economic analysis is the most frequently used technique for evaluating the effectiveness of a proposed
system. More commonly known as Cost / Benefit analysis, the procedure is to determine the benefits
and savings that are expected from a proposed system and compare them with costs. If benefits
outweigh costs, a decision is taken to design and implement the system. Otherwise, further justification
or alternative in the proposed system will have to be made if it is to have a chance of being approved.
This is an outgoing effort that improves in accuracy at each phase of the system life cycle.
Operational Feasibility
This is mainly related to human organizational and political aspects. The points to be considered are:

What changes will be brought with the system?

What organizational structure are disturbed?
What new skills will be required? Do the existing staff members have these skills? If
not, can they be trained in due course of time?

This feasibility study is carried out by a small group of people who are familiar with information system
technique and are skilled in system analysis and design process.

Prepared By Neelam Rawat

11
Proposed projects are beneficial only if they can be turned into information system that will meet the
operating requirements of the organization. This test of feasibility asks if the system will work when it is
developed and installed.
Schedule Feasibility Study
Schedule Feasibility is defined as the probability of a project to be completed within its scheduled time
limits, by a planned due date. If a project has a high probability to be completed on-time, then its
schedule feasibility is appraised as high. In many cases a project will be unsuccessful if it takes longer
than it was estimated: some external environmental conditions may change, hence a project can lose its
benefits, expediency and profitability.
Schedule feasibility study is also used in conjunction with technical, economical and operational
feasibility study. Schedule feasibility study includes use of the following:

Project Estimation
Gantt and PERT charts
CPM (Critical Path Method)
Change Management

Information Modeling

An information model is essential to provide the structure for information that is transferred in
a communication. An information model is a formal description of a portion of interest of the
real world and that provides explicit rules to enable the data items that populate the model to
be interpreted without ambiguity.
An example of an information model is the structure of a sentence in a natural language. The
grammar of the natural language provides the rules for interpretation of the information model
(sentence) and the data items in the structure are the words of the language. To complete the
capability to interpret the communication correctly a dictionary that defines the meanings of
the data items (words) is also needed. To achieve unambiguous communication, everyone in the
communication process must use the same information model and the same dictionary. If the
communication process is between two computer software systems then the information model
and the dictionary also have to be computer process-able. A dictionary also has to have an
information model to provide a structure for the items and their definitions.
In general, the contents of an information model include
1. Scope
2. Information requirements

Scope
I fo atio
odeli g sta ts ith the defi itio of the s ope of the odel s appli a ilit . The s ope
specifies the domain of discourse and the processes that are to be supported by the information model.
It is a bounded collection of processes, information, and constraints that satisfy some industry need.

Prepared By Neelam Rawat

12
A well-defined scope should be accurate, unambiguous, viable, and meet the industrial need. During the
course of the modeling, the scope should be revisited and may be refined. Since the scope provides the
ou da ies of the appli atio do ai , it also se es as a guideli e fo e aluati g the o plete ess of
the information model.
The scope statements include the purpose as well as viewpoints of the model mentioned bellow:

type of product,
type of data requirements,
supporting manufacturing scenario,
supporting manufacturing activities,
supporting stage in the product life cycle.

Information Requirement
After the scope is defined, the next phase is to conduct a requirements analysis. There is no standard
method for collecting information requirements. However, requirements analysis may be accomplished
by:

Literature surveys,
Standards surveys,
Do ai e pe ts i te ie s,
Industrial data reviews,
State-of-the-art assessments.

As the result of the requirements analysis, information requirements should be documented. The
definition of each identified information item should be included in the document. This document will
be a straw man for developing the information model.
There are different practices in developing an information model:
1.
2.
3.
4.
5.

DFD
Structure Charts
HIPO Diagram
ER-Diagram
Decision Tables

Data Flow Diagram

Data flow diagram is graphical representation of flow of data in an information system. It is

capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does not
mention anything about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of
control in program modules. DFDs depict flow of data in the system at various levels. DFD does
not contain any control or branch elements.

Prepared By Neelam Rawat

13
Types of DFD: Data Flow Diagrams are either Logical or Physical.
1. Logical DFD - This type of DFD concentrates on the system process, and flow of data in the
system.For example in a Banking software system, how data is moved between different
entities.
2. Physical DFD - This type of DFD shows how the data flow is actually implemented in the system.
It is more specific and close to the implementation.
DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of components

Entities - Entities are source and destination of information data. Entities are represented by a
rectangles with their respective names.
Process - Activities and action taken on the data are represented by Circle or Round-edged
rectangles.
Data Storage - There are two variants of data storage - it can either be represented as a
rectangle with absence of both smaller sides or as an open-sided rectangle with only one side
missing.
Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from the
base of arrow as its source towards head of the arrow as destination.

Levels of DFD

Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire
information system as one diagram concealing all the underlying details. Level 0 DFDs are also
known as context level DFDs.

Prepared By Neelam Rawat

14

Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1 DFD depicts
basic modules in the system and flow of data among various modules. Level 1 DFD also
mentions basic processes and sources of information.

Level 2 - At this level, DFD shows how data flows inside the modules mentioned in Level 1.
Higher level DFDs can be transformed into more specific lower level DFDs with deeper level of
understanding unless the desired level of specification is achieved.

Structure Charts

Structure chart is a chart derived from Data Flow Diagram. It represents the system in more
detail than DFD. It breaks down the entire system into lowest functional modules, describes
functions and sub-functions of each module of the system to a greater detail than DFD.
Structure chart represents hierarchical structure of modules. At each layer a specific task is
performed.

HIPO Diagram

HIPO (Hierarchical Input Process Output) diagram is a combination of two organized method to
analyze the system and provide the means of documentation. HIPO model was developed by
IBM in year 1970.

Prepared By Neelam Rawat

15

HIPO diagram represents the hierarchy of modules in the software system. Analyst uses HIPO
diagram in order to obtain high-level view of system functions. It decomposes functions into
sub-functions in a hierarchical manner. It depicts the functions performed by system.
HIPO diagrams are good for documentation purpose. Their graphical representation makes it
easier for designers and managers to get the pictorial idea of the system structure.

Decision Tables

A Decision table represents conditions and the respective actions to be taken to address them,
in a structured tabular format.
It is a powerful tool to debug and prevent errors. It helps group similar information into a single
table and then by combining tables it delivers easy and convenient decision-making.

Creating Decision Table

To create the decision table, the developer must follow basic four steps:
1.
2.
3.
4.

Identify all possible conditions to be addressed

Determine actions for all identified conditions
Create Maximum possible rules
Define action for each rule

Decision Tables should be verified by end-users and can lately be simplified by eliminating duplicate
rules and actions.
Example: Let us take a simple example of day-to-day problem with our Internet connectivity. We begin
by identifying all problems that can arise while starting the internet and their respective possible
solutions.
We list all possible problems under column conditions and the prospective actions under column
Actions.

Decision Table In-house Internet Troubleshooting

Prepared By Neelam Rawat

16
Entity-Relationship Model
Entity-Relationship model is a type of database model based on the notion of real world entities and
relationship among them. We can map real world scenario onto ER database model. ER Model creates a
set of entities with their attributes, a set of constraints and relation among them.
ER Model is best used for the conceptual design of database. ER Model can be represented as follows:

Entity - An entity in ER Model is a real world being, which has some properties called attributes.
Every attribute is defined by its corresponding set of values, called domain.
For example, consider a school database. Here, a student is an entity. Student has various
attributes like name, id, age and class etc.
Relationship - The logical association among entities is called relationship. Relationships are
mapped with entities in various ways. Mapping cardinalities define the number of associations
between two entities.

Software Quality Assurance (SQA)

Quality --> refers to measurable characteristics of a software.

These items can be compared based on a given standard
Two types of quality control:
Quality design -> the characteristics that designers specify for an item.
Includes: requirements, specifications, and the design of the system.
Quality of conformance -> the degree to which the design specification are followed. It focuses
on implementation based on the design.

Software quality assurance (SQA) is a process that ensures that developed software meets and complies
with defined or standardized quality specifications. SQA is an ongoing process within the software
development life cycle (SDLC) that routinely checks the developed software to ensure it meets desired
quality measures.

Prepared By Neelam Rawat

17
Software Quality Assurance Activities (SQA PLANS)

Prepares an SQA plan for a project

Pa ti ipates i the de elop e t of the p oje t s soft a e p o ess des iptio .
Reviews software engineering activities to verify compliance with the defined software process
Audits designated software work products to verify compliance with those defined as part of the
software process.
Ensures that deviations in software work and work products are documented and handled
according to a documented procedure.
Records any noncompliance and reports to senior management.

SQA Life Cycle

Prepared By Neelam Rawat

18
Software Quality Frameworks

Prepared By Neelam Rawat

19
ISO 9000 Models vs. SEI-CMM Model
ISO 900(INTERNATIONAL STANDARD
ORGANISATION)
It applies to any type of industry .

CMM is specially developed for software industry

ISO 9000 addresses corporate business process

CMM focuses on the software Engineering activities.

ISO 9000 specifies minimum requirement.

CMM gets nto technical aspect of software engineering.

ISO 9000 restricts itself to what is required.

It suggests how to fulfill the requirements.

ISO 9000 provides pass or fail criteria.

It provides grade for process maturity.

CMM (CABABILITY MATURITY MODEL)

CMM has 5 levels:

ISO 9000 has no levels.

1.

Initial

2.

Repeatable

3.

Defined

4.

Managed

5.

Optimization

ISO 9000 does not specifies sequence of steps required

to establish the quality system.
Certain process elements that are in ISO are not included
in CMM like:

It reconnects the mechanism for step by step progress through

its successive maturity levels.

1.

Contract management

1.

Project tracking

2.

Purchase and customer supplied components

2.

Process and technology change management

3.

Personal issue management

3.

Intergroup coordinating to meet customers requirements

4.

Packaging ,delivery, and installation management

4. Organization level process focus, process development

and integrated management.

Prepared By Neelam Rawat

Similarly other process in CMM are not included in ISO 9000