Requirements Engineering for Enterprise Systems: What We Know and What We Don’t Know? - Intentional Perspectives on Information Systems Engineering - page 118

elicitation techniques, the ARIS framework [ 48] is one of the most popular.
It provides RE professionals with a ready-to-use repository of industry-sector-
specific business process models, meant to help structuring requirements elicita-
tion interviews and making them more effective. The large consulting companies
(e.g. Accenture, Cap Gemini, IBM, and others) have also developed proprietary
reference-model-based elicitation approaches which rest on the very same idea
as ARIS does. Another example of a business-area-specific elicitation approach
is SCOR [31] , which proposed an extended reference model of supply chain
processes, including the structuring of information exchanged between business
processes.
Furthermore, since 1992, the use of reference models has been encouraged by
all major ES package vendors (SAP, Baan, Oracle and PeopleSoft). They docu-
mented the functionality of their respective packages in the form of ES reference
models that also come for free to ES adopters as part of the ES itself. This made
it possible, for RE staff and clients engaged in elicitation, to inform themselves
quickly about the concerned ES functionality in business terms by navigating
from the ES process and data models to the relevant piece of online documen-
tation and to the smallest unit of software functionality, namely the transactions
[ 12] .
3. Quality-model-based approaches , which focus on the joint elicitation of func-
tional and non-functional requirements by using standard underlying quality
models or quality frameworks. The proposals in [ 6, 17] help building quality
models for ES by deploying the ISO/IEC-9026 model, while [ 49] presents a
Fuzzy Quality Function Deployment approach that helps translating functional
requirements expressed with linguistic variables into non-functional require-
ments.
4. Feature-based approaches , which draw on the idea of top-down refinement
of both functional and non-functional requirements. Similarly to the package-
specific-reference-model-based approaches, the feature-based approaches help
elicit domain knowledge through the investigation of the specification of the ERP
package. These approaches term a function (or a quality attribute of the package)
“a feature” [ 22] . Examples of feature-based approaches are the PORE method
[ 28, 29, 33] and the PAORE approach [ 22] . When using these approaches, the
elicitation analyst first shortlists suitable packages that match the ERP-adopter's
requirements, and then elicits and documents in detail the requirements by
presenting one concrete package's specification to the clients and by adding
those client-specific requirements which are not included in the original package
specification.
5. Constructionist and organization-theory-based approaches , which consider (i)
ES requirements as a specific form of knowledge representation, (ii) the ES as
an organizational transformation system, e.g. a system that changes its users'
work patterns, and (iii) the ES project reality as socially constructed [ 2, 4,
24, 39] . These approaches rest on the position that our understanding of the
ES requirements can be complete only when we understand the organizational
transformation that the ES enables and the effect of the transformation on the