J. Software Engineering & Applications, 2009, 2:13-19
Published Online April 2009 in SciRes (www.SciRP.org/journal/jsea)
An Approach to Generation of Process-Oriented
Requirements Specification
Jingbai Tian1, Keqing He1, Chong Wang1, Huafeng Chen1
1State Key Lab of Software Engineering, Wuhan University, China
Received January 10th, 2009; revised February 21st, 2009; accepted March 19th, 2009.
ABSTRACT
In service-oriented computing, process model may serve as a link to connect users’ requirements with Web Services. In
this paper, we propose an approach and related key techniques to generate process-oriented requirements specification
from user’s goal. For this purpose, a requirements description language named SORL will be provided to capture us-
ers’ requirements. Then, a unified requirements meta-modeling frame RPGS will be used to construct reusable domain
assets, which is the basis of generating requirements specifications. Finally, a set of rules are defined to extract process
control structures from users’ requirements described with SORL, so that we can convert requirements description into
process-oriented requirements specification smoothly.
Keywords: Requirements Specification, Process Modeling, Process Control Stucture, Networked Software
1. Introduction
Service-oriented computing (SOC) [1] paradigm is
deemed as an active topic in recent years, because it pro-
vides a loosely coupled, highly interoperability and high
levels of reuse application architecture. As a typical kind
of SOC applications, networked software (NS) [2,3] is
born as a software system whose structure and behavior
can evolve dynamically. Following the idea of user-cen-
tric development, NS can satisfy users’ demands dy-
namically by composing web services distributed among
the network hosts.
When customizing personalized requirements of NS,
one of the key problems is to elicit users’ requirements
precisely. In the network environment, it is difficult for
users to describe their requirements correctly and com-
pletely. What’s more, users’ requirements are always with
preference and rapid change. Traditional requirements
elicitation methods collect initial requirements by memo
of interview transcripts, which is hard to capture rapid
changes of requirements in the network environment.
Moreover, Users usually describe requirements with im-
precise natural languages, and it’s difficult for them to
grasp formal or logical requirements description lan-
guages. Accordingly, a requirements description language
called Service-Oriented Requirements Language (SORL)
[4] was proposed in our previous works. It defined set of
natural language patterns to describe requirements and
supported online requirements elicitation.
In order to develop software rapidly, many previous
researches emphasize on using domain acknowledge to
support requirement assets reuse. In order to analyze and
satisfy users’ requirements in networked environment, we
proposed a domain requirements metamodelling frame-
work called RGPS (Goal-Role-Process-Service) [5]. It is
tended to model common requirements assets in a do-
main, including domain ontology and four types of do-
main models. Domain ontology consists of entity ontol-
ogy and operation ontology, which represents noun terms
and verb terms respectively. Domain models can resides
in role layer, goal layer, process layer and service layer.
Role layer describes organizations, roles, participants and
the relationships between them. Goal layer addresses
users’ requirements based on SORL and provides a goal
based hierarchy for requirements refinement. Process
layer and service layer present the processes and web
services that can fulfill users’ requirements.
Based on RGPS framework, users’ requirements in
SORL can be translated into customized goal model and
process chain step by step. Finally, these models ex-
pressed with OWL can be saved as the corresponding
Web service-based requirements specifications. During
the process of translating, process model plays a very
important role. Because process can not only give a de-
tailed perspective on how a service operates, but serve as
a bridge between users’ requirements and service compo-
sition. According to the refining process in RPGS, goals
can be refined as operational goals, which can be mapped
to some certain processes. Compared with goal model,
process model contains control structures. In order to
generate complete process chain from initial require-
ments, a control structure extraction method is expected.
In this paper, an approach to generate process-oriented
requirements specification is proposed to extract control
structure from language patterns and business rules. This
approach can be used to generate a process-based re-

14 An Approach to Generation of Process-Oriented Requirements Specification
quirements specification from users’ requirements and
support web services composition in NS.
The rest of this paper is organized as follows: Section
2 introduces the theoretical foundation of our approach.
Section 3 gives the overview of the requirements specifi-
cation generation approach. Section 4 states the process
control structure extraction method with a case study.
Section 5 discusses related works, followed by the con-
clusions and future work in Section 6.
2. Theoretical Foundation
2.1 SORL: A Requirements Description Language
Natural language pattern is the key to information extrac-
tion. Based on natural language patterns, SORL is de-
signed for online requirements elicitation. Figure 1 illus-
trates the requirements description metamodel in SORL.
There are four layers in the syntactic structure of SORL,
which are sentence, pattern, phrase and word. More spe-
cifically, Word includes concepts in the domain ontology
and key words defined in sentence and pattern (e.g.
preposition and adverb).
There are 10 types of patterns in SORL, covering the
description of functional goals, qualitative nonfunctional
goals, quantitative non-functional goals, and precondition
and post condition of a goal, etc.
The SORL sentence, which can be simple sentence or
compound sentence, is composed of patterns. Simple
sentence can be used to describe an activity, a constraint,
or a state. Compound sentence is composed of natural
language pattern, which can be Loop Sentence, Choose
Sentence and Trigger Sentence. In this paper, we will pay
more attention to compound sentences. More details of
SORL are provided in [6].
2.2 RGPS: A Domain Metamodeling Frame
In order to develop software rapidly, reuse of both code
and components should be taken into account. Common
requirements resources are also important asserts in
software development, which should be given to recovery
and reuse. Many researches recognized the potential
benefit of requirements reuse [7,8], and provided corre-
sponding methods. In [9], for example, ontology was
used to represent common requirements in certain do-
mains. In order to sort and reuse requirements assets in
the networked environment, a unified requirements
meta-modeling frame named RPGS is proposed. The
frame is consisted of domain ontology and domain model.
Domain ontology includes entities and operations, which
can be imported by domain models. There are four
meta-models in RGPS:
Role metamodel describes the user roles of networked
softwares, the actors who play roles, the contexts where
actors are, intercourse between different roles, and the
business rules to be complied with.
Goal metamodel describes the requirements goals of
users, including functional, non-functional goal, and se-
mantic relationships between them (e.g. depend, conflict,
etc.). The goals can be refined to operational goal further,
which can be realized by business processes. The process
of goal refinement will not halt until all the goal leaves
are operational goals.
Process metamodel defines information of business
processes, including functional description such as IOPE
(input, output, precondition and effect), and non-func-
tional description such as Qos expectation and individu-
alized business context expectation. A process can realize
at least one functional goal and promote realization of
non-functional goals. A process can be either an atomic
process or a composite process, and a composite process
has its own control structures.
Service metamodel provides the solution based on ser-
vice resources, with functional and non-functional attrib-
utes. A service-based solution can be used to realize the
specified business process.
Figure 1. Requirements description metamodel

An Approach to Generation of Process-Oriented Requirements Specification 15
1.Parsing 2.Goal
Refinement
3.Process
Matching
NS
Requirements
Specification
Requirements
In SORL
Initial
Customized
Goal Model
Refined
Goal Model
Process
Chain
Domain
Ontology
Domain Role
Model
Domain Goal
Model
Domain Process
Model
Figure 2. Overview of the NS requirements specification generation process
The domain model is provided by domain experts un-
der the guidance of these four metamodels. Some domain
requirements assets are stored as domain knowledge in
each layer of RGPS, which corresponds to the respective
requirements of different users group. Requirements of
the user are elicited, analyzed, and finally matched to the
common domain requirements specifications described
with Web services.
3. Overview of the Approach
Figure 2 illustrates the overview of the requirements
specification generation process. The three shadowed
parts are key steps to convert requirements into NS re-
quirements specifications.
·The first step is to parse users’ requirements described
in SORL to initial customized goal models by a finite
automaton. SORL and domain ontology share a com-
mon vocabulary to ensure that the requirements can be
parsed to goal model in a consistent manner. All the
functional goals and non-functional goals are matched
against domain goal model. All the unmatched goals will
be marked, and stored into the specification repository
for further analysis by domain engineers to check
whether common requirements assets are enough.
·Secondly, each goal in the first step will be linked to a
role. The goals can be decomposed into more concrete
sub-goals according to the hierarchical structure in
domain goal model. While the sub-goals are all opera-
tional goals, the refinement process is ended. The goal
refinement process is shown in Figure 3. An opera-
tional goal means a goal which can be matched to a
simple process or a composite process consistently. In
this step, the goals depended by existing goals from
users’ requirements will also be added to improve us-
ers’ demands. For example, if user needs the goal
“book airline ticket by credit card”. To achieve this
goal, the goal “validate credit card” must be carried out
previously.
Figure 3. Goal refinement process

16 An Approach to Generation of Process-Oriented Requirements Specification
Figure 4. Process metamodel in RPGS
·In the third step, a set of processes are gained based
on the refined goal model composing operational
goals. Since process model has its own control
structure (e.g. sequence, choice, join, etc), a set of
extraction rules is needed to extract control struc-
tures from above two steps and composite these
processes into process chains. With the control
structures, the discontinuous processes can be inte-
grated as process chains and saved as requirements
specification finally.
In this section, the overview of our approach is illus-
trated, in next section, the process control structure ex-
traction rules will be discussed in detail.
4. Extraction Rules for Process Control
Structure
This section discusses some rules of extracting process
control structures. Figure 4 illustrates the process meta-
model in RPGS frame. The shadowed parts are primitive
control structures defined in RPGS, i.e. Sequence, Loop,
Choice, Join, and Split. In order to obtain control struc-
tures in process chains, each control structure should be
mapped in metamodel layer.
In our approach, process control structures are gener-
ated from two sources: one is sentences based on SORL.
The other is Depend relationships between related goals
of the specific process.
4.1 Extraction Rules Based on SORL Sentence
As Section 2 describes, two kinds of compound sentence
in SORL can be used for process control structure extrac-
tion, i.e. Loop sentence and Choose sentence.
Loop Sentence
The loop control structure can be extracted from loop
sentence. Loop sentence describes system cyclic behavior
under a certain condition. As Figure 5 shows, loop sen-
tence is represented as “loop <function requirement pat-
tern> until <condition pattern>”. To extract loop control
construct from the corresponding loop sentences, we de-
fine extraction rules as follows:
Def.1 In a Loop sentence, FP is the Function Require-
ment Pattern and CP is the Condition Pattern. So the
Loop sentence “loop FP until CP is true” denoted as
LoopSentence (FP, CP).
Def.2 In a process chain, P is a process and C is a condi-
tion. “Loop a Process P until condition C is true” will be
denoted as LoopControlStructure (P, C).
Def.3 If FP is a Function Pattern, the process related to
the corresponding goal of this Function Pattern is denoted
by P. If CP is a Condition Pattern, the related Condition
in process chain is denoted by C.
Extraction Rule.1:
LoopSentence (FP,CP)⇒LoopControlStructure (P,C)
Figure 5. Loop sentence
Figure 6. Choose sentence

An Approach to Generation of Process-Oriented Requirements Specification 17
Choose Sentence
The extraction of Choice control structure is similar to
the one of Loop control structure. In SORL, choose sen-
tence describes a selection of different system behaviors.
Choose sentence is represented as “if <Condition Pat-
tern>, then <Function Pattern>, else <Function Pattern>”,
as Figure 6 depicts. The extraction rules of choice control
structure are the followings:
Def.4 FPA and FPB are two alternative Function Re-
quirement Patterns in a Choose Sentence, and CP is the
Condition Pattern. The Choose sentence “if CP, then FPA,
else FPB” is denoted by ChooseSentence (CP, FPA, FPB).
When FP is a Function Requirement Pattern in a Choose
Sentence, the Choose sentence “if CP, then FP” is de-
noted by ChooseSentence (CP, FP).
Def.5 C is a condition in process chain, and PA and PB are
two processes. The Choice control structure in process
chain is denoted by ChoiceControlSturcture (C,PA,PB),
which means “if C is true, then execute PA; if not, exe-
cute PB”. When P is a process, if C is true, then executes
P, else skip P, this is denoted by ChoiceControlSturcture
(C,P)
Extraction Rule.2:
ChooseSentence (CP, FPA, FPB)⇒ChoiceControlStruc-
ture (C, PA, PB)
ChooseSentence (CP,FP)⇒ChoiceControlStructure(C,P)
4.2 Extraction Rules based on Goal Model
In RGPS, Goal metamodel defines Depend relationships
between goals. A Depend relationship can be either an
Object Depend or a Conditional Depend. Object Depend
used to indicate the Input/Output relationship between
two goals, which is related to dataflow in system. Condi-
tional Depend describes the Precondition/Postcondition
between two goals, which is related to business rules.
Object Depend
In Object Depend relationship, realization of a goal de-
pends on output data of the other goals. We assume that
such dataflow in real time systems would never get fail-
ure. Correspondingly, the realization of related process
also depends on the others. Therefore, we can extract
process control structure from Object Depend relation-
ship this section defines three extraction rules for Se-
quence, Split and Join control structure respectively.
Def.6 GA and GB are two goals in refined goal model. If
GA Object Depend on GB, the relationship is denoted by
ObjectDepend (GA, GB). GAi (i=1, 2,…,n) and GB are goals in
refined goal model, GAi (i=1, 2,…,n) Object Depend on GB, it
is denoted by ),(
...2,1 BAi niGGndobjectDepeAnd =
. GA and
GBi(i=1,2,…,n) are goals in refined goal model, GA Object
Depend on GBi(i=1, 2,…,n), it is denoted by
),(
...2,1AiB niGGndobjectDepeAnd =.
Def.7 PA and PB are two processes in process chain. If
there is a sequence control structure between PA and PB
and PA executes after PB, denoted by Sequence (PA, PB).
Extraction Rule.3:
),(),( ABBA PPSequenceGGndObjectDepe ⇒
Def.8 PAi(i=1, 2… n) and PB are Process in process chain, if
PAi(i=1, 2… n) is split from P
B, the control structure is de-
noted by Split (PB, PAi).
Extraction Rule.4:
),(),( ...2,1...2,1 AiB
ni
BAi
ni PPSplitAndGGndObjectDepeAnd ==
⇒
Def.9 PAi(i=1, 2… n) and PB are Process in process chain, if
PAi(i=1, 2… n) is join to PB, the control structure is denoted
by Join (PAi, PB).
Extraction Rule.5:
),(),( ...2,1...2,1 BAi
ni
AiB
ni PPJoinAndGGndObjectDepeAnd==
⇒
Conditional Depend
Conditional Depend describes the business rules between
goals. “Goal A is Conditional Depend on Goal B” means
“if Goal B cannot be achieved, then Goal A cannot be
achieved; if not, it should be skipped”. For example, a
traveler want to travel to Wuhan, he want to “book an
airline ticket to Wuhan”, and to “book a standard room in
Wuhan”. If the first goal can’t be achieved, which means
he can’t arrive in Wuhan in time, the second goal will be
canceled. From this point of view, we defined the fol-
lowing rules:
Def. 10 GA and GB are two goals in refined goal model, If
GA Conditional Depend GB, denoted by ConditionalDe-
pend (GA, GB).
Def. 11 PA is a process, if PA is successful execution, the
condition CA in A
P’s Effect would be True, else be False.
Extraction rule.6
),(
),(
AB
BA
PC
rerolStructuChoiceContGGlDependConditiona ⇒
4.3 Case Study
In this section, a case in travel and transportation domain
will be demonstrated. Firstly, we constructed the domain
ontology and domain model in [5]. And the following
ones are requirements examples.
A customer is planning a trip to Wuhan. His SORL-
ased requirements are as followings:“Query travel ex-
pense in Wuhan”, “Book an airline ticket to Wuhan by
credit card”, “if the price is no more than 500 RMB, then,
book a room, the standard of the hotel is no less than
4-Star, else, book a standard room, the standard of the
hotel is equal to 3-Star.”
Figure 7 Refined goal model of the case.
·Based on extraction rule 2, we can find that there is a
choice control structure in the corresponding processes
of “book room”.
·Based on extraction rule 3, the related process of
“Validate Credit Card” must be executed before the re-
lated process of “Book Airline Ticket by Credit Card”.
·Based on extraction rule 6, if “book airline ticket”
cannot be achieved, “book room” should be skipped.
The generated process chain is shown in Figure 8.

18 An Approach to Generation of Process-Oriented Requirements Specification
Figure 7. An example of refined goal model
Figure 8. An example of process chain
A trial system based on this approach is build up pre-
liminarily. With the graphical process tool, users can see
their requirements directly, so that users can understand the
work flow intuitively and modify the work flow with ease.
5. Related Works
Process-oriented technology has many potential advan-
tages in software development, and many SOC tech-
nologies have adopted process in their methods to im-
prove the service composition. For example, OWL-S
[10] models services as processes to give services a
more detailed perspective. In WS-BPEL [11], processes
use Web Service interfaces to export and import func-
tionality.
In [12], W. M. P. van der Aalst proposes an algorithm
based on petri net to extract process model from “work-
flow log”, which contains information about the work-
flow processes in real-time systems. Moreover, many
systems (e.g. ERP, CRM) provide a set of pre-defined
process models. In our work, we use RGPS to manage
not only process model but also related goal, role and
service model. A solution for process model generation
from user’s requirements is given.
In [13] and [14], authors established relationships be-
tween process model and high-level requirements models
(e.g. KAOS and i*), presented methods to generate, vali-
date and improve process model. In [15], authors present
a framework and associated techniques to synthesis ser-
vice composition from temporal business rules through
process models. Compared with these approaches, our
approach is more suitable for end-users and caters for the
“user-centric” trend.
6. Conclusions and Future Work
In this paper, we proposed an approach to generation of
process-oriented requirements specifications. It estab-
lishes mappings from SORL metamodel and Goal meta-
model in RGPS to the control structures defined in Proc-
ess metamodel. So it can be used to generate an NS re-
quirements specification including goal models and
process chains through these control structures.
In the future, the control structure extraction rules will
be improved, the influences from goal refinement types
(e.g. mandatory, optional) to the control structure will be
supplemented. Moreover, the corresponding validation
and verification methods will be provided later, followed
by the relevant tools and platforms.
7. Acknowledgements
This research project was supported by the National Ba-
sic Research Program of China (973) under Grant No.
2006CB708302 and 2007CB310801, the National High
Technology Research and Development Program of
China (863) under Grant No.2006AA04Z156, the Na-
tional Natural Science Foundation of China under Grant
No. 60803083, 60873009, 60803025 and 60703018, the
Provincial Natural Science Foundation of Hubei Province
under Grant No.2006ABA228,and the Research Fund for
the Doctoral Program of Higher Education of China un-
der Grant No. 60803025.
REFERENCES
[1] M. N. Huhns and M. P. Singh, “Service-oriented comput-
ing: Key concepts and principles,” IEEE Internet Com-
putting, pp. 2-8, 2005.

An Approach to Generation of Process-Oriented Requirements Specification 19
[2] K. He, R. Peng, J. Liu, F. He, et al., “Design methodology
of Networked Software Evolution Growth based on Soft-
ware Patterns,” Journal of System Science and Complex-
ity, Vol. 19, pp. 157-181, 2006.
[3] K. He, P. Liang, R. Peng, et al., “Requirement emergence
computation of networked software,” Frontiers of Com-
puter Science in China, 1(3), pp. 322-328, 2007.
[4] W. Liu, K. He, J. Wang, et al., “Heavyweight semantic
inducement for requirement elicitation and analysis,” In
Proceedings of the 3rd International Conference on Se-
mantics, Knowledge and Grid (SKG 2007), Xi’an, China,
pp. 206-211, 2007.
[5] J. Wang, K. He, P. Gong, C. Wang, R. Peng, and B. Li,
“RGPS: A unified requirements meta-modeling frame for
networked software,” in Proceedings of Third Interna-
tional Workshop on Advances and Applications of Prob-
lem Frames (IWAAPF’08) at 30th International Confer-
ence on Software Engineering (ICSE’08), Leipzig, Ger-
many, pp. 29-35, 2008.
[6] L. Wei, “Research on services-oriented software require-
ments elicitation and analysis,” Ph. D thesis, Wuhan Uni-
versity, 2008.
[7] P. Massonet and A. van Lamsweerde, “Analogical reuse
of requirements frameworks,” Third IEEE International
Symposium on Requirements Engineering, pp. 26, 1997.
[8] W. Lam, “A case-study of requirements reuse through
product families,” Springer Netherlands, pp. 253-277,
1998.
[9] Y. Q. Lee and W. Y. Zhao, “Domain requirements elicita-
tion and analysis-An ontology-based approach,” In: Pro-
ceedings of Workshop on Computational Science in Soft-
ware Engineering (CSSE), pp. 805-813, 2006.
[10] M. Smith, C. Welty, and D. McGuinness, “OWL web
ontology language guide,” W3C Candidate Recommen-
dation, 2004. Available: http://www.w3.org/TR/owl-
guide/.
[11] OASIS: Web services business process execution lan-
guage version 2.0, 2006. Available: http://docs.oasis-
open.org/ wsbpel/2.0/wsbpel-specification-draft.html.
[12] W. van der Aalst, T. Weijters, and L. Maruster, “Work-
flow mining: Discovering process models from event
logs,” IEEE Transactions on Knowledge and Data Engi-
neering, Volume 16, Issue 9, 2004.
[13] G. Koliadis and A. Ghose, “Relating business process
models to goal-oriented requirements models in KAOS,”
PKAW 2006, pp. 25-39, 2006.
[14] A. Ghose and G. Koliadis, “Actor eco-systems: From
high-level agent models to executable processes via se-
mantic annotations,” COMPSAC 2007, pp. 177-184,
2007.
[15] J. Yu, Y. B. Han, J. Han et al., “Synthesizing service
composition models on the basis of temporal business
rules,” Journal of computer science and technology 23(6)
pp. 885-894, 2008.