Journal of Physics: Conference Series

PAPER • OPEN ACCESS

Guidelines for defining user requirement specifications (URS) of

manufacturing execution system (MES) based on ISA-95 standard
To cite this article: Lei Yue et al 2019 J. Phys.: Conf. Ser. 1168 032065

View the article online for updates and enhancements.

This content was downloaded from IP address 158.46.212.183 on 12/03/2019 at 12:26

CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

Guidelines for defining user requirement specifications (URS)

of manufacturing execution system (MES) based on ISA-95
standard

Lei Yue1*, Pengfei Niu1 and Yan Wang2

1
Industrial Software Laboratory, Sensor and Network Control Centre, Instrumentation
Technology and Economy Institute, Beijing 100055, China
2
Beijing Chieftain Control Engineering Technology Co., Ltd., Beijing 102600, China
*
Lei Yue’s e-mail: yuelein@126.com

Abstract. To standardize the authoring of user requirement specifications (URS)for

manufacturing execution system (MES) proposed by manufacturing enterprises from users’
perspectives, and facilitate a quick and effective communication between them and M E
S
vendor or integrator, an approach for URS definition was introduced based on the ISA-95standard,
in which a method for requirement elicitation based on goal and scenario wascombined. In
this approach, a framework for MES problem space was constructed first from three
dimensions: generic activity model for manufacturing operations management (MOM),
manufacturing operations categories and supporting activities, and then a series of guidelines
for standard application, scenario authoring and requirement arrangement were established to
guide the users in seeking the needs and writing them in a normalized sentence form step by
step. Additionally, a structure of the table of content for URS documentation was
recommended to help the users organizing the textual requirement description. Finally, a case
study for applying this approach was performed in a pharmaceutical company’s example,
which illustrates the application prospect in MES product selection.

1. Introduction
The so-called “stakeholder needs and requirements definition process” defined in the ISO/IEC/IEEE
15288 standard[1] is an important technical process in software and IT projects, and it differs from the
"system requirements definition process" that we are usually familiar with. The former puts forward
the expectations for the target software system from user’s perspectives in terms of function,
behaviour, performance, constraints, etc., and translates them into clear requirements definition in
form of documented user requirement specifications (URS) as the outcome. While, the URS, as the
input of the latter, is then responded by the system integrators and software vendors. Consequently, the
functions and features of the target software system can be obtained on basis of the To-Be analysis of
user requirements, as a result, the documented functional specifications (FS) are formed.
Along with the implementation of the “Made in China 2025” strategy and industrial upgrading brought
about by smart manufacturing, more and more Chinese manufacturing enterprises have beenimporting
the manufacturing execution system (MES) as an instrument supporting the manufacturing operations
management (MOM). However, many MES implementation projects have stalled or failed during the
“stakeholder needs and requirements definition process” and “system requirements definition process”,
because the users cannot express their needs accurately or provide an

Content from this work may be used under the terms of the Creative Commons Attribution 3.0 licence. Any further distributionof
this work must maintain attribution to the author(s) and the title of the work, journal citation and DOI.
Published under licence by IOP Publishing Ltd 1
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

unambiguous URS document, and the system integrator and software vendors cannot understand the
users’ demands well. It was shown in the research of Standish Group[2] that one of the reasons why a
number of software and IT projects were cancelled or did not achieve the originally goals was
inadequate requirements engineering. Most of the cancelled projects were due to lack of clear
requirements and well-controlled changes.
In manufacturing enterprise, the activities performed in shop floor encompasses many management
functionalities, addressing several types of manufacturing operations from the receipt of raw material to
the shipping of finished goods, from production operations to equipment maintenance, and from
inventory movements to quality tests[3]. These activities must operate collaboratively under the
business management procedures in spite of their different responsibilities. Therefore, it will be an
arduous task for the manufacturer to specify the URS for such a MES with global collaborative
functions.
There are twofold factors which may lead to risks if are not taken seriously. Firstly, the potential
system users from different departments have different understandings of MES, and it is difficult to
reach a consensus. Some users focus on the standard operation procedure (SOP) enforcement and data
collection from the manufacturing perspective, and consider these as the main functions of MES to be
implemented. Some other users, on the other hand, pay more attention to the actual performance of the
operations management and control in shop floor from the business management perspective.
The division of these two opinions mainly due to the following two aspects:
 Manufacturing processes involve the utilization of resources, execution of processes andtransfer
of the products, as well as business management and operations. They are actualy two facets of the
same thing.
 The user group formed on behalf of information technology (IT) and business management are
difficult to understand the production control constraints, so they may hardly understand the
requirements proposed by the user group formed on behalf of work execution. Likewise, the
latter are also difficult to understand the former’s thoughts and visions standing on theposition
of them.
Consequently, the issue of partitioning functionalities and responsibilities arose. This make it very
difficult to build a clearly defined URS, and the evaluation process of MES solutions has becomeextremely
challenging. Furthermore, high requirements have been put forward for the comprehensive skills and
practical experience of personnel.
Secondly, the first step of advancing a MES project is to specify the requirements that the systemneeds
to meet. Obviously, the well-defined requirements have been the cornerstone for everything that
followed. For example, in a pharmaceutical company, the URS will be undoubtedly put in the initial
position of the GAMP cycle, in which there are two verification activities linking system acceptance test
(SAT) to URS and SAT to functional specification (FS). Additionally, there is a mapping between URS
and FS. The quality management of a MES project must ensure that each function in FS canbemapped
to the relevant item in URS and serves as the evidence for SAT.
In summary, the characteristics of MES and special status of URS in project quality management
jointly determine that it is not easy to define a qualified URS for MES. However, defining requirements
precisely is the key factor for the successful implementation of an efficient and practical MES. The aim
of this paper is therefore to propose a practical, normative and operable approach toeliciting and
authoring requirements for MES hoping to guide the manufacturer towards their standard URS
documents. In a first step, the approach to requirements elicitation for MES will be introduced through
reviewing the previous relevant studies (section 2). The results from section 3 provide a set ofguidelines
for applying ISA-95 standard to eliciting and authoring requirements for MES, as well as some
interpretations for these guidelines will be given. In section 4, a case study for a pharmaceutical
company’s example will be illustrated and the topic of MES product selection will be discussed briefly.
Finally, a conclusion on this study will complete this article (section 5).

2
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

2. Basis of requirements definition for manufacturing execution system

One of the purposes of URS is to provide integrators and software vendors with as much detailed
information on the enterprise as possible, as well as expectations and requirements for MES, but what
exactly the integrators and software vendor need to know before offering the proposal is often vagueto
many enterprise users who are about to import MES. The best practices of MES implementation showed
that the ISA-95 standard entitled Enterprise-Control system integration can be used as a guiding
principle for developing URS[4]. This standard clarified the boundaries between the systems in office
floor and shop floor, and the upper limit range of functions that a MES may cover.

2.1 Constructing problem space based on ISA-95 standard

A number of literatures that referenced to, elaborated, utilized and enriched the ISA-95 standard have
been published. Some software vendors examined in a vendor’s perspective how the ISA-95 standard can
be used to develop a MES product that can address both the MOM domain and its integration withthe
business domain, meanwhile, some of the benefits recognized when applying ISA-95 standard to a
product were listed[5]. Some other software vendors proposed extensions for ISA-95 standard to
support fully both longer term and dynamic scheduling[6]. There are also some vendors focused on a
partial domain of MOM and considered the activities as well as information flow between them in
detail for developing some dedicated software tools[7], such as plant performance analysis (PPA),
statistical process control (SPC), and so on. Additionally, a neutral institution has conducted a
survey[8] in various MES products provided by global vendors on the market using questionnaires, in
which the ISA-95 standard was considered as one of important criterion for product evaluation.
The relationship between the MES application components and the ISA-95 standard as well as
relationship between MES and MOM was discussed by reference [9]. It is revealed that “the standard-
defined terms, models and methods contribute to large extent to the effectiveness of work shop level
analysis for production management, as well as to the development of decision support functions
implemented in the MES applications”.

2.1.1 Generic activity model of manufacturing operations management.

The third part of ISA-95 standard has defined a generic activity model[10] and summarized al
operative activities to be carried out at manufacturing operations management (MOM) level. It is able
to assist users in understanding how their workshops operate in daily production management within
twofold aspects: business management and work execution. The aforementioned two divided user
groups can be therefore harmonized.
Figure 1 illustrates the generic activity model for MOM, in which, the activities can be considered
according to the time they occur relatively to the moment of the work execution[11]. Figure 2 showshow
this time view applies to the generic activity model.
The types of activities that differ in time include time-independent reference data, as well as pre-work,
actual work, and post-work, which are time-dependent and executed in sequence. Reference data refers to
data that is used to categorize other data within enterprise applications and databases, and it is distinct
from master data that represent business entities, transactional data produced bytransactions within
applications, as well as meta data which describes the structure of business entities[12]. Reference
data is provided by the professional standards organization. The object models of resources (such as
material, personnel, equipment, physical asset, process segment) and operations from ISA-95 standard
determine the reference data for MES.

3
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

Operation Operation Operation Operation

defini tion capabilit y schedule performance

Detailed
scheduli ng

Resource Tracking
management

Dispatching Analysis

Definit ion Data

management collecti on

Process-specific Execution Process-specific

rules data

command response

Figure 1. Generic activity model of manufacturing operations management.

Pre-Work
Detailed
scheduling
Post-Work
Reference d
t
a Tracking
Resource
management Dispatching Analysis

Definition
management Actual Work
Data
collection

Execution

Figure 2. Temporal view of generic activity model[11].

The interactions between these activities are roughly described as follows: (1) the pre-work contains
detailed scheduling activity and dispatching activity. Detailed scheduling activity takes theoperation
schedules as input information, solves work arrangements under the constraints of reference data and
produces work schedules as output; (2) the arranged work schedules are then assigned to specific
resources through dispatching activity, forming a work dispatch list comprising various job orders
with semi-finished goods, finished goods, and services as outputs in a certain time span; (3) after
receiving the job orders, the equipment and personnel on the workstation start performing
specific tasks following SOPs or instructions. During the execution process, personnel send commands
to equipment or some control system, and receive responses from them. In this way, personnel and
equipment cooperate with each other to complete jobs. The information flow between pre-work and
actual work is shown in Figure 3.

4
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

product or operation

A Operation
B schedule
C
D
E
Detailed
scheduling
time
Work
work center schedule

transactional
Dispatching data

Work
time dispatch list
work instruction
job order dispatch list Work
instruction
work center workflow step Execution

Command Response
time
Figure 3. Information flow between pre-work and actual work (partly).

2.1.2 Determining system boundaries

According to the characteristics of value added to products and services by these activities, ISA-95
standard classified them into five distinct but similar categories: production, maintenance, quality test,
inventory movement and support activities. Four operations management categories can be therefore
derived from the MOM generic activity model, which are production operations management, maintenance
operations management, quality operations management and inventory operationsmanagement.
Generally speaking, most of MES instances support these four categories of operationsmanagement,
but the functional scope is different. So an example of the boundary between MES and enterprise
resource planning (ERP) system was given in the annex of ISA-95 standard Part 3 toexplain how
activity models can be used to determine the functional scope of MES.
One thing to note is that responsibilities boundary may not match with technical boundary in
system integration, that is, the system boundary is to a certain extent independent to the
responsibilities of departments, but is dependent on what activities within MOM may be supported by
MES. So the boundaries among different information system may vary depending on industry or plant.

2.1.3 Establishing domain framework for manufacturing execution system

In addition to above four types of operations management categories (called core activities), there isalso
a collection of supporting activities according to ISA-95 standard Part 3, including management of
information, management of security, management of documentation, management of configuration,
management of compliance and management of incidents and deviations. The supporting activities ensures
each of the core activities shall be performed in the right way, and may therefore haveinfluences
on MES to be implemented.
The generic activity model, four types of core activities and supporting activities constitute three
dimensions of a problem space of MES, in other words, they represent different aspects of the problem

5
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

space, and each functional requirement proposed to MES can be expressed from these threedimensions.
So a problem space framework for requirement engineering of MES is obtained, as shownin Figure 4.

MOM categories：
- production
- maintenance
Generic activity model：
- quality test
Supporting activities： - detailed scheduling
- inventory movement
- management of information - dispatching
- management of configuration - execution
- management of security Problem space of MES - data collection
- management of incidents and deviations - tracking
- management of documentation - analysis
- management of compliance - definition management
- resource management

Figure 4. Problem space framework for MES.

2.2 Defining requirements using scenarios

Requirement definition language is a language used to write software requirements definition, whichcan
be divided into three classes: non-formal language (also known as natural language), semi-formal
language and formal language[13-16] according to their degree of formalization[17]. The formallanguage
establish rules for grammar mathematically, and have clear semantics used to supportautomatic elicitation
and analysis of requirements. At present, however, this method is hardly directly used to define
requirements of information system in practice, because it not only needs software tools to provide
support for requirements analysis, but also poses high challenges to mathematical literacy of users and
system analysts.
In contrast, non-formal language employing natural language is much easier to be accepted by the
general users, because of its characteristics of comprehensibility and usability, which howeveroppositely
result in a disadvantage of ambiguity.

2.2.1 Semi-formal methods for requirements definition

In view of feasibility and operability, it is necessary to preserve the advantages of natural language. nI
this context, the improvement of non-formal requirement definition language is to make the natural
language as accurate as possible in terms of presentation. On the basis, the ambiguity can be
eliminated with the help of effective communication. It is the semi-formal requirement definition
language that was adopted in this study.
In the early years of requirement engineering, a linguistics-based method of requirement elicitation
has been proposed, in which the disadvantages of non-formal requirement definition language have
been avoided by means of normalized and formatted sentences. Colette Rolland[18-20] initiatively
proposed modelling a goal using scenarios which in fact comprises use cases, then authoring the
scenarios with formatted sentences. A two-tuple of goals and scenarios <G, Sc> uniquely defines a so-
called requirement chunk.
The main advantage of using formatted sentences to author scenarios is that ambiguity of natural
language can be eliminated to some extent, as well as the characteristics of comprehensibility and
usability can be reserved.

2.2.2 Methodology system of defining URS for MES

The requirement elicitation work often start with As-Is/To-Be analysis. On the basis of analysis on the
current situation of business management and execution management, users or system analysts needot

6
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

plan how the MES functions should support business management and execution management in
future. This analysis process will produce a set of goals for future MES functions to achieve.
The framework methodology we have used to develop our methodology framework is based on
Colette Rolland’s guidelines system and the practice of reference [21]. Figure 5 illustrates the
methodology framework established in this article, in which the grey rectangles represent what are
discussed in detail. It provides an overall procedure for defining URS for MES. The MES problem
space can help users to consider the scope of MES functions thoroughly. Guidelines system can direct
iterative reasoning with <G, Sc> through discovering goals and refining scenarios. The URS document
structure helps to consolidate the requirements into a unified URS documents.

MES problem space (As-Is) G: goal

Supporti ng MOM Generic Sc: scenario
activities categories acti vity Goals + Scenarios (To-Be)
—— ———— model < G, Sc >
—— ———— ———— URS document
—— ———— ————
 --------
 ------
URS  --------
 ---- --
transformation  ------
 ------
 --------
 --------
Guidelines system  ----
 ---- --
URS
document structure

Figure 5. Methodology framework of defining URS for MES.

3. Guidelines for defining URS of manufacturing execution system

3.1 Guidelines system

The guidelines were divided into three collections depending on the role they play in defining URS,
which are ISA-95 standard application guidelines, scenario authoring guidelines and requirements sorting
guidelines. In this section, we first present a work flow of defining URS in Figure 6 in general,then each
guideline will be presented in subsections in form of <caption, definition, notes> followed by examples if
needed.
ISA-95 application
Preparation guidelines

Collecting Critical success

reference data factors (CSFs)
Describing current
business process Scenarios authoring
guidelines
As-Is/To-Be
analysis
Requirements
To-Be scenarios sorting guidelines
authoring

Sorting URS document

requirements
Figure 6. General work flow of defining URS.

3.1.1 Guidelines for applying ISA-95 standard

Guideline 1: Operation classification
Definition: Operations are divided into production, maintenance, quality test and inventorymovement,
depending on the characteristics of value added to products and services by the activities involved in
operations.

7
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

Notes:
The different added value are as follows:
 Production leads directly to a series of physical and chemical changes on the raw materials and
transfer them into desired final tangible products.
 Maintenance delivers intangible services to keep the equipment and physical assets in normal
state all the time, or restore them to normal state when they malfunction.
 Quality test delivers intangible services to judge whether the raw materials, work-in-process
(WIP) and products are qualified or not with inspection tools through comparing the results with
specification requirement, sometimes including verifying qualification of equipment.
 Inventory movement delivers intangible services to load, unload, handle, store and move the
raw materials, WIPs and products, excluding the movement related to production. □
Guideline 2: Reference data collecting
Definition: On the basis of operation classification, collect reference data of plant resources
corresponding to four types of operations within the framework of “object model” defined in ISA-95
standard Part 2.
Notes:
Plant resources can include various personnel, materials, equipment, physical assets and process
segments used in four types of operations. Reference data about these resources as well as the
“operation definition” should be organized in accordance with the structure of “object model”.
Operation definition is a generic term of product production rules, maintenance rules, quality test rules
and inventory movement rules. In practice, information on operation definition can be found in various
kinds of technical data and work instructions, such as process specification, inspection procedure, etc.
□
Guideline 3: Business process depiction
Definition: On the basis of operation classification, depict the as-is activities and information flow
between them in detail with distinguishing operation category.
Notes:
A business process consist of various activities orchestrated in a certain sequence, and can bedepicted
in a combined manner of flowchart presented by for example BPMN (Business Process Modeling
Notation)[22] and textual form. □
Guideline 4: Requirement discovery
Definition: From the as-is situations of business process, perform to-be study on the as-is situations
using business drivers, and the improved business process shall be obtained. Determine if the activity
involved in improved business process needs the MES function support, if needed, define a functional
requirement for this activity.
Notes:
(1) Determining the relevance of an activity to the MES function can be done by answering the
following questions:
 Whether performing the activity requires a MES function support?
 Will data processing be required to be done by a MES function, during the acting of the
activity?
 Will data exchanging with external systems be involved, during the acting of activity?
(2) Some examples of business drivers include reduced cycle time, asset efficiency, agile
manufacturing, supply chain optimization, traceability, compliance and so on. □
Guideline 5: Goals and scenarios introduction
Definition: For each functional requirement, elicit the elements including goals, actors, trigger
conditions, operation steps from every activity involved in it.
Notes:
(1) An activity always intends to meet some default goals which can be elicited by answering the
following questions:
 What changes happened to data after the activity was performed?

8
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

 What results were produced after the activity was performed?

 How the activity will be improved and optimized after importing a MES function?
(2) The actors of an activity may be personnel of certain roles, departments, units within
organizations, or a information system, and can be elicited by answering the following questions:
 Who participate in the performance of the activity, personnel or information system?
(3) The trigger conditions, which determine when an activity is performed, are typically divided into
three classes: by messages, by time and following the predecessors. This elements can be elicited by
answering the following questions:
 How are the actors informed of performing an activity?
 If the actors are informed by messages, then what kind of messages are sent to them and howthey
receive the messages?
 If the activity is performed depending on a time schedule, then how the actors are informed?
 If the activity is performed following the predecessor, then whether the end of preceding activities
will be responded or not, if not, how the actors are informed of this activity?
(4) An activity is usually composed of several procedural operation steps. This element canbe
elicited by answering the following questions:
 What operation steps are involved in an activity?
 Who perform these operation steps?
 What equipment and physical assets will be used in the operation steps?
 How will these equipment and physical assets be used in performing the activity?
 Are validations needed in operation steps? □

3.1.2 Guidelines for authoring scenarios

Guideline 6: Well-formed formula
Definition: All the textual statements on scenarios should be authored with the following sentence
pattern:
Subject: Agent + Verb + Target: Object + Direction: (Source, Destination) + Way: (MeansManner).
,
Notes:
(1) In principle, one textual scenario statement should contain only one action that represents one
operation step.
(2) Target, direction and way are summarized in a generic term called parameter element.
(3) The elements that constitute a scenario are similar with the elements of a sentence. A scenario will
be associated with one subject, one verb and three types of parameters which qualify the verb in
different ways.
(4) These elements of a sentence ensure that information needed to describe a scenario aresufficient to
support subsequent work of goals refinement and facilitate an accurate common understanding.
(5) User should endeavor to keep scenario descriptions complete when authoring scenarios.
(6) It is noticed that the elements of a sentence are not equal to grammatical items.
(7) More details may reference to literature [18].
Example: Table 1 shows some samples and explains each element in this well-formed formula, in
which the element samples are indicated in bold. □
Guideline 7: Alternative refinement
Definition: If there are multiple options for the parameter element of the sentence, and these options are
mutually independent and exclusive, then it is necessary to declare the truth-value conditions of each
alternative branch. Introduce sub-goals and corresponding scenario descriptions for each branch
according to “Goals and scenarios introduction guideline”, forming OR relationships between these sub-
goals.
Notes:

9
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

The “Goals and scenarios introduction guideline” and “Alternative refinement guideline” will be
together applied to an iterative reasoning process. □
Table 1. Meanings and samples of some elements of sentence pattern.
Element Label in subscript Meaning in this study Sample
An active entity that initiates na
(Operator)Agent scans the barcode of material with
action for a purpose, a system or a
Agent Agent the scanner, and inputs the lot number of raw
participant can be treated as an
material into the system.
agent
Operator (scans)Verb the barcode of material with
Verb Verb predicate that denotes an action the scanner, and (inputs) Verb the lot number ofraw
materials into the system.
data or information that are Operator scans the barcode of material with the
Object Obj directly affected or imposed bythe scanner, and inputs the (lot number of raw
action, materials)Obj into the system.
Operator obtains detail information about raw
Source So the origin of information flow
materials from (the system)So
Operator scans the barcode of material with the
Destinati
Dest the end of information flow scanner, and inputs the lot number of raw
on
materials into (the system)Dest.
equipment, tools used to achieve Operator scans the barcode of material (with the
Means Mea scanner)Mea, and inputs the lot number of raw
the goal
materials into the system.
Operator inputs the lot number of raw materials into
methods, approach used to
Manner Man the system (by means of scanning the barcode
achieve the goal
(with the scanner)Mea)Man
Guideline 8: Composition refinement
Definition: If there are multiple options for the parameter element of the sentence, and these options are
mutually complementary, then introduce sub-goals and corresponding scenario descriptions for each
branch according to “Goals and scenarios introduction guideline”, forming ANDrelationships between
these sub-goals.
Notes:
The “Goals and scenarios introduction guideline” and “Composition refinement guideline” will be
together applied to an iterative reasoning process. □

3.1.3 Guidelines for sorting requirements

Guideline 9: Requirement filtration
Definition: Identify the repetitive and conflicting requirements involved in textual scenario
descriptions and eliminate them.
Notes:
(1) The requirements elicited from people of multiple roles and departments may be repetitive or
mutually conflicting especially for a large-scale MES project. It is therefore needed to eliminate themfor
ensuring a correct subsequent work of functional design.
(2) The following tips can help identifying the potential conflicts:
 Conflicts are more likely to be found in the requirements for the same functionality.
 There may be conflicts between the functionality and input/output of it if they are elicitedfrom
different people.
 Due to differences in work experiences and positions, there may be conflicts between the
requirements presented respectively by the person and his/her superior. □
Guideline 10: Priority determination
Definition: The priority level should be determined for each filtered requirement to be
implemented.
Notes:
It can be evaluated from the following aspects:

10
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

 Dominant requirements first implemented ─ some functionalities must be implemented fistwhile

,
others can be implemented.
 Most associated requirements first implemented ─ the functionalities that are most associatedto
others should be implemented first.
 Most benefited requirements first implemented ─ the functionalities that may bring about
most benefits to enterprises should be implemented first. □

3.2 Recommended document structure for URS

Each statement on requirement for MES is elicited through comprehensive application of ISA-95standard
application guidelines, scenario authoring guidelines and requirements sorting guidelines, and is
presented as a scenario in the context of a certain MOM category. The problem space framework of
MES can be therefore used to document URS naturally. In this section, the main elements of table of
contents for MES User Requirement Specifications are listed in Table 2 on the basis of previous best
practices[23].
Table 2. Main elements of table of contents for MES User Requirement Specifications (partly).
Chapte
Chapter Heading Chapter Chapter Heading
r
0 Introduction 4.8 Maintenance performance analysis
0.1 Scope of this URS document 5 Quality operations management
0.2 Normative references 5.1 Quality definition management
0.3 Document structure 5.2 Quality resource management
1 Basic description of the enterprise 5.3 Detailed quality scheduling
1.1 General 5.4 Quality dispatching
1.2 Organizational structure 5.5 Quality execution management
1.3 Physical hierarchy 5.6 Quality data collection
1.4 Process segments 5.7 Quality tracking
Current application architecture and
1.5 5.8 Quality performance analysis
infrastructure
2 Business drivers 6 Inventory operations management
3 Production Operations Management 6.1 Inventory definition management
3.1 Product definition management 6.2 Inventory resource management
3.2 Production resource management 6.3 Detailed inventory scheduling
3.3 Detailed production scheduling 6.4 Inventory dispatching
3.4 Production dispatching 6.5 Inventory execution management
3.5 Production execution management 6.6 Inventory data collection
3.6 Production data collection 6.7 Inventory tracking
3.7 Production tracking 6.8 Inventory performance analysis
3.8 Production performance analysis 7 Supporting functionalities
4 Management of information (storage, backup,
Maintenance operations management 7.1
recovery, redundancy, archiving, etc.)
4.1 Management of documentation (technical data,
Maintenance definition management 7.2
records)
4.2 Management of security (authorization, access
Maintenance resource management 7.3
right, password)
4.3 Management of compliance (GMP, 21 CFR Part
Detailed maintenance scheduling 7.4
11)
4.4 Management of configuration (change
Maintenance dispatching 7.5
management, versioning, audit trails)
Management of incidents and deviations
4.5 Maintenance execution scheduling 7.6
(recording of alarms and deviations)
4.6 Maintenance data collection 8 Interfaces with external systems
interfaces with ERP, PDM, LIMS, WMS,
4.7 Maintenance tracking 8.1 Computerized Maintenance Management
Systems (CMMS) and control system

Limited to space, only headings of level 1 and level 2 are listed in Table 2, chapters 3, 4, 5, 6 and7
should be detailed into headings of level 3 to describe the as-is situations and to-be scenarios.

11
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

Additionally, the requirements on other aspects of MES should also be described in the URS, such as
database, response speed, graphical user interface (GUI), scalability, deployment mode (C/S, B/S), etc.
Finally, an audit page should be inserted into the appropriate place of the URS document for signing and
approval.
As necessary, the terms and abbreviations used in the URS document should be listed in theappendix,
together with samples of the bill of materials (BOM), process flow charts, work records (or batch
production records), work schedules, etc.
It is necessary to state that the recommended table of contents for URS document is based on the
maximum scope of a project. The requirements outside the scope of project need to be removed fromthe
actual URS document after the scope of project is determined.

4. Case study and discussion

The methodology proposed in this paper has been applied to a pharmaceutical company denoted by
“A”. It is turned out that the URS document defined by this methodology can make the
communications between users and system integrators easier and more efficient. The effects are
particularly obvious especially for the internationally known MES product vendors, because most of
these vendors are able to provide MES platforms that are compliance with the ISA-95 standard,
so that , the functions provided by the MES product can be corresponded well with the
requirements listed in the URS document. Thus, URS defined in this way is more suitable for MES
products survey and selection before importing MES applications.
Company “A” has selected a MES product on the market on the basis of URS. When selecting a
MES product, company “A” investigated the implementation approaches involved in solutions provided
by vendors for each requirement within URS, from various perspectives, such as which
requirements can be supported by the standard modules of MES products, which need to be
implemented in a customized way or by functional configuration, and so on. Figure 7 illustrates the
practices of selecting the MES products, which have been done by company “A”.
Production Quality
operations operations Inventory operations
management management
management

Functional requirements
refinement

G1 Sc1
And
G2 Sc2 Users
Or
Gn Scn

URS
MES application
components
Solutions

Standard Customized Functional Standard

modules development configuration interfaces

Figure 7. Practices of MES products selection based on URS.

It is not easy to be “qualified” users for enterprises, because they need to obtain a clear
understanding of the production control activities and business planning activities that occur in their
own plants, before importing a manufacturing execution system. It is a great challenge for enterprises to
build a flexible and constantly evolving manufacturing execution system successfully. This goal can

12
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

be achieved only when the enterprises reach a high level of maturity and recognize the necessity of
continuous improvement.
The ISA-95 standard reconciles business management with execution management and harmonize
their visions. The whole standard, especially Part 3, can be regarded as a tutorial on understanding the
functionalities and information flow within manufacturing execution system, and has great reference
value for defining URS. It is hoped that more and more users can participate in requirement elicitation
process and make a good use of these guidelines when implementing a manufacturing execution system,
for facilitating an effective communication with system integrator and software vendors.

5. Conclusions
In this paper, the issues arose in the implementation of manufacturing execution system wer discussed
first, then the significance of URS in a manufacturing execution system implementation project was
highlighted. The problem space framework of manufacturing execution system wasconstructed from
three dimensions based on ISA-95 standard and contributions by members of ISA95standard committee.
All of the requirements for MES applications will emerge in the problem space. So the problem space
framework has laid a foundation for requirements elicitation. On the other hand, a semi-formal
requirement definition language was introduced mainly based on contributions by Colette Rolland.
The guidelines for defining URS of MES were also enumerated and justified one by one.
It can be stated that ─ as result of applying this methodology to a pharmaceutical company’s MES
project ─ the guidelines proposed by this paper have been proved to be effective on defining a
normative and clear URS, as well as selecting a suitable MES product on the market.
In the situation of smart manufacturing, the emerging information and communication technology
(ICT) should be paid more attentions to when implementing the manufacturing execution system on
one hand, and the ISA-95 standard will be updated and supplemented with models of operations
management events which can enable users to better identify their requirements for MES.

Acknowledgments
The authors wish to thank all the members of ISA95 for sharing information across the standardcommittee.
The support of the third author Yan Wang who is a consultant engaged in pharmaceutical process
validation is acknowledged.

References
[1] ISO, IEC & IEEE (2015). ISO/IEC/IEEE 15288-2015 Systems and software engineering —
system life cycle processes.
[2] Group, S. (2013). Chaos Manifesto 2013: Think Big, Act Small.
[3] Vieille, J. (2005) How to Use ISA-95 Part 3 for MES Functional User Requirements
Specifications. In: WILLIAM HAWKINS, D. B., WALT BOYES, ed. World Batch Forum
North American Conference, 2005 Atlantic City, New Jersey, USA. New York:
Momentum Press, LLC.
[4] Scholten, B. (2009). MES Guide for Executives: Why and How to Select, Implement, and
Maintain a Manufacturing Execution System, USA, ISA.
[5] Johnson, C. (2004). Applying ISA 95 – a vendor perspective. ISA EXPO 2004. Houston:ISA.
[6] Morrison, S. (2004). Extending SP95 Objects for Batch Scheduling. AUTOWEST 2004.USA:
ISA.
[7] Cawley, J., Gifford, C. & Grasley, M. (2004). ISA95 Production Performance Analysis onan
Integrated Quality Data Management and Reporting Platform. AUTOWEST 2004. USA:
ISA.
[8] CGI (2018). 2018 CGI MES Product Survey. USA: MESA International. Available:
https://www.cgi.com/en/manufacturing/mes-product-survey.

13
CISAT 2018 IOP Publishing
IOP Conf. Series: Journal of Physics: Conf. Series 1168 (2019) 032065 doi:10.1088/1742-6596/1168/3/032065

[9] Bikfalvi, P., Erdélyi, F., Kulcsár, G., Tóth, T. & Forrai, M. K. (2014). On some functionsofthe
MES applications supporting production operations management. In: BOGNáR, G. &
TóTH, T. (eds.) Applied Information Science, Engineering and Technology: Selected
Topics from the Field of Production Information Engineering and IT for Manufacturing:
Theory and Practice. Cham: Springer International Publishing.
[10] ANSI (2005). ANSI/ISA-95.00.03-2005 Enterprise-Control System Integration Part 3:
Activity Models of Manufacturing Operations Management.
[11] Vieille, J. (2006) Manufacturing Information Systems - ISA88/95 Based Functional Definition.
MESA International, USAMESA White Paper #22.
[12] Chen, W. J. Reference Data Management [Online]. USA: IBM Redbooks. Available:
http://www.redbooks.ibm.com/abstracts/tips1016.html [Accessed 07/09 2018].
[13] Jin, Z., Bell, D. & Wilkie, F. G. (1998) Automatically Acquiring the Requirements of
Business Information Systems by using Business Ontology. 1998 Brighton, UK:
Chapman and Hall Ltd, 62-75.
[14] Ruqian, L., Zhi, J. & Ronglin, W. (1995) Requirement specification in pseudo-natural language
in PROMIS. Proceedings Nineteenth Annual International Computer Software and
Applications Conference (COMPSAC'95), 9-11 Aug. 1995 1995. 96-101.
[15] Jiazhong, Z., Jian, L., Zhijian, W. & Jiafu, X. (1996). ON THE DESIGN O F A
GRAPHICAL OBJECT ORIENTED REQUIREMENTS DEFINITION LANGUAGE
(in Chinese). JOURNAL OF SOFTWARE, 7, 647-655.
[16] Dardenne, A., van Lamsweerde, A. & Fickas, S. (1993). Goal-directed requirements acquisition.
Science of Computer Programming, 20, 3-50.
[17] Unknown (2005). Requirements definition language. In: XIAOXIANG, Z. (ed.)Encyclopedia
of Computer Science and Technology. 2nd edition ed. Beijing: Tsinghua University Press.
[18] Rolland, C., Souveyet, C. & Achour, C. B. (1998). Guiding goal modeling using scenarios.
IEEE Transactions on Software Engineering, 24, 1055-1071.
[19] Rolland, C. & Achour, C. B. (1998). Guiding the construction of textual use case
specifications. Data & Knowledge Engineering, 25, 125-160.
[20] Rolland, C. & Salinesi, C. (2009). Supporting Requirements Elicitation throughGoal/Scenario
Coupling. In: BORGIDA, A. T., CHAUDHRI, V. K., GIORGINI, P. & YU, E. S. (eds.)
Conceptual Modeling: Foundations and Applications: Essays in Honor of John
Mylopoulos. Berlin, Heidelberg: Springer Berlin Heidelberg.
[21] Kim, J., Park, S. & Sugumaran, V. (2004) A Linguistics-Based Approach for Use Case
Driven Analysis Using Goal and Scenario Authoring. In: MEZIANE, F. & MéTAIS, E.,
eds. Natural Language Processing and Information Systems, 2004// 2004 Berlin,
Heidelberg. : Springer Berlin Heidelberg, 159-170.
[22] Prades, L., Romero, F., Estruch, A., García-Dominguez, A. & Serrano, J. (2013). Defining a
Methodology to Design and Implement Business Process Models in BPMN According to
the Standard ANSI/ISA-95 in a Manufacturing Enterprise. Procedia Engineering, 63,115-
122.
[23] Scholten, B. (2008) Best Practices for MES User Requirement Specifications. In:WILLIAM
HAWKINS, D. B., WALT BOYES, ed. 2008 WBF European Conference, 2008
Barcelona, Spain. New York: Momentum Press, LLC.

14