ࡱ> 572343 bjbjCC 4:!!E"7lDDDD|EFLM.M8ڇd>.MjnfL(ډډډ>R$ JE2"@ގlJ*DDډډ$$*** DډD8ډ**f*zD2EAډZ PrƁ).Mt:ʜklU:0jjpU*.M.MDDDD Note, while modifying this document in draft, Id ask that everyone other than the document author please use either MS Word revision tracking or MS Word comments. That allows smooth tracking and integration of various users participation in the drafting process. Thanks, Chris.  ASK ClientName "Organization Name" \* MERGEFORMAT VPS 101 DRAFT January 30, 2006 Bloomberg L.P. Bloomberg Message Search suggested requirements v0.6 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@autonomy.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 Milestone deliverables are discussed in the Required deliverables section of this document. Required by specifications for features refer to milestones named in that section. 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. Core 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: RAD1 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: RAD1 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 call. The number of documents requested per call 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 is practically unlimited in the number of messages returnable per request; however, this number (100) 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: RAD1 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: RAD1 rollout R1.6 Returned results will be sorted by message date or relevance in descending order Hard requirement Required by: RAD1 rollout R1.7 Returned results 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 Autonomy 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: The intended feature behind this requirement is incompatible with caching multiple pages of search results per API call (requirement 1.2) R1.10 Fully integrated into current Bloomberg Messaging Application. Description: It must be possible to submit search queries for documents containing 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: RAD2 rollout Notes: grep-like searches over the bodies of documents are not the strength of VDK. Providing such features would have several caveats, including anomolous behavior (listed below) where whitespace and puncuation characters occur in substrings. Perhaps we should discuss continuing using the existing grep functionality for substring searches, ammended with VDK text searching? Furthermore, even using the ngram assist extension, VDK searches that begin with a wildcard match, for example *begin, are resource-intensive. All of these problems require investigation and may be solvable, if Bloomberg must rely on Verity for grep-like substring searching. Anomoly 1 of 2: In substring queries, multiple consecutive whitespace may be coalesced into a single whitespace. For example, a search for big one would match a msg containing big\t\tone (Note existence of 2 tabs in msg whereas only one space occurs in query)? Anomoly 2 of 2: punctuation characters may be ignored. For example, searching for end may always yield the same results as searching for end! BB would like search to initially behave like the existing grep search.  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: RAD1 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. See questions in comment. 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: RAD2 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: RAD2 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: RAD4 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: RAD3 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} Verity Locale Configuration Guide, v6.1. Hard requirement Required by: RAD2 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: RAD2 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: 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 Hard requirement Required by: Notes: Metadata updates cannot be used to move messages between user-created folders. R44. Ingest and search of attachments Description: Ingest and search of attachments {TBD by Autonomy: fill in supported attachment typespdf, word, etc.} Soft requirement Required by: Note: Attachment support will require some additional data characteristics (what percent of data is pdf, etc.) in order to estimate performance Scalability R5. Dynamic expansion Description: Expanding the system to meet growing demands (scaling) will not require downtime. Hard requirement Required by: RAD4 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: RAD4 rollout Notes: Should this be 15 million messages per day? Any particular 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: RAD4 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: RAD3 rollout Notes: This feature is out of scope of the existing SOW. Multiple redundancy requirements should perhaps be coalesced into one. R55. The search system will use as its platform the Fujitsu 850 system. Description: Bloomberg has identified that it would like the search system to meet all requirements running on a Fujitsu 850. Hard requirement Notes: The underlying requirement behind choice of system is the power footprint of this server. Would it be preferable to list the underlying power requirements? 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 in every 12 total nodes in a cluster 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. Need to further define what a cluster is. 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: RAD4 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: Notes: This feature is out of scope for the project. R13. Is a loss of in-progress search transactions (not ingest) 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. No part of the API code running on the MSG big server will be hang indefinitely as a result of no answer 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. Per 2/2 mtg at Bloomberg, turning will not be required for systems dedicated to VDK search (i.e. non-bloomberg machines) 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 RAD1 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: RAD1 rollout R23.2 Searches can specify descending sorting by message date or relevance Description: Hard requirement Required by: RAD3 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}} Verity Locale Configuration Guide, v6.1 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: RAD1 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? Verity would like a full histogram, so far as available, and as specific data characteristics as Bloomberg is willing to guarantee. 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} Verity Locale Configuration Guide, v6.1 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. Note that, should we determine that the latency and throughput requirements preclude use of the uni locale and filter, multiple language support would require a great number of collections per user, and such an effort would be out of scope of the SOW. Performance testing is required. Meeting performance requirements with the uni filter may require one collection for internal BB docs (known lang/charset/format, all uni options turned off) and one for internet messags (unknown lang/charset/type, uni filtering options turned on). 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} Verity Locale Configuration Guide, v6.1 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 Autonomy 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. The VDK search system will be capable of tracking the message recipient in a field that does not affect search results. Hard requirement Date sort by ingest date Performance Requirements (derived from Bloomberg/Autonomy data)  The following requirements are a generalization that cannot be guaranteed in all cases. These performance requirements should probably be broken out into tabular form, with each latency spec given at 50th (median, not average) and 95th percentiles. This document states requirements at a load level of 200,000 users.  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: Notes: Verify from logs what is the peak load during any hour, not just average during the day. 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? Brent: depending on how difficult it is to meet latency requirements, we may desire the ability to asynchronously send search result highlight info to the viewer (in the form of word positions). BB has been asking if we could send highlight position info with our search resultspresumably because they want to recycle existing code that rendered docs with highlight info from their grep search engine. Reserving the right to require BB to accept (asynchronous) highlight info might help us meet latency requiremnts. 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. .Folder profiling throughput Description: Up to 625,000 msgs per hour comprising not more than 1 GB per hour can be ingested with folder classifications delivered to Bloomberg; 4000 peak in any 10 seconds Soft requirement Required by: R43.2. User folder profiling of each message will have 500 ms worst case latency. This needs to be qualified better. . Description: Soft requirement Required by: {To be filled in by Autonomy: name aggregate limits on search operations?} Hardware requirements R43. Ingest to folder profiler performance (same for classifier?) R43.1. Description: Bloomberg will provide a Storage Area Network  (SAN). Bloomberg will provide any terms or restrictions upon the choice of SAN, and Autonomy will provide a list of preferred SAN systems and what will be demanded from the SAN Soft requirement Required by: R44. The search system will consume no more than {TBD by Autonomy} 50% of the original storage. Description: The search system will consume no more than 1 TB of SAN storage per every 2 TB of searchable messages. For example, with 200,000 users storing 60M of data per day and 50 days of archived messages, the search system would require 3TB of SAN storage... Soft requirement Required by: R45. Description: {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? Soft requirement Required by: Cost requirements R46. A complete hardware bill of materials for the initial system will be made available Description: {TBD by Autonomy} Initial hardware requirements necessary to meet system specifications, and their associated costs, are still under investigation and will be provided by Autonomy as part of a hardware systems design document or in the final requirements document. Soft requirement Required by: Notes: {To be filled in} Who will be responsible to purchase the development and production hardware? R46.1 Bloomberg will provide hardware Autonomy as needed Description: Bloomberg will provide, within 2 weeks of request, hardware from the bill of materials that is needed by Autonomy for developing the search system. R47. A complete bill of materials for required third party software will be provided. Description: Soft requirement Required by: Notes: Who will be responsible to purchase any required development and/or production third party software? R48. System support and maintenance costs will be bounded Description: 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 insert quote here for Bloomberg.} Soft requirement Required by: Incomplete specifications I have not yet figured out how to specifically state the operating boundaries and requirements for the following systems. Automatic classification of messages across 15 Bloomberg priority message types {What does this mean? If this is differenent that user folders, can Bloomberg define this classification?} Future and optional features 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. In order to guarantee core functionality, it might behoove us to omit non-essential features from the requirements until such a time that including them in a later phase does not put core functionality at risk. Example features that might be optional include remote replication and the folder profiling system, which acts largely independently of the Search/Index/View system. Cbiow, 1/26/06: Dont raise this feature yet: 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 R49. Sample tests will be provided. Description: Autonomy will provide testing tools used by Autonomy as sample code for Bloomberg to use in testing the API. Soft requirement Required by: When is this needed? R54. Performance-measuring test harness will be provided. Description: Autonomy will build a test harness for isolating and measuring the search subsystems independently from the MSG machings. This test harness will be provided to Bloomberg in full source code and, if applicable, in compiled form. This test harness will allow specification of loadmodel, with exponential (Poisson) distribution of load-inducing events.  Soft requirement Required by: When is this needed? Notes: Rather than providing compiled form, would it be more useful to deliver actual use of the test harness system, which is likely to include hardware systems and configuration? R50. A system design will be provided that addresses the requirements in this document. Description: A design for an implementation that will ultimately meet requirements with reasonable predictability will be provided by Autonomy within 4 weeks of project start(*). Hard requirement Required by: Design validation R50.1 Development plan and schedule Description: 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. Soft requirement Required by: Design validation Notes: Considering the desire for a RAD approach, should this requirement be removed? R51. General VDK feature and configuration documentation will be provided. Description:  Autonomy will provide general GA documentation describing features and configuration of VDK. This documentation will not necessarily be specific to the VDK version used in the MSG search deployment (which may not be a generally available version); however, it will be documentation provided with a significantly similar VDK GA release. Described features will include VDK search and indexing, profiling, language identification and document viewing with highlights. Hard requirement Required by: Project start Notes: What features will Bloomberg require being able to tune? Present features of different query parsers? R52. Specific required deliverables Description: {To be filled in by Bloomberg} Are there any specific milestones or Audit points already known to be desired? Does Bloomberg have any features desired to be released in any specific timeframe or sequence? Such requirements should be listed as requirements here. Hard requirement R52.1 The following milestone releases will be delivered Hard requirement MilestoneTimeframeSummaryDesign ValidationWeek 4Proposed C API for index & searchRAD1 rolloutWeek 8Search/index available for implementation explorationRAD2 rolloutWeek 12Message updatesRAD3 rolloutWeek 14Failover, QA Simulation 250K usersRAD4 rolloutWeek 15Administration, collection versioning, scalingProduction rolloutWeek 19Production/stability  Other requirements R53. Bloomberg will provide sample data. Hard requirement R53.1 Bloomberg will provide 10 representative messages by project start Description: This will be non-sensitive data that can be used off-site by Autonomy. Required by: Project start(*) R53.2 Bloomberg will provide 100 representative messages by 2 weeks after project start Description: This will be non-sensitive data that can be used off-site by Autonomy. Required by: 2 weeks after project start(*) R53.3 Bloomberg will provide 1000 representative messages by 6 weeks after project start Description: Bloomberg will provide a set of at least 1000 messages from at least 10 users. These messages will exemplify every language and character set code page that Bloomberg supports internally, and every system folder as well. Required by: 6 weeks after project start(*) Notes: Autonomy Professional Services may sanitize this message corpus 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. R53.4 Bloomberg will provide 250,000 representative messages by the RAD2 rollout Description: Bloomberg will provide a set of at least 250,000 messages by the RAD2 rollout. This corpus will have the following qualities. 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. Required by: RAD2 rollout Notes: Autonomy Professional Services may sanitize this message corpus 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. Next available requirement id: R56. * Project start is earliest date on which both Autonomy and Bloomberg have signed the SOW and formal requirements.      Autonomy Professional Services Page  PAGE 18 of  NUMPAGES 18  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 How so? 1.2 only refers to number of items in a search result setnothing about caching. bdm 2/2/06: changed text to clarify that BB intends to fetch 100 docs per request and show 20 docs per page, thus having 5 pages of results cached from a single call. Caching 5 pages of results precludes the ability to insert newly arrived msgs. Please provide a better example. This particular example is how any type of search would work. Perhaps the intent of this is that it would match a msg containing xxxxbig onexxxx? bdm 2/2/06: improved example to note multiple whitespaces. This would require wildcarding the start of the first term and end of the last term, with serious performance impact. It must not be the default behavior, but could be provided as a legacy option if restricted from suicidal searches, such as (*e, t*) bdm 2/2/06: Bloomberg does, in fact, intend for default searches to act as double-ended wildcard searches. I noted that this is going to be an impediment to Verity search meeting their requirements. 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 Alternatively, user numbers can be cooked as terms of the form user_number_NNNNN bdm 1/27/06: I am not positive what you mean. It sounds like we should split out different approaches for user-searchable fields (i.e. sender = Chris Biow and system-searchable fields (i.e. Sender = 34726). What I was trying to describe was allowing users to search for Chris Biow and find a document, even if the only occurrence of Chris Biow was in the sender field (i.e. include a text user-searchable sender field as a zone in the virtual document). 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. I believe this and related items are intended to capture only the basic nature of the system, avoiding single points of failure through the use of redundant nodes. Perhaps they could be better captured in a single requirement concerning the redundant, scale-out node design. 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. Our conversation of 2/2 indicates that there should be no routine turning requirement imposed by Operations. bdm 2/2/06: noted. 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? bdm 1/27/06: noted that bcc recipients do not contribute to msg size. UTF-8 ?? bdm 1/27/06: noted in R23.4 and R30 Few hundred bytes for body text. bdm 1/27/06: noted in R30 Lets include the full histogram, so far as available. Its needed for a meaningful load model. bdm 2/2/06: Requested histogram a little below this requirement. Why would not a single uni collection per user do the job? bdm 2/2/06: made warning about uni filter conditional. We should test if uni filter/locale can meet performance requirements. Depends on performance characteristics of verity backend. See mp14 comment for detailed list This is an external GUI requirement that does not affect the backend. bdm 2/2/06: noted the implication that we can store a field without it affecting searches. We need to see latency numbers in different load scenarios. bdm 1/27/06: Erroneous references to ingest date removed. We must avoid specifying worst case, as complex queueing systems have unbounded, probabilistic worst cases that generally have no analytical solution, even at a specified load. Use 95th percentile instead. Probably best to break this out in tabular form, with each latency spec given at 50th (median, not average) and 95th percentiles. bdm 2/2/06: Noted refinements necessary, but did not fix them yet. Number of users should be an independent variable. This doc can capture requirements at the 200K users level and so state. bdm 2/2/06 So stated. Assuming 15M messages per day, it comes to on an avg 625k per hour?? bdm 1/27/06: Number changed We could make that an optional optimization for later in the project, but its not a requirement. bdm 2/2/06: noted that we might want to reserve the ability to require them help us with highlights. Assuming 15M messages per day, it comes to on an avg 625k per hour?? bdm 1/27/06: Number changed Presumably this refers to folder-profiling, which is the most latency-critical element. Is this in accordance with the SOW? bdm 2/2/06: I did not see any specific latency numbers in the 111805v3 SOW. What are the assumptions from SAN perspective for the above latency numbers? bdm 1/27/30: The latency numbers merely represent BB requirements; Autonomy will provide a system design and hardware (including SAN) configuration to meet requirements. Latency numbers currently appearing should be within the capabilities of industry-quality SAN configurations. This should be expressed as a percentage of data indexed, with example in TB for initial users and retention period. bdm 2/2/06: done. Application test harnesses to verify C-API and performance/latency requirements. bdm 1/30/06: Added R54. Test harness must allow specification of load model, with exponential (Poisson) distribution of load-inducing events. bdm 2/2/06: do we really want to require this level of detail of the sample code we provide them, if they dont ask for it?  Verity backend should be configurable in general and thats a requirement. bdm 1/30/06: documentation explaining configuration of VDK provided in R51. Autonomy Professional Services Requirements Document PQXYZ[ars78GHtuvIJp jU0JjUhCJhmH nH uCJ0JhjUh jUhh @OJQJCJ :>*CJ5CJ 5:CJ5CJ5B*CJ(ph55CJj5CJUCJ B*ph3Z[ars$ $a$ $@&]a$ $&dPa$$]a$$]a$'$d%d&d'dNOPQ]]E%h`ZZZZ$If$If4$$Ifl" ! t4 la. $ $$Ifa$E$$Ifl0" t4 la. $$Ifa$$If %78G;I $$Ifa$ $ $$Ifa$'$*$If xx$If$Ifpqr   i j u ( 5 2 :;Gwy?@lz2 еЯеЦЦННЦЯЦЌ H*OJQJj0JOJQJUB*OJQJphB*OJQJph *OJQJj0JCJOJQJU >*OJQJ5>*OJQJOJQJ j0JU 5B*ph>*CJmH nH u50J jUjU7b c $a$!$*$$$a$ *$@&  !*$@& *$@&^G$$Ifl0" t4 la. i j u ' ( 5 1 .  p0^p`0 @ `^@ `` 0^`0` p`^p`` *$@&2A 56wGxy ^` ^`@ ^@ ^`^ p0^p`0 @ `^@ `` 0^`0Uflzm%{|^ `^`` p0^p`0^ 0^`0 ! @ `^@ `` @ `^@ `` 0^`0 ^` ^` !!"l"`#a##$%%%|'(p^p p`^p`` 0^`0@ ^@ 0^`0 @ `^@ `` !!!"j"k"l"_###&&&|'/(0(1(J((((((()))))+2,d,e,...P1Q1+2q355D6d666)7`77777y:::::;; <=Y=Z=[= j * B*phj0JOJQJUB*H*OJQJphB*OJQJphj0JCJOJQJU *OJQJ j0JUOJQJB*OJQJphD((())))3*=+z++2,3,f,---.... ^`p^p 0^`0 !^ @ `^@ `` 0^`0 p`^p`` 0^`0./0@0Z0[001 2$2r3444M5666(7)7`77788  !^ @ ^@ ` 0^`0 ^` @ `^@ ``8I:y::::;<$<<=Z=[==~>>>>>???1` ^`^ 0^`0^ p`^p`` ! @ ^@ `[=x=====>>I???>@?@K@@ALAMAsAtACBnBoBBCC DDEFFFGGHHJJKL-L.LXLYLM8M9M_NqNNNNNOLOMOPPPPPPP(Q.Q˹ž𳱳 *7OJQJj0J7U7 7OJQJ B*ph j0JU *OJQJ >*OJQJB*OJQJphj0JCJOJQJUB*OJQJph7B*OJQJphOJQJ???>@?@K@a@@@@ A!AuAB"BOLOMOwO{PPPPPQQ'Q(QfQQRRTRRRRASSS\T1^^ ^` p`^p``.QbQcQfQsQQRSRTRRRRRSST4VJVVl[[\\t]]v_w_`.`/`0`4`>`6atauaabbbdddeeeef~ff*g+grgsgugggɶɫɶɫɶիɶ 7B*ph 7B*phj0J7OJQJU7 *OJQJ B*phj0JCJOJQJU >*OJQJOJQJ j0JUB*OJQJph *7OJQJ 7OJQJj0J7U7B*OJQJph8\TTTTVVVWWWXXXZZZ[\\\ ! ^`^`^1 0^`0 p`^p`` p`^p`` 0^`0 ^`\\\]]]] ^^(^B^C^^x_____b`s````)aaaa @ `^@ ``  !^ !aaaabbbbd dIdd eee]ef,f:f*g+gggg8hIh ^` @ `^@ ``  !^ !gg0h1hWhXhhhiijjjjxkykmm.m/m\o_oo!p"pp?q@q.r/rIrJrbrcrsst/tVtvwxxxxxyyyzz[{^{Q}S}q}r}{}}}}~IJKWXHIJ4E H*OJQJ *OJQJ j0JU B*ph *j0JOJQJU>*B*OJQJphj0JCJOJQJUOJQJKIhWhXhhhiiiiiwjjjjjYkjkxkykkOl`l p`^p`` ! `^``  !^  !^ ^` @ `^@ ```lnlmmmPmnbncnn oo4o5olooo#ppp@qAqq ^` p`^p`` ^` 1p`^p``1 ! p`^p``q.r/rbrsssWthtvxx"yyzzDz{-{L{M{{}}@~~~1p^p ^` p`^p``~JKcFWX߀J4E_` E҄ @ `^@ ``1^ p`^p``1 ^` p`^p``E]^`npPQR݅ av ::P89OzԐՐ+ۑ ЪЗ >*OJQJ j0JU *OJQJB*OJQJphj0JCJOJQJUOJQJj0JOJQJUCJB*CJH*ph B*CJphj0JCJU>*CJj0J7OJQJU7;҄QRޅ $IņӆԆbpBuv$a$@ ^@ 1 ^`1^ @ `^@ ``6 ,:Qu&7EF͏ޏ @ `^@ ``1^1ޏ89O %34: w p`^p``1` ^`1^1 @ `^@ `` 34G wDwۗݗޗ9:TΙ%&'#ՠܠQRKQʨƩ 5OJQJCJ j0JUj0JCJOJQJU *OJQJj0JOJQJU *B*ph * >*OJQJ>*CJB*OJQJphOJQJFwxLDRcpܗݗޗ+9:TΙ ^` p`^p`` ^` ! p`^p``1Ιϙ'KŞ֞3ՠǢ p`^p``1 ^`ǢȢˣܣQR>Rcd$If 1p`^p``1$a$p^p p`^p`` ^` @ `^@ ``1^¨ʨ˨ݨQR_gw||,||$$IflFd\ p\& 0    4 la$IfwxƩ '()|||||||||z$If|$$IflFd\ p\& 0    4 la )<ѱEFHIKLNOQRSTuz{fgZ[\w ɽ}}} B* ph j0JUjUmHnHuCJ0JCJ!0J5CJOJQJhmHnHuj0J5CJOJQJUh0J5CJOJQJh CJOJQJCJjCJUmHnHu jU6CJOJQJ>*CJOJQJB*OJQJph1)<ew2ޫ cNzc} & F2 h  ^  & F h  ^ @ `^@ `` 1^`1^1$a$ѱұEGHJKMNPQSTUҲ$a$$a$  !H$f[w!Hqø:Y` (^(` !"Hpqr˷¸øĸxj9:;Y`a23D123SIhij@AB j B* ph j0JU^`2D2iAGM,#GH (LMNn+,-g#$GH&abcuP0JKL%=>?1235CJH* B* ph j0JU]#GbK>2*$a$OJQJ2 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 & Signature669mpatnamChristopher Biow ?j/$$d(P-139L=BXHbMNOv[/\t]^`~brc0dd.i!lInbnsqy{H}]~~Ԍ%mp"ՁmpmpMCmpYImpICBCBCB3mp3KCBmp8ՁmpaՁmpFmp+GmpRQmpKmp'ׁCB;mp?ׁmp\UCBmp3mpMmpNmp-mp1PmpWPmpPmpPmp`mpQmpUmpUmp VCBCBmp=WmpWCBmp XCBCBmpXCBmpCBmpZCB:mpc[CBmpRG ]o &  L{U-3 9u3Nw7 *!""":Z[ars%78G;Ibc  iju'(51.   2 A 56wGxyUflzm%{|!l`a !!!|#$$$%%%%3&='z''2(3(f()))****/,@,Z,[,,- .$.r/000M1222(3)3`33344I6y666678$889Z9[99~:::::;;;;><?<K<a<<<< =!=u=>"><>o>C?D?c????? @@@eAvAAABB\BBBCCCCDDDcD5EFETEFF.GHH%H-H.HeHHHI9I:IINJrJJJJK-K>KLKMKwK{LLLLLMM'M(MfMMNNTNNNNAOOO\PPPPRRRSSSTTTVVVWXXXXXYYYY ZZ(ZBZCZZx[[[[[b\s\\\\)]]]]]]]^^^^` `I`` aaa]ab,b:b*c+cccc8dIdWdXdddeeeeewfffffYgjgxgyggOh`hnhiiiPijbjcjj kk4k5klkkk#lll@mAmm.n/nbnoooWphprtt"uuvvDvw-wLwMwwyy@zzzJ{K{c{F|W|X|||||J}4~E~_~`~~ EҀQRށ $IłӂԂbpBuv6 ,:Qu&7EF͋ދ89O %34: wxLDRcpܓݓޓ+9:TΕϕ'KŚ֚3՜ǞȞ˟ܟQR>Rcd¤ʤˤݤQR_gwxƥ '()<ew2ާ cNzc}ѭҭESTUҮ@X@''''''!     1   1 1      11111111111 11 1 111 1 1 1 1 11 1 111111111111111 11 1  1 1 1 1 11 1110000000000000000000000000111111111  2 0@0@@@0@ @@ @@@@@@@ * VZp[=.QgE mrx|% (.8? DFI-O\T\aIh`lq~҄ޏwΙǢw)`#npqstuvwyz{}~oPXGuIq&XXX5<?DOR!t    ,b$?6v{E˳ijO@ 0(  B S  ?(  \  3 " P  3 " V`3*Gu u ClientName _Hlt69097118 _Hlt125730630Qav@Xaw- "ՁMCYII33K8ՁaՁF+GRQK'ׁ;?ׁ\U3MN-1PWPPP`QUU V=WW XXZ:c[q & !#$7(,13a91=AOHMMTNvO0[\O]p^`bb`cdd&il4nr@y{|E~vG  !"#$%&'()*+, ?j/$$d(P-139L=BXHbMNOu[/\t]^`~brc0dd.i!lInsqy{H}]~Ԍ%Gs|R[ ' "Y\DHklq9CEO|09DL?Haekt%(4@_b\`"!+!!!<"F"""##("(1):)++,,--//011V3_33333'4*424:4:5=566F7J77788::};~;;<<iBrBMM]N`NdNnNNNNPPPPRRPSYSjSsSTTTT UUUUJVSVVVVV_ _X_^___B`H`tb}bbbccddeefffghhhhhhhykk0l8lllllnnnnqrzrBsEs,t/tnttttttttttu!uculu:vCvvvvpxyxxxyyZ{b{~IQ ~ ތ"YbBMenT]ƢϢ_hȣAJ}8Apyکs|NWݬvEEGGHHJKMNPQzIMwz!%,1HK˳γWZgnovy|ŶζYjloƹʹ `dORY\սؽ"%DG"SVILV[hp),orDGhk'*uxQT14%($lq#$EI!!&&#)0)//#0+0G2I2:5=55G6F7J76B:BGGKKX9YuYwY)\.\)]]]].^<^__aascycAeIej%jnnppttuuwwrywyV_7Wőȑjmۣ)/qwSVEEGGHHJKMNPQwzHK˳γy|eoY\սؽDG"SVIL$'),orhk'*uxQT14%(hs3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333DEEGGHHJKMNPQzBrent D. Miller_C:\DOCUME~1\BMILLE~1.BMI\LOCALS~1\Temp\AutoRecovery save of MsgRequirements_060131_internal.asdBrent D. Miller_C:\DOCUME~1\BMILLE~1.BMI\LOCALS~1\Temp\AutoRecovery save of MsgRequirements_060131_internal.asdBrent D. Miller_C:\DOCUME~1\BMILLE~1.BMI\LOCALS~1\Temp\AutoRecovery save of MsgRequirements_060131_internal.asdBrent D. Miller_C:\DOCUME~1\BMILLE~1.BMI\LOCALS~1\Temp\AutoRecovery save of MsgRequirements_060131_internal.asdBrent D. Miller_C:\DOCUME~1\BMILLE~1.BMI\LOCALS~1\Temp\AutoRecovery save of MsgRequirements_060131_internal.asdBrent D. Miller_C:\DOCUME~1\BMILLE~1.BMI\LOCALS~1\Temp\AutoRecovery save of MsgRequirements_060131_internal.asdBrent D. Miller_C:\DOCUME~1\BMILLE~1.BMI\LOCALS~1\Temp\AutoRecovery save of MsgRequirements_060131_internal.asdBrent D. Miller_C:\DOCUME~1\BMILLE~1.BMI\LOCALS~1\Temp\AutoRecovery save of MsgRequirements_060131_internal.asdBrent D. MillerS\\192.168.2.38\bmiller\work\veroquest\bloomberg\MsgRequirements_060202_internal.doc Joe&Joannie?U:\accounts\jkuefler\verity\MsgRequirements_060202_internal.doc2^ .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<Gt $ z T0~g hh^h`OJQJo(^`o(.^`56B*CJOJQJo(phNote ()^`.pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.h ^`OJQJo(h ^`OJ QJ o(oh pp^p`OJQJo(h @ @ ^@ `OJQJo(h ^`OJ QJ o(oh ^`OJQJo(h ^`OJQJo(h ^`OJ QJ o(oh PP^P`OJQJo(h ^`OJQJo(^`OJPJQJ^Jo(-h pp^p`OJQJo(h @ @ ^@ `OJQJo(h ^`OJ QJ o(oh ^`OJQJo(h ^`OJQJo(h ^`OJ QJ o(oh PP^P`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo(h^`.h^`.h$ $ ^$ `.h @ @ ^@ `OJQJo(h^`.hL^`L.h^`.h^`.hPLP^P`L. hh^h`OJQJo(hh^h`o(. hh^h`OJQJo( hh^h`OJQJo($^`56B*CJOJQJo(phVwhVn ^`OJ QJ o(o pp^p`OJQJo( @ @ ^@ `OJQJo( ^`OJ QJ o(o ^`OJQJo( ^`OJQJo( ^`OJ QJ o(o PP^P`OJQJo( hh^h`OJQJo(h ^`OJ QJ o(oh^`B*OJQJo(phh pp^p`OJQJo(h @ @ ^@ `OJQJo(h ^`OJ QJ o(oh ^`OJQJo(h ^`OJQJo(h ^`OJ QJ o(oh PP^P`OJQJo( (^`56B* CJOJQJo(phhH SLO / SLA . ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.h^`.h ^`OJQJo(hpLp^p`L.h@ @ ^@ `.h^`.hL^`L.h^`.h^`.hPLP^P`L.  ^` 56B* CJOJQJo(ph Contact () 8Lp^`L56B* CJOJQJo(ph Contact ()pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.(^`56B*CJOJQJo(phhHObservation / Scope . ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH. hh^h`OJQJo( hh^h`OJQJo(h ^`OJQJo(h ^`OJ QJ o(oh pp^p`OJQJo(h @ @ ^@ `OJQJo(h ^`OJ QJ o(oh ^`OJQJo(h ^`OJQJo(h ^`OJ QJ o(oh PP^P`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo(h ^`OJQJo(h  ^ `.h L ^ `L.hxx^x`.hHH^H`.hL^`L.h^`.h^`.hL^`L. hh^h`OJQJo( }P}^}`POJQJo( PP^P`OJ QJ o(o   ^ `OJQJo(   ^ `OJQJo( ^`OJ QJ o(o ^`OJQJo( ``^``OJQJo( 00^0`OJ QJ o(o ^`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo(h^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJQJo(hH^`o(.^`B*o(.h ^`OJQJo(h ^`OJ QJ o(oh pp^p`OJQJo(h @ @ ^@ `OJQJo(h ^`OJ QJ o(oh ^`OJQJo(h ^`OJQJo(h ^`OJ QJ o(oh PP^P`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo()hh^h`6B*CJOJQJaJo(phhH.#P^`P56CJOJQJaJo(hH..#x^`x56CJOJQJaJo(hH...#^`56CJOJQJaJo(hH....  ^`o(hH .....  X^ `Xo(hH ......  ^ `o(hH.......  8^`8o(hH........  `^``o(hH.........  ^` 56B*CJOJQJo(ph Question ()^`.pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.h^h`.P^`P..p^`...x@ ^`x.... ^` .....  X^ `X ......  ^ `....... 8^`8........ `^``.........hhh^h`.hP^`P..h^`...hxp^`x.... h ^` ..... h X ^ `X ...... h ^ `....... h8^`8........ h`^``.........(^`56B*CJOJQJo(phhH. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH. hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo(h ^`OJ QJ o(opp^p`.@ L@ ^@ `L.^`.^`.L^`L.^`.PP^P`. L ^ `L.2noIT0~J4. /"VffCTI1(F"+>(j8Zaz!A,YIzxR6G#H!|brv\hAK Gi<KC ($NG !s%dJm?%n\e."Y>_OoWID PO oOR9 'Y $ zXZu:'k-I9+L>t32   ¤ʤˤݤQR_gwxƥ '(EGJMP@H`@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Ԛ"h!ƶ!ʡf5I2M2kd0dw ;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@@Ph!@)@)5՜.+,D՜.+, $ , 4<D LT\d l SOW BloombergoOW David Lingleyo Verity, Inc.o2Iw 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{|}~      !#$%&'()+,-./016Root Entry F@Ɓ)8Data 1TableWordDocument4:SummaryInformation("DocumentSummaryInformation8*CompObjjObjectPool@Ɓ)@Ɓ)  FMicrosoft Word Document MSWordDocWord.Document.89q