Guideline: Developing Business Scenarios
Main Description

26.7.1 General Guidelines

The stakeholders (e.g., business managers, end users) will tell you what they want, but as an architect you must still gain an understanding of the business, so you must know the most important actors in the system. If the stakeholders do not know what they want:

  • Take time, observe, and record how they are working today
  • Structure information in such a way that it can be used later
  • Uncover critical business rules from domain experts
  • Stay focused on what needs to be accomplished, and how it is to be accomplished

This effort provides the anchor for a chain of reason from business requirements through to technical solutions. It will pay off later to be diligent and critical at the start.

26.7.2 Questions to Ask for Each Area

The business scenario workshops mentioned above in the Gathering phase are really structured interviews. While there is no single set of appropriate questions to ask in all situations, the following provides some guidance to help business scenario consultants in asking questions.

Identifying, Documenting, and Ranking the Problem

Is the problem described as a statement of what needs to be accomplished, like steps in a process, and not how (with technology "push")?

If the problem is too specific or a "how":

  • Raise a red flag
  • Ask "Why do you need to do it that way?" questions

If the problem is too vague or not actionable:

  • Raise a red flag
  • Ask "What is it you need to do, or will be able to do if this problem is solved?" questions

Ask questions that help to identify where and when the problem exists:

  • Where are you experiencing this particular problem? In what business process?
  • When do you encounter these issues? During the beginning of the process, the middle, the end?

Ask questions that help to identify the costs of the problem:

  • Do you account for the costs associated with this problem? If so, what are they?
  • Are there hidden costs? If so, what are they?
  • Is the cost of this problem covered in the cost of something else? If so, what and how much?
  • Is the problem manifested in terms of poor quality or a perception of an ineffective organization?
Identifying the Business & Technical Environment, and Documenting in Models

Questions to ask about the business environment:

  • What key process suffers from the issues? What are the major steps that need to be processed?
  • Location/scale of internal business departments?
  • Location/scale of external business partners?
  • Any specific business rules and regulations related to the situation?

Questions to ask about the current technology environment:

  • What technology components are already presupposed to be related to this problem?
  • Are there any technology constraints?
  • Are there any technology principles that apply?
Identifying and Documenting Objectives

Is the "what" sufficiently backed up with the rationale for "why"? If not, ask for measurable rationale in the following areas:

  • Return on investment
  • Scalability
  • Performance needs
  • Compliance to standards
  • Ease-of-use measures
Identifying Human Actors and their Place in the Business Model

An actor represents anything that interacts with or within the system. This can be a human, or a machine, or a computer program. Actors initiate activity with the system, for example:

  • Computer user with the computer
  • Phone user with the telephone
  • Payroll clerk with the payroll system
  • Internet subscriber with the web browser

An actor represents a role that a user plays; i.e., a user is someone playing a role while using the system (e.g., John (user) is a dispatcher (actor)). Each actor uses the system in different ways (otherwise they should be the same actor). Ask about the humans that will be involved, from different viewpoints, such as:

  • Developer
  • Maintainer
  • Operator
  • Administrator
  • User
Identifying Computer Actors and their Place in the Technology Model

Ask about the computer components likely to be involved, again from different points of view. What must they do?

Documenting Roles, Responsibilities, Measures of Success, Required Scripts

When defining roles, ask questions like:

  • What are the main tasks of the actor?
  • Will the actor have to read/write/change any information?
  • Will the actor have to inform the system about outside changes?
  • Does the actor wish to be informed about unexpected changes?
Checking for Fitness-for-Purpose, and refining if necessary

Is there enough information to identify who/what could fulfil the requirement? If not, probe more deeply.

Is there a description of when, and how often, the requirement needs to be addressed? If not, ask about timing.