2. • According to IEEE standard 729, a requirement is defined as
follows:
• A condition or capability needed by a user to solve a
problem or achieve an objective
• A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard,
specification or other formally imposed documents
• A documented representation of a condition or capability as
in 1 and 2.
3. A software requirement can be of 3 types:
• Functional requirements
• Non-functional requirements
• Domain requirements
4. Functional Requirements:
These are the requirements that the end user
specifically demands as basic facilities that the system should
offer. It can be a calculation, data manipulation, business
process, user interaction, or any other specific functionality
which defines what function a system is likely to perform.
5. Non-functional requirements:
These are basically the quality constraints that the system
must satisfy according to the project contract
They basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
6. • Domain requirements: Domain requirements are the
requirements which are characteristic of a particular
category or domain of projects. Domain requirements can
be functional or nonfunctional. Domain requirements
engineering is a continuous process of proactively defining
the requirements for all foreseeable applications to be
developed in the software product line. The basic functions
that a system of a specific domain must necessarily exhibit
come under this category.
• For example, in an academic software that maintains
records of a school or college, the functionality of being able
to access the list of faculty and list of students of each grade
is a domain requirement. These requirements are therefore
identified from that domain model and are not user specific.
8. • Feasibility Study
The main aim of a feasibility study is to create reasons
for the development of the software that the users accept,
that is flexible enough and open to changes, and abide by
the standards chosen for software development and
maintenance.
• Elicitation of Requirements and Analysis
This process is also called requirements gathering. If
there are any existing processes available and with the help
of customers, requirements gathering is done. Elicitation of
requirements is the starting step of requirements analysis.
9. Specification of Software Requirements
• A document consisting of requirements that are collected
from various sources like the requirements from customers
expressed in an ordinary language and created by the
software analyst is called a specification document for
software requirements.
• Several models are used during the process of specification
of software requirements like Entity-Relationship
diagrams (ER diagrams), data flow diagrams (DFD), data
dictionaries, function decomposition diagrams (FDD),
etc.
10. • Data Flow Diagrams (DFD): The modeling of requirements
can be done using Data Flow Diagrams (DFD). The flow of
data within the system can be seen by using data flow
diagrams (DFD).
The data flow diagrams (DFD) are also called bubble
charts or data flow graph.
11. • Data Dictionaries: The data defined using a data flow
diagram (DFD) is stored as information in the form of
repositories called data dictionaries
• Entity Relationship Diagrams: One of the other tools used
for the specification of requirements is entity-relationship
diagrams. It is also called as ER diagrams
12. • Validation of Software Requirements
• After the development of the specification of requirements,
the requirements laid down in the document are validated.
• The requirements must satisfy the following conditions:
• If the requirements can be implemented practically.
• If the requirements are correct and they are according to
the software functionality.
• If there are any confusions.
• If the requirements are full.
• If the requirements can be described.
13. • There are several techniques for the validation of
requirements
• Inspection of requirements or reviews of requirements.
• Prototyping
• Generation of test case
• Automated consistency analysis
14. • Management of Software Requirements
• The process of managing the requirements that keep
changing during the process of requirements engineering
and development of the system is called management of
software requirement
15. Project size estimation techniques
• Project size estimation is a crucial aspect of software engineering, as it helps in
planning and allocating resources for the project. Here are some of the popular
project size estimation techniques used in software engineering:
• Expert Judgment: In this technique, a group of experts in the relevant field estimates the
project size based on their experience and expertise. This technique is often used when
there is limited information available about the project.
• Analogous Estimation: This technique involves estimating the project size based on the
similarities between the current project and previously completed projects. This technique
is useful when historical data is available for similar projects.
• Bottom-up Estimation: In this technique, the project is divided into smaller modules or
tasks, and each task is estimated separately. The estimates are then aggregated to arrive at
the overall project estimate.
16. • Three-point Estimation: This technique involves estimating
the project size using three values: optimistic, pessimistic,
and most likely. These values are then used to calculate the
expected project size using a formula such as the PERT
formula.
• Program Evaluation Review Technique (PERT) is a project
management planning tool used to calculate the amount of time it
will take to realistically finish a project.
17. • Function Points: This technique involves estimating the
project size based on the functionality provided by the
software. Function points consider factors such as inputs,
outputs, inquiries, and files to arrive at the project size
estimate.
18. • Use Case Points: This technique involves estimating the project size
based on the number of use cases that the software must support.
Use case points consider factors such as the complexity of each use
case, the number of actors involved, and the number of use cases.
• Estimation of the size of the software is an essential part of Software
Project Management. It helps the project manager to further predict
the effort and time which will be needed to build the project. Various
measures are used in project size estimation. Some of these are:
• Lines of Code
• Number of entities in ER diagram
• Total number of processes in detailed data flow diagram
• Function points
19. • 1. Lines of Code (LOC): As the name suggests, LOC count
the total number of lines of source code in a project. The
units of LOC are:
• KLOC- Thousand lines of code
• NLOC- Non-comment lines of code
• KDSI- Thousands of delivered source instruction
2. Number of entities in ER diagram:
3. Total number of processes in detailed data flow
diagram
4. Function Point Analysis
20. CLASSIFICATION OF SOFTWARE
On the basis of application:
System Software –
System Software is necessary to manage the computer resources
and support the execution of application programs. Software like
operating systems, compilers, editors and drivers, etc., come under
this category.
Application Software –
Application software is designed to fulfill the user’s requirement by
interacting with the user directly. It could be classified into two
major categories:- generic or customized
21. • Networking and Web Applications Software –
Networking Software provides the required support necessary for
computers to interact with each other and with data storage facilities.
Networking software is also used when software is running on a
network of computers (such as the World Wide Web).
• Reservation Software –
A Reservation system is primarily used to store and retrieve
information and perform transactions related to air travel, car rental,
hotels, or other activities. They also provide access to bus and railway
reservations, although these are not always integrated with the main
system
22. Business Software –
This category of software is used to support business
applications and is the most widely used category of
software. Examples are software for inventory management,
accounts, banking, hospitals, schools, stock markets, etc.
Entertainment Software –
Education and entertainment software provides a powerful
tool for educational agencies, especially those that deal with
educating young children
23. • Artificial Intelligence Software –
Software like expert systems, decision support systems, pattern
recognition software, artificial neural networks, etc. come under
this category.
• Scientific Software –
Scientific and engineering software satisfies the needs of a
scientific or engineering user to perform enterprise-specific tasks.
Such software is written for specific applications using principles,
techniques, and formulae particular to that field. Examples are
software like MATLAB, AUTOCAD, PSPICE, ORCAD, etc.
24. • Utilities Software –
The programs coming under this category perform specific
tasks and are different from other software in terms of size,
cost, and complexity
• Document Management Software –
Document Management Software is used to track, manage
and store documents in order to reduce the paperwork
25. • On the basis of copyright:
Commercial –
It represents the majority of software that we purchase from
software companies, commercial computer stores, etc
• Shareware –
Shareware software is also covered under copyright but the
purchasers are allowed to make and distribute copies with
the condition that after testing the software, if the
purchaser adopts it for use, then they must pay for it.
26. • Freeware –
In general, according to freeware software licenses, copies of the
software can be made both for archival and distribution purposes but
here, distribution cannot be for making a profit. Derivative works and
modifications to the software are allowed and encouraged
• Public Domain –
In the case of public domain software, the original copyright holder
explicitly relinquishes all rights to the software. Hence software
copies can be made both for archival and distribution purposes with
no restrictions on distribution. Modifications to the software and
reverse engineering are also allowed.
27. SOFTWARE TESTING
Software testing can be stated as the process of verifying and
validating whether a software or application is bug-free,
meets the technical requirements as guided by its design and
development, and meets the user requirements effectively
and efficiently by handling all the exceptional and boundary
cases.
28. • Software testing can be divided into two steps:
1. Verification: it refers to the set of tasks that ensure that
the software correctly implements a specific function.
• 2. Validation: it refers to a different set of tasks that ensure
that the software that has been built is traceable to
customer requirements.
• Verification: “Are we building the product right?”
Validation: “Are we building the right product?”
29. • Manual Testing: Manual testing includes testing software
manually, i.e., without using any automation tool or any
script. In this type, the tester takes over the role of an end-
user and tests the software to identify any unexpected
behavior or bug.
• Automation Testing: Automation testing, which is also
known as Test Automation, is when the tester writes scripts
and uses another software to test the product. This process
involves the automation of a manual process
30. • Software testing techniques can be majorly classified into
two categories:
• 1. Black Box Testing: The technique of testing in which the
tester doesn’t have access to the source code of the
software and is conducted at the software interface without
any concern with the internal logical structure of the
software is known as black-box testing.
• 2. White-Box Testing: The technique of testing in which the
tester is aware of the internal workings of the product, has
access to its source code, and is conducted by making sure
that all internal operations are performed according to the
specifications is known as white box testing.
31. Black Box Testing White Box Testing
Internal workings of an application are not required. Knowledge of the internal workings is a must.
Also known as closed box/data-driven testing. Also known as clear box/structural testing.
End users, testers, and developers. Normally done by testers and developers.
This can only be done by a trial and error method.
Data domains and internal boundaries can be better
tested.
32. Different levels of software testing
Unit Testing: A level of the software testing process where
individual units/components of a software/system are tested.
Integration Testing: A level of the software testing process
where individual units are combined and tested as a group.
System Testing: A level of the software testing process where
a complete, integrated system/software is tested
33. • Acceptance Testing: A level of the software testing process
where a system is tested for acceptability. The purpose of
this test is to evaluate the system’s compliance with the
business requirements and assess whether it is acceptable
for delivery.
34. Grey Box Testing
• While white box testing assumes the tester has complete
knowledge, and black box testing relies on the user’s
perspective with no code insight, grey box testing is a
compromise. It tests applications and environments with
partial knowledge of internal workings. Grey box testing is
commonly used for penetration testing, end-to-end system
testing, and integration testing.
35. Functional Testing
• Black box testing can test specific functions or features of the software under test.
For example, checking that it is possible to log in using correct user credentials, and
not possible to log in using wrong credentials.
• Functional testing can focus on the most critical aspects of the software
Examples of Functional Testing are:
• Unit Testing
• Smoke Testing- is a software testing method that is used to determine if a new
software build is ready for the next testing phase
• Sanity Testing - Sanity testing is a subset of regression testing. After receiving the
software build, sanity testing is performed to ensure that the code changes
introduced are working as expected
• Integration Testing
• User Acceptance Testing
37. Non-Functional Testing
• Black box testing can check additional aspects of the software, beyond features and
functionality. A non-functional test does not check “if” the software can perform a specific action
but “how” it performs that action.
1. Performance Tests: Performance testing checks how well software components work
• This is typically done by:
• Measuring response times
• Identifying bottlenecks
• Locating failure points
2. Load Tests
Load testing checks how the software behaves under both normal and peak conditions. This is
done to determine how much work load the software can handle before performance is
negatively affected.
3. Stress Tests
Stress testing checks how the software behaves under abnormal conditions. This determines the
limit at which the software will break.
39. Techniques of black box testing
• Volume Tests
Volume testing serves to verify what happens to system
performance when a huge volume of data is added to the
database. This is done to identify what problems may occur
with increasing volumes of data. It’s also known as flood
testing.
Security Tests
• Security testing checks software to find flaws or
vulnerabilities that may compromise data
40. Upgrade and Installation Tests
• Upgrade testing and installation testing verify that software
will work properly on everyone’s machines.
Recovery Tests
• Recovery tests determine how quickly software can rebound
after a crash or failure
41. What is Regression Testing?
• Regression testing is a black box testing techniques. It is
used to authenticate a code change in the software does not
impact the existing functionality of the product. Regression
testing is making sure that the product works fine with new
functionality, bug fixes, or any change in the existing
feature.
42. Coupling
Coupling refers to the degree of interdependence between software modules. High
coupling means that modules are closely connected and changes in one module may affect
other modules. Low coupling means that modules are independent and changes in one
module have little impact on other modules.
43. Data Coupling: If the dependency between the modules is based on the fact that they communicate
by passing only data
Stamp Coupling:In stamp coupling, the complete data structure is passed from one module to
another module.
Control Coupling: If the modules communicate by passing control information, then they are said to
be control coupled
External Coupling: In external coupling, the modules depend on other modules, external to the
software being developed or to a particular type of hardware. Ex- protocol, external file, device
format, etc.
Common Coupling: The modules have shared data such as global data structures
Content Coupling: In a content coupling, one module can modify the data of another module, or
control flow is passed from one module to the other module. This is the worst form of coupling and
should be avoided.
44. • Cohesion: Cohesion is a measure of the degree to which the elements
of the module are functionally related. It is the degree to which all
elements directed towards performing a single task are contained in
the component. Basically, cohesion is the internal glue that keeps the
module together.
47. Software Maintenance
Corrective maintenance: This involves fixing errors and bugs in the
software system.
Adaptive maintenance: This involves modifying the software system to
adapt it to changes in the environment, such as changes in hardware or
software.
Perfective maintenance: This involves improving the functionality,
performance, and reliability of the software system.
Preventive maintenance: This involves taking measures to prevent future
problems, such as updating documentation, reviewing and testing the
system, and implementing preventive measures such as backups.
