Requirements Engineering for Business Information Systems ... · information systems. The dimension-oriented theory serves as a solid foundation for the design of more effective software

Requirements Engineering for Business Information Systems: ADimension-Oriented Approach

ARBI GHAZARIANArizona State University

Department of Engineering7171 E. Sonoran Arroyo Mall, Mesa, AZ 85212

[email protected]

Abstract: In previous work, we developed a software engineering theory, called dimension-orientation, whichis capable of explaining and predicting the characteristics of the requirements space in the domain of businessinformation systems. The dimension-oriented theory serves as a solid foundation for the design of more effectivesoftware engineering processes in the domain of business information systems. Accordingly, In this paper, wedevelop a theory-backed approach for the engineering of requirements in business information systems, which isbased on the dimension-oriented theory. We further provide a mathematical formalism for the theory and evaluateits theoretical and methodological aspects within the two standard frameworks of design science research andsoftware engineering theory goodness criteria.

Key–Words: Requirements Engineering, Software Engineering Theory, Design Science, Dimension Orientation,Business Information System, Domain Engineering, Theory Goodness Criteria, Requirements Taxonomy.

1 IntroductionIn a series of previous work [3, 11, 4, 10, 5, 6, 9,8, 7, 13, 12], we developed a software engineeringtheory, called dimension-orientation, which is capa-ble of explaining and predicting important charac-teristics of software requirements in the domain ofbusiness information systems. Among other impor-tant aspects, these characteristics include a compre-hensive taxonomy of functional requirements classesin the domain of business systems as well as therelationships between the various taxonomy classes(i.e., the relationships between the various require-ment types). Because of its explanatory and predic-tive capabilities, the dimension-oriented theory canserve as a domain model that accurately and reliablycharacterizes the requirements space in future (i.e.,to-be-developed) business information systems. Thedimension-oriented theory is shown in Tables 1 and 2,which use the four-component theory structure, sug-gested by Sjoberg et al. [23], where the descriptionfor a theory is divided into the following four parts:

1. Constructs (i.e., the basic elements of the theory)

2. Propositions (i.e., descriptions of the interactionsamong the theory constructs)

3. Explanations (i.e., explanations as to why thepropositions of the theory hold)

4. Scope (i.e., the universe of discourse in which thetheory is applicable)

The present work uses the theoretical foundationof dimension-orientation in order to developed a prac-tical and effective approach for the engineering of re-quirements in business information systems. The con-tributions of this paper are twofold: first, we developa mathematical formalism for dimension-orientationand evaluate its theoretical and methodological as-pects within the two standard frameworks of designscience research [14] and software engineering the-ory goodness criteria [23]. Second, we introduce andevaluate a Dimension-Oriented Requirements Engi-neering (DORE) approach for the domain of businessinformation systems. Throughout this paper, we usethe terms business information systems and enterpriseinformation systems interchangeably.

The rest of this paper is organized as follows:in Section 2, we provide a mathematical formalismfor dimension orientation. In Section 3, we presentthe Dimension-Oriented Requirements Engineering(DORE) approach. The evaluation of the DORE pro-cess in a controlled environment follows in Section4. In Section 5, we will evaluate the theoretical andmethodological aspects of the work presented in thispaper. Conclusions and directions for future researchare presented in Section 6.

WSEAS TRANSACTIONS on BUSINESS and ECONOMICS Arbi Ghazarian

E-ISSN: 2224-2899 229 Issue 3, Volume 10, July 2013

Table 1: Constructs, Propositions, Explanations, and the Scope of the Dimension-Oriented Theory

ConstructsC1 Functional Requirements SpaceC2 Functional Requirements Classes (Problem Dimensions)C3 System FunctionsC4 Atomic Functional RequirementsC5 Data Output Functional Requirement ClassC6 Data Input Functional Requirement ClassC7 Event Trigger Functional Requirement ClassC8 Business Logic Functional Requirement ClassC9 Data Persistence Functional Requirement ClassC10 UI Navigation Functional Requirement ClassC11 External Call Functional Requirement ClassC12 Communication Functional Requirement ClassC13 User Interface Functional Requirement ClassC14 UI Logic Functional Requirement ClassC15 Data Validation Functional Requirement ClassC16 External Behavior Functional Requirement ClassC17 Core Functional Requirement Class (Core Problem Dimension)C18 Non-Core Functional Requirement Class (Non-core Problem Dimension)C19 Data Input ItemC20 Data Persistence ItemC21 Compound RequirementPropositionsP1 The Functional Requirements Space is composed of 14 known Functional Requirements Classes, including Data Output,

Data Input, Event Trigger, Business Logic, Data Persistence, UI Navigation, External Call, Communication, User Interface,UI Logic, Data Validation, External Behavior, Post-Condition, and Data Source.

P2 The Nine functional requirements classes of Data Output, Data Input, Event Trigger, Business Logic, Data Persistence,Data Validation, User Interface, User Interface (UI) Logic, and User Interface (UI) Navigation belong to Core FunctionalRequirement Classes.

P3 The five functional requirements classes of External Call, Communication, External Behavior, Post-Condition, and DataSource belong to the Non-core Functional Requirement Classes.

P4 For every Event Trigger, there exists one corresponding System Function, Compound Requirement, or Atomic FunctionalRequirement.

P5 For every requirement of type Data Validation, there is a high probability that at least one corresponding requirement of typeData Output should also exist.

P6 For every System Function, there is a high probability that at least one requirement of type Data Persistence should also exist.P7 For every System Function, there is a high probability that at least one requirement of type Data Input should also exist.P8 For every System Function, there is a high probability that at least one requirement of type Data Output should also exist.P9 For every System Function, there is a high probability that at least one requirement of type Business Logic should also exist.P10 For every Data Input Item, there is a high probability that at least one corresponding Data Persistence Item should also exist.P11 For every Data Input Item, there is a high probability that at least one corresponding requirement of type Data Validation

exist.P12 For every System Function, there exists at least one corresponding Event Trigger.P13 For every violation of a business rule, there exists a system reaction as a corresponding compound requirement, consisting of

a set of atomic requirements.



Table 2: Table 1 Continued

ExplanationsE1 The functional requirements space in the domain of enterprise applications can be logically divided into two partitions: (a)

core functional requirements classes and (b) non-core functional requirements classes. As of yet, there are 9 known core and5 known non-core classes of functional requirements. The sets of of core and non-core classes of functional requirementswill be updated with future observations and discoveries. See E2 and E3 as to why core and non-core classes exist in thedomain.

E2 Enterprise software systems, in order to support their corresponding business processes in the real-world, frequently needto run system functions (through Event Triggers), which collect information (Data Input), check the validity of inputteddata (Data Validation), execute the prescribed business rules pertaining to the supported business process (Business Rules),store information as a result of executing the system functions (Data Persistence), and interact with users through displayingthe results of executing the system functions, error messages, or success messages (Data Output). In GUI-based enterprisesystems, Data Inputs and Data Outputs are tied to user interfaces; Inputs are collected through a user interface and systemoutputs are displayed on the user interface. These give rise to the three user interface-related classes of requirements includingUser Interface, User Interface Logic, and User Interface Navigation. The sequence of event trigger, input, data validation,business rule execution, output, and persistence, or a variation of this sequence, is very common in business systems, givingrise to the 9 core classes of functional requirements.

E3 In addition to the core functional requirements classes, enterprise systems occasionally need to support features that arenot common in the domain, but specific to particular applications within the domain. Although compiling an exhaustivelist of non-core requirements classes would require surveying every imaginable application in the domain and therefore animpossible task to carry on, in our studies so far, we have discovered 5 classes of non-core requirements.

E4 Event triggers, by definition, force the execution of either a single atomic requirement, a compound requirement, or a systemfunction (e.g., a collection of atomic and compound requirements).

E5 When the execution of a data validation rule results in the detection of a violation of the corresponding correctness rules(i.e., detection of erroneous input), as a best practice, the user of the system needs to be notified, through appropriate errormessages and possibly be given instructional messages, describing a course of action that can be taken to rectify the problem.Therefore, the existence of a requirement of type data validation, with a high probability, implies the existence of one or morerelated requirements of type data output.

E6 Most business services, and system functions as their implementations in enterprise systems, need to store information,typically collected from end users or generated as a result of a transaction with the end user. Therefore, it is very likelythat most system functions will have one or more statements of requirements, describing the data persistence aspects of thesystem function.

E7 Most business services, and system functions as their implementations in enterprise systems, need to collect information, typ-ically from end users. Therefore, it is very likely that most system functions will have one or more statements of requirements,describing the data input aspects of the system function.

E8 From P7 and P11, we can deduce that it is very likely that a system function will have at least one requirement of type datavalidation. According to P5, the existence of data validation requirements creates a high probability for the existence ofcorresponding data output requirements. Therefore, from P7, P11, and P5, we can conclude P8. Moreover, System functionsoften need to notify their end users of the successful completion of the system function through requirements of type dataoutput, giving rise to further opportunities for the existence of requirements of type data output in system functions.

E9 Most business services, and system functions as their implementations in enterprise systems, involve the execution of businessrules. Therefore, it is very likely for system functions to have one or more statements of requirements, describing the relatedbusiness rules.

E10 Business services, and system functions as their implementations in enterprise systems, are very likely to need to storeinformation collected from end users to conduct business and complete transactions. Therefore, it is very likely for inputdata items to be stored in the system. From a specification point of view, input data items reappear in statements of datapersistence requirements.

E11 To prevent data entry errors, when such errors are possible, as a best practice, system functions need to validate inputted dataitems before consumption and storage in the system. Therefore, data input items may need one or more relevant statement ofrequirements describing the data validation rules.

E12 All System Functions should be accessible through at least one Event Trigger.E13 Systems need to respond to violations of the business rules. This response is specified in the form a set of requirements.ScopeS1 The Domain of Enterprise Systems



2 A Formalism for Dimension-Orientation

Improving the precision, completeness, and con-sistency of documentation in software engineeringhas been a major goal for the software engineeringcommunity [2]. The use of mathematical expressionsin software engineering artifacts has been a majorpart of the efforts directed towards achieving this goalas mathematics is the best way to achieve precision[2]. A mathematical basis for design allows manytypes of quantitative evaluations of an IT artifact,including optimization proofs, analytical simulation,and quantitative comparisons with alternative designs[14, 16]. In agreement with these considerations, inthis subsection, we will express the propositions ofthe refined dimension-oriented theory, as presentedin Table 1, in a precise and formal mathematicallanguage. We will use a form of probabilistic logicto capture the notion of strong implication, which ispresent in several of our theory propositions. Thiscan be accomplished by extending the first orderlogic with the notion of strong implication denotedas ⇀. In logical propositions involving implications,where the consequent is highly probable, but norcertain, we will replace the standard implicationsymbol (→) with the strong implication symbol (⇀),indicating a strong probability for the consequent, ifthe antecedent is true. Table 3 defines the set vari-ables and predicates that will be used in our formaldefinitions. Note that since our theory concerns theatomic statements of requirements in the domain ofenterprise systems, we define the following universalset, which contains all the elements in the universe ofdiscourse:

U =n∪

i=1Ri =

n∪i=1

Req(Ai)

where Ai is an imaginable enterprise system andReq(Ai) returns the set Ri of all atomic functionalrequirements in enterprise system Ai. This universalset U represents the functional requirements space inthe domain of enterprise systems, which is the subjectof the dimension-oriented theory. Note that atomicityis a property of all the elements of the sets Ri andconsequently the universal set U . We will define ouraxioms as follows:

Part-Whole Axiom:∀x, y[Prt(x, y) ↔ Whl(y, x)]

Non-Inclusion of Self Axiom:∀x[¬Prt(x, x)]

Atomicity Axiom:∀x¬∃y[Atm(x) ↔ Prt(y, x)]

Compoundedness Axiom:∀x∃y[Cmp(x) ↔ Prt(y, x)]

Single-Dimensionality Axiom:∀x¬∃y¬∃z[Sdm(x) → x ∈ y ∧ x ∈ z]

where in the Single-Dimensionality Axiomx ∈ U, y ∈ D, z ∈ D, y ̸= z.

Completeness Axiom:∀x∃y[x ∈ y]

where in the Completeness Axiom x ∈ R, y ∈ D.

This last axiom is known as the CompletenessAxiom as it asserts that every atomic requirement in aparticular system Ai is assigned to a problem dimen-sion from the set D of all known problem dimensions.That is, set D is complete over all the requirementsof Ai. This implies that there exist a classifier func-tion that maps every atomic requirement from systemAi to exactly one of the classes of set D of functionalrequirements classes in enterprise systems.

Note that from the Atomicity and the Compound-edness axioms above we have:

Dichotomy Theorem:Cmp(x) ↔ ¬Atm(x)

An inherent and important property of atomic re-quirements, then, is that they are necessarily single-dimensional. That is:

Single-Dimensionality of Atoms Theorem:∀x[Atm(x) → Sdm(x)]

The functional requirements space is partitionedinto subsets, each representing a class of functionalrequirements - a dimension. As shown in the for-mulae P1 below, and stated in Proposition P1 of thetheory, the classes of functional requirements are fur-ther categorized into two classes of core and non-coreclasses. Formula P2 and P3 further show the knownclasses of core and non-core functional requirements,as described in propositions P2 and P3, respectively.The remaining formulas correspond to their respectivepropositions from Table 1.

D = C ∪N (P1)

C = O ∪ I ∪ T ∪B ∪ P ∪ V ∪ U1 ∪ U2 ∪ U3 (P2)



Table 3: Set Variables

Set VariableSet of Functional Requirements Classes in Enterprise Systems DSet of Core Functional Requirement Class in Enterprise Systems CSet of Non-Core Functional Requirement Class in Enterprise Systems NSet of Atomic Functional Requirements for a particular Enterprise System Ai RSet of Compound Functional Requirements for a particular Enterprise System Ai MSet of System Functions for a Particular Enterprise System Ai FReturns True if atomic requirement x is an Event Trigger T(x)Returns True if atomic requirement x is a Data Validation V(x)Returns True if atomic requirement x is a Data Persistence P(x)Returns True if atomic requirement x is a Data Output O(x)Returns True if atomic requirement x is a Data Input I(x)Returns True if atomic requirement x is a Business Logic B(x)Returns True if atomic requirement x is a UI Navigation Unv(x)Returns True if atomic requirement x is a UI Logic Uil(x)Returns True if atomic requirement x is a UI Uin(x)Returns the set Ri of atomic functional requirements for System Ai Req(Ai)Returns the set of data input items for a data input requirement x Itm(x)Requirement x triggers atomic or compound requirement, or system function y Trg(x,y)Requirement x is part of requirement y Prt(x,y)Requirement x is whole of (i.e., includes) requirement y Whl(x,y)Requirement x outputs a message about requirement y Out(x,y)Requirement x specifies a validity rule for data item y Vld(x,y)Requirement x specifies the storage for data input item y Str(x,y)Requirements set Y specifies the response to Violation of Requirement x Rsp(x,Y)Returns True if requirement x is atomic Atm(x)Returns True if requirement x is compound Cmp(x)Returns True if requirement x is single-dimensional Sdm(x)Set of Data Output Atomic Requirements {r ∈ R : O(r)} OSet of Data Input Atomic Requirements {r ∈ R : I(r)} ISet of Event Trigger Atomic Requirements {r ∈ R : T (r)} TSet of Business Logic Atomic Requirements {r ∈ R : B(r)} BSet of Data Persistence Atomic Requirements {r ∈ R : P (r)} PSet of UI Navigation Atomic Requirements {r ∈ R : Unv(r)} U3

Set of External Call Atomic Requirements N1

Set of Communication Atomic Requirements N2

Set of User Interface Atomic Requirements (UI) {r ∈ R : Uin(r)} U1

Set of UI Logic Atomic Requirements {r ∈ R : Uil(r)} U2

Set of Data Validation Atomic Requirements VSet of External Behavior Atomic Requirements N3

Set of Post-Condition Atomic Requirements N4

Set of Data Source Atomic Requirements N5



N = N1 ∪N2 ∪N3 ∪N4 ∪N5 (P3)

∀ri∃rj∃t∃m[ri ∈ R ∧ T (ri) → rj ∈ R ∧ ri ̸= rj∧Trg(ri, rj)∨m ∈ M∧Trg(ri,m)∨t ∈ F∧Trg(ri, t)]

(P4)

∀ri∃rj [ri ∈ R∧V (ri) ⇀ rj ∈ R∧Out(rj , ri)] (P5)

∀t∃r[t ∈ F ⇀ (Prt(r, t) ∧ P (r))] (P6)

∀t∃r[t ∈ F ⇀ (Prt(r, t) ∧ I(r))] (P7)

∀t∃r[t ∈ F ⇀ (Prt(r, t) ∧O(r))] (P8)

∀t∃r[t ∈ F ⇀ (Prt(r, t) ∧B(r))] (P9)

∀ri∀d∃rj [ri ∈ R∧ I(ri)∧di ∈ Itm(ri) ⇀ rj ∈ R

∧ P (rj) ∧ Str(rj , d)] (P10)

∀ri∀d∃rj [ri ∈ R ∧ I(ri) ∧ d ∈ Itm(ri) ⇀ rj ∈ R

∧ V (rj) ∧ V ld(rj , d)] (P11)

∀t∃r[t ∈ F → r ∈ R ∧ T (r) ∧ Trg(r, t)] (P12)

∀ri∃rj [ri ∈ R ∧B(ri) ⇀ rj ∈ M ∧Rsp(rj , ri)](P13)

3 Dimension-Oriented Require-ments Engineering (DORE)

Having developed a formalized theory that is capableof making predictions about the requirements spacein the domain of enterprise systems, we now put thetheory’s predictions into practical use by using themas input to the design process for a requirements engi-neering process. The result is the following process,called the Dimension-Oriented Requirements Engi-neering (DORE), for the development of requirements

specifications for enterprise systems. The require-ments engineer compiles and negotiates a list of sys-tem functions (e.g., use cases, features, high-level re-quirements, or system capabilities) needed by projectstakeholders for a business system and then followsthe following process to develop a complete specifi-cation for each individual system function. Note howthe process steps are justified based upon the theory’spropositions.

1. Identify and Specify Triggers - Justification:P12 - Identity all the alternative ways (i.e., stim-uli) to trigger the execution of the system func-tion (e.g., system behavior). A system behaviorcan be activated either by:

(a) User generated trigger - an end user signi-fying the system, for instance, through gen-erating a user interface event, such as click-ing on a button, link, or menu item, or typ-ing in a command at a command prompt.

(b) System generated trigger - a system vari-able reaching a predefined threshold. Forinstance, the automatic activation of a sys-tem function to place an order for somequantity of a good, when the inventory levelfor that good reaches a predefined mini-mum level. Another example would be arecurring time trigger that automatically ac-tivates a system behavior in predefined pe-riodic time intervals.

For each identified event trigger, add a uniquelyidentifiable and atomic statement of requirementto the system function specification, describingthe event trigger. Tag each such requirement asbelonging to the event trigger class of functionalrequirements.

2. Identify and Specify Inputs to System Func-tions - Justification: P7 - For each documenteduser generated event trigger in Step 1, identifywhether or not the event trigger requires to passany information to the system function. In otherwords, does the system behavior require user-provided external input before it can be acti-vated? A system service, such as the one ina typical banking system that opens a bank ac-count for a customer, requires personal infor-mation about the clients as well as informationabout the type of account being opened. In con-trast, a reporting system function that is activatedby a user interface event and displays a particularreport all based on default values or the existingdata of the system is an example of a trigger thatdoes not requires user input. An event trigger



that merely makes the user interface for a par-ticular system function accessible to the systemuser is another example of a simple event triggerwithout any user data input. The description formany system use cases start with such an eventtrigger, where the end user of the system noti-fies the system of his or her intention to executea system function by generating a user interfaceevent. In response to such an event, the systemdisplays the input form to collect the required in-formation for the execution of the system func-tion. The user, after entering all the information,eventually generates another event trigger to ex-ecute the service, but unlike the previous eventtrigger, this latter trigger passes the informationentered by the user to the system function.

For each identified system function with inputadd a uniquely identifiable and atomic statementof requirement to the system function specifica-tion, explicitly listing all the input data items thatmust be entered into the system by the end user.Tag each such requirement as belonging to thedata input class of functional requirements.

3. Identify and Specify Data Validations - Justifi-cation: P11 - For every data input item in everydata input requirement specified in Step 2, iden-tify which data inputs require validation to detectand prevent data entry problems and what thosevalidation rules are for each such data input item.

For every identified data input item with val-idations specify each data validation rule as auniquely identifiable and atomic statement of re-quirement. Tag each such requirement as belong-ing to the data validation class of functional re-quirements.

4. Identify and Specify Outputs for Violated Val-idation Rules- Justification: P5 - For every datavalidation requirement, specified in Step 3, iden-tify whether an alert message needs to be dis-played and what the format and content of themessage should be, in case the validation rule isviolated, to inform the end user of the erroneousdata entry and guide the user to rectify the prob-lem.

For every data validation requiring relevant out-put messages add a uniquely identifiable andatomic statement of requirement, explicitly spec-ifying the content and format of the message tobe displayed. Tag each such requirement as be-longing to the data output class of functional re-quirements.

5. Specify User Interface for Inputs and Outputs- Justification: P2 - For each system functionthat requires external inputs from users ( identi-fied in Step 2), add requirements to the systemfunction specification that describe the interface(e.g., GUI such as an input screen) that will beneeded to collect the input data items specifiedin Step 2. The specification of the user interfacerequirements for a system function will includea collection of uniquely identifiable and atomicstatements of requirements that together specifythe various aspects of the user interface includingthe user interface components that will be usedfor data entry, the style of the data input (e.g., en-tering text or selecting from a list), the location ofthe components, and cosmetic aspects such as thelayout, font, and color of the data input screen.One or more user interfaces might be neededfor a single system function. Conversely, mul-tiple system functions can share the same userinterface. Visual descriptions of user interfacerequirements, such as screen mock-ups, are anoption here. Some user interface requirementscan also be derived from the data output require-ments, documented in Step 4, as these outputs aredisplayed through the user interface and, there-fore, can add new statements of requirements tothe specification. An examples of such a require-ment would be a statement describing where anoutput should be placed on a screen. Note that incommand line systems the interactions betweenthe system and the user takes place through aseries of data inputs and outputs rather than agraphical interface.

6. Identify and Specify Event Trigger for UILevel Data Validations - In GUI-based sys-tems, for every data validation requirement spec-ified in Step 3, determine if the rule needs to bechecked at the graphical user interface level, atthe system back end, or both.

For every validation rule identified as requiringvalidation at the UI level, add a uniquely identi-fiable and atomic statement of requirement thatdescribes the user interface event trigger for thecorresponding user interface data input compo-nent. Tag each such requirement as belongingto the event trigger class of functional require-ments.

7. Identify and Specify the Business Rules - Jus-tification: P9 - Identify the set of business rulesthat are relevant to the system function or busi-ness service. Business rules typically specify cal-culations or rule checking using existing data of



the system and/or the new data passed to the sys-tem function. Statements of functional require-ments describing business rules define the rulesof the application domain. These are the rulesthat govern the operations in an enterprise do-main (e.g., banking, insurance, accounting, in-ventory management, order processing, etc.).Document each identified business rule as auniquely identifiable and atomic statement of re-quirement. Tag each such requirement as be-longing to the business rule class of functionalrequirements.

8. Identify and Specify System Reaction for Vio-lated Business Rules - Justification:P13 - Forevery business rule, specified in Step 7, identifythe appropriate system response/reaction to the,in case the business rule is violated. This sys-tem reaction is specified as a set of one or morerequirements. The reaction requirements set caninclude requirements of various types. As an ex-ample of a simple response to the violation ofa business rule, a system may display an alertmessage to the end user. This will lead to theaddition of a requirement of type output to thesystem function specification. As another exam-ple, if the system needs to roll back changes toa database as a result of a violation of a businessrule, this rollback response can be specified as arequirement of type data persistence and addedto the system function specification.For every requirement identified as being part ofthe system response to the violated business rule,add a uniquely identifiable and atomic statementof requirements. Tag each such requirement withits proper class of functional requirements.

9. Identify and Specify Data Persistence - Justi-fication: P6 and P10 - Identify a list of itemsand their values that need to be persisted as a re-sult of executing the system function. Data per-sistence requirements specify all database create,read, update, and delete operations. The list ofitems requiring persistence often includes, but isnot limited to, many of the data input items listedunder the data input requirements, documentedin Step 2.Add one or more uniquely identifiable atomicstatements of requirements to the specificationof the system function, describing the requiredpersistence operation, explicitly stating the listof entities or items along with their values. Tageach such statement of requirement as belongingto the data persistence class of functional require-ments.

10. Identify and Specify Data Outputs for SystemFunction Results - Justification: P2, P8 - Theexecution of system functions results in either asuccessful completion or a failure. In either case,the user of the system needs to be notified of thefailure or success of the service. In the case ofsuccessful execution, results need to be displayedto the user. Success and failure messages as wellas the results of the execution of system functionsare described using statements of requirementsthat specify the content and format of the outputs.Tag each such requirement as belonging to thedata output class of functional requirements.

11. Specify UI Navigation - Justification: P2 - Ifthe fulfillment of a condition transfers the con-trols of the application from the current user in-terface to another user interface of the system(e.g., another screen) then document this transi-tion as a uniquely identifiable and atomic state-ment of requirement. Tag each such requirementas belonging to the UI navigation class of func-tional requirements. UI navigation requirementsdescribe the flow of the application. An exampleof such actions includes the violation of a datavalidation or business rule which takes the userto an error screen.

12. Specify UI Logic - Justification: P2 - For ev-ery user interface, such as a system screen, de-termine if the interface will engage in a dynamicinteraction with the end user. For instance, a sys-tem screen may dynamically update itself andpresent a different set of user interface compo-nents based on an end user’s selection of an itemon the screen. Document the rules for such userinterface interactions as uniquely identifiable andatomic statements of requirements. Tag eachsuch requirement as belonging to the UI logicclass of functional requirements.

4 Controlled Evaluation of DOREIn the previous steps, we used the dimension-orientedtheory as a theoretical foundation, on top of which,we designed the DORE approach to requirements en-gineering. To evaluate the practical effectiveness ofthis requirements method in real-world software en-gineering situations, we must put it into practice byapplying it to the requirements phase in enterprise sys-tem development projects. This will allow us to col-lect evidence on the effectiveness or ineffectivenessof the method. Such evidence can then be used toimprove the design of the method. However, as a



first step in evaluation, it is advisable to test the pro-cess in one or more controlled or simulated smaller-scale proof-of-concept projects before introducing themethod to a real-life software engineering context,where, due to schedule and cost constraints, the stakesare high. Successful applications of the method to pi-lot projects as well as collecting and applying feed-back from such controlled evaluations to improve themethod will help us to increase our confidence on theeffectiveness of the process in real-world large-scaleprojects. Accordingly, we applied the DORE methodto the requirements phase of an information systemdevelopment project to evaluate its effectiveness inproducing complete requirements specifications. Theproject, wherein the DORE method was tested, wasa web-based information system that would combinesocial networking capabilities with Geographical In-formation System (GIS) capabilities, allowing its endusers to shares various categories of stories and newswith friends in their network. Stories were geograph-ically tagged, so it would allow the users to visuallynavigate the network of friends and stories throughan interactive world map. The system included 11system functions and 90 statements of functional re-quirements. A description of this system can be foundin [19]. Our criterion for the effectiveness of the re-quirements method is the completeness of the specifi-cation that it produces. In our case study, which is re-ported in [19], the DORE method helped the require-ments engineer to discover and specify a significantmajority of the system functional requirements (over90%) during the requirements phase, which is veryencouraging. In a number of cases, the statementsof requirements were misclassified (i.e., assigned tothe incorrect class), which were discovered and fixedduring the requirements inspection process. We up-dated the descriptions of the requirements classes aswell as the process steps to minimize the possibilityof incorrect classifications. We also felt that a shorttraining workshop and training material could havesignificantly prevented the occurrence of such cases.We incorporated these insights into our plan for thepreparation of the method before its introduction tolarge-scale industrial projects. Planning is currentlyunderway for the introduction of the DORE methodto a number of industrial projects. Training on DOREis part of this plan.

The development of theories and theory-basedmethods in software engineering involve continuouscycles of refinements. Theories drive the developmentof software engineering methods, while the practicalapplication of such methods provide feedback to re-fine their underlying theories. Once we evaluate theDORE method in industrial projects, we will use theresults from such industrial evaluations to further im-

prove the DORE process.The dimension-oriented theory presented in this

paper captured the essence of functional requirementsin enterprise systems and empirical evidence thus farconfirms that it is capable of making fairly accuratepredictions about its domain of discourse. However,it must be acknowledged that since each software en-gineering setting is unique, software engineering the-ories might need local adaptations to be directly usefulin concrete cases [23]. A corollary of this is that thesoftware engineering methods that are based on suchtheories might need local adaptations as well to reflectthe adaptations in their underlying theories. There-fore, although we believe the dimension-oriented re-quirements method should be sufficient for most en-terprise systems, it is expected that local adaptationsto specific organizational and project contexts mightfurther increase its effectiveness.

5 Evaluating Theoretical andMethodological Aspects in DORE

The ultimate criterion to judge dimension orientationas a software engineering paradigm, and in particularDORE, is how useful it is to the software engineeringpractitioners in the software industry. However, thereare useful evaluation frameworks that provide crite-ria for the evaluation of the theoretical and method-ological aspects of a theory or approach. In this sec-tion, we will use two such widely-used frameworks,namely the software engineering theory goodness cri-teria by Sjoberg et al. [23] and the design science re-search guidelines by Hevner et al [14], to evaluate thegoodness of the dimension-oriented theory as well asthe proposed research and design methodology, whichwas used to develop the DORE method, respectively.

5.1 The Goodness of the Dimension-Oriented Theory

Sjoberg et al. [23] provide a framework for evaluat-ing empirically-based theories in software engineer-ing that includes the followings six criteria:

• Testability

• Empirical Support

• Explanatory Power

• Parsimony

• Generality

• Utility



We will briefly discuss each of these criteria in thecontext of the dimension-oriented theory presented inthis paper. Testability, refers to the degree to which theempirical refutation of a theory is possible [23] andis the criterion that distinguishes science from non-science [18, 23]. Sjoberg et al. [23] emphasize thefollowing three criteria for testability:

• The constructs and propositions of a theoryshould be clear and precise such that they are un-derstandable, internally consistent, and free fromambiguities

• It must be possible to deduce hypotheses fromthe theory’s propositions, so that they may beconfirmed or dis-confirmed

• The theory’s scope conditions must be explicitlyand clearly specified, so that the domain or situa-tions in which the theory should be confirmed ordis-confirmed and applied is clear.

The constructs and propositions of the dimension-oriented theory are clearly stated in Table 1. We fur-ther mathematically formalized the theory constructsand propositions to achieve precision and avoid am-biguities. It is easy to derive hypotheses from thistheory’s propositions that can be tested for validity.In fact, this is precisely what we did when we evalu-ated the predictive power of the theory in our previouswork. The theory’s domain was clearly stated to bethe domain of business information systems. There-fore, we believe that the dimension-oriented theory,presented in this paper, meets the testability criterionfor a theory.

The empirical support criterion refers to the de-gree to which a theory is supported by empirical stud-ies that confirms its validity [23]. We used data from18 software projects to build and test the dimension-oriented theory. We believe these 18 cases providedus a large enough empirical data set that supports thetheory. However, as with any other theory, replicatedstudies to test the theory can increase our confidenceto the validity of the theory by aggregating further ev-idence to support the theory. We plan for further repli-cations of the study as future work.

The explanatory power of a theory refers to thedegree to which a theory accounts for and predictsall known observations within its scope. It also re-fer to how well the theory relates to what is alreadywell known [23]. In previous work, we evaluated thepredictive power of the dimension-oriented theory anddemonstrated that it has a high predictive power in thedomain of enterprise systems.

Parsimony refers to the degree to which a theoryis economically constructed with a minimum of con-

cepts and propositions [23]. We tried to achieve somedegree of parsimony by detecting and removing re-dundant constructs and propositions from the theory.For instance, in an earlier version of the theory, wehad a Proposition P5, which was later removed in thesubsequent version of the theory because PropositionP12 subsumed it and therefore Proposition P5 was notnecessary.

Generality refers to the breadth of the scope of atheory and the degree to which the theory is indepen-dent of specific settings [23]. A theory with a largescope, such as the domain of all software projects, willhave a larger explanatory breath and thus a broaderapplicability, but may demand more effort in opera-tionalizing the theory to a given situation. In contrast,a lesser generality might make a theory immediatelyapplicable [23]. As we discussed earlier in this pa-per, our main goal from theory building was to informthe design process for a requirements method for thedomain of enterprise systems and therefore direct ap-plicability was our top priority. Accordingly, we lim-ited our theory to the domain of enterprise systems.However, as future work, we plan to conduct similarstudies in other software domains to understand thedegree to which the dimension-oriented theory holdsfor other domains.

The utility of a theory refers to the degree towhich a theory supports the relevant areas of thesoftware industry [23]. Our goal in developing thedimension-oriented theory was to support the require-ments process in the domain of enterprise systems.We believe the theory completely supports this areaand thus has a high practical utility.

5.2 Conformance to Design Science Guide-lines

The work reported in this paper nicely fits withinthe design science paradigm [14], which providesa framework for information systems (IS) research.Hevner et al. [14] established the following sevenguidelines that set the requirements for effective de-sign science research:

• Guideline 1: Design as an Artifact

• Guideline 2: Problem Relevance

• Guideline 3: Design Evaluation

• Guideline 4: Research Contributions

• Guideline 5: Research Rigor

• Guideline 6: Design as a Search Process

• Guideline 7: Communication of Research



We will briefly discuss what each guidelinemeans and how we addressed the guideline. Thefirst guideline, design as an artifact, states that designscience research must produce a viable InformationTechnology (IT) artifact in one of the following fourforms, which is created to address an important orga-nizational problem [14]:

• Construct (i.e., vocabulary and symbols)

• Model (i.e., abstractions and representations)

• Method (i.e., algorithms and practices)

• Instantiation (i.e., implemented and prototypesystems)

These four types of artifacts provide guidelinesand prescriptions that allow us to understand and solveproblems inherent in the development and implemen-tation of information systems within organizations[15, 17]. Constructs provide the vocabulary and sym-bols used to define problems and solutions [14] andas such have a significant impact on the way in whichtasks and problems are conceived [1, 20]. In our work,the concept of a problem dimension is the main con-struct. It allows us to view and describe softwareengineering problem spaces, such as the functionalrequirements space, as a set of problem dimensions,which in turn impacts how we perceive and attempt tosolve software engineering problems, hence the nameDimension-Oriented Software Engineering (DOSE).The search for an effective problem representation iscrucial to finding an effective design solution [26]. Si-mon [22] states that ”solving a problem simply meansrepresenting it so as to make the solution transparent”.

We argue that representing software problemspaces as a set of problem dimensions indeed makestheir solutions transparent. We developed a theorythat revolves around the notion of problem dimen-sions. The laws and the explanations of the proposedtheory explain and predict the nature and the relation-ships among the problem dimensions in the domain ofenterprise systems and, therefore, provide a model forthe domain of enterprise systems. In previous work,we demonstrated that this model is a fairly accuraterepresentation of systems in the domain of enterprisesystems. We then used this empirically-verified modelin building a requirements practice around it (Subsec-tion 3) - the dimension-oriented requirements engi-neering. In Subsection 4, we further demonstrated thefeasibility and effectiveness of the new requirementsprocess by instantiating it in the context of a proof-of-concept information system development project.Therefore, our work involved the creation of all four

types of IT artifacts that are the subject of the designscience research paradigm.

The second guideline, the problem relevance,states that the objective of design-science research isto develop technology-based solutions to importantand relevant business problems. In the introductionto this paper, we discussed that the quest for softwareengineering approaches that are economically viableis both important and relevant to the business orga-nizations, who depend on information technology toachieve their business goals, namely increasing rev-enue and decreasing cost. The dimension-oriented re-quirements process described in this paper, is a steptoward achieving a more effective and productive ap-proach for developing high-quality information sys-tems. A high-quality and complete specification canavoid unnecessary rework and, therefore, make a sig-nificant contribution to achieving a more economicapproach to information systems development.

The third guideline, design evaluation, empha-sizes that the utility, quality, and efficacy of a designartifact must be rigorously demonstrated via well-executed evaluation methods including observationalmethods such as case and field studies, analyticalmethods such as static analysis, architecture analy-sis, optimization, and dynamic analysis, experimentalmethods such as controlled experiments and simula-tion, testing-based methods such as functional (blackbox) testing and structural (white box) testing, anddescriptive methods such as informed arguments andscenarios [14].

Evaluation is an integral part of the research anddesign methodology that was followed to produce thedimension-oriented theory as well as the dimension-oriented requirements engineering approach pre-sented in this present work. For instance, we eval-uated (a) the validity of the hypothesis underlyingthe dimension-oriented theory, (b) the validity andthe predictive power of the dimension-oriented the-ory that is formed based on the accepted hypothesis,(c) the effectiveness of the method that has been builtbased on this theoretical foundation in a controlledenvironment, and (d) the resulting DORE method byputting it into practice in the real environment. Re-sults from every form of evaluation is fed back to thedesign process, and is used to improve the process.

The fourth guideline, research contributions,states that effective design-science research must pro-vide clear and verifiable contributions in the areasof design artifact, design foundations, and/or designmethodologies. The work reported in this papermake a number of such contributes including a de-sign methodology, a set of constructs to view and rep-resent software engineering problem spaces such asthe functional requirements space, a domain model for



enterprise systems, a theory, a requirement engineer-ing method, and a series of evaluations.

The fifth guideline, research rigor, states thatdesign-science research relies upon the application ofrigorous methods both in the construction and evalua-tion of the design artifact [14]. The design methodol-ogy presented in this paper relies on well-establishedscientific research methods including, hypothesizing,hypothesis testing via adherence to appropriate datacollection and analysis techniques, theory buildingand evaluation as well as other established best prac-tices in empirical software engineering research.

The sixth guideline, design as a search process,states that the search for an effective artifact requiresutilizing available means to reach desired ends whilesatisfying laws in the problem environment [14].Hevner et al. [14] emphasize that the search for thebest, or optimal, design is often intractable for realisticinformation systems problems. Therefore, it involvesa heuristic-based iterative search process for a satis-factory solution. The requirements process, presentedin this paper, was designed through several cycles ofdesign, evaluation, and refinements. We developeda theory to inform and facilitate the initial design ofthe process and then used feedback from several typesof evaluations to refine and improve both the processand its underlying theory. The end result is a repeat-able requirements process that is capable of guidingthe requirements engineer through the task of creatinga complete functional specification for systems in thedomain of enterprise systems. The design of the pro-cess steps is based on the laws of the domain and helpsto minimize specification defects in the form of miss-ing requirements hence producing a complete specifi-cation of functional requirements.

The seventh guideline, the communication ofresearch, emphasizes that design-science researchmust be presented effectively both to technology-oriented as well as management-oriented audiences[14]. Technology-oriented audiences need sufficientdetails in order to be able to implement the de-scribed design artifact. We have described a step bystep requirements process (see Subsection 3), whichshould be easy for requirements engineers to followto produce functional specifications for their enter-prise projects. Hevner et al. [14] also emphasizethat it is important for such audiences to understandthe processes by which the artifact - in our case, theDORE requirements process - was constructed andevaluated. The benefits of such an understanding isthat it establishes repeatability of the research projectand builds the knowledge base for further researchextensions by design-science researchers in informa-tion systems. We described our design methodologyin previous work and rigorously followed it to design

the DORE requirements process. Therefore, we be-lieve it should be possible for information systems re-searchers to reuse the proposed design methodologyto design novel software engineering methods or ex-tend the work reported in this paper. In the relatedwork section of this paper, we will discuss some pos-sible directions for future work.

Management-oriented audiences, on the otherhand, need sufficient details in order to decide whetherorganizational resources should be committed to con-structing, or purchasing, and using the artifact withintheir specific organizational context. In our work, weattempted to achieve this by conducting case studiesand collecting evidence on the effectiveness of theproposed requirements methods. Data from our casestudies thus far confirm that the process can help ISdevelopment organizations to be more productive increating functional specifications for enterprise sys-tems (i.e., economic incentive), while helping them toproduce higher-quality functional specifications (i.e.,more complete), which in turn can increase the qualityof the resulting information systems.

6 Conclusions and Directions for Fu-ture Work

Our position is that a fruitful avenue for designingmore effective software engineering processes is tobuild domain-specific software engineering theoriesthat can then be used as a solid scientific foundationfor the design of various life cycle processes withinthe domains of interest. Accordingly, in this paper,we presented a domain-specific approach for require-ments engineering in the domain of business infor-mation systems, called Dimension-Oriented Require-ments engineering (DORE), and demonstrated howevery step in the DORE process is backed by the-ory propositions and their corresponding explanationsfrom the dimension-oriented theory of requirementsspace. More details about the dimension-oriented the-ory and its practical applications in various areas ofsoftware engineering can be found in our previousworks (see [3, 11, 4, 10, 5, 6, 9, 8, 7, 13, 12], for ex-ample). In this paper, we demonstrated yet anotherpractical application of this theory in the area of re-quirements engineering for the domain of business in-formation systems. We also evaluated the method-ological and theoretical aspects of the work reportedhere through the two frameworks of design science re-search [14] and software engineering theory goodnesscriteria [23].

In future work, we plan to use dimension-orientation as a theoretical foundation to improveother software life cycle processes, including architec-



ture [7][25]. Work on a dimension-oriented approachto test case development is currently underway. Wealso plan to apply dimension-orientation to other soft-ware domains, including the domain of scientific sim-ulation applications [21][24]. Finally, we plan to in-troduce the DORE requirements process into a num-ber of industrial projects and use the resulting feed-back to further improve the DORE process.

References:

[1] R.J. Boland, Design in the Punctuation of man-agement science, in Managing as Design: Cre-ating a Vocabulary for Management Educationand Research, R. Boland (ed.), Frontiers ofManagement Workshop, Weatherhead School ofManagement, June 2002.

[2] X. Feng, and D.L. Parnas, and T.H. Tse,T. O’Callaghan, A Comparison of TabularExpression-Based Testing Strategies, in IEEETransactions on Software Engineering, IEEEComputer Society, Vol. 37, No. 5, Septem-ber/October 2011, pp. 616-634.

[3] A. Ghazarian, Characterization of FunctionalSoftware Requirements Space: The Law of Re-quirements Taxonomic Growth, in Proceedingsof 20th IEEE International Requirements Engi-neering Conference (RE’2012), Chicago, USA,September 2012.

[4] A. Ghazarian, Coordinated Software Develop-ment: A Framework for Reasoning about TraceLinks in Software Systems, Proc. of the IEEE13th Int’l Conf. on Intelligent Engineering Sys-tems (INES 2009), April 2009, pp. 39–44.

[5] A. Ghazarian, Effects of Source Code Regular-ity on Software Maintainability: An EmpiricalStudy, Proc. of the IASTED Int’l Conf. on Soft-ware Engineering and Applications (SEA 2010),Marina del Rey, USA, November 2010.

[6] A. Ghazarian, A Probabilistic MathematicalModel to Measure Software Regularity, Pro-ceedings of the 15th IASTED International Con-ference on Software Engineering and Applica-tions (SEA 2011), Dallas, December 2011, USA.

[7] A. Ghazarian, A Domain-Specific ArchitecturalFoundation for Engineering of Numerical Soft-ware Systems, WSEAS Transactions on Systems,No. 7, Vol. 10, July 2011, pp. 193–208.

[8] A. Ghazarian, Traceability Patterns: An Ap-proach to Requirement-Component Traceabilityin Agile Software Development, Proc. of the 8thWSEAS Int’l Conf. on Applied Computer Science(ACS’08), Venice, 2008, pp. 236–241.

[9] A. Ghazarian, A Formal Scheme for SystematicTranslation of Software Requirements to SourceCode, Proceedings of WSEAS Applied Comput-ing Conference (ACC 2011), Angers, France,November 2011, pp. 44–49.

[10] A. Ghazarian, A Matrix-Less Model for Trac-ing Software Requirements to Source Code, Int’lJournal of Computers, NAUN, ISSN: 1998-4308, Issue 3, Volume 2, 2008, pp. 301–309.

[11] A. Ghazarian, M. Sagheb-Tehrani, and A. Ghaz-arian, A Software Requirements SpecificationFramework for Objective Pattern Recognition:A Set-Theoretic Classification Approach, Proc.of the 16th IEEE Intl Conf. on Engineeringof Complex Computer Systems (CECCS 2011),USA, 2011, pp. 211–220.

[12] A. Ghazarian, R. Chughtai, Dimension-OrientedInspection of Use Case-Based RequirementsSpecifications, Proceedings of the EuropeanConference of Computer Science (ECCS12),WSEAS/NAUN, Paris, France, December 2012.

[13] A. Ghazarian, Dimension-Driven Software De-velopment Through Traceability Patterns, Pro-ceedings of the European Conference of Com-puter Science (ECCS12), WSEAS/NAUN, Paris,France, December 2012.

[14] A.R. Hevner, and S.T. March, and J. Park, andS. Ram, Design Science in Information SystemsResearch, MIS Quarterly, Vol. 28, No. 1, March2004, pp. 75-105.

[15] S. T. March, and G. Smith, Design and Natu-ral Science Research on Information Technol-ogy, Decision Support Systems (15:4), Decem-ber 1995, pp. 251-266.

[16] F. Neri, Learning and Predicting Financial TimeSeries by Combining Evolutionary Computationand Agent Simulation, Applications of Evolu-tionary Computation, EvoApplications, LNCS6625, pp. 111–119, Springer, Heidelberg (2011).

[17] J. Nunamaker, and M. Chen, and T. D. M. Pur-din, Systems Development in Information Sys-tems Research, Journal of Management Infor-mation Systems (7:3), inter 1991a, pp. 89-106.

[18] K. Popper, The Logic of Scientific Discovery,Hutchison, London, 1959.

[19] R. Pulavarthi, and A. Ghazarian, An InteractiveNetwork of Events with Geographic Perspec-tive, WSEAS Transactions on Information Sci-ence and Applications, No. 12, Vol. 9, pp. 369-378, World Scientific and Engineering Academyand Society, December 2012.

[20] D. A. Schon, The Reflective Practitioner: HowProfessionals Think in Action, Basic Books,New York, 1983.



[21] L. Shuang, W. Zhixin, W. Guoqiang, A Feed-back Linearization Based Control Strategy forVSC-HVDC Transmission Converters, WSEASTransactions on Systems, Issue 2, Volume 10,pp. 49-58, February 2011.

[22] H. A. Simon, The Sciences of the Artificial, 3rdEdition, MIT Press, Cambridge, MA, 1996.

[23] D.I.K. Sjoberg, T. Dyba, B.C.D. Anda, and J.E.Hannay,Building Theories in SOftware Engi-neering, Guide to Advanced Empirical Softwareengineering, F. Shull et al. (eds.), Springer, 2008,pp. 312-336.

[24] T-S Tsay, Intelligent Guidance and ControlLaws for an Autonomous Underwater Vehicle,WSEAS Transactions on Systems, Issue 5, Vol-ume 9, pp. 463-475, May 2010.

[25] S-G Yoo, K-Y Park, J. Kim,Software Architec-ture of JTAG Security System, WSEAS Transac-tions on Systems, Issue 8, Volume 11, pp. 398-408, August 2012.

[26] R. Weber, Editor’s Comments:Still DesperatelySeeking the IT Artifact, MIS Quarterly (27:2),June 2003, pp. iii-xi.



Documents

Requirements Engineering for Business Information Systems ... · information systems. The dimension-oriented theory serves as a solid foundation for the design of more effective software