ࡱ>     3 _bjbjCC 4!!T7lDDDDZEJJJyyy8yL zJn{Lf{({{{}n`~$~ """"""$ /FJE~}}@* 6FDD{{$[D{D8{ ~ >^D2Ex{{ 0%J.yֈpjq0h/Fp/JJDDDD  ASK ClientName "Organization Name" \* MERGEFORMAT VPS 101 DRAFT January 26, 2006 Bloomberg L.P. Bloomberg Message Search suggested requirements v0.5 Prepared For:Autonomy Contacts:Bloomberg Bloomberg L.P. 731 Lexington Avenue New York, NY 10022 www.bloomberg.com James Cariello  HYPERLINK "mailto:jcariello@bloomberg.net" jcariello@bloomberg.net 212-617-4741 Mohan Patnam  HYPERLINK mailto:Mpatnam@bloomberg.net mpatnam@bloomberg.net  Autonomy Professional Services David Neubert Director, Consulting Services 401-885-9462  HYPERLINK mailto:dneubert@verity.com dneubert@verity.com Brent Miller Development Lead 408-802-3900 brentdmiller@sbcglobal.net  This document represents my best understanding of Bloombergs requirements for Bloomberg Message Search. In many cases, I have drafted best guess line items as placeholders, without attempting accuracy. My intent is to begin an iterative process of refinement that will hopefully culminate in documented formal requirements associated with the SOW for the Bloomberg Message Search project. If you have any questions, please do not hesitate to call for clarification. Sincerely, Brent Miller Development Lead 408-802-3900. Requirements Summary The application described in this document is further defined in a separate Statement of Work. Milestones The following named milestones are referenced for deliverable dates of individual requirements. MilestoneTimeframeSummaryDesign ValidationWeek 4Proposed C API for index & searchInitial rolloutWeek 8Features available for implementation explorationAlpha rolloutWeek 12Possibly feature incomplete & incomplete scalingQA/Pilot rolloutWeek 14QA Simulation 250K usersBeta rolloutWeek 15Production rolloutWeek 19 Requirements In the following list of requirements, unresolved issues are in red font. Requirement ID numbers are prefixed with R to allow for easy searching within this document. Features R1. Ability to search inbound messages, outbound messages, or both Description: System will provide Bloomberg application ability to search users message sets as described in API requirements below. Hard requirement Required by: Initial rollout R1.1 Searchable parameters will include from body text and metadata items Description: Search parameters can include operations on index keywords, Date, TO/From, and Folder. () Hard requirement Required by: Initial rollout Notes: We will need to declare metadata fields in advance of ingestion. We need to add requirements for process of adding to collection schema and how that would get rolled/rotated inthis for metadata that will be returned in metadata or sorted on. R1.2 Returning relevant documents Description: Each search returns all relevant documents, up to the requested number per page. The number of documents requested per page will be not more than 100. For the purpose of this document, requests for additional pages of results beyond the first page will be counted as searches. Hard requirement Required by: Initial rollout Notes: Autonomys software has no limitation with respect to the specific number of documents returned per page; however, this number is provided to assist predicting the data flow of the system. R1.3 Returned search results will include subject, date, sender and recipient. Description: Results from users incoming folder(s) may omit recipient. Results from users outgoing folder(s). We need to list other required metadata here as well, such as system and user folders. Hard requirement Required by: Initial rollout R1.4 Search results will include snippets containing query terms Description: In addition to previously mentioned metadata, returned search may be required to include text message summary snippets of up to 80 bytes from the corresponding messages, including relevant terms from the query. This will be an optional feature enabled on a per-query basis (New on 1/27/06) Soft requirement Required by: TBD. Notes: Searches with summary snippets enabled are not subject to the latency requirements otherwise stated in this document. Make an option for searching only the subject??? R1.5 Returned search results will be restricted to data associated with a specified user Hard requirement Required by: Initial rollout R1.6 Returned results will be sorted by message date or relevance in descending order Hard requirement Required by: Initial rollout R1.7 Returned results will will include required metadata. Description: Returned results will include: message id, message subject, message sender, message date, msg type (internet or BB), read flag, folder enumeration, msg receiver info. Required by: Note: metadata returned from the search index will have a brief latency period before it is synchronized with recently updated messages. R1.8. Active persistent search notification of newly arriving msgs that belong in search result lists. Description: Newly arriving msgs that match an existing search actively being displayed should be delivered via the C API. Soft requirement: design should allow future implementation. Required by: TBD. Delivery not required in phase 1, but implementation will be desired sooner than attachments. [James, 1/26/06] Notes: Can we limit # of persistent searches simultaneously active per user and kick back the N+1st search, requiring some other persistent searches get deleted first? For persistent searches, maybe require a response from the Bloomberg system for each hit, to verify the client is still listening (else persistent search will get dropped)? We do not want a resource drain problem from ever-increasing number of persistent searches open on one side. [brent 1/26/06] R1.9 Search result paging will include newly ingested messages Description: The Verity system will provide sequence identifiers for messages (probably microsecond addition to timestamp) and use them during paging of search results to assure newly ingested messages are appropriately inserted into results when retrieving pages of results. Soft requirement (Is this correct?) Required by: Note: This requirement is incompatible with caching 100 search results at a time. (requirement 1.2) R1.10 Fully integrated into current Bloomberg Messaging Application. Description: It must be possible to submit search queries that find messages containing matches to a specified substring. Substrings in such queries would always contain at least at least 3 characters. (i.e. Search for *ab* is not required) Hard requirement Required by: Alpha rollout Notes: Would it be acceptable to provide substring matches for alpha characters, but with multiple whitespace characters compressed to a single whitespace? (For example, a search for big one would match a msg containing big one)? BB would like our first take on search to behave like the existing grep search. Note: a checkbox on the UI should be available to turn on a wildcard search, and a requirement should be noted that some % of searches will be wildcard searches. R2. Ability to add highlight markup to messages selected from search result lists Description: For viewing messages, the system will have the ability to add markup to messages in search result lists, identifying terms in the message that are relevant to the search query. This markup will take the form of configurable (system-wide) start and end strings identifying the region to be highlighted. Hard requirement Required by: Initial rollout Notes: Bloomberg will maintain copies of all ingested messages and make their data available as needed via the C api. All relevant search terms are highlighted in a virtual document when the document is viewed, and what attributes to include in the virtual document can be configured by Bloomberg. Fields (attributes) to be shown in the result list are typically not hightlighted, except for Passage-Based Summaries. (Brent: Verify) Some non-default search operators (i.e. near) highlight fewer items than often expected when not all occurrences of the item(s) contribute to documents search relevance. Searching metadata fields will be dependent on zoning them, meaning we will need to use searchable strings (rather than user #s) for values to include in the virtual document. Highlighted subjects will require, possibly, PBS from a VDKSUMMARY field with 1st x (size of subject). R3. Ability to create and remove users Description: An API call is required for removing users, and will free all resources associated with the specified user(s). An API call for explicitly creating users is not required (see requirement 2.1). Hard requirement Required by: QA rollout. R3.1 (New on 1/26/06) System must have the ability to dynamically create new users implicitly Description: When a message is ingested for a user that is not recognized by the search system, an implied user creation will be performed. An API call will also be available for removing users, and will free all resources associated with the specified user(s). Soft requirement: design should allow future implementation. Required by: Alpha rollout Notes: Should we allow for some kind of gatekeeper to control creation of users, allowing for a pilot rollout with access limited to explicity created users? R4. Ability to insert, remove and update messages Description: Messages can be inserted to and removed from the search system in their entirety. Inserted (Ingested) become available for search and other features of the system. Removed messages The Bloomberg deleted and other folder attributes will be available as search criteria Hard Requirement Required by: Alpha rollout Notes: Is any behavior required in response to attempts to view removed documents? Retracted messages must get updated in senders outbox, and get purged from recipients data. This will become an update for the sender, and a delete for the recipient (on the search system) R4.1 Notification of rejected messages Description: Ingested messages that are unintelligible by subsequent systems (unintelligible according to character set code page, etc.) will trigger notifications delivered to the Bloomberg system via the C API. Notifications will indicate if message should be resent (transient errors) or aborted (permanent conditions). Hard Requirement Required by: Beta rollout R4.2 Search index insert transactions cannot be lost. Description: Ingest transactions successfully submited via the C API cannot become lost except through a catastrophic failure of the SAN causing permanent corruption or loss of stored data. The search system will continue attempting to process a message until it is available for search or a notification of failure is delivered to Bloomberg via the C API Hard requirement Required by: QA/Pilot rollout Notes: Do we really want to require successful delivery of failures? This exposes us to the risk of a down error handler backlogging until all message ingestion halts, which might be worse than lost error notifications. Perhaps only guarantee notifications unless greater than some number of pending notifications have been queued. If such a requirement will exist for the profiling system, should ingestion into the profiling side and the search side be atomic? If so, foldering and/or search latency may increase as each system would need to talk to, and wait for, the other. If not, independent failure notification from each system must be possible, and ingestion into each system must be available independently. R4.3 Search system will be able to provide language and character set recognition Description: The search ingest system will provide best-effort auto-recognition of language  and character set encoding of submitted messages that Bloomberg does not identify. Supported, identifiable languages are listed in the Autonomy document, {To be filled in by Autonomy}. Hard requirement Required by: Alpha rollout Notes: Performance considerations associated with language identification are discussed later in this document. R4.4 Message updates can alter fixed-width metadata. Description: Updates may occur to fixed-length message metadata fields, such as System Folder, Read Flag (unread(read), or Retract Flag. Hard requiremend Required by: Alpha rollout Notes: Updates to var-length metadata fields or updates to the searchable body text will require the message to be re-ingested. Autonomy may provide an API call for re-ingestion, or may elect a remove-and-insert approach. This feature will be used to move messages to deleted folders. Every msg will be in system inbox folder, and will also appear in any other system folders the user puts it in. A delete removes it from all other system and user-defined folders, but this can be implemented by Bloomberg setting the correct field data in an update operation. Users cannot move messages between user folders Add criteria for performance of updates? R21. (New 1/27/2006) Message Classifier Description: Ingested messages will be compared against up to 5 system-wide queries used to identify 5 types of messages. meta tags identifying messages types will be available for searching, and notification will be delivered to the Bloomberg system of messages types. Soft requirement (Is this correct?) Required by: When is this required? Notes: I am not sure I understand how this is to be used and if it is different than message folders. Is this a required feature and, if so, can Bloomberg explain it in more detail? Do we need to add performance specifications for classifier? This feature is out of scope for the projectno hours are listed. R22. Return notification of per-user user-defined folder classifications  per message Description: TBD by Autonomy: expand what this means. Hard requirement Required by: Notes: Metadata updates cannot be used to move messages between user-created folders. Scalability R5. Dynamic expansion Description: Expanding the system to meet growing demands (scaling) will not require downtime. Hard requirement Required by: Beta rollout Notes: This feature is out of scope for the project. R6. Scalable to 5 years of message history , at up to 12 million messages per day Description: Search system will be able to scale to meet existing requirements with 5 years of message history stored at up to 12 million messages per day. Hard requirement Required by: Beta rollout Notes: Should this be 15 million messages per day? Any pariticular maximum amount of data can be accommodated at the expense of designing to use additional hardware. After we have done a design pass, we might want to discuss the implications of this requirement. R7. Scalable to 400,000 users Description: Search system will be able to scale to meet existing requirements for 400,000 users. Hard requirement Required by: Beta rollout Reliability requirements We do not have specific criteria for what is required in a failure scenario yet, but these item are placeholders for the specific checklist terms that will eventually replace them: R8. The search system will have fail-over capability Description: System .will be comprised of components that may fail with load transferring to surviving components Hard requirement Required by: Beta rollout Notes: This feature is out of scope for the project. R8.1 System solution can meet all requirements during one complete server node failure Description: Hard requirement Required by: R8.2 System can survive multiple component failures at reduced performance. Description: System solution can survive concurrent, complete failure of up to 2 nodes for every 12 total nodes without loss of functionality, but at performance of 75% the normally required level. Soft requirement Required by: Notes: This requirement is an attempt to state what reliability guarantee there will be, in a way that will be measurable to check that is has been achieved when the system is delivered. Questions regarding distinction between machines pertain to details of the architecture that are not available until we have verified all the systems requirements. What % of machines can fail? R8.3 System can survive multiple component failures at reduced performance. Description: System solution can survive complete failure of one switched network channel per every 400,000 users without loss of functionality, but at performance of 75% the normally required level. (new 1/27/2006) Soft requirement Required by: Notes: R9.1 The search system will have fail-back capability Description: Failed system components may be replaced and the system will resume operation in a load-balanced state Hard requirement Required by: Beta rollout Notes: This feature is out of scope for the project. R10. The search system will have system-wide remote site replication and remote site fail-over. Description: Replication services allowing fail-over and load sharing with redundant system hosted in alternate site connected via wide area network (WAN)one site in NY, on in NJ Soft requirement (Is this correct?) Required by: Beta rollout Notes: This feature is out of scope for the project. R13. Is a loss of in-progress search transactions acceptable upon each system node failure Description: Hard requirement Required by: R14. C API library will provide timeouts Description: The API layer will provide a timeout capability, implemented in the C-invoked code running on the MSG-big server, for all synchronous calls Hard requirement Required by: R15. (New on 1/26/06) The following transactions should uh oh. What was supposed to go here? Description: Hard requirement Required by: R16. Are there any requirements for Turning of machines? Description: {To be filled in by Bloomberg} Information describing the turning process will be necessary if the system must conform to such a process. Hard requirement Required by: Notes: This feature is out of scope of the project SOW. API requirements R17. Autonomy will provide libraries with a C API providing features listed in this document. Description: The API itself will be implemented on a secure network. There is no requirement for authentication or encryption of data or transmissions on Autonomys part. Hard requirement Required by: Validationheader files and minimal flow diagram with no commitment to finality Initial rolloutcomplete API, unchanging without Bloomberg review R18. Notification of impending search Description: Bloomberg will be willing to deliver notifications via the C API identifying users actively ready to perform searches (and no longer actively ready to perform searches), with the purpose to improve average-case latency. If such a feature is requested by Autonomy, performance requirements will be required to be met only when (a) not more than 50,000 users (make this a percent?) are actively ready to perform searches and (b) all searches run are for by active users only. Notes: See requirement R40.2. R19. Bloomberg will provide message data as required by C API calls Description: Storage of ingested messages will be provided by the Bloomberg system, and the Bloomberg system will pass relevant corresponding message data to any the C API calls the require it (as determined by Autonomy). Required by: Notes: At Autonomys request, stored messages may be provided via a message handler rather than via a pre-determined set of API calls. R20. The API will require an error handler running on the Bloomberg system. Description: Bloomberg will create a process running on the Bloomberg system that will call an Autonomy library entry-point for receiving messages from the search system. The API will provide for a mechanism by which messages are relayed to the Bloomberg system. The search system will guarantee that relayed messages cannot be lost unless they are successfully delivered to the Bloomberg system, and messages will have sequence ids allowing Bloomberg to identify if a transaction has already been seen. Hard requirement Required by: Notes: Bloomberg might want handle communications for this handler, and pass received buffers to the Autonomy system for decoding??? (Is this good design? Theyd have to hold sockets open in case while our calls decide whether or not to pass data back.) This process may become responsible for all RCP communications, holding TCP sockets open to all search system servers. This option is left to Autonomys design. R23. Search API requirements R23.1 Search queries of up to 32000 bytes will be allowed Description: With search string of no more than 32000 bytes of UTF-8 VQL-format queries. The VQL format is described in the Autonomy publication, {To be filled in by Autonomy} Hard requirement Required by: Initial rollout R23.2 Searches can specify descending sorting by message date or relevance Description: Hard requirement Required by: QA/Pilot rollout R23.3 Searches can be restricted to specific system or user folders Description: Searches can include a specification enumerating system and user-defined folders to be searched. The search system will allow for system folders including all messages, inbox, outbox, deleted inbox, deleted outbox and drafts. Hard requirement Required by: R23.4 Search requests will include a unique ID of the user Description: Searches will include an accompanying unique identifier naming Recipient whose the user whose message archive is to be searched. Hard requirement Required by: Notes: The user id or username will not appear in the body text of inbound messages. R23.4 Search requests will use query strings in the UTF-8 character set code page Description: With identifiers for the language and character set code page of the search query string. Hard requirement Required by: R24. Ingestion API requirements 24..1 Ingestion requests will include messages via in-memory buffer Description: Messages submitted for ingestion to the C API will include message via an in-memory buffer (identified with a pointer and number of bytes) Soft requirement Required by: Notes: XML is not required, but we should be consistenteither deliver all msgs in XML or none. If we do not use XML, then we can use struct members in the C API to pass field/attribute metadata. XML would work, or a header style like RFC 822; otherwise we should specify stored attributes via the API. The encoding will be UTF-8. R24.2 Ingested messages will have MSGIDs Description: Ingested messages will include an accompanying MSGID, an immutable, unique identifier that will remain consistent from ingestion to subsequent searches or updates Hard requirement Required by: R24.3 Submitted messages will use an Autonomy-supported code page. Description: Submitted messages will use one of the supported code pages named in the Autonomy publication, {To be filled in by Autonomy} Soft requirement (See note) Required by: Notes: To simplify highlighting, we are not including the Bloomberg  ascii-esque code page in the list of supported character sets. However, it may be possible for Autonomy to support and highlight messages using the Bloomberg code page. With code page (but not language) identified for all remaining messages Move to data characteristics section R24.4 Ingested messages will have system folder identifier Description: With enumerated identifier for system folder field (1/inbox, 2/outbox, 4, 10, etc.) Hard requirement Required by: R24.5 Ingested messages will have unique identifer for Sender. Description: Ingested messages will include an authoritative unique identifier for Sender Hard requirement Required by: Notes: What will be used for the identifier? If internet addresses, integral values wont work, so we could either pump the user # into a string, or use the UserName string value. R24.5.1 Sender id will be searchable Description: This will require ability to search email address. Also, the ability to search recipient field (zone) is required for outbox. Hard requirement Required by: R24.6 Messages can have up to 1000 recipients (bdm: reduced from 32000 1/27/2006) Description: The C API can accept messages with authoritative unique identifier(s) for up to 1000 recipient(s). Hard requirement Required by: R25 API must be versioned Description: The API must to be able to evolve to handle schema changes. Any C structures used to hold metadata or other infrustructure specific to the message format must be versioned. Hard requirement Required by: Notes: This basically requires sturct headers identifying the API version so that we can decode structs passed from difference versions of the headers. Data characteristics R26. Each message will be no more than 150k bytes. Description: In messages where the recipient list is hidden, the recipient list does not consume bytes in the message, and do not count towards the size limitation of the message. Notes: For outbox going messages, recipient should be included in the virtual message body. R27. Attachment names should be included in the searchable text of messages Description: Attachment names should be included in the searchable virtual message body Hard requirement Required by: Initial rollout R28. No message will have greater than 255 recipients. Description: Bloomberg will break up messages to large numbers of recipients and submit docs, each with a batch of recipients. R29. Submitted messages bodies will be in text format Description: Metadata will be specified by either including it with the message body in a structured format such as XML or SGML, or by naming metadata attributes in struct members of the C API. Soft requirement Notes: Brent: XML, SGML, and RFC 822 can all be parsed by the zone filter R30. At least 40% of the all messages processed will contain bodies with fewer than 200 bytes. Description: Performance requirements are contingent on at least 40% of all messages in any period to have body text of fewer than 200 bytes. What average message size should be accommodated? Does Bloomberg want a system built to handle average case traffic with dynamic expansion, or a system built to handle worst-case lost at the expense of more hardware? R31. Supported languages Description: To be correctly searchable, submitted messages must use languages identified by the Autonomy document, {TBD by Autonomy} Hard requirement Notes: Can we reduce this to one supported language per user, set during initial creation of a user? (incompatible with dynamic inferred user creation.) Language ID and creation of a collection per language for each use increases the complexity of the system and imposes a performance hit on searches (searching multiple collections and merging results). Typically, users only create search queries relevant to one language. Multiple (incorrect) languages submitted to a single collection would remain searchable with substring search; however, documents in languages foreign to the collection would hit haphazardly upon searches. Out of project scope. Multiple languages will require a great number of collections per user. R32. Supported character set encodings Description: Ingested messages must use one of the character set encodings identified in Autonomy document {To be filled in by Autonomy} to become correctly searchable Hard requirement R33. Effect of unsupported languages or character set encodings Description: Submitted messages in other languages or character sets may not be searchable, but will not harm search functionality of valid documents. Such un-indexable message exceptions will be recorded in a log. Hard requirement Required by: Q/A Pilot rollout R34. At least 75% of all messages submitted will be English Description: At least 75% of all messages submitted will be English-language messages using the UTF-8 character set code page. These messages will be submitted with the language and character set code page correctly identified by Bloomberg via the provided API. This requirement may be changed to demand an alternate code page (for example, Bloombergs internal modified-ASCII code page instead of UTF-8) at Autonomys discretion, up to the end of the 18th week after the project start date(*) The only reason Verity would ask to change the code page is to best meet Bloombergs requirements. R35. At least 85% of all ingested messages will have language and character set pre-identified Description: The code page (character set) and language will be correctly identified for at least 85% of messages submitted for ingestion via the C API Hard requirement Notes: The % of docs with language known is now about 90%, but will drop, possibly to about 80%. R36. Messages metadata Description: Messages contain Sender, From, Date, Subject header fields that can be returned in search results. Each field consists of 80 chars or fewer, or enumerated integral values between 2,147,483,647 and 2,147,483,648 Hard requirement R37. Messages contain a system folder identifier Description: Messages contain a mailbox identifier (such as new, deleted, sent, etc.) Hard requirement R38. Message recipients will not be shown in message headers of incoming system folders Description: Message recipients will not be included in message headers, but will be communicated via the C API Hard requirement Date sort by ingest date Performance Requirements (derived from Bloomberg/Autonomy data) Rephrase throughput numbers in units per users per second? R39. Ingest for search performance (time to searchability) R39.1. Number of messages throughput Description: System must handle throughput up to 625,000 msgs per hour comprising not more than 1 GB per hour ; 4000 peak in any 10 seconds Hard requirement Required by: R39.2. Worst case allowed latency is 2-3 seconds This needs to be qualified betterdifferentiate between average case and during peak load. Description: Hard requirement Required by: R40. Search performance R40.1. Number of searches throughput Description: System must handle throughput of up to 1200 searches per minute, 200 peak in any ten seconds. Hard requirement Required by: R40.2. Worst case allowed latency is 1 second This needs to be qualified betteraverage case over 24 hours, & during 10 seconds of peak load. Description: Hard requirement Required by: Notes: Bring down average case by opening and priming collections upon user activity. . Notification of logout can occur also, but most users dont log out. See requirement 18. Number of active users during peak is about 50,000 Are there any performance requirements for notifying open/active searches of new results from newly ingested messages? R41. Highlighting performance R41.1. Throughput highlighting messages Description: System must handle throughput of up to 1200 messages per minute, 200 peak in any ten seconds. Hard requirement Required by: R41.2. Worst case allowed latency is 2 seconds. Qualify this for peak load? Description: Hard requirement Required by: Notes: Chris: prefetch doc(s) for viewing, once we return a result list? R42. Scaling of system R42.1. Number of users Description: The system will initially meet the performance and other requirements named in this document for up to 200,000 users. Through approximately linear addition of hardware, the system will be capable of expanding to host up to 400,000 users while remaining within the relevant performance metrics. Hard requirement Required by: R43. Ingest to folder profiler performance (same for classifier?) R43.1. 500 ms worst case, latency. This needs to be qualified better. Description: Soft requirement Required by: Hardware requirements Bloomberg will provide a Storage Area Network  {If use of a SAN will be required, we can respond to the terms of that requirement with what performance we will demand from the SAN} (SAN) and require the search system to store all permanent data on that SAN. (i.e. loss of nodes will never permanently lose data so long as SAN is intact.) {Question for Bloomberg: is SAN use, in fact, a required characteristic?} At this time Autonomy hopes to further discover the characteristics and requirements regarding Bloombergs SAN storage in order to completely understand associated design implications. Is it a Centera SAN provided? Will the SAN provide read-write access? If existing SAN is a WORM only providing archive, a read-write near-storage SAN will be required? Please provide system I/O and device performance metrics for the SAN. For example, what disks and network I/O devices will be used, and what associated performance that will be available? The search system will consume no more than {TBD by Autonomy} Tb of storage on the Bloomberg SAN {TDB by Autonomy}. What is the minimum throughput required for the WAN between remote failover sites (NY, NJ)? What are the requirements of mean uptime of this WAN? Cost requirements Initial hardware requirements necessary to meet system specifications, and their associated costs, are still under investigation and will be provided in the final requirements document. Autonomy will offer system support and maintenance based upon final system hardware and software configuration. {TBD: Autonomy should determine worst-case support and maintenance costs, not to be exceeded, and offer here to Bloomberg.} A complete hardware bill of materials for the initial system will be available in the final requirements doc. {To be filled in by Autonomy} {To be filled in} Who will be responsible to purchase the development and production hardware? Who will be responsible to purchase any required development and/or production third party software? Incomplete specifications I have not figured out how to specifically state the operating boundaries and requirements for these systems yet. Up to fifteen personal folders per user can be created to classify and filter ingested messages. Each folder will have an associated query defining which messages to route into that folder {To be filled in by Autonomy: name aggregate limits on search operations?} {To be filled in: limits on latency of filtering alert notifications} Automatic classification of messages across 15 Bloomberg priority message types {What does this mean?} Future and optional features Note: Due to day-to-day schedule slips because of contractual issues, certain features may be at risk for inclusion in the basic MSG unit delivery in June. Example features that might behoove us to make optional include remote replication and the folder profiling system, which acts largely independently of the Search/Index/View system. Persistent, notification of hits in newly arriving messages, for active update of open search sessions. Ingest and search of attachments {TBD by Autonomy: fill in supported attachment typespdf, word, etc.} Note that attachment support will require some additional data characteristics (what percent of data is pdf, etc.) in order to estimate performance Reasonable modifications to Autonomys default thesaurus will be made, or a customized knowledgebase will be provided, as possible, to accommodate industry-specific linguistics identified by Bloomberg. TDB by Bloomberg: Provide a list of the industry-specific linguistics to be accommodated Required Deliverables If required, Verity can provide our testing tools as an example to Bloomberg for testing the API. {When would this be required?} A design for an implementation that will ultimately meet requirements with reasonable predictability Within four weeks from project start (*), Autonomy will provide a detailed, development plan with periodic measurable milestones, leading to a predictable fulfillment of all requirements by project completion. {To be filled in by Bloomberg} Are there any specific milestones or Audit points already known to be desired? What hardware will Autonomy require to be available, and by when? {To be filled in by Autonomy. Name offsite and on-site systems in N.Y.}  Verity must provide documentation describing configuration and feature options of VDK search and indexing, profiling, language identification, and document viewing. Mohan would like here a summary of configurable features in. Present summary of features? Present features of different query parsers? Other requirements Bloomberg will provide 10 representative messages before start Bloomberg will provide 100 representative messages before end of week 2 Bloomberg will provide 1,000 representative messages from at least 10 users by end of week 6 Bloomberg will provide 250,000 representative messages by end of week 12 The messages will be from at least 25 users The messages will span at least 3 months use The messages distribution across time and across users from which they come will be representative of entire Bloomberg user base. Sample message sets of size 10 and 100 will be non-sensitive data that can be used off-site by Autonomy. Autonomy Professional Services may sanitize the sets of 1,000 and 100,000 messages for transfer outside the Bloomberg network by replacing user IDs and subject and body text with random content of similar length and complexity. Such content may be screened by Bloomberg personnel for verification of sanitization. * Project start is earliest date on which both Autonomy and Bloomberg have signed the SOW and formal requirements.      Autonomy Professional Services Page  PAGE 16 of  NUMPAGES 16  Autonomy, Inc. 894 Ross Drive Sunnyvale, CA 94089 Attn: Cindy Johnson Phone: (408) 541-1500 Fax: (403)-770-8448 Need a SCOPE section as this doc refers phase-I reqs only. Need unique ID for every requirement. This is better to track and later would be used for Traceability Matrix (for mapping test cases etc). bdm 1/27/06: I am noting required milestone dates and soft/hard notations for each item. Ive added a numeric ID for each line item Need parametric search based on: 1. Date 2. TO/From 3. Keywords 4. Folder to search bdm 1/27/06: Added listed of searchable metadata fields. Note that Autonomy provides a feature known as parametric search that is unrelated to this project. Why? Probably we need 100. bdm 1/27/06: changed to 100. This number can be anything, but eventually we should settle on a specific value so that we can observe the load and data flow of searches. We need by message date and relevance. I cannot think of a scenario when we need by ingest time. bdm 1/27/06: references to ingest time have been removed. List is not complete: 1. MSG type (internet or BB) 2. Read Flag 3. Folder 4. MSG Time 5. Sender/Rcvr Info (user#, username) 6. Subject bdm 1/27/06: Noted items to be returned It should highlight keywords in: 1. MSG body 2. MSG Subject 3. MSG attachment names 4. Sender/Receiver? bdm 1/27/06: Noted items to be highlighted Why is this required? Instead, a dynamic approach where collections can be setup for new users on the fly would be better. bdm 1/27/06: Dynamic approach listed as a requirement. There are other operations: undel, purge depending on inbox, outbox etc. Basically, there is a need to define an attr folder on the verity MSG schema. bdm 1/27/06: Text changed to insert and remove to avoid miscommunication with regard to Bloomberg delete and undelete folder-based operations. This is not acceptable as we might not index that msg ever? bdm 1/27/06: The system design will include hardware recommendations to achieve the desired level of redundancy in the SAN. Probably we should go with UTF-8 and minimize this overhead on verity. BB specific issue: How to handle fractions from FONT2 code page? Updates can happen for: 1. Folder (5 possible values as listed above) 2. Read Flags (unread ( read) 3. Retract Flag bdm 1/27/06: Noted updatable fields.  Meaning which folder (inbox/outbox?) msg belongs to? SOW says 5 years bdm 1/27/06: Any particular maximum amount of data can be accommodated, at the expense of additional hardware. Requirement reset to 5 years. Fallback? bdm 1/27/06: Added descriptive text During turning of a MSG machine, no traffic for ingest/search requests would be coming from that machine. Upon turning, this is automatically restored. Anything expected from BB end? bdm 1/27/06: Security of the network is left to Bloomberg. We need: following folder info: 1. Inbox 2. Outbox 3. Deleted Inbox 4. Deleted Outbox 5. Drafts bdm 1/27/06: Noted. A better word is user performing search as it depends on whether which mailbox is user is searching (inbox or outbox) Also BCC nature of recipients should be preserved, as this is the default BB MSG support. bdm 1/27/06: Text changed, and BCC behavior noted. Why language? If needed, what exactly need to be passed. bdm 1/27/06: language removed. Need to sort out format/encoding? XML? bdm 1/27/06: James leans towards C API struct members. Soft requirement.  Prefer to use term MSGID. Yes, MSGID would be immutable bdm 1/27/06: Text changed to use MSGID Need to sort out encoding details for Ingest and Search? UTF-8. bdm 1/27/06: UTF-8 agreed upon Remaining msgs?? bdm 1/27/06: Erroneous text removed. This would be a enumeration with following: 1. Inbox 2. Outbox 3. Deleted Inbox 4. Deleted Outbox 5. Drafts User Info: 1. User# (unique) 2. UserName 3. User Email Address (in case of internet) Does this include the max 32k recipients mentioned before? UTF-8 ?? Few hundred bytes for body text. Depends on performance characteristics of verity backend. See mp14 comment for detailed list We need to see latency numbers in different load scenarios. bdm 1/27/06: Erroneous references to ingest date removed. Assuming 15M messages per day, it comes to on an avg 625k per hour?? bdm 1/27/06: Number changed What are the assumptions from SAN perspective for the above latency numbers? Application test harnesses to verify C-API and performance/latency requirements.  Verity backend should be configurable in general and thats a requirement. Autonomy Professional Services Requirements Document :;BCDEK\]l!"12^_`wxy34Z[\ojU jU0JjUhCJhmH nH uCJ0JhjUh jUhh @OJQJCJ :>*CJ5CJ 5:CJ5CJ B*ph5B*CJ(ph55CJj5CJUCJ4DEK\]lm $$Ifa$$If$ $a$ $@&]a$ $&dPa$$]a$$]a$]Ӗ'^!"woiiiii_ xx$If$If$If4$$Ifl" ! t4 la. $ $$Ifa$E$$Ifl0" t4 la. "1y%3qrt $$Ifa$ $ $$Ifa$'$*$If$IfopQ R ]     z { | lm,-9ik45  iw/۾۱۫۱ۢۢ۫ۑ H*OJQJj0JOJQJUB*OJQJph *OJQJj0JCJOJQJU >*OJQJB*OJQJph 5OJQJ5>*OJQJOJQJ j0JU 5B*ph>*CJmH nH u5 jU9JK$a$!$*$$$a$ *$@&  !*$@& *$@&^G$$Ifl0" t4 la.Q R ] o|$$IflF # 0    4 la$If *$@&   ' . ` a o w |(| ||$$IflF # 0    4 la$If       |\|t|zzzz|$$IflF # 0    4 la$If   ~ 0 ' ^`^ p0^p`0 @ `^@ `` 0^`0` p`^p``'(i9jkJ[xyiw ! @ `^@ `` 0^`0 ^` ^`@ ^@ @ `^@ ``^j"xybc 0^`0@ ^@ ^ `^`` p0^p`0^ @ `^@ `` 0^`0a  ####$$$$ % %&& & &&'e(((7*8**--c./11|22:3q3333366666788*9k9l9m99999999o:q:r:7B*OJQJph j B*phj0JOJQJUB*H*OJQJphB*OJQJphj0JCJOJQJU *OJQJB*OJQJphOJQJA9!J!g!!#$$ %%%&&e&o'''e(f(()) 0^`0 !^ @ `^@ `` 0^`0 0^`0p^p p`^p``))8***+c,t,,,,-.>.\./0121311222 @ ^@ ` 0^`0 ^` @ `^@ `` ^` !p^p p`^p``293:3q33 4'45[6666678688*9l9m99 ^`^ 0^`0^ p`^p`` ! @ ^@ `  !^ @ `^@ ``99 ::q:r:~:::;;S;T;;D<U<o<<w=x=== >$>%>>>p^p 0^`0^ p`^p``r:~:;R;;;;;v<<<v=%>>>>??@@C1C2C3CHDWDDDDDVEEFFFGGoGGGHHHHHHHIHIIILIYIIJ9J;JLJJJLMM6NRQSSSTTVVWWWWW 7OJQJj0JCJOJQJUB*OJQJph B*phB*OJQJph j0JU *OJQJOJQJ >*OJQJJ>>>(??????S@a@r@@@@AAA2C3CCXDiDwDD @ `^@ ``  !^ !^ p`^p`` ^`DDD+E* 7B*ph 7B*phj0J7OJQJU7 *OJQJj0JCJOJQJUj0J7U 7OJQJOJQJB*OJQJph>[[m\~\\\\Z]v]]t^u^^^ ______<`M`[`aa5a  !^ ^` @ `^@ ``  !^5aaaaa3bbbbbbcccOdPdeddMeeee 1p`^p``1 p`^p`` ! @ `^@ ``  !^ ^` `^``eRfcffff7g8gog1hBhhhhzi{iVjWjpjjkmmp^p p`^p`` ^` p`^p`` ^`1 1p`^p``mmnnnnooo p pGprrrsstttuuuEuuuuv p`^p``1 ^`mmrnnnnpprr/r0r9rrrrstttYtZtuuuuvuvvvvvvwwww)x*x[xxxxy9zN{{{||}[}~~  Egcƿ B*phj0JOJQJU >*OJQJCJ B*CJph>*CJj0J7OJQJU7 *OJQJj0JCJOJQJU H*OJQJB*OJQJphOJQJAvuvvvvvwwXw}w xx)x*xxxxxxx!yyyy @ `^@ ``1^1 ^` p`^p`` p`^p``yy:zHzYzgz{M{N{{{{|y||||||}}\}]}t}}~~1$a$@ ^@ @ `^@ ``1^~~~!hvKL#$LMmnσЃwxd^d ^` 1^1 @ `^@ ``cJLnЃwxC2†ԈgΉЉ@ʋoȍɍʍߍbʎ ?|ȑɑʑݑfT  jUB*OJQJph j0JU B*CJphCJ>*B*CJphj0JOJQJU >*OJQJ>*CJOJQJB*OJQJph B*ph@xDE34†!"ӈԈ fgωЉ?@ ^`oɍʍcdɎʎ ɑʑݑefÒĒ $a$ ^` 9fST XYZ  !H$ ^`$a$ & F h^49:@ACDHISTVWXYZ[^іӖԖ%&z6ߙD~/01śƛǛByz{abcIͼͼͷ B* ph j0JUjUmHnHuCJ0JCJ!0J5CJOJQJhmHnHuj0J5CJOJQJUh0J5CJOJQJh CJOJQJCJjCJUmHnHu=Z\]^m|ЖіҖӖ%z6D0ƛBz$a$$a$baП_)Ң`ӣ8Ѥ>Хڥ (^(`IJaП^_`k)*JҢ@_`aңӣԣ789yФѤҤ>?Хѥڥۥ89\]ӦԦզ678קا'[\^_OJQJ5CJ j0JU B* ph jP8\Ԧ7ק&'\]^_*$a$ 2 0 0&P1P/R / =!"#$%DyK jcariello@bloomberg.netyK >mailto:jcariello@bloomberg.netDyK Mpatnam@bloomberg.netyK :mailto:Mpatnam@bloomberg.netDyK dneubert@verity.comyK 6mailto:dneubert@verity.com i0@0 Normal_HmH sH tH 66 Heading 1$@& 5CJhbb Heading 2,H2,Chapter Title$$@&a$5CJ^Jh<< Heading 3$$-D@&a$5hPP Heading 4,Map Title$@&5CJOJQJj!j Heading 5,Block Label$$d<(@&a$CJOJQJhu>@> Heading 6$$@&]a$CJ66 Heading 7$$@&a$50@0 Heading 8$@&5< < Heading 9 $@&5CJOJQJ<A@< Default Paragraph Font,@, Header  !, @, Footer  !*)@* Page Number58B@"8 Body Text$a$ CJOJQJ6'@16 Comment ReferenceCJ,@B,  Comment Text:R: Task$ & Fa$5CJOJQJBbB SubTask$^a$56CJOJQJLrL Normal Indent$^a$CJOJQJuBB HTML BodyOJQJ_HhmH sH tH <C@< Body Text Indent ^RR HTML Heading 1"5CJ0OJQJ_HhmH sH tH (U@( Hyperlink>*B*8V@8 FollowedHyperlink>*B* 8Y8  Document Map-D OJQJFF TOC Based P @OJQJu<P@< Body Text 25@OJQJh8/@8 List h^h` OJQJuHOH Text body !$*$a$CJOJQJmHnHu6Q"6 Body Text 3" CJOJQJ W@1 Strong5$X@A$ Emphasis64R4 Table Text%<@CJ:b: Table text&$ `0^JDOrDWW-Body Text 2'*$CJmHnHu@@  Balloon Text(CJOJQJ^JaJN"N Caption,Figure Heading )xx5\X>@!X Title*$dd@&[$\$a$"5@CJKHOJQJ\^J aJ >J> Subtitle+$<@&a$ CJ^JaJ22 P00_Bullets , & FR^R Normal (Web)-dd[$\$CJOJ PJ QJ ^J aJ\0\ List Bullet#. & F hTTL^T`LCJOJQJaJ!codem/$xx$d!%d$&d!'d$-DM N!O$P!Q$^a$%5@CJ OJ QJ \^J mHnHu 00CJLR@L Body Text Indent 210^`0^J@"@ xl242$dd[$\$a$CJPJ ^JaJ@2@ xl253$dd[$\$a$CJPJ ^JaJlBl xl2684$dd$d-D@M N[$\$a$B*CJPJ ^JaJphLRL xl27!5dd%dO[$\$CJPJ ^JaJ@b@ xl286$dd[$\$a$CJPJ ^JaJ@r@ xl297$dd[$\$a$CJPJ ^JaJ@@ xl308$dd[$\$a$CJPJ ^JaJxx xl31C9dd$d%d-D@M NO[$\$B*CJPJ ^JaJphll xl328:$dd$d-D@M N[$\$a$B*CJPJ ^JaJph~~ xl33I;$dd$d'd-D@M NQ[$\$a$B*CJPJ ^JaJphRR xl34'<$dd'dQ[$\$a$CJPJ ^JaJVV xl35!=dd%dO[$\$B*CJPJ ^JaJph\\ xl362>dd%d&dOP[$\$CJPJ ^JaJRR xl37'?$dd&dP[$\$a$CJPJ ^JaJRR xl38'@$dd&dP[$\$a$CJPJ ^JaJbb xl398A$dd&d'dPQ[$\$a$CJPJ ^JaJR"R xl40'B$dd$dN[$\$a$CJPJ ^JaJR2R xl41'C$dd$dN[$\$a$CJPJ ^JaJbBb xl428D$dd$d'dNQ[$\$a$CJPJ ^JaJRRR xl43'E$dd&dP[$\$a$CJPJ ^JaJ2b2 0hiF0^`0CJ&r&L1G^CJ22 1hiH0^`0CJ&& 2I^CJ22 2hiJp0^p`0CJ&& 3Kp^pCJ22 3hiL@ 0^@ `0CJ&& 4M@ ^@ CJ22 4hiN0^`0CJ&& 5O^CJ22 5hiP0^`0CJ,, Bullet Q & FCJ:": CENTER 1R$$a$;CJ626 CENTER 2S$$a$CJ<B< CENTER 3T$$a$ 5;CJJJTOC 1"U $ @((^@` mHnHuFFTOC 2V $ ^`aJmHnHu:: TOC 3W $  @^ `@622 TOC 4 X^ CJOJQJ22 TOC 5 Yp^p CJOJQJ22 TOC 6 ZL^L CJOJQJ22 TOC 7 [(^( CJOJQJ22 TOC 8 \^ CJOJQJ22 TOC 9 ]^ CJOJQJ(( Center 4^CJ..  Footnote Text_8&@8 Footnote ReferenceH*T#T Table of Figuresa $@JH^`H::: Table Headingb$CJ\nn B COVER headlinecx*$@&](;B*CJ4OJ QJ _HmH phVsH tH ^^ B COVER Subtitledx%B*CJ$OJ QJ _HmH phOOOsH tH ZRZ B COVER text ex*$%B*CJ OJQJ_HmH phOOOsH tH POaP B Hyperlink*>*@B*CJEHOJQJRHdphffwhVVrV Bullet2#g & F T[x<^[B*CJaJphNN font5hdd[$\$"6>*B* CJPJ ]^JaJphHH font6idd[$\$>*B* CJPJ ^JaJph<< font7jdd[$\$CJPJ ^JaJ xl44Zk$dd$d%d&d-D`M NOP[$\$a$CJPJ ^JaJtt xl45Il$dd$d&d-D`M NP[$\$a$CJPJ ^JaJ xl46Zm$dd$d%d&d-DM NOP[$\$a$CJPJ ^JaJtt xl47In$dd$d&d-DM NP[$\$a$CJPJ ^JaJ xl48Zo$dd$d%d&d-D`M NOP[$\$a$CJPJ ^JaJtt xl49Ip$dd$d&d-D`M NP[$\$a$CJPJ ^JaJ xl50Zq$dd$d%d&d-DM NOP[$\$a$CJPJ ^JaJt"t xl51Ir$dd$d&d-DM NP[$\$a$CJPJ ^JaJ\2\ xl522sdd'd-D`M Q[$\$CJPJ ^JaJB xl53kt$dd$d%d&d'd-DM NOPQ[$\$a$B*CJPJ ^JaJphR xl54ku$dd$d%d&d'd-DM NOPQ[$\$a$B*CJPJ ^JaJphRbR xl55'v$dd-DM [$\$a$CJPJ ^JaJr xl56kw$dd$d%d&d'd-D`M NOPQ[$\$a$CJPJ ^JaJ xl57kx$dd$d%d&d'd-D`M NOPQ[$\$a$CJPJ ^JaJ xl58ky$dd$d%d&d'd-DM NOPQ[$\$a$CJPJ ^JaJbb xl598z$dd$d-D`M N[$\$a$CJPJ ^JaJtt xl60I{$dd$d%d-D`M NO[$\$a$CJPJ ^JaJbb xl618|$dd$d-D`M N[$\$a$CJPJ ^JaJtt xl62I}$dd$d%d-DM NO[$\$a$CJPJ ^JaJbb xl638~$dd$d-DM N[$\$a$CJPJ ^JaJff xl642dd%d-DM O[$\$B* CJPJ ^JaJphjj xl656dd%d-D9DM O[$\$B* CJPJ ^JaJph\\ xl662dd'd-DM Q[$\$CJPJ ^JaJ" xl67k$dd$d%d&d'd-DM NOPQ[$\$a$CJPJ ^JaJ\2\ xl682dd'd-DM ̙Q[$\$CJPJ ^JaJB xl69Z$dd$d%d&d-DM ̙NOP[$\$a$CJPJ ^JaJtRt xl70I$dd$d&d-DM ̙NP[$\$a$CJPJ ^JaJb xl71k$dd$d%d&d'd-DM ̙NOPQ[$\$a$CJPJ ^JaJr xl72k$dd$d%d&d'd-DM NOPQ[$\$a$CJPJ ^JaJ xl73Z$dd$d%d&d-DM NOP[$\$a$CJPJ ^JaJtt xl74I$dd$d&d-DM NP[$\$a$CJPJ ^JaJTT xl75!dd-DM [$\$CJOJ PJ QJ ^J aJdd xl762dd$d-DM N[$\$CJOJ PJ QJ ^J aJXX xl77!dd-DM [$\$56CJPJ \]^JaJZZ xl78%dd-D9DM [$\$B* CJPJ ^JaJphff xl792dd%d-DM O[$\$B*CJPJ ^JaJph xl80Z$dd$d%d&d-DM NOP[$\$a$CJPJ ^JaJt t xl81I$dd$d&d-DM NP[$\$a$CJPJ ^JaJv v xl82Cdd$d'd-DM NQ[$\$CJOJ PJ QJ ^J aJd" d xl832dd'd-DM Q[$\$CJOJ PJ QJ ^J aJ\2 \ xl842dd'd-DM Q[$\$CJPJ ^JaJ~B ~ xl85I$dd%d'd-DM OQ[$\$a$B*CJPJ ^JaJphtR t xl86I$dd%d'd-DM OQ[$\$a$CJPJ ^JaJtb t xl87I$dd%d'd-DM OQ[$\$a$CJPJ ^JaJbr b xl888$dd'd-DM Q[$\$a$CJPJ ^JaJt t xl89I$dd&d'd-DM PQ[$\$a$CJPJ ^JaJ8AB8 Comment Subject5\N+ N  Endnote Text $ 0^`0a$CJ6*@ 6 Endnote ReferenceH*r r bText1$ & F L]^`La$$B*CJKH OJ QJ ^JaJ hphV> > Bullet 3 & F ^b b Bullet 2. & F hL<<^`LB*CJaJphP P highligh & F ^ B*aJphOOO>> Note & F x<B*CJaJphOOO8 8 nText & F B*aJphOOOd" d Bullet List & F p<%B*CJOJQJ_HmH phOOOsH tH L2 L aText<]^B*CJPJ ^JaJphDT!B D Block Textd^ B*CJph\SR \ Body Text Indent 3<^6B*CJ]aJphZA b Z Bullet 1# & F L^`L5B*CJ\phN r N Bullet 4 & F^B* CJaJph3JO J Bullet Char#CJOJQJ_HaJmH sH tH u@ @ Contact & F<B*^JaJphL L Figure Text $<a$6B*\^JaJph Observation1$ & F (^`(a$*6B*CJPJ ]^JaJnHphtHu\ \ SLA)$ & F (^`(a$6B* ]nHphtHuT T B Copyright*$%B*CJOJQJ_HmH phOOOsH tH 0h@ 0 HTML Variable6]< < level 3 & F < B*aJphR R Number 1" & F h@ <^ B*aJphB B Question & F <B*^JaJphA "  QuoteF.F  TOA Headingx5B*\^JaJph@L@ Dated<0$] B*ph8R 8 From:<B*CJ^JaJphZZ Name!d<&dP@B*CJ6OJ PJ QJ ph\ r \ Goal! & F TT|^T`| B*CJPJ ^JnH phtH uR R B Header *$%B*CJ4OJ QJ _HmH phVsH tH . . B SubheadxCJL L Index 1<^`B*OJQJaJphL L Index 2<^`B*OJQJaJphL L Index 3<^`B*OJQJaJphL L Index 4<^`B*OJQJaJphLL Index 5<^`B*OJQJaJphLL Index 6<^`B*OJQJaJphLL Index 7<^`B*OJQJaJphLL Index 8<^`B*OJQJaJphLL Index 9p<^p`B*OJQJaJphH! H  Index Heading<B*OJQJaJphZQB Z Table Header Text ((5@B*CJOJQJphHR H aIOItem`<^``B*CJaJphFF H3$dd7$8$@&H$5CJOJQJ\aJ>> H5$dd7$8$@&H$5OJQJ\h h Preformatted1 # ~= z9!v%7$8$H$ OJ QJ ^J h h Style Code + Courier New BlueB*CJOJ QJ aJph: : CodeB*CJOJ QJ ^J aJpha (Style TOC 2 + Left: 0.5" Hanging: 0.5" $0^`0:B*OJQJaJphu 4Style Number 1 + (Latin) Arial (Complex) Arial 10 pt! & F @ 88^8*5B*CJPJ \^JaJnHphtHuO >Style Number 1 + (Latin) Arial (Complex) Arial 10 pt Char Char55CJOJPJ QJ\^J_HaJmH nHsH tHu Style Heading 1 + Bold+$ & F <1$^`"5B*CJ KH \^JaJhph1 Style Heading 3 + 10 pt8$ & F   0-D1$M ^ `05B*\^Jhph"? " ClosingFO F DeltaView Insertion>*@B*phJO! J DeltaView Deletion57@B*\ph4Z2 4 Plain Text OJ QJ ^J vB v Sub-Title'$&d@& P[$\$*5:@B*CJ$OJQJ\^JaJ0ph&@R & Signature6_69mpatnamz l 4  !$)-/57@HEFRSTUXYZz[:\w`mce/nYprs{߉_mp"ՁmpmpMCmpYImpImp3Kmp8ՁmpaՁmpFmp+GmpRQmpKmp'ׁmp?ׁmp\Ump3mpMmpNmp-mp1PmpWPmpPmpPmp`mpQmpUmpUmp Vmp=WmpWmp XmpXmpZmpc[mpRG ] V ) 3 e k)edSV_QR]'.`aow ~  0 '(i9jkJ[xyiwj"xybc9Jg !!!""e"o###e$f$$%%%8&&&'c(t((((-*>*\*+0-2-3--...9/:/q// 0'01[2222234644*5l5m555 66q6r6~66677S7T77D8U8o88w9x999 :$:%:>::(;;;;;;S<a<r<<<<===2?3??X@i@w@@@@+A>DHXOU[5aemvy~x Z_VXY[\]^_`acdefhijklnopqstuwxy{|~^W:B1_w3[o_&XXX5<?DOR!t    ,b$?6v{E˳ijO@ 0(  B S  ?(  \  3 " P  3 " V`3*Gu u ClientName _Hlt69097118 _Hlt125730630 _Hlt125730551;K`f`@BKag`! "ՁMCYII3K8ՁaՁF+GRQK'ׁ?ׁ\U3MN-1PWPPP`QUU V=WW XXZc[[   j$)-/s5d7@3EFRSTU XYZa[\o`bcemEprs{ʉ  l 4  !$)-/57@HEFRSTUXYZz[:\w`mce/nYprs{߉]f6?  n v VY}AEin #-+5XbnwL$U$d%m%''((**6,?,.".g/o///0 090<0D0L0L1O12#2X3\33344!6)688mEvEGG;HDH;JDJJJJJ(L1LGLPLvLL0M9MMMMMYNbNVVVVVWWWYYYY_ZhZ[[\]^^E_M_W_e___``bb|cccdddeeiiijIjRjjkkk.m7mmmnnppIsVsss!y)yx{$-&foĎ͎ 9DHWҒӒ z}69DG BEqzۙޙadu~ЛӛknJM{Ҟ՞@Cy|MR_g &']` 9DHW` 9DHW`Brent D. MillerVC:\DOCUME~1\BMILLE~1.BMI\LOCALS~1\Temp\AutoRecovery save of MsgRequirements_060127.asdBrent D. MillerVC:\DOCUME~1\BMILLE~1.BMI\LOCALS~1\Temp\AutoRecovery save of MsgRequirements_060127.asdBrent D. MillerVC:\DOCUME~1\BMILLE~1.BMI\LOCALS~1\Temp\AutoRecovery save of MsgRequirements_060127.asdBrent D. MillerVC:\DOCUME~1\BMILLE~1.BMI\LOCALS~1\Temp\AutoRecovery save of MsgRequirements_060127.asdBrent D. MillerJ\\192.168.2.38\bmiller\work\veroquest\bloomberg\MsgRequirements_060127.docBrent D. MillerJ\\192.168.2.38\bmiller\work\veroquest\bloomberg\MsgRequirements_060127.docBrent D. MillerJ\\192.168.2.38\bmiller\work\veroquest\bloomberg\MsgRequirements_060127.docBrent D. MillerS\\192.168.2.38\bmiller\work\veroquest\bloomberg\MsgRequirements_060128_internal.docBrent D. MillerS\\192.168.2.38\bmiller\work\veroquest\bloomberg\MsgRequirements_060128_internal.doc Joe&Joannie?U:\accounts\jkuefler\verity\MsgRequirements_060128_internal.doc1^ .P#M"+>8$Bz8QCTR9  D  XZ $N i< YIؠ9+ `'L >_O K A,:'Y   $pH!e{z!ٔN/"L"6G#pu:' C ( J4.ߦ81 ^b> m? I1(F$| G noI R,k-I oWI %dJ hAKBO oOF<G(j8Zaz!A,YIzxR6G#H!|brv\hAK Gi<KC ($NG !s%dJm?%n\e."Y>_OoWID PO oOR9 'Y $ zXZu:'k-I9+21   '.`aow ҒӒ&'`@B_P@UnknownGz Times New Roman5Symbol3& z Arial;Wingdings?CitizenBold9Garamond5& zaTahomaI Arial,BoldItalic7&  VerdanaI& ??Arial Unicode MS?& Arial Black?5 z Courier New;SimSun[SOC PMingLiUe0}fԚ"hqqʡffx=M2k!d0dۓ ;s2SOWBloombergMessaging111805Search and Foldering/FilteringSearch Messages Messaging David Neubert Joe&JoannieOh+'0(4H \h    SOWBloombergMessaging111805Search and Foldering/Filteringi David NeuberteSearch Messages Messagingriear Normal.dota Joe&Joannie2e&Microsoft Word 9.0s@G@Ph!@%@%fx՜.+,D՜.+, $ , 4<D LT\d l SOW BloombergoOW David Lingleyo Verity, Inc.o=ۓ SOWBloombergMessaging111805 Title X&.: _PID_LINKBASE _PID_HLINKS_NewReviewCycle_EmailSubject _AuthorEmail_AuthorEmailDisplayName_AdHocReviewCycleID _ReviewingToolsShownOnceAATqH mailto:dneubert@verity.com7mailto:Mpatnam@bloomberg.netJ{mailto:jcariello@bloomberg.netRevMessaging SOW and start datendneubert@verity.comDavid Neuberty./avi  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ Root Entry F ފ%Data 1Table/WordDocument4SummaryInformation(DocumentSummaryInformation8CompObjjObjectPool ފ% ފ%  FMicrosoft Word Document MSWordDocWord.Document.89q