Software is more than just a program code.

A program is an executable code, which serves some

computational purpose. Software is considered to be collection of executable programming code,
associated libraries and documentations. Software, when made for a specific requirement is
called software product.

Engineering on the other hand, is all about developing products, using well-defined, scientific principles
and methods.
Software Evolution
The process of developing a software product using
software engineering principles and methods is referred to
as software evolution. This includes the initial development
of software and its maintenance and updates, till desired
software product is developed, which satisfies the expected
requirements.
Evolution starts from the requirement gathering process.
After which developers create a prototype of the intended
software and show it to the users to get their feedback at the
early stage of software product development. The users suggest changes, on which several consecutive
updates and maintenance keep on changing too. This process changes to the original software, till the
desired software is accomplished.
Software Development Paradigm
This Paradigm is known as software engineering paradigms where
all the engineering concepts pertaining to the development of
software are applied. It includes various researches and
requirement gathering which helps the software product to build. It
consists of –

 Requirement gathering
 Software design
 Programming
Programming Paradigm
This paradigm is related closely to programming aspect of software development. This includes –

 Coding
 Testing
 Integration
Software Design Paradigm
This paradigm is a part of Software Development and includes –

 Design
 Maintenance
 Programming
Software requirements
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 client’s point of view.
Types of requirements

 business
 user
 Software
o Functional requirements (what a software
system must do or not do) eg If an alarm is
received from a sensor, the system will report
the alarm and halt until the alarm is
acknowledged and cleared.
o Nonfunctional requirements (how the system
must operate or perform) eg The pages of this
web portal must load within 0.5 seconds.
o Domain requirements (Domain requirements can be functional or nonfunctional) eg military,
medical and financial industry sectors
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 ‘System Requirements Specification’ document.
Requirement Engineering Process includes

 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation
Feasibility Study – (All types of feasibility)
When the client approaches the organization for getting the desired product developed, it comes up with
rough idea about what all functions the software must perform and which all features are expected from
the software.
Requirement Gathering (fact finding techniques)
If the feasibility report is positive towards undertaking the project, next phase starts with gathering
requirements from the user. Analysts and engineers communicate with the client and end-users to know
their ideas on what the software should provide and which features they want the software to include.
Requirement Elicitation Process (Extraction)
Requirements Elicitation is the process to find out the requirements for an intended software system by
communicating with client, end users, system users and others who have a stake in the software system
development.

 Interviews
 Surveys
 Questionnaires
 Task analysis
 Domain Analysis
 Brainstorming
 Prototyping
 Observation
Requirements elicitation Activities

 Knowledge of the overall area where the systems is applied.

 The details of the precise customer problem where the system are going to be applied must be
understood.
 Interaction of system with external requirements.
 Detailed investigation of user needs.
 Define the constraints for system development.
Requirements elicitation Methods:
1. Interviews:
Objective of conducting an interview is to understand the customer’s expectations from the software. It is
impossible to interview every stakeholder hence representatives from groups are selected based on their
expertise and credibility.
Interviews maybe be open-ended or structured.
In open-ended interviews there is no pre-set agenda. Context free questions may be asked to understand
the problem.
In structured interview, agenda of fairly open questions is prepared. Sometimes a proper questionnaire is
designed for the interview.
2. Brainstorming Sessions:
It is a group technique. It is intended to generate lots of new ideas hence providing a platform to share
views. A highly trained facilitator is required to handle group bias and group conflicts. Every idea is
documented so that everyone can see it. Finally, a document is prepared which consists of the list of
requirements and their priority if possible.
3. Facilitated Application Specification Technique:
It’s objective is to bridge the expectation gap – difference between what the developers think they are
supposed to build and what customers think they are going to get. A team oriented approach is developed
for requirements gathering. Each attendee is asked to make a list of objects that are-

 Part of the environment that surrounds the system

 Produced by the system
 Used by the system
Each participant prepares his/her list, different lists are then combined, redundant entries are eliminated,
team is divided into smaller sub-teams to develop mini-specifications and finally a draft of specifications is
written down using all the inputs from the meeting.
4. Quality Function Deployment:
In this technique customer satisfaction is of prime concern, hence it emphasizes on the requirements
which are valuable to the customer.
Normal requirements –
In this the objective and goals of the proposed software are discussed with the customer. Example –
normal requirements for a result management system may be entry of marks, calculation of results, etc
Expected requirements –
These requirements are so obvious that the customer need not explicitly state them. Example – protection
from unauthorized access.
Exciting requirements –
It includes features that are beyond customer’s expectations and prove to be very satisfying when present.
Example – when unauthorized access is detected, it should backup and shutdown all processes.
The major steps involved in this procedure are –

 Identify all the stakeholders, eg. Users, developers, customers etc

 List out all requirements from customer.
 A value indicating degree of importance is assigned to each requirement.
 In the end the final list of requirements is categorized as –
 It is possible to achieve
 It should be deferred and the reason for it
 It is impossible to achieve and should be dropped off
5. Use Case Approach:
This technique combines text and pictures to provide a better understanding of the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a functional view of
the system.

Software Requirement Specification (SRS)

SRS is a document created by system analyst after the requirements are collected from various
stakeholders. SRS defines how the intended software will interact with hardware, external interfaces, speed
of operation, response time of system, portability of software across various platforms, maintainability,
speed of recovery after crashing, Security, Quality, Limitations etc.

 The requirements received from client are written in natural language.

 It is the responsibility of system analyst to document the requirements in technical language so
that they can be comprehended and useful by the software development team.
 Software Requirement Specification
 User Requirements are expressed in natural language.
 Technical requirements are expressed in structured language, which is used inside the
organization.
 Design description should be written in Pseudo code.
 Format of Forms and GUI screen prints.
 Conditional and mathematical notations for DFDs etc.
Why SRS

 In order to fully understand one’s project, it is very important that they come up with an SRS listing
out their requirements, how are they going to meet them and how will they complete the project.
 It helps the team to save upon their time as they are able to comprehend how are going to go
about the project.
 Doing this also enables the team to find out about the limitations and risks early on.
Characteristics of Good SRS

 Correctness:
User review is used to ensure the correctness of requirements stated in the SRS. SRS is said to be
correct if it covers all the requirements that are actually expected from the system.
 Completeness:
Completeness of SRS indicates every sense of completion including the numbering of all the pages,
resolving the to be determined parts to as much extent as possible as well as covering all the
functional and non-functional requirements properly.
 Consistency:
Requirements in SRS are said to be consistent if there are no conflicts between any set of
requirements. Examples of conflict include differences in terminologies used at separate places,
logical conflicts like time period of report generation, etc.
 Unambiguousness (clarity):
A SRS is said to be unambiguous if all the requirements stated have only 1 interpretation. Some of the
ways to prevent unambiguousness include the use of modelling techniques like ER diagrams, proper
reviews and buddy checks, etc.
 Ranking for importance and stability:
There should a criterion to classify the requirements as less or more important or more specifically as
desirable or essential. An identifier mark can be used with every requirement to indicate its rank or
stability.
 Modifiability:
SRS should be made as modifiable as possible and should be capable of easily accepting changes to
the system to some extent. Modifications should be properly indexed and cross-referenced.
 Verifiability:
A SRS is verifiable if there exists a specific technique to quantifiably measure the extent to which
every requirement is met by the system. For example, a requirement starting that the system must be
user-friendly is not verifiable and listing such requirements should be avoided.
 Traceability:
One should be able to trace a requirement to design component and then to code segment in the
program. Similarly, one should be able to trace a requirement to the corresponding test cases.
 Design Independence:
There should be an option to choose from multiple design alternatives for the final system. More
specifically, the SRS should not include any implementation details.
 Testability:
A SRS should be written in such a way that it is easy to generate test cases and test plans from the
document.
 Understandable by the customer:
An end user maybe an expert in his/her specific domain but might not be an expert in computer
science. Hence, the use of formal notations and symbols should be avoided to as much extent as
possible. The language should be kept easy and clear.
 Right level of abstraction:
If the SRS is written for the requirements phase, the details should be explained explicitly. Whereas,
 for a feasibility study, fewer details can be used. Hence, the level of abstraction varies according to the
purpose of the SRS.

 Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated.
User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly.
Requirements can be checked against following conditions -

 If they can be practically implemented

 If they are valid and as per functionality and domain of software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated
Requirements verification and validation
Verification is the process of checking that a software achieves its goal without any bugs. It is the process
to ensure whether the product that is developed is right or not. It verifies whether the developed product
fulfills the requirements that we have. Verification is static testing.
Verification means Are we building the product right?
Validation is the process of checking whether the software product is up to the mark or in other words
product has high level requirements. It is the process of checking the validation of product i.e. it checks
what we are developing is the right product. it is validation of actual and expected product. Validation is
the dynamic testing.

Validation means Are we building the right product?

Verification in Software Testing

Verification in Software Testing is a process of checking documents, design, code, and program in
order to check if the software has been built according to the requirements or not.
The main goal of verification process is to ensure quality of software application, design, architecture etc.
The verification process involves activities like reviews, walk-throughs and inspection.
Validation in Software Testing
Validation in Software Engineering is a dynamic mechanism of testing and validating if the software
product actually meets the exact needs of the customer or not.
The process helps to ensure that the software fulfills the desired use in an appropriate environment. The
validation process involves activities like unit testing, integration testing, system testing and user
acceptance testing.
Example
Now, let’s take an example to explain verification and validation planning:
In Software Engineering, consider the following specification for verification testing and validation testing,
A clickable button with name Submet
Verification would check the design doc and correcting the spelling mistake.
Otherwise, the development team will create a button like

So new specification is

A clickable button with name Submit

Once the code is ready, Validation is done. A Validation test found –
Example of Validation
Owing to Validation testing, the development team will make the submit button clickable

Software Testing:
Software testing is an empirical investigation conducted to provide stakeholders with information about the
quality of the product or service under test, with respect to the context in which it is intended to operate. It
is not limited to the process of executing a program or application with the intent of finding software bugs.
Software testing is set of activities that involve planning and preparation of what to test the software for and
executing the software with the intent of finding defects and validating the software against requirements. It
involves operations of a system or application under controlled conditions and abnormal conditions.
Software testing is conducted not only to check if the software meets the functional /technical/security
requirements but also to break the software with negative input or by incorrect usage.
The general testing process that starts with testing of individual program units like functions or objects and
then integrated to subsystem and system, again interaction of these units were tested finally. After delivery
of the system the customer may carry out a series of acceptance tests to check that the system perform as
specified. This model of the testing process is appropriate for large system development but for smaller
system, or for system that are developed through scripting or reuse, there are fewer distinct stages in the
process.
During system testing, the components are integrated to form subsystem or the complete system. At this
stage, system testing should focus on establishing that the system meets its functional and non-functional
requirements, and must not behave in unexpected ways. Defects in earlier testing are discovered during
system testing.
Level of testing
Client needs Acceptance testing

Requirements System Testing

Design Integrated Testing

Code Unit Testing

Software testing process has two distinct goals.
1. To demonstrate to the developer and the customer that the software meets its requirements. At least
one test for every requirement in the user and system requirements documents. For generic
software products there should be test for all the system features that will be incorporated in the
product release.
2. To discovers faults or defects in the software where the behaviour of the software is incorrect,
undesirable or does not conform to its specification. Defect testing is concerned with rooting out all
kinds of undesirable system behaviour such as system crashes. Unwanted interactions with other
system, incorrect computation and data corruption.
3. Systems are not designed as entire systems nor are they tested as single systems. The analyst
must perform both unit and integration testing.

Unit Testing
In unit testing the analyst tests the programs making up a system. (For this reason unit testing is
sometimes called program testing.) The software units in a system are the modules and routines are
assembled and integrated to perform a specific function. In a large system, many modules at different levels
are needed.
Unit testing focuses first on the modules, independently of one another, to locate errors. This enables the
tester to detect errors in coding and logic that are contained within that module alone. Those resulting form
the interaction between modules are initially avoided.

For example, a hotel information system consists of modules to handle reservations; guest check-in and
checkout; restaurant, room service, and miscellaneous charges; convention activities; and accounts
receivable billing. For each, it provides the ability to enter, change, or retrieve data and respond to inquiries
or print reports. The test cases needed for unit testing should exercise each condition and option.
For example, test cases are needed to determine how the system handles attempts to check-in guests who
do and do not have reservations, as well as those instances involving changing the name on the reservation
when a person other than the one listed arrives. Also needed are test cases for the checkout situations of
paying the exact amount of the bill, only part of the bill, and more than the amount shown. Even checking
out without making any payment at all must be included in a test case.

Integration testing
The process of system integration involves building a system from its components and testing the
resultant system for problem that arise from component interactions. The components that are integrated
may be off the shelf components, reusable components or newly developed components. For many large
system all three types to be used. This testing checks that these components actually work together and
transfer right data at the right time across their interfaces

White Box Testing

Using white box testing methods, the software engineer can derive test cases that do the following:

 Guarantee that all independent paths Within a module have been exercised at least once
 Exercise all logical decisions on their true and false sides
 Execute all loops at their boundaries and within their operational bounds and
 Exercise internal data structures to ensure their validity
Black Box Testing

Black box testing methods focus on the functional requirements of the software. It enables the software
engineer to derive sets of input conditions that will fully exercise all functional requirements for a program.
Black box testing is not an alternative to white box testing techniques. Rather, it is a complementary
approach that is likely to uncover a different class of errors than white box methods.

Black box testing method attempts to find errors in the following categories:

 Incorrect or missing functions

 Interface errors
 Errors in data structures or external database access
 Performance errors
 Initialization and termination errors

Black box tests are designed to answer the following questions:

 How is the functional validity tested?

 What classes of input will make good test cases?
 Is the system particularly sensitive to certain input values?
 How are the boundaries of a data class isolated?
 What data rates and data volume can the system tolerate?
 What effect will specific combinations of data have on system operation?

For complex system there are two phases of system testing –

1. Integration testing
The test team have access to the source code of the system . when problem arise the integration
team tries to find the source of the problem and identify the components that have to debugged. It
is mostly concerned with finding defects in the system.
2. Release testing
A version of the system that could be released to users is tested. The test team validates whether
system meets its requirement. It is usually ‘black box’ testing where the test team is simply concerned
with demonstrating that the system does or does not work properly. Problems are reported to
development team who debug the program. In release testing customers are involved, called
acceptance testing.