- Email: [email protected]
Determining information requirements: A contingency method for selection of a requirements assurance strategy
Determining information Requirements: A Contingency Method for Selection of a Requirements Assurance Strategy J. David ~au~ann,
Gordon E3.Davis, and James D. ~cKeen
U~zit~er:rif,v ~?~,~~~i?~i~~.s~~f[l
If the information requirements for an information system application can be established accurately and completely and then documented clearly and unambiguously, there is a high probability that theapplication can be successfully designed and implemented. information requirements determination consists of two major processes: (1) eliciting requirements and (2) requirements assurance. Many techniques, procedures, and methodologies have been proposed for these two processes. This paper describes the selection of a strategy for information requirements assurance. Selection of the appropriate strategy depends on environmental and project contingencies. Contingencies determine the level of uncertainty to be resolved in order to ensure an accurate and complete statement of information requirements. Based on the level of uncertainty, the strategy for assurance may be to accept the requirements as stated or to follow either a linear. iterative, or experimental assurance process. The approach to strategy selection is illustrated by a contingency analysis worksheet for evat-
uating requirements uncertainty and by examples.
THE INFORMATION DETERMINATION
REQUIREMENTS PROCESS
Successful information systems application deveiopment hinges on accurate and complete determinati~)n and definition of information requirements. Information requirements are usually documented in the form of a “functional specification” or a “logical design.” ;md represent an agreement between users and developers. Although these requirements may include some petformance items such as response time, the
majority deal with information. As used in this paper, the term ~~?#~~~/~I~~~~~~~~ ~e~f~fi~~~/rl~~i~f.~ for an information system appIication p~marify involves inf~~rn~ation specifications, although performance specifications may be inctuded. Determining requirements is generally described as a single process, but two major component processes can be identified: (1) eliciting the requirements and (2) requirements assuritnce. Requirements may be elicited in a variety of ways using a variety of techniques. For example, users may provide a written statement of requirements. analysts may obtain the requirements by interviewing and by examining cxisting reports and documents, or requirements may be derived from analysis of objectives. decision processes, and so on. Requireff~~nts as elicited cannot be used for implementation unless there is assurance that they are consistent, accurate, and complete. Many formal application development steps (such as user review and sign off) are part of an assurance process. The objective of the assurance process is to ensure that the requirements are accurate and complete statements of user needs from the system. An explicit reco~Iliti~)n of the need for. utility of, and ~t~~~ra~t~risticsof the requirements assurance process aids in selecting an appropriate assurance strategy for each specific application. This paper defines a contingency approach for selecting an information requirements assumnce strntegy. A strategy is defined as it general approach for achieving an objective. Once a strategy is selected. methods appropriate to the strategy can be selected from the many techniques and procedures available i II.
Four situations illustrate common problems in :krat accurate and complete statements of infor-
riving
J. D. Naumann, G. B. Davis, and J. D. McKeen
274 mation requirements for information systems applications. In each of the following situations, a traditional life cycle methodology was used to elicit requirements, document them, and obtain assurance of accuracy and completeness by asking users to review and sign off. Payroll ~pa~ment asked for modifications to update the payroll system with new Social Security tax rates and wage base and to add reports to meet new federal and state reporting requirements. The job was classified as a major modification, and an analyst was assigned to do an information systems requirements study. Specifications were presented to the Payroll Depa~ment for review and approval sign-off 1 month later. The Payroll Department supervisor complained of unnecessary system work, excessive documentation, and undue delay. Situation
1. The
Situation 2. The Sales Order Office requested an automated order entry system because no additional office space was available to add clerks to handle increased order volume. The systems staff studied document content and flow and recommended an on-line order entry system that would not change the basic order document. Their analysis showed a 15year development cost payback period and a clerical staff reduction of 25%. The Office Manager and supervisors reviewed the requirements d~uments and signed off. They were enthusiastic about the work of the anaiyst. Situation 3. Part of the MIS plan called for a standard inventory control system to be implemented at each of 12 decentralized distribution centers (each with their own purchasing and marketing departments). After a study of one center, a system was proposed, but it was rejected by the other 11 centers. A second study, with a steering committee member from each center, was begun but analyst and user turnover, travel time and cost, and the inability of center representatives to negotiate compromises at meetings, delayed agreement on system requirements. The study took 2 years and users approved the results reluctantly. Situation 4. In response to a request from Marketing, DP began a study of a system to aid in selection of advertising media, format, and content. Although the study team included two of DP’s best analysts, the project was dropped after 9 months. According to the analysts, “the users couldn’t say
what they wanted,” and according to the users, “there was no assurance the suggested system would really help.” THE CONTINGENCY
APPROACH
In each of the above situations, the same information analysis procedures were used to provide assurance that the information requirements as elicited were accurate and complete. The different results and the variety of user reactions to these situations suggests that there should be different methods in different situations. If different methods are to be used, a basis for deciding which method to select must be provided. The proposed contingency approach is based on the premise that the presence of certain situational factors (contingencies) introduces uncertainty into the information analysis process and that the assessment of their contribution to this uncertainty can be used to determine the appropriate requirements assurance strategy. Contingency theory has been proposed for selection of project management methodology based on three factors [2] and for estimating probability of successful information system implementation based on eight factors [3, 41. This paper presents contingency theory for selection of the best strategy for information requirements assurance. Uncertainty Determines the Requirements Assurance Strategy Implementations
of information systems frequently
fail to satisfy user needs. Such failure may be due to faulty design, programming, testing, or training. The chief cause of failure, however, is incomplete or inaccurate specification of requirements. If information requirements are accurate and complete, the remainder of the systems development process can be performed with a high degree of certainty. Uncertainty regarding information requirements therefore leads to uncertainty as to whether the application can be successfully implemented. This uncertainty begins with the process of eliciting requirements; the requirements assurance process attempts to reduce it. Most formal life cycle project management methods have a single approach to assurance: essentially, requiring user approval, a “sign-off” that the requirements document is correct and complete. For a given level of uncertainty, this approach may be appropriate, but for other levels of uncertainty, different strategies are more suitable. In order to select a suitable strategy for requirements assurance, it is necessary to evaluate the level of unce~ainty associated with the application requirements determination.
Determining Information Contingencies Uncertainty
Requirements
275
the Level of
Determine
In determining information requirements for an information systems application, uncertainty refers to the state of knowledge of”rea1” user information needs. Naumann and Davis [Sl identified four contingencies that determine this unce~aint~: project size, degree of structuredness, user task comprehension, and developer task proficiency. An application development project has some combination of these attributes (and perhaps other as yet ~nspeci~ed contingencies). The presence of a combination of these contingencies yields a level of uncertainty which is used to choose an appropriate information requirements assurance strategy. Table I summarizes the contingencies and their general relationship to information requirements uncertainty. Project size. The project size contingency has two characteristics: duration and total cost. These characteristics are usually. but not necessarily, collinear: that is, a high-cost project usually requires an extended time period. Large project size increases the difficulty of determining information requirements because of the number of persons involved in establishing requirements~ the volume and complexity of communications. and the changes in both user and developer personnel during prqjects. Degree of structured~ess. One dimension of the Gorry and Scott Morton 161 framework for information systems is the relative structuredness of the decisions to be supported by an information system. For informatior~ systems. a high degree of structuredness implies that a genera1 mode1 exists which needs only to be applied to the given organizational setting. A low degree of structuredness means that there is no routine decision procedure for dealing with the problem, so there is ambiguity in the problem definition and
Table 1. Contingency
Analysis
Contingency
‘I‘ype Prqject
4,x
-Degree Small Large
Degree of stnictureJness
Structured Unstructured
User ta\k comprehension
Complete Slight
Developer t;ksk proficiency
High LOW
uncertainty over the criteria for evaluating solutions. Uncertainty about the structure of the decision process to be supported is thus an important factor in unce~ainty about requirements. User task comprehension. Distinct from degree of structuredness is the comprehension that the user or users have of the task to be performed by the information system. User task comprehension affects requirements determination uncertainty in much the same way as the degree of structuredness. If users have a low degree of understanding, or do not agree on the task for which a system is intended, the level of uncertainty for requirements accuracy and completeness is high. Developer-task proficiency. Developer task proficiency is a measure of the specific training and experience brought to the project by the development staff: project manager, liaison staff, systems analysts. systems designers, programmers. and so on. It is not a measure of ability or potential but rather of directly appiicable experience. This contingency indicates the degree of certainty that the developer will be able to elicit and document information requirements RCCUrately and completely.
Selection of Alternative Strategies
Uncertainty-Reducing
The response to information requirements uncertainty produced by these contingencies is usually to add control in the form of a single requirements assurance method. In the traditional development life cycle, there are formal procedures. reviews. committees, check points, sign-offs. and so on. A more suitable approach. which recognizes the differences in the project-related factors. is as follow\;: I. Measure contingencies
and determine the level of uncertainty. 2. Select an inform~ition requirements assurance strategy suitable for the observed fevel of uncertainty.
Contribution
to uRce~aint~
Table 2 shows uncertainty-reducing assurance strategies and characterizes the process associated with each strategy. The strategies are (1) accept the user’s statement of information requirements. or employ a (2) linear, (3) iterative, or (4) experimental assurance process. The table specifies strategies rather than methods for requirements assurance to clarify the basic thrust of each. The strategy is the general statement: methods associated with each arc specific implementations.
J. D. Naumann, G. B. Davis, and J. D. McKeen
276 Table 2. Information Requirements Assurance Strategies Requirements
assurance
strategy
accept user statement of requirements linear assurance process iterative assurance process
experimental
assurance
process
Process characterization elicit/document elicit/document/signoff elicit/document elicitidocument document/sign off elicit/demonstrate elicit/demonstrate document/sign
off
Accept user statement of requirements. If information requirements are known, the appropriate strategy is to accept the user’s statement of need as a specification for implementation. The method is therefore to employ no information requirements assurance process. Examples of appropriate use of the accept strategy are file conversions, reports from existing files or data bases, and some simple, single-user decision models. The contingencies these examples have in common are small size, high degree of structure, users who understand what the systems are to do, and developers who are experienced in this kind of task. When appropriate, a recognition of the need for the accept strategy will lead to greater responsiveness to users, elimination of frustrating assurance procedures, and an increase in development efficiency. In situation 1 involving payroll modifications, this strategy could have reduced development time and improved user attitude. Linear assurance process. If information requirements can be determined through a straightforward process of interviewing, fact gathering, documentation, and sign-off, the proper strategy is to proceed step-by-step to requirements specification. This is a linear assurance process and is used in most formal life cycle methodologies. It can be characterized as an elicit/document/sign-off process. The linear assurance process is an effective strategy under the appropriate combination of contingencies. Information requirements for systems that are highly structured and for which user task comprehension and developer task proficiency are high may be effectively ensured by this process. An example is the simple order entry system described in situation 2. Information requirements for a relatively small system might not be ensured by this process if (1) the decisions to be supported are relatively unstructured, (2) the user does not comprehend the task, or (3) the developers have not previously produced such a system.
Iterative assurance process. Where requirements uncertainty is greater, the linear assurance strategy may not result in acceptable information requirements. For such applications, traditional life cycle methodologies can be modified to include iteration. Requirements specifications are iterated past users until a complete, consistent specification is determined and accepted. The iterative assurance process can be characterized as elicit/document/elicit/document . . . elicit/document/sign-off. This approach assumes that a correct and complete specification of requirements can be made given sufficient iterations. In situation 3, the multiple-user inventory control system, an iterative approach, one center at a time, would have been more effective than the linear process described. Other examples where the iterative assurance process is applicable are large multipleuser systems, application areas that are new to the user or developer organization, and systems that support the relatively unstructured decisions of strategic management. Experimental assurance process. A high level of uncertainty may be indicated by a combination of the contingencies. Repeated iterations to arrive at requirements specifications might never successfully produce adequate assurance. The experimental assurance process obtains information requirements assurance by having the user experience the system being developed by such means as prototyping or simulation. It can be characterized as elicit/demonstrate/ elicit/demonstrate . . . document/sign-off. The strategy of experimental assurance as realized in the prototype design method reduces uncertainty by producing successive approximations. Users and developers can readily identify the shortcomings of a prototype even though they were unable to specify information requirements a priori. The contingencies of the advertising media model case (situation 4) indicate that an experimental assurance process would have been appropriate. Other examples include decision support systems for upper management, interactive forecasting models, and unstructured systems to be implemented for many different users. Conscious selection of the experimental assurance strategy may be the only effective approach to information requirements determination when the level of uncertainty is very high.
THE CONTINGENCY APPLICATION
MODEL AND ITS
A complete model for requirements assurance strategy selection is depicted in Figure 1. It is formed by linking the contingencies to the information require-
Determining Information
Requirements
l
Project
Size
s accept
0 Degree of Structuredness l
‘!-ll---
-2
User task Comprehension
user statement
0 linear assurance process 0 iterative process
0 Developer task Proficiency
high
assurance
0 experimental assurance process
, ~~
---~_I_____ Contingencies
Uncertainty
Level
Information Requirements Assurance Strabgy
--.
Figure 1. The
ments assurance strategies via an uncertainty assessment procedure. AppIi~ation of the ~ontinge~lcy model requires measurement of the level of each contingency, estimation ofthe overall levelof uncertainty determined by the contingencies, and selection of an appropri~~te strategy. The reactions and outcomes of the situations described earlier in the paper can now be understood in the context of contingency analysis (Table 3). An assurance strategy appropriate to the extant level of uncertainty is necessary for successful systems development. The contingency approach has been described: more specific guidelines may be useful to apply it. Figure 2 is a contingency analysis worksheet used to estimate the level of uncertainty for an application development project. The worksheet provides an assessment of the relevant contingencies through responses to eight questions, two for each contingency. An uncertainty profile and an estimate of overall uncertainty is provided by these responses. The profile
Table 3. ~ontjngenc~ __--.-_ ._ _A__
Analysis Applied to
Sittl~ti~n
Project size -___I_..
The existence or absence of collinearity among the responses: Is a long project always costly? Is a high degree of structuredness associated with high user task comprehension’? The weights for the contribution of each response to the overall un~el~ainty: Is cost more or less important than goal cIarity by the user’! In assessing response weights, the absence or existence of homogeneity must be evaluated. Low and high scores do not necessarily offset each other. A
_.^__._~___~.~
Degree of structuredness
User task c~rnpre~ensi~~n -..-__-
Developer task proficiency ----
Payroll update
Small
High
High
High
2.
Simple order entry
~~edi~~R1
High
3.
Multiple-riserconlrol
Large
Mediumhigh Mediumhigh
Low
Mediumhigh Medium
4.
Adrerrising
Low
LOW
LOW
media model
Meditlm
- --~_ ---- _
~. “.._ - _.__
Contingencies
I,
inventory
mo~lel
is useful in establishing the general level of uncertainty and in identifying significant differences that must be evaluated before selecting a requirements assurance strategy. In order to move from a single profile to a well-defined qlIantitative assessment of ~-~quirements uncertainty, it is necessary to establish three items:
Four Situations
_~ ~___
~---
ctlntingencv
C‘onlingency hased strategy
J. D. Naumann, G. B. Davis, and J. D. McKeen
278
1 REQUIREMENTS
I.
II.
Project Size a. Project development time
short
long
b, Total project development cost
small
large
high
low
Degree of Structuredness a. Goal clarity
(specificity)
b. Existence and definition of general model of process or procedures III.
IV.
V.
High
Moderate
LOW
CO~INGENCIES
UNCERTAINTY
poorly defined
well defined
User Task Comprehension high
low
high
1OW
a. Previous experience with same or similar system
high
low
b. Previous experience
high
low
a. Understanding
of problem
b. Understanding
of application
system
Developer Task Comprehension
in user area
Overall Assessment Sum of responses Times uncertainty
factor
0
’ +
Uncertainty
1
2 +
score
Figure 2. Contingency analysis worksheet.
small project with experienced developers may appropriately select an experimental assurance strategy if users have a very low understanding of the function and there is a low degree of structuredness. 3 Quantitative measures for the meaning of low, medium, high, and so on in the responses. This may, however, depend somewhat on the organization. What is a big project in one organization may be of moderate size in another. A research approach to make these dete~inations and validate the contingency model is described by McKeen [7]. The contingency profile is a useful supplement because low and high scores do not necessarily offset each other. Two case studies in the Appendix illustrate the use of the analysis worksheet. In order to provide illustrations of the contingency method using the worksheet, some naive assumptions
are made. Judgment is used to scale the responses, and homogeneity and equal weighting plus absence of co~inea~ty are assumed. This means that responses can be summed in each column and weighted to provide a mean weight of one for each response. The overall uncertainty score is the weighted sum for all responses. Measuring for overall scores can thus be assumed. A very low uncertainty score (say, ~4) indicates that a strategy to accept the user’s statement of requirements will effectively provide assurance that requirements are accurately and completely specified. A very high score (213) suggests that an experimental strategy will be needed to ensure complete and accurate system specifications. Similarly, a linear or iterative strategy is suggested by moderate scores in overall uncertainty.
CONCLlJSlON The importance of information requirements determination is well defined. This paper makes three important cont~butions to a more complete conceptual
Determining
Information
Requirements
and methodological understanding quirements determination:
279
of information
re-
APPENDIX:
Case
Studies
The case studies illustrate the application of contingency analysis in selecting an information requirements assurance strategy and the use of the contingency analysis worksheet.
I. There is a separation of information requirements determination into two subprocesses: (1) eliciting requirements and (2) requirements assurance. This conceptual distinction is important to both research and practice. 3. Contingency theory is applied to requirements assurance. Both the initial, tentative set of situational variables (contingencies) and a set of requirements assurance strategies are identified. 3. A contingency analysis worksheet is presented as the first step in establishing a method for relation of a requirements assurance strategy. The first stage of development of the contingency worksheet is a simple profile with nai’ve assumptions.
THE CLINFO PROJECT’ The target system is a data management and analysis system for direct use by clinical medical researchers who usually have no experience or interest in computers. Kesearcher.5 will use the system interactively to describe, enter, orgarenize. retrieve, analyze, and display patient-oriented search data. There are about 3000 researchers in more than 80 independent research centers that are potential users. (See Figure A I.)
The paper provides a conceptual framework for better understanding of information requirements determination and provides a basis for further research to validate the contingencies and establish weights, relationships, and measurements.
‘Adapted
from [8].
Figure Al.
CLINFO
REQUIREbENTS
worksheet
UNCERTAINTY
CONTINGENCIES I.
Project Size a. Project development
time
b. Total project development II.
cost
Degree of Structuredness a. Goal clarity
(specificity)
b. Existence and definition of general model of process or procedures III.
IV.
User Task Comprehension a. Understanding
of problem
b. Understanding
of application
I-system
high
high
in user area
Overall Assessment Sum of responses Times uncertainty
Uncertainty
score
x
_
;
factor
= /z
_ I
low low
high
Developer Task Comprehension
b. Previous experience
I
4. ~. ~___. ~
X
a. Previous experience with same or similar system
V.
.-___
c ,
i
J. D. Naumann, G. B. Davis, and J. D. McKeen
280 Res&s. The developers chose an experimental (prototype) requirements determination methodology because “without concrete, working examples, potential users could not be sure that computer systems were needed, what functions they should perform, or how they would use them.”
MAJOR CITY NATIONAL
department director and the five division managers. (See Figure A2.) Results. Using a conventional linear assurance strategy, the bank specified a system and successfully “implemented a distributed system with on-line minicomputers and central batch update.
BANK2
Five divisions of the Bank’s Commercial Paper Department are involved in processing, custody, and control of commercial paper transaction volume, and use of short-lived financial instruments indicate rapid reference to all documents in custody will shortly be necessary. The target is to specify information requirements to the satisfaction of the
*Adapted from [9].
Figure A2. Bank worksheet.
REFERENCES 1. W. M. Taggart, Jr., and M. 0. Tharp, A Survey of Information Requirements Analysis Techniques, Cornputing Surveys 9 (4), 273-290 (December 1977). 2. F. W. McFarlen, Effective EDP Project Management, in Manuging the Datu Resource Function (R. Nolan, ed.), West Publishing, St. Paul, Minnesota, 1974. 3. S. Alter, Implementation Risk Analysis, Working Paper, University of Southern California, 11 February 1976. 4. S. Alter and M. Ginzberg, Managing Uncertainty in MIS Implementation, Sloan Management Review (Fall 1978). 5. J. D. Naumann and G. B. Davis, A Contingency Theory to Select an Information Requirements Determination
REQUIREMENB
I.
Project Size a. Project development
short
time
b. Total project development cost II.
V.
long large
Small x high
(specificity)
b. Existence and definition of general model of process or procedures
IV.
x
Degree of Structuredness a. Goal clarity
III.
High
Moderate
LOW
CONTINGENCIES
UNCERTAINI?
1OW
x
poorly defined
well
defined
User Task Comprehension high
a. Understanding
of problem
b. Understanding
of application
system
low
X
1OW
high Y
Developer Task Comprehension a. Previous experience with same or similar system
high
b. Previous experience
high
in user area
low
x
low
X
Overall Assessment
Times uncertainty
3
‘$
Sum of responses factor
score
= 3-
I
+
2
2
1
0 +
Uncertainty
/
4
i
1
Determining
Information
Requirements
6. G. A. Gerry and M. S. Scott Morton, A Framework for Management Informaiion Systems, Sloan Mrrmgcww~lt KcLYc,ll~ (Fall 1971). 7. J. D. McKeen. J. D. Naumann, and G. B. Davis, Development of a Selection Model for Information Requirement\ Determination, Management Information Sys-
281 tems Research Center Working Paper 79-06, University of Minnesota, Minneapolis, June. 1979. 8. G. F. Groner. M. D. Hopwood. N. A. Palley, and W. L. Sibley, Requirements Analysis in Clinical Research Information Processing-A Case Study, C‘o/rl/ultc~~ I2 (9). 100 (September 1979).
Gordon E3.Davis, and James D. ~cKeen
U~zit~er:rif,v ~?~,~~~i?~i~~.s~~f[l
If the information requirements for an information system application can be established accurately and completely and then documented clearly and unambiguously, there is a high probability that theapplication can be successfully designed and implemented. information requirements determination consists of two major processes: (1) eliciting requirements and (2) requirements assurance. Many techniques, procedures, and methodologies have been proposed for these two processes. This paper describes the selection of a strategy for information requirements assurance. Selection of the appropriate strategy depends on environmental and project contingencies. Contingencies determine the level of uncertainty to be resolved in order to ensure an accurate and complete statement of information requirements. Based on the level of uncertainty, the strategy for assurance may be to accept the requirements as stated or to follow either a linear. iterative, or experimental assurance process. The approach to strategy selection is illustrated by a contingency analysis worksheet for evat-
uating requirements uncertainty and by examples.
THE INFORMATION DETERMINATION
REQUIREMENTS PROCESS
Successful information systems application deveiopment hinges on accurate and complete determinati~)n and definition of information requirements. Information requirements are usually documented in the form of a “functional specification” or a “logical design.” ;md represent an agreement between users and developers. Although these requirements may include some petformance items such as response time, the
majority deal with information. As used in this paper, the term ~~?#~~~/~I~~~~~~~~ ~e~f~fi~~~/rl~~i~f.~ for an information system appIication p~marify involves inf~~rn~ation specifications, although performance specifications may be inctuded. Determining requirements is generally described as a single process, but two major component processes can be identified: (1) eliciting the requirements and (2) requirements assuritnce. Requirements may be elicited in a variety of ways using a variety of techniques. For example, users may provide a written statement of requirements. analysts may obtain the requirements by interviewing and by examining cxisting reports and documents, or requirements may be derived from analysis of objectives. decision processes, and so on. Requireff~~nts as elicited cannot be used for implementation unless there is assurance that they are consistent, accurate, and complete. Many formal application development steps (such as user review and sign off) are part of an assurance process. The objective of the assurance process is to ensure that the requirements are accurate and complete statements of user needs from the system. An explicit reco~Iliti~)n of the need for. utility of, and ~t~~~ra~t~risticsof the requirements assurance process aids in selecting an appropriate assurance strategy for each specific application. This paper defines a contingency approach for selecting an information requirements assumnce strntegy. A strategy is defined as it general approach for achieving an objective. Once a strategy is selected. methods appropriate to the strategy can be selected from the many techniques and procedures available i II.
Four situations illustrate common problems in :krat accurate and complete statements of infor-
riving
J. D. Naumann, G. B. Davis, and J. D. McKeen
274 mation requirements for information systems applications. In each of the following situations, a traditional life cycle methodology was used to elicit requirements, document them, and obtain assurance of accuracy and completeness by asking users to review and sign off. Payroll ~pa~ment asked for modifications to update the payroll system with new Social Security tax rates and wage base and to add reports to meet new federal and state reporting requirements. The job was classified as a major modification, and an analyst was assigned to do an information systems requirements study. Specifications were presented to the Payroll Depa~ment for review and approval sign-off 1 month later. The Payroll Department supervisor complained of unnecessary system work, excessive documentation, and undue delay. Situation
1. The
Situation 2. The Sales Order Office requested an automated order entry system because no additional office space was available to add clerks to handle increased order volume. The systems staff studied document content and flow and recommended an on-line order entry system that would not change the basic order document. Their analysis showed a 15year development cost payback period and a clerical staff reduction of 25%. The Office Manager and supervisors reviewed the requirements d~uments and signed off. They were enthusiastic about the work of the anaiyst. Situation 3. Part of the MIS plan called for a standard inventory control system to be implemented at each of 12 decentralized distribution centers (each with their own purchasing and marketing departments). After a study of one center, a system was proposed, but it was rejected by the other 11 centers. A second study, with a steering committee member from each center, was begun but analyst and user turnover, travel time and cost, and the inability of center representatives to negotiate compromises at meetings, delayed agreement on system requirements. The study took 2 years and users approved the results reluctantly. Situation 4. In response to a request from Marketing, DP began a study of a system to aid in selection of advertising media, format, and content. Although the study team included two of DP’s best analysts, the project was dropped after 9 months. According to the analysts, “the users couldn’t say
what they wanted,” and according to the users, “there was no assurance the suggested system would really help.” THE CONTINGENCY
APPROACH
In each of the above situations, the same information analysis procedures were used to provide assurance that the information requirements as elicited were accurate and complete. The different results and the variety of user reactions to these situations suggests that there should be different methods in different situations. If different methods are to be used, a basis for deciding which method to select must be provided. The proposed contingency approach is based on the premise that the presence of certain situational factors (contingencies) introduces uncertainty into the information analysis process and that the assessment of their contribution to this uncertainty can be used to determine the appropriate requirements assurance strategy. Contingency theory has been proposed for selection of project management methodology based on three factors [2] and for estimating probability of successful information system implementation based on eight factors [3, 41. This paper presents contingency theory for selection of the best strategy for information requirements assurance. Uncertainty Determines the Requirements Assurance Strategy Implementations
of information systems frequently
fail to satisfy user needs. Such failure may be due to faulty design, programming, testing, or training. The chief cause of failure, however, is incomplete or inaccurate specification of requirements. If information requirements are accurate and complete, the remainder of the systems development process can be performed with a high degree of certainty. Uncertainty regarding information requirements therefore leads to uncertainty as to whether the application can be successfully implemented. This uncertainty begins with the process of eliciting requirements; the requirements assurance process attempts to reduce it. Most formal life cycle project management methods have a single approach to assurance: essentially, requiring user approval, a “sign-off” that the requirements document is correct and complete. For a given level of uncertainty, this approach may be appropriate, but for other levels of uncertainty, different strategies are more suitable. In order to select a suitable strategy for requirements assurance, it is necessary to evaluate the level of unce~ainty associated with the application requirements determination.
Determining Information Contingencies Uncertainty
Requirements
275
the Level of
Determine
In determining information requirements for an information systems application, uncertainty refers to the state of knowledge of”rea1” user information needs. Naumann and Davis [Sl identified four contingencies that determine this unce~aint~: project size, degree of structuredness, user task comprehension, and developer task proficiency. An application development project has some combination of these attributes (and perhaps other as yet ~nspeci~ed contingencies). The presence of a combination of these contingencies yields a level of uncertainty which is used to choose an appropriate information requirements assurance strategy. Table I summarizes the contingencies and their general relationship to information requirements uncertainty. Project size. The project size contingency has two characteristics: duration and total cost. These characteristics are usually. but not necessarily, collinear: that is, a high-cost project usually requires an extended time period. Large project size increases the difficulty of determining information requirements because of the number of persons involved in establishing requirements~ the volume and complexity of communications. and the changes in both user and developer personnel during prqjects. Degree of structured~ess. One dimension of the Gorry and Scott Morton 161 framework for information systems is the relative structuredness of the decisions to be supported by an information system. For informatior~ systems. a high degree of structuredness implies that a genera1 mode1 exists which needs only to be applied to the given organizational setting. A low degree of structuredness means that there is no routine decision procedure for dealing with the problem, so there is ambiguity in the problem definition and
Table 1. Contingency
Analysis
Contingency
‘I‘ype Prqject
4,x
-Degree Small Large
Degree of stnictureJness
Structured Unstructured
User ta\k comprehension
Complete Slight
Developer t;ksk proficiency
High LOW
uncertainty over the criteria for evaluating solutions. Uncertainty about the structure of the decision process to be supported is thus an important factor in unce~ainty about requirements. User task comprehension. Distinct from degree of structuredness is the comprehension that the user or users have of the task to be performed by the information system. User task comprehension affects requirements determination uncertainty in much the same way as the degree of structuredness. If users have a low degree of understanding, or do not agree on the task for which a system is intended, the level of uncertainty for requirements accuracy and completeness is high. Developer-task proficiency. Developer task proficiency is a measure of the specific training and experience brought to the project by the development staff: project manager, liaison staff, systems analysts. systems designers, programmers. and so on. It is not a measure of ability or potential but rather of directly appiicable experience. This contingency indicates the degree of certainty that the developer will be able to elicit and document information requirements RCCUrately and completely.
Selection of Alternative Strategies
Uncertainty-Reducing
The response to information requirements uncertainty produced by these contingencies is usually to add control in the form of a single requirements assurance method. In the traditional development life cycle, there are formal procedures. reviews. committees, check points, sign-offs. and so on. A more suitable approach. which recognizes the differences in the project-related factors. is as follow\;: I. Measure contingencies
and determine the level of uncertainty. 2. Select an inform~ition requirements assurance strategy suitable for the observed fevel of uncertainty.
Contribution
to uRce~aint~
Table 2 shows uncertainty-reducing assurance strategies and characterizes the process associated with each strategy. The strategies are (1) accept the user’s statement of information requirements. or employ a (2) linear, (3) iterative, or (4) experimental assurance process. The table specifies strategies rather than methods for requirements assurance to clarify the basic thrust of each. The strategy is the general statement: methods associated with each arc specific implementations.
J. D. Naumann, G. B. Davis, and J. D. McKeen
276 Table 2. Information Requirements Assurance Strategies Requirements
assurance
strategy
accept user statement of requirements linear assurance process iterative assurance process
experimental
assurance
process
Process characterization elicit/document elicit/document/signoff elicit/document elicitidocument document/sign off elicit/demonstrate elicit/demonstrate document/sign
off
Accept user statement of requirements. If information requirements are known, the appropriate strategy is to accept the user’s statement of need as a specification for implementation. The method is therefore to employ no information requirements assurance process. Examples of appropriate use of the accept strategy are file conversions, reports from existing files or data bases, and some simple, single-user decision models. The contingencies these examples have in common are small size, high degree of structure, users who understand what the systems are to do, and developers who are experienced in this kind of task. When appropriate, a recognition of the need for the accept strategy will lead to greater responsiveness to users, elimination of frustrating assurance procedures, and an increase in development efficiency. In situation 1 involving payroll modifications, this strategy could have reduced development time and improved user attitude. Linear assurance process. If information requirements can be determined through a straightforward process of interviewing, fact gathering, documentation, and sign-off, the proper strategy is to proceed step-by-step to requirements specification. This is a linear assurance process and is used in most formal life cycle methodologies. It can be characterized as an elicit/document/sign-off process. The linear assurance process is an effective strategy under the appropriate combination of contingencies. Information requirements for systems that are highly structured and for which user task comprehension and developer task proficiency are high may be effectively ensured by this process. An example is the simple order entry system described in situation 2. Information requirements for a relatively small system might not be ensured by this process if (1) the decisions to be supported are relatively unstructured, (2) the user does not comprehend the task, or (3) the developers have not previously produced such a system.
Iterative assurance process. Where requirements uncertainty is greater, the linear assurance strategy may not result in acceptable information requirements. For such applications, traditional life cycle methodologies can be modified to include iteration. Requirements specifications are iterated past users until a complete, consistent specification is determined and accepted. The iterative assurance process can be characterized as elicit/document/elicit/document . . . elicit/document/sign-off. This approach assumes that a correct and complete specification of requirements can be made given sufficient iterations. In situation 3, the multiple-user inventory control system, an iterative approach, one center at a time, would have been more effective than the linear process described. Other examples where the iterative assurance process is applicable are large multipleuser systems, application areas that are new to the user or developer organization, and systems that support the relatively unstructured decisions of strategic management. Experimental assurance process. A high level of uncertainty may be indicated by a combination of the contingencies. Repeated iterations to arrive at requirements specifications might never successfully produce adequate assurance. The experimental assurance process obtains information requirements assurance by having the user experience the system being developed by such means as prototyping or simulation. It can be characterized as elicit/demonstrate/ elicit/demonstrate . . . document/sign-off. The strategy of experimental assurance as realized in the prototype design method reduces uncertainty by producing successive approximations. Users and developers can readily identify the shortcomings of a prototype even though they were unable to specify information requirements a priori. The contingencies of the advertising media model case (situation 4) indicate that an experimental assurance process would have been appropriate. Other examples include decision support systems for upper management, interactive forecasting models, and unstructured systems to be implemented for many different users. Conscious selection of the experimental assurance strategy may be the only effective approach to information requirements determination when the level of uncertainty is very high.
THE CONTINGENCY APPLICATION
MODEL AND ITS
A complete model for requirements assurance strategy selection is depicted in Figure 1. It is formed by linking the contingencies to the information require-
Determining Information
Requirements
l
Project
Size
s accept
0 Degree of Structuredness l
‘!-ll---
-2
User task Comprehension
user statement
0 linear assurance process 0 iterative process
0 Developer task Proficiency
high
assurance
0 experimental assurance process
, ~~
---~_I_____ Contingencies
Uncertainty
Level
Information Requirements Assurance Strabgy
--.
Figure 1. The
ments assurance strategies via an uncertainty assessment procedure. AppIi~ation of the ~ontinge~lcy model requires measurement of the level of each contingency, estimation ofthe overall levelof uncertainty determined by the contingencies, and selection of an appropri~~te strategy. The reactions and outcomes of the situations described earlier in the paper can now be understood in the context of contingency analysis (Table 3). An assurance strategy appropriate to the extant level of uncertainty is necessary for successful systems development. The contingency approach has been described: more specific guidelines may be useful to apply it. Figure 2 is a contingency analysis worksheet used to estimate the level of uncertainty for an application development project. The worksheet provides an assessment of the relevant contingencies through responses to eight questions, two for each contingency. An uncertainty profile and an estimate of overall uncertainty is provided by these responses. The profile
Table 3. ~ontjngenc~ __--.-_ ._ _A__
Analysis Applied to
Sittl~ti~n
Project size -___I_..
The existence or absence of collinearity among the responses: Is a long project always costly? Is a high degree of structuredness associated with high user task comprehension’? The weights for the contribution of each response to the overall un~el~ainty: Is cost more or less important than goal cIarity by the user’! In assessing response weights, the absence or existence of homogeneity must be evaluated. Low and high scores do not necessarily offset each other. A
_.^__._~___~.~
Degree of structuredness
User task c~rnpre~ensi~~n -..-__-
Developer task proficiency ----
Payroll update
Small
High
High
High
2.
Simple order entry
~~edi~~R1
High
3.
Multiple-riserconlrol
Large
Mediumhigh Mediumhigh
Low
Mediumhigh Medium
4.
Adrerrising
Low
LOW
LOW
media model
Meditlm
- --~_ ---- _
~. “.._ - _.__
Contingencies
I,
inventory
mo~lel
is useful in establishing the general level of uncertainty and in identifying significant differences that must be evaluated before selecting a requirements assurance strategy. In order to move from a single profile to a well-defined qlIantitative assessment of ~-~quirements uncertainty, it is necessary to establish three items:
Four Situations
_~ ~___
~---
ctlntingencv
C‘onlingency hased strategy
J. D. Naumann, G. B. Davis, and J. D. McKeen
278
1 REQUIREMENTS
I.
II.
Project Size a. Project development time
short
long
b, Total project development cost
small
large
high
low
Degree of Structuredness a. Goal clarity
(specificity)
b. Existence and definition of general model of process or procedures III.
IV.
V.
High
Moderate
LOW
CO~INGENCIES
UNCERTAINTY
poorly defined
well defined
User Task Comprehension high
low
high
1OW
a. Previous experience with same or similar system
high
low
b. Previous experience
high
low
a. Understanding
of problem
b. Understanding
of application
system
Developer Task Comprehension
in user area
Overall Assessment Sum of responses Times uncertainty
factor
0
’ +
Uncertainty
1
2 +
score
Figure 2. Contingency analysis worksheet.
small project with experienced developers may appropriately select an experimental assurance strategy if users have a very low understanding of the function and there is a low degree of structuredness. 3 Quantitative measures for the meaning of low, medium, high, and so on in the responses. This may, however, depend somewhat on the organization. What is a big project in one organization may be of moderate size in another. A research approach to make these dete~inations and validate the contingency model is described by McKeen [7]. The contingency profile is a useful supplement because low and high scores do not necessarily offset each other. Two case studies in the Appendix illustrate the use of the analysis worksheet. In order to provide illustrations of the contingency method using the worksheet, some naive assumptions
are made. Judgment is used to scale the responses, and homogeneity and equal weighting plus absence of co~inea~ty are assumed. This means that responses can be summed in each column and weighted to provide a mean weight of one for each response. The overall uncertainty score is the weighted sum for all responses. Measuring for overall scores can thus be assumed. A very low uncertainty score (say, ~4) indicates that a strategy to accept the user’s statement of requirements will effectively provide assurance that requirements are accurately and completely specified. A very high score (213) suggests that an experimental strategy will be needed to ensure complete and accurate system specifications. Similarly, a linear or iterative strategy is suggested by moderate scores in overall uncertainty.
CONCLlJSlON The importance of information requirements determination is well defined. This paper makes three important cont~butions to a more complete conceptual
Determining
Information
Requirements
and methodological understanding quirements determination:
279
of information
re-
APPENDIX:
Case
Studies
The case studies illustrate the application of contingency analysis in selecting an information requirements assurance strategy and the use of the contingency analysis worksheet.
I. There is a separation of information requirements determination into two subprocesses: (1) eliciting requirements and (2) requirements assurance. This conceptual distinction is important to both research and practice. 3. Contingency theory is applied to requirements assurance. Both the initial, tentative set of situational variables (contingencies) and a set of requirements assurance strategies are identified. 3. A contingency analysis worksheet is presented as the first step in establishing a method for relation of a requirements assurance strategy. The first stage of development of the contingency worksheet is a simple profile with nai’ve assumptions.
THE CLINFO PROJECT’ The target system is a data management and analysis system for direct use by clinical medical researchers who usually have no experience or interest in computers. Kesearcher.5 will use the system interactively to describe, enter, orgarenize. retrieve, analyze, and display patient-oriented search data. There are about 3000 researchers in more than 80 independent research centers that are potential users. (See Figure A I.)
The paper provides a conceptual framework for better understanding of information requirements determination and provides a basis for further research to validate the contingencies and establish weights, relationships, and measurements.
‘Adapted
from [8].
Figure Al.
CLINFO
REQUIREbENTS
worksheet
UNCERTAINTY
CONTINGENCIES I.
Project Size a. Project development
time
b. Total project development II.
cost
Degree of Structuredness a. Goal clarity
(specificity)
b. Existence and definition of general model of process or procedures III.
IV.
User Task Comprehension a. Understanding
of problem
b. Understanding
of application
I-system
high
high
in user area
Overall Assessment Sum of responses Times uncertainty
Uncertainty
score
x
_
;
factor
= /z
_ I
low low
high
Developer Task Comprehension
b. Previous experience
I
4. ~. ~___. ~
X
a. Previous experience with same or similar system
V.
.-___
c ,
i
J. D. Naumann, G. B. Davis, and J. D. McKeen
280 Res&s. The developers chose an experimental (prototype) requirements determination methodology because “without concrete, working examples, potential users could not be sure that computer systems were needed, what functions they should perform, or how they would use them.”
MAJOR CITY NATIONAL
department director and the five division managers. (See Figure A2.) Results. Using a conventional linear assurance strategy, the bank specified a system and successfully “implemented a distributed system with on-line minicomputers and central batch update.
BANK2
Five divisions of the Bank’s Commercial Paper Department are involved in processing, custody, and control of commercial paper transaction volume, and use of short-lived financial instruments indicate rapid reference to all documents in custody will shortly be necessary. The target is to specify information requirements to the satisfaction of the
*Adapted from [9].
Figure A2. Bank worksheet.
REFERENCES 1. W. M. Taggart, Jr., and M. 0. Tharp, A Survey of Information Requirements Analysis Techniques, Cornputing Surveys 9 (4), 273-290 (December 1977). 2. F. W. McFarlen, Effective EDP Project Management, in Manuging the Datu Resource Function (R. Nolan, ed.), West Publishing, St. Paul, Minnesota, 1974. 3. S. Alter, Implementation Risk Analysis, Working Paper, University of Southern California, 11 February 1976. 4. S. Alter and M. Ginzberg, Managing Uncertainty in MIS Implementation, Sloan Management Review (Fall 1978). 5. J. D. Naumann and G. B. Davis, A Contingency Theory to Select an Information Requirements Determination
REQUIREMENB
I.
Project Size a. Project development
short
time
b. Total project development cost II.
V.
long large
Small x high
(specificity)
b. Existence and definition of general model of process or procedures
IV.
x
Degree of Structuredness a. Goal clarity
III.
High
Moderate
LOW
CONTINGENCIES
UNCERTAINI?
1OW
x
poorly defined
well
defined
User Task Comprehension high
a. Understanding
of problem
b. Understanding
of application
system
low
X
1OW
high Y
Developer Task Comprehension a. Previous experience with same or similar system
high
b. Previous experience
high
in user area
low
x
low
X
Overall Assessment
Times uncertainty
3
‘$
Sum of responses factor
score
= 3-
I
+
2
2
1
0 +
Uncertainty
/
4
i
1
Determining
Information
Requirements
6. G. A. Gerry and M. S. Scott Morton, A Framework for Management Informaiion Systems, Sloan Mrrmgcww~lt KcLYc,ll~ (Fall 1971). 7. J. D. McKeen. J. D. Naumann, and G. B. Davis, Development of a Selection Model for Information Requirement\ Determination, Management Information Sys-
281 tems Research Center Working Paper 79-06, University of Minnesota, Minneapolis, June. 1979. 8. G. F. Groner. M. D. Hopwood. N. A. Palley, and W. L. Sibley, Requirements Analysis in Clinical Research Information Processing-A Case Study, C‘o/rl/ultc~~ I2 (9). 100 (September 1979).