Computerworld - Two questions have often bothered me about software work.

First, why
do competent software professionals agree to completion dates when they have no idea
how to meet them? Second, why do rational executives accept schedule commitments
when the engineers offer no evidence that they can meet those commitments? Where
software is concerned, many otherwise hardheaded executives willingly accept vague
promises and incomplete plans. Management's undisciplined approach to schedule
commitments contributes to every one of the five most common causes of project failure:

Unrealistic Schedules
You might think that pushing for an aggressive schedule would accelerate the work, but it
actually delays it. When faced with an unrealistic schedule, engineering teams often
behave irrationally. They race through the requirements, produce a superficial design and
rush into coding. This mad scramble to build something - anything - results in a poor-
quality product that has the wrong functions, is seriously defective and is late.

Inappropriate Staffing
The only way to complete an engineering project rapidly and efficiently is to assign an
adequate number of people and then protect them from interruptions and distractions.
This helps build the motivation and effective teamwork needed for quality results. When
managers fail to provide timely, adequate and properly trained resources, their projects
will generally fail.

Changing Requirements During Development

To start designing and building products, engineers must know what product to build.
Unfortunately, management, marketing and even customers often don't know what they
want. Worse, they think they know and then change their minds partway through the job.
While the requirements (or objectives) normally change in the early phases of a job,
there's a point beyond which changes will waste time and money and disrupt the work.

Poor-Quality Work
Consider the case of Greg, manager of a manufacturing software project that had to meet
an accelerated delivery date set by his boss. Greg unmercifully pushed his engineers, who
rushed through the design and coding and skipped all of the quality reviews and
inspections. Testing found many defects, but Greg argued for delivering the software and
fixing defects later. Greg met the deadline, but the system was a disaster. It was so
unreliable that the software had to be fixed every time a change was made in the product
or product mix. Excessive factory downtime and repairs cost the company over $1
million. When executives push for unrealistic schedules, the project either will be late in
delivering a working product or will produce a product that doesn't work. There's a
saying about software quality: "If it doesn't have to work, we can build it really fast."

Believing in Magic
Commercial off-the-shelf software, or COTS, is an attractive way to save development
time and money. But COTS isn't a silver bullet. If not properly managed, it can be a
disaster. A COTS product that works perfectly in demonstrations, for example, may crash
when subjected to different hardware configurations, higher data rates or even data-entry
errors. You must test the product thoroughly enough to expose previously untested
conditions. If the program is troublesome when stress-tested, it will almost certainly be
troublesome when used in production.
- Watts S. Humphrey
Humphrey is a fellow at the Software Engineering Institute at Carnegie Mellon
University, where he led the Capability Maturity Model effort and other work to improve
software development. This article is adapted, with permission, from Winning With
Software: An Executive Strategy (Addison-Wesley, 2002).

Why Do Software Projects Fail?

"What are the chances that this project will succeed?"
For most companies and entrepreneurs starting on a new software project, this is one of
the first questions that are considered. Unfortunately, the question is a very relevant one.
Studies conducted by major research groups show that 50% of software projects fail
today.
Why do software projects fail? Are there preventive measures to avoid software project
failure?
A recent research project at 'The Standish Group' has identified reasons for software
project failure. Lets have a look at the results of the research project.
For purposes of the study, projects were classified into three resolution types –
Resolution Type 1 or project success, Resolution Type 2 or project challenged and
Resolution Type 3 or project impaired.

Resolution Type 1 or project success:

The software project is completed on-time and on-budget, with all features and functions
as initially specified.
Among the Project Success Factors, it was noted that ' Clear Statement of Requirements'
was ranked third in importance for the success of a project, after User Involvement and
Executive management Support.

Resolution Type 2 or project challenged:

The software project is completed and operational but over-budget, over the time
estimate, and offers fewer features and functions than originally specified.
'Incomplete Requirements and Specifications' was cited as the second main reason for
exceeding the budget and time
 Resolution Type 3 or project impaired:
The software project is canceled at some point during the development cycle. Here again,
Incomplete Requirements was the main reason cited for the failure of the software
project.
Overall, the success rate was only 16.2%. Challenged projects accounted for 52.7%, and
impaired (canceled) for 31.1%.
The table below lists the criteria for software project success in order of importance.
SUCCESS CRITERIA POINTS
1. User Involvement 19
2. Executive Management Support 16
3. Clear Statement of Requirements 15
4. Proper Planning 11
5. Realistic Expectations 10
6. Smaller Project Milestones 9
7. Competent Staff 8
8. Ownership 6
9. Clear Vision & Objectives 3
10. Hard-Working, Focused Staff 3
TOTAL 100
The chart clearly shows that 3 major factors greatly influence the success of a project -
User Involvement, Executive Management Support and Clear Statement of
Requirements.
Out of these, “Clear Statement of Requirements” scores 15 points and is one among
the top 3 reasons for the success or failure of a Software Project. It is clear therefore that
Requirement Definition is a crucial step in Software Development. Read about our
Requirement Analysis process here.

Requirements Evolution
Requirements & Analysis is one of the most important and often most neglected activities
of the software development life cycle. A good requirements model fosters
communication between the business and IT by enabling them to share a common vision
of the system’s solution prior to implementation. This will ensure that the system meets
the business needs, can be delivered on time, and have the level of quality and flexibility
to easily accommodate future business needs.

Requirement Capture and Analysis - The Difference

Requirements Analysis

• To determine • To describe what the customer requires

what needs to
be built • To understand what will be built

• To • To understand why it should be built

understand
users and • To determine how much it is likely to cost.
their (estimation)
potential • To determine the order in which should be built
usage of (prioritization)
the system.
• To understand the system itself and explore the details
• To of the problem domain
determine
what users • To understand how it will be built
want to
have built. • To identify and translate business goals and needs
into system features, and use them to derive both
functional and nonfunctional (technical) system
requirements

• To ensure that it represents the middle ground

between requirements and design

• To define a set of requirements that can be validated

• To establish a basis for the creation of a software

design
How can we ensure that we have specified a system that properly meets the
customer’s needs and satisfies the customer’s expectations?
There is no foolproof answer to this difficult question, but a solid requirements
engineering process is the best solution we currently have.
Requirements engineering provides the appropriate mechanism for understanding what
the customer wants, analyzing needs, assessing feasibility, negotiating a reasonable
solution, specifying the solution unambiguously, validating the specification and
managing requirements as they are transformed into an operational system. The
requirements engineering process can be described in five distinct steps-

• Requirements Elicitation
• Requirements Analysis and negotiation

• Requirements Specification

• System modeling

• Requirements Validation

• Requirements Management