A Web-Based Requirements Analysis Tool

Annie I. Anton
Eugene Liang
Roy A. Rodenstein
fanton,eugene,royrod@cc.gatech.edug
College of Computing
Georgia Institute of Technology
Atlanta, GA 30332-0280

Abstract Analysis Method (GBRAM) and summarizes our ex-

The Goal Based Requirements Analysis Tool periences in applying the method to a relatively large
(GBRAT) is designed to support goal-based require- example. Our experiences with scenario analysis [4]
ments analysis. The tool provides procedural support demonstrated that scenarios are useful for uncovering
for the identication, elaboration, renement and or- and elaborating requirements, and for answering ques-
ganization of goals to specify the requirements for soft- tions that are not easily answered using other tech-
ware based information systems. GBRAT employs in- niques. These studies prompted us to further develop
teractive Web browser technology to support the col- and validate our strategies to identify and construct
laborative nature of requirements engineering. goals. We are currently prototyping GBRAT to sup-
port the process of identifying and capturing goals,
responsible agents, stakeholders, constraints, goal ob-
1 Introduction stacles and scenarios as well as for specifying relation-
ships between goals and subgoals. We are applying the
The World-Wide-Web (WWW) has emerged in re- method (GBRAM) and tool (GBRAT) to electronic
cent years as a standard medium to display informa- commerce applications as we discuss in this paper.
tion. The ability to support the collaborative nature
of requirements engineering using interactive WWW Goal Analysis
technologies led us to develop our Web-based Goal-
Based Requirements Analysis Tool (GBRAT). Using Goals are high level objectives of the business, orga-
GBRAT, project members can work collaboratively to nization or desired system. They are a logical mech-
specify goals for software systems. The specied goals anism for identifying, organizing and justifying soft-
can be viewed and modied by other project members ware requirements [1]. Using the Goal-Based Require-
located anywhere around the world. ments Analysis Method [1], we identied the func-
This paper discusses some aspects of GBRAT in tional modules for GBRAT and determined the func-
the context of its use in a real study involving the tional requirements by operationalizing the goals (Op-
specication of requirements for Web-based applica- erationalization is the process of dening a goal with
tions. The tool is useful to identify, elaborate and enough detail so that its subgoals have an operational
organize goals for requirements specication. Section or functional denition). The result of this analysis is
2 provides a brief overview of our previous work. An best observed in the GBRAT prototype.
overview of the tool and its use on a real study are Current goal-based methods do not provide ana-
provided in Section 3. A summary and conclusions lysts with sucient strategies for knowing how to ini-
are discussed in Section 4. tially identify goals or how to extract goals from the
available information sources. Furthermore, tool sup-
port is lacking to support these methods. The objec-
2 Previous Work tive of the underlying research is to develop a catalog
of heuristics and questions to guide analysts as they
In a previous paper [1] we cite the need for strate- identify and specify system and enterprise goals. The
gies for the initial identication and construction of objective of GBRAT is to provide analysts with the
goals. We discussed goals from the perspective of two procedural support they need to be able to analyze
themes: goal analysis and goal evolution. That paper and rene goals. GBRAT will support and guide an-
provides an overview of our Goal-Based Requirements alysts as they identify, capture and structure require-
ments information in the form of goals. of the analysts working on a given project. From
within a specic project repository, we can create new
3 GBRAT goals or view the previously specied goals using three
lters: the maintenance and achievement goal lter,
GBRAT supports goal-based requirements analy- the agent lter, and the total order lter. The fol-
sis. The tool serves as a medium for project team lowing sections discuss how goals are created and how
members, working from dierent locations, to partici- the ability to view the specied goals via the dierent
pate in the decision-making processes which permeate available lters is helpful to analysts.
requirements engineering. Team members are able to
work collaboratively on new ideas, discuss issues, and
make decisions about system goals despite their geo-
graphic and time dierences.
3.1 Users
The typical GBRAT user is an experienced require-
ments engineer with a considerable working under-
standing of the goal-based method, the WWW and
Web-based applications. We assume that GBRAT
users will work from existing diagrams, textual state-
ments of need and/or additional sources of informa-
tion, such as transcripts of interviews with stakehold-
ers to identify and specify the goals of the desired sys-
tem. After the analyst/elicitor has gathered all avail-
able information about the desired system he or she
can then extract goals from these information sources
and specify them using GBRAT as described below.
3.2 System Features Figure 1: Project Repositories
GBRAT features enable users to create project
repositories and, specify goals, view goals from several
perspectives and order goals. The examples provided Creating Goals
in this paper to illustrate these features are part of an
ongoing requirements reengineering of a Web server Goal creation requires users to complete a form, as
that supports various consortium member organiza- shown in Figure 2, to specify the goal name, classi-
tions participating in electronic commerce. The Web cation and responsible agent(s). Users must specify
server must support secure payment and transactions, a goal name, such as, \AVOID duplicate purchase"
dierent access levels, membership and seminar regis- as shown in Figure 2. Goals are named in a stan-
trations, as well as project and proposal status track- dardized subset of natural language in which the rst
ing. Several examples from this study are employed word is a verb that describes the kind of goal being
to demonstrate how GBRAT enables us to easily iden- named. For example, AVOID denotes one kind of goal.
tify synonymous goals and manage traceability via the Goals of this kind are satised for as long as their
Web. Although, we are currently using GBRAT to es- target conditions remain false. Each goal is classied
tablish the requirements for Web-based applications, either as an achievement or as a maintenance goal.
its use is certainly not limited to this kind of system. Achievement goals are objectives of the system and
It can be used for a more general range of information are named by the verbs MAKE and KNOW. For example,
systems involving multiple stakeholders. a seminar registration system may need to satisfy the
The method (GBRAM), though not the tool goal of enrolling consortium members in the seminar
(GBRAT), has been used on a range of problems, in- before the actual seminar begins. The object of the
cluding a business process reenginering project for an goal is seminar registration and so the goal would be
Air Force Base [1] and the requirements specication named MAKE member registered. Maintenance goals
for GBRAT [2] [3]. are those goals that are satised while their target con-
dition remains true and are therefore named using the
Project Repositories verbs MAINTAIN, KEEP, AVOID and ENSURE. They tend
to be operationalized as actions that prevent certain
Goals concerning a given system are stored in a states from being reached. The goals in Table 1 are
project repository. Each project repository has a spec- examples of maintenance goals.
ied project name and description as well as the name
 bullet (labeled M) in the left hand column, users can
modify the selected goal. The second column (la-
beled C) noties the users of the existence of any
constraints on each goal. A constraint places a condi-
tion on the achievement of a goal. For example, in
Figure 2, Member must be able to ascertain if
product was previously purchased places a condi-
tion on the achievement of the goal AVOID duplicate
purchase. In the third column (labeled Name) the
user can select a goal by name in order to view all the
properties of the goal (This view is shown in Figure ??
and discussed in more detail below). The next three
columns list the agents responsible for each goal, the
goal obstacles and scenarios (respectively). Goal ob-
stacles are behaviors that prevent or block the achieve-
ment of a given goal. Scenarios are behavioral descrip-
tions of a system and its environment. The bullets in
the far right column (labeled D) allows users to delete
goals.

Figure 2: GBRAT Form to Create Goals

Goal Classication Agent
ENSURE secure transaction Maintenance Server
ENSURE information updates managed Maintenance Server

Table 1: Maintenance Goal Example

Goal Traceability
Hypertext links enable traceability to take various
forms in GBRAT. When a user creates a new goal, the
user must specify the name of the information source
from which each goal was identied. In Figure 2, the
source is an email message from Kenji Takahashi dated Figure 3: Viewing Goals by Name
9 Feb This ensures that each goal can be traced back
to its place (i.e. document) of origin. It also enables Viewing Goals by Agent
analysts to easily identify goals which may have been
extracted from more than one information source so Many times analysts need the ability to look at all
that any similarities and dierences can be immedi- of the goals for which a particular agent is responsi-
ately reconciled. Goals may also be traced back to the ble. For each agent, the relevant goals he or she is
responsible agents. Further enhancements to GBRAT responsible for are displayed in the same format as
will include traceability among obstacles and scenar- described above. However, a dierent table is created
ios as well as pre-conditions and post-conditions. for each agent. For example, Figure 4 shows a few of
the achievement goals which a consortium member is
Viewing Goals by Name responsible for in the electronic commerce web-server
system. More than one agent can be associated with
Goals may be viewed by various lters in GBRAT. a goal. Our experience with GBRAT has shown that
When viewed by name, the goals are listed alphabet- when the same goal is identied from two dierent
ically and displayed in a tabular format, as shown in sources, the only dierence between the two goals is
Figure 3. GBRAT allows users to view either achieve- often the responsible agents. GBRAT noties the user
ment or maintenance goals by name. The goals in when this occurs and allows the user to merge the two
Figure 3 are achievement goals. By clicking on the goals into one goal with multiple responsible agents.
 Figure 5: Viewing Goals by Precedence Relation

duplicate purchases it includes, for each goal, its

name, responsible agent(s), constraints, obstacles, sce-
narios, as well as any pre- and post-conditions.
Implementation
Having described what GBRAT does, we now de-
Figure 4: Viewing Goals by Agent scribe how it is implemented. The WWW provides
a consistent user interface and the ability to incorpo-
rate a wide range of technologies and document types.
Web browsers allow multiple users in dierent physi-
Viewing Goals by Precedence Relation cal locations to access information via the Web. These
characteristics played a role in the decision to develop
All achievement goals are related in some way to the GBRAT as a Web-based application. GBRAT allows
other goals in the system. A precedence relation exists analysts working in dierent locations to easily ac-
between goals G1 and G2, when goal G1 must be com- cess the same documents. Netscape oers a consistent
pleted before goal G2. Our main interest in organizing interface across dierent platforms and nonstandard
achievement goals according to their precedence rela- HTML tags. It has built in security capabilities that
tions is to enable analysts to envisage goal operational- enable us to limit access to registered GBRAT users.
izations and renements. GBRAT enables users to GBRAT is compliant with Web browsers; the capabil-
specify precedence relations among achievement goals ity to establish clearly visible links from one document
so that a total ordering can be produced for the sys- to another as well as within documents is supported
tem goals. Once the user has specied the precedence via hypertext links.
relations, GBRAT assigns a number to each goal and The cacheing capability of WWW browsers requires
displays the goals according to that ordering. Fig- repeated reloading of modied pages. However, by
ure 5 shows the ordering produced by GBRAT for using PERL scripts to retrieve information from the
goals based on the ordering specied by the user. This goal database, pages are dynamically generated and
view of the goals is helpful. The easy identication of the user is assured that all information displayed is
synonymous goals in clusters facilitates an analyst's always up-to-date. Goals and goal properties are en-
ability to recognize those goals which need to be rec- tered in natural language fragments. GBRAT easily
onciled, merged or elaborated. manipulates and scans large amounts of text as ev-
idenced by the ability to display goals via dierent
Viewing a Goal's Properties lters as shown in Figures 2, 3, 4 and 5.
Viewing Goal Hierarchy Relationships
Goals have 7 properties, as shown in Figure ??. A
link is provided from each goal in a table to the goal Drag-and-drop seemed the most intuitive way to
record itself. Figure shows this view for the goal AVOID build a visualization of the relationships among goals.
 it is highlighted in the goal list at right, so that the
user will know that goal has been used at least once.
Lastly, when the user is not dragging a goal over a
subtree, the status bar displays the name of the last
goal that the user added a subgoal to, so that if the
hierarchy becomes large and/or dense the user will not
lose h(is)(er) place.
Each subtree in the hierarchy can be collapsed to
save space, as well as to abstract away its subgoals.
An arrow appears to the left of each subtree, i.e. leaf
nodes do not display an arrow, as they have no chil-
dren. The arrow changes orientation depending on the
state of the subtree- when it is open and showing its
subgoals the arrow points down; when it is closed, the
arrow points to the right. The arrow is also the place
the user should click in order to open and close the
hierarchy.
By dragging the label for a subtree or leaf, the user
can reposition it. A subtle drop shadow is provided
in these cases, as feedback that the structure is out of
the tree and being dragged. This feedback also occurs
in the tree, as it redisplays itself to show the hierarchy
without the goal being dragged.
Figure 6: Goal Hierarchy If a goal from the goal list at right is dropped on
an invalid area, such as empty space or the trash area,
it simply goes away (though the original remains in
In order to show these relationships, an n-ary tree the list so that it can be used again; this is because
structure can be constructed, with the root being the certain goals, such as 'training,' may be needed more
name of the project (repository) and any number of than once. Ideally, though, a separate goal would be
children at each level in the tree. This allows for show- created for each situation, to preserve the specicity
ing that a particular goal is a subgoal of another, and of requirements). If a subtree or leaf from the tree is
must be completed as a prerequisite of its parent. The dropped in the trash area, it also goes away, in eect
goal list, at right, includes an item labelled 'OR' so removing it from the hierarchy. As before, the goals
that OR relationships among goals may be created- remain in the goal list at right so that they may be
this goal depends on 'goal A' OR 'goal B' being com- used again. If a subtree or leaf is dropped onto empty
pleted. By default, an AND relationship is assumed space, it returns to the level it was originall dragged
for subgoals, so hierarchies that re ect more complex out of, but is inserted as the rst child on that level.
requirements may be built using these AND and OR If a subtree or leaf is dropped onto the same parent
relationships. it was dragged o of, it is inserted as the last child at
In order to make the visualization as malleable as that level. These two positioning features allow goals
possible, to simplify its use and be forgiving of mis- to be arranged in a particular order within subtrees,
takes, it was necessary to allow the dragging not only to show the order that subgoals need to be completed
of goals onto the tree but also leaves and entire sub- in, for example.
trees. This allows repositioning of the goals to re ect The tree exists within a Panner object that turns
changes in the project's structure or subtasks. scrollbars on and o as appropriate, so that the user
Feedback is provided to the user in several ways. may scroll to any section of the tree if the latter grows
First, naturally, the goal is displayed as it is dragged, large. This feature, along with collapsibility, allow for
so that the user can tell they are taking the action eective use of limited space.
of adding a goal to the hierarchy. Second, the goal
is highlighted while it is over an area where it can 4 Summary and Conclusions
be dropped, which helps the user ascertain that they
are adding the new goal exactly where they want to. Goal-oriented methods are attracting research in-
Further, the name of the goal the the user is over (i.e. terest, but there exists little work in the form of tool
the goal that the user would add a subgoal to, where support for these methods. GBRAT supports the col-
(s)he to release the drop at that point) is displayed laborative nature of requirements engineering using in-
in the status bar at the bottom of the screen. After teractive WWW technologies and allows project mem-
a particular goal has been inserted into the hierarchy, bers located anywhere around the world to work col-
laboratively. Ultimately, GBRAT will support the two [3] Liang, E, \Goal-Based Requirements Analy-
stages of our goal-based approach (GBRAM) [1]: sis Tool (GBRAT): Design Document," Ver-
sion 0.3, Georgia Institute of Technology Web
1. Goal Analysis: The process of exploring gathered Page, http:// www.cc.gatech.edu/ computing/
information and then identifying, classifying and SW Eng/ Project/ design doc.html, 14 November
organizing goals. 1995.
2. Goal Renement and Decomposition: The pro- [4] Potts, C., K. Takahashi and A.I. Anton, \Inquiry-
cess of rening the classied goals and decompos- Based Requirements Analysis," IEEE Software,
ing them into functional requirements. 11(2), pp. 21-32, March 1994.
GBRAT currently provides a mechanism for ana-
lysts to capture, classify and organize goal informa-
tion. The ability to specify goal hierarchies oers an
initial approach to goal renement. Future work will
further support the goal renement and decomposition
process. GBRAM calls for the ability to assign prece-
dence relations to each goal in order to organize the
goals accordingly. In its current state, the tool allows
users to reorder goals based on their precedence rela-
tions resulting in a total ordering of the specied goals.
Future extensions will enable users to rene goals by
specifying subgoals with precedence relations assigned
to each goal's subgoals. The use of Web technology
for collaborative requirements engineering is still in
its infancy. GBRAT is oers some minimal support
for dening and specifying goal repositories. By em-
ploying the tool in our work on electronic commerce
applications we are seeking to answer how goals are
used to identify and rene system requirements and
how the method's strategies are used in reengineering
eorts involving a team of analysts.
Problems
The use of the WWW introduces problems linked to
cooperation, information sharing, dierent viewpoints
and networked enterprises.
Acknowledgements
The authors would like to thank NTT for support-
ing this research, Dr. Peter Freeman who directed the
development of GBRAT, as well as, Colin Potts, Kenji
Takahashi, Je Smith and Erik Bataller.
References
[1] Anton, A.I., \Goal-Based Requirements Analysis,"
2nd IEEE International Conference on Require-
ments Engineering (ICRE `96), Colorado Springs,
Colorado, 15-18 April 1996, pp. 136-144.
[2] Anton, A.I., \Goal-Based Requirements Anal-
ysis Tool (GBRAT): Requirements Document,"
Version 0.3, Georgia Institute of Technology
Web Page, http://www.cc.gatech.edu/ comput-
ing/ SW Eng/ Project/ reqts doc.html, 14 Novem-
ber 1995.