Software Requirements
• 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
• There are two types
• 1. functional
• 2. Non-functional
2
Functional
• 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. All these
functionalities need to be necessarily incorporated into the
system as a part of the contract.
• For example, in a hospital management system, a doctor
should be able to retrieve the information of his patients
3
Non-functional requirements
• These are basically the quality constraints that the system must satisfy
according to the project contract.
• Nonfunctional requirements, not related to the system functionality,
rather define how the system should perform They basically deal with
issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
4
User-System Requirement Engineering
Process
• It is a four-step process, which includes -
[Link] Study
[Link] Elicitation and Analysis
[Link] Requirement Specification
[Link] Requirement Validation
[Link] Requirement Management
5
6
Feasibility Study:
• The objective behind the feasibility study is to create the reasons for
developing the software that is acceptable to users, flexible to change and
conformable to established standards.
• Types of Feasibility:
[Link] Feasibility - Technical feasibility evaluates the current
technologies, which are needed to accomplish customer requirements
within the time and budget.
[Link] Feasibility - Operational feasibility assesses the range in which
the required software performs a series of levels to solve business
problems and customer requirements.
[Link] Feasibility - Economic feasibility decides whether the necessary
software can generate financial profits for an organization.
7
Requirement Elicitation and Analysis:
• This is also known as the gathering of requirements. Here, requirements are
identified with the help of customers and existing systems processes, if available.
• Analysis of requirements starts with requirement elicitation. The requirements
are analyzed to identify inconsistencies, defects, omission, etc. We describe
requirements in terms of relationships and also resolve conflicts if any.
• Problems of Elicitation and Analysis:
• Getting all, and only, the right people involved.
• Stakeholders often don't know what they want
• Stakeholders express requirements in their terms.
• Stakeholders may have conflicting requirements.
• Requirement change during the analysis process.
• Organizational and political factors may influence system requirements.
8
• This process involves several techniques, such as:
• Interviews: Direct communication with stakeholders to gather information.
• Surveys: Distributing questionnaires to collect opinions and preferences.
• Workshops: Group sessions to brainstorm and gather requirements
collaboratively.
• Observation: Actively observing users to understand their workflow and
needs.
• Prototyping: Building a preliminary version of the software to elicit
feedback.
9
Software Requirement Specification:
• In this phase, the gathered and analyzed requirements are documented
formally. The Software Requirement Specification (SRS) document is
created, which serves as a blueprint for the development process. The SRS
includes the following components:
• Functional Requirements: Descriptions of what the system should do in
terms of specific functions and features.
• Non-functional Requirements: Constraints and qualities the system must
possess (e.g., performance, security).
• User Interfaces: Descriptions of how users will interact with the system.
• Data Requirements: Details about the data the system will store, process,
and manage.
10
Software Requirement Validation
This step involves validating the documented requirements to ensure
they accurately represent the stakeholders' needs and expectations.
The aim is to identify and rectify any errors or misunderstandings
before development begins. Techniques used for requirement
validation include:
1. Reviews: Expert reviews and walkthroughs to identify issues in the SRS.
2. Prototyping: Building a working model of the software to validate
requirements.
3. Simulation: Simulating the software's behavior to test its alignment with
requirements.
11
Software Requirement Management:
Requirement management is an ongoing process that involves
maintaining and tracking changes to requirements throughout the
software development lifecycle. It includes activities such as:
1. Version Control: Managing different versions of the requirements document.
2. Change Control: Managing and documenting changes to requirements and
their impact.
3. Traceability: Establishing links between requirements and design,
implementation, and testing.
4. Prioritization: Assigning priorities to requirements to guide development
efforts.
5. Communication: Ensuring stakeholders are informed about changes and
updates to requirements.
12
Software Prototyping
• Prototyping is defined as the process of developing a working
replication of a product or system that has to be engineered. It
offers a small-scale facsimile of the end product and is used
for obtaining customer feedback.
13
Software Prototyping
14
• Step-1: Requirements gathering and analysis :
• Requirement analysis is the first step in developing a prototyping model.
During this phase, the system’s desires are precisely defined. During the
method, system users are interviewed to determine what they expect
from the system.
• Step-2: Quick design :
The second phase could consist of a preliminary design or a quick design.
During this stage, the system’s basic design is formed. However, it is not
a complete design. It provides the user with a quick overview of the
system. The rapid design aids in the development of the prototype.
• Step-3: Build a Prototype :
During this stage, an actual prototype is intended to support the
knowledge gained from quick design. It is a small low-level working
model of the desired system.
15
• Step-4: Initial user evaluation :
The proposed system is presented to the client for preliminary testing at
this stage. It is beneficial to investigate the performance model’s
strengths and weaknesses. Customer feedback and suggestions are
gathered and forwarded to the developer.
• Step-5: Refining prototype :
If the user is dissatisfied with the current model, you may want to
improve the type that responds to user feedback and suggestions. When
the user is satisfied with the upgraded model, a final system based on the
approved final type is created.
• Step-6: Implement Product and Maintain :
The final system was fully tested and distributed to production after it
was developed to support the original version. To reduce downtime and
prevent major failures, the programmer is run on a regular basis.
16
S/W Documentation
• Software documentation is written text or illustration that provides
information about an application or other software product.
• Documentation for software includes two target viewers: software
engineers and product end users. Documentation in software
engineering refers to information and publications that assist
professionals comprehend the planning, coding, and implementation
of a product.
• This documentation enables developers to comprehend, update, and
customize software from the ground up.
17
Software Documentation Types
• Administrative Records
• Administrative paperwork can comprise project documents such as
guidelines, roadmaps, product specifications, and project information
such as progress reports and meeting notes.
• Documentation for end user/customers : Software for End-User
Documentation Customers documentation is a type of documentation
for processes that explains how to use, install, and configure your
program. Having this type of documentation available helps people
understand how to utilise your programme. User directs, databases of
information, instructions, troubleshooting manuals, reference directs,
and release notes are examples of end-user documentation.
18
• Documentation for Developers
• Developer documentation is the documentation for the product that describes how your
software should function so that developers understand what they're working on. These
papers include build requirements, which describe what the program is expected to
perform, architectural information, which describes the parts and features of the
programs, and checklists, which assist developers through the software development
process.
• Documentation "Just-In-Time"
• The 'just-in-time' (JIT) documentation strategy involves developing documentation as
needed and providing users with support documents at the point of need. It is built on
agile techniques and focuses on customer feedback. If you release a piece of software,
you develop just the necessary amount of documentation rather than a library of
information based on preconceptions about what your consumers need help with. When
your customers have questions or encounter issues, you add the solutions to your
documentation and make those resources available to them in their processes, allowing
them to maintain high productivity and become self-sufficient users of your good.
19
Analysis and modelling Requirement
Elicitation
• We typically start by gathering the requirements, this could be done
through a general discussion or interviews with your stakeholders,
also it may involve some graphical notation.
• Then you organize the related requirements into sub-components
and prioritize them, and finally, you refine them by removing any
ambiguous requirements that may arise from some conflicts.
• Here are the 4 main processes of requirements elicitation and
analysis.
20
21
Software Requirements Specification(SRS)
• Software Requirement Specification (SRS) Format as the name
suggests, is a complete specification and description of requirements of
the software that need to be fulfilled for the successful development of
the software system. These requirements can be functional as well as
non-functional depending upon the type of requirement. The interaction
between different customers and contractors is done because it is
necessary to fully understand the needs of customers.
• Depending upon information gathered after interaction, SRS is developed
which describes requirements of software that may include changes and
modifications that is needed to be done to increase quality of product and
to satisfy customer’s demand.
• NOTE: kindly refer attached document for SRS
22
3Ps Process
• People, Product & Process provide principles for successful
engineering leadership.
• People : People are at the heart of solving problems. Software
engineers, testers, program/project managers, product managers, ux
researchers, technical writers, support engineers, etc make an
engineering team. Organization structures may vary from one
company to the other, but you find these key players in every
software organization. A great investment of money and time should
be hiring, retaining, growing, and coaching talent.
23
Continue..
• Product : Product is any physical device or service that gets the job
done for a customer.
• This includes the objectives, benefits, outcomes, and
deliverables of the project
• Process : Software engineers despise process governance and lately
the increasing trend of blueprints, checklists and dossiers are burning
out engineering teams at the expense of delivering customer value. In
my view process is important if it serves outwardly — delivery of
product features and inwardly — cover all bases from design to
quality to performance and security.
24
Software metrics
• A software metric is a measure of software characteristics which are
measurable or countable. Software metrics are valuable for many
reasons, including measuring software performance, planning work
items, measuring productivity, and many other uses.
25
Types of Software Metrics
• 1. Process Metrics
• Process metrics are used to measure the characteristics of the process of
software development. The example includes the efficiency of detection of fault
and effort of process etc. The characteristics of the methods, tools, and
techniques used for software development can be measured using process
metrics.
• 2. Product Metrics
• The characteristics of the software product are measured using product metrics.
Some of the important characteristics of the software are:
• Software size and complexity
• Software reliability and quality
• Computation of these metrics is done for different stages of the software
development lifecycle.
26
Continue..
• Internal Metrics
• The properties which are of great importance to a software developer can be measured
using the metrics called internal metrics. An example is a measure of Lines of code (LOC).
• External Metrics
• The properties which are of great importance to a user can be measured using the
metrics called external metrics. An example is portability, reliability, usability, etc.
• 3. Project Metrics
• The progress of the project is checked by the project manager using the metrics called
project metrics. Various metrics such as time, cost, etc., are collected by using the data
from the projects in the past, and they are used as an estimate for the new software. The
project manager checks the progress of the project from time to time, and effort, time
and cost are compared with the original effort, time and cost. The cost of development,
efforts, risks and time can be reduced by using these metrics. The quality of the project
can also be improved. With the increase in quality, there is a reduction in the number of
errors, time, cost, etc.
27
Project Estimation
• It is used to examine the analysis model with the objective of
predicting the size of resultant system.
• LOC
• FP
28
LOC Metrics
• It is one of the earliest and simpler metrics for calculating the size of
the computer program. It is generally used in calculating and
comparing the productivity of programmers. These metrics are
derived by normalizing the quality and productivity measures by
considering the size of the product as a metric.
29
Example
void selSort(int x[], int n) {
//Below function sorts an array in ascending order
int i, j, min, temp;
for (i = 0; i < n - 1; i++) {
min = i;
for (j = i + 1; j < n; j++)
if (x[j] < x[min])
min = j;
temp = x[i];
x[i] = x[min];
x[min] = temp;
}
}
So, now If LOC is simply a count of the number of lines then the above function
shown contains 13 lines of code (LOC). But when comments and blank lines are
ignored, the function shown above contains 12 lines of code (LOC).
30
Advantages and Disadvantages
• Advantages of LOC
[Link] to measure
• Disadvantage of LOC
[Link] is defined on the code. For example, it cannot measure the size of the
specification.
[Link] characterizes only one specific view of size, namely length, it takes no
account of functionality or complexity
[Link] software design may cause an excessive line of code
[Link] is language dependent
[Link] cannot easily understand it
31
Functional Point
• It is derived by using a relationship between complexity of software and the
information domain value.
• FPA is used to make estimate of the software project, including its testing in
terms of functionality or function size of the software product. However,
functional point analysis may be used for the test estimation of the product. The
functional size of the product is measured in terms of the function point, which is
a standard of measurement to measure the software application.
• FPs of an application is found out by counting the number and types of functions
used in the applications.
• FP characterizes the complexity of the software system and hence can be used to
depict the project time and the manpower requirement.
• The effort required to develop the project depends on what the software does.
• FP is programming language independent.
32
Types of FP Attribute
Measurements Parameters Examples
[Link] of External Inputs(EI) Input screen and tables
2. Number of External Output (EO) Output screens and reports
3. Number of external inquiries (EQ) Prompts and interrupts.
4. Number of internal files (ILF) Databases and directories
5. Number of external interfaces (EIF) Shared databases and shared routines.
33
The FPA functional units are shown in Fig:
34
Formulas:
Total pages of documentation = technical document + user document
Documentation = Pages of documentation/FP
35
Problem:
• Given the following values, compute function point when all
complexity adjustment factor (CAF) and weighting factors are
average.
• User Input = 50
• User Output = 40
• User Inquiries = 35
• User Files = 6
• External Interface = 4
36
Solution
• Unadjusted Function Point(UFP) = (50*4) + (40*5) + (35*4) + (6*10) +
(4*7) = 628
• As complexity adjustment factor is average (given in question), hence,
scale = 3.
Fi = 14 * 3 = 42
• Function Point = Count-total * [0.65 + 0.01 *∑(fi)]
628*[0.65 + ( 0.01 * 42 ) ]
628 * 1.07 = 671.96
37
Problem 2
• Compute the function point, productivity, documentation, cost per function for the
following data:
[Link] of user inputs = 24
[Link] of user outputs = 46
[Link] of inquiries = 8
[Link] of files = 4
[Link] of external interfaces = 2
[Link] = 36.9 p-m
[Link] documents = 265 pages
[Link] documents = 122 pages
[Link] = $7744/ month
• Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.
38
Solution
39
40
Empirical Estimation Models
• Based on the data taken from previous projects
• There are two types.
• 1. Expert Judgement Technique.
It is the most widely used empirical software estimation technique. In this approach, an
expert makes an executed guess of problem size and hence the effort required after
analyzing the problem thoroughly.
• 2. Delphi Cost Estimation
• The Delphi cost estimation approach overcomes come of the shortcomings of the expert
judgement approach. Delphi estimation is carried out by a group of experts and a
coordinator. Who provides each estimator with a copy of the software requirement
specification(SRS) and a form for recording the cost estimate.
• The estimators after giving their individual estimate submit it to the coordinator who
then prepares and distributes the summary of the responses of all the estimators. In this
process, any unusual rationale is also noted by the coordinator based on this summary
the estimators re-estimate and the process iterates for several rounds. After which the
co-ordinator finally compiles the result of the final estimate.
41
COCOMO-II Model
• COCOMO 2 is another cost-estimating methodology utilized to calculate
the cost of software development. It is a modified version of the
original COCOMO that was developed at the University of Southern
California. It was mainly designed to resolve the shortcomings of the
COCOMO 1 model. Its primary goal is to offer methodologies, quantitative
analytic structure, and tools. It computes the total development time and
effort that is based on the estimates of all individual subsystems.
• It is based on the non-linear reuse formula. This approach assists in
offering estimates that represent one standard deviation of the most
common estimate. Five scale factors define its effort equation exponent,
and it has 17 cost drivers attributed to it. It is useful in the software
development cycle (SDLC) non-sequential, reuse, rapid development, and
reengineering models.
42
COCOMO 2 estimation models
• here are mainly 3 types of COCOMO 2 estimation models. These
models are as follows:
• 1. Application Composition Model
• 2. Early Design Estimation Model
• 3. Post Architecture Estimation
43
1. Application Composition Estimation Model
• Application Composition Estimation Model allows one to
estimate the cost, and effort at stage 1 of the COCOMO II
Model. In this model, size is first estimated using Object Points.
Object Points are easy to identify and count. Object Points
define screen, reports, and third-generation (3GL) modules as
objects
• Used when software is composed from existing parts.
• Focus on those applications which can be quickly developed
using interoperable components.
• Example. GUI, database Manager etc..
44
Steps for Efforts Estimation
• [Link] Object Counts
• Estimate the number of screens, reports and 3GL components
that will comprise this application.
• 2. Classify Complexity Levels of Each Object
• We have to classify each object instance into simple, medium
and difficult complexity level depending on values of its
characteristics. Complexity levels are assigned according to the
given table.
•
45
46
• 3. Assign Complexity Weights to Each Object
• The weights are used for three object types i.e, screens, reports
and 3GL components. Complexity weight are assigned
according to object’s complexity level using following table.
•
47
• 4. Determine Object Points
• Add all the weighted object instances to get one number and
this is known as object point count.
• Object Point = Sigma (number of object instances) *
(Complexity weight of each object instance)
• 5. Compute New Object Points (NOP)
• We have to estimate the %reuse to be achieved in a project.
Depending on %reuse
• NOP = [(object points) * (100 – % reuse)] / 100
• NOP are the object point that will need to be developed and
differ from the object point count because there may be reuse
of some object instance in project.
48
• 6. Calculate Productivity rate (PROD)
• Productivity rate is calculated on the basis of information given
about developer’s experience and capability. For calculating it,
we use following table.
49
7. Compute the estimated Effort
• Effort to develop a project can be calculated as:
• Effort = NOP / PROD
• Effort is measured in person-month.
50
Example
• Consider a database application project with
[Link] application has four screens with four views each and
seven data tables for three servers and four clients.
[Link] may generate two reports of six section each from
seven data tables for two servers and three clients.
3.10% reuse of object points.
[Link]’s experience and capability in similar environment is
low.
• Calculate the object point count, New object point and effort to
develop such project.
51
Solution
Step 1: Number of screens = 4 and Number of records = 2
Step 2: For screens,
Number of views = 4
Number of data tables = 7
Number of servers = 3
Number of clients = 4
By using above given information and table (For Screens), Complexity
level for each screen = medium
For reports,
Number of sections = 6
Number of data tables = 7
Number of servers = 2
Number of clients = 3
By using above given information and table (For Reports),
Complexity level for each report = difficult. 52
Step 3: By using complexity weight table we can assign complexity weight to each
object instance depending upon their complexity level.
Complexity weight for each screen = 2
Complexity weight for each report = 8
Step 4:
Object point count = sigma (Number of object instances) * (its Complexity weight)
= 4 * 2 + 2 * 8 = 24
Step 5:
%reuse of object points = 10% (given)
NOP = [object points * (100 – %reuse)] / 100
= [24 * (100 -10)]/100 = 21.6
53
Step 6:
Developer’s experience and capability is low (given) Using information given about
developer and productivity rate table
Productivity rate (PROD) of given project = 7
Step 7:
Effort = NOP / PROD
= 21.6/7
= 3.086 person-month
Therefore, effort to develop the given project = 3.086 person-month.
54
Example 2
55
Answer
56
2. Early Design Model : COCOMO-II
• Used when requirements are available but design has not yet started
• It is used at the Stage – II in COCOMO -II models and supports estimation in
early design stage of project. Base equation used in COCOMO – II models is
as follows –
• PMnominal = A * (size)B
• where PMnominal = Effort for the project in person months
• A = constant representing the nominal productivity where A = 2.5
• B = Scale Factor
• Size = size of the Software
• The early design model uses Unadjusted Function Points (UFP) as measure
of size.
57
3. Post Architecture Estimation
• It supports estimation in the post architecture stage of a
project. For this it uses Post Architecture Estimation Model.
This model is used after the completion of the detailed
architecture of application generator, infrastructure, system
integration.
• Master Software Testing and Automation in an efficient and
time-bound manner by mentors with real-time industry
experience.
58