| Project: | Fez |
|---|---|
| Internal Release Number: | 1.2.0 Beta |
| Related Documents: |
| Direct Actors: |
User: end-user in any role
System: The system being built
When actors are not listed, assume User is doing it.
Items beginning with "see" indicate that System has presented a new screen.
|
|---|---|
| Stakeholders: | Project Owners and other members |
| Prereq: | User is logged in |
| Summary: | The Administrator install pre-requisite packages and copies the Fez file to the webserver. Initially, the php scripts will need write access to the Fez directories. A setup PHP script is run which writes some files to store inital settings such as the location of the databases and applications on which it depends. |
|---|---|
| Priority: | Expected |
| Use Frequency: | Once |
| Direct Actors: |
Admin: Web-site administrator
|
| Main Success Scenario: |
|
Alternative Scenario Extensions: |
If Fez can't write the configuration files or there is an invalid setting:
|
| Notes and Questions |
|
| Summary: | The Administrator usually doesn't have to add users to the system as they are authenticated through Active Directory. If a user is to have special privileges, they can be added to the Fez user list. They can then be put into certain priviledged groups used within Fez. |
|---|---|
| Priority: | Essential |
| Use Frequency: | Sometimes |
| Direct Actors: | Administrator |
| Stakeholders: | User |
| Prereq: | |
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If the user is already in Fez
|
| Notes and Questions |
| Summary: | An Fez user group can be made to provide authorisation for a group of Fez users. The users may still be authenticated from AD. |
|---|---|
| Priority: | Desired |
| Use Frequency: | Sometimes |
| Direct Actors: | Administrator |
| Stakeholders: | User |
| Prereq: | |
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If the user group is already in Fez
|
| Notes and Questions |
| Summary: | Some users of Fez may want to have an Fez account so they can save searches they have made, comment on research and make annotations. |
|---|---|
| Priority: | Desired |
| Use Frequency: | Often |
| Direct Actors: | User |
| Stakeholders: | User |
| Prereq: |
User must have an email address and pass a CAPTCHA (completely automated public Turing test to tell computers and humans apart) challenge
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If username exists at step 4
If email address exists at step 4
If the password and password confirmation don't match at step 4
|
| Notes and Questions |
The confirmation URL should time out after a few hours. The Fez user created will belong to a default set of Fez groups |
| Summary: | When a user forgets their Fez password, they can re-register using their ability to read their email as a security check. This only works for Fez users - not UQ AD. |
|---|---|
| Priority: | Expected |
| Use Frequency: | Sometimes |
| Direct Actors: | User |
| Stakeholders: | User |
| Prereq: |
User is registered with Fez - it can't obtain their UQ AD password. Logged out of Fez. |
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If at step 4, the email or username is not in the Fez database
|
| Notes and Questions: |
|
| Summary: | All items in Fez including collections and communities can have access restrictions. The restrictions are inherited from parent collections and communities. This is needed so that the repository can have different staff with control of different parts of the repository. |
|---|---|
| Priority: | Essential |
| Use Frequency: | Sometimes |
| Direct Actors: | Administrator |
| Stakeholders: | User, Collection or Community Reviewers |
| Prereq: | Logged in as Administrator
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
|
| Notes and Questions | Possible actions or roles on an item:
Possible credentials
|
| Summary: | As well as creating user groups that have users in them, each user can belong to multiple groups so there is a way to map groups to a user as well (many to many) |
|---|---|
| Priority: | Desired |
| Use Frequency: | Sometimes |
| Direct Actors: | Administrator |
| Stakeholders: | User |
| Prereq: |
Logged in as Administrator
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
|
| Notes and Questions |
There will need to be a list of Fez users but what about AD users - there are a great many AD users, perhaps this feature can only work for Fez users. If the Fez user is also in the AD then you can add AD groups as well as Fez groups, otherwise only Fez groups can be used. |
| Summary: | When an item in the repository has no ancestor credentials, a set of defaults should be used. |
|---|---|
| Priority: | Essential |
| Use Frequency: | Rarely |
| Direct Actors: | Administrator |
| Stakeholders: | User |
| Prereq: |
Logged in as Administrator
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
|
| Notes and Questions: |
|
| Summary: | When a user self registers, their initial group and maybe some other details will need to be set up as well. The Administrator will be able to control what the default group membership is. |
|---|---|
| Priority: | Desired |
| Use Frequency: | Rarely |
| Direct Actors: | Administrator |
| Stakeholders: | User |
| Prereq: |
Administrator logged in
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
|
| Notes and Questions: |
|
| Summary: | The document type XSDs describe metadata formats that are used in Fez. The are formats used for all items and formats used for specialised items such as audio files. |
|---|---|
| Priority: | Essential |
| Use Frequency: | Sometimes |
| Direct Actors: | Administrator |
| Stakeholders: | Library |
| Prereq: |
Logged in as Administrator
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If Editing an exisiting XSD at step 2
If XSD name already exists at step 5
|
| Notes and Questions: |
|
| Summary: | The Administrator can control how metadata is entered into forms in Fez. XSD documents describe the metadata files. Fez makes a mapping between the XSD files and HTML form elements such as text boxes. |
|---|---|
| Priority: | Essential |
| Use Frequency: | Sometimes |
| Direct Actors: | Administrator |
| Stakeholders: | Library |
| Prereq: |
Logged in as Administrator
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If you need to create a new display
|
| Notes and Questions: |
|
| Summary: | An adapter is used to extract metadata from an object automatically. In Fez, instructions for running the adapter are entered into the system along with information about the file format that it works on such as any documentation that defines it or names of organisations that provide the information. The instructions will be used to run an external application (or call a PHP script if possible) to extract the metadata and associate it with objects as they are ingested. |
|---|---|
| Priority: | Expected |
| Use Frequency: | Sometimes |
| Direct Actors: | Administrator |
| Stakeholders: | Library, Archiver, Reviewer |
| Prereq: |
Logged in as Administrator
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If the application doesn't exist at step 5
|
| Notes and Questions: |
Fez will check that the script exists and notify user but doesn't need to take action. What if the extraction will take a long time? Should there be the option to do it in a cron job? Same problem if the extraction can't happen on Fez's platform, can metadata be extracted manually and submitted manually in one piece? |
| Summary: | Process records are used to record any changes to the data after it has been put in the repository. Perhaps items were upgraded to a new file format or transformed in some way. The Adminsitrator will perform these operations on the items and record their actions in a process record. The Process Records are stored as objects in the repository themselves and describe a generalised process. If all WAV files in the archive are to have their header format changed, then only one change record describing the generalised case needs to be created. Process records are likely to be used by the Fez workflows to describe standard steps to perform. For this reason, they might also be automated so that a workflow could specify an automatic operation to be performed. |
|---|---|
| Priority: | Essential |
| Use Frequency: | Sometimes |
| Direct Actors: | Administrator |
| Stakeholders: | Library |
| Prereq: |
Logged in as Administrator
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If there are a large number of objects to be associated with the process
|
| Notes and Questions: |
There is a risk that large scale automated changes within Fez could corrupt data if the script has a bug. We'll need a procedure for testing Fez processes to make sure they are correct before we apply them to a large set of data. |
| Summary: | The Administrator can create communities which are used to group collections of research. These communities might be by faculty or research area. |
|---|---|
| Priority: | Essential |
| Use Frequency: | Sometimes |
| Direct Actors: | Administrator |
| Stakeholders: | Researcher, Archiver, User |
| Prereq: |
Logged in as Administrator
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
|
| Notes and Questions: |
|
| Summary: | Collections are used to group sets of items that belong together. The collections are grouped in communities |
|---|---|
| Priority: | Essential |
| Use Frequency: | Sometimes |
| Direct Actors: | Administrator |
| Stakeholders: | Archiver, Researcher, User |
| Prereq: |
Logged in as Administrator
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
|
| Notes and Questions: |
|
| Summary: | Workflows are used to describe how users interact with a piece of software. In this context, an Fez workflow defines the states an item proceeds through to acheive a task - e.g. ingesting or extracting. This Fez workflow is configurable so that it can be adapted to suit a variety of organisations. The workflow defines a set of roles that will be associated with each object. When an object is submitted, these roles are inherited from the parent object or can be over-ridden by the archiver. |
|---|---|
| Priority: | Desired |
| Use Frequency: | Sometimes |
| Direct Actors: | Administrator |
| Stakeholders: | Library, Archiver, Reviewer |
| Prereq: |
Logged in as Administrator
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
|
| Notes and Questions: |
|
| Summary: | The Fez workflow defines a network of states that the Fez item must progress through. Each state has a set of instructions (in a process record) and is associated with a configured role. The state of each item is stored in it's metadata. Each Workflow has a start state and a way of triggering it. For example there may be a workflow configured to trigger on the ingesting of a slide image. There is another workflow that is triggered when a user self registers. Making the workflows configurable creates a lot of flexibility about how Fez interacts with all users. |
|---|---|
| Priority: | Desired |
| Use Frequency: | Sometimes |
| Direct Actors: | Administrator |
| Stakeholders: | Library, Archiver, Reviewer |
| Prereq: |
Logged in as Administrator
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If there are no roles defined, then no states can be created
|
| Notes and Questions: |
It will be possible to mark a Start State.
|
| Summary: | To access certain parts of Fez, the user must log into Fez. |
|---|---|
| Priority: | Essential |
| Use Frequency: | Often |
| Direct Actors: | User |
| Stakeholders: | All |
| Prereq: |
Not logged into Fez User exists in Fez or AD |
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If username or password is invalid
|
| Notes and Questions: |
|
| Summary: | Inserting, Ingesting, Uploading. The archiver moves items into the repository. |
|---|---|
| Priority: | Essential |
| Use Frequency: | Often |
| Direct Actors: | Archiver |
| Stakeholders: | User |
| Prereq: |
Logged in as Archiver. A collection has been created to group the items The repository is configured to ingest the type of item to be submitted |
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If the adapter fails to extract the preservation metadata
|
| Notes and Questions: |
Some users can have multiple roles so the reviewer may also be an archiver - it depends on the configuration of the collection. If there is a problem with the preservation metadata, the problem can be resolved on the spot or fixed later as part of the workflow. The details can be manually added. |
| Summary: | Items can be removed from the repository |
|---|---|
| Priority: | Essential |
| Use Frequency: | Sometimes |
| Direct Actors: | Archiver |
| Stakeholders: | Library, Archiver , Reviewer |
| Prereq: |
Logged in as Archiver
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If item was deleted by mistake
|
| Notes and Questions: |
The items should only be marked as deleted in fedora - i.e. they can be recovered. non-archivers can't see the deleted items, only the archiver sees them. You could have an extra step for purging deleted items over a month old or something. The unique item identifiers should not be re-used. Even after items are purged, Fez will keep track that the item has been deleted and won't re-use the item id. Perhaps a deletion record will be kept or maybe Fez will just hang onto the metadata and just the actual data will be gone. |
| Summary: | When item data needs to be changed, an Fez process is used to record the changes made. The Fez process is an item itself that describes how to transform an item type to another form. e.g. perhaps the .au sound format will become awkward to handle but the .wav format is prefferred, so we write a process for converting .au to .wav. |
|---|---|
| Priority: | Essential |
| Use Frequency: | Sometimes |
| Direct Actors: | Archiver |
| Stakeholders: | Library, User, Administrator |
| Prereq: |
Logged in as Archiver
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
|
| Notes and Questions: |
Item history will note the process id, time, date and username. For bulk process, see UC-03-03 |
| Summary: | 1-3 SENTENCES |
|---|---|
| Priority: | Essential | Expected | Desired | Optional |
| Use Frequency: | Always | Often | Sometimes | Rarely | Once |
| Direct Actors: | ACTOR1 |
| Stakeholders: | STAKEHOLDER |
| Prereq: |
PRECONDITIONS
|
| Main Success Scenario: |
|
| Alternative Scenario Extensions: |
If CONDITION, then ALTERNATIVE STEPS.
|
| Notes and Questions: |
|