Task: Define Automation Requirements |
|
|
This task focuses on determining what are the candidate technologies for making the target organization more effective. |
Disciplines: Business Modeling |
|
Purpose
-
To understand how new technologies can be used to make the target organization more effective.
-
To determine level of automation in the target organization.
-
To derive system requirements from the business modeling work products.
|
Relationships
Roles | Primary Performer:
| Additional Performers:
|
Inputs | Mandatory:
| Optional:
|
Outputs |
|
Main Description
The team must make a rough estimate of what kinds of support the changed business use cases will require. It is
important to indicate, at an early stage, which techniques are available for implementing the business. Are your free
to support the business use case with new custom business tools? Must you use existing business tools? Or can you
purchase off-the-shelf products? Can you find the necessary resources, internally or externally, for the business tools
that must be developed? Is the existing configuration of computer systems, terminals, workstations, and networks
important? Is compatibility with the existing business tools required?
|
Steps
Explore New Technologies
Many technologies are developing very fast. You must build up a good understanding of available state-of-the-art
solutions, generally solutions as well as those specific to your own business domain.
Common to all organizations is the dependence on information technology. For a long time, information technology has
been used to improve the performance of the business. However, modern solutions can totally change the way business is
done. Before deciding on any new process designs it is important that you understand the potentials of modern
information technologies. The following list (see [JAC94]) gives you
an idea as to what you can do with technology to improve, or totally revolutionize, the way a business operates.
-
Automate work to eliminate human labor.
-
Analyze data in a way that cannot practically be done by hand.
-
Parallelize work or change the sequencing of activities by using databases and networks.
-
Distribute the organization by making it possible to access information from geographically different places,
ultimately to the front line where the customer is. Consider developing dedicated hardware solutions to withstand
rain and so forth, if required.
-
Move parts of the use cases outside the organization by giving your customers or suppliers access to your
information system.
-
Help coordinate tasks by supporting information exchange within the organization.
-
Use expert systems to make it possible for non-experts to do specialized work.
-
Collect information from different sources and present it in a way that humans can understand.
-
Keep track of work. Measure the business to find where improvements need to be made and where problems have
occurred.
-
Purchase customer databases to improve sales and marketing.
-
Sell and market electronically. More and more, companies and consumers are moving into the electronic world of
business.
-
Follow standards for electronic communication so that you can communicate with other businesses easily.
|
Identify System Actors and Use Cases
To identify information-system use cases, begin with the business workers in the business analysis model. For each
business worker, perform the following steps:
-
Decide if the business worker will use the information system.
-
If so, identify an actor for the information system in the information system's use-case model. Give the actor the
same name as the business worker.
-
For each business use case the business worker participates in, create a system use case and give it a brief
description.
-
Consider performance goals or additional information about the business worker that should be noted as a Special
Requirement for the system use case, or be entered in the Supplementary Specifications for the system.
-
Repeat these steps for all business workers.
See also Guideline: Going from Business Models to Systems, the section on business models and
actors to the system.
If a business worker is to be completely automated by the system, the corresponding system actor can be removed. The
system use case corresponding to the business worker still needs a system actor that initiates it. Search for that
system actor among the business actors and business workers supported by the to-be-automated business worker. See also
Guideline: Going from Business Models to Systems, the section on automated business
workers.
|
Identify Entities in the Analysis Model
For each business entity, consider the following:
-
If it is to be managed by the information system, identify a corresponding entity in the analysis model of that
system.
-
For each attribute of the business entity, determine if it should be modeled as an entity in the analysis model,
rather than an attribute. See also Guideline: Design Class, the section on attributes.
See also Guideline: Going from Business Models to Systems, the section on business models and
entity classes in the analysis model.
|
Identify Other Sources to Requirements on Systems
There are many sources of knowledge about-and requirements for-the information system outside the business model.
Examples of sources are:
-
Users of the information systems that you have not modeled in the business model. For example, the system
administrator is a user of the information system that is (usually) not represented in the business model.
-
Strategies that the business as whole has decided on. For example, regarding IT, reuse, compatibility and quality.
-
Corporate databases that must be used.
-
Other information systems with which the new system(s) must work (legacy considerations).
-
Timing and coordination with other projects.
-
Trends within the business's own industry and within the IT industry.
See the Requirements Discipline for more details.
|
Review the Results
As the task concludes, review the system work products that have been sketched, to ensure that they are consistent. As
the results of this task are preliminary and relatively informal, reviews should be informal as well.
|
|
More Information
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|