Use case methodology discussion

Main Page > Projects > Vancouver Digital Archives > Requirements Analysis > Use Case Methodology > Use case methodology discussion

Use of OAIS

OAIS as primary requirement source

Peter: For our use case work we should start by using only OAIS as a requirement source so that we can map everything we want the system to do back to OAIS.

Peter: As per the discussion in our last meeting OAIS is a bit vague in some areas but I think this is a really important step to ensure that we've got our baseline OAIS Use Cases/Requirements. Evelyn and I discussed this further this week. Once the OAIS use cases are completed we'd like to snapshot those and keep them seperate (e.g. we'll cut-and-paste a UC-1-OAIS page from UC-1) before we do the next iteration of the use cases by adding new, more specific best-practice sources to the existing Use Cases (i.e. by revising UC-1 to add Cairo information). That way we can always easily refer back to the OAIS baseline Use Cases as a seperate, authoritative set after we find ourselves a few iterations deep into the requirements analysis.

Diagrams, not text, authoritative source in OAIS

Evelyn: We've had a few issues arise when the OAIS diagrams do not match the text. For example, Fig. 4-3, Functions of Archival Storage, has two-way arrows between Disaster Recovery and media and Disaster Recovery and backup media, but the text refers only to duplicating digital objects to a physically separate facility. Peter & I discussed this & we feel that when in doubt, the diagrams should be taken as the authoritative representation of the OAIS reference model when it comes to developing the use cases. So in this example the use case refers to Disaster Recovery retrieving the digital objects from backup media if necessary even though the text does not include this step.

Purpose of using OAIS for developing analogue-activity use cases

Sue: Regarding the Preservation Planning Use Case: since it seems to be all analogue activity, how useful will it be for the developers? Or is the purpose of that use Case just so that we can show, by comparing our policies to the model, that we conform to OAIS?

• Peter's reply: Yes, exactly.

Actors

Peter: I think using the OAIS sub-functions as the Actors was the right call because that's how OAIS is doing it and its giving us a nice pure OAIS analysis. For the second iteration where we clean things up and make it more practical one incremental step we could make (to make things a little more logical) would be to change each of the 'verb' actors into 'noun' actors (e.g. 'Receive Submission' becomes 'Submission Receiver', 'Generate AIP' becomes 'AIP Generator', 'Administration>Archival Information Update' becomes 'Archival Information Updater'). That then makes it easier for us to assign real people, manual procedures, software tools or software processes to those roles and interchange them as the system evolves.

Glenn: We've adopted a naming convention for the actors. When referring to actors that come from different functional areas of the OAIS than the current use case, we give the full path to that actor. E.g., when referring to the Generate Report actor while describing an Access use case, we would call the actor Data Management>Gen rate Report. Actors within the functional area of the use case being described can be referred to by their short name. IN the scenario above, Generate DIP would still be just "Generate DIP" when describing an Access use case.

Evelyn:The one thing I'm still wondering about is the use of Management, Manager, Administration or Administrator as an actor. We started out with Management, and then I suggested Administrator and I notice that a couple of use cases use Administrator (e.g. UC-1.3).

In OAIS, Management and Administration are two different functions. Management is defined as "The role played by those who set overall OAIS policy as one component in a broader policy domain" and Administration is defined as "The OAIS entity that contains the services and functions needed to control the operation of the other OAIS functional entities on a day-to-day basis." As with other areas of OAIS, functions and actors are somewhat confused here. Perhaps we should use "Management" and "Administration" as our actors, though, since we are following OAIS as literally as possible.

• Peter's reply: Let's see what comes out of the actual analysis. If a 'Management' actor is never mentioned in the actual text, let's eliminate it from the list. In the meanwhile let's just continue with the use case analysis of the Administration function, naming actors as per our existing practice and we can see if an 'Administrator' actor emerges.

Use case structure

General

Peter: A couple of minor notes related to the Use Case template itself. I'd like to make the following changes:

• rename 'Sub-Requirement' to 'Sub-Use Case'
• rename 'Requirements documentation to 'Documentation'
• post 'Notes' in its own sub-section at the bottom of the page
• reserve the 'Requirements' section for specific functional, metadata,

technical requirements for if/when they emerge

I've made these suggested changes here: http://artefactual.com/wiki/index.php?title=UC-1.1

Evelyn: I like the idea of bolding the actors and providing a contextual link for actors mentioned in use cases that are described in other sections of OAIS.

Level of detail

I think the level of detail you're providing is about right...at least, it's as far down as OAS takes you.

Breakdown into sub-use cases

Glenn: I'm looking for some feedback on how to break down the sub-use cases for Access. It's turning out to be more complex than the diagram suggests. The crux of the problem is that there are two requesting actors (Consumer and Administration) each requesting a variety of things: query responses, report responses, assistance responses, and (finally) dissemination responses (DIPs).

I've tried breaking down the uses cases in a couple of different ways. One way was to divide them by the type of object being requested, independent of who is requesting it. This leads to sub-cases that look like:

UC-6.1 Coordinate query request .2 Coordinate report request .3 Coordinate assistance request .4 Coordinate dissemination request… .n Deliver query response .n+1 Deliver report response, etc.

The other way is to break it down by requesting actor: UC-6.1 Coordinate Consumer request UC-6.2 Coordinate Administration request, etc.

The problem in both cases seems to be that when further detailing the sub-cases, they each typically end up having multiple triggers and/or outcomes (E.g., triggered by request for query, OR request for report, OR request for DIP…; and successful outcome= delivery of result set, OR delivery of report, OR delivery of DIP, etc.)

It seems to me that if you have a generic sub-case UC-0.n, that has multiple triggers A, B and C, and multiple outcomes X, Y, and Z. then what you more likely have are three separate use cases. This seems particularly true if there is a correlation between the triggers and the outcomes: A--->X, B--->Y, C--->Z. I think that when it comes down to translating these into actual requirements, it would be useful for clarity to minimize the number of triggers and/or successful outcomes for each sub-case.

This leads me to the conclusion that the sub-cases should be sufficiently granular so as to minimize the triggers and/or outcomes for each sub-case. This would give something like:

UC-6.1 Coordinate Consumer query request... .n Co-ordinate Consumer Dissemination request .n+1 Co-ordinate Administration Dissemination request, etc.

Another way of handling it would be through lower level cases: UC-6.1 Coordinate Consumer request .1.1 Coordinate Consumer query request .1.2 Co-ordinate Consumer report request, etc.

The first approach leads to a large number of cases at the UC-6.x level, many of which have similar content. This strikes me as being somewhat redundant.

I don't like the second approach. It seems to me that lower level cases should more properly be reserved for (for lack of a better term) "sub-routines" completely internal to a particular use case (E.g., authenticating a user might be described as a step within a use case -the authentication process might need to be broken down into sub-cases). In the access case, what we have are a number of more-or-less parallel threads that pass through many of the second level use cases in Access (Consumer makes a report request, report is obtained from Data Management, report is delivered to Consumer; Consumer makes dissemination request, AIP is obtained from Storage, DIP is generated, DIP is delivered to Consumer; etc.)

All in all, I think I prefer redundancy to trying to organize these threads in a third level of use case. Any thoughts?

• Peter's reply: I agree with your conclusion. This also fits with our approach to stick as closely to OAIS as possible, warts and all, in the first iteration of our Use Case analysis. In the second iteration we can resolve some of these redudancies and clean up the logic.

References

Sue: I reference diagrams only where that was the only place in OAIS that I could relate the action or step to. In other words, I'm using the text as the main reference, but if it doesn't show up in the text and ONLY shows up in the diagram, I'm referencing the diagram. So you'd like us to reference the diagram in every instance where that action/step appears there?

• Evelyn's reply: I see what you mean regarding the diagram vs. the text, & I've noticed that in other parts of OAIS as well. It might be helpful to say "diagram only" for steps that are not referenced in the OAIS text.

Content

Evelyn: Just a couple of tiny things. Sometimes you refer to the diagrams in your references, but that doesn't always seem to be consistent. For example, UC-2.1 step 6 refers to the diagram but it seems to me that other steps should reference the diagram as well for the sake of consistency. Also, I was wondering what happened to "backup media" in UC-2.5? It appears in the diagram but is not mentioned in the use case. Should step 3 of that use case refer to "backup media" in addition to a "physically separate facility"? OAIS is a little confusing on this point, because the diagram and the textual description don't match up all that well. Also, the diagram has a two-way arrow between Disaster Recovery and media, but the use case only describes a one-way transfer of data to Disaster Recovery. Maybe a separate step in the use case should refer to Disaster Recovery restoring the data from backup media to archival storage media in the event of corruption or deletion of the stored AIPs.