Unit 1 Requirement Analysis

Unit 1
Software Project Management

Software project management is the art and science of planning and leading
software projects. It is a sub-discipline of project management in which software projects are
planned, monitored and controlled.

Activities covered by software project management:

Feasibility Study How do

we do
it?
doing
?
wort
h
Is i t
Plan Do it!

Project execution

The feasibility study/plan/execution cycle

What Is a Requirement?

Although many definitions of software requirements have been used throughout the years, the
one provided by requirements engineering authors Dorfman and Thayer (1990) is quite
workable:
o A software capability needed by the user to solve a problem to achieve an objective
o A software capability that must be met or possessed by a system or system component
to satisfy a contract, standard, specification, or other formally imposed documentation

Requirements Management

Software Project Management Page 1

 Unit 1 Requirement Analysis

Requirement management is a systematic approach to eliciting, organizing, and

documenting the requirements of the system, and a process that establishes and maintains
agreement between the customer and the project team on the changing requirements of the
system. Requirements management includes organizing, prioritizing, controlling access to,
and providing resources for the various requirements.
Software Requirements
Once we have established the feature set and have gained agreement with the
customer, we can move on to defining the more specific requirements that we will need to
impose on the solution. If we build a system that conforms to those requirements, we can be
certain that the system we develop will deliver the features we promised. In turn, since the
features address one or more stakeholder needs, we will have addressed those needs directly
in the solution. These more specific requirements are the software requirements. We'll
represent them as a block within our pyramid in a similar manner to the features. We also
note that these appear pretty far down on the pyramid, and this implies, correctly, that we
have much work to do before we get to that level of specificity later in the book.

Requirements analysis

Requirements analysis encompasses those tasks that go into determining the needs
or conditions to meet for a new or altered product, taking account of the possibly conflicting
requirements of the various stakeholders, such as beneficiaries or users.

Requirements analysis is critical to the success of a development project.

Requirements must be documented, actionable, measurable, testable, related to identified
business needs or opportunities, and defined to a level of detail sufficient for system design.
Requirements can be architectural, structural, behavioural, functional, and non-functional.

The Software Team

The history of software development is one of increasing scale. Initially, a few

individuals could hand craft small programs; the work soon grew beyond them. Teams of one
or two dozen individuals were then used, but success was mixed. While many organizations
have solved these small-system problems, the scale of our work continues to grow. Today,
large projects typically require the coordinated work of many teams.
Software Project Management Page 2
 Unit 1 Requirement Analysis

Requisite Team Skills for Effective Requirements Management

1) Analyzing the Problem, we develop a set of techniques the team can use to
gain a proper understanding of the problem that a new software system is
intended to solve.
2) Understanding User Needs, we introduce a variety of techniques the team can
use to elicit requirements from the system users and stakeholders.
3) Defining the System, we describe the initial process by which the team
converts an understanding of the problem and the user's needs to the initial
definition of a system that will address those needs.
4) Managing Scope, we arm the team with the ability to do a better job of
managing the scope of the project.
5) Refining the System Definition, we help the team organize the requirements
information. Further, we introduce a set of techniques the team can use to
elaborate on the system definition, or refine it to a level suitable to drive
design and implementation, so that the entire extended team knows exactly
what kind of system it is building.
6) Building the Right System, we cover some of the more technical aspects of
design assurance, verification, validation testing, and change management,
and we show how traceability can be used to help ensure a quality outcome.
The Organization of Software Teams

Software development is exceedingly complex, and the domains in which we apply

our skills vary tremendously. It therefore seems unlikely that one specific way to organize a
software team will work in all cases or is inherently more efficient than other approaches.
Nonetheless, certain common elements occur in many successful teams. Therefore, we think
it's important to establish a hypothetical team construct. But rather than invent an ideal team,
which would be too easy and too academic, we decided to pattern our hypothetical team on a
real software development team.
The team we'll model is based on a real-world software team that has proved effective in two
major areas:
(1) Effective requirements management

Software Project Management Page 3

 Unit 1 Requirement Analysis

(2) Delivering on time and on budget. (Of course, we believe that this is an obvious cause-
and-effect relationship!)

Analyzing the Problem

The last few years have seen an unprecedented increase in the power of the tools and
technologies that software developers use to build today's enterprise applications. As the
productivity of the software development environment has increased, it should now be easier
than ever before to develop systems that satisfy real business needs. However, the data
demonstrates that we remain challenged in our ability to truly understand and to satisfy these
needs. The resulting systems do not fit the needs of the users and stakeholders as well as
could have been reasonably expected. The consequences of this mismatch are inadequate
economic reward for the customers and developers of the system, dissatisfied users, and
career challenges. It seems obvious, therefore, that an incremental investment in an analysis
of the problem will produce handsome rewards downstream. The goal of this team skill is to
provide guidelines for problem analysis and to define specific goals for this skill in
application development.

Five Steps in Problem Analysis

1) Gain agreement on the problem definition.
2) Understand the root causes—the problem behind the problem.
3) Identify the stakeholders and the users.
4) Define the solution system boundary.
5) Identify the constraints to be imposed on the solution.

Gain Agreement on the Problem Definition

The first step is to gain agreement on the definition of the problem to be solved. One
of the simplest ways to gain this agreement is to simply write the problem down and see
whether everyone agrees.
Understand the Root Causes—the Problem behind the Problem

Software Project Management Page 4

 Unit 1 Requirement Analysis

There are variety of techniques to gain an understanding of the real problem and its
real causes. One such technique is "root cause" analysis, which is a systematic way of
uncovering the root, or underlying, cause of an identified problem or a symptom of a
problem. There are certain methods for identifying the problem behind the problem. They are
• Fishbone diagram
• Pareto analysis

Fishbone diagram of root causes

In fish bone diagram method each source was listed as one of the "bones" on the
diagram. Once the root causes are listed on the "bones" of the diagram, the materiality, or
contribution, of each root cause is determined. The results of this investigation can be plotted
as a Pareto chart.

Pareto chart of root causes

Identify the Stakeholders and the Users

Software Project Management Page 5

 Unit 1 Requirement Analysis

Effectively solving any complex problem typically involves satisfying the needs of a
diverse group of stakeholders. Stakeholders will typically have varying perspectives on the
problem and various needs that must be addressed by the solution.

Define the Solution System Boundary

Once the problem statement is agreed to and the users and stakeholders are identified,
we can turn our attention to defining a system that can be deployed to address the problem. In
so doing, we enter an important transition state wherein we have to keep two things in mind:
an understanding of the problem and the considerations of a potential solution.
The next important step is to determine the boundaries of the solution system. The
system boundary defines the border between the solution and the real world that surrounds
the solution. In other words, the system boundary describes an envelope in which the solution
system is contained. Information, in the form of inputs and outputs, is passed back and forth
from the system to the users living outside the system. All interactions with the system occur
via interfaces between the system and the external world.

System boundary

Identify the Constraints to Be Imposed on the Solution

Before launching a well-intended trillion-dollar effort to revolutionize the state of the

art in sales order entry, we must stop and consider the constraints that will be imposed on the
solution. We'll define a constraint as a restriction on the degree of freedom we have in
providing a solution. Each constraint has the potential to severely restrict our ability to
deliver a solution as we envision it. Therefore, each constraint must be carefully considered

Software Project Management Page 6

 Unit 1 Requirement Analysis

as part of the planning process, and many may even cause us to reconsider the technological
approach we have initially envisioned. A variety of sources of constraints must be
considered. These include schedule, return on investment, budget for labour and equipment,
environmental issues, operating systems, databases, hosts and client systems, technical issues,
political issues within the organization, purchased software, company policies and
procedures, choices of tools and languages, personnel or other resource constraints, and a
host of other considerations. These constraints may be given to us before we even begin ("No
new hardware"), or we may have to actively elicit them.

Systems engineering(SE)

Systems engineering is an interdisciplinary field of engineering that focuses on how

complex engineering projects should be designed and managed. Issues such as logistics, the
coordination of different teams, and automatic control of machinery become more difficult
when dealing with large, complex projects. Systems engineering deals with work-processes
and tools to handle such projects, and it overlaps with both technical and human-centered
disciplines such as control engineering, industrial engineering, organizational studies, and
project management.

(International Council on engineering system – INCOSE 1999)

Systems engineering is an interdisciplinary approach and means to enable the

realization of successful systems. It focuses on defining customer needs and required
functionality early in the development cycle, documenting requirements, then proceeding
with design synthesis and system validation while considering the complete problem:

Operations
• Performance
• Test
• Manufacturing
• Cost and Schedule
• Training and Support
• Disposal
Systems engineering integrates all the disciplines and specialty groups into a team
effort forming a structured development process that proceeds from concept to production to
Software Project Management Page 7
 Unit 1 Requirement Analysis

operation. Systems engineering considers both the business and the technical needs of all
customers with the goal of providing a quality product that meets the needs of the user.

Scope of Systems engineering

One way to understand the motivation behind systems engineering is to see it as a

method, or practice, to identify and improve common rules that exist within a wide variety of
systems. Systems engineering encourages the use of modelling and simulation to validate
assumptions or theories on systems and the interactions within them.

The systems engineering process

Depending on their application, tools are used for various stages of the systems
engineering process:

Software Project Management Page 8

 Unit 1 Requirement Analysis

Pragmatic Principles of Systems Engineering:

If we choose to view systems engineering as a problem analysis technique, the

specific steps, or at least the basic principles of the discipline, should provide us with the
steps we need to apply to use systems engineering to analyze the problem in our requirements
context. The INCOSE Systems Engineering Practices working group (INCOSE 1993)
defined a basic set of eight systems engineering principles.

1) Know the problem, know the customer, and know the consumer.
2) Use effectiveness criteria based on needs to make the system decisions.
3) Establish and manage requirements.
4) Identify and assess alternatives so as to converge on a solution.
5) Verify and validate requirements and solution performance.
6) Maintain the integrity of the system.
7) Use an articulated and documented process.
8) Manage against a plan.

Software Project Management Page 9

 Unit 1 Requirement Analysis

This list identifies some pragmatic systems engineering principles. In point of fact, however,
a subset of the systems engineering discipline is based on another process, the successive
decomposition of complex systems into simpler ones.

Using models

Models play important and diverse roles in systems engineering. A model can be defined
in several ways, including.

• An abstraction of reality designed to answer specific questions about the real world
• An imitation, analogue, or representation of a real world process or structure; or
• A conceptual, mathematical, or physical tool to assist a decision maker.

Software Project Management Page 10