Chapter 6

Requirements Engineering

LEARNING OBJECTIVES

After reading this chapter, you will be able to understand:

 What is requirement engineering?

 Document requirements using the following

 Structured English
 Event process chains by SAP
 Object-oriented modelling
 Object Process Model
 Data Activity Model for Configuration (DAMC)

6.1 INTRODUCTION

As mentioned in Chapter 2, an ERP implementation has multiple phases (refer to Figure 2.1).
This chapter concerns the second phase of ERP implementation namely requirements
engineering (RE). This phase is also referred to as creation of business blueprint. In the RE
phase, needs of different stakeholders are identified and documented using some standard
modelling technique for subsequent communication and realization purpose. This phase consist
of requirements elicitation, requirements representation and requirements
validation. Requirements are gathered from customers, system users and others who have a
stake in the system during requirements elicitation phase. Requirements are represented
through various models.

An ERP system automates and integrates business processes across the organization.
Therefore, requirements are expressed in terms of business processes that are being
considered for inclusion in ERP system. Defining and documenting the requirements involve the
following:

 Establishing a high-level project scope by working with senior executives to determine

the processes to be included in the ERP implementation.
 Establish ownership for the business processes included in the ERP implementation.
 Designate team leaders for documenting business processes.
 Produce business process documents.

As described in Chapter 1, an organization and its business processes evolve over a period of
time. Business processes may not be documented or the documents may not be up-to-date. It
is a challenging task to gather requirements for ERP system. But once business blueprints are
created, they can be used for multiple purposes.

 Use these documents to invite quotations or bids from the perspective ERP vendors.
 These documents serve as baseline documents for establishing the gap between the
solution offered by the vendor and the requirements. One would like to select an ERP
solution with minimum gap. The gap is a factor in the ERP implementation risk, time
and cost.
 These documents are used as reference for ERP configuration.
 These documents also serve as reference in education and training.
 In future, if a change is required in a business process, these documents serve as
reference documents, a new version of the document is created and a log is
maintained.

A big question is whether an organization should model its business processes from the scratch
or not. Modelling business processes of an organization is expensive and time consuming. If the
organization has never documented its processes, its staff may not have modelling expertise.
Simple mistakes such as focusing on functions rather than processes can render the whole
effort worthless. For example, if modelling focuses on individual’s activities rather than the
processes of the organization, the model will unnecessarily proliferate and the larger picture
may be lost. Sometimes, an amateur may misrepresent processes specially in the absence of
any documentation.

An alternative is to do a preliminary shortlisting of potential ERP vendors and then choose

business models of one of the vendors as reference. Business process modelling involves
identifying the common components, adding the missing components and deleting
extra/irrelevant components. The advantages of this approach are easy gap analysis and
communication with the vendor because of the common reference.

Some researchers oppose the idea of using an ERP specific modelling technique; rightly so,
since the issue addressed by the enterprise requirements are independent of the specific ERP
package.

All companies managing from small and medium enterprises (SMEs) to large, seem to gather
basic information about ERP vendors and then shortlist them based on some very high level
factors such as their past clients, implementation time and cost, etc. Then the requirements are
documented using either structured English or questions (discussed in Section 6.2). The
shortlisted vendors are asked to make a presentation. Equipped with a reasonable knowledge
of the systems, they make a selection by analysing the prototype, examination by consultants
and/or taking the studies done by companies like Gartner etc. The vendor is then involved in
modelling the business processes using its own modelling techniques.

Another approach is to pick an ERP solution that has minimum gap and then adapt its business
processes discarding the existing business processes of the organization. This approach is
referred to as IT-driven re-engineering. Business process re-engineering is discussed in Chapter
7.
Irrespective of the approach taken for modelling the business processes, it is a good idea to
start with critical business processes. Business processes that give competitive advantage to an
organization are referred to as critical business processes. These processes are added to the
requirements first, and in the next iteration more generic requirements are added. The generic
processes will be supported by almost all ERP solutions.

The business blueprints will have to be managed and maintained to counter the following
problems:

 Simultaneous update: Multiple persons may have to work separately on the same
document or different parts of the document. If everybody works on the same copy,
the last one to make changes may easily destroy the work of others.
 Shared document: If multiple copies of the document are created, a change in one
copy may not reflect in all other copies.
 Common document: A document that has been finalized becomes a reference
document and multiple people may refer to it. If for some reason, a change is made
to the reference document, every user must be informed. That means someone has
to know who all are affected by the change in the reference document.
 Versions: A change in the document may fix one issue but may introduce another
one. Sometimes, one may have to go back to what was discussed and rejected earlier.

The primary requirement is management of documents including sharing, version and change
management. A librarian will manage the documents. Once a document is finalized and
becomes part of the library, it cannot be changed casually. The change has to be justified,
costed and approved by the concerned authority. The change approval strategy has to be
worked out a priori. The librarian has to maintain record of all references (people and
documents) to the documents in the library. In case, a document from the library is changed, all
concerned people are informed (a policy is required to know how changes are communicated)
and all documents are cross checked for any conflicts or discrepancy. The documents such as
requirement documents, re-engineering documents, test plan and technology documents are
all maintained by the librarian. Thumb rule is that all the documents that go through multiple
revisions, developed by multiple people and refereed to by multiple people and documents
should be maintained and managed.

ERP vendors offer help for modelling business processes using their own reference models. For
instance, SAP suggests that you model your business processes using their reference EPC
models (discussed in Section 6.3). Some techniques used for capturing requirements are
discussed next.

6.2. STRUCTURED ENGLISH AND STRUCTURED INTERVIEWS

SMEs do not adopt any formal method for modelling their processes. Often times, the inhouse
team may not have skillset to undertake the business process modelling task. They rely on the
implementation partner to a greater extent. Recall that an ERP implementation involves a
vendor (who supplies the ERP software), an implementation partner (who configures the ERP
software according to the business needs of the client) and a consultant (who advises the client
and protects the client’s interests). In the beginning, the client team prepares an informal
description of their processes by talking to business process owners. In SMEs, processes are
mostly people centric. On a visit to two SMEs in Kanpur, and after having discussion with their
project leader and implementation leaders, it was found that they did not use any specific
modelling technique. Incidentally, processes were not documented anywhere and it was a
challenge to get a description of the business processes. Employees were the business process
owners who showed some resistance (refer to Chapter 4) in sharing their business processes
with the implementation partner and the consultant.

One popular method for capturing requirements informally is through structured interviews.
The client will need to detail company profile and processes. Some of this information may
seem trivial but it is important for the vendors and consultants to understand the organization.
A set of high-level questions for capturing the organization structure that are seen across client
organizations, software vendors and consultants is shown in Figure 6.1.

FIGURE 6.1 Questions for Capturing the Organization Structure Using Structured English

To summarize, a written document about organization’s vision, mission and structure provides
a common baseline to the clients, the vendors and the consultants. During the process, the
client gains a better understanding of its organization. The next step is to detail each process
that will be included in the ERP implementation using structured interviews and recording the
responses using structured English. A sample set of questions for material requirement
planning process of a manufacturing organization is shown in Figure 6.2.

These questions partially capture MRP process of an organization. This list of questions is not
exhaustive. An organization will come up with questions to represent their own concerns and
process specific details. One can add another 30 questions easily. The questions and their
answers are organization specific but vendor independent. Structured interviews may
compliment any of the formal techniques for capturing requirements.

FIGURE 6.2 Questions for Finding About the Purchase Process of an Organization

6.3. EVENT-DRIVEN PROCESS CHAINS

We already know that SAP is the largest ERP company. SAP has its own proprietary modelling
technique called event-driven process chain (EPC).

SAP uses EPC as basic modelling technique. An EPC captures tasks or functions (what should be
done), events (when should something be done), organization (who should perform the task)
and communication (what information is required to perform the task). In EPC diagrams, events
are passive elements. They describe the circumstances that trigger a function. Examples of
events are sales order entered, stock not available, quality test failed, etc. In the EPC diagrams,
an event is represented as a hexagon. Functions are active elements in EPC. They model the
tasks or activities within the company. Examples of functions are create sales order and check
stock. A function is represented as a rounded rectangle. A function in EPC diagram may end
with more than one mutually exclusive events. There are objects such as information, material
or resource objects that portray objects from the real world. A function may use these objects
as input or may produce them as its output. Examples are material data, purchase order data,
etc. An object is represented as a rectangle. The organizational unit that performs the activity is
represented as an oval. Example organization units are sales department, purchase
department, quality department, etc.
A control flow connects events with functions creating chronological sequence and logical
interdependencies between them. A control flow is represented as a dashed arrow.

Information flow shows connection of a function with input and output objects. Input objects
are read, and the output objects are changed or created. Information flow is represented as a
solid arrow. The legends are shown in Figure 6.3. The sales and order processes using EPC are
shown in Figure 6.4. EPC shown in Figure 6.4 is not a standard reference model of SAP. It is a
generic process. For reference model of SAP, the book on SAP business blueprint can be
referred.

This process creates a sales order for a particular customer after verifying their credit limit.
Then the availability of items is checked. If items are available, the material is packed and
dispatched updating the inventory. Customer invoice is created and the financial records are
updated. If ordered items are not available, they have to be procured from the vendor by first
creating a purchase requisition and then converting it to a purchase order. The purchase order
will be given to a selected vendor who will supply goods. The received goods/items go through
a quality check and finally goods receipt is created. Inventory is also updated. When invoice is
received from the vendor, payment is made and necessary postings to the financial accounts
are also made. The pending sales orders can now be processed.

FIGURE 6.3 EPC Legends

Each function in EPC accesses global data and communicates with other functions through
global data. EPC reference models can be viewed in the following four different ways.

1. Component model: Component model captures all the functions performed by an

organization. If we retain only the functions that are performed and do away with all
other details contained in an EPC, then a component view is seen. A component view
looks like a tree that may have multiple levels as follows.
1. Level 0 describes an application as a whole.
2. Level 1 contains the functional areas covered by the application.
3. Level 2 contains the main tasks of a given functional area.
4. Level 3 contains the individual tasks performed within the scope of a main
function from the reference models.
Figure 6.5 shows a partial component model of a company that trades stationary.
2. Organization model: The organizational model captures the structure of the
organization. An organization is divided into functional units and business units. A
functional unit may have further divisions such as departments or cells, etc. An
organizational map, which also looks like a tree, shows the relationships among the
organizational units. The organizational map serves as a reference for organization
restructuring. The organizational model also serves as a reference for deciding
different levels of access required at different levels of hierarchy. Figure 6.6 shows a
partial organizational model of a company that trades stationary. This company has
units to manage sales, purchase and warehouse. There would be other units that
have not shown. Each unit may have further subunits. Such a figure captures the
organizational structure and the division of responsibilities.
3. Data model: The data required by functions is captured by the data model. The model
that SAP uses is different from the standard techniques such as entity relationship
diagrams (ER) or extended ER diagrams. The data/information and resources are
represented as rectangles. Arrows are used to show specialization/generalization and
a two-headed arrow with a stroke is used to show a relationship between data
entities. In Figure 6.7, a customer could be an orderer, a receiver of the goods or a
debitor. A customer is associated with an account that could be a general ledger
account (payable/receivable).
4. Interaction model: Firstly, it is required to club together the functions that an
organizational unit performs, then an interaction map to show interaction between
organizational units is created. No details are included in the interaction map. For
example, a customer interacts with sales units of the organization and sales unit
interacts with accounting. An interaction map shown in Figure 6.8 captures these
interactions.
FIGURE 6.4 Event Process Chain for Sales and Order Process
FIGURE 6.5 Component Model (Partial) of a Stationary Trading Business
FIGURE 6.6 Organizational Model (Partial) of a Stationary Trading Business
 FIGURE 6.7 Data Model (Partial) of a Stationary Trading Business

Variation of EPC called configurable EPC also exists in which a function can be marked as
optional. SAP has 3,000 reference business processes represented as EPC models. SAP claims
that these reference models capture best business practices followed across the globe. An
organization should be able to find almost all of their business processes among these
reference models. These models include business processes from all business units of an
organization such as financial accounting, inventory management, organizational management,
plant maintenance, procurement, production planning, project management, quality
management, sales and distribution, etc. There are multiple versions of the same process to
cover variations in the processes. SAP also claims that their reference models cover all options
for a process and these represent best practices. If a client is doing a process in any other way,
they should consider changing their business process. The question whether an organization
should change its process or not falls under the general discipline of business process re-
engineering. Business process re-engineering is discussed in Chapter 7.
 FIGURE 6.8 Interaction Model (Partial) of a Stationary Trading Business

6.4 OBJECT-ORIENTED MODEL

It is observed that 70 per cent or more of flow within an organization (manufacturing or

service) is information. This result confirms the claim by Toffler, that we are living in an
information society and organizations have become information organizations. For a business
process, data is important and a business process should be analysed in terms of data and
information that it modifies. Data is an important constituent of business processes and one
needs to look at how data is defined, created, modified and used. In fact, enterprise resource
planning software models an organization in terms of data and their relationships, and a set of
functions that operate on the data.

Object-oriented (OO) model supports this view point and focuses on the data entities. The
building block of OO model is named class that consists of data and methods (functions) that
operate on the data. A class has relationship with other classes and interacts with other classes.
A class may request another class to perform some action and/or provide data. The modelling
may proceed in two different ways:
  View integration approach: Translate informal individual requirements into formal
representation and merge.
 Centralized schema design approach: Merge informal individual requirements and
then create formal representation.

Since OO modelling technique is not directly supported by any of the major ERP players, no
reference models would be available. Starting point for capturing requirements would be
legacy systems if they exist. The existing documents explaining the existing business processes
may also provide inputs to the requirement gathering phase. The team who is creating OO
model may also interview the business process owners (BPOs) for details. It is important to
make the BPOs feel comfortable during the interviews. BPOs would open up and tell the details,
strong points, trouble spots and bottlenecks only if they do not feel intimidated, undermined or
threatened. The team consolidates information gathered from all sources. It remains a
challenge to filter out what is information and what is not; what is to be retained and what is to
be discarded.

The legends used in an OO model are shown in figures 6.9 and 6.10. There are classes or objects
(shown in Figure 6.9(a)) that have attributes (or data part) and methods. A class can be
specialized form of a general class (Figure 6.9(b)). The objects are related other through
associations (Figure 6.9(c1) and (c2)) that have multiplicity (Figure 6.9(d) that defines the
number of instances that can relate. A relationship or association may itself have attributes
(refer to Figure 6.9(c3)). A class may request another class to perform functions (refer to Figure
6.9 (e1) and (e2)).

There are some guidelines that one can follow during modelling. One should start with the set
of nouns that have been mentioned during interviews and found in the legacy systems. Out of
the nouns with similar meanings, retain the one which is most general and descriptive. For
example, out of client, buyer, receiver and payer, retain client as other words explain the role
played by the client. The nouns which are out of the scope and irrelevant, are also deleted. The
nouns that do not convey specific meaning and are vaguely defined should also be deleted.
Nouns that describe individual objects and whose independent existence is not required are
attributes that belong to an entity and not entities. For example, weight, price and colour are all
attributes of an entity item. The verbs or actions are the methods or relationships. A verb that
describes a relation between two classes is an association. Any dependency between two or
more classes is also an association. A reference from one class to another is an association as
well. Associations correspond to stative verbs, and verb phrases such as next to, part of,
contained in, drives, talks to, has, supplies, works for and manages. An association should
describe a structural property of the application domain, not a transient event.

Associations between entities provide path for data sharing and collaborations. Ask questions
that should be answered by the model to make sure that there are enough entities, attributes
and associations to answer your questions. If multiple paths exist between classes, eliminate
the redundant ones. For a detailed description of OO modelling, refer to Rumbaugh et
al.7 Figures 6.10 and 6.11shows OO model and collaboration model for the processes shown
in Figure 6.4. There are six data items namely customer data, sales order data, purchase order
data, vendor data, material data and accounts in Figure 6.4. The corresponding OO model has
the same classes. With each class, we have methods/functions associated that cover all
functions shown in the Figure 6.4. OO model provides a different view than EPC model. These
two complement each other nicely. We can also create a collaboration model as shown
in Figure 6.11 to capture the interaction among classes.

FIGURE 6.9 OO Legends

FIGURE 6.10 Example of Data Model

FIGURE 6.11 Example of Collaboration Model

6.5 OBJECT PROCESS MODELLING

Object process modelling (OPM) captures data and processes/functions without worrying about
the sequence in which processes are invoked. Basic building blocks of OPM 8 are entities that
represent processes and objects. Relationships between entities are represented by links that
are either structural or procedural. The entities can be high level or abstract and an entity can
be detailed in another OPM creating a top-down representation of the requirements.

OPM legends are shown in Figure 6.12. In OPM, a process is represented as an oval and an
object as a rectangle (Figure 6.12(a) and (b)). An object may be linked with another object or
process with a link of one of the following types:
  If many instances of an object form another object, they are linked by an aggregation
link (shown inFigure 6.12(c)).

FIGURE 6.12 OPM Legends

 Two objects may have a generalization–specialization relationship. An item object is a

generalization of a non-inventory items and inventory items (shown in Figure
6.12(d)).
 Two objects may have structural relationship. For instance, inventory by location and
warehouse have a structural relationship (shown in Figure 6.12(e)).
 An entity may play an instrumental role for another entity. That is, if a process
requires an entity to execute, then the process and entity will be linked with an
instrument link (shown in Figure 6.12(f)).
 If a process modifies an object, the relationship is shown as an effect link (shown
in Figure 6.12(e)).

An example OPM to handle sales order is shown in Figure 6.13. OPMs can be created at
different levels of abstraction to get the desired level of details. There are some other
components of OPM which are not included in the description. For a detailed treatment of
OPM refer to Sturm, Dori and Shehory.

6.6 DATA ACTIVITY MODEL FOR CONFIGURATION

A configurable data model created to align the organizational structure to an ERP organizational
structure forms the basis of Data Activity Model for Configuration (DAMC). The techniques
which are described so far, focus on capturing the business requirements so that a suitable ERP
solution can be selected. Assumption is that the information required during configuration
phase is captured during RE phase. This assumption is not correct. During RE phase, the focus is
on business requirements whereas the focus shifts to ERP software during configuration. The
RE modelling techniques are process modelling techniques which emphasize on functions,
processes, their interactions and required data. Configuration involves defining a business
process in terms of data, their interrelationships and interactions to accomplish a task. The
process modelling techniques used in RE phase may capture data elements but they fail to
show their interactions and interrelationships. DAMC is suitable for capturing configuration
specific requirements for ERP system.
FIGURE 6.13 OPM to Handle Sales Order

The following information about data and processes is significant for configuration: 12, 13

 Information regarding processes, functions, control flow and data is required for
configuration. Process should be defined in terms of its functionality and control flow.
 While configuring an ERP system, many decisions about alternative functions, tables
and parameters have to be made. Configuration reference models should be able to
capture these decisions. The decisions can either be mandatory or optional in nature.
Some configuration decisions are critical while others are non-critical. Critical
decisions have significant impact on the business processes. The decisions should be
differentiated between critical and non-critical decisions.
 There should be a logical sequence to take decisions for configuration. A decision may
include processes and data objects. The logical sequence is through interrelationships
within one process model, between one or more process models or between process
and data models.
 ERP-specific configuration details may also be required. For instance, SAP
configuration is done through its IMG. Such information may provide valuable
information to the configuration team.
 Reference data models are important for configuration. ER diagram or its variants are
used for data models. We need to distinguish between optional entities and required
entities. An entity is connected to another entity through a relationship. A
relationship may be optional. Distinction between mandatory and optional
relationship is required.

In addition, following information is also important:

 Distinction between persistent (master) and transactional data is important.

Transactional data is created when a transaction is executed after a successful
configuration. It is master data that is used for configuration.
 Representation of business rules: Business processes have integrity and activity rules.
Activity rules prescribe actions or operation sequences which are to be performed
 and incorporated in any process and/or information constraint that is required for an
activity. Activity rules can either be structural or operational in nature. The type of
relationships and cardinality constraints define structural rules. Cardinality expresses
maximum number of entities that can be associated with another through a
relationship.17 Operational rules define pre-condition/s and post-condition/s for an
activity. A precondition is a constraint that specifies what must be true before an
activity is performed. Post-condition is a constraint that is true after an activity is
accomplished.18 During configuration, there is a need to know the business rules
associated with an activity as well as the type and cardinalities of relationships among
participating entities. Thus, structural and pre-condition activity rules are required
while modelling.

DAMC has notations to represent entity, its attributes and relationship type between entities
along with representing pre-condition and structural business rules. An entity represents data.
Data can be either master data or transactional data. A rectangle denotes an entity
representing master data, whereas a double rectangle denotes an entity representing
transactional data. An entity has attributes. An ellipse represents an attribute. A relationship
connects entities and can either be mandatory or optional in nature. It represents an activity
and has a unique name. A solid line represents a mandatory relationship whereas a dotted line
denotes an optional relationship. The entities participating in an optional relationship may
themselves be optional. In other words, one may not depict entities participating in an optional
relationship. A required (mandatory) entity is represented with an r and an optional entity is
depicted with an o written in the corner of an entity representing master data. One-to-one,
one-to-many and many-to-many cardinality constraints depict structural rules. Precondition
rules check availability of external or transactional data and output of an activity/relationship.
Conditions/constraints associated with a relationship represent precondition business rule
within curly brackets just below the name of a relationship. Figure 6.14 summarizes the
notations of DAMC.

Figure 6.15 shows a simple DAMC containing A and B entities that participate in the
relationship T1 and has precondition: C1 to be true. These entities represent master data.
Activity T1 creates transactional data that is stored in an entity M. T2 is an optional relationship
between entities B and Cthat represent master data. T2 has precondition C2 associated with it.
For the optional activity T2, entity B is required entity whereas entity C is optional. Activity T3
reads entity A if precondition C3 is true. A1 and A2 are the attributes of entity A.

DAMC for creating a sales order activity is shown in Figure 6.16. A sales order consists of the
customer details, and the material details that are fetched from persistent entities customer
and material. The sales orders are stored in a transactional entity sales order. A sales order is
created if either a quotation or a purchase order is available.

Credit of a customer may be verified under any of the following conditions. For one time sales
order,credit of a customer is verified (using verify credit status) whereas for recurrent sales
orders, this is an optional activity. Similarly, if a customer is a one time customer then his credit
limit may be verified but for regular customers it may be an optional activity. Discount may be
associated with a customerand material depending upon the discount strategy and/or
customer type and discount strategy and/or material type, respectively. For this optional
relationship, entity customer is required whereas the entity discount is optional. Tax may be
associated with material depending upon its type and/or taxation strategy. Compute discount
and compute tax relationship between entities discount-pricing and tax-pricing is optional and
depend upon discount status and tax status, respectively. The pricing procedure determines
pricing of the material that uses entity pricing and material. Pricing uses entity discount and
entity tax. More details of DAMC may be found in Negi and Bansal.19

FIGURE 6.14 DAMC Legends

FIGURE 6.15 Small Example of DAMC

FIGURE 6.16 Sales Order Processes in DAMC

CONCLUSION

The objective of this chapter has been to understand the RE phase of ERP project. The various
ways of documenting requirements are learnt. One of the ways of documenting requirements is
to use structured English. Small organization would generally use structured English for
documenting their requirements. There are many formal ways of documenting the
requirements. Event Process Chains by SAP, Object Process Model, object-oriented
modelling and Data Activity Model for Configuration (DAMC) are the ones which are discussed.
There are many more modelling techniques which have not been discussed. The aim is to
capture the requirements in sufficient details so that an appropriate ERP system can be
selected.