Research Proposal on Requirement Engineering Process for Service Oriented Software
Eric Ateba Manga
Northcentral University
June 6, 2020
Background
Component Based software Development is a branch of software engineering that
utilizes the available software components in providing a project facility that allow reusability
while reducing the overall effort in effective management. The development of the internet
has played a key role in global communication and computing making distributed promising
(Bano, 2010). Distributed computing provides the appropriate infrastructure and technology
that allows distributed application development in a transparent environment where the have
access to all the underling technologies. The developers focus on application design and
locating the required components in the distributed environment.
Service oriented software development is a software engineering paradigm that is
based on the use of web services which are available on the internet. Some of the web
interfaces can be leased as part of the software.
Distributed computing largely deploys Service Oriented Architecture (SOA). It has
become its new reference architecture with the exponential increase of web services within
the last few years. Researchers face difficulty in selecting the best service that fulfills user
requirements and provides emphasis on automating the process of web service discovery. The
service centric systems do not have a standard requirement engineering process whereas the
systems used for COTS selection and traditional processes have architectural differences
compared to the services-oriented software development in other domains and therefore
cannot be implemented (Bano M. I., June 2010).
The challenges faced by the larger complex system design and implementation can be
solved through component-based software engineering and service-oriented software
engineering. This paper aims to outline challenges of the service-oriented software
development paradigm and design a framework to solve the highlighted problems. Moreover,
the proposal shall be validated through experiments.

Problem Statement
This new field in software has presented the research community with various issues.
Service composition and service management and monitoring are the two key areas concerned
with requirement engineering. Service composition focuses on the methods and techniques
involved in the discovery and selection of web serviced through evaluation of system
requirements and subsequently integrating them using an orchestrating language or a tool to
develop the application. Service management and monitoring on the other hand deals with the
management and control of the service-based application during its life cycle. Re-composition
is done when some of the services needed as part of the composed service are no longer
available forcing the requirements of the existing system to evolve. The provider launches a
new version of the web service which results in a conflict with the existing system
requirements (Tsai, March 2007).
When a software meets all the objectives it was designed for, the said software is
deemed to be successful. The requirement engineering process is used to identify the
objectives through identifying the stakeholders, gathering the stakeholder’s needs and
understanding them, documentation of specification and analyzing it.
Requirement engineering is made of two phases; requirement development which
involves elicitation of requirements, analysis and verification. Requirement management
focuses on control and changing or evolving requirements.
The stakeholders come to an agreement on the system to be built and agreed upon
requirements are controlled and managed during requirement management. Service based
software Development is a shift from the traditional development and has several new
methods proposed for implementation. The SDLC model used affects the requirement
engineering phase (Pandey, 2010). Taking the traditional waterfall model as an example
where requirements are gathered from informal sources with the main focus being the coding
phase. Considering that majority of the effort in requirement engineering is put in acquiring,
analyzing and specification of requirements during its analysis phase, with this agile model it
is rendered irrelevant.
Having noted this, it is clear that the Service Oriented Software Development is an
entirely different architectural style compared to the traditional development styles and
therefore requires a new requirement engineering process.
The requirement engineering process for Service Oriented Software Development may
borrow some activities from the traditional model such as modeling, analysis and specification
but shall be executed differently.
This study is focused on identification of the services that coincide with the system
requirements and subsequently modelling the composition from the identified services. The SOA
application can alter its services, web interfaces and workflow if the user changes the
requirements or judging from the system’s current status (Mishra, 2008). The producer centric
architecture on which these services are built on allow the service provider to publish
specifications of the service, before it is launched, in the central registry UDDI where an XML
based messaging language is used to locate them based on the system needs.
The central registry is important as it provides the service provider with data that
specifies the user’s query. The supplier then provides the based on the user demands, however
there is no standard for following any requirement engineering process within this domain.

Objectives
Once the research is complete, we should be able to provide a framework that is
derived from a solution to the issues regarding requirement engineering process in the serviceoriented systems. Moreover, we should be able to validate the proposed framework through a
simulated scenario

Relevance and Significance
In recent times, service-oriented architecture (SOA) has become synonymous to
distributed computing. The services available on the web have greatly increased over the last
decade. HTTP, SOAP, WSDL and UDDI are some of the web services that are widely used
and have adopted SOA in their implementation (Hurwitz, 2009). With SOA becoming more
popular, service-oriented requirement engineering (SORE) will in turn become important.
Research on service-oriented requirement is minimal since it only recently begun. SORE has
its own independent features from SOA. Some of the key features include; SORE is modelbased meaning it is specific to a particular paradigm of software development. SORE is reused oriented; the services, tools and methods are designed to be used in other software or
different versions of the software so long as they meet user requirements. SORE offers
framework-oriented analysis and in comparison, to the traditional model it can be
distinguished through the modelling techniques, development process and runtime behaviors.
Some of the runtime behaviors include publishing, composition, discovery, monitoring and
enforcement. With updated SOA concepts including services and workflow, formal methods
such as reasoning and checking of the model can be applied (Komoda, 2006).

Literature Review
The Service Oriented Software Development is similar to component-based software
development in a number of ways therefore we will analyze the issues of requirement
engineering that occur in Component based software development and whether they are
transferable to Service Oriented Software Development.
In the analysis of this literature we have to keep in mind the original issues affecting
requirement engineering.
1. Challenges of requirement engineering in traditional software development
In the traditional software development approach, the success of the project is largely
dependent on the activities carried out during requirement engineering. The researchers face
issues with the stakeholders in the project. The capturing, modeling and analysis of nonfunctional requirements and the reusability of some requirement models. In addition to this,
conflicting resolutions in the requirements and the requirements changing or evolving are also
challenges they face (Beaton, 2008). The software engineer also has to come up with the
requirements from scratch.
2. Challenges of Requirement Engineering in component-based software development
(CBSD)
The CBSD is entirely different from the traditional life cycle and therefore newer methods of
requirement engineering are applied. The CBSD life cycle involves analysis of requirements,
selection of software architecture, evaluation and analysis, identifying components,
customization, integration of the system, testing and maintenance of the system. In CBSD,
there is no standard process in requirement engineering which proves to be a challenge to the
software engineer during the search and selection of components (Alshinina, 2017). The
components of CBSD have a black box nature allowing them to only be tested for quality
against user criteria as opposed to NFR which can be key in comparing multiple components.
The traditional approach cannot be applied during specification of the existing components
considered in building the new system’s requirements. The search and selection process are
critical in the life cycle of this model. The user requirements require systematic evaluatio n
and testing against the components. Moreover, a flexible and iterative requirement
engineering technique is used to allow for a tradeoff between user requirement and component
selection to take place. During integration, incompatible components may cause the entire
system to fail. The system faces challenges during versioning of the components especially
when the new version does not meet the existing system requirements.
3. Challenges of Requirement Engineering in Service Oriented Software Development
(SOSD)
Literature shows a number of inherited issues from CBSD and the traditional model, however,
there are challenges specific to service-oriented software development. Service discovery,
being the most important phase, requires accurate location of services specific to the user’s
requirements. The system, based on the user requirement specification is automated in order
to support dynamic service discovery. An iterative process is required in refining the
requirement specification. Innovation and creativity are critical in the requirement engineering
process.
Problem Analysis
The issues cited may be categorized into four categories; specification issues, service
discovery issues, knowledge management issues and composition issues.
Specification issues
 These are the issues that are related to what the actual application to be built
should look like, its requirements and the services that fulfill these
requirements. The location of the requirements and how to complete them also
fall under this category.
 The system support of high-level language in specifying the initial
requirements and later converting the requirements into formal specification is
a key specification issue.
 Creation of the requirements and being innovative in formulation of the process
in order to maintain the competitive market.
 The heterogenous environments require that the semantic gaps be minimal.
 High level of knowledge management for the previous versions in order to
implement system updates as requirements evolve and newer versions of the
service are made available.
 Defining the resulted services as prototypes in order to make the discovery
process more iterative.
Service discovery issues
 This are the issues that arise after the specifications are complete. The search
for services that meet functional and nonfunctional requirements are sorted.
They include
 The automated and runtime discovery issues
 The generation of queries from formal specifications
 Testing whether the resulted services meet the quality set through NFR and QR
testing.
 Defining the resulted services as prototypes in order to make the discovery
process more iterative.
Knowledge Management issues
 Knowledge from previous versions and composition is required in order to
understand the functionalities of service. This knowledge assists in
specification and discovery.
 Managing knowledge of previous specification that are used for service recomposition when new versions of the service are made available and
classification of services based on their functionality in order to reduce time
spent searching are the major knowledge management issues. `
Composition issues
 Services are discovered based on their individual functionality and therefore it
is important to analyze whether they would work in a work flow. Composition
issues are mainly related to this flow of components within a system. They
include
 The management of deadlock when the services are interdependent on one
another in order to complete their functionality.
 The re-deployment and re-designing of the entire composition when there are
new versions of the service available or the requirements have evolved.
Work done so far
service oriented software development is continuously being researched within the
research community. Different perspective of the software development paradigm have been
raised and methods, techniques and tools have been proposed by research teams and different
projects. Some of the research teams and projects include;
Service Centric System Engineering project. (SeCSE)
The SeCSE aimed at creating a free and pen source tools, techniques and methods to
be utilized by service providers and system integrators. The program targeted development of
service centric applications through support in terms of cutting the financial implications and
providing dependable services. They incorporated requirement engineering in three phases,
that is, design time discovery, early service discovery and run time discovery.
Software Engineering for Service Oriented Overlay Computers (SENSORIA)
With a more holistic focus on the SDLC in Service oriented paradigm, SENSORIA
main objective is to develop a new approach to the service-oriented software engineering.
This is achieved through the foundation theories, techniques and methods.
IBM Service Oriented Architecture.
The IBM modeling architecture is an end to end paradigm for creation of serviceoriented architecture solutions. IBM provides guidance through identification of service. The
system resembles the identification of objects in object-oriented software development
(Walker, 2007).
Service Oriented Requirement Engineering workshops (SORE)
The SORE workshop held in 2004 and 2007 with the goal of gathering the research
community to share ideas and knowledge on requirement engineering required for serviceoriented system.

Approach
Having identified the issues and challenges, the first step is identifying a framework
that will facilitate the requirement engineering process with consideration of solutions to the
problems cited. I would have to identify the impact of these issues and challenges and the
resulting impact of the proposed solutions.
Once this is done, generating an experimental scenario in which the developed
framework is tested and validated. The validation should be executed from different
perspective such as the service provider or the service consumer.
It is important to not that establishing a test environment is difficult as the deployment
environments are distributed. The experimentation may be rather costly because of the
heterogenous hardware and software. Alternatively, a test environment that mirrors the key
aspects and offers alternatives for the missing aspects may be used.
The test environment shall be populated with the following
A suite that has all the testing tools required to manage test, validate the conformance
and analyze the overall runtime functionality and performance.
Sufficient data to serve as test data in the associate database.
An end to end thread that will be used to determine the orchestration of service.
A means to simulate the services which would not have been developed.

References
Alshinina, R. &. (2017). Performance and challenges of service-oriented architecture for wireless
sensor networks. Sensors, 17(3),, 536.
Bano, M. &. (2010). Issues and challenges of requirement engineering in service oriented
software development. In 2010 Fifth International Conference on Software Engineering
Advances (pp. 64-69). IEEE.
Bano, M. I. (June 2010). Thesis proposal on" Requirement Engineering Process for Service
Oriented Software Development. Proceedings of the 11th International Conference on
Product Focused Software (pp. 84-87). IEEE.
Beaton, J. J. (2008). Usability challenges for enterprise service-oriented architecture APIs. IEEE
Symposium on Visual Languages and Human-Centric Computing (pp. 193-196). IEEE.
Hurwitz, J. S. (2009). Service Oriented Architecture (SOA) for Dummies. John Wiley & Sons.
Komoda, N. (2006). Service oriented architecture (SOA) in industrial systems. . 4th IEEE
International Conference on Industrial Informatics (pp. 1-5). IEEE.
Mishra, D. M. (2008). Successful requirement elicitation by combining requirement engineering
techniques. First International Conference on the Applications of Digital Information
and Web Technologies (ICADIWT) (pp. 258-263). IEEE.
Pandey, D. S. (2010). An effective requirement engineering process model for software
development and requirements management. International Conference on Advances in
Recent Technologies in Communication and Computing ( (pp. 287-291). IEEE.
Tsai, W. T. (March 2007). Process specification and modeling language for service-oriented
software development. 11th IEEE International Workshop on Future Trends of
Distributed Computing Systems (pp. 181-188). IEEE.
Walker, L. (2007). IBM business transformation enabled by service-oriented architecture. IBM
Systems Journal, 46(4), 651-667.