Avoiding Software Disasters – Remedy
Pinpointing the Problem to be Solved
So far we have shown the consequences of not defining requirements properly and
explained why requirements are difficult to define. Now it's time to look for some
answers. Incidentally, the word 'problem' is used synonymously with 'opportunity'
in this section.
Typically, the drivers for projects stem from some general malaise or prospect.
Often this is quite vague. Symptoms of problems can be experienced in the following
ways:
- Falling sales
- Escalating costs
- Low productivity
- Low profitability
- Low customer/staff/board satisfaction
- Falling share price
|
|
Similarly, opportunities are things like:
- Increase market share
- Increase profit
- Maintain competitiveness
- Improve morale
The first task in relation to a symptom is to measure its severity. This is a matter
of assessing various costs; financial costs, opportunity costs, hidden costs (after
they have been found) and human costs. If it's significant, proceed.
The second task is to root out the underlying problem. Falling sales isn't the problem,
it's the symptom. The 'real' problem might be product defect, market decline, inadequate
marketing, or a mish-mash of all these.
Once you've got to the heart of the problem, the next step is to decide whether
it's worth fixing. At this stage all that is required is a general agreement that
the matter is worth following up. What will happen if you don't do anything? What
is the likely impact if you do?
Armed with a correctly identified problem that is worthwhile, you can move to preparing
a business case.
The Business Case
Identifying and Assessing the Alternatives
The challenge now is to weigh up the alternative solutions and get business buy-in.
You need to identify the constraints and objectives of all serious alternatives.
Constraints are the things that stand between you and implementation of that particular
solution, including budget, technology, environment, people and skills.
Objectives are the things that you expect the solution to give you. What are the
basic criteria for considering a project? Can we measure our success? Are we trying
to improve gain or reduce pain?
Eliminate projects with too many constraints or too little impact.
Prepare a broad outline of the obvious risks and scope of the remaining alternatives,
including preliminary costings and timeframes. The projects that survive this step
are the ones that you want to get up.
Recommending a Solution
 In
terms of getting business buy-in this is the most important step. It is your chance
to present your vision of what the world will be like after successfully implementing
the selected project(s).
Your recommendation should be in the form of a Vision and Scope document, and include:
- Concise statement of business requirements
- Project description and goal
- High level scope (major features)
- High level cost/benefit analysis
- High level risks
- High level assumptions
- Exclusions
When you get business buy-in, then the real fun starts…
Defining and Communicating the System Requirement
So you've selected a juicy project and you've got management support; now it's time
to do the most important part of the entire software life cycle – define and
communicate the system requirement.
This is a big task and it's not something you can do by yourself. In most projects,
several people are involved in gathering requirements. A matrix of different approaches
to Requirements Gathering is presented on the third page in this menu. We remind
you that our focus is on fixed price jobs of up to around 3 years of effort.
The analyst's responsibility is to:
- Speak the customer's language
- Learn about the customer's business and objectives
- Prepare a Software Requirement Specification which accurately maps the customer's
requirements
- Accept feedback from customers on the Software Requirement Specification
The customer's responsibility is to:
- Educate analysts about the business
- Allocate resources to provide and review requirements
- Set priorities
- Make business decisions
Specifying the Requirement
Your requirements gathering will yield unwieldy amounts of data. Without structure
and context, this data may seem overwhelming, and have little chance of becoming
knowledge.
A Software Requirement Specification will allow you to structure the information
you've gathered. It's a practical document which should be designed as a blue-print
for the project. We present a template for this on the fourth page in this menu.
Verifying the Requirement
The last step is to verify your findings. It's important to submit your documentation
to all your stakeholders in order to get their feedback. The requirement definition
process isn't finished until your customer says it is.
Now you're in a commanding position to re-assess the business case and then call
for proposals or issue a tender if proceeding.
Conclusion
Remember, the consequences of not defining requirements properly can be crippling.
Follow the principles we have laid out and avoid becoming a statistic.
|