Some roles has different interest and thus different requirements for the functionality of the Application. For clarity, here the requirements are specified sorted by user roles.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
In order to be able to browse, search, annotate and view the Component base, a Guest sets the following requirements on the Application:
A Guest MUST be able to query the Application for Components either by specifying a set of propertyname and propertyvalue pairs for exact matching methods or by specifying string pattterns for string pattern matching methods.
A Guest MUST be able to add annotations to available Material Components.
A Guest MUST be able to read annotations to available Material Components.
A Guest MUST be able to view metadata associated to available Material Components in the Application.
A Material Components metadata set SHOULD be dependent on the Material Components type and the view MAY be dependent on other roles associated to the user in the Application
A Guest MUST be able to access Material Components that is available in the Application.
"Accessing a Material Component" means that content associated to a File Component is downloaded, the organization of a Folder Component is displayed in the browser, the browser is redirected to the destination of a URL Component and the metadata about a Person Component is displayed in the browser.
A Guest MAY be able to list Portfolio Components that is available in the Application.
"List Portfolio Components" means that the Application is queried for this type of Component.
A User MUST be able to do the same things as a Guest. Also, in order to be able to manage the Material Component base and set access restrictions on Components a User adds the following requirements:
A User MUST be able to add new Material Components to the Application.
"Adding a new Material Component" means that the metadata associated to the Component is stored in the Application and content associated to a File Component is uploaded to the Application. New Material Components MUST be included in the organization of an existing Folder Component.
A User MUST be able to remove Material Components from the Application.
"Removing a Material Component" means that the metadata associated to the Material Component is removed from the Application, content associated to a File Component is deleted from the Application and for Folder Components are Components included in the organization also removed from the Application.
A User MUST be able to copy Material Components from one Folder Component to another Folder Component in the Application.
"Copy a Material Component" means that a new Material Component is added and the metadata copied from the original Component to the new Component, content associated to a File Component SHOULD NOT be copied and for Folder Components are Components that is included in the organization also copied to the new Folder Component in the Application.
A User MUST be able to move Material Components from one Folder Component to another Folder Component in the Application.
"Moving a Material Component" means that only the [reference to ?] Material Component is moved from one organization to another organization in the Application.
A User MUST be able to create a link to availabel Material Components in a Folder Component in the Application.
"Linking a Material Component" means that the destination Folder Component organization is augmented with a reference to the Material Component in the Application.
A User MUST be able to edit metadata associated to available Material Components in the Application. A User MUST NOT be able to edit metadata defined as a "live property".
A User MUST be able to add read privileges to Material Components and Portfolio Components for other Users in the Application.
"Adding read access privilege to a Component for a User" means that the Component, associated annotations, associated metadata and access privileges will be available for the User to read.
A User MUST be able to add write privileges to Material Components and Portfolio Components for other Users in the Application.
"Adding write access privilege to a Component for a User" means that the Component, associated annotations, associated metadata and access privileges will be available for the User to read, update and remove.
A User MUST be able to revoke access privileges that has been granted to Material Components and Portfolio Components for a User in the Application.
"Revoking an access privilege to a Component for a User" means that the Component, associated annotations associated metadata and access privileges will no longer be available for the User.
A User MUST NOT be able to revoke access privileges to Components for the Owner of the Portfolio Component in the Application.
A Owner MUST have write access privileges to the assigned Portfolio Component in the Application.
A User SHOULD be able to manage access privileges for groups of User in the Application.
A Owner SHOULD be able to personalize the assigned Portfolio Component.
"To personalize a Portfolio Component" means that the visualization of the Portfolio Component uses the colors, font families and font sizes that is choosen by the Owner
In order to be able to manage the Portfolio Component base of the Application, an Administrator sets the following requirements on the Application:
An Administrator MUST be able to create new Portfolio Components in the Application.
"Creating a Portfolio Component" means that a User is assigned as the Owner and granted write access privilege of the new Portfolio Component and metadata about the new Portfolio Component is stored in the Application.
An Administrator MUST NOT be able to assign a User as Owner to more than one Portfolio Component in the Application.
An Administrator MUST be able to remove a Portfolio Components from the Application.
"Removing a Portfolio Component" means that all Components and metadata that is associated to the Portfolio Component is removed from the Application.
An Administrator MUST be able to make backups of Portfolio Components in the Application.
"Makeing a backup of a Portfolio Component" means that content of File Components, metadata and organization of Material Components, associated with the Portfolio Component in the Application, is written to a backupfile.
An Administrator MUST be able to restore Portfolio Components from backups in the Application.
To "restore a Portfolio Component from a backup" means that content of File Components, metadata and organization of Material Components, associated with the Portfolio Component in the backup, is stored in the Application. Any Portfolio Component in the Application that is already associated to the Owner of the backup is removed from the Application.
An Administrator MAY be able to maintain the user configuration of the Application. This requirement may not be fullfilled if using an external user configuration system that do not allow user maintenance due to security or other aspects.
There are no specific technical requirements regarding System performance. The only constraint is that the Application MUST be "usable", which in practice means a query or operation response time of less than five seconds. For the purposes of project Portfolio, the System MUST initially support a small amount of users (less than 500). But the Application design SHOULD be scalable enough to in the future support (with appropriate hardware and network connections) a customer base of [10 000?] and a daily query rate of [25 000?].
The application MUST support user idenfication and provide a username and password authentication scheme. To minimize the maintenance of user configuration SHOULD the authentication mechanism be replaceable with an exsisting authentication system. With this, the application knows the roles associated with the user. This identification scheme also makes it possible for the application to associate a Portfolio Component with a user and to allow a Owner to grant access privilege to other users.