2010 34th Annual IEEE Computer Software and Applications Conference Workshops
Stakeholders-driven Requirements Semantics Acquisition for Networked Software Systems Bin Wen, Peng Liang, Keqing He State Key Lab of Software Engineering, Wuhan University Wuhan, China Email:
[email protected],
[email protected]
stakeholders inform more concerns than end users; software development is a long-term application and continuous, evolutionary growth process; use all software resource from local or internet as well as services [1]. Faced with complex stakeholders and requirements, largescale networked software should combine with the research of information technology and information system to complex structure by introducing complex science theory. Analysis for requirements generating mechanism of large-scale complex system indicates that requirements present selfadaptive and collective evolution characteristic and overall requirements emergence phenomena for requirements acquiring is unable to be interpreted with traditional Reductionism. Now plenty of Web 2.0 applications have fully showed it. How to explore novel requirements acquiring technique to answer complex situation for the development of networked software? How to facilitate the subsequent automated and on-demand services software delivery just in time through attaching semantic information? These issues are the motivation and focus of the paper. In our previous work, we have partly investigate these questions and argued that requirements acquisition should fully make use of stakeholders participation and folks intelligence. Through some collaborative platforms of social software such as semantic wikis and RSS/Atom etc., and exploiting simple annotating function plus evolutionary mechanism, software requirements specification and requirements semantics will efficiently emerge. At the same time, requirements acquiring process is continuous in accordance with networked software features, i.e. on-demand changing and uninterrupted growing.
Abstract—Large-scale and complex system exhibits adaptive feature, and evolutionary emergence of collective behaviors is its fundamental phenomena. Considering service oriented requirements engineering (SORE), this paper explores requirements semantics acquisition technique and analyzes its adaptive feature. The strategy of evolutionary growth to gain domainspecific requirements semantics model is proposed. Also, this approach combines with folks and experts intelligence to create requirements semantics. The instantiation of semantics is performed based on this model. The semantic model can facilitate consistency check and reasoning for high-quality requirements. By employing the functions provided by semantic wikis, a stakeholders-driven semantics acquisition platform for prerequirements is designed. Apart from traditional documentary specification, on-demand semantics artifacts will be exported to the subsequent services aggregation and semantics-driven service customization. Keywords-service requirements; requirements engineering; requirements semantics; semantic wikis;
I. I NTRODUCTION Requirements engineering (RE) is crucial to the success of software development projects, especially for networked software based on services [1]. Presently, typical RE approaches include goal-oriented, ontology-oriented, scenariobased, problem framework, pre-requirements analysis based on domain modeling, document driving and aspect-oriented method [2]. The applicability and feasibility of those above-mentioned approaches for service-oriented computing must be reconsidered while networked software gradually becomes new paradigm. Significant differences exist between serviceoriented and object-oriented software development, serviceoriented development focuses on finding and reusing existing services resource to satisfy users requirements, whereas nowadays requirements modeling methods are deficient to support the aspect. Apart from small and instant services-assembled software, internet users with same interest and similar benefit, namely stakeholders including end customers, sponsors, project managers, architects, designers etc., also have urgent demand for domain-specific large scale networked software based on services. The sort of software embodies the following characteristic: enormous functions and complex requirements; 978-0-7695-4105-1/10 $26.00 © 2010 IEEE DOI 10.1109/COMPSACW.2010.76
II. S EMANTIC W IKIS FOR SORE Collaborative interaction mechanism of Wiki has been applied across entire lifecycle for software development [3]. We mainly concern about the supporting of semantics requirements engineering (SRE) with semantic wikis [4]. SRE is the deepening of traditional RE via plus semantics on requirements artifacts to expose the relationships among requirements elements explicitly. Requirements semantics will facilitate the subsequent on-demand automated manufacture of services software, and semantics can penetrate the process 281 255
as unstructured data, hard to reuse of knowledge and limited search functions [4]. The above-mentioned problems reduce to the absence of semantics. Semantics indicates explicit expression for concept entities and relations among entities to derive a series of intelligent and flexible applications. With the addition of semantics to a wikis, the wikis becomes more sophisticated than normal wikis to machine accessible. Data in a wikis page can be captured or identified and can be related to data in other wikis pages. These semantic annotations can store as knowledge base or correspond to a underlying ontology ( e.g. domain ontology ). Consequently, the navigation, search, retrieval, and presentation can be improved. Another point of interest is the better means to support interoperability. First impression is that a semantic wiki provides an interesting platform for RE. The collaboration between the different stakeholders can be improved by using a wiki. With the use of a wiki, non-technical stakeholders can also easily participate. Next to collaboration support, semantic relations can model conflicts or dependencies between the requirements. Functionalities provided by existing requirement management tools can also be supported by semantic wikis. Furthermore, a semantic wiki can interoperate with an Integrated Development Engineering (IDE) platform. Requirements can be exported from a semantic wiki to the Eclipse IDE. Consequently, the rendering of organizational business processes and system artifacts from the requirements description, can be partially automated [6]. Different semantic wikis are on the market with their own characteristics [4]. Some engines of the semantic wikis which are still under development and suit to add auxiliary functions openly for semantics acquiring mainly include semantic mediawiki, ontowiki, KiWi, SweetWiki1 etc.
Domain Requirements Ontology Conduct
Extract
Reasoning
Coarse Requirements
Annotation system
tagging
Service Providers
requirements semantics acquiring
Stakeholders
inform (RSS)
requirements analysis verify & validity
customized produce by requirements semantics
Refined requirements Requirements Engineers
matching results or just-in-time produce
requirements semantics extending services
RSO clustering matching
dpo repository RGPS Assets
local services pool
Figure 1.
Broker
simulation & evaluation collaboration v&v ......
process composition & application deployment NOTE: RSO (Requirements Signal Ontology), similar to semantic representation of services software business process. DPO (Domain Problem Ontology), semantic description of domain-specfic problem oriented solving.
Semantics Requirements Engineering for service
for service industry chain containing requirements semantics acquiring, interoperability extending and services customization directed by requirements semantics (Figure 1). From the phase of requirements semantics acquisition, stakeholders will tag the requirements elements and related semantics through annotation system directed by domainspecific requirements ontology. Meanwhile annotation system will be able to extract collective requirements model for better semantics description. With explicit semantics, reason supporting can be executed. Tagged coarse requirements artifacts including documentary artifacts and requirements semantics artifacts are submitted to requirements engineers for further refining. According to business process theory, refined requirements semantics will be organized as RSO (Requirements Signal Ontology) which is similar to semantic representation of services business process. Under the setting of Internet, with SOA, varied repository and registry, dispersed services including local and remote services resource should be aggregated to services software centralized on RSO [5]. Temporarily unmatched services will follow user-centric principle to individually manufacture. Customized product can apply inform (e.g. RSS/Atom) mechanism to publish on-demand requirements semantics for services providers. Consequently, SRE will greatly upgrade RE quality and level for services. The paper only investigates requirements semantics acquisition. Semantic wikis is highly compatible with synthesized use of semantics information for SRE, especially, in the initial semantics acquiring phase. The principle of wikis consists in open editing and free collaboration designated to encyclopedia systems, software development and project management etc. But, for the normal wikis, there are also problems with to mention such
III.
STAKEHOLDERS - DRIVEN REQUIREMENTS SEMANTICS ACQUISITION
Through the above-mentioned analysis, we believe that requirements semantics will span the entire lifecycle for services software and requirements semantics acquiring is also a process of continuous evolution. Firstly, ideal strategy for requirements semantics growth should design a meta-conceptual model (ontology) of services requirements by domain/requirements experts. Next, depending on folks intelligence of free semantic annotating to get folksonomic requirements semantics with baseline management, the folksonomic requirements semantics can revise the experts model to gain service oriented requirements semantics ontology (SORSO) combined with experts and folks power. Stakeholders and requirements engineers carry out instantiated annotation conduct by SORSO. At last, 1 http://semantic-mediawiki.org; http://ontowiki.net; project.eu; http://argentera.inria.fr:8080/wiki
256 282
http://www.kiwi-
goal commitment will translate into process which can be matched by services with service R& R mechanism.
requirements semantic artifacts can be successfully and highquality produced from the stakeholders-driven requirements semantics acquiring architecture.
B. collaborative platforms for stakeholders-driven requirements semantics acquisition
A. service oriented requirements semantics ontology
With collaboration and semantics annotating mechanism based on semantic wikis, fully making use of collective intelligence, we design a collaborative system of large-scale and complex networked software requirements semantics acquisition based on stakeholders-driven fashion ( Figure 3). System consists of stakeholders and related platforms, and platforms include two parts: collaborative interaction platform for stakeholders and requirements semantics instantiation platform.
Regarding the features for service computing, role, goal, process and service, the four fundamental elements can be used to modeling for the users’ truly intentions of networked software. A meta-modeling framework containing the four fundamental elements, namely RGPS [7], is presented for conducting synergy and ordered structure requirements specification from disordered requirements information. Furthermore, choosing ontology meta-modeling and encapsulating domain reusable core services asset, O-RGPS (OntologyRGPS) meta-model proposal is also put forward. Based on O-RGPS requirements meta-model framework, user requirements can be described from different angle, level and granularity in order to form domain requirements asset and store as OWL for reuse. In our previous works [8]
St ak eh ol d er s
R e q u ir e m e n ts s e m a n tic s in s ta n c e s a n n o ta tin g
cause / conflict
to / object propose
Stakeholders Chosen Requiremets
cause
Canididate Requiremets
Role
caus e/c onfli ct
Alternative Requiremets
prefers takeCharge Actor
Goal
r cove
ach con trib ieves utes
Role Goal
Functional
Organization Nonfunctional R
G
SO R e qui r e m e nt s S e m an t i c s O n t o l o g y (SO R SO ) C o nduc t
D o m a i n o r i t e n t e d Revise e xpe r t s r e qui r e m e nt s s e m an t i c d e s c r i p t i o n
Motivator
cause
D o m ai n E x p e r t s & R e qui r e m e nt s E ngi ne e r s
s e m a n tic s in s ta n c e s a n n o ta tin g
realizes
Process
E x t r ac t f o l ks o no m i c r e qui r e m e nt s s e m an t i c s
c o lla b o r a tiv e p la tf o r m f o r r e q u ir e m e n ts r e q u ir e m e n ts s e m a n tic d o m a in s e m a n tic in s ta n tia tio n s e r v ic e s a s s e t a r tif a c t e x p o r t e x p o rte r re a s o n e r r e qui r e m e nt s c o n s is te n c y ...... s e m an t i c i n s t an t c hec k s o c ia l do c um e nt b u s i n e s s w id g e ts O n to W ik i de s c r i pt i o n c o re
Obstacle Domain Assumption
Personal Goal
C o lla b o r a tiv e in te r a c tiv e d o c um ent p la tf o r m e x p o rte r s o c ia l w id g e ts R D F /O W L s e m a n tic r e qui r e m e nt s ve r s i oni ng e x p o rte r do c um e nt r e q u i r e r m e n t s m e d ia W ik i s e m a n tic s ar t i f ac t e x p o r t c o re e x te n s io n
f r e e e d itin g & ta g g in g & s e m a n tic a n n o ta tin g
Service
(a) interactive platforms Main view
Main menu
Atomic Service
Atomic process Composite Process P
Project Description
Semantics model
Composit Service
Access control
S
semantic annTohteatdioentailed description about this project can refer to course project description. About this project wiki
This project wiki is basceodnfoirnmPmWiki, acanndcealcts as a template wiki for our RE course project. Instance wikis based on this template wiki will be created according to the number of project groups. This is the first time we introduce wiki as a lightweight RE documentation tool for stakeholders (i.e., students) in this course to collaboratively elicit, analyze, negotiate, document and manage the ream projeccatnrdeiqduaitreedmreenqtsu.iH vienngtsfun with this REWiki. Page descriptions * RequiremernotlsePlayground page is used to document all the requirements, including stakeholders for the course project. Template and examples have been provided for reference. giosatol ry page is used to record the revision history of your * Revision H requirements specifications documented in this wiki. goal ty*peM : eeting History page is used to record the Meeting History, including the Stakeholders' Role Allocation by group members, for discussing the requirements speFcuifnicctaiotinoanl sgodaolcumented in this wiki. We suggest that each group member should play all the roles at least once throughout the course period.
Association is A
Nonfunctional goal
Figure 2. Experts-level requirements semantics model defined by requirements engineer for services software
Role goal
(b) semantic annotation interface design
have presented a Requirements Rationale Model (RRM) and related reasoning rule support. Combined with RGPS and RRM, experts-level requirements semantics model for services software ( Figure 2 ) can be created as evolutionary base. Goal part of RGPS model directly inherits from Chosen Requirements of RRM. RRM segment mainly focus on pre-requirements reasoning, and RGPS segment emphasize particularly on the relation from requirements to services. Experts-level requirements semantics model with reasoning rule [8] furnishs elementary requirements description and reason supporting for further requirements extending. The model spans from goal to service realization. Clear
Figure 3. •
Stakeholders-driven requirements semantics acquisition
collaborative interaction platform: opening for general stakeholders and providing some social functions such as free editing, tagging and semantics annotating. Since semantic mediawiki (mediawiki2 plus semantic extension) supports collaborative semantics annotation and need not conform to a base model, the platform chooses semantic mediawiki as underlying core and develop versioning management, social widgets ( e.g. tagging,
2 http://www.mediawiki.org
257 283
•
V.
RSS, discuss panel ), RDF/OWL exporter for folksonomic semantics, exporter for requirements document. With baseline management, Requirements artifacts can be generated as follows: (1) requirements document conforming to standard. (2) extracted folksonomic semantics to renew experts knowledge and form service oriented requirements semantics ontology ( SORSO ). requirements semantics instantiation platform: Adopting ontowiki core which can provide instantiation mechanism supervised by a imported ontology as base technique, general stakeholders, domain experts and requirements engineers able to annotate instantiation data conducted by SORSO. At the same time, supporting consistency check and requirements reasoning with external DIG reasoner(e.g.Pellet), this platform can generate high-quality and dependable baseline requirements semantics artifacts for the subsequent automated services software aggregating and requirementsoriented customization.
This paper explores requirements semantics acquisition technique for large-scale and complex services-based software and analyzes its adaptive feature. The key steps of proposed approach are stated below: (1) build folksonomy semantics to revise expert-level service model, then form the SORSO; (2) semantics instantiation annotation based on SORSO; (3) export requirements artifact from annotated SORSO. In the end, the requirements semantics, namely intelligent content, will commit itself to play a key role for the age of networked software systems. Further works can be classified as follows: platforms running online for valuable evaluation; application of requirements semantics artifacts based on IDE environment; interoperability extending of requirements semantics to services software production and so on. ACKNOWLEDGMENT This research has been partly supported by the National Basic Research Program of China (No. 2007CB310801) and the National Natural Science Foundation of China under No.60970017 and 60950110352.
According to the principle of always online and evolution just in time, i.e. self-adaptive feature for social and complex services software, collaborative platforms should better improve QoE (Quality of Expectation) of end users. IV.
CONCLUSIONS AND FUTURE WORK
R EFERENCES [1] K. He, R. Peng, and W. Liu, Networked Software. Beijing: Science Press, 2008. [2] Z. Jin, L. Liu, and Y. Jin, Software Requirements Engineering: Principles and Method. Beijing: Science Press, 2008. [3] B. Decker, E. Ras, J. Rech, P. Jaubert, and M. Rieth, “Wikibased stakeholder participation in requirements engineering,” IEEE Software, no. 2, pp. 28–35, 2007. [4] H. Bart and P. Liang, “A survey of semantic wikis for requirements engineering,” Software Engineering and Architecture Group,Department of Mathematics and Computing Science,University of Groningen., Tech. Rep. RUG-SEARCH-09L03, July 27 2009. [5] B. Wen, K. He, and J. Wang, “Building requirements semantics for networked software interoperability,” Journal of Software Engineering and Applications, vol. 3, no. 2, pp. 125–133, 2010. [6] P. C. L. Abeti and R. Moretti, “Wiki-based requirements management for business process reengineering,” in Proceedings of ICSE 09 workshop on Wikis4SE. Vancouver, Canada: IEEE Computer Society Press, 2009, pp. 14–24. [7] J. Wang, K. He, and R. Peng, “Rgps: A unified requirements meta-modeling frame for networked software,” in Proc. of Third International Workshop on Advances and Applications of Problem Frames (IWAAPF’08)at 30th International Conference on Software Engineering (ICSE’08), Leipzig, Germany, May 2008, pp. 29–35. [8] P. Liang, P. Avgeriou, and V. Clerc, “Requirements reasoning for distributed requirements analysis using semantic wiki,” in Proceedings of the International Workshop on KNOWledge engINeering in Global software development (KNOWING). 388-393: IEEE Computer Society Press, 2009. [9] S. Lohmann, P. Heim, S. Auer, S. Dietzold, and T. Riechert, “Semantifying requirements engineering - the softwiki approach,” in Proceedings of the 4th International Conference on Semantic Technologies (I-SEMANTICS). Graz, Austria: ACM, 2008, pp. 182–185.
RELATED WORKS
SOP-Wikis [3] and WikiReq [6] proof the usefulness of semantic wikis in the distributed requirements elicitation and documentation phase of the RE process. There is also another cooperative research project going on, SoftWikis [9], which focuses on semantic collaboration in particular with respect to software requirements based on Ontowiki engine. WikiReq, exploits the Semantic Mediawikis to manage system and organizational requirements among the Si* main concepts. But, WikiReq can’t dynamically generate requirements semantics and Si* concepts model is also unsuitable to requirements description for services. Software Organization Platform (SOP) wikis has the ability to harvester links and freeze them. Another feature about versioning is version tagging. Furthermore, the SOP wikis provides the ability to export wikis content (e.g., requirements) to individual documents (Open Office documents). Compared with our work, SOP hasn’t underlying model to conduct stakeholders annotation, since requirements semantics may be imprecision and lack intelligent applications. SoftWikis focuses on semantic collaboration with respect to software requirements activities. The core concepts and interrelation of RE are defined in the SoftWikis Ontology for RE (SWORE). Apparently, SoftWiki unable to support stakeholders’ semantics model to evolutionary revise SWORE, and SWORE also couldn’t better concern about the facets of services requirements to fit the semantics description for networked software.
258 284
