This paper reviews requirements analysis paradigms from the 1980s through 2008. We will proceed chronologically to better reflect and understand their evolution. Our review shows that requirements analysis paradigms have evolved from informal analysis through formal analysis. We proceed from the informal, briefly looking at reflections concerning their disadvantages and possibilities for improvement (automation). We then look at some semi-formal paradigms (philosophical considerations borrowed from sociology and knowledge analysis). We conclude by examining more formal paradigms (object-oriented, goal oriented). The list is by no means comprehensive or conclusive but, we hope provides a useful overview of the domain.
Suzie is doing requirements analysis for a local art store, Arts Are Us. She has contacted the store manager and arranged to interview the five departmental heads: Liz Jones, Finance Director, Mary Kelly, Artistic Director, Julie Lomaz, Sales Director, Hugh Ritter, IT director, and Lucy Bennington, Education Director. After doing some initial research of Arts Are Us – viewing websites, studying newspaper clippings, browsing catalogs and brochures – she interviewed the store manager, Kathy Littleton. Kathy Littleton is in general satisfied with the stores operations but, believes there is room for improvement. She feels they lose a lot of potential receipts because their information is not timely. In particular, she cannot rapidly get transactional information from her departmental directors that would help her to react quickly to problem areas, market shifts, and new market possibilities. Moreover, she states that any new system should be highly usable, flexible and adaptable to the work patterns of individual users while creating as little disruption as possible.
The above scene is imaginary but brings to the
forefront the raw material of typical requirements analysis. The
importance of being aware of developments in requirements analysis in
order to effectively select and implement successful analysis
techniques should not be underestimated. We plan to provide a few
insights in the vast domain of frameworks that have been and continue
to be used today.
But before going further, in order to better situate this work, we begin by defining two fundamental terms: requirements analysis and paradigms.
We take our base definition for requirements analysis from the die.net dictionary (http://dictionary.die.net/requirements%20analysis). Die.net defines requirements analysis as the process of reviewing a business's processes to determine the business needs and functional requirements that a system must meet. A report taken from the Eagles Evaluation Working Group Website (Eagles Evaluation Working Group 1996) says that requirements are “stated or implied needs”
The Merriam-Webster Online dictionary (paradigm - Definition from the Merriam-Webster Online Dictionary) defines paradigm as “a philosophical and theoretical framework of a scientific school or discipline within which theories, laws, and generalizations and the experiments performed in support of them are formulated; broadly: a philosophical or theoretical framework of any kind.” However, historian of science Thomas Kuhn gave the word paradigm its contemporary meaning as referring to a set of practices that define a scientific discipline during a particular period of time. We associate the two definitions in this review.
Our
first article written in 1982, Prototyping: The New Paradigm for
Systems Development discusses a paradigm that indirectly impacts
requirements analysis. (Naumann and Jenkins 1982). The authors believe
that the traditional method – the old systems development paradigm – no
longer fits the real world. Their research suggests that the new
systems development paradigm is prototyping. Prototyping as
diagrammed below, is a four-step procedure. (Figure 1).
In both of these approaches, the emphasis is on identifying the essential features of a user’s requirements. Prototyping presents a different way of approaching information systems implementation. The prototype builder’s and user’s paradigm accepts the uncertainty of information requirements statements and the certainty of continuing change. Prototype information systems are purposely incomplete and very changeable. Users interact with their system in its environment to specify their requirements more completely and correctly.
Advances in technology had made prototyping feasible, but no integrated set of prototyping resources was yet available.
Our next paradigm examines the possibility of improving informal paradigms. Our author acknowledges the insufficiency of informal paradigms. In 1983, Robert Balzer, wrote (Balzer, Cheatham Jr. and Green 1983) that there is no technology for managing the knowledge-intensive activities that constitute software development processes. He found that such processes, which convert requirements into a specification and then into an implementation, were informal, labor intensive, and largely undocumented. Even though the information about these processes and the rationale behind each of their steps was crucial for maintenance this information was unavailable. Requirements analysis until this time was largely informal. However, many, including Balzer recognized that maintenance was a costly bottleneck in the system development life-cycle. In his article, Software Technology in the 1990’s: Using a New Paradigm, Balzer investigated a software paradigm based on automation, which would augment the effectiveness of the costly and limited supply of people producing and maintaining software.
The automation paradigm, although applicable to the entire systems development lifecycle would have a direct effect on requirements analysis as demonstrated in Fig. 2 below.
Figure 2. Paradigm Comparison: (a) automation-based paradigm and (b) current paradigm
In this new paradigm, maintenance is performed on the specification rather than the implementation (source program). We modify the form that is closest to the user’s conceptual model. Although automation mechanization would occur from the specification level, both validation and maintenance phases now return to the end-user to improve requirements.
Three Paradigms for IS | ||
Pursuing
Balzer’s automation line of reasoning, in 1984, in his article, “Three
Paradigms for Developing Information Systems” (Blum 1984) Bruce Blum
examined the information systems development in light of three
paradigms: the standard paradigm, the tool enhanced paradigm, and the fully automated paradigm.
Once again, we see a direct impact on the requirements analysis phase in the life cycle. To minimize both types of risk, Blum promotes an iterative process for requirements analysis. Specifically, within the fully automated paradigm, Blum said that the analysis phase produces a statement of the target system requirements; it involves the transformation of the user’ understanding of their needs into the analysts’ understanding of user’s needs. Users are assumed to know well the application area but less well the different computer supported solutions. The analyst is assumed to know both areas with emphasis on the latter. By definition, this is a high application risk project. Therefore, the initial analysis will probably be imperfect and subject to iteration. Consequently, the product – requirements specification – should emphasize clarity rather than completeness. While several design methodologies emphasize diagrams and graphics for requirements, Blum felt that text in a structured outline is generally the most inexpensive and maintainable media for the user to review. To realize this methodology one would need a “requirements text processor” that could structure and restructure requirements and their associated text; modify and edit; and list as documents or outlines. Further, listing by topic or level of detail or importance should be provided. An implementation of Blum’s paradigm named TEDIUM existed but was limited to low technical risk applications.
By 1989 requirements analysis was looked at less and less informally. In their CACM article of 1989 (Hirschhelm and Klein 1989), Hirschheim and Klein examined four paradigms of information systems development that intricately involve requirements analysis methodology. They do this by applying a philosophical line of analysis. They propose alternatives to the orthodox approach to systems development that are based on four fundamentally different sets of assumptions. These assumptions deal primarily with the attitudes adopted toward reality and how to obtain knowledge about it.
Hirschheim and Klein define paradigm as “the most fundamental set of assumptions adopted by a professional community that allows its members to share similar perceptions and engage in commonly shared practices.” Their four paradigms are functionalism (objective-order), social relativism (subjective-order), radical structuralism (object-conflict), and neohumanism (subjective-conflict). Although the concepts were initially developed in the sociological domain, the authors found the paradigms are a good fit in the domain of information systems development. They used “generic stories” to show that different types of behavior in requirements determination arise depending on whether one believe in an objective organizational reality or not. Pools of systems development literature were interpreted that share the assumptions of each of these paradigms. We will examine the implications of applying the first two paradigms: objective-order versus subjective-order.
In their paper, the authors show:
The first approach we call the utopia approach. This is best illustrated by a real life example. In typical systems designs, analysts focused on rationalizing newspaper production by combining editing and formatting -- tasks that can be done on the same devices. Since page layout can be seen as a natural extension of formatting, orthodox requirements analysis would suggest that editors can also perform the typesetting function because computers already help the editors with editing and formatting. Thus typesetting would be assigned to the editors.
The Utopia project attempted an
alternative approach. Their goal was to establish an electronic
typesetting support system that would enhance the position of the
typesetting craft in the newspaper industry. Typesetters replaced
management on the design team. In the requirements analysis, the design
team viewed typesetting as an essential task requiring specialist
skills that would be lost by its integration with editing. The
typesetters were interested in retaining the quality of typesetting and
possibly enhancing their own productivity. To retain quality,
systems design options focused on providing the flexibility and
diversity of the traditional tools of the typesetting trade by
electronic means. The UTOPIA approach resulted in an electronic
typesetting support system that enhanced the typesetters’ skills and
productivity.
A second example drives home the need for new paradigms. Deregulation has forced airlines to be more cost conscious while maintaining costly safety. One company decided to rationalize engine maintenance to cut costs while improving maintenance quality. During the knowledge acquisition phase, rules for engine maintenance and repairs were extracted from engineering specifications and maintenance handbooks. The system was partially automated to let machines diagnose needed repairs. A schedule was printed out and mechanics made the repairs. However, costs did not decrease but increased by 13%.
The redesign process revealed
that mechanics relied too heavily on computer-based fault
diagnosis. They didn’t challenge the computer diagnosis for
errors. Mechanics knowledge acquired through education and
experience could not easily be formalized and put into a rule-based
expert system. The focus of requirements analysis was shifted
from the acquisition of an expert rule base to the support of the
mechanics’ judgment in diagnosing maintenance need. After the mechanics
decided on the necessary repairs, they would then consult the computer
system for repair options, part availability, etc. In other
words, the mechanics took over fault-diagnosing with the support of
computers.
The primary role of the analyst is to be the expert in technology, tools and methods of system design, and project management. Their application helps make systems development more formal and rational, placing less reliance on human intuition, judgment, and politics. Structured analysis approaches this objective by making analysis procedures more formal.
The authors show that the differences in the above examples are the product of fundamentally different underlying systems development assumptions. Paradigm 1 –functionalism- assumes the ends and system objectives are agreed, legitimization can become little more than a hollow force or thinly concealed use of power. The pre-specified ends meet the needs of certain system stakeholders at the expense of others. A possible reaction is end user resistance to change. In some of the more advanced thinking in ISD, it is explicitly recognized that there are changing requirements emerging from constantly shifting trends and policies of organizational life which can never fully be known to developers.
This approach believes that systems cannot be designed but emerge through social interaction. The approach facilitates the learning of all who are concerned and affected. Instead of expert, the analyst helps to stimulate reflection, cooperation, and experiential learning.
By 1990, the problem of requirements analysis was being dealt with more directly. In their article, Extending Analysis Paradigms (Woodfield, Embley and Kurtz 1990), the authors define the primary goal of software requirements and specification to be efficient communication. In order to achieve this, the authors promote the object-oriented paradigm. The authors believe that the programmer-orientation adopted by many analysts can cause communication problems. Many analysts believe that they are correct and everyone else, especially users, just need more education or experience. To be able to address the problem requires that analysts step outside their own paradigm and understand its weaknesses else they remain literally blind to the things their paradigms won’t let them express. For example, as a programmer-oriented analyst normally thinks of values being discrete, she will describe the light as being “dim” or “not-dim” and try to get the user to define a discrete meaning of dim. Because the conceptual models of many analysts won’t allow the expression of fuzzy concepts, the analyst won’t comprehend that the term “dim” is fuzzy. This paper then goes on to propose that the organization of natural languages be used to guide the development of conceptual models.
Even though communication is the essence of good requirements and specification documents, most non-computer scientists find it difficult to understand a requirements document created by a computer scientist. The user thinks in terms of natural language while the computer scientist has been trained to think in terms of implementation concepts. The authors propose that the optimum communication about software requirements and specification occurs when the underlying conceptual model contains concepts similar to those found in natural languages. The underlying conceptual model of any analysis methodology should thus include the following concepts: entities, actions, declarative statements, concurrency, events, communication, and various forms of abstraction.
In the early days of analysis, entities were thought of as data. The analyst typically would determine all the activities taking place in the environment being analyzed and produce a report of the inputs, outputs and other relationships between the activities. It was difficult to understand the requirements or specification document from the point of view of some entity. This model is still prevalent in such methodologies as classic Structured Analysts.
They conclude by saying that neither requirements nor specification models should constrain an analyst who is describing problems or solutions. Underlying conceptual models must easily represent reality and must not be artificially constrained by some implementation paradigm.
Byrd, Cossik and Zmud take an even more "head on" approach to improving requirements analysis. In A Synthesis of Research on Requirements Analysis and Knowledge Acquisition Techniques (Byrd, Cossick and Zmud 1992) state that requirements analysis (RA) involves end users and systems analysts interacting in an effort to recognize and specify the data and information needed to develop an information system. The authors then go on to compare the process of eliciting information with knowledge acquisition (KA). When examined closely, many entities and processes involved in RA and KA are almost identical. The article compares representative RA and KA techniques, grouped according to elicitation mode, on three dimensions: communication obstacles, a technique’s locus of control, and the nature of the understanding gained from using the technique. This comparison demonstrates that researchers in one area can benefit from developments in the other area. Additionally, this analysis leads to several suggested research areas:
It is well understood that the development of effective information systems (IS) requires thorough analyses of user information needs prior to IS design. This step in the process of systems development, generally referred to as requirements analysis (RA), typically involves an analyst (1) working with end users to establish an understanding of organizational information processing needs; (2) developing IS objectives; (3) designing and evaluating IS alternatives; (4) communicating the results of analyses to superiors, other analysts, and end users; and (5) performing a systems audit.
Determining correct and complete information requirements is a vital part of designing an IS. Many IS failures can be attributed to a lack of clear and specific information requirements (Cooper and Swanson,1979; Davis, 1982; Telem, 1988a). Proper identification of information needs early in the design process produces more successful systems and allows for early correction of errors while the cost of correction is lower (Mittermeir, et al., 1982).
Wasserman, et al. (1983) have shown that senior managers believe that early identification of their true information requirements is a crucial factor in a successful implementation. Unfortunately, the recognized importance of the RA process has not been stressed in either practice or research (Galliers, 1987). As a result, systems continue to be designed that do not adequately support the activities that motivated them.
The overall sequence of RA activities, given in Figure 4, is commonly viewed as consisting of four processes (Zmud, 1983): (1) conceptual design; (2) logical design; (3) validation; and (4) formal specification. The first process, conceptual design, encompasses developing a normative model of the system. In the logical design process, analysts assess the strengths and weaknesses of the conceptual design regarding a range of organizational (resources, maturity, attitudes, politics, priorities) and technological (existing systems capabilities, data availabilities, personnel) factors. The result of this process is a system design compatible with the organization's strengths and weaknesses. The third process, validation, is an attempt to determine if a valid set of requirements has been developed. Reviewers must inspect methods of data entry, outputs, and do other evaluations pertaining to the operations of the designed system. Finally, a document, the formal specification, is produced; this document clearly and complete-ly specifies a complete set of information requirements-inputs, outputs, and processing environment-and explains how these objects are to be used. It is important to recognize that, depending on the strategy employed, the four processes may occur sequentially, iteratively, or quasi-simultaneously.
Figure 4.
It is well-understood that both RA and KA processes both work best when end users of the resulting systems participate in the design process. Such participation by end users, however, adds more pressure for good communication between the members of the development team.
Another similarity between RA and KA is
that the end products of each can be used in basically the same ways:
to automate specific functions, thus replacing workers; or to support
workers in their work tasks.’
Another recent development has given more importance to the desirability of merging research from RA and KA: the embedding of expert systems into “traditional IS”. Two of these ES types, technology-intensive and strategic impact, are of interest to this article because they combine elements of both traditional IS and ES.
The authors concluded by saying that as requirements analysis and knowledge acquisition are the most critical steps in their respective system development processes, it is imperative that practitioners use appropriate and sufficient tactics to improve these processes. The authors presented an initial categorization scheme to facilitate the merging of research across the two areas. The article demonstrated that techniques in RA and KA share similarities regarding characteristics and purpose. Finally, they express the hope that the article stimulates IS and ES researchers to develop improved knowledge of these techniques being used to elicit the information that will form the basis of the computerized systems of tomorrow.
By 1999, object-oriented requirements analysis was fairly well seated. From Object-Oriented to Goal-Oriented Requirements Analysis proposes goal-oriented as a paradigm complementary to object-oriented. The former focuses on the early stages of requirements analysis, the latter on late stages. (Mylopoulos and Yu 1999). Returning to the example in our introduction, we see a case in point. While consulting with the other stakeholders may help our analyst to better model objects and activities in the operational environment of a new system, how do we include Kathy Littleton’s insistence the system be “usable and flexible” in our analysis? OOA techniques don’t offer guidance for this.
The authors propose we look at the non-functional requirements framework which centers around the concept of softgoal. The concept of goal is used extensively in Artificial Intelligence (AI) where a goal is satisfied absolutely when its subgoals are satisfied, and that satisfaction can be automatically established by an algorithm. However, since non-functional requirements have a relative, ill-defined and tentative nature we need a looser notion of goals. Softgoals are goals that do not have a clear-cut criterion for their satisfaction. They are satisficed when there is enough positive and little negative evidence that they are satisficed and unsatisficeable when there is enough negative evidence and little positive support for their satisficeability. Softgoals must be analyzed in relation to one another.
Goal oriented analysis focuses on the description and evaluation of alternatives and their relationship to the organizational objectives.
The authors argue that adoption of an alternative set of primitive modeling concepts, such as those of softgoal and goal, can lead to a different kind of analysis than those advocated by OOA techniques. This kind of analysis is important because it deals with non-functional requirements and relates them to functional ones. Preliminary empirical studies suggest that goal-oriented analysis can lead to a more complete requirements definition than OOA techniques.
In their conclusion, the authors trace traditional requirements analysis practice - driven by the programming paradigm of the day – through OOA and argue that perhaps it is time to turn things around and let the concepts and techniques of goal-oriented analysis drive the design and implementation techniques that follow. They envisage a methodology that would perhaps be based on software architectures that share some of the characteristics of human organizations and be grounded in the concepts of agent, goal, and of course softgoal. Here they mention that agent programming is gaining in popularity as the programming paradigm for network computing, so the possibility of a new development methodology grounded on goal-oriented analysis and agent-based design and implementation may not be as farfetched as it might seem. This leads us into the next paradigm we examined.
In 2001, Eric Yu in Agent Orientation as a Modelling Paradigm (Yu 2001) argues that agent orientation can be as significant a paradigm shift for requirements engineering as for software construction.
In this paper, they push for the need to develop agent orientation as a modeling paradigm, quite separately from the use of agents as a software technology. Because the nature of systems and the characteristics of their environments have changed, a more flexible, higher-level set of constructs are needed to deal with a world operating more on social principles than on mechanistic rules. They identified a number of properties that are desirable for a concept of agent that is suitable for the purpose of modeling and analysis. The authors discuss a number of software technologies that could be used to construct such a system including:
While the agent-oriented approach to requirements modeling and analysis can be used regardless of the type of software technology to be used eventually to construct the system, there are clearly advantages if the implementation is also based on agent-oriented concepts (see e.g., Wagner et al, 2000). Efforts are underway to develop an agent-oriented approach to software development that is guided by a concept of agent from the modeling level (Mylopoulos & Castro 2000).
A few articles have been published in 2008 concerning recent RA paradigms. In “Security Requirements Engineering: A Framework for Representation and Analysis” (Haley, et al. 2008) the authors propose a framework for security requirements elicitation and analysis. The framework is based on constructing a context for the system, representing security requirements as constraints, and developing satisfaction arguments for the security requirements. The system context is described using a problem-oriented notation, then is validated against the security requirements through construction of a satisfaction argument. The satisfaction argument consists of two parts: a formal argument that the system can meet its security requirements and a structured informal argument supporting the assumptions expressed in the formal argument. The construction of the satisfaction argument may fail, revealing either that the security requirement cannot be satisfied in the context or that the context does not contain sufficient information to develop the argument. In this case, designers and architects are asked to provide additional design information to resolve the problems. We evaluate the framework by applying it to a security requirements analysis within an air traffic control technology evaluation project.
Another problem-oriented article published in 2008 looks at why a significant percentage of data warehouses fail to meet business objectives or are outright failures. They found that one of the reasons is that requirements analysis is typically overlooked in real projects. In their paper (Giorggini, Rizzi and Garzetti 2008) propose GRAnD, a goal-oriented approach to requirement analysis for data warehouses based on the Tropos methodology. Two different perspectives are integrated for requirement analysis: organizational modeling, centered on stakeholders, and decisional modeling, focused on decision makers. Their approach can be employed within both a demand-driven and a mixed supply/demand-driven design framework.
When I began this paper, I was not quite sure what to expect. From initially browsing one or two articles, the subject looked interesting and relevant. My initial thought however, was that there would be sufficient compartmentalization of possible frameworks such as to clearly distinguish and categorize them. This has not been the case. Instead I have discovered a world of nuances. There appears to be much overlapping, some revisiting, some peripheral implied action and a lot of borrowing from multiple domains – including an application of Burrell and Morgan’s sociological paradigms. This has been an interesting journey.
I have attempted to limit the scope despite the temptation to continue down a multitude of attractive paths. By so doing, I have left a few unanswered questions which could potentially serve as a solid basis for future research in the domain.
Summarizing my overall impression, led me to conclude that requirements analysis paradigms not only exists but have evolved hand-in-hand with general systems development paradigms. As the world of systems analysis has become more complex and further complicated by technologies such as networking and data warehousing, we have traveled from an informal, almost artisanal world of requirements analysis, to a more formal, more structured environment.
Balzer, Robert, Thomas E Cheatham Jr., and Cordell Green. "Software Technology in the 1990's: Using a New Paradigm." IEEE Xplore, 1983: 39 - 45.
Blum, Bruce I. "Three Paradigms for Developing Information Systems." IEEE, 1984: 534 - 542.
Bubenko, J, C Rolland, P Loucopoulos, and V DeAntonellis. "Facilitating “Fuzzy to Formal”." Proceedings of IEEE International Conference on Requirements Engineering. Colorado, 1994. 18 - 22.
Byrd,
Terry Anthony, Kathy L Cossick, and Robert W Zmud. "A Synthesis of
Research on Requirements Analysis and Knowledge Acquisition
Techniques." MIS Quarterly, 1992: 117 - 138.
Eagles Evaluation Working Group. Evaluation of Natural Language Processing Systems. Final Report, Geneva: ISSCO, 1996.
Giorggini,
Paolo, Stefano Rizzi, and Maddalena Garzetti. "GRAnD: A goal-oriented
approach to requirement analysis in data warehouses." Decision Support Systems 45 (2008): 4 - 21.
Haley,
Charles B, Robin Laney, Johnathan D Moffett, and Bashar Nuseibeh.
"Security Requirements Engineering: A Framework for Representation and
Analysis." IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 34, NO. 1, JANUARY/FEBRUARY 2008 34, no. 1 (January 2008): 133 - 153.
Hirschhelm, Rudy, and Heinz K Klein. "Four Paradigms of Information Systems Development." CACM 32, no. 10 (1989): 1199 - 1216.
Mylopoulos, Lawrence Chung, and Eric Yu. "From Object-Oriented to Goal-Oriented Requirements Analysis." CACM 42, no. 1 (January 1999): 31 - 37.
Naumann, Justus D, and A. Milton Jenkins. "Prototyping: The New Paradigm for Systems Development." MIS Quarterly 6, no. 3 (September 1982): 29 - 44.
Woodfield, Scott N, David W Embley, and Barry D Kurtz. "Extending Analysis Paradigms." IEEE Xplore, 1990: 441 - 446.
Yu, Erin. "Agent Orientation as a Modelling Paradigm." Wirtschaftsinformatik, 2001: 123 - 132.