Previous Table of Contents Next


3. SYSTEMATIC CREATIVITY

The Systematic Creativity process was developed by Dr. Anthony Salvador and Dr. Jean Scholtz (Salvador and Scholtz, 1996). The name, Systematic Creativity, stems from the fact that design is creative. It should be creative. It must be creative in order to achieve a competitive lead. However, that creativity needs to have a systematic basis. The process used in product definition, design, and implementation needs to be systematic to achieve a time to market advantage. Additionally, all decisions made during the software process need to be made in the context of the integrated requirements.

3.1. THE FRAMEWORK

We developed two techniques: a method for collecting requirements from end users in an efficient manner and a framework for collecting, storing, and using this information during product definition, design, and evaluation. Our method is based on the underlying assumption that the work users do changes less frequently than how the work is done.

We’ll discuss the framework first, as our requirements gathering technique is based on collecting the information types discussed in the framework. The framework separates product definition (what the product will do) from product design (how the product will do it.) Figure 9.1 identifies the data classes that comprise the framework. The data classes in the framework display one of three types of relationships to the data class above or below them in the hierarchy: one-to-one, one-to-many, or many-to-one. For example, several goals may be related to one objective. Likewise, one goal can support several objectives.


Figure 9.1  Systematic creativity framework.

Although the framework is statically represented here, the information in it is generated at different times. Think of the process as proceeding from the outer corners inward, starting from the upper right corner and moving counter clockwise. Information from marketing is combined with human factors input and engineering input. The culmination of this process results in the definition of the goals that must be supported in the product, along with the necessary actions and objects.

In this section we will define the data classes and discuss the reason we collect each one. The definitions are in the order that the various data classes would ideally be collected. The use of the various data classes is discussed in the section on “Using Systematic Creativity” and demonstrated using examples from a product where we employed this method.

3.1.1. Product Goals and Objectives

Goals are what users or customers want to do. Objectives are the reasons they want to accomplish given goals. Objectives may be personal: the customer or user wants to get promoted. Customer and user objectives also support the company objectives, for example, helping the company to increase revenue. A consultant in advertising might have goals of obtaining and distributing the most up-to-date information to her clients. Objectives for this could include obtaining more work from current clients or from their recommendations to others.

Product goals and objectives come from marketing research as well as from the marketing team itself. Remember, if the software being produced is intended for large corporations, the customer is likely to be someone from Information Technology, not the end user of the software. Customer information is obtained by marketing through customer visits, surveys, focus groups, etc. Customer goals usually are in terms of different types of networks, servers, platforms, and operating systems that the product should run on. Other goals are related to robustness, bandwidth, and compatibility with other applications currently in place. Objectives are not usually obtained from customers.

In addition, marketing contributes goals they have for the product from marketing research. Examples of these goals are that they must include the functionality of a previous version of the product, must include the functionality of another product currently on the market, must be compatible with a specified list of operating systems. Marketing also produces certain requirements of their own. A goal such as being able to collect information through registration of the software is an example of this type of input. An objective for this could be to collect information as to which users would be interested in other products being developed.

3.1.2. User Goals, Objectives, and Tasks

User goals, objectives, and tasks are now acquired by the human factors team, using an interview process (described in the next section). We are primarily interested in the goals and objectives for use in product definition. We use this input, along with the marketing input on product goals and objectives, as the basis for product definition and design. We also collect the tasks that the users carry out to achieve their goals. Depending on the scope of an envisioned product, we may do one set of interviews or two. If we are envisioning a large product or one that supports many different types of users, we may do an initial set of interviews to collect goals, objectives, and prioritization of goals. However, integrating our user input with marketing input, we can agree on the functionality essential for the product. We would then do another set of interviews to collect task information before we start the design phase.

Human factors engineers may also collect information about customer tasks. If customers express goals of installing, monitoring, or regulating use of the envisioned product, it may be necessary to provide another interface to access such functionality. In this case, the human factors staff interviews system administrators about tasks they currently do in other systems to support such goals.

3.1.3. Facilitators and Obstacles for Tasks and Goals

There are two more data classes not shown on the diagram in Figure 9.1 that are also collected: facilitators and obstacles. Facilitators and obstacles are associated with tasks, that is, what makes it easy or difficult for users in their current work environment to achieve their goals and objectives. Figure 9.2 shows a one-to-one relationship between tasks and facilitators and obstacles. As with goals, objectives, and tasks, facilitators and obstacles may also have many-to-one and one-to-many relationships. The obstacles and facilitators are constraints which help us evaluate alternative designs and implementations. Can we reduce the current obstacles and maintain or enhance the current facilitators in defining new user tasks in our software?


Figure 9.2  User task data structure.


Previous Table of Contents Next