SharePoint Development Options: Requirements Gathering

Transcription

1 SharePoint Development Options: Requirements Gathering Purpose... 1 Process... 1 Questionnaire... 2 Supporting Information... 5 Appendix 1: Development Time Considerations... 8 Appendix 2: Tips for Writing a Requirements Document... 8 Purpose This document will assist in the information gathering stage of the SharePoint development process. By working through the options contained in this document, you will be prepared to discuss your project with a SharePoint developer. Process 1. Fill out the Questionnaire, which covers information from the Item Level up to the Site Level. Use the Supporting Information section for reference. 2. Think about time considerations for both you and the developer (considerations for the developer are listed in Appendix 1). 3. Work together with SharePoint Developer to produce a requirements document (see Appendix 2 for tips about how to write the requirements document) 1

2 Questionnaire Please type your answers to each question below. Step 1. Answer the questions prior to meeting with the developers General What is the purpose of the site and what is current business process for this activity/task? What do you challenges do you hope to mitigate by conducting business in SharePoint? Who is the main point of contact for this site? Who will need to access the site are users internal or external to NIH? Do you anticipate special needs, such as on-going high volume of use, unrestricted access for all NIH staff, or highly complex design? Site or sub-site Level Information This may be either a whole site (e.g. NIHGPS, HS-PAS, or OEPSPS) or a sub-site on an existing SharePoint instance (e.g. the Research Misconduct System is a sub-site of OEPSPS). Will the site be used to complete a review/approval process or other business process? o Provide a flowchart of the process. o If digital signatures will be required, please provide the names of individuals required to sign. Does the site need to store documents? o Will the documents be open for editing? Does the site need to display updates or announcements? Does the site need to display scheduled events and meetings? Will the site need to connect to external information? o Where is the external information located and who has access to it? o How often will the connection need to be made? What on-going support will be required to the site? o Basic support such as updating permission groups? o Back end maintenance of complex design such as moving items and/or sending s? o Helpdesk support for users? Should the data be archived or deleted to meet records retention policies? o What are the schedules for archiving or deletion? 2

3 Step 2. During your meeting with the SharePoint developers, you will develop a census of needed lists, libraries and other resources: List and Library Level Information Main List(s) and/or Library(ies) This list contains the item specified above. Examples include: Q2A Documents and ENS & HHS Forecast (NIH Guide Publishing System), Human Subjects Request and HS Team Assignments (Human Subjects Protection Assessment System), Justification Memo for Limited Competition and Request for Page Limit Exception (NIH Guide Publishing System) How many main lists are required? What purpose does each main list serve? If there is more than one main list, what is the relationship between them? Are any of the relationships one-to-many? Supporting List(s) This list is used to provide reference information that supports the main list. Examples of common supporting lists include: Institutes and Centers, Code Numbers and Descriptions, Activity Codes. How many supporting lists are required? What purpose does each supporting list serve? What is the relationship between each supporting list and the main list(s)? Are any of the relationships one-to-many? Step 3. After initial discussions identifying lists, libraries and other resources needed, answer the following questions for each list, library and resource identified: Access and Permission Groups Standard permission groups are: Owners, Members and Visitors. Permission levels are typically defined as follows: Owners- full control, Members - edit privileges, Visitors - view only privileges. Are the standard permission groups sufficient? If not, what other groups are needed? Are the standard permission levels sufficient? If not, how should the permission levels be modified for each group? Who will be in the Owners permission group? 3

4 Item Level Information Items are the records that make up a list or library; they may have a variety of required and optional fields, field types, labels, etc. What is the item: is it a document, a record (to which documents may be attached), something else? What information do you know (or need to know) about the item? These are called the fields; examples include: Assigned to, Status, Date(s), Description, PI Name, and Project Number. Will the item have attachments? If so, what will be the maximum size of the attachment (in MB)? Which fields are always in the item (i.e. required)? Which fields are optional? Which permission groups can view items? Which permissions groups can edit items? Which permission groups can delete items? Is there any point in the business process in which certain individuals or groups should not have access to the items? If so, please explain. Is there a need for a unique numbering system that counts up in increments? Please explain. How are the lists related, e.g. moving items and referencing items? 4

5 Supporting Information SharePoint Development Types SharePoint development can be represented by a banana split. The bananas represent basic SharePoint development: SharePoint lists and libraries. Each scoop of ice cream represents different types of advanced SharePoint development: o SharePoint Workflows o InfoPath Forms o InfoPath Lists Note: More than one type of advanced development may be necessary depending on the requirements of the site. Basic SharePoint Development List and libraries are the foundation of SharePoint websites, but they store data in different ways. List Lists function like databases. Each item (also called a record) contains data that is organized into fields. Some fields are required and some fields are optional. SharePoint views are like database queries because they show a window into the database based on pre-defined filters. Lists are most commonly used for data collection, tracking and processing. Permission groups are used to determine who has the ability to create, edit, or delete records. Documents (Word, Excel, etc.) can be attached to individual records. Library Libraries (also called document libraries) function like shared network drives to provide centralized access to documents that are often stored within folders. Each document has document properties that may be required or optional. Libraries are most commonly used as a replacement for shared network drives. Permission groups are used to determine who has the ability to create, edit, or delete documents. 5

6 The document is the record. Any columns that are created in the document library are properties of the document. Advanced SharePoint Development SharePoint Workflows Workflows allow for automation of business processes. Workflows can control or change almost any aspect of any item in lists and libraries, including the life cycle of that item. Workflows can be as simple or complex as needed. For example, a simple workflow could route a document to a series of users for review. Workflows can be run manually, or run automatically when an item is created or changed Workflows are commonly used to route documents for review and approval. Workflows can be used to save and track data elements at various times. Workflows can be used to send s automatically. Workflows can populate data within a record. Workflows can update information in one list with information from another list. InfoPath Form Library InfoPath Form Libraries store InfoPath forms. InfoPath forms include data in text boxes and other controls that let people enter, view, or otherwise specify information on their forms. InfoPath forms allow hiding and showing of specific fields based on custom rules. The form is the record. The form contains fields, which can be promoted to the SharePoint library. The number of fields that can be promoted as columns is limited. The functionality of the promoted fields is not the same as SharePoint columns; only certain types of promoted fields can be edited directly in SharePoint without opening up the form. InfoPath forms have the following controls that are not available within a SharePoint list or library: Combo box - allows for the user to type in text to the field or selects an option from a drop down box Numbered or bulleted list allows the user to choose one or more selections within that list External Item Picker - allows the user to pull information from an external source Button (including Picture button) allows the user to initiate custom actions by clicking on the button Two common uses for InfoPath forms are approval processes and survey collection. For approval processes, the developer uses buttons and digital signatures, and users click a button to digitally sign the form. For survey collection, data is collected by asking the users a series of questions questions can be hidden based on custom rules. 6

7 Reasons to use InfoPath Forms repeating or nested data digital signatures custom coding or controls rules to hide and show fields One-to-many relationships InfoPath List InfoPath Lists are a hybrid of SharePoint lists and InfoPath forms. The InfoPath list is a SharePoint list that is customized by InfoPath to allow for text boxes and other controls that let people enter, view, or otherwise specify information on their forms. InfoPath lists allow hiding and showing of specific fields based on custom rules. InfoPath fields are limited only by SharePoint, and are truly SharePoint columns. InfoPath lists have the same controls as InfoPath forms. InfoPath lists do not allow repeating elements and do not support digital signatures. By opening up the list in InfoPath s design mode, changes can be published directly back to the site, without having to create and store a form. Reasons to Use InfoPath Lists custom coding or controls rules to hide and show fields easier user interface than InfoPath forms 7

8 Appendix 1: Development Time Considerations Work with the Project Manager and SharePoint Developer to establish realistic deadlines. The following conditions influence the amount of time it can take to develop a site: Complexity of the Site Complexity of InfoPath rules Complexity of Workflows Holidays and leave schedules Workload and availability of SharePoint Developer Appendix 2: Tips for Writing a Requirements Document Work with the Project Manager and the SharePoint Developer to create the Requirements Document. The answers to this questionnaire will allow the SharePoint Developer to create the first draft of the Requirements Document. To complete the Requirements Document, you will be asked to provide additional content, a summary of the business process, and a thorough review of the documentation. Typical Headings of a Requirements Document Introduction Business Process Permission Groups Development Method Conclusion Explaining the Business Process There are two options for explaining the business process. It is a good idea to prepare both options for the SharePoint Developer. Write out the business process as text Create a visual display of the business process as a flowchart, using pencil and paper, or software such as Microsoft Visio or Microsoft PowerPoint 8