Department of Computer Science and Engineering

Question Bank With Answers

UNIT- II
Software Project Management: Software project management complexities,
Responsibilities of a software project manager, Metrics for project size
estimation, Project estimation techniques, Empirical Estimation techniques,
COCOMO, Halstead’s software science, risk management.

Requirements Analysis And Specification: Requirements gathering and

analysis, Software Requirements Specification (SRS), Formal system
specification, Axiomatic specification, Algebraic specification, Executable
specification and 4GL.

Short Questions:
1. What is Software Project Management?
Sol: Software Project Management (SPM) is a proper way of planning
and leading software projects. It is a part of project management in
which software projects are planned, implemented, monitored, and
controlled.

2. Define project size estimation?

Sol : Project size estimation is the process of determining the overall
scope or scale of a project in terms of effort, resources, time, and cost.
This involves estimating the amount of work required, the complexity of
the tasks, and the necessary resources (like personnel, equipment, and
technology) to complete the project successfully.

3. What is COCOMO model?

Sol: The COCOMO (COnstructive COst MOdel) is a widely used software

cost estimation model developed by Barry Boehm in the 1980s. It helps
 to predict the cost, effort, and schedule required to complete a software
project based on its size and other attributes. The model estimates the
required effort (in person-months), project duration, and the required
number of people based on input factors like project size, complexity,
and environment.

4. Define risk management?

Sol: Risk management is the process of identifying, assessing and
controlling threats to an organization's capital, earnings and
operations.
(OR)
Risk management is the process of identifying, assessing, and
prioritizing risks to minimize, monitor, and control the probability or
impact of unfortunate events.

5. What is Software Requirements Specification (SRS)?

Sol: A Software Requirements Specification (SRS) is a detailed
document that describes the functional and non-functional
requirements for a software system. It serves as a contract between the
stakeholders (like the client, end-users, and developers) and provides a
clear understanding of the software.

6. Define 4GL?
Sol: 4GL stands for Fourth-Generation Language. It refers to a
category of programming languages that are closer to human language
and are more abstracted from the machine code compared to earlier
generations (such as 1GL, 2GL, and 3GL). 4GLs are designed to be
more user-friendly, offering higher-level commands that enable
developers to write programs more quickly and efficiently.

7. What is meant by software Design?

Sol: Software design refers to the process of planning and creating the
structure of a software system. It involves making high-level decisions
about how the software will function, how different components will
interact, and how the overall system will meet its requirements. The
goal of software design is to create a blueprint that ensures the system
is reliable, scalable, maintainable, and efficient.

8. Define Project manager?

 Sol: Project managers in software organize software projects and can
assign tasks to software engineering teams according to the specifications
of a task. Software project managers use their leadership skills, technical
knowledge and experience to direct their teams and ensure software meets
client requirements.

Software Project Manager is generally never directly involved in producing

the end product but he controls and manages the activities involved in the
production. He is aware of all the phases of Software Development Life Cycle.

Topic: Software project management complexities

7. Discuss about Software project management complexities?[7M]

[Understanding].

Sol: Software Project Management Complexities refer to the various

difficulties to manage a software project. It recognizes in many different ways.
The main goal of software project management is to enable a group of
developers to work effectively toward the successful completion of a project in
a given time. But software project management is a very difficult task.

Management of software projects is much more complex than management of

many other types of projects. The main factors of the complexity of managing
software project as identified by Brooks in 1975. They are

Invisibility: Until the development of a software project is complete, Software

remains invisible. Anything that is invisible, is difficult to manage and
control. Software project managers cannot view the progress of the project
due to the invisibility of the software until it is completely developed. The
project manager can monitor the modules of the software that have been
completed by the development team and the documents that have been
prepared, which are rough indicators of the progress achieved. Thus
invisibility causes a major problem in the complexity of managing a software
project.

Changeability: Requirements of a software product are undergone various

changes. Most of these change requirements come from the customer during
the software development. Sometimes these change requests resulted in
redoing of some work, which may cause various risks and increase expenses.
Thus frequent changes to the requirements play a major role to make
software project management complex.
Complexity: Even moderate-sized software has millions of parts (functions)
that interact with each other in many ways such as data coupling, serial and
concurrent runs, state transitions, control dependency, file sharing, etc. Due
to the inherent complexity of the functioning of a software product in terms of
the basic parts making up the software, many types of risks are associated
with its development. This makes managing software projects much more
difficult compared to many other kinds of projects.

Uniqueness: Every software project is usually associated with many unique

features or situations. This makes every software product much different from
the other software projects. This is unlike the projects in other domains such
as building construction, bridge construction, etc. where the projects are
more predictable. Due to this uniqueness of the software projects, during the
software development, a project manager faces many unknown problems that
are quite dissimilar to other software projects that he had encountered in the
past. As a result, a software project manager has to confront many
unanticipated issues in almost every project that he manages.

o The exactness of the Solution: A small error can create a huge

problem in a software project. The solution must be exact according
to its design. The parameters of a function call in a program are
required to be correct with the function definition. This requirement
of exact conformity of the parameters of a function introduces
additional risks and increases the complexity of managing software
projects.

o Team-oriented and Intellect-intensive work: Software

development projects are team-oriented and intellect-intensive work.
The software cannot be developed without interaction between
developers. In a software development project, the life cycle activities
are not only intellect-intensive, but each member has to typically
interact, review the work done by other members, and interface with
several other team members creating various complexity to manage
software projects.

o The huge task regarding Estimation: One of the most important

aspects of software project management is Estimation. During
project planning, a project manager has to estimate the cost of the
project, the probable duration to complete the project, and how
much effort is needed to complete the project based on size
estimation. This estimation is a very complex task, which increases
the complexity of software project management.

Topic: Responsibilities of a software project manager

 8. What are the Responsibilities of a software project manager?
Explain. [7M] [Analyzing]

A software project manager is the most important person inside a team who
takes the overall responsibilities to manage the software projects and plays an
important role in the successful completion of the projects.

1. Managing people:
 Acts as a project leader
 Communication with stakeholders
 Manages human resources

2. Managing project:
 Monitors progress and performance
 Risk analysis at every phase
 Manages time and budget constraint

3. Job Responsibilities:
 Involves with the senior managers in the process of appointing team
members.
 Builds the project team and assigns tasks to various team members.
 Responsible for effective project planning and scheduling, project
monitoring and control activities in order to achieve the project
objectives.
 Acts as a communicator between the senior management and the
development team and internal and external stakeholders.
 Effectively resolves issues that arise between the team members by
changing their roles and responsibilities.
 Modifies the project plan (if required) to deal with the situation.

4. Scheduling
After the completion of the estimation of all the project parameters,
scheduling for manpower and other resources is done.

5. Staffing
Team structure and staffing plans are made.

6. Risk Management
The project manager should identify the unanticipated risks that may occur
during project development risk, analyze the damage that might cause these
risks, and take a risk reduction plan to cope with these risks.
7. Miscellaneous Plans
This includes making several other plans such as quality assurance plans,
configuration management plans, etc.

 Lead the team: The project manager must be a good leader who makes
a team of different members of various skills and can complete their
individual tasks.

 Motivate the team-member: One of the key roles of a software project

manager is to encourage team members to work properly for the successful
completion of the project.

 Tracking the progress: The project manager should keep an eye on the
progress of the project. A project manager must track whether the project
is going as per plan or not. If any problem arises, then take the necessary
action to solve the problem. Moreover, check whether the product is
developed by maintaining correct coding standards or not.

 Liaison: The project manager is the link between the development team
and the customer. Project manager analysis the customer requirements
and convey it to the development team and keep telling the progress of the
project to the customer. Moreover, the project manager checks whether the
project is fulfilling the customer’s requirements or not.

 Monitoring and reviewing: Project monitoring is a continuous process

that lasts the whole time a product is being developed, during which the
project manager compares actual progress and cost reports with
anticipated reports as soon as possible. While most firms have a formal
system in place to track progress, qualified project managers may still gain
a good understanding of the project’s development by simply talking with
participants.

 Documenting project report: The project manager prepares the

documentation of the project for future purposes. The reports contain
detailed features of the product and various techniques. These reports help
to maintain and enhance the quality of the project in the future.

 Reporting: Reporting project status to the customer and his or her

organization is the responsibility of the project manager. Additionally, they
could be required to prepare brief, well-organized pieces that summarize
key details from in-depth studies.

Topic: Metrics for project size estimation

9. Discuss about Metrics for project size estimation? [7M] [Understanding].

Sol:

Metrics for software project size estimation

Accurate estimation of the problem size is fundamental to satisfactory estimation of effort, time
duration and cost of a software project. In order to be able to accurately estimate the project size, some
important metrics should be defined in terms of which the project size can be expressed. The size of a
problem is obviously not the number of bytes that the source code occupies. It is neither the byte size of
the executable code. The project size is a measure of the problem complexity in terms of the effort and
time required to develop the product. Currently two metrics are popularly being used widely to estimate
size:

1- lines of code (LOC)

2- function point (FP)

LINES OF CODE (LOC):

LOC is the simplest among all metrics available to estimate project size. This metric is very popular
because it is the simplest to use. Using this metric, the project size is estimated by counting the number
of source instructions in the developed program. Obviously, while counting the number of source
instructions, lines used for commenting the the code and the header lines should be ignored.
Determining the LOC count at the end of a project is a very simple job. However, accurate estimation of
the LOC count at the beginning of a project is very difficult. In order to estimate the LOC count at the
beginning of a project, project managers usually divide the problem into modules, and each module into
submodules and so on, until the sizes of the different leaf-level modules can be approximately
predicted. To be able to do this, past experience in developing similar products is helpful. By using the
estimation of the lowest level modules, project managers arrive at the total size estimation.

FUNCTION POINT (FP):

Function point metric was proposed by Albrecht [1983]. This metric overcomes many of the
shortcomings of the LOC metric. Since its inception in late 1970s, function point metric has been
slowly gaining popularity. One of the important advantages of using the function point metric is that
it can be used to easily estimate the size of a software product directly from the problem
specification. This is in contrast to the LOC metric, where the size can be accurately determined only
after the product has fully been developed. The conceptual idea behind the function point metric is
that the size of a software product is directly dependent on the number of different functions or
features it supports. A software product supporting many features would certainly be of larger size
than a product with less number of features. Each function when invoked reads some input data and
transforms it to the corresponding output data. For example, the issue book feature (as show in
figure) of a Library Automation Software takes the name of the book as input and displays its
location and the number of copies available. Thus, a computation of the number of input and the
output data values to a system gives some indication of the number of functions supported by the
system. Albrecht postulated that in addition to the number of basic functions that a software
performs, the size is also dependent on the number of files and the number of interfaces.
Besides using the number of input and output data values, function point metric computes the
size of a software product (in units of functions points or FPs) using three other characteristics
of the product as shown in the following expression. The size of a product in function points
(FP) can be expressed as the weighted sum of these five problem characteristics. The weights
associated with the five characteristics were proposed empirically and validated by the
observations over many projects. Function point is computed in two steps. The first step is to
compute the unadjusted function point (UFP).

UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4 + (Number of

files)*10 + (Number of interfaces)*10

Number of inputs: Each data item input by the user is counted. Data inputs should be
distinguished from user inquiries. Inquiries are user commands such as print-account-balance.
Inquiries are counted separately. It must be noted that individual data items input by the user
are not considered in the calculation of the number of inputs, but a group of related inputs are
considered as a single input.

For example, while entering the data concerning an employee to an employee pay roll
software; the data items name, age, sex, address, phone number, etc. are together considered
as a single input. All these data items can be considered to be related, since they pertain to a
single employee.

Number of outputs: The outputs considered refer to reports printed, screen outputs, error
messages produced, etc. While outputting the number of outputs the individual data items
within a report are not considered, but a set of related data items is counted as one input.

Number of inquiries: Number of inquiries is the number of distinct interactive queries which
can be made by the users. These inquiries are the user commands which require specific action
by the system.
Number of files: Each logical file is counted. A logical file means groups of logically related data.
Thus, logical files can be data structures or physical files.

Number of interfaces: Here the interfaces considered are the interfaces used to exchange
information with other systems. Examples of such interfaces are data files on tapes, disks,
communication links with other systems etc.

Once the unadjusted function point (UFP) is computed, the technical complexity factor (TCF) is
computed next. TCF refines the UFP measure by considering fourteen other factors such as high
transaction rates, throughput, and response time requirements, etc. Each of these 14 factors is assigned
from 0 (not present or no influence) to 6 (strong influence).

The resulting numbers are summed, yielding the total degree of influence (DI).

Now, TCF is computed as (0.65+0.01*DI). As DI can vary from 0 to 70, TCF can vary from 0.65 to 1.35.
Finally, FP=UFP*TCF.

Shortcomings of function point (FP) metric LOC as a measure of problem size has several shortcomings:

• LOC gives a numerical value of problem size that can vary widely with individual coding style –
different programmers lay out their code in different ways. For example, one programmer might write
several source instructions on a single line whereas another might split a single instruction across
several lines. Of course, this problem can be easily overcome by counting the language tokens in the
program rather than the lines of code. However, a more intricate problem arises because the length of a
program depends on the choice of instructions used in writing the program. Therefore, even for the
same problem, different programmers might come up with programs having different LOC counts. This
situation does not improve even if language tokens are counted instead of lines of code.

• A good problem size measure should consider the overall complexity of the problem and the effort
needed to solve it. That is, it should consider the local effort needed to specify, design, code, test, etc.
and not just the coding effort. LOC, however, focuses on the coding activity alone; it merely computes
the number of source lines in the final program. We have already seen that coding is only a small part of
the overall software development activities. It is also wrong to argue that the overall product
development effort is proportional to the effort required in writing the program code. This is because
even though the design might be very complex, the code might be straightforward and vice versa. In
such cases, code size is a grossly improper indicator of the problem size.

• LOC measure correlates poorly with the quality and efficiency of the code. Larger code size does not
necessarily imply better quality or higher efficiency. Some programmers produce lengthy and
complicated code as they do not make effective use of the available instruction set. In fact, it is very
likely that a poor and sloppily written piece of code might have larger number of source instructions
than a piece that is neat and efficient
• LOC metric measures the lexical complexity of a program and does not address the more important
but subtle issues of logical or structural complexities. Between two programs with equal LOC count, a
program having complex logic would require much more effort to develop than a program with very
simple logic. To realize why this is so, consider the effort required to develop a program having multiple
nested loop and decision constructs with another program having only sequential control flow.

• It is very difficult to accurately estimate LOC in the final product from the problem specification. The
LOC count can be accurately computed only after the code has been fully developed. Therefore, the LOC
metric is little use to the project managers during project planning, since project planning is carried out
even before any development activity has started. This possibly is the biggest shortcoming of the LOC
metric from the project manager’s perspective.

Topic: Project estimation techniques, Empirical Estimation techniques

10. What are the techniques in Project estimation? Explain Briefly.

[7M] [Remembering].

Sol : Project estimation involves determining the resources, time, effort, and cost required to
complete a project. Various techniques are used to estimate projects accurately. Here are the
key techniques, explained briefly:

1. Expert Judgment

 Description: Relies on the experience and knowledge of experts familiar with similar projects.
 Advantage: Quick and effective for high-level estimates.
 Limitation: Subjective and depends heavily on the expert’s accuracy.

2. Analogous Estimation

 Description: Uses historical data from similar past projects to estimate the current project.
 Advantage: Fast and straightforward.
 Limitation: Assumes that current and past projects are sufficiently similar

3. Parametric Estimation

 Description: Uses mathematical models and statistical data to calculate estimates based on
parameters (e.g., cost per unit or time per task).
 Advantage: More accurate if input data is reliable.
 Limitation: Requires high-quality historical data.
4. Bottom-Up Estimation

 Description: Breaks the project into smaller tasks, estimates each task individually, and
aggregates them for the overall estimate.
 Advantage: Highly detailed and accurate.
 Limitation: Time-consuming and requires detailed project breakdown.

5. Three-Point Estimation

 Description: Uses three estimates (Optimistic, Most Likely, Pessimistic) to calculate an average
or weighted estimate.
 Formula:
o Triangular Distribution: (O+M+P)/3(O + M + P) / 3(O+M+P)/3
o PERT (Beta Distribution): (O+4M+P)/6(O + 4M + P) / 6(O+4M+P)/6
 Advantage: Accounts for uncertainty and risk.
 Limitation: Requires experience to estimate the three values accurately.

6. Top-Down Estimation

 Description: Estimates the project as a whole and distributes the effort among tasks based on
proportions.
 Advantage: Quick for early-stage estimates.
 Limitation: Less accurate, especially for complex projects.

7. Monte Carlo Simulation

 Description: Uses probability distributions to simulate various project outcomes and estimate
effort or cost.
 Advantage: Provides a range of outcomes and accounts for uncertainty.
 Limitation: Requires advanced tools and statistical knowledge.

8. Function Point Analysis (FPA)

 Description: Estimates effort based on the functionality delivered (e.g., input/output points,
files).
 Advantage: Useful for software projects.
 Limitation: Requires expertise in identifying function points.

9. COCOMO (Constructive Cost Model)

 Description: A model-based approach that uses inputs like project size, complexity, and team
capability to estimate effort and cost.
 Advantage: Standardized and reliable for software projects.
 Limitation: Requires detailed project parameters.
10. Heuristic Estimation

 Description: Uses rule-of-thumb or experience-based shortcuts for quick estimates.

 Advantage: Simple and fast.
 Limitation: May lack accuracy.

Each technique has its strengths and is chosen based on the project’s complexity, data availability, and
the stage of the project lifecycle.

11. Write about Empirical Estimation techniques?[7M]

[understanding].

Sol: Empirical estimation technique are based on the data taken from the previous project and some based on

guesses and assumptions.

There are many empirical estimation technique but most popular are

Expert Judgement Technique

Delphi Cost Technique

Expert judgement technique:

An expert makes an educated guess of the problem size after analyzing the problem thoroughly. Expert estimate
the cost of different components that is modules and sub modules of the system.

Disadvantages:

Human error, considering not all factors and aspects of the project, individual bias, more chances of failure.

Estimation by group of experts minimises factors such as individual oversight, lack of familiarity with a particular

aspect of a project, personal bias and desired to win a contract through overly optimistic estimates.

Delphi cost estimation:

 Role of Members: Coordinator provide a copy of Software Requirement Specification(SRS) document and a

form of recording it cost estimate to each estimator.

Estimator: It complete their individual estimate anomalously and submit to the coordinator with mentioning, if

any, unusual characteristics of product which has influenced his estimation.

The coordinator and distribute the summary of the response to all estimator and they re-estimate them.

No discussion is allowed among the estimator during the entire estimation process because there may be many

estimators get easily influenced by rationale of an estimator who may be more experienced or senior.

After the completion of several iterations of estimation, the coordinator takes the responsibility of

compiling the result and preparing the final estimates.

Topic: COCOMO, Halstead’s software science, risk management.

12. Discuss about COCOMO Model?[7M] [Evaluating]

sol: The COCOMO (COnstructive COst MOdel) is a popular algorithmic model used for estimating the
cost, effort, and time required to develop software systems. It was first introduced by Barry Boehm in
1981 and has since been widely adopted and updated (e.g., COCOMO II). The model helps project
managers estimate software project resources based on various project parameters.

According to Boehm, software cost estimation is categorized into three stages:

1. Basic Model
2. Intermediate Model
3. Detailed Model.
 1. Basic COCOMO Model: The basic COCOMO model provide an accurate
size of the project parameters. The following expressions give the basic
COCOMO estimation model:

Effort=a1*(KLOC)a2 PM

Tdev=b1*(efforts)b2 Months

Where

KLOC is the estimated size of the software product indicate in Kilo Lines of Code,

a1,a2,b1,b2 are constants for each group of software products,

Tdev is the estimated time to develop the software, expressed in months,

Effort is the total effort required to develop the software product, expressed in person

months (PMs).

In COCOMO, projects are categorized into three types by BOhems[1981]:

1. Organic
2. Semidetached
3. Embedded

1. Organic: A development project can be treated of the organic type, if the project
deals with developing a well-understood application program, the size of the
development team is reasonably small, and the team members are experienced in
developing similar methods of projects.

Examples : simple business systems, simple inventory management systems, and

data processing systems.

2. Semidetached: A development project can be treated with semidetached type if the

development consists of a mixture of experienced and inexperienced staff. Team
members may have finite experience in related systems but may be unfamiliar with
some aspects of the order being developed.

Example of Semidetached system includes developing a new operating system (OS),

a Database Management System (DBMS), and complex inventory management
system.

3. Embedded: A development project is treated to be of an embedded type, if the

software being developed is strongly coupled to complex hardware, or if the stringent
regulations on the operational method exist.
 For Example: ATM, Air Traffic control.

Estimation of development effort

For the three classes of software products, the formulas for estimating the effort based on
the code size are shown below:

Organic: Effort = 2.4(KLOC) 1.05 PM

Semi-detached: Effort = 3.0(KLOC) 1.12 PM

Embedded: Effort = 3.6(KLOC) 1.20 PM

Estimation of development time

For the three classes of software products, the formulas for estimating the development
time based on the effort are given below:

Organic: Tdev = 2.5(Effort) 0.38 Months

Semi-detached: Tdev = 2.5(Effort) 0.35 Months

Embedded: Tdev = 2.5(Effort) 0.32 Months

The basic COCOMO model can be obtained by plotting the estimated characteristics for
different software sizes.

The below figure shows a plot of estimated effort versus product size. From fig, we can
observe that the effort is somewhat superliner in the size of the software product. Thus, the
effort required to develop a product increases very rapidly with project size.
The development time versus the product size in KLOC is shown in below figure. From fig it
can be observed that the development time is a sub linear function of the size of the
product, i.e. when the size of the product increases by two times, the time to develop the
product does not double but rises moderately. A larger number of activities which can be
carried out concurrently can be identified. The parallel activities can be carried out
simultaneously by the engineers. This reduces the time to complete the project.

For example, a 60 KLOC program can be developed in approximately 18 months,

regardless of whether it is of organic, semidetached, or embedded type.

Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and
development time for each of the three model i.e., organic, semi-detached & embedded.

Solution: The basic COCOMO equation takes the form:

Effort=a1*(KLOC)a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC

(i)Organic Mode

E = 2.4 * (400)1.05 = 1295.31 PM

D = 2.5 * (1295.31)0.38=38.07 PM

(ii)Semidetached Mode

E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM

(iii) Embedded Mode

 E = 3.6 * (400)1.20 = 4772.81 PM
D = 2.5 * (4772.8)0.32 = 38 PM

13. What is Halstead’s software science? Explain [7M] [Evaluating].

Halstead's Software Science is a set of metrics developed by Maurice H. Halstead in the

late 1970s to measure various properties of software programs. It is part of the broader field
of software metrics, which focuses on quantifying software characteristics to evaluate
complexity, quality, or maintainability.

Halstead's metrics are derived from the basic elements of a program: operators and operands.
It assumes that the complexity of a program can be evaluated based on the number and
variety of these elements. The key idea is to measure the mental effort required to develop,
understand, or maintain a piece of software.

Metrics in Halstead’s Software Science:

1. Operands and Operators:

o Operands: The variables, constants, and data items used in the program.
o Operators: The symbols or keywords that perform operations (e.g., +, -, if, while).

2. Basic Measures:

n1 = Number of distinct operators.

n2 = Number of distinct operands.
N1 = Total number of occurrences of operators.
N2 = Total number of occurrences of operands.
Program length (N):
This is the total number of operator and operand occurrences in the
program.
Vocabulary size (n):
This is the total number of distinct operators and operands in the program.
Program volume (V):
This is the product of program length (N) and the logarithm of vocabulary
size (n),
i.e., V = N*log2(n)
Program level (L):
This is the ratio of the number of operator occurrences to the number of
operand occurrences in the program,
i.e., L = n1/n2
where n1 is the number of operator occurrences and n2 is the number of
operand occurrences.

Program difficulty (D):

This is the ratio of the number of unique operators to the total number of
operators in the program,
i.e., D = (n1/2) * (N2/n2)
Program effort (E):
This is the product of program volume (V) and program difficulty
(D), i.e., E = V*D
Time to implement (T):
This is the estimated time required to implement the program, based on
the program effort (E) and a constant value that depends on the
programming language and development environment.

Halstead’s Software Metrics are:

Halstead Program Length

Halstead Program Length (N) in Halstead’s Software Metrics refers to the
total number of tokens in a program. Where tokens are the smallest
individual units of code such as operators, operands, keywords, and
identifiers.
N = N1 + N2

The estimated program length is denoted by N^ and is given by the

formula:
N^ = n1log2n1 + n2log2n2
Several alternative formulas have been proposed to estimate program
length, including:

NJ = log2(n1!) + log2(n2!)NB = n1 * log2n2 + n2 * log2n1NC = n1 *

sqrt(n1) + n2 * sqrt(n2)NS = (n * log2n) / 2
Halstead Vocabulary
The total number of unique operators and unique operand occurrences.
n = n1 + n2
Program Volume
Proportional to program size, represents the size, in bits, of space
necessary for storing the program. This parameter is dependent on
specific algorithm implementation. The properties V, N, and the number of
lines in the code are shown to be linearly connected and equally valid for
measuring relative program size.
V = Size * (log2 vocabulary) = N * log2(n)

Potential Minimum Volume

The potential minimum volume V* is defined as the volume of the most
succinct program in which a problem can be coded.
V* = (2 + n2*) * log2(2 + n2*)
Here, n2* is the count of unique input and output parameters.

 The accuracy of these metrics depends on consistent measurement of operators and operands.

Halstead’s Software Science remains influential in software engineering, particularly in static

code analysis and complexity measurement.

Example: Obtain Halstead’s length and volume measure for following C function.

Void swap (int a[ ], int i)

int temp;

Temp = a[i];

a[i] = a[i+1];

a[i+1] = temp;

}
N = N1 + N2

= 16 +21= 37

N = 37

n = n1 + n2

= 5 + 9 = 14

n = 14

Estimated length = n1 log n1 + n2 log n2

= 5 log 5 + 9 log 9

= 5 * 2.32 + 9 * 2.19 = 31.37

Estimated length = 31.37

Volume = N * log n
= 37 * log (14)

37 * 2.63 = 97.64

Volume (V) = 97.64

14. Define risk management? Explain it. [7M] [Understanding].

Sol: Risk management involves identifying, assessing, and prioritizing risks to

minimize, monitor, and control the impact of potential threats. It’s a critical
process across industries to ensure organizations can achieve objectives while
navigating uncertainties. Here's a breakdown of the key components of risk
management:

(Or) Risk Management is a systematic process of recognizing, evaluating, and

handling threats or risks that have an effect on the finances, capital, and overall
operations of an organization. These risks can come from different areas, such as
financial instability, legal issues, errors in strategic planning, accidents, and
natural disasters.

The risk management process

Risk management is a sequence of steps that help a software team to understand,
analyze, and manage uncertainty. Risk management process consists of

 Risks Identification.
 Risk Assessment.
 Risks Planning.
 Risk Monitoring

Risk Identification
Risk identification refers to the systematic process of recognizing and
evaluating potential threats or hazards that could negatively impact an
organization, its operations, or its workforce. This involves identifying various
types of risks, ranging from IT security threats like viruses and phishing
attacks to unforeseen events such as equipment failures and extreme weather
conditions.

Risk analysis
Risk analysis is the process of evaluating and understanding the potential
impact and likelihood of identified risks on an organization. It helps determine
how serious a risk is and how to best manage or mitigate it. Risk Analysis
involves evaluating each risk’s probability and potential consequences to
prioritize and manage them effectively.

Risk Planning
Risk planning involves developing strategies and actions to manage and
mitigate identified risks effectively. It outlines how to respond to potential
 risks, including prevention, mitigation, and contingency measures, to protect
the organization’s objectives and assets.

Risk Monitoring
Risk monitoring involves continuously tracking and overseeing identified risks
to assess their status, changes, and effectiveness of mitigation strategies. It
ensures that risks are regularly reviewed and managed to maintain alignment
with organizational objectives and adapt to new developments or challenges.

Topic : Requirements gathering and analysis

15. Explain software requirements document. [7M] [DEC -2022]

[Understanding].

A Software Requirements Document (SRD) is a formal document that outlines the specific
requirements of a software system to be developed. It serves as a critical communication tool
between stakeholders, such as business analysts, developers, testers, and project managers,
ensuring everyone understands what the software must accomplish. It acts as a blueprint for the
software development process, guiding the design, implementation, and testing phases.

Components of an SRD

1. Introduction
o Purpose: Explains why the document exists and its objectives.
o Scope: Defines the boundaries and features of the software.
o Definitions/Abbreviations: Lists key terms for clarity.
o Stakeholders: Identifies the people or entities involved.
2. Overall Description

 System Overview: High-level description of the system's purpose.

 User Needs: Explains the needs and goals the system will fulfill.
 Assumptions/Constraints: Details any limitations or assumptions for development.

3. Functional Requirements

 Describes the specific features and behaviors the software must have.
 Includes user interactions, data handling, and workflows.
 Typically organized into modules or use cases.

4. Non-Functional Requirements

 Performance, scalability, reliability, security, and usability specifications.

 These describe how the system performs rather than what it does.

5. System Interfaces

 Details how the system will interact with other systems, software, or hardware.
  Includes APIs, databases, and user interfaces.

6. Data Requirements

 Defines data inputs, outputs, storage needs, and formats.

 Includes schemas, data flow diagrams, or other data modeling tools.

7. Acceptance Criteria

 Specifies the conditions under which the software will be considered complete and
satisfactory.

[Link]

 Includes references, supporting diagrams, or supplementary details.

The Software Requirements Document is essential to the success of software projects, ensuring that the
delivered product meets business needs and user expectations.

16. Explain Requirements gathering and analysis? [7M][Feb – 2022]

[Evaluating].

Requirements Gathering and Analysis

Requirements gathering and analysis is a crucial phase in the software development lifecycle
(SDLC) or any project management process. This phase ensures that the project delivers value
by understanding what the stakeholders need and converting those needs into actionable
requirements.

Requirements gathering is a critical phase in the software development

lifecycle, and it involves several subprocesses to ensure a
comprehensive understanding of the project's needs. The main
subprocesses include:

1. Requirements Gathering

This involves collecting information about the expectations and needs of stakeholders. The main
goal is to understand what the system or product should do from the perspective of all
stakeholders, including end-users, clients, and business owners.

Activities:

 Identify stakeholders: Determine who is involved in or impacted by the project.

 Elicit requirements: Use techniques like:
 Interviews: Directly asking stakeholders about their needs.

Surveys/Questionnaires: Collecting information from larger groups.

Workshops/Focus Groups: Collaborating with stakeholder.

Workshops/Focus Groups: Collaborating with stakeholders to brainstorm.

Observation: Watching how users interact with existing systems.

Document analysis: Reviewing existing documentation or workflows.

Prototyping: Creating early models or mockups for feedback.

2. Requirements Analysis

Once the requirements are gathered, the next step is to refine, validate, and prioritize them. This
ensures the requirements are clear, complete, consistent, and feasible.

Activities:

 Categorization: Separate functional requirements (what the system does) from non-functional
requirements (performance, security, scalability).
 Feasibility Study: Assess whether the requirements can be implemented within the budget,
timeframe, and technology constraints.
 Conflict Resolution: Address discrepancies or conflicting requirements among stakeholders.
 Prioritization: Rank requirements based on importance, urgency, and value.
 Validation: Ensure requirements align with business goals and stakeholder needs.
 Documentation: Formalize requirements into clear, concise formats like:
o SRS (Software Requirements Specification): A detailed description of all system
requirements.
o User Stories: High-level descriptions of system features from an end-user perspective.

17. a) What are various steps are to be followed in Requirement Analysis? Discuss.
[7M]

Requirements Analysis Process

A requirements analysis process involves the following steps:

Step 1: Identify Key Stakeholders and End-Users

The first step of the requirements analysis process is to identify key stakeholders
who are the main sponsors of the project. They will have the final say on what
should be included in the scope of the project.

Next, identify the end-users of the product. Since the product is intended to satisfy
their needs, their inputs are equally important.

Step 2: Capture Requirements

Ask each of the stakeholders and end-users their requirements for the new product.
Here are some requirements analysis techniques that you can use to capture
requirements:

1. Hold One-On-One Interviews

Interview each stakeholder and end-user individually. This technique will help you
gather specific requirements.

2. Use Focus Groups

Conduct group interviews or group workshops to understand the flow of information

between different stakeholders and end-users. This technique will ensure that there
will be no conflict of interest later on during the project.

3. Utilize Use Cases

Use cases provide a walkthrough of the entire product through the eyes of the end-
user. This technique will help visualize how the product will actually work.

4. Build Prototypes

A prototype provides users a sample look and feel of the final product. This
technique will help address feasibility issues and identify problems ahead of time.

Step 3: Categorize Requirements

Since requirements can be of various types, they should be grouped to avoid

confusion. Requirements are usually divided into four categories:
 Functional Requirements: Functions the product is required to perform.

 Technical Requirements: Technical issues to be considered for the successful

implementation of the product.

 Transitional Requirements: Steps required to implement a new product

smoothly.

 Operational Requirements: Operations to be carried out in the backend for

proper functioning of the product.

Step 4: Interpret and Record Requirements

Once the requirements are categorized, determine which requirements are actually
achievable and document each one of them. Here are some techniques to analyze
and interpret requirements:

Define Requirements Precisely

Ensure that the requirements are clearly worded, sufficiently detailed, and related to
business needs.

Prioritize Requirements

Prioritize requirements and list them out based on which ones are the “most critical”
and which ones are just “nice-to-have”.

Carry Out an Impact Analysis

Carry out an impact analysis to make sure that you fully understand the
consequences of the requirements.

Resolve Conflicts

Arrange a meeting with key stakeholders and resolve conflicting requirements. You
can also perform a scenario analysis to explore how the requirements would work
for different possible scenarios.

Analyze Feasibility

Perform a detailed analysis of the product based on the requirements gathered to

determine its reliability and to identify any major problems.
 Once all the requirements are analyzed, create a detailed written document and
circulate it among the key stakeholders, end-users and development teams.

Step 5: Sign off

Once a final decision is made on the requirements, ensure that you get a signed
agreement from the key stakeholders. This is done to ensure that there are no
changes or uncontrolled growth in the scope of the project

18. What is requirements analysis and explain tools used to do it? [7M] [DEC - 2023,
Set - 2] [Understanding].

Requirements analysis is the process of identifying, documenting, and managing the needs and
expectations of stakeholders for a project, product, or system. It involves understanding what is
required to achieve the project's goals and ensuring that the requirements are complete, clear, and
feasible. The primary goal is to define and document the system’s functionalities and constraints to
guide the development process.

Steps in Requirements Analysis:

1. Elicitation: Gathering requirements from stakeholders through interviews, surveys,

observations, or workshops.
2. Analysis: Refining, prioritizing, and validating the requirements.
3. Specification: Documenting the requirements in a clear and structured format.
4. Validation: Ensuring the requirements align with stakeholders' needs and are feasible for
implementation.
5. Management: Maintaining and updating requirements throughout the project lifecycle.

Tools Used in Requirements Analysis

Several tools and techniques are used to facilitate the requirements analysis process. These
include:

1. Requirement Elicitation Tools

 Interviews and Workshops: Face-to-face discussions or collaborative sessions with

stakeholders.
 Surveys and Questionnaires: Structured methods to collect feedback from a larger audience.
 Focus Groups: Engaging small groups of stakeholders to discuss their needs and expectations

2. Documentation and Modeling Tools

 Microsoft Word/Google Docs: To create requirement documents.

  Microsoft Excel/Google Sheets: For tabular requirement tracking.
 Case Tools (Computer-Aided Software Engineering): Software like Rational Rose and Enterprise
Architect for modeling requirements.

3. Diagramming and Visualization Tools

 Flowcharts: Tools like Lucidchart and Visio to visualize workflows and processes.
 Unified Modeling Language (UML): Tools like StarUML and Visual Paradigm to create use-case
diagrams, class diagrams, etc.
 Mind Mapping Tools: MindMeister or XMind for brainstorming and organizing ideas.

4. Prototyping Tools

 Figma, Sketch, or Adobe XD: For designing wireframes and low-fidelity prototypes.
 Axure RP or Balsamiq: For creating interactive prototypes to gather user feedback.

5. Requirements Management Tools

 Jira or Trello: For tracking and managing requirements in agile projects.

 IBM DOORS: A dedicated tool for managing and tracing requirements.
 ReQtest or Helix RM: Tools designed specifically for requirements tracking and collaboration.

6. Analysis and Validation Tools

 Traceability Matrices: Often created using Excel or specialized tools like Jama Connect to map
requirements to design, testing, and implementation phases.
 Simulation Tools: Tools like MATLAB and Simulink for validating complex requirements.
 Peer Reviews and Walkthroughs: Collaborative sessions to validate and refine requirements.

By combining these tools and techniques, teams can ensure that the requirements are
thoroughly understood, documented, and aligned with stakeholders’ needs, leading to
successful project outcomes.

Topic: Software Requirements Specification (SRS), Formal system

specification, Axiomatic specification, Algebraic specification, Executable
specification and 4GL.

19. Discuss about Software Requirements Specification (SRS)?[Aug/Sep-

2021][7M] [Remembering]

A software requirements specification (SRS) is a detailed description of a software system to be

developed with its functional and non-functional requirements. The SRS is developed based the
agreement between customer and contractors. It may include the use cases of how user is going
to interact with software system. The software requirement specification document consistent
of all necessary requirements required for project development. To develop the software
 system we should have clear understanding of Software system. To achieve this we need to
continuous communication with customers to gather all requirements. A good SRS defines the
how Software System will interact with all internal modules, hardware, communication with
other programs and human user interactions with wide range of real life scenarios. Using the
Software requirements specification (SRS) document on QA lead, managers creates test plan. It
is very important that testers must be cleared with every detail specified in this document in
order to avoid faults in test cases and its expected results.

It is highly recommended to review or test SRS documents before start writing test cases and
making any plan for testing. Let’s see how to test SRS and the important point to keep in mind
while testing it.

Classifications of Software Requirements

Other common classifications of software requirements can be:
1. User requirements: These requirements describe what the end-
user wants from the software system. User requirements are usually
expressed in natural language and are typically gathered through
interviews, surveys, or user feedback.
2. System requirements: These requirements specify the technical
characteristics of the software system, such as its architecture,
hardware requirements, software components, and interfaces. System
requirements are typically expressed in technical terms and are often
used as a basis for system design.
3. Business requirements: These requirements describe the
business goals and objectives that the software system is expected to
achieve. Business requirements are usually expressed in terms of
revenue, market share, customer satisfaction, or other business
metrics.
4. Regulatory requirements: These requirements specify the legal or
regulatory standards that the software system must meet. Regulatory
requirements may include data privacy, security, accessibility, or other
legal compliance requirements.
5. Interface requirements: These requirements specify the
interactions between the software system and external systems or
components, such as databases, web services, or other software
applications.
6. Design requirements: These requirements describe the technical
design of the software system. They include information about the
software architecture, data structures, algorithms, and other technical
aspects of the software.
 20. Define the terms following

a) Formal system specification

A formal system specification is a rigorous and precise description of a software system's

requirements, behavior, and design. It uses mathematical notations, logical expressions, and
structured techniques to define system components, interactions, and constraints, ensuring clarity,
consistency, and correctness.

Advantages of Formal System Specifications

 Precision: Eliminates ambiguity by using formal notations.

 Verification: Enables rigorous testing and mathematical proofs of correctness.
 Consistency: Reduces contradictions and ensures all parts of the system work together.
 Automation: Allows automated analysis, validation, and verification.
 Clarity: Improves communication among stakeholders with an unambiguous framework.

b) Algebraic specification

Algebraic specification is a formal method used to describe and reason about abstract data types
(ADTs) and software systems. It defines systems or data types in terms of their operations and the
algebraic properties those operations must satisfy. This approach is particularly useful in software
engineering, formal verification, and theoretical computer science.

Advantages of Algebraic Specification:

1. Precision: Describes operations and their relationships mathematically, leaving no ambiguity.

2. Modularity: Systems can be specified in parts and combined systematically.
3. Implementation Independence: Focuses on behavior, not how it is achieved.
4. Formal Reasoning: Provides a foundation for formal verification and correctness proofs.

c) Executable specification

An executable specification refers to a specification or a description of a system or its behavior that is

written in such a way that it can be directly executed by a machine. This concept is often used in
software development to bridge the gap between requirements and implementation, ensuring that
the system behaves exactly as described. It is especially used in contexts like behavior-driven
development (BDD) or test-driven development (TDD), where the specification is often written in a
human-readable language and can be executed to verify the correctness of the system.
[Aug/Sep-2021][7M] [Evaluating]

21. Discuss about 4GL? [7M] [Remembering]

 A Fourth Generation (Programming) Language (4GL) is a grouping of
programming languages that attempt to get closer than 3GLs to human language,
a form of thinking, and conceptualization and are easier to use than 3GLs. It is a
non-procedural language which means that the programmer defines what has to
be done instead of how the task is to be completed.I4GL is more familiar and
similar to human language. A compiler translates the whole program once i.e. it
generates the object code for the program along with the list of errors. The
execution is very fast. It allows users to develop software. These languages are
usually designed for specific purposes and are commonly used in database
programming and scripts such as PHP, Python, SQL, and many more. 4GLs make
programming easier, more efficient, and more effective for users with less
programming skills.

4th generation language is also known as a domain-specific language or a high-

productivity language.

Fourth-generation languages (4GL) are a type of programming language designed to be more

user-friendly and closer to human language than traditional third-generation languages (3GL)
like C, Java, or Python. The goal of 4GLs is to allow users to develop applications quickly,
without needing to focus on the intricate details of hardware or low-level programming.

1. High-Level Abstraction

4GLs are more abstract than 3GLs, which means developers don’t have to manually manage
memory, variables, or low-level logic. They typically allow users to express complex ideas in
fewer lines of code.

2. Declarative Nature

Most 4GLs are declarative, meaning you specify what you want the program to do, rather than
how to do it. For example, in database management, a 4GL might let you specify "find all
records where the age is greater than 18" without needing to write the underlying SQL query or
implement the logic for searching.

3. Database-Oriented

Many 4GLs are closely tied to databases and are often used in developing applications with
significant database interaction. Languages like SQL, which is inherently a 4GL, are built around
this concept. These languages allow users to interact with the database in a more abstract and
simplified manner, focusing on queries and data manipulation rather than on the technical details
of storage and retrieval.

4. Rapid Application Development (RAD)

4GLs are designed to speed up software development, and are often used in environments where
rapid prototyping is required. Tools based on 4GLs provide a set of prebuilt templates,
components, and user interface elements that developers can leverage to quickly create
applications.

Examples of 4GLs

 SQL (Structured Query Language): The most common 4GL, used for database querying.
 ABAP: A language developed by SAP for developing business applications.
 MATLAB: Used for numerical computing and data analysis, focusing on matrix operations.
 SAS: Used for statistical analysis, primarily in the fields of data science and analytics.

22. Explain the steps in formal system specification? [7M][June/July -

2022][Evaluating]

sol: A formal system specification is a rigorous and precise description of a software system's
requirements, behavior, and design. It uses mathematical notations, logical expressions, and structured
techniques to define system components, interactions, and constraints, ensuring clarity, consistency,
and correctness.

syntactic domains: