Reuse Oriented Requirement Engineering

S.K. Jha Yogesh Singh Rathore

Amity Institute of Information Technology Amity School of Engineering and Technology
Email:shambhukjha@yahoo.com Email: ysrathore@aiit.amity.edu
Mobile: 9810625752 Mobile: 9891664816

ABSTRACT
Software reuse is the process whereby an organization defines a set of systematic operational
procedure to specify, produce, classify, retrieve and adapt software artifacts for the purpose of
using them in its development activities for different software applications. Component Based
Development (CBD) and software reuse has been a longstanding goal in IT environments and
across industry as a means to lower software costs, development time and risk and better quality.
Commercial component libraries abound, and some IT organizations have been able to implement
and realize returns through their own component factories. Web services and Service Oriented
Architecture (SOA) represent a further evolution of the software reuse quest -evidence of the
pressure to move from reusable technical functions to reusable business functions. The necessary
next step in this journey is to facilitate the evolution and ongoing success of reuse based
requirement development, traceability, and component reuse activity to weave the best practices
and foundations for reuse into the Requirements Development. Bringing the reuse agenda into the
requirement development phase opens revolutionary opportunities for SDLC process
improvement, better business control of technical results, and better alignment of technology
spending with investment return goals of the executive office. This paper will explain the role of
reuse activity in requirement development, the constraints of reuse and future of reuse based
requirement development.

Key Words: Component Based Development (CBD), Requirement Engineering, Reuse,

Requirement Interaction management

1. INTRODUCTION
Reusability can be introduced at different phases in the software development life cycle, from
requirements to design, to deployment; and at different granularity from subroutine libraries to
frameworks to application servers. The higher the level of abstraction at which reuse takes place,
the greater the benefit, as is demonstrated by the extensive use of frameworks in contemporary
development. The largest granularity of reuse incorporates a very high level of abstraction such as
the integration of complete products into a complex system. The fact that there is so much in
common among numerous applications in a domain is what led to the development of
frameworks, which embody design, implementation and the documentation for how to use
the framework. Frameworks, especially domain-specif ic ones, provide functionality that is
common to a set of applications. Thus the user of a framework is also implicitly reusing the
common requirements that led to the framework. But these common requirements are usually the
result of examining the individual requirements of a number of products, not from any
systematic effort at requirements reuse. That said, frameworks are still the most common form
of achieving requirements reuse at present. When reuse practices are integrated into the RDM
(Requirement Development Management) discipline, the result is Reuse Based RDM (RBRDM).
The RBRDM combines and augments the best practices of classic RDM, Component Based
Development (CBD), and Object Oriented Analysis and Design (OOAD).The methodology
revolves around several high-level activities shown below— Define, Refine, Reuse, and Repeat.
Define and Refine refers to the activities associated with creating requirement-related assets.
Reuse and Repeat are activities associated with reusing the previously defined assets to create
repeatable and predictable results.
 Fig 1 Define, Refine, Reuse & Repeat

Requirements reuse can be defined as the process of analyzing, elicitating and managing
requirements at a suitable abstraction level so that they can be reused in new systems.
Requirements Interaction Management.(RIM) was first introduced by W. Robinson as “the set
of activities directed towards the discovery, management, and disposition of critical
relationships among a set of requirements”. One has to consider that there are parameterized
requirements that need specific values, that is, they are really “new” requirements. Therefore
the big question is how to ensure that the values that are assigned to the parameterized
requirements or the new requirements that are added to the specification will not interact with
the already existing requirements? This can only be ensured by continuously analyzing the
requirements for any interaction that might occur. Furthermore, requirements evolve over
time, so the process of interaction management must be continuous. Requirements interaction
management (RIM) addresses the question how reused requirements might interact with each
other in a common environment. Several problems caused by neglecting RIM when building a
new system using reusable requirements.

2. AN APPROACH TO REQUIREMENT REUSE, BASED ON FORECAST OF

USER NEED
The elementary idea for requirements reuse is based on assumption, that the problems and
needs of different people should be very similar at the case if they perform similar tasks in the
similar environment and they use similar tools. Undoubtedly there is a fair amount of other
factors (such as user character type, experience, competence to perform specific tasks and
etc.), that make influence to user needs, however those three factors, mentioned above are
most important, as they reflect relatively objective and steady user needs. In order to be more
precise, instead of term “user” term “Requirements Source (RS)” can be used, which is more
general and can be used to define any type of stakeholder. Formally, the state of RS defines in
following way:
s= {(task, env_constraint, tool_ property)},
Here: taskє T, env_constraintє C, tool property є P, srs є S
T - The set of all possible tasks, performed by requirements sources;
C - The set of all possible environmental constraints that make influence to realizations of tasks
(for instance: temperature, pressure, humidity and etc.);
P - The set of all possible properties of all possible tools, used to support tasks of requirements sour-
ces;
S - The set of all possible states of requirements sources, S є P (T × C × P)
The key principle to forecast the needs of the requirements source
All possible states of requirements sources are identified and stored in knowledge base. At the end of every
project the set of consistent, validated requirements specifications is known, so it can be stored in knowledge
base also and related to corresponding SRS with some degree of uncertainty, which is dynamically recalculated
every time new project is finished. Let define the possibility of j-th group of requirements specifications (rgj) to
be appropriate, when RS is in state s as g(s, rgj). It could be calculated following way:
n
g(s, rgj) =∑ p (s, sk ).t ( sk, rgj ),
k=1
Here:
n - An amount of available states;
t(sk, rgj) - the probability of j-th rsp group when requirements source is in state sk;
p(s, sk) - the degree of similarity between state of given RS (s) and some available state (sk),
stored in the knowledge base.
Forecasted, the most probable group/groups of specifications are that, for which function
g(s,rgj) has maximum value, i.e.:
Forecasted _rg(s) є {rg : RG | max g(s,rgj)},
j є{1…..m}
Here: m- an amount of available groups of requirements specifications.

One of the challenges in the phase of forecasting of user needs is the determination of
similarity
between different SRS. Different concepts are related with each another in different ways. In
order to have precise information about RS, its state should be explicitly modeled; however it
is also not acceptable, since explicit modeling is quite difficult and time consuming activity.
Instead of that elicit only information about top most tasks (being computerized), performed
by RS and relate them to environmental constraints and tools, used in the process of execution
of tasks. There is no need to model problem domain explicitly, so the amount of efforts in
knowledge acquisition and problem domain modeling phases is reduced. The comparison of
two states can be performed just calculating the percentage of common elements of two sets,
corresponding to these states, i.e. the similarity of two states (s and sk) can be expressed
following way

P(s, s k) = # (s k ∩ s)
----------------
# (s k υ s)

3. THE NEW ROAD TO REUSE

A much more effective practice is to reverse the bottom up process and drive reuse from the
top. In other words, Define, Refine, and Reuse requirements, and then drive the reuse into the
complementary disciplines of the development process and their related artifacts. A key to
driving reuse at the requirements level is identifying and categorizing common business
activities. This focus produces common and thus reusable requirements. Reusable
requirements in turn identify reusable and common functionality. These sets of common
functionality are the basis for reusable software components—software components that can
be traced back to the requirements dictating their functionality and value. Reuse at the
requirements level forces analysts to apply some of the same practices that OO designers use
in modeling, such as encapsulation, aggregation, and abstraction. In addition, analysts will
expand their craft, searching for commonality and opportunities to combine and categorize
requirements. In some larger organizations, this could even justify a specialized role - a reuse
harvester, an option for which RBRDM provides.

Fig2: ReFig2: Reuse Based Requirement Meta Model.

Requirement: A requirement is an element of information, a constraint, or an action needed to

properly perform some task or business activity. A requirement may be specified in a number
of forms such as a use case, a UML diagram, or a simple atomic specification of an action or
constraint.
Requirement Set: A requirement set is a group of one or more logically related requirements
which can be treated as a complete entity relating to a business activity. A requirement set can
stand alone (i.e., be identifiable from a business view) and always has business value.
Requirement Reuse Repository: A requirement reuse repository is the mechanism that
supports the ability to store, categorize, search and retrieve requirement sets in whole or in
part. Conceptually the repository could just be a folder.

Fig3:
Requirement Development Management

4. REUSE BASED REQUIREMENT DEVELOPMENT METHODOLOGY:

The RBRDM combines the best practices of classic RDM methods, Component Based
Development practices, and OOAD. The activities on the right side of the diagram represent
the Define and Refine activities of RBRDM, while the activities on the left represent the Reuse
and Repeat activities. When an analyst develops requirements, they are organized into
requirement sets and published to the reuse repository. Over time, the repository accumulates
requirement sets for many of the key activities of the business. On future projects, the first step
in requirements development becomes consulting the repository to identify relevant business
activities. These business activities are retrieved from the repository into the requirements
development environment in whole or in part as versioned requirement sets. Retrieved
requirements can be updated to reflect distinctions of the current project as and when required.
Updates to base requirement sets may be republished to affect other projects or the tailored
current set can be published as branches from the reused base sets. As coding, unit testing,
system testing, and deployment reveal issues, those issues can be translated into requirements
updates, which, when captured in the reuse repository, ensure that future instances of similar
business activity implementation become more robust.

5. SUCCESS AND FAILURE FACTORS IN REUSE MANAGEMENT

Reuse does not happen spontaneously. There are quite a lot of things that are likely to go
wrong when they are not addressed explicitly. Fortunately, lessons about this have been
accumulated over the years. The first set of lessons addresses conditions that need to be
satisfied to ensure that there is a potential for reuse. These conditions help to determine
whether reuse is possible in a given context.
• This software must belong to a focused and narrow domain that has considerable
commonality. The commonality in the domain should be identified through domain analysis
and captured by (product line) architecture.
• A large volume of software must be developed.
• The reuse program must be planned over a long period of time in order to amortize
cost of new procedures and to populate the reuse repository
• Introduce reuse in an incremental manner rather than as big-bang. Select a few pilot
projects that look promising for starting reuse.
• Establish development processes that support reuse.
• Organize training for staff
• Create incentives for individual engineers for doing reuse
Once an organization is doing reuse, the following advices help to continue doing reuse in a
fruitful manner:
• Apply strict quality criteria for accepting assets in the reuse library.
• Collect reuse metrics in order to manage reuse. A reuse program should be driven by
business objectives.
• Keep track of technological developments to avoid obsolescence.

Pitfalls and Obstacles to Reuse

Despite the benefits promised, there are a number of obstacles that stand in the way of the
adoption of reuse based software engineering. These obstacles are of the following types:
managerial & organizational, economical, psychological, legal, and also technological. These
categories are not strictly disjoint, but we follow this structure for ease of explanation.

Managerial and Organizational Obstacles

• Lack of management support: Management is not willing to invest in the introduction of
reuse. This may be due to lack of money for the up-front cost or lack of human resources.
• Lack of organizational incentives: Producing software for reuse requires more effort than
producing software for single use, hence is more expensive. Project managers are often
reluctant to invest in a comprehensive reuse program because the benefits of making assets
reusable often accrue to projects outside their realm of responsibility. Unless a business unit is
compensated for the cost of providing reusable software, it will avoid making it.
• Organizational Inertia: It is difficult to change the way an organization works. The wider
the scope of the reuse program, the more effort it will take to get all involved to support the
reuse program. Overcoming this inertia requires coming up with a good business case for
reuse.
Economical Psychological Legal obstacles
• Investment hurdle: introducing a reuse program first incurs cost .The potential benefits are
obtained only after some period of time passes. To compensate the extra efforts of the reuse
groups, appropriate taxation or charge-back schemes need to be invented
• A psychological affect that influences the adoption of new technology is the “Not Invented
Here”-syndrome. This syndrome is fuelled by several factors:
- Fear of the unknown
-Engineers feel hindered in their creativity and independence if they are urged to reuse
software they did not develop themselves.
• Liability: Often components are sold without liability for the seller. This means that the
buyer/consumer of the component takes on the risk of cost incurred from failure of the
component.
Technical Obstacles
• Given a problem, it is difficult to find suitable assets that can potentially be used to solve this
problem. In essence a problem description needs to be matched with a solution description.
Generally, the problem has many different degrees of freedom that can be exploited in a
solution. No methods have crystallized that can bridge this gap. Existing approaches are based
on classifications, keywords, formal specifications. Related to this is the lack of methods for
cataloguing and matching assets. In matching assets, perfect matches hardly ever occur and it
is difficult to determine when a match is good enough. This also involves balancing the degree
of mismatch indifferent characteristics of a component. For instance, it may be the case that a
component may match well with requirement A, but not match well with requirement B. How
does this compare with a component that matches these requirements in a converse manner?

6. CONCLUSION:
RBRDM is a revolutionary methodology that combines and augments the best practices of
classic RDM discipline, Component Based Development, and Object Oriented Analysis and
Design, to achieve an unprecedented increase in the successful delivery of software projects
and systems that match customer intent, within budget and delivery constraints. Some of the
key concepts that are essential to RBRDM include:
1. Requirements optimization which is enabled by the Define, Refine, Reuse, and Repeat
method
2. Harvesting and populating requirements for reuse from existing requirement artifacts
3. Driving reuse throughout the SDLC and its artifacts
4. Improving the analyst role for effective requirements reuse
5. Enabling the organization to utilize a reuse repository
6. Enhancing existing RDM discipline to embrace requirements reuse .
Substantial tangible benefits to the RDM process occur when implementing the RBRDM
Methodology. They include:
1. Applications have greater success of being delivered on time, in budget, in fulfillment of the
project intent of the customer.
2. Reduces cost and time to market, while improving quality, by reusing vetted requirement
assets, which prevents errors and development rework
3. Requirement sets become usable by disparate project teams
4. Leverages subject matter expertise across the product line, development group, or enterprise
lead directly to reuse of other valuable SDLC assets such as test cases, models , and code
Further matures the RDM process by applying OOAD best practices to the RDM process

References
1. Gill N. S. (2003) “Reusability Issues in Component Based Development”, ACM SIGSOFT
Software Engineering Notes. Vol 28, Iss 4.
2. Nasib Singh Gill, “Importance of Software Component Characterization For Better
Software Reusability” ACM SIGSOFT Vol. 31 No. 1
3. Allen Paul (2001): The State of the Practice. Component Development Strategy Journal,
March 2001, Vol XI, No. 3
4. Oscar Lopez, Miguel A..Laguna , Franscisco J.Garcia “Reuse Based Analysis And
Clustering Of requirement Diagram”.
5. Stephen Brown, Mac Felsing, Process exchange, Inc. “reuse Based Requirements
Development & Management, the Reuse Revolution of RDM”.
6 Victor R. Basili “Maintenance =Reuse –Oriented Software Development”, Institute for
Advanced Computer Studies ,Department of Computer Sciences , University of Maryland.
7 Mohamed S.Shehata, Armin Eberlein, H.James Hoover “Requirement reuse and Feature
Interaction Management”..
8 Erdvinas Prednikas “Requirement Reused Based on Forecast of User Needs”,Information
system department, Kaunas University of technology.
9. Han, Jun (1998): “Characterization of Component” In proceedings of International
Workshop on Component Based Software Engineering.
10. Itkonen Juha: “Measuring Object-Oriented Software Reusability”