Below is an excerpt from a system design document for an accident management system. It is a natural language description of the rationale for a relational database for permanent storage. Model this rationale with issues, proposals, arguments, criteria, and resolutions:

One fundamental issue in database design was database engine realization. The initial
nonfunctional requirements on the database subsystem insisted on the use of an object-
oriented database for the underlying engine. Other possible options included using a
relational database, a file system, or a combination of the other options. An object-
oriented database has the advantages of being able to handle complex data relationships
and is fully buzzword compliant. On the other hand, OO databases may be too sluggish
for large volumes of data or high- frequency accesses. Furthermore, existing products do
not integrate well with CORBA, because that protocol does not support specific
programming language features such as Java associations. Using a relational database
offers a more robust engine with higher performance characteristics and a large pool of
experience and tools to draw on. Furthermore, the relational data model integrates nicely
with CORBA. On the downside, this model does not easily support complex data
relationships. The third option was proposed to handle specific types of data that are
written once and read infrequently. This type of data (including sensor readings and
control outputs) has few relationships with little complexity and must be archived for
extended periods of time. Files offer an easy archival solution and can handle large
amounts of data. Conversely, any code would need to be written from scratch, including
serialization of access. We decided to use only a relational database, based on the
requirement to use CORBA and in light of the relative simplicity of the relationships
between the system’s persistent data.

Key: I[1] = issue 1, P[1] = proposal 1, A[1] = argument 1, C[1] = criterion 1,
R[1] = resolution to I[1].
I[1]: Which database engine realization?
P[1]: OO DBMS.
A[1] for P[1]: Can handle complex data relationships.
A[2] for P[1]: Buzzword compliant. (see C[1])
A[3] against P[1]: Sluggish for large volumes of data or high-frequency accesses.
A[4] against P[1]: Existing products do not integrate well with CORBA. (see C[2])
P[2]: Relational DBMS.
A[5] for P[2]: More robust engine than OO DBMS.
A[6] for P[2]: Higher performance characteristics.
A[7] for P[2]: Large pool of experience.
A[8] for P[2]: Some relational DBMS integrate well with CORBA.(see C[2])
P[3]: File system
A[9] for P[3]: Good for serial data with simple relationships, including sensor data.
A[10] against P[3]: Need to rewrite many programs to provide similar functionality
than a DBMS, including serialization of access.
P[4]: Combination of P[1,2,3].
C[1]: Database subsystem should use an OO database.(Pseudo-requirement)
C[2]: Needs to co-exist with CORBA. (Prior design decision)
R[1]: P[2], because of C[2] and simplicity of relationships of system’s persistent data.