Managing Requirements in

an Acquisition Organization`
What is acquisition organization?
• An organization that purchase systems and then use them to provide an
operational capability.
• These organizations are mainly concerned with creating and managing
stakeholder requirements, which subsequently are used as the basis for
acceptance of the delivered system
• Planning
• The starting point for a project in an acquisition organization will be some form
of concept description.
• In its most basic form this will be just an idea
• The reason for this is simple: projects must be authorized by the organization and
the authorization process will require some documented evidence to support the
case for spending time and money (resources). The evidence usually contains a
brief description of what the users want to be able to do (the concept) and a
supporting argument to indicate the benefits that will ensue to the operating
organization from the provision of such a capability. The information in the
concept definition enables the project manager to begin planning.
• Since the concept definition contains a “description of what the users want to be
able to do”, we immediately have an initial set of stakeholders (users) for the
system and an outline of one or more scenarios (ability to do something).
• The first step in constructing a plan consists of identifying a fuller set of
stakeholder types and a more complete set of scenarios that cover the
complete range of expected operation of the system including, where useful,
different modes of operation.
• Once the number of stakeholder types is known, it is possible to plan in detail
how to set about eliciting requirements.
• Actions that may be instantiated in the plan include:
1. Plan to interview one or more candidates of each stakeholder type.
2. Allocate time to write up the interviews as interview reports and agree them
with candidates interviewed.
3. Decide the interview strategy and communicate to the interviewers (who may
be involved in the decision process anyway).
4. Prior to the interviews it can be useful (but not necessarily easy) to get all the
candidates together and explain the purpose of the interviews.
5. Agree and document the set of user scenarios that best reflect the purpose
and operation of the system in its context. It is essential to ensure that the
scenarios are not too blinkered in their scope.
6. Following the interviews, suggested stakeholder requirements can be extracted
from the interview reports and agreed with the interview candidates.
7. Decide on a structure into which each of the stakeholder requirements can be
entered.
8. Place each identified stakeholder requirement within the agreed structure and
modify the structure as necessary.
9. Identify and record any constraints. Some constraints are product requirements
such as physical size. Others are plan constraints such as budgeted cost and
completion time.
10. Decide whether additional attributes are required to support the text of the
requirements.
11. Agree the criteria for the review of each individual requirement and for the
requirement set as a whole. These criteria are best presented as a checklist for the
reviewers
12. Define the review process and relate this to the status of the individual
requirements.
13. Perform reviews as required by the review procedure defined.
Monitoring
• Monitoring can start once the plan is in place. Obvious monitoring points are
the completion of each activity in the plan.
• In the early stages the activities will mainly revolve around preparing for the
interviews, conducting them and reporting on them. These are easy to assess.
Three major milestones help to define the monitoring for the rest of the
process:
• the definition of the structure for the requirements specification;
• the definition of the attributes required for each requirement;
• the definition of the review process(es) with associated checklists. Once the structure is
in place, it is possible to determine whether there are any areas where there should be
requirements but none exist.
Changes
• During the development of stakeholder requirements there will be a period of
rapid and intense change.
• Managing change is a vital activity in requirements development.
• Important stages include the following:
• stakeholder requirements used as the basis for a competitive bidding process;
• contract in place for the development of a system;
• design complete and manufacturing about to start;
• acceptance trials are being undertaken;
• the system is in service
Whatever stage a project is at, the following steps are required in a change control process:
1. record the suggested change;
2. identify the impact of the suggested change;
3. decide whether to accept the change;
4. decide when to implement the change.
Supplier Organizations
• Supplier organizations that respond to acquisition requests from acquisition
organizations or higher level supplier organizations. These organizations
receive input requirements and develop system requirements (and subsequently
a design that is manufactured) in response to them
Bid Management
• Planning
• Often the starting point for requirements management within a supplier organization
will be the receipt of an invitation to tender (ITT), also known as a request for proposal
(RFP).
• Such an invitation or request will contain a set of requirements that must be satisfied
by the system to be delivered.
• The nature of the requirements received will depend upon the organization type of the
customer (i.e. the organization that issued the invitation).
• Whatever the nature of the input requirements received, the first task is to assess them
to determine whether they are:
• clearly identified and distinguished from purely descriptive information;
• unambiguous;
• consistent;
• free from undue design constraints
Monitoring
• Measuring progress during the creation of a proposal is vital, because time-
scales are usually constrained and the submission date is not negotiable.
• The end-point must be that the proposal clearly indicates how each input
requirement will be met.
• However, merely asserting how a requirement will be met is not sufficient.
• It is also necessary to check that all the assertions are valid.
• This is an aspect of the review process, but an indication of progress can be
obtained by comparing the percentage of input requirements that have been
traced to the solution model (and hence to either system requirements or
design components).
Changes
• During the preparation of a proposal there are three potential sources of
change:
• customer;
• suppliers,
• internal.
• the probability of change is roughly proportional to the size of the system (or
component) to be developed.
Product Organizations
• Product companies that develop and sell products. These organizations collect
stakeholder requirements but from their market place rather than from
individuals or from operations organizations.
• Product organizations define stakeholder requirements and develop a product
to satisfy them.
• Hence they have many of the characteristics of acquisition and supplier
organization.
• The main difference is that the customer–supplier agreement at the top level of
the supply chain is within the overall organization although different
departments usually undertake the roles of defining stakeholder requirements
and developing products to satisfy them
Planning
• Single Product Version
• Planning for a single version of a single product involves the same activities as for the
acquisition and the supplier organizations.
• The difference between the bidding and the development stages may still be there.
• For example, when starting a new product, the company may want to have an initial idea
of what is involved in building it.
• To achieve this it is necessary to elicit the stakeholder requirements and to produce an
outline solution.
• Producing the stakeholder requirements is very similar to the way in which acquisition
organizations do it. There is a need to identify stakeholders and user scenarios.
• However, rather than interviewing real stakeholders, what usually happens is that people
volunteer (or are volunteered) to act as “surrogate” stakeholders. This means that they
adopt the role of a defined stakeholder and define, from that point of view, what the
stakeholder requirements are. From a planning point of view there is little difference.
Multiple Products and Versions
• Product organizations may have several versions of the same product at
different stages in their evolution.
• Typically they will have some product versions in use by people who have
purchased them, some in development and some being defined.
• From a planning point of view, each version can be treated as a separate
“project” going through its own set of stages and gates.
• However, there is an additional need to plan for the different versions of the
products in the pipeline.
• It is important to plan when each version in current use will be phased out and
replaced by a later model.
• These aspects can also be brought under the stage gate process, so that a set of
stage gate reviews can be held at the same time to determine the best
investment strategy to keep or increase market share
Contd..
• A further factor in this area is that there may well be different versions for
different markets.
• For example, it may be necessary to have user interfaces that support different
natural languages for sale in different countries.
• To cope with this type of difference we introduce the notion of a “variant”
meaning “differing in form or details from the main one”.
• Thus we can have the “main one” (perhaps better expressed as the “core
product”) being a product with the user interface in English and variants for the
French, German and Spanish markets. Each variant can have its own versions
such that each version is an improvement over the previous one
Monitoring
• Monitoring progress in a product organization uses exactly the same
mechanisms as for the other organizations.
• Progress can be measured based on the extent to which the desired state has
been reached.
• As a general rule such states can be measured in the following terms:
• whether new objects exist that will become targets for traceability links (e.g.
solution objects in response to stakeholder requirements, or design objects in
response to system requirements);
• whether attribute values exist;
• whether the required review status exists;
• whether traceability links exist from one data set to others (e.g. from
stakeholder requirements to system requirements, from system requirements
to design and from all of these to testing strategies and possibly test results).
Changes
• As mentioned earlier, the major additional factor for change management in a product
organization is where several variants of a product have common requirements and a
change proposal is raised against one or more of them.
• The questions that must be answered are:
• will all the variants want to incorporate the change?;
• when will they want to incorporate it?
• Often the answer will be that all variants will want to incorporate the change, but not at
the same time!
• The change can only achieve the status of complete when all the variants have reached
their individual “incorporated” state.
• In summary, product organizations perform similar tasks to both acquisition and supplier
organizations.
• In addition, they must take care to control their product portfolio so that an appropriate
degree of commitment is made and the overall commercial exposure is acceptable