Unit -II

Requirement Analysis
Project Estimation and Planning

Focuses on

The manager and software team must estimate the work to be done,
and the time that will elapse from start to finish.

1
Requirement Analysis

Prof. Rohini Joshi 2

 Requirements Analysis (requirements engineering)
Requirements analysis (requirements engineering) is the process of
determining user expectations for a new or modified product. It is usually a
team effort and demands a variety of human soft skills, such as critical thinking,
communication, and judgment.

At the start of every software project, the project team must understand,
finalize, and document the features and functionalities required of the end
product. These required features and functionalities are often called functional
specifications, and the process of determining and understanding them is
called requirements gathering and analysis.

Requirements must be quantifiable, as detailed as possible, and relevant to the

end product. In addition, they should be clearly documented so the
development team has clear expectations and understands the required
specifications from the beginning.

3
 Requirements analysis in software engineering does
the following:

• Clarifies the required features and overall vision of a

new product.
• Clarifies stakeholder expectations for that product.
• Prevents conflict and communication gaps during
development and testing.
• Ensures that the final product conforms to
requirements

4
5
Requirements analysis process :
Requirements analysis is a multistage process that involves the
following steps.
1. Understand the key stakeholders and end users
2. Understand the project goal
3. Capture requirements
4. Categorize requirements
• Functional requirements.
• Technical requirements.
• Transitional requirements.
• Operational requirements.

5. Interpret and document requirements

6. Finalize SRS and get sign-off on requirements
6
Functional Requirements:
•Focus on the "what" of the system - the specific actions and features the user
needs to perform.
•Examples: "The user must be able to log in with their username and password,"
"The system should calculate the total order amount automatically."

Technical Requirements:
•Focus on the "how" of the system implementation.
•Examples: "The application will be developed using Java," "The database must be
able to handle 1 million concurrent users."

Transitional Requirements:
•Address the process of moving from the old system to the new one.
•Examples: "Data migration plan from the legacy system," "User training program
for the new interface"

Operational Requirements:
•Define the conditions under which the system will function.
•Examples: "The system must be available 24/7," "The response time should be
under 2 seconds," "The system must be able to operate in a network with limited
bandwidth."
7
 Software Requirement Specification (SRS) document
• Software Requirement Specification (SRS)
document, is a complete specification and
description of requirements of the software that
need to be fulfilled.

• 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.
8
 Uses of SRS document :
• The development team requires it for developing products
according to the need.
• Test plans are generated by the testing group based on the
described external behavior.
• Maintenance and support staff need to understand what the
software product is supposed to do.
• Project manager base their plans and estimates of schedule,
effort, and resources on it.
• Customers rely on it to know what product they can expect.
• As a contract between developer and customer.
9
 Content of SRS document

1. Introduction
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices

10
1. Introduction
• Purpose of this Document – At first, the main aim of why this
document is necessary and what purpose of the document is
explained and described.

• Scope of this document – In this, the overall working and

main objective of the document and what value it will
provide to the customer is described and explained. It also
includes a description of the development cost and time
required.

• Overview – In this, the description of the product is

explained. It’s simply a summary or overall review of the
product.
Prof. Rohini Joshi 11
2. General description
In this, the general functions of the product which include the objective of the user, a user
characteristic, features, and benefits, about why its importance is mentioned. It also
describes the features of the user community.

3. Functional Requirements
• In this, the possible outcome of the software system which includes effects due to the
operation of the program is fully explained. All functional requirements which may
include calculations, data processing, etc. are placed in a ranked order.

• Functional requirements specify the expected behavior of the system outputs that
should be produced from the given inputs. They describe the relationship between the
input and output of the system. For each functional requirement, a detailed
description of all the data inputs and their source, the units of measure, and the range
of valid inputs must be specified.

12
4. Interface Requirements
In this, software interfaces which mean how software program communicates
with each other or users either in the form of any language, code, or message are
fully described and explained. Examples can be shared memory, data streams, etc.

5. Performance Requirements
In this, how a software system performs desired functions under specific
conditions is explained. It also explains required time, required memory,
maximum error rate, etc.
The performance requirements part of an SRS specifies the performance
constraints on the software system. All the requirements relating to the
performance characteristics of the system must be clearly specified. There are
two types of performance requirements: static and dynamic. Static requirements
are those that do not impose constraints on the execution characteristics of the
system. Dynamic requirements specify constraints on the execution behavior of
the system.

13
6. Design Constraints
In this, constraints which simply means limitation or restriction are specified and
explained for design team. Examples may include use of a particular algorithm, hardware
and software limitations, etc. There are a number of factors in the client’s environment
that may restrict the choices of a designer leading to design constraints such factors
include standards that must be followed resource limits, operating environment,
reliability and security requirements, and policies that may have an impact on the design
of the system. An SRS should identify and specify all such constraints.

7. Non-Functional Attributes
In this, non-functional attributes are explained that are required by software system for
better performance. An example may include Security, Portability, Reliability, Reusability,
Application compatibility, Data integrity, Scalability capacity, etc.

8. Preliminary Schedule and Budget

In this, the initial version and budget of the project plan are explained which include the
overall time duration required and overall cost required for the development of the
project.

9. Appendices
In this, additional information like references from where information is gathered, and
definitions of some specific terms, acronyms, abbreviations, etc. are given and explained.
Functional vs. Non Functional Requirements
Functional Requirements:

• These are the requirements that the end user specifically demands as
basic facilities that the system should offer. All these functionalities
need to be necessarily incorporated into the system as a part of the
contract.
• These are represented or stated in the form of input to be given to the
system, the operation performed and the output expected.
• They are the requirements stated by the user which one can see
directly in the final product, unlike the non-functional requirements.

Examples:
• What are the features that we need to design for this system?
• What are the edge cases we need to consider, if any, in our design?

16
Non-Functional Requirements:
These are the quality constraints that the system must satisfy according to the project
contract. The priority or extent to which these factors are implemented varies from
one project to another. They are also called non-behavioral requirements. They deal
with issues like:
Portability, Security, Maintainability, Reliability, Scalability, Performance
Reusability, Flexibility

Examples:
• Each request should be processed with the minimum latency
• The system should be highly valuable

17
Examples of Functional and Non-functional Requirements
1. Online Banking System
1. Functional Requirements:
• Users should be able to log in with their username and password.
• Users should be able to check their account balance.
• Users should receive notifications after making a transaction.
2. Non-functional Requirements:
• The system should respond to user actions in less than 2 seconds.
• All transactions must be encrypted and comply with industry security standards.
• The system should be able to handle 100 million users with minimal downtime.

2. Food Delivery App

1. Functional Requirements
• Users can browse the menu and place an order.
• Users can make payments and track their orders in real time.
2. Non-functional Requirements:
• The app should load the restaurant menu in under 1 second.
• The system should support up to 50,000 concurrent orders during peak hours.
• The app should be easy to use for first-time users, with an intuitive interface.
18
 How to Gather Functional and Non-functional Requirements

1. Functional Requirements:

• Interviews: Talk to stakeholders or users to understand their needs.

• Surveys: Distribute questionnaires to gather input from a larger audience.
• Workshops: Host sessions to brainstorm features and gather feedback.

2. Non-functional Requirements:

• Performance Benchmarks: Consult with IT teams to set expectations for

performance and load.
• Security Standards: Consult with security experts to define the best
practices for data protection.
• Usability Testing: Test the system to find areas where users might struggle
and refine the interface.

19
Differences between Functional Requirements and Non-Functional Requirements:

Aspect Functional Requirements Non-Functional Requirements

Describes what the system should do, Describes how the system should perform, i.e.,
Definition
i.e., specific functionality or tasks. system attributes or quality.
Focuses on the behavior and features Focuses on the performance, usability, and other
Purpose
of the system. quality attributes.
Defines the actions and operations of Defines constraints or conditions under which
Scope
the system. the system must operate.
User authentication, data Scalability, security, response time, reliability,
Examples
input/output, transaction processing. maintainability.
Easy to measure in terms of outputs or More difficult to measure, often assessed using
Measurement
results. benchmarks or SLAs.
Drives the core design and Affects the architecture and overall performance
Impact on Development
functionality of the system. of the system.
Directly related to user and business Focuses on user experience and system
Focus on User Needs
requirements. performance.
Typically documented in use cases, Documented through performance criteria,
Documentation
functional specifications, etc. technical specifications, etc.
Can be tested through functional Evaluated through performance testing, security
Evaluation
testing (e.g., unit or integration tests). testing, and usability testing.
Determines what the system must do Depends on how well the system performs the
Dependency
to meet user needs. required tasks.
20
 Project
Planning and Estimation

21
Your attempt to determine
 How much money
 How much effort
 How much resources
 How much time
it will take to build a specific software-based system
or product
 Project Size

 Project Complexity

 Degree of structural uncertainty

 The objective of project planning is to provide the
framework that enables the manager to make
reasonable estimates of resources, cost and
schedule

 This estimate was made at the beginning of the

project and updated regularly as the project
progresses

 Estimate should attempt to define best-case and

worst-case scenario so that the project outcome can
be bounded
- This is the first activity of project planning

- Software scope describes the data and the control to be

processed, function, performance, constraints, interfaces,
and reliability

 Obtaining information necessary for Scope

- Data to be collected by asking context free question
suggested by Gause & Weinberg
 Feasibility
- Software feasibility has four dimension
Technology, Finance, Time, Resources
- The second software planning task is the
estimation of resources

- Each resource is specified with four characteristics

- - Description of the resources
- - Statement of availability
- - Time when resources will required
- - Duration of time that resources will be applied
 Human resources
 Reusable software resources: Bennatan
suggest four S/W resources.
- Off the shelf components
- Full Experience component
- Partial Experience component
- New components

 Environmental resources
1. If off-the-shelf components meet project
requirements, acquire them because they are
less expensive and also have low risks.

2. If fully experienced components are available, the

risks associated with modification and
integration are generally acceptable.

3. If partial components are available, their use for

the current project must be analyzed.
To achieve reliable cost and efforts estimation ,a
following options are available

 Delay estimation until late in the project

 Base estimation on similar projects that have already

been completed

 Use relatively simple decomposition technique to

generate project cost and effort estimation

 Use one or more empirical models for software cost and

efforts estimation
 Software sizing :
The accuracy of a software project estimate is predicted on
following things:
1. The degree to which the planner properly estimated the size of
the product to be built
2. The ability to translate the size estimate into human efforts,
time, and cost
3. The degree to which the project plan reflects the abilities of
the software team
4. The stability of product requirements and the environment
that supports the software engineering efforts.
 Software sizing :
Putnam and Myers suggest four different approaches
to the sizing problem
1) “Fuzzy logic” sizing
2) Function point sizing
3) Standard component sizing
4) Change sizing
The result of these methods create “three-point” or
“expected value” estimate
This is accomplished by developing optimistic(low), most
likely and pessimistic( high) value for size
 Software Measurement:
➢ A measurement is the size, quantity, amount, or dimension
of a particular attribute of a product or process.

➢ Software measurement is a characteristic of a software

product or the software process.

➢ The software measurement process is defined and governed

by ISO Standard.

32
Software Measurement Principles :
The software measurement process can be characterized by five
activities-
• Formulation: The derivation of software measures and
metrics appropriate for the representation of the software
that is being considered.
• Collection: The mechanism used to accumulate data required
to derive the formulated metrics.
• Analysis: The computation of metrics and the application of
mathematical tools.
• Interpretation: The evaluation of metrics results in insight into
the quality of the representation.
• Feedback: Recommendation derived from the interpretation
of product metrics transmitted to the software team.
Need for Software Measurement:
Software is measured to:
➢ Create the quality of the current product or process.
➢ Anticipate future qualities of the product or process.
➢ Enhance the quality of a product or process.
➢ Regulate the state of the project concerning budget and
schedule.
➢ Enable data-driven decision-making in project planning and
control.
➢ Identify bottlenecks and areas for improvement to drive
process improvement activities.
➢ Ensure that industry standards and regulations are followed.
➢ Give software products and processes a quantitative basis for
evaluation.
➢ Enable the ongoing improvement of software development
practices.
34
Classification of Software Measurement
There are 2 types of software measurement:

Direct Measurement:
• In direct measurement, the product, process, or thing is
measured directly using a standard scale.
• Example it includes cost & efforts applied and also includes
lines of codes (LOC), execution speed, and memory size.

Indirect Measurement:
• In Indirect measurement, the quantity or quality is to be
measured using related parameters i.e. by use of reference.
• Example it includes functionality, quality, complexity,
efficiency, reliability, & maintainability.

35
Software Metric:

➢ A metric is a measurement of the level at which any impute

belongs to a system product or process.

➢ Software metrics is a quantifiable or countable assessment of

the attributes of a software product.

➢ There are 4 functions related to software metrics:

➢ Planning
➢ Organizing
➢ Controlling
➢ Improving

36
Characteristics of software Metrics
➢ Quantitative: Metrics must possess a quantitative nature. It
means metrics can be expressed in numerical values.
➢ Understandable: Metric computation should be easily
understood, and the method of computing metrics should be
clearly defined.
➢ Applicability: Metrics should be applicable in the initial phases
of the development of the software.
➢ Repeatable: When measured repeatedly, the metric values
should be the same and consistent in nature.
➢ Economical: The computation of metrics should be economical.
➢ Language Independent: Metrics should not depend on any
programming language.

37
Classification of Software Metrics:
There are 3 types of software metrics: Product, Process, Project

Product Metrics:
These are the measures of various characteristics of the software product.
The two important software characteristics are:
• Size and complexity of software.
• Quality and reliability of software.

Process Metrics:
• Process metrics pay particular attention to enhancing the long-term process
of the team or organization. These metrics are used to optimize the
development process and maintenance activities of software.
• Examples include effort variance, schedule variance, defect injection rate,
and lead time.

38
Project Metrics:
The project metrics describe the characteristics and execution of a
project.

Examples include effort estimation accuracy, schedule deviation,

cost variance, and productivity.
Usually measures-
• Number of software developer
• Staffing patterns over the life cycle of software
• Cost and schedule
• Productivity

39
Size-Oriented Metrics
Size-oriented metrics are derived by normalizing quality and
productivity measures by considering the size of the software
that has been produced.
A simple set of size measures :

Size = Kilo Lines of Code (KLOC)

Effort = Person/month
Productivity = KLOC / person-month
Quality = Number of faults / KLOC
Cost = $ / KLOC
Documentation = Pages of documentation / KLOC

40
• Problem based estimation technique

i) LOC based estimation

ii) FP based estimation

• Process based estimation technique

LOC & FP parameters are used for estimation
 LOC and FP parameter used in two way
i) as an estimation variable to “size”
ii) as baseline metrics collected from past project
 A three point or expected value can be computed using
three factors (Optimistic(Sopt),most likely(Sm),pessimistic(Spess))
S=( Sopt + 4Sm + Spess) / 6
 Once the expected value for the estimation has been
determined, historical LOC or FP productivity data are
applied
 • Uses LOC for estimation value
• Example of CAD software system for LOC based estimation
• Following are the major software function for CAD Software
system
• For 3D Geometric Estimated LOC is 6800
S= ( 4600 + 4*6900 + 8600) /6 = 6800
• Review of historic data – 620 LOC/ Month
• Labor rate of $8000 / Month
• Cost per Line is 8000 /620 = $13
• So total cost is = 33200 * 13 = $431600
Estimated effort = 33200/620 = 54 Person / Month
• Estimating information domain value for CAD system
Σ (Fi) = 53.17
 Finally Estimated number is derived
 FPestimated = Count _total X [ 0.65 + 0.01 X S ( Fi ) ]
FPestimated = 320 X [ 0.65 + 0.01 X 53.17) ]
= 375
 The organizational Productivity for this type of system is 6.5FP/Month
 Labor rate $8000 / Month
 The cost per FP is approx - 8000/6.5= $1230
 Total estimated project cost is = FPestimated * cost per FP
= 375 * 1230
= $461538
 Estimated efforts required is = FPestimated /6.5
= 375 / 6.5
= 58 Person / Month
• Using average labor rate of $8000 / month
• Estimated project cost is = $8000 X 46 = $368000
• Estimated efforts is 46 person / month
 Reactive Risk Strategies
- the software team does nothing about risk until something
goes wrong
- Called fire fighting mode
- when this fails “crisis management” takes over the project
 Proactive Risk Strategies
- Potentially risk is identified, their probability and
impact are assessed and they are ranked by
importance
- The software team establishes a plan for managing
risk
 Risk always involve two characteristics
1. Uncertainty
2. Loss

Types of risk :
 Project risk
 Technical risk
 Business risk

 Known or predictable risk

 Unpredictable risk
 Step 1 - Risk Identification
 Step 2 - Risk Projection
 Step 3 - Risk Refinement
 Step 4 - Risk Mitigation, Monitoring ,&
Management
 Generic risk
 Product specific risk
Risk item checklist
 Product size
 Business impact
 Customer characteristics
 Process definition
 Development environment
 Technology to be built
 Staff size and experience
 Assessing overall project risk
 Risk component and drivers
▪ Performance risk
▪ Cost risk
▪ Support risk
▪ Schedule risk
1. Developing a risk table
2. Assessing risk impact
All of the risk analysis activities have a single goal in
developing a strategy for dealing with risk. An
effective strategy must consider three issues.

 Risk avoidance(Mitigation)
 Risk monitoring
 Risk management and contingency planning
Requirement Analysis is a software engineering task that
bridges the gap between System level requirement
engineering and software design
 Requirement analysis provide the software designer
with representation of Information, function and
behavior that can be translated to data
,architectural ,interfaces and component level
design
 Software requirement analysis may be divided into
five areas of efforts
1. Problem recognition
2. Evaluation and synthesis
3. Modeling
4. Specification and review
1. Initiating the process
2. Facilitated Application Specification
Technique ( FAST)
3. Quality Function Deployment

 Software prototyping
 Specification
 Specification Principles
 Representation
 Software Requirement Specification(SRS)
For a size oriented metrics, software organization maintains records in tabular form.
The typical table entries are: Project Name, LOC, Efforts, Pages of documents, Errors,
Defects, Total number of people working on it.

Project Name LOC Effort Cost ($) Doc. (pages) Errors Defects People

ABC 10, 000 20 170 400 100 12 4

PQR 20, 000 60 300 1000 129 32 6

XYZ 20, 000 65 522 1290 280 87 7

61
Are size-oriented metrics universally accepted in the software industry?

62
Function-Oriented Metrics
➢ Function-Oriented Metrics are also known
as Function Point Model.
➢ This model generally focuses on the functionality of
the software application being delivered.
➢ These methods are actually independent of the
programming language that is being used in software
applications and based on calculating the Function
Point (FP).
➢ A function point is a unit of measurement that
measures the business functionality provided by the
business product.

63
64
The software complexity can be computed by answering
the following questions :
➢ Does the system need reliable backup and recovery?
➢ Are data communications required?
➢ Are there distribute processing functions?
➢ Is the performance of the system critical?
➢ Can the system be able to run in an existing, heavily, and largely utilized operational
environment?
➢ Does the system require on-line data entry?
➢ Does the input transaction is required by the on-line data entry to be built over
multiple screens or operations?
➢ Are the master files updated on-line?
➢ Are the inputs, outputs, files, or inquiries complex?
➢ Is the internal processing complex?
➢ Is the code which is designed to be reusable?
➢ Are conversion and installation included in the design?
➢ Is the system designed for multiple installations in various organizations whenever
required?
➢ Is the application designed to facilitate or make the change and provide effective
ease of use by the user?

65
Each of the questions is answered using a scale that ranges from o to 5 (not important or
applicable to absolutely essential).
This scale is shown below :

66
 Lines of Code per
Language
Function Point
ADA 83 71

C 128

C++ 49

CLOS 27

COBOL 85 91

Eiffel 21

C++ 21
Smalltalk 21

Visual Basic 32

Small Project: <2000 Function Points

Medium Project: 2, 000 to 10, 000 Function Points
Large Project: > 10, 000 Function Points

Prof. Rohini Joshi 67

Compute the function point, productivity, documentation, cost per
function for the following data:
Number of user inputs = 24
Number of user outputs = 46
Number of inquiries = 8
Number of files = 4
Number of external interfaces = 2
Effort = 36.9 p-m
Technical documents = 265 pages
User documents = 122 pages
Cost = $7744/ month
Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3,
2, 2, 4, 5.
Prof. Rohini Joshi 68
Extended Function Point (EFP) Metrics
A number of extensions to the basic function point measure have been proposed.
These are as follows:
Feature Points:
➢ Feature Points are computed by counting the information domain values.
➢ It can be used in those areas where there is a level of complexity, is comparatively
very high.
➢ Function point (FP) measure is the subset for the Feature point.
➢ But both the Function point and feature point represents the functionality of the
systems

Prof. Rohini Joshi 69

3D function points:
Data, Functional, and control are three dimensions represented
by 3D function points.
➢ Data: User interfaces and data as in the original method.
➢ Control: Real-time behavior(s)
➢ Function: Internal processing

Prof. Rohini Joshi 70

Advantages of Software Metrics
➢ Reduction in cost or budget.
➢ It helps to identify the particular area for improvising.
➢ It helps to increase the product quality.
➢ Managing the workloads and teams.
➢ Reduction in overall time to produce the product,.
➢ It helps to determine the complexity of the code and
to test the code with resources.
➢ It helps in providing effective planning, controlling
and managing of the entire product.

Prof. Rohini Joshi 71

Disadvantages of Software Metrics
➢ It is expensive and difficult to implement the metrics in some
cases.
➢ Performance of the entire team or an individual from the
team can’t be determined. Only the performance of the
product is determined.
➢ Sometimes the quality of the product is not met with the
expectation.
➢ It leads to measure the unwanted data which is wastage of
time.
➢ Measuring the incorrect data leads to make wrong decision
making.

Prof. Rohini Joshi 72

Qu. Compute the function point value for a project with
the following information
domain characteristics:
Number of user inputs: 32
Number of user outputs: 60
Number of user inquiries: 24
Number of files: 8
Number of external interfaces: 2
Assume that all complexity adjustment values and
weighting factors are average.

Prof. Rohini Joshi 73

Consider a software project with the following information domain characteristic
for calculation of function point metric.
Number of external inputs (I) = 30
Number of external output (O) = 60
Number of external inquiries (E) = 23
Number of files (F) = 08
Number of external interfaces (N) = 02

It is given that the complexity weighting factors for I, O, E, F and N are 4, 5, 4, 10

and 7, respectively. It is also given that, out of fourteen value adjustment factors
that influence the development effort, four factors are not applicable, each of the
other four factors have value 3, and each of the remaining factors have value 4.
The computed value of function point metric is ____________

Prof. Rohini Joshi 74

The value of function point metric = UPF * VAF
Here, UPF: Unadjusted Function Point (UFP) count
VAF: Value Adjustment Factor(VAF)

UPF = 4*30 + 60*5 + 23*4 + 8*10 + 7*2 = 606

Here TDI is Total Degree of Influence
TDI = 4*3 + 4*0 + 6*4 = 36

FP=Count_total*[0.65+0.01*Sum(fi)]
= 606*[0.65+0.01*36]
=612.06

Prof. Rohini Joshi 75

Consider a software project with the following information domain characteristic for
calculation of function point metric.
Number of external inputs (I) = 40
Number of external output (O) = 50
Number of external inquiries (E) = 43
Number of files (F) = 09
Number of external interfaces (N) = 0

It is given that the complexity weighting factors for I, O, E, F and N are 5, 4, 2, 9 and 8,
respectively. It is also given that, out of fourteen value adjustment factors that
influence the development effort, two factors are not applicable, each of the other
three factors have value 3, and each of the remaining factors have value 5. The
computed value of function point metric is ____________

Prof. Rohini Joshi 76

Assume the following regarding the development of a software system P:
Estimated lines of codes :33,480 LOC
Average productivity for P: 620 LOC per person-month
Number of software developers:6
Average salary of a software developer:$50,000 per month

If E,D,C are the estimated development effort(in person-months),estimated development

time(in months) and estimated development cost(in $)respectively ,then value of E,D,C wil
be_______________
Solution
Step1: Estimated Development Effort(in person-months):(E)
33,480/620 =54

Step 2: Estimated Development Time(in months):(D)

54/6=9 months

Step 3: Estimated Development Cost(in $):(C)

50,000 *6* 9=2,700,000 $

Prof. Rohini Joshi 77

A Software project was estimated at 864 Function Points. A six person team will be assigned
to project consisting of a requirement gathering person, one designer, two programmers and
two testers. The salary of the designer is Rs. 70.000 per month, requirement gatherer is Rs.
50,000 per month, programmer is Rs. 60.000 per month and a tester is Rs. 60,000 per month.
Average productivity for the team is 12 FP per person month. What will be the projected cost
of the project?
Solution
Given data, Functional Point=864
team=6 persons
average each person(FP) productivity=12
designer monthly salary=70000
programmers monthly salary=2x60000
tester monthly salary=2x60000
Requirement gatherer=50000
Projected cost of project=?

Total number of months= Function Point(FP)/(Team * Average each person (FP)Productivity)

=864/(6*12)
=12 months
Total cost of the project=(one designer salary+2 x Programmer month salary+2 x tester
month salary + one requirement gatherer) x total number of months
=(70000+2x60000+2x60000+50000) x 12
=43,20,000 Rs.
Prof. Rohini Joshi 78
Q1. A software project was estimated at 352 Function Points (FP). A four person team
will be assigned to this project consisting of an architect, two programmers, and a
tester. The salary of the architect is ` 80,000 per month, the programmer ₹ 60,000 per
month and the tester ₹ 50,000 per month. The average productivity for the team is 8
FP per person month. What will be the projected cost of the project ?

Q2. Consider a software program that is artificially seeded with 100 faults. While
testing this program, 159 faults are detected, out of which 75 faults are from those
artificially seeded faults. Assuming that both real and seeded faults are of same nature
and have same distribution, the estimated number of undetected real faults is
____________.

79
Sol1 ₹ 2750000

Sol2 28

Prof. Rohini Joshi 80

 Decomposition technique
1. Software sizing :
Putnam and Myers suggest four different approaches to the
sizing problem
1) “Fuzzy logic” sizing(approximate reasoning)
2) Function point sizing
3) Standard component sizing
4) Change sizing

The result of these method create “three point” or “expected

value”estimate.
This is accomplished by developing optimistic(low), most likely
and pessimistic( high) value for size.
Prof. Rohini Joshi 81
Cost & Efforts estimation techniques
2. Problem based estimation technique

i) LOC based estimation

ii) FP based estimation

3. Process based estimation technique

Prof. Rohini Joshi 82

 Problem Based Estimation

LOC & FP parameters are used for estimation

⚫ LOC and FP parameter used in two way

i) as an estimation variable to “size”
ii) as baseline metrics collected from past project

⚫ A three point or expected value can be computed using three

factors
(Optimistic(Sopt),most likely(Sm),pessimistic(Spess))

S(Expected value)=( Sopt + 4Sm + Spess) / 6

⚫ Once the expected value for the estimation has been determined,
historical LOC or FP productivity data are applied

Prof. Rohini Joshi 83

 LOC Based Estimation

• Uses LOC for estimation value

• Example of CAD software system for LOC based estimation
• Following are the major software function for CAD Software system

Prof. Rohini Joshi 84

 Estimation table for LOCmethod for CAD system

optimistic—4600 LOC, most likely—6900 LOC, and pessimistic—8600 LOC.

• For 3D Geometric Estimated LOC is 6800
S= ( 4600 + 4*6900 + 8600) / 6 = 6800
• Review of historic data :- 620 LOC/ Month
Given
• Labor rate of $8000 / Month values

•Estimated effort = 33200/620 = 54 Person / Month

•Cost per Line is = 8000 /6 20 = $13
• So total cost is = 33200Prof.
* 13Rohini
= $431600
Joshi 85
 Problem-1: for one of the method for CAD system
Sopt Sm Spess
User interface and control facilities 4500 5600 7000
(UICF)
Two-dimensional geometric analysis 3450 5700 7450
(2DGA)
Three-dimensional geometric analysis 2250 4000 8250
(3DGA)
Database management (DBM) 5600 7540 9600
Computer graphics display facilities 6820 7400 9820
(CGDF)
Peripheral control function (PCF) 5420 7800 9420
Design analysis modules (DAM) 6540 8900 10450

Estimate the size of each function in LOC. Assuming that your

organization produces 850 LOC/pm with a burdened labor rate of
$9000 per person-month, estimate the effort and cost required to
build the software using the LOC-based estimation technique.

Prof. Rohini Joshi 86

 For one of the method for CAD system LOC is given below.
Estimate the size ofeach function in LOC. Assuming that your
organization produces 1800 LOC per two month, with a burdened
labour rate of $20000 per two person/ month, estimate the effort
and cost required to build the software using the LOC-based
estimation technique.

Functions S Values
User interface and control facilities (UICF) 8600 5500 8000
Two-dimensional geometric analysis (2DGA) 3450 6700 6450
Three-dimensional geometric analysis 8250 4000 9250
(3DGA)
Database management (DBM) 8600 7540 9600
Computer graphics display facilities (CGDF) 6820 2400 6820
Peripheral control function (PCF) 5420 4000 3420
Design analysis modules (DAM) 4540 4000 6450

Prof. Rohini Joshi 87

 FP Based Estimation
• Estimating information domain value for CAD system

Estimates are rounded-off to the nearest $1,000 and person-month.

(20+4(24)+30)/6= 24…….then apply weight factor

(12+4(15)+22)/6=16….
Prof. Rohini Joshi 88
•Each of the complexity weighting factor is estimated and the
complexity adjustment factor is computed

Σ (Fi) = 53.17
Prof. Rohini Joshi 89
 Final estimation of cost & efforts

⚫ Finally Estimated number is derived

⚫ FPestimated = Count _total X [ 0.65 + 0.01 X S ( Fi ) ]

FPestimated = 320 X [ 0.65 + 0.01 X 53.17) ]
= 375

⚫ The organizational Productivity for this type of system is 6.5FP/Month

⚫ Labor rate $8000 / Month (given data)

⚫ Estimated efforts required is = FPestimated /6.5

= 375 / 6.5
= 58 Person / Month

⚫ The cost per FP is approx - 8000/6.5= $1230

⚫ Total estimated project cost is = FPestimated * cost per FP

= 375 * 1230
= $461538

Qu calculate for actual values, w/o any assumptions.

Prof. Rohini Joshi 90
 Problem-1:

For one of the method for CAD system FP’S are given

Number of inputs 24 20 30
Number of outputs 30 34 25
Number of enquiries 15 20 24
Number of files 30 25 20
Number of external 20 25 24
Interfaces

Estimate the size of each function in FP. Assuming that your organization
produces 44 FP/pm with a burdened labor rate of $12000 per person-month,
estimate the effort and cost required to build the software using FP-based
estimation technique. Assume that all complexity adjustment value is
maximum and weighting factors are average.

Prof. Rohini Joshi 91

 Problem-2:
For one of the method for Computer Aided Design system FP’s are given.
Estimate the size of each function in terms of FP’s. Assuming that your
organization produces 30 FP/per two months with a burdened labour rate of
$9000 per person-month, estimate the effort and cost required to build the
software using the FP-based estimation technique. Assume complexity
adjustment values and weighting factors are maximum

Functions FP’s
User interface and control 60 66 50
facilities (UICF)
Two-dimensional geometric 55 40 60
analysis (2DGA)
Three-dimensional geometric 21 14 20
analysis (3DGA)
Database management (DBM) 10 15 20
Computer graphics display 29 24 28
facilities (CGDF)
Peripheral control function (PCF) 20 22 16

Design analysis modules (DAM) 24 20 18

Prof. Rohini Joshi 92
Planning involves Estimation
Your attempt to determine
⚫How much money
⚫How much efforts
⚫How much resources
⚫How much time
it will take to build a specific software
based system or product

Prof. Rohini Joshi 93

 Software scope :
- This is the first activity of project planning

- Software scope describes the data and the control to be

processed, function, performance, constraints ,interfaces and
reliability

1.Obtaining information necessary for Scope

- Data to be collected by asking context free question
suggested by Gause &Weinberg
2. Feasibility
- Software feasibility has four dimension
Technology, Finance ,Time , Resources
Prof. Rohini Joshi 94
 Feasibility
⚫ Technology
⚫Is a project technically feasible?
⚫ Is it within the state of the art?
⚫Can defects be reduced to a level matching the
application’s needs?
⚫ Finance— Is it financially feasible? Can development be

completed at acost the software organization, its client,

or the market can afford?
⚫ Time— Will the project’s time-to-market beat the
competition?
⚫ Resources—Does the organization have the resources
needed to succeed? Prof. Rohini Joshi 95
 Resources

- The second software planning task is the estimation of

resources.

- Each resources is specified with four characteristics

- - Description of the resources
- - Statement of availability
- - Time when resources will required
- - Duration of time that resources will be applied

Prof. Rohini Joshi 96

 Resources required

⚫ Human resources

⚫ Reusable software resources: Bennatan suggest four S/W

resources.
- Off the shelf components(Validated)
- Full Experienced component
- Partial Experience component
- New components

⚫ Environmental resources

Prof. Rohini Joshi 97

 Risk Analysis and Management
⚫ Reactive Risk Strategies
- the software team does nothing about risk until something
goes wrong
- Called fire fighting mode
- when this fails “crisis management” takes over the project
⚫ Proactive Risk Strategies
- Potentially risk is identified, their probability and impact are
assessed and they are ranked by importance.
- The software team establishes a plan for managing risk.

Prof. Rohini Joshi 98

 Software Risk :

⚫ Risk always involve two characteristics

1. Uncertainty
2. Loss

Types of risk :
⚫ Project risk
⚫ Technical risk
⚫ Business risk
⚫ Known or predictable risk
⚫ Unpredictable risk

Prof. Rohini Joshi 99

Steps in risk management
⚫ Step 1 - Risk Identification
⚫ Step 2 - Risk Projection
⚫ Step 3 - Risk Refinement
⚫ Step 4 - Risk Mitigation, Monitoring ,&
Management

Prof. Rohini Joshi 100

 Step 1 - Risk Identification
⚫ Generic risk:-Generic risks are a potential threat to every software
project.
⚫ Product specific risk:- can be identified only by those with a clear
understanding of the technology, the people, and the environment that
is specific to the project.

Risk item checklist

⚫ Product size
⚫ Business impact
⚫ Customer characteristics
⚫ Process definition
⚫ Development environment
⚫ Technology to be built
⚫ Staff size and experience

Prof. Rohini Joshi 101

⚫ Handling?
I. Assessing overall project risk
II. Risk component and drivers
⚫ Performance risk- (to meet requirements )
⚫ Cost risk-(Project budget maintained)
⚫ Support risk(Easy to correct, adapt?)
⚫ Schedule risk(maintained?, delivery time?)

Prof. Rohini Joshi 102

1.Assessing Overall Project Risk

Prof. Rohini Joshi 103

• The No. of Negatives should be less…

• The degree to which the project is at risk is directly

proportional to the number of negative responses to
these questions.

Project risk α (no. of negative responses)

Prof. Rohini Joshi 104

Impact assessment

Prof. Rohini Joshi 105

Step 2:-Risk Projection (estimation)
PS-Project Size risk
BU-Buisness risk
CU-customers ass risks
PS-Process Definition
1. Developing a risk table DE-Development Envi
ST-Staff size

Prof. Rohini Joshi 106

 Step 2:-Risk Projection (estimation)

• Once the first four columns of the risk table have been
completed, the table is sorted by probability and by impact.
• High-probability, high-impact risks percolate to the top of the
table, and low-probability risks drop to the bottom.

• The project manager studies the resultant sorted table

and defines a cutoff line.----------------→
• only risks that lie above the line will be given further
attention.
• Risks that fall below the line are re-evaluated to
accomplish second-order prioritization.

Prof. Rohini Joshi 107

 Ps-Project Size risk
Cut –off line BU-Buissness risk
CU-customers ass risks
PS-Process Definition
DE-Development Envi
1. Developing a risk table ST-Staff size

Prof. Rohini Joshi 108

 Step 2:- Risk projection
2.Assessing risk impact

The overall risk

exposure, RE, is
determined using the
following relationship

RE = P x C
P→prob of occ of a
risk
C→Cost to the proj

Prof. Rohini Joshi 109

Step-3:- Risk Refinement
⚫ During early stages of project planning, a risk may be stated quite
generally.
⚫ As time passes and more is learned about the project and the risk,
it may be possible to refine the risk into a set of more
detailed risks, each somewhat easier to mitigate, monitor, and
manage.(using previous experiences)

⚫ One way to do this is to represent the risk in condition-transition-

consequence(CTC)That is, the risk is stated in the following form:
⚫ Given that <condition> then there is concern that
(possibly) <consequence>.

Prof. Rohini Joshi 110

Step-4 Risk Mitigation, Monitoring &
Management
All of the risk analysis activities have a single goal in
developing a strategy for dealing with risk. An effective
strategy must consider three issues.

⚫ Risk avoidance(Mitigation)
⚫ Risk monitoring
⚫ Risk management and contingency planning

Prof. Rohini Joshi 111

 Risk Mitigation/ MGMT
To mitigate this risk, project management must develop a strategy for
reducing turnover. Among the possible steps to be taken are

•Meet with current staff to determine causes for turnover (e.g., poor
working conditions, low pay, competitive job market).
• Mitigate those causes that are under our control before the project starts.

•Once the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave.

•Organize project teams so that information about each development

activity is widely dispersed.

•Conduct peer reviews of all work (so that more than one person is "up to
speed”).
• Assign a backup staff member for every critical technologist.
Prof. Rohini Joshi 112
 SAFETYRISKS AND HAZARDS

⚫Risk is not limited to the software project itself.

⚫Risks can occur after the software has been
successfully developed and delivered to the
customer.
⚫enormous economic damage or, worse,
significant human injury or loss of life.

Prof. Rohini Joshi 113

"If you know the enemy and know yourself, you need not fear the result of
a hundred battles." For the Prof. Rohiniproject
software Joshi manager, the enemy is risk. 114
 Problems
⚫ Create a risk table for a Data entry & display system
software (i.e. Voter ID List) for door to door survey for office
staff collecting data from households, It should provide the ward-
wise voters list according to need of voter, election commission.
⚫ Assume, you’re the project manager for a major software company.
You’ve been asked to lead a team that’s developing “IOT based
assembly line for manufacturing air conditioners”. Create a risk
table for the project.
⚫ RKN Multimedia System wanted to develop software to support a
low-video editing system. The system accepts digital video system
as input stores the video on disk and then allows the user to do a
wide range of edits to the digized video. Identify the different risk
occur and develop a mitigation strategy.
Prof. Rohini Joshi 115
 Requirement Analysis
Requirement Analysis is a software engineering task that bridges the
gap between System level requirement engineering and software
design.

/ Analysis

Prof. Rohini Joshi 116

 INTRODUCTION
⚫ SYSTEMANALYSIS:-Is about finding out what the new
system is to do, rather than how?

⚫ There are two basic components to the analysis process.

⚫ Fact-Finding:-An exercise needs to take place where all users
of the new system should contribute to determine
requirements.
⚫ Documentation:- Detailed system design,
⚫ Unambiguous documentation
⚫ Diagrams

Prof. Rohini Joshi 117

SYSTEM ANALYSIS

⚫Involves the investigation of the business

and user requirements of an information
systems.

Prof. Rohini Joshi 118

Need of SYSTEM ANALYSIS

⚫ MAKE or BUYdecision.(@ )Feasibility stage)

⚫ Application Complexity.(Complex)

Prof. Rohini Joshi 119

 Identifying the requirements

⚫ Is to identify those user requirements that need to be

incorporated into the design of the new information system

⚫ That the requirements identified really meet the users need.

Prof. Rohini Joshi 120

Difficulties for identifying the Requirements
⚫ User limitations-inability to express correct requirements.
⚫ User awareness-What can be achieved and what not?
⚫ User Interpretations-Users attitude, personality, or
environment
⚫ Complex Communication issues.

Prof. Rohini Joshi 121

Prof. Rohini Joshi 122
Technique for Identifying requirements

1. Interviewing
2. Questionnaires
3. Documentation Review
4. Observation
5. Pictures

Prof. Rohini Joshi 123

 Requirement Engineering Tasks
1. Inception(Scope and Nature of Problem)
2. Elicitation(Customer to define what is req?)
3. Elaboration(basic req are refined and modified)
4. Negotiation
5. Specification
6. Validation

Prof. Rohini Joshi 124

 1.Inception
⚫ Identify stakeholders
⚫ “who else do you think I should talk to?”
⚫ Recognize multiple points of view
⚫ Work toward collaboration
⚫ The first questions
⚫ Who is behind the request for this work?
⚫ Who will use the solution?
⚫ What will be the economic benefit of a successful
solution
⚫ Is there another source for the solution that you need?

Prof. Rohini Joshi 125

 2.Eliciting Requirements
⚫ Meetings are conducted and attended by both software
engineers and customers
⚫ Rules for preparation and participation are established
⚫ an agenda is suggested
⚫ A "facilitator" (can be a customer, a developer, or an outsider)
controls the meeting
⚫ A "definition mechanism" (can be work sheets, flip charts, or
wall stickers or an electronic bulletin board, chat room or
virtual forum) is used
⚫ the goal is
⚫ identify the problem
⚫ propose elements of the solution
⚫ negotiate different approaches, and
⚫ specify a set of solution requirements
Prof. Rohini Joshi 126
3.Elaboration

⚫ Create an analysis model that identifies data, function and

behavioral requirements.

Prof. Rohini Joshi 127

 4.Negotiating Requirements
⚫ Identify the key stakeholders
⚫ These are the people who will be involved in the negotiation.
⚫ Determine each of the stakeholders“win conditions”
⚫ Win conditions are not always obvious.
⚫ Negotiate
⚫ Work toward a set of requirements that lead to “win-win”.

Prof. Rohini Joshi 128

5. Specification
⚫ Software Requirement Specification(SRS)

Prof. Rohini Joshi 129

 Three aspects need to be documented in
Requirement Specification

⚫Functional Requirements.
Consist of requirements that perform the activities that run the
business.(updating master files, enq. data against file..)
⚫Non-functional requirements.
business function to be supported(Online response time,
security issues)
⚫Quantification of requirements.
Refers to the need for a measure of quality if benefits are to be
properly evaluated.(inc sales by 25%, red cust complaints by
75%)

Prof. Rohini Joshi 130

Prof. Rohini Joshi 131
Qu Explain the procedure for
Requirement Elicitation for Software
1. Initiating the process
2. FacilitatedApplication SpecificationTechnique ( FAST)
3. Quality Function Deployment
4. Use Case Diagrams

Prof. Rohini Joshi 132

 1.Initiating the Process

⚫The most commonly used requirements elicitation technique is to

conduct a meeting or interview.

⚫ The meeting between a software engineer (the analyst) and the

customer.

⚫Communication must be initiated.

⚫The analyst start by asking context-free questions. That is, a set of

questions that will lead to a basic understanding of the problem,
the people who want a solution, the nature of the solution that is
desired.
Prof. Rohini Joshi 133
2. Facilitated Application Specification Techniques
(FAST)
⚫A number of independent investigators have developed a team-oriented
approach to requirements gathering that is applied during early stages of
analysis and specification. Called facilitated application specification techniques
(FAST).

⚫This approach encourages the creation of a joint team of customers and

developers who work together to identify the problem, propose
elements of the solution, negotiate different approaches and specify a
preliminary set of solution requirements.

⚫FAST has been used predominantly by the information systems community,

but the technique offers potential for improved communication in
applications of all kinds.

Prof. Rohini Joshi 134

 3.Quality Function Deployment
⚫Quality function deployment (QFD) is a quality management
technique that translates the needs of the customer into
technical requirements for software.

⚫QFD emphasizes an understanding of what is valuable to the

customer and then deploys these values throughout the
engineering process.
⚫QFD identifies three types of requirements..
⚫Normal requirements.:- the customer explicitly state them.

⚫ Expected requirements.- the customer does not explicitly state them.

⚫Exciting requirements:- go beyond the customer’s expectations

Prof. Rohini Joshi 135

 4. Use-Cases

⚫Tocreate a use-case, the analyst must first identify the different types of
people (or devices) that use the system or product.

⚫These actors actually represent roles that people (or devices) play as the
system operates.

⚫Anactor is anything that communicates with the system or product and

that is external to the system itself.

Prof. Rohini Joshi 136

Prof. Rohini Joshi 137
Prof. Rohini Joshi 138
Prof. Rohini Joshi 139
Prof. Rohini Joshi 140
 SOFTWARE PROTOTYPING

⚫Requirements elicitation (via FAST, QFD, use-cases, or other

"brainstorming" techniques ) is conducted, analysis principles are
applied, and a model of the software to be built, called a prototype.

⚫It is constructed for customer and developer assessment.

⚫Finally, some circumstances require the construction of a prototype

at the beginning of analysis, since the model is the only means
through which requirements can be effectively derived. The model
then evolves into production software.

Prof. Rohini Joshi 141

 Qu. Write short note on
SOFTWARE PROTOTYPING

1. Selecting the PrototypingApproach

2. Prototyping Methods andTools

Prof. Rohini Joshi 142

 1.Selecting the Prototyping Approach

⚫The prototyping paradigm can be either close-ended or open-ended. The

close-ended approach is often called throwaway prototyping.

⚫Using this approach, a prototype serves solely as a rough demonstration

of requirements. It is then discarded, and the software is engineered
using a different paradigm.

⚫ An open-ended approach, called evolutionary prototyping, uses the

prototype as the first part of an analysis activity that will be continued
into design and construction.
⚫The prototype of the software is the first evolution of the finished system.

Prof. Rohini Joshi 143

 1.Selecting the Prototyping Approach
⚫ Depends on…Application area, application complexity, customer
characteristics, and project characteristics.

Prof. Rohini Joshi 144

 2. Prototyping Methods and Tools

⚫For software prototyping to be effective, a prototype must

be developed rapidly so that the customer may assess results
and recommend changes.

⚫Three generic classes of methods and tools

⚫ Fourth generation techniques.
⚫ Reusable software components.
⚫ Formal specification and prototyping environments.

Prof. Rohini Joshi 145

Example-Prototype

Prof. Rohini Joshi 146

 SPECIFICATION

⚫Specification α Quality(solution).

⚫There is no doubt that the mode of specification has much

to do with the quality of solution.
Else
frustration and confusion

1. Specification Principles
2. Representation

Prof. Rohini Joshi 147

 Specification Principles
⚫ 1. Separate functionality from implementation.

⚫ 2.Develop a model of the desired behavior of a system that encompasses data and the
functional responses of a system to various stimuli from the environment.

⚫ 3. Establish the
context in which software operates by specifying the manner in which
other system components interact with software.

⚫ 4. Define the environment in which the system operates and indicate how “a highly
intertwined collection of agents react to stimuli in the environment (changes to
objects) produced by those agents” .

⚫ 5. Create a cognitive model rather than a design or implementation model. The cognitive model
describes a system as perceived by its user community.

⚫ 6. Recognize that “the specifications must be tolerant of incompleteness and augmentable.

⚫ 7. Establish the content and structure of a specification in a way that will enable it to be
agreeable to change.
Prof. Rohini Joshi 148
 Representation

⚫ Representation format and content should be relevant to

the problem.

⚫ Information contained within the specification should

be nested.

⚫ Diagrams and other notational forms should be

restricted in number and consistent in use.

⚫ Representations should be revisable.

Prof. Rohini Joshi 149

Software Reengineering

Prof. Rohini Joshi 150

 What? Who? Why?
⚫ Technology product--→ well.
⚫ It breaks often..longer repairs…
⚫ Youshould rebuild it--->functionality, reliability,
maintainability

⚫ Who? Organizational level-→consultants

⚫ s/w level--→ software engineers.

⚫ Why?
⚫ We live in the rapidly changing world.

Prof. Rohini Joshi 151

 Software Reengineering

Forward inventory
engineering analysis

Data document
restructuring restructuring

code reverse
restructuring engineering

Prof. Rohini Joshi 152

 1. Inventory Analysis (other apps)
⚫ Build a table that contains all applications
⚫ establish a list of criteria, e.g.,
⚫name of the application
⚫year it was originally created
⚫number of substantive changes made to it
⚫total effort applied to make these changes
⚫date of last substantive change
⚫effort applied to make the last change
⚫system(s) in which it resides
⚫applications to which it interfaces, ...

⚫ analyze and prioritize to select candidates for

reengineering
Prof. Rohini Joshi 153
 2. Document Restructuring
⚫ Weak documentation is the trademark of many legacy
systems.
⚫ But what do we do about it? What are our options?
⚫ Options …
⚫ Creating documentation is too time consuming.
⚫ Documentation must be updated, but we have limited
resources.
⚫ The system is business critical and must be fully
redocumented. Even in this case, an intelligent approach is
to prepare documentation.

Prof. Rohini Joshi 154

 3. Reverse Engineering
existing source code

restructure
code

clean source code processing

extract
abstractions interface

initial specification database

refine
&
simplify

final specification

Prof. Rohini Joshi 155

 4. Code Restructuring
⚫ Source code is analyzed using a restructuring tool.
⚫ Poorly design code segments are redesigned.
⚫ Violations of structured programming constructs
are noted and code is then restructured (this can
be done automatically).
⚫ The resultant restructured code is reviewed and
tested to ensure that no anomalies have been
introduced.
⚫ Internal code documentation is updated.

Prof. Rohini Joshi 156

 5. Data Restructuring
⚫ data structuring is a full-scale reengineering activity.
⚫ In most cases, data restructuring begins with a
reverse engineering activity.

⚫ Current data architecture is dissected and necessary

data models are defined.
⚫ Data objects and attributes are identified, and existing
data structures are reviewed for quality.
⚫ When data structure is weak (e.g., flat files are currently
implemented, when a relational approach would greatly
simplify processing), the data are reengineered.

Prof. Rohini Joshi 157

 6. Forward Engineering
• A prototype of the software already exists, development

productivity should be much higher than average.

• The user now has experience with the software.

Therefore, new requirements and the direction of change

can be done with greater ease.

Prof. Rohini Joshi 158