Professional Documents
Culture Documents
1
On a more serious note, I know of commercial
organisations who have identified niches in their
markets but lack the ability to be able to exploit
those niches. Their capability gap is in the form of a
lack of people, processes and tools to perform
product development in order to address those
niches with marketable solutions.
2
develop a formal understanding of the system-level
requirements that our potential solutions must meet
if they are to satisfy stakeholder and business needs.
3
invariably exist and limit the options open to the
organisation in terms of the ultimate solution to their
business needs.
4
Examples of typical stakeholders might include
representatives from management who are directly
impacted by the system or the need that the system
is being designed to satisfy.
5
Once we have the right stakeholders on board and we
understand the constraints under which we are
operating, the stakeholders are able to start working
on developing an appreciation of the business needs
that are driving the requirement for a new system.
6
Some of these concepts will be supported by the
scenarios that have already been developed but it is
important for business stakeholders to explain their
concepts, thoughts, and expectations in relation to:
- How the system will be operated (sometimes called
an Operational Concept or OpsCon)
- How the system will be acquired (called an
acquisition concept covering things like the expected
use of contractual models arrangements and so on)
- How the system will be deployed or transitioned
from the acquisition phase to the utilisation phase
- How the system will be supported during the
utilisation phase including ideas for contracted
support versus in house support and so on
- And how the system will ultimately be disposed of
including expectations, constraints or requirements
associated with disposal.
7
agent.
PART 2
It is now time to translate the business needs into
more formal business requirements.
8
most likely solution option when looking at
requirements. This avoids wasted effort and also
focuses the business requirements, making them
more useful in the following stages.
9
We have endorsed Business Needs and Requirements
from the previous work. This shows that
management are confident that there is a need
existing for a new or improved system and that they
understand those needs sufficiently to move on with
the process. We have a preliminary lifecycle concept
document that describes all of the lifecycle concepts
(including concepts of acquisition, operation, support
and disposal) and we have a Business Requirements
Specification that define the agreed business
requirements for the system.
10
find perfection difficult to come by in the
requirements analysis space) and it is a job that
requires iterations, reviews and rework.
11
section 4. The RBS provides a common framework
against which different teams of people can have
discussions and it will provide a common framework
against which requirements can be allocated when
the time comes. This will allow similar requirements
to be grouped and allocated to single sections of the
framework (assisting in correcting conflicting
requirements) and guarding against duplication or
omission of requirements.
12
problems with the requirements statement and
forces the author to revise the statement in order to
make it more verifiable. This is a worthwhile exercise.
13
We now have our requirements in a structured form
that we will call a System Requirements Specification
(SyRS). This may be a physical document, it may be a
spread sheet or it may be in the form of a structured
and populated database. It could even be in the form
of a model of the desired system that is able to
illustrate the system requirements via simulation.
14
The draft SyRS is sent to potential solution providers.
These may be external organisation or may be in-
house solution providers.
15
In most cases, solution providers will propose a
revision of the draft SyRS to make it better align with
their proposed solution.
16