Information Technology Reference
In-Depth Information
Table 2.
Design elements that support requirements listed in Table 1
ID Element Description
RE1 RE2 RE3 RE4 RB1 RB2 RB3 RB4
A Simple IKMI
B1 OpenLDAP based IKMI
B2 Active Directory based IKMI
B3 Oracle Identity Directory based IKMI
C Ad-hoc SSO
D Network Intrusion Detection System
E Common application gateway for External
Boundary Protection System
F Centralized Policy Decision Point (PDP)
G Application-based
solution
for
External
Boundary Protection System
Each element in this table can support (or fulfill) requirements listed in columns. To prevent useless
redundancy, some elements are exclusive to due to functionality overlapping (
e.g.,
A, B1, B2 and
B3 are mutual exclusive each other).
and a sequence number. There are compulsory requirements (
i.e.
they are es-
sential at the time the system is designed) and optional ones (
i.e.
they can be
ignored at present, but might be critical sometime in the future). Solutions for
these requirements are listed in Table 2. Each solution has an IDentifier, a short
description and a checklist of requirements that it can fulfill.
3 Modeling Requirement Evolution
In this section, we describe how we model evolution, which essentially affects to
any further analysis. We capture evolutions by classifying them into two groups:
controllable
. Furthermore, we include in this section the game-
theoretic account for probability.
and
observable
3.1 Evolution on Requirement Model: Controllable and Observable
Stakeholder requirements, mostly in textual format, are their wishes about the
system-to-be. Analyzing requirements in such format is dicult and inecient.
Designer thus has to model requirements and design decisions by using various
approaches (
e.g.,
model-based, goal-based) and techniques (
e.g.,
DFD, UML).
Generally, a requirement model is a set of elements and relationships, which
depend on particular approach. For instance, according to Jackson and Zave [30],
model elements are
Requirements
,
Domain assumptions
,
Specifications
; in a goal-
based model (
e.g.,
i*), elements are goals, actors and so on.
Here we do not investigate any specific requirement model (
e.g.,
goal-based
model, UML models), nor go to details about how many kinds of element and
relationship a model would have. The choice of a one's favorite model to represent
these aspects can be as passionate as the choice of a one's religion or football
team, so it is out of scope. Instead, we treat elements at abstract meaning, and
only be interested in the satisfaction relationship among elements.
