community.tibco.com · Web viewThe information in this document is subject to change without notice. This document contains information that is confidential and proprietary to TIBCO

AMX BPM Business Requirements Document TemplateProject Name Project Name

Release Draft/Final

Date Date

Primary Author Name/Title/Company

Document Owner Name/Title/Company

Client Client Name

Document Location This document is only valid on the day it was printed. The source of the document will be found in the folder name folder (insert file path)

Purpose Document purpose

Template Version 2.1Revision History

TIBCO Business Process Requirements Document for <project name> 1

Version Date Author Comments

ApprovalsThis document requires the following approvals. Signed approval forms are filed in the project files.

Name Signature Title Company Date of Issue Version

DistributionThis document has been distributed to:

Name Title Company Date of Issue Version


Copyright NoticeCOPYRIGHT© 2017 TIBCO Software Inc. This document is unpublished and the foregoing notice is affixed to protect TIBCO Software Inc. in the event of inadvertent publication. All rights reserved. No part of this document may be reproduced in any form, including photocopying or transmission electronically to any computer, without prior written consent of TIBCO Software Inc. The information contained in this document is confidential and proprietary to TIBCO Software Inc. and may not be used or disclosed except as expressly authorized in writing by TIBCO Software Inc. Copyright protection includes material generated from our software programs displayed on the screen, such as icons, screen displays, and the like.TrademarksTechnologies described herein are either covered by existing patents or patent applications are in progress. All brand and product names are trademarks or registered trademarks of their respective holders and are hereby acknowledged.ConfidentialityThe information in this document is subject to change without notice. This document contains information that is confidential and proprietary to TIBCO Software Inc. and may not be copied, published, or disclosed to others, or used for any purposes other than review, without written authorization of an officer of TIBCO Software Inc. Submission of this document does not represent a commitment to implement any portion of this specification in the products of the submitters.Content WarrantyThe information in this document is subject to change without notice. THIS DOCUMENT IS PROVIDED "AS IS" AND TIBCO MAKES NO WARRANTY, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO ALL WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. TIBCO Software Inc. shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance or use of this material.For more information, please contact:TIBCO Software Inc.3303 Hillview AvenuePalo Alto, CA 94304USA


ContentsDocument Overview................................................................................................................................................................................................................5Requirements Overview..........................................................................................................................................................................................................6Process Discovery...................................................................................................................................................................................................................7

Tools:...................................................................................................................................................................................................................................7Areas:...................................................................................................................................................................................................................................8

Process Level........................................................................................................................................................................................................................10

Process Name: <xyz>........................................................................................................................................................................................................10

Overview.........................................................................................................................................................................................................................10Process Parameters.......................................................................................................................................................................................................10Process Map...................................................................................................................................................................................................................11Inter-Process Dependencies and Interactions & Inter-Case Dependencies..................................................................................................................11Information Relevant to the Process..............................................................................................................................................................................12Process Audit Points......................................................................................................................................................................................................12

Step Details...........................................................................................................................................................................................................................14

Step A (Manual Step).....................................................................................................................................................................................................14Step B (Automatic Step / Service Call)...........................................................................................................................................................................16

Data Definition.......................................................................................................................................................................................................................18

Data Dictionary...................................................................................................................................................................................................................18DWH Strategy....................................................................................................................................................................................................................21Data Maintenance..............................................................................................................................................................................................................21

Organization Model................................................................................................................................................................................................................22Other Requirements..............................................................................................................................................................................................................23

Supervisor Functions.........................................................................................................................................................................................................23others.................................................................................................................................................................................................................................23

Technical Infrastructure.........................................................................................................................................................................................................24


Strategic Architectural Vision.............................................................................................................................................................................................24Target Architecture.............................................................................................................................................................................................................24Overall Process Volumes...................................................................................................................................................................................................25Non-functional Requirements.............................................................................................................................................................................................25Interfacing System Restrictions..........................................................................................................................................................................................25System Monitoring Tools....................................................................................................................................................................................................25Administration Tools...........................................................................................................................................................................................................25

Appendix A – Change Log.....................................................................................................................................................................................................26Appendix B – De-scoped Requirements...............................................................................................................................................................................27Appendix C – Functional Issues............................................................................................................................................................................................28Appendix D – Project Assumptions.......................................................................................................................................................................................29


Document OverviewThe purpose of the document is to document all the business requirements for the implementation of TIBCO BPM in the given project scope. The intent is that the requirements are articulated at a level of detail that ensures that there is no subsequent need to return to the users to ask for further clarifications.The Requirements Definition Document is the deliverable of the Analysis Phase of a project. It builds on the High Level Business Requirements and Statement of Work documents in defining in detail, and in workflow terms, what the final solution is required to achieve.The Requirements Definition Document is an input to both the Design Phase of the project and the Test Planning Phase. It also provides a baseline of the functional requirements against which detailed project estimates can be made, and against which Change Control can be applied.


Requirements OverviewUse this section to describe requirements that apply to the overall project, not specific business processes.


Process Discovery

Tools:This Document can be used to discover all artifacts of a TIBCO Business Process Implementation. The use of tools like TIBCO NIMBUS Control could be helpful to discover a process in more details, and to import all Artifacts later directly into TIBCO Business Studio.

In this Project Phase Tools like Visio, Aris, Adonis, etc. can be use, too. Also TIBCO Business Studio can be used in the Process discovery Phase, in case Nimbus is not available.If TIBCO Business Studio is used from the Beginning this helpful in many Projects to discuss the Implementation later on with the Business People.

TIBCO NIMBUS Control The Strategy TIBCO Nimbus Control follows is very business User friendly and help to split Tasks also into reusable parts.All that can be defined here is mainly the following, but other Documents, Screenshots, Form-Samples, Rule Sheets, etc. can be attached, too.A Task in Nimbus:

The Tool can be used in the following Areas, from process discovery in the requirements pase, up to the execution times, and the implementation of a change:● Connect multiple initiatives, around an Integrated Management Platform● Collaboratively connect all process stakeholders: Process owners, Analysts, IT, Lean, SixSigma, Quality, Compliance and end users● Uses a simple common language which business users and process specialists both understand.● Scalable – from top level core business processes down to individual initiatives

Personalized Intelligent Operations Manual – engaging all employees in continuous improvement


●

Areas:

The Requirements should cover the following high-level and detail Areas (Example only)Every procedure is different and has his own main important Areas

Remark: “orange” areas covered by a Business Analyst - “yellow” areas need be covered by IT-Architects.TIBCO Business Process Requirements Document for <project name> 9

Process Level

Process Name: <xyz>

OverviewThe overview is a text description of the process. In projects where multiple processes are being implemented, a separate section for each process is completed.

Process ParametersCategory Content

Department Name of Department / Division / Team(s) that are prime executors of this process

Physical Locations List of physical locations for Team(s) that execute this process

Products A list of products covered by the process. Note this will become a validation that all products are explicitly covered by the set of workflow processes, or that specific products have been excluded.

Channels A list of the interaction channels covered by this process, e.g. mail, faxes, call centre, branches. Note some channels may be excluded from the process.

Work Allocation Rules If more than one team or one location are involved in the process, a description of how work is allocated to the teams (e.g. based on State)

Work Prioritisation Rules A text description of the order in which work is processed, e.g. ‘As Received’. Note individual steps may have different priority rules to the overall process, however these are noted in the relevant Step Definition section

Deadlines / SLAs A description of the relevant SLAs for the process. Note there may be more than one SLA that is relevant, and also that different SLAs may apply for different products. All should be noted here.

Process Triggers / Inputs A description of how a new process is initiated. For example an application form, a mainframe exception (Control-D) report, an email, a web enquiry, a call to the Call Centre etc. Note examples of the inputs / triggers may be attached to the process definition

Process Outputs A description of all outputs generated by the process, including the format used. Note examples of the outputs may be attached to the process definition

Business Volumes A description of the business volumes for the process, including average volumes, peak volumes (and when the peak volumes are experienced), and expected growth over 2 to 3 years

Key Performance Indicators A description of the current (As-Is) KPIs and the target (To-Be) KPIs for the process, e.g. FTE, cycle times etc.


Process MapThis map shows the business process in a graphical form. There is no preferred format for the process map; indeed the customer should determine the format. It is recommended to use Tools like TIBCO NIMBUS in this first phase. In many cases the customer will provide a process map as an input to the requirements gathering exercise. The Requirements Gathering exercise will normally need to transform that map into a format that is suitable to take through to the Design exercise. It is that ‘transformed’ process map that should be documented here.

Specific transformations that occur to an existing business process map include:● Aggregation of individual tasks into steps that represent process hand-offs,● Identification of automatic steps in the process,● Identification of common ‘sub-processes’,● Clarification of ambiguous business rules.

Note for ease of cross-reference to the Step Definition section below each step in the process should be uniquely identified.

Inter-Process Dependencies and Interactions & Inter-Case DependenciesA text description of dependencies between different processes, and dependencies between different cases in the same process. This can include relationships such as Parent / Child (where a parent process spawns one or more child processes, and needs to track the status of each child process), and group or sibling relationships (where multiple related cases need to be coordinated through a process). Examples might include:

● Checking for duplicate cases. This can occur when cases are started in TIBCO BPM by an external system (e.g. CRM, overnight


batch processing). The initiating system may erroneously execute a second (duplicate) case start command. Requirements should state how the workflow recognizes and processes duplicate cases.

● Where multiple cases correctly exist for a single process (or even across multiple like processes), but the response / conclusion of each case needs to be coordinated as a single event. For example in Superannuation where an employer requests plan changes for multiple employees at the same time. Each plan change is a separate case, but the response to each case is required to be a single letter to the employer.

● In a claims process where multiple claims from the same person / company are required to be identified as part of a fraud detection process.

● Where a second incoming case needs to be matched with a pre-existing case. For example, in a Cards Chargeback process where the initial chargeback case is processed and returned to the disputing bank and then the chargeback is returned for further processing. The follow-up case needs to be matched with the initial case and treated as a single entity.

● Where at a certain time in the day, data across a number of cases needs to be consolidated into a single report. For example, at the end of each business day, a spreadsheet must be sent to the Accounts department listing all debits and credits processed by the workflow during the day.

Information Relevant to the ProcessA tabular description of all information sets (documents, data records etc) that are used by the process. For data sets summary information is acceptable, e.g. Contact Details, more detailed information can be captured in the Data Dictionary section below. A good source of this information is any forms used by the process, and screen shots of system transaction that are used in the process.Title Description Source

A brief description of the information set. From where does the information set enter the process.

Examples:

Application Form Paper or fax. Contains customer details, and details of product applied for. From Customer via mail, fax or branch. Triggers process.

Valuers Report Details of the value of the property to be mortgaged. From Valuer (3rd party). Received after Request for Valuation step.

Credit Assessment Report from Credit Advantage on creditworthiness of applicant From Credit Advantage. Received as part of Credit Assessment step. Electronic file.

Acceptance Letter Letter confirming application has been approved. Word document, generated as part of process at


Application Approved step.

Process Audit PointsA list of all milestones in the process that need to be logged. Specifically this relates to status information that needs to be made available to parties external to the process, including management, the customer, other areas of the business, and possibly third parties.i.e. TIBCO Spotfire Reporting Milestones


Step DetailsThis section is repeated for each step in the process. Note a Step is defined as a collection of one or more tasks performed by the same role in a contiguous time frame. A separate sub-section is required for each step in the process, however the information recorded is different depending on whether the step is a user step or an automatic step. Each sub-section should be titled with the step name, and each step should be cross-reference able.

Step A (Manual Step)Step InformationThe following table describes the parameters that need to be collected about each user step.

Step Name A descriptive step name.

Description A full description of the purpose of the step.

Role The name of the role that performs the step, this will relate directly to the addressees for a workflow step.

Location The physical location where the step is performed, note there may be more that one.

SLA Details of any SLA that is applicable to this particular step. Noting of SLA details here rather than in the Process Level section above may aid clarity, but is optional. The only requirement is that SLAs are noted somewhere.

Delivery Optional. Describes how work is received at this step, which normally would be via a work queue / inbox. This is only relevant where some constraint exists on the delivery of work, such as where physical documents are required.

Selection / Allocation Rules Describes the rules by which work is allocated to or selected by users. This can include rules on allocating work to teams (e.g. by State, by alphabetical range on surname etc), rules on case ownership (e.g. this work must be performed by the same user who performed a previous step), and rules on exclusion (e.g. this step must not be performed by the user who performed the previous step).May use here directly the TIBCO Resource Query Language (RQL) to query for resources inside your specified Meta Organizational Model.

Prioritisation Rules Describes the rules by which work is prioritized for this step. This can include rules based on product type, by customer value etc.

Next Steps Describes where the work is delivered to next, if relevant (i.e. requires a physical handoff) how the work is delivered, what information is handed over, and if relevant any rules that determine when this handoff happens. For example:Supervisor Authorization, claim details & assessor’s report, if claim value > $1000.



Task InformationThe following table describes the parameters that need to be collected about each task in the step. This table should be repeated as many times as required. The level of granularity of task descriptions is determined by the needs of the project. If a step is seen as having only one task then this table and the above table may be combined, with redundant fields removed.

Name The name of the task.

Description A text description of the task.

Form A first draft Screen design, if available, maybe a existing System ? Think about the use of TIBCO Business Studio Forms, this allows a real Model-driven approach and enable rapid development.

Systems i.e. Name and transaction / screen of any other systems, used during the execution of the task.

Information Required Details of the information required to complete the task, and from where that information is sourced.

Information Outputs Details of the information that is generated as an output from the task.

Rules Details of any rules that determine the order in which tasks are completed. This is a useful input for dynamic form building. Note if the rules are complex it may be appropriate to represent the rules as a flowchart.

Validations / Exceptions Detail of any validations that take place in a task, and the exception processing that occurs if a validation fails. For example:If the application form is incomplete the user will write to the customer asking for the missing information. The user will keep the work item and pend it for 10 working days awaiting the new information.

Complex Task Specify is the use of reuseable Form- or Page-flows, can be helpful(i.e. Wizzard driven Forms)


Step B (Automatic Step / Service Call)Step InformationThe following table describes the parameters that need to be collected about each automatic step. Generally there is not a need to document specific tasks as part of an automatic step, however if the detail will add value then it may be included. Automatic steps relate directly to TIBCO BPM Services. As a generalization there are typically four types of Services – System Integration Services, Rule Tasks, Document Services, and Email Services. The Information required for each is slightly different.

Step Name A descriptive step name.

Description A full description of the step.

Location Optional. The physical location where the step is performed, note there may be more that one. This might be relevant for Document Services.

Prioritisation Rules Describes the rules by which work is prioritised for this step. This can include rules based on product type, by customer value etc. In most cases this parameter will not be relevant.

Systems Name and transaction / screen of any systems used during the execution of the step. Note screen prints of transactions used are very useful here. This information is only relevant for a System Integration Service. If it is known that a composite Service Layer (like AMX SOA) or other middleware will be used at this point that should be noted here.In case of a Rule Task describe the Rule Decision Table.

Information Required Details of the information required to complete the step, and from where that information is sourced. The exact requirements will vary by type of Service:System Integration: Data passed into the transaction.Rule Task: Data passed into the rule.Document Services: Document details (template – if generated, location, name), note there may be more than 1.

Data used in generation of document (in).Email / tibbr Task: Content – both static and dynamic (i.e. data passed in).

Attachments used (location, name, template – if generated, data used to generate).Recipients.

Information Outputs Details of the information that is generated as an output from the step. The exact details will vary by type of Service:System Integration: Data passed back by the transaction, including status data.Rule Task: Data back from Rule, i.e. a Process decision to go the left or right pathDocument Services: Data on the status of the request.

Storage location (if document generated by step).


Email / tibbr Task: Data on the status of the request.Storage location (if attached document generated by step).

Validations / Exceptions Detail of any validations that take place in the step, and the exception processing that occurs if a validation fails. This can include roll-back requirements if the step includes multiple system transactions.

Next Steps Describes where the work is delivered to next, what information is handed over, and if relevant any rules that determine when this handoff happens.

Other Information This section should contain any additional information that would be useful for the design phase of the project. This will depend on the type of automatic step being defined. An example for System Integration Service would be typical transaction response times. This is useful input to the design decision as to whether the integration should be synchronous or asynchronous. Can also include factors such as time restrictions in which to run the task.


Data Definition

Data DictionaryA single Data Definition section is required for the complete scope of the project, including where multiple processes are being developed. Whilst it is expected that additional data requirements will be identified during the design phase of the project, it is recommended that as much information as can be captured about data requirements is recorded here. In particular data types and lengths should be recorded if they are available.In looking for data definitions there are seen to be 5 types of data that need to be recorded:

1. Information Data. This is data held by workflow to give to people (or instructions to Systems) to tell them what the work and their task is about and what they should be doing. Information data also includes documents and attachments, whether they be actual attachments, pointers to electronic documents (e.g. images), or references to other documents / information held outside the workflow system (e.g. physical files).

2. Reporting Data. This is really a subset of Information Data. MIS data focuses on process statistics such as produced by Event Collector (i.e. quantitative data), whilst BPM includes extracts of case data (e.g. product type, customer segment) at various points in the process (i.e. qualitative data).

3. Routing Data. This could be a subset of information data, but it differs in that it directly affects work routing. Routing data can also be derived from information data (e.g. via a calculation), and can be derived from workflow status (e.g. a user decision to accept / reject an application). It is important to include status information that is updated from errors and / or exception processing.

4. Transient Data. This is typically information that is passed from system to system in an STP environment. It can differ from information data in that it is not displayed to a user, nor does it necessarily affect routing decisions.

5. Status Data. Describes the informational requirements for external users or non-participants in the workflow process. For example a call centre may require a view of all open cases for a client through workflow or CRM, or a customer might require a view of the status of an application through a customer portal.



The parameters to be documented for each data item is as follows:

Field Name Description Type / Len

Source Where Used / Updated

Deleted / Archived

Validations Transformations Notes

The following notes are relevant to the above table:● Description. A description of the logical purpose of the data item.● Type / Len. Describes the data type, and if relevant (and available) it’s length. Note the data type could be Word Document or

email, or indeed anything.● Source. Describes the source of a data item, including the step at which it enters the workflow process and where it comes

from. This could be from a system, or keyed in by a user from a document.● Where Used / Updated. List of steps in the process that use and / or update the data item.● Deleted / Archived. Details of what happens to the data item at the end of the process, and whether it needs to be retained /

archived?● Validations. Details of any validations applied to the data item. This includes lists of valid values (pick lists).● Transformations. Details of any data transformations done on the data item. This is particularly valid for STP / SOA

implementations where data is passed from one system to another.● Notes. Any other pertinent information about the data, including issues such as currency of data, details of how documents

will be viewed by the user (e.g. images) etc.


Also a Process Data Map can be helpful fo specify where is witch datafield used and if it is mandatory at a given Step or not:

Field Name Default

Stepname

Stepname

Stepname

Approval Step

Stepname

Service Task

etc.

Order ID O M M R R IN

Status "OPEN" M M M M M IN In Example combination out of this:O=Optional ; M=Mandatory ; R=Readonly ; - =not used hereIN=Input Parameter for a Service or Rule TaskOUT= feedback Parameter from aService or Rule Task

Order Date <current datetime>

O R R R R IN,O

Approved ? "NO" - - - M R -

Archiv DocID - - - - - OUT


DWH StrategyThis section describes the strategy for the storing of reporting / Data Warehouse (DWH) data. In particular it describes where the DWH data captured by the process will be stored, and the requirements for how TIBCO BPM will populate the database.i.e. TIBCO Spotfire Reporting Dashboards

Data MaintenanceThis section documents any administration tools required by the overall solution. These tools are typically required to manage static data sets (e.g. postcodes, products) and / or relationships between multiple static data sets (e.g. data references from other external Databases).


Organization ModelTIBCO ActiveMatrix BPM uses the enterprise’s own meta organization model as the basis for work distribution. TIBCO ActiveMatrix BPM maintains its own model of the enterprise’s organizational structure. This organization model is based on the enterprise directory, augmented with additional business process management-related information required to manage work for users - for example, an employee’s role (their job title or function), technical capabilities and so on. (e.g. a skills matrix mapping users to products they can work on).

Define the following:● Organizations denote the overall container for an organizational hierarchy. Typically this means a company.● Organizational units represent structural associations of people in the context of the organization. ● Positions define the membership roles of an organization unit. For example, a Customer Services department may define the

positions of manager● Groups, i.e. virtual team that work in a particular group of users are capable of doing.● Privileges, like approve expense claims or limits like expense claims up to a 1000 $● Capabilities, like a skill or speak a foreign language, hold a professional qualifications

Remark:In case other Systems (i.e. HR Systems) are connected here, please specify how to sync. or if the task resource allocation is driven by those system.


Other RequirementsThis section is essentially a bucket to cover all other business requirements that are not covered in the previous sections. The structure of this section is likely to be different for each project, but as a guideline could include the following sections.

Supervisor FunctionsThis section describes any additional supervisor functionality required by the customer. This can include items such as the ability to reallocate work, to view queue lengths etc. This section is completed as free text.

othersAlso other necessary Implementations can be store here, like:

● Description of Search capabilities or use of a Matching Engine● Event correlation, to react automatically on given Scenarios● Custom User Interface Implementation / Integration● Company Calendar● Online Documentation / Help● etc.


Technical InfrastructureThe Technical Infrastructure section details the technical requirements and constraints of the target solution environment. This information can impact the design of the overall solution. Information gathered for this section might either be captured directly in this document, or captured via reference to an existing customer document. If an existing customer document is being referenced then a copy of that document should be attached as an appendix to this document.The Technical Infrastructure section is split into the following headings:

Strategic Architectural VisionThis section covers the following elements:

● Technology preferences. This covers a preference for technologies such as Windows, Unix, Cloud Web deployment, etc.● Standard Operating Environment (SOE). If relevant this is likely to exist as an existing document.● Security policy constraints. Documents any security constraints that apply for the solution. This can include elements such as

web delivery constraints, external security directories, third party interactions, hardware isolation, encryption requirements etc.

Target ArchitectureThis section covers the following elements:

● Network topology, including specifically geographic distribution of hardware, and hardware isolation through routers and firewalls.

● Server vendor preference.● Client delivery preference, e.g. TIBCO standard, Web, Mobile, or custom Java, .NET, GWT, COM, 64-bit, etc.● Development preference, e.g. preferred language(s), source control requirements.



Overall Process VolumesThis section aggregates all the process volumetric information. It may also refine volumes by geographic distribution if it is relevant.

● i.e. cases by day/hour etc.● count of users active/registered only

Non-functional RequirementsThis section covers the following elements:

● Required hours of operation, including in a 24 hour period, plus weekly, monthly and yearly requirements.● Service level requirements (SLR/SLA). This can include items such as performance targets for interactions to other systems.● Backup constraints, including those imposed by hardware, and those imposed by policy requirements.● Fail over.● Disaster recovery requirements.

Interfacing System RestrictionsThis section documents any constraints imposed on interfaces, such as requirements to use middleware (SOA), or to provide batch interfaces etc.

System Monitoring ToolsThis section documents any requirements to interface to existing system monitoring tools within the target environment.

Administration ToolsThis section documents any requirements to interface to existing system administration tools within the target environment.


Appendix A – Change LogThis section details the changes made between each version of the document, along with the source of the change, e.g. Team Review, Customer, 3rd Party etc.

Version Date Author Details Source


Appendix B – De-scoped RequirementsThis section provides details of any business requirements that are documented as part of the High Level Business Requirements, but which for whatever reason are de-scoped. Each item in this section should be related back to the High Level Business Requirements document, and should include: Item Cross Ref Reason Agreed

Item Description Reason for de-scope (e.g. budget, time constraints, alternative method of delivery)

Who from Customer agreed to de-scope


Appendix C – Functional IssuesThis appendix is used to document any issues that remain to be clarified at the end of the Analysis Phase of the project. Typically these will be areas of functionality that need to be clarified by the business, or ambiguous business rules that need to be made explicit. By documenting outstanding issues here in the appendix, the customer will be signing off the fact that the issue exists, the responsibility for resolving the issue, and the target date. The use of this appendix though is optional, and is not intended to replace the overall project Issues Log.The following table should be completed:Date Description Responsible Person Target Date

The following comments are relevant to completing this table:● Date: the date the issue was identified.● Description: a text description of the issue that needs to be clarified. This section can include details of possible options

available, along with the potential impact of each option.● Responsible Person: the name of the individual responsible for resolving the issue.● Target Date: the date that resolution of the issue is required by.


Appendix D – Project AssumptionsThis appendix lists any assumptions that have been made in completing the Requirements Definition Document. In many cases these assumptions will relate to issues that have not been resolved, but there may also be assumptions made during the Analysis Phase that may impact the next phases of the project. These can include assumptions on availability of other technologies (e.g. imaging), assumptions on centralisation of business functions etc. In particular these assumptions can impact project estimates that would normally be reviewed at the end of this phase.The following table should be completed:Date Assumption Source

The following comments are relevant to completing the table:● Date: the date the assumption was made.● Assumption: details of the assumption. This can include discussion of the impact of the assumption, and the potential

impact if the assumption proves to be invalid.● Source: the source of the assumption, usually either the customer, a third party, or TIBCO. It is important that the source of

an assumption is recorded.
