The aim of Prerequisites analysis is to bring an understanding of the business under development, and to make that understanding inter- subjective among the different persons involved (engineers, users, sys- tem owners, et cetera). One way to start is to produce a Business defini- tion as shown in Fig 6-1.
A Business definition defines the results (products and services) of the business, what customers and clients the result is produced for, the main tasks that have to be carried out to create the results, and the groups of persons involved in the process. In addition, it might be a good idea to include information about important raw material and suppliers as well. The main purpose of the Business definition is to ensure that developers do not ‘forget’ the business; its intended results used to sat- isfy customers, and the activities performed to create such satisfactions. Doing this early during systems engineering emphasizes that informa- tion systems are developed with the purpose of adding value to the busi- ness – and thus to the business’ customers (Goldkuhl, 1993).
BUSINESS DEFINITION Series
The Paper Mill Creator PÅ Date 4.4.99 Version 2 Ref. Code BD1 Concerns: Material Administration System (MA)
Products: Tissue and Laminate
Customers: Mostly other companies within the same combine. Occasionally to other large producers of consumer products.
Tasks: Refine pulp and sell as tissue and laminate. This includes purchasing pulp, colouring, glue etc., planning and carrying out production, warehousing, and providing products to customers. Producers: Salespersons, purchasers, schedulers, workers and economy
personnel.
Fig 6-1: Example Business Definition.
Before development actually starts, it is important to get an un- derstanding of the problems that the new system is supposed to solve. Thus, problems are to be identified, formulated and analysed during a Problems inventory.
The problems found can be documented in a Problem list as shown in Fig 6-2.
It is usually not enough to list problems, one needs to analyse how problems relate to each other as well. That is, to identify causes and ef- fects of problems. The reason for undertaking such analysis is to struc- ture problems in ‘problem hierarchies’ in order to understand which are the ‘real problems’, i.e. the central problems that are the source of all the
PROBLEM LIST Series
The Paper Mill Creator PÅ Date 4.4.99 Version 4 Ref. Code PL1 Concerns: Material Administration System (MA)
1. Lots of information must be remembered and processed manually by the staff. 2. Communication between sales dept. and production dept. is often too
ineffective. The right people are often hard to reach when needed.
3. Delivery promises are hard to live up to. Often deadlines need to be changed and re-negotiated with customers.
4. Production schedules are changed frequently. Sometimes even for production weeks that have already begun.
Fig 6-2: Example Problem List.
The analysis of problem causes and effects can be documented in a Problem diagram; see Fig 6-3.
PROBLEM DIAGRAM Series
The Paper Mill Creator PÅ Date 4.4.99 Version 4 Ref. Code PG1 Concerns: Material Administration System (MA)
1. Manual processing required 2. Ineffective communication 4. Changes in schedules are common 3. Broken promises are common
A Problem diagram consists of a directed graph (cf. e.g. Lipschutz, 1976) where the nodes represent problems and the vertices represent causal relationships between problems.
A Problem diagram graph must not necessarily be a rooted tree (as in Fig 6-3). It might in fact even be disconnected.
The most important problems to solve are those represented by nodes having indegree equal to zero (sources), referred to as root prob- lems. Nodes of a Problem diagram graph having outdegree equal to zero (sinks) correspond to problems that are usually solved ‘on the fly’ when the harder problems (closer to root problems) are considered, given that their indegree is greater than zero.
To develop (re-engineer) a business is (or at least ought to be) to move away from the problematic and approach the desired. Therefore it is not enough to analyse the problems. One also needs to examine the business’ goals during a Goals inventory. Goals might exist on different levels, from high-level goals such as strategies and policies to low-level goals such as norms and business rules for a particular business process or activity. During BPM it is important to concentrate on the goals that specifically relate to the IS to be developed in order to keep focus on the task at hand, i.e. systems engineering.
Goals can be documented in a Goal list, similar to problems in the Problem list (Fig 6-2).
Similar to problems, goals have to be analysed in terms of causes and effects. This is to discover which goals are the most important to achieve in order to decide where to put most engineering resources. Fur- thermore, it is possible that some goals contradict each other. Such ‘goal conflicts’ are important to identify and to solve, if possible.
The analysis of goal causes, effects and conflicts can be docu- mented in Goal diagrams. A Goal diagram consists of a directed graph with nodes representing goals and with two different kinds of vertices: one kind representing goal/sub-goal relationships, and the other repre- senting goal conflicts. As a notational convention Goal diagram graphs are drawn in the opposite direction of Problem diagram graphs – having the most prominent goals at the top and sub-goals beneath. Hence, nodes with outdegree equal to zero are the most prominent (important to achieve) as opposite to Problem diagrams. Fig 6-4 shows the notation used in Goal diagrams.
Goal.
Goal achievement. A goal and a sub-goal that is a means to achieve the goal.
Goal conflict. A goal that contradicts another goal.
Fig 6-4: Notation used in Goal graphs (Goldkuhl & Röstlinger, 1988).
As discussed previously (chapter 5 and section 6.1), VIBA should optimally be preceded by Change analysis/SIMM (CA). During CA the problems and goals of (the part of) the business that the new IS supports are treated as described above. The results of CA can then be used di- rectly after filtering goals and problems that obviously do not relate to the IS being developed. Otherwise this part of VIBA (i.e. Problems in- ventory and Goals inventory) must be worked through more carefully.
In addition to the business per se and its problems and goals, there are in general a number of different prerequisites that delimit the engi- neering work but also give rise to different possibilities. It is very impor- tant to make such prerequisites explicit early during systems engineer- ing.
Prerequisites might be of different kinds. Goldkuhl (1993) lists some examples, such as:
! strategic, ! organizational, ! hardware, ! software, ! security, ! legal, ! work environment,
Identified prerequisites can be documented in a Prerequisites list as shown in Fig 6-5.
PREREQUISITES LIST Series
The Paper Mill Creator PÅ Date 4.4.99 Version 6 Ref. Code PL1 Concerns: Material Administration System (MA)
Hardware
The system shall be implemented on the departments existing personal computers running Windows NT. Existing relational database management systems running on UNIX mainframes shall be used.
Software
The system shall be constructed using Visual Basic following Microsoft’s standards as much as possible.
System integration
The system shall communicate with the existing sales support system (called ISP). Some data are to be imported from ISP and some (not existing) are to be owned by the new system.
Time
The system shall be running within 4 months.
User experience
Experience of computers differs widely between different groups of users. Special attention shall be paid to make interfaces easy to learn and to understand by all users.
Fig 6-5: Example Prerequisites list.
The Prerequisite list, together with the Problem list and the Goal list, is the most important tool in guiding the systems engineering proc- ess.