Roles and Activities > Analyst Role Set > Business Designer > Define Automation Requirements

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 artifacts. 
Steps
Input Artifacts: Resulting Artifacts:
Frequency: Once per iteration, with most work occurring in the early iterations.
Role: Business Designer
Guidelines:
Tool Mentors:

Workflow Details:

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?

Explore New Technologies To top of page

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 activities 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 top of page

To identify information-system use cases, begin with the business workers in the business object 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 Guidelines: 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 Guidelines: Going from Business Models to Systems, the section on automated business workers. 

Identify Entities in the Analysis Model To top of page

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 Guidelines: Design Class, the section on attributes. 

See also Guidelines: 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 To top of page

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 To top of page

As the activity concludes, review the system artifacts that have been sketched, to ensure that they are consistent. As the results of this activity are preliminary and relatively informal, reviews should be informal as well.

 

Copyright  © 1987 - 2001 Rational Software Corporation


Display Rational Unified Process using frames

Rational Unified Process