The quarterly publication of the International Legal Technology Association
Issue link: https://epubs.iltanet.org/i/230349
functionality. This was the essential request from internal clients and other end-user representatives. In addition to a few group meetings — limited to one hour and conducted via WebEx — some individual members were consulted to elicit their specific user scenarios. The output was a business requirements document that was sent back to advisory team members in survey format for prioritization of features and functionality, with the understanding that changes might be necessary after IT review. Once the advisory team finalized business requirements, the next step was to create a list of potential products that might meet those requirements. We compiled a list of vendors from these sources: • Advisory team • ILTA forum • An outside IT research firm • IT staff discussions • Independent research The initial long list had about 30 names on it, which was pared down to the top 10 or so. Then the top three were named, with backups. The goal was to identify which products most closely matched the firm's business requirements within our architectural framework. The Vetting Process There were several steps in our vetting process: • Conduct an initial screen, and exclude products that did not meet critical requirements or firm technical standards • Map product features to individual business requirements • Evaluate product features on whether they could be delivered a) out of the box; b) via a configurable; c) through customization; or d) with a build • Obtain confidentially agreements when needed ahead of sending business requirements to select vendors for discussion Business Requirements for an Extranet Replacement Business requirements for replacing the McGuireWoods extranet fell into eight functional segments: 1. Front-End Security Security has two levels on the extranet front end: users and content. Attorneys want both centralized support and the ability to do things themselves ad hoc. Documents need security on many planes. The analyst must carefully weigh needs of workflow with firm policy. 2. Content and Functionality Content is not only applications, file types and their characteristics — it is also how content is created, updated, organized, viewed, maintained, imported, exported, archived and deleted. Content includes databases, calendars, notes, tasks, attachments and more. Functionality includes things like navigation, search, marking private, sending alerts, accessing help and sharing and synchronizing calendars. 3. Reporting Query results require list management features such as sort, filter, print, export, save, modify and delete. System reports need standing templates to pull data into, and users and/or administrators need the ability to create, customize and send reports. 4. Collaboration An extranet needs a variety of collaboration tools such as non-file-based Web pages, discussion forums and message boards in addition to document collaboration. 5. Accessibility The extranet needs to be accessible via a variety of operating systems, machine types (like tablets and mobile devices) and from varied locations. 6. Interfaces Common applications used both internally and externally need to work with the extranet product. This section calls out specific applications such as email, a variety of browsers and the firm's document management system. 7. Migration Once existing content is mapped to the new product, it needs to be migrated. This section identifies business rules that must be met, such as maintaining naming conventions, user grouping, priority order for the migration and integrity for metadata and such. 8. Nonfunctional Performance, scalability, availability, reliability and ease of use are nonfunctional requirements needed in an extranet product. Extranet back-end requirements should be listed in a separate document that will also be sent as part of the RFP. Peer to Peer 29