Category list

Identify the Stakeholders (Process Notes 1.2.4)

Identify all the people who have a vested interest in the product being built: These are the stakeholders. Stakeholders participate in the requirements-gathering phase, as it is the stakeholders who determine the product they need built.

You are looking for people who will be affected by the product or participate in its development. While the stakeholder list must not be so large as to include everyone in the building, neither must it exclude people who have a real interest in the product. To do so will result in later repercussions that may well scuttle your project.

Stakeholders must be individually named. Do not accept "someone from the accounting office."

Here is a checklist of potential stakeholders:

Client: The person responsible for paying for the development
Customer: The person(s) or group (s) who will pay for the product
User (potential at this stage): The person(s) or group(s) who will use the product to do work
Sponsor Name : The person with organizational responsibility for the project
Marketing Department
Developer(s): Person(s) or group(s) responsible for developing the product
Domain Expert(s): Sources of subject matter knowledge
Technical Expert(s): Person(s) or group(s) who have expertise in the subjects relating to the product's nonfunctional requirements (e.g., machines, legal, operational environment; see the requirements template for an exhaustive list)
Tester(s): Person(s) responsible for testing the quality of the requirements

For each stakeholder identify these items:

Stakeholder name
Stakeholder specialization (e.g., accounting, pricing, manufacturing)
Estimated amount of time the stakeholder will need to contribute to the project (It's difficult to know this at blastoff time because it depends on how much you know about the project. but it's worth considering whether you have an indication of the number of days/weeks and the frequency of the involvement.)

Refer to Chapter 3, Project Blastoff, for more guidance in doing a complete stakeholder analysis.

Refer to appendix D, Project Sociology Analysis Templates, for tools to help you analyze the sociology of your project.

Partition the Context (Process Notes 1.2.5)

Partition the context into business events.

The term "events" is used here to mean the business events that have an effect on the system. You will need to study these events to have enough knowledge to decide the best scope for the product.

Start outside the system, and look for those happenings that result in a communication between an adjacent system and your work context. For example, when a customer places an order for some service from your system, it is a business event.

The system does not initiate the event, but has to respond to it. Thus, when any signal arrives from outside your context and your system must make some response, it is a business event.

Remember that these are business events, not the individual events that happen when the user clicks a button.

Consider Non-Events (Process Notes 1.2.6)

Non-events are what happens if an event doesn't happen. For example, suppose that you have a fundamental event, "Customer pays for goods." The non-event is what happens if the customer does not pay. Is there another event that happens, such as "Follow up on bad payers"?

Examine each business event and ask if it has one or more associated non-events. Add the new events to your list of business events.

Add the new data flows to your work context diagram.

Buy on amazon.com >>

Robertson S., Robertson J.

<< Previous page

Table of contents

Next page >>