|
Requirements
Specification
BEST PRACTICE GUIDES
The aims and objectives of this document are to:
- describe WHAT needs to be done to capture and specify
requirements
- provide checklists, questions, tips and
- highlight the risks associated with not using a structured
approach
This should be seen in the context of it being a LEVEL 2 document
where:
- LEVEL 1 is WHAT senior managers need to know headlines,
attention grabbers - a marketing document
- LEVEL 2 identifies WHAT needs to be done (the
activities)
- LEVEL 3 details WHICH processes should be used lists
the activities within, say, a procurement strategy identifies
the performance measures and risk assessment methods
- LEVEL 4 explains HOW to use the processes
1. Definition of Requirements Capture
A summary of the needs of the organisation in business, (not
technical,) terms, captured as a formal expression of user needs,
written in the light of what is technically possible but without
indicating any particular solution.
2. Measuring Return on Investment in IT
As with any other business venture, IT investment must provide
measurable and costed benefits e.g. reduced costs, improved customer
service. Assessment of the costs and benefits in this area is seen
to be difficult because most benefits do not come directly from IT
but from the information which becomes available as a result of
processing data and the enabling of cross-functional business
processes. As a result, traditional financial justification
"rules" may be inadequate. The use of Best Practice Guides
and some basic principles can help.
3. Lessons From the Past
First and second generation corporate IT investment was concerned
primarily with automating existing business processes. In general,
the ongoing potential benefits were often not fully realised because
the rationalisation of associated business processes was not
addressed or the outcome of doing so was unknown. Where they are
unknown, there is little alternative to adopting a Rapid
Applications Development or prototyping approach.
The perceived cost of the IT investment was often too limited and
concentrated on development and implementation. The most significant
costs e.g. the management of change, retraining, redeployment,
maintenance, replacement etc. were either ignored or underestimated.
Corporate, centralised, highly structured, mainframe based
proprietary systems tended to have long development cycles, were
perceived to be inflexible to a rapidly changing business
environment and exploitation of the information was rare. However,
requirements which change frequently are hard to meet. An iterative
development life cycle is more likely to keep pace with change than
a big bang approach.
Too often users have attempted to specify solutions as opposed to
requirements. The skills with which the user states requirements if
fundamental to the success of the procurement. Requirements need to
be comprehensively described and precisely identified. They must
also be expressed in a manner which allows them to be used to test
the solutions offered by suppliers.
4. Strategies for Success
4.1 Business Strategy
The creation of a Business Strategy is fundamental. It should be
considered to be the "core" around which all other
strategies are built.
4.2 IS Strategy
The IS Strategy takes the Business Strategy as the prime driver
for its activities which will include the following, (again these
are not necessarily consecutive):
IT systems need to:
- reflect the needs of the business today and accommodate future
changes
- meet the needs of information users, owners, managers and
buyers
- be rapidly implemented with a high chance of success at low
risk
Significant skill sets will be required to "get it right
first time, on time, every time".
Your core IT facilities should be viewed as business utilities
and managed or outsourced accordingly. If IT isn't your core
business then seriously consider getting out of it. But beware any
single source of supply.
Expanded services to the users, be they internal to your own
corporation or your customer, should become one of your key
objectives.
The following comparison chart attempts to identify the strengths
and weaknesses, by area, of differing IT architectures,
infrastructures and strategies.
**** = Best/Easiest * = Weakest/Difficult
| Feature |
Mainframes |
Distributed
Systems |
Downsizing |
| I.S. Structuring
Techniques |
**** |
*** |
** |
| System Security |
**** |
** |
* |
| System privacy |
*** |
*** |
** |
| O.S. Functionality |
**** |
** |
** |
| User Graphical
Interfaces |
** |
*** |
**** |
| Interoperability |
** |
**** |
*** |
| Applications Portfolio |
** |
*** |
**** |
| Applications Portability |
** |
*** |
**** |
| Backup & Recovery |
**** |
*** |
** |
| Software Maturity |
**** |
*** |
** |
| Cost/MIPS |
*** |
*** |
**** |
| Open Standards |
** |
*** |
**** |
| Hardware/Labour Ratio |
**** |
*** |
** |
4.3 Information Strategy
The Information Strategy "maps" the business processes,
determines who "owns" them and the information flows, who
owns and uses them. Using a structured approach will enable the
identification of users, owners, managers and buyers of data,
processes, systems, information and equipment. There are sub-groups
within these categories - frequent, occasional and potential users,
owners etc..
All have a part to play in defining requirements.
There must be clear linkages between a company's' maturity,
strategies, capabilities and its IT systems.
Understanding these linkages will identify issues which affect
the way people do their jobs, the need for training and the possible
need to change the structure and processes of the organisation.
- Do you understand the current processes and procedures, who
does and are they still appropriate?
- Do you know what information is required by who or is lacking?
- Do you know what skills your people have or need?
- Do you have the right skills in-house, where or how could you
get these?
4.4 Quality Strategy
Investment in the production of a "Quality Plan" will
be well rewarded.
The Quality Plan should be seen to be a fundamental part of the
natural process to complete the task, (not an expensive and time
consuming overhead).
4.5 Communications Strategy
A successful project must combat fear and prejudice, cost and
time pressures and result in a system which is still useful and
relevant to a business which may have changed due to market
pressures. Your plans need to be communicated, sold and accepted by
users.
Production of this 'marketing communications' document requires a
knowledge and understanding not just of the corporate environment
but also of people, their aims and ambitions, their position within
the hierarchy and their past experiences.
4.6 Change Strategy
In a fast changing commercial World, nothing stays the same for
very long. A strategy should be devised which will identify and plan
for change as early as possible in the overall project life-cycle.
Splitting a "system" into bite sized, modular and
prototypable chunks successfully, is probably the IT
equivalent of finding the Holy Grail. There is a need to:
- clarify user interface issues
- continually review the needs analysis to ensure a close match
to the business requirements
- consider Rapid Development tools and methods
- ensure that splitting the project into manageable chunks
doesn't incurr an unacceptable cost penalty over building a
monolith.
4.7 Project Management Strategy
IT projects are vulnerable to:
- late delivery - taking too long can be critical in an
environment where both the technology and the business is
changing so fast
- budget overrun - if the project costs exceed plan then
managers will reinforce their views that IT gives a poor return
on investment. This may lead to short-sighted decisions such as
outsourcing or facilities management.
- changing requirements/business needs
- Scope "drift" - the more requirements are amended
during development the greater the chances of disaster - at best
you may have a project which is too expensive to scrap, too
cumbersome to change and too big to manage.
Successful IT projects need a combination of business and IT
skills. You may need to buy-in these for development and
implementation but don't forget the need for high level project
management resource. Once you know where the risks lie, carry out a
skills assessment - the result may be a decision to contract-out the
whole project. In this case the need to undertake a similar
assessment of your potential suppliers is obvious.
5. Requirements Management Strategy
This is THE key customer/user role.
No assumptions should be made. The CSSA reports "We expect
our suppliers to understand the business we're in but we don't
necessarily understand it ourselves." People tend to be
absorbed by the minutiae of their daily tasks and often fail to see
the broader picture.
It is generally accepted that people find it difficult to say
what they want/need until presented with a solution. Then they are
able to say precisely what they don't want/need or like. Therefore,
within the planning stage, consideration should be given to
producing prototypes or examples to gain support and buy-in to the
eventual deliverables and manage the expectations of users.
The three main stages of requirements management strategy
definition are as follows:
Stage 1. Requirements Analysis
You will need to identify:
- who are the users/owners and managers of the data
- what they say they want and why (may not be of use to the
company)
- what they say they need and why (may be more or less than is
required)
- what they will settle for, (depends on their status in
organisation)
- the content/form/presentation & structure requirements
(human factors)
- what might be the acceptance criteria
Using a structured approach will enable the identification of
users, owners, managers and buyers of data, processes, systems,
information and equipment. There are sub-groups within these
categories - frequent, occasional and potential users, owners etc..
All may have a part to play in defining requirements.
There are a few very basic tasks which should be commenced before
any of the more traditional elements of requirements capture are
started. The project initiation period should include:
- an assessment of the value you are getting out of your current
system(s)
- ensure top level commitment to the project
- a review of your business objectives, (which this investment
must support)
These business objectives can be specified in simple measurable
terms such as:
- Increase revenue/margin by:
- ensuring increased customer satisfaction
- reducing effort/waste/rework
- reducing stock levels
- reducing or enabling redeployment of staff
The information should undergo an initial assessment which checks
its relevance to:
- company objectives
- procurement policies
- timing - how big a project - how long - how costly
- other owners/users requirements and objectives
- technical objectives, application boundaries and chances of
success
- other systems - present, planned & possible
You will need to:
- determine the feasibility or desirability of assessing
alternative technical solutions
- develop business case(s) to decision making point
Stage 2. Requirements Specification
- collate business/user/technical input to specification
- support awareness of issues, policies and procedures
- produce functional requirements, system characteristics,
system operations, design constraints, acceptance criteria and
service requirements specifications
Stage 3. Business Support and Liaison
- liaise between users and providers to ensure compliance
6. Summary
There must be clear linkages between a companys' objectives,
maturity, capabilities and its IT/IS strategies.
Understanding these linkages will identify issues which affect
the way people do their jobs, the need for training and the possible
need to change the structure and processes of the organisation.
A structured approach throughout all stages should be viewed as a
MANDATORY.
Press
here to go to managing projects mainpage < |
MANAGING PROJECTS