until all their documentation has been transferred to the new document management system transfer. Needs further discussion 1.8 The new system should provide a of concept for E&B within one area to the new system Note: We will take an area of E&Bs choosing to set up for them. They will be able to set the area up they require and can use to see if it is easier for them to manually migrate documents or have them automatically migrated MH 2 2. Training for E&B required. 2 2EB15/Admin ID Requirement Category Serengeti SharePoint WIKI 2.1 The new Estates and Buildings document management system must have the capacity to store the existing EB15 folder and related subfolders. The system should allow for future growth. This will include the Technical Services and Finance folders which currently reside under EBLDGS but which are being transferred to Admin Note: This folder should be called Admin going forward and is referred to as Admin in rest of this requirement set. The present storage capacity for EB14 (for the full year) will be confirmed before Design stage along with the size of the Technical Services and Finance folders MH 2 3. 3.1 already defines the total current capacity? 3.1 defines for EBLGS; 2.1 defines for Admin (EB15) 1 2.2 Retention on the folder should be Permanent MH 2 2 0 2.3 E&B only require the area to be set up at this point. MH 2 2 2 2.4 All E&B should be able to view Admin folders and subfolders MH 2 2 2 2.5 Administrators must be able to set up folders and subfolders under Admin in the future and assign permissions within these folders as to who can create, edit and delete folders Note: it should be that External users can never access Admin folder MH 2 2 2 2.6 E&B will migrate the EB15 folder to the new system manually (as they require to set this folder up themselves) MH E&B process 2 2 2 3EBLDGS folder
contacted if any issues arise with the project 6.7 Project managers must be able to move to a permanent folder in EDLDGS building folder from the projects folder Note: this will mainly be for documentation that has to reside with the building when the project is closed such as Health and Safety documents MH 2 3. Documents can be tagged in such a way that when the project workflow ends the document is automatically i.e. document with type Safety document moves to Health and Safety folder on xx/xx/xxxx (project closure confirmed date) 1 7PROJECTS folder retention ID Requirement Serengeti SharePoint WIKI 7.1 Each Level within the Project will have a retention period set – all documents in the Level folder inherit the same retention period – there should be no anomalies MH 2 - Note that retention policies are implemented via the Lifecycle module - we'll need to check if our licence covers the use of that and if it has been installed 2 0 7.2 Retention periods should be set on the Level when the project is created as follows Level 1 – Feasibility – documents and folder can be deleted when the project ends Level 2 – General - documents and folder can be deleted 6 years after the end of project Level 3 – Procurement - documents and folder can be deleted 12 years after end of project Level 4 - Legal & Statutory - documents and folder can never be deleted MH 1 - Yes, if the service levels are set up as 'categories' of documents. If these will be folders, I'll need to check whether policy rules can be applied to folders 3. Retention options in SharePoint are very flexible with workflows. The Retention policy feature lets you define retention stages, with an action that happens at the end of each For example, you could define a two-stage retention policy on all documents in a specific library that deletes all previous versions of the document one year after 0
They must be able to search on either one, or a combination of, the following criteria: of document authors name building name date uploaded keywords (tags) project name project code content tagging and highly configurable search in SharePoint addresses this requirement and more with minimal effort to implement 11.2 Users must be able to search for documents using wildcards MH 2 3 - search in SharePoint is extremely powerful, highly configurable and flexible 2 11.3 Users will not be able to search in projects they do not have access to MH 2 2 11.4 E&B administrators will have permission to search in all projects MH 2 2 12Upgrades ID Requirement Category Serengeti SharePoint WIKI 12.1 The new system should be easily upgradeable with the minimum amount of downtime while the upgrade happens SH 0 3 Microsoft upgrades SharePoint Online. As part of our Office 365 tenancy, this is at no extra cost 2 12.2 Upgrades should not be expensive – this should be clarified as part of a SLA regarding the usage of the chosen solution MH 0 3 Microsoft upgrades SharePoint Online. As part of our Office 365 tenancy, this is at no cost. Comprehensive SLA's and full Service Descriptions are available 2 - Upgrades funded by IS – 5.2 from BRD Non-Functional Requirements Identify and record requirements for aspects of the solution other than those explicitly concerning its functionality. For IT applications examples of non functional requirements may include those relating to security, scalability, performance, backup and recovery, extensibility, portability etc. Record the agreed non-functional requirements below: Separate requirements into sections Uniquely identify each requirement Describe each requirement in sufficient detail to enable verification by the business user, definition of acceptance criteria and cross-referencing during the Design stage. Specify the category for each requirement, using the following abbreviations: M = mandatory; HD = highly desirable; D = desirable Security Ref Security Requirement Category D/HD/M Serengeti SharePoint WIKI