ocumentation to Vendor Assessment

Transcription

1 CBAP Study Group IIBA Germany Chapter From Do ocumentation to Vendor Assessment Workshop Limburg , Rainer Wendt masventa Business GmbH Von-Blanckart-Str Alsdorf Tel Fax rainer.wendt@masventa.de

2 Agenda Documentation Coverage Matrix for Vendor Selection Vendor Assessment Summary Questions Seite 2

3 Today we discuss some Techniques! Techniques used by Task... to provide Output in Knowledge Area Documentation Prepare Package Package Management and Communication Coverage Matrix for Vendor Selection Manage Traceability Prepare Package Vendor a. Define Business Case a. Business Case a. Enterprise Analysis b. Assess Proposed b. Assessment of b. Solution Assessment Assessment Solution Solution and Validation are only Techniques according rather than tasks, phases, knowledge areas or whatsoever DO NOT MIX UP! Seite 3 Traced Package to BABOK Management and Communication Management and Communication

4 Documentation (1/3) Documentation is a technique mentioned in BABOK as follows: Explicitely mentioned as technique e used for task 4.4: Prepare Package (KA: Management & Communication) In Change-driven approaches Req quirements Documentation is often limited to a prioritized requirements list Outsourced projects may need a more detailed Documentation Documentation may have to follow Organizational Process Assets Short, focused, agile style iteration ns of software development projects may not specify any or very little formal Req quirements Documentation. A formal Sign-Off of Documentation may be required by organizational standards or for regulatory reasons To make requirements reusable, Business Analysts may have to revise the Documentation to ensure that it is self-explanatory Seite 4

5 Documentation (2/3) Documentation according to BABOK may consist of: Business Documen nt* Product Roadmap Software/System Sp pecification Supplementary Spe ecification (non-functional/supporting Req) Vision Document (High-Level-used in Enterprise Analysis or Project Charter) Real-Life Examples for Software e/system Specification 1) CTI Extension for Microsoft CRM Business Req & DOORS User 2) Migration of Custom-CRM to Open Source SugarCRM Simple Excel approach Microsoft Office el Arbeits Original Project Excels Microsoft Office el Arbeits *) many Business Document templates also include stakeholder requirements Seite 5

6 Documentation (3/3) Requirement Attributes according to BABOK!! M E M O R I Z E!! CARA S SOUPS Complexity Absolute Ref. Risks Author Source Status Ownership Urgency Priority Stability Seite 6

7 Tra aceability is the ability to identify and document the lineage of each requirement, including - its derivation (= backward traceability to Business requirements), - its allocation (= forward traceability to implementation), and - its relationship to other requirements.!! M E M O R I Z E!! Business PAST Backw ward Derivation ====================== ==================== Allocation Forward FU UTURE Implementation Seite 7

8 Coverage Matrix The Coverage Matrix helps to trace the requirements backwards and forwards and furthermore ensure completeness (coverage) of the requirements (derivation and allocation). A coverage matrix is a table or spreadsheet used to manage tracing. It is typically used when there are relatively few requirements or when tracing is limited to high-level requirements (e.g. features or models). Requirement in System Specification Origin of Requirement Business/Stakeholder Design Specification Reference Transition & Deployment Ref. Test Cases Ref. RSS100.2 Aggregated daily Positions per counterparty will be calculated by end of day job Business Dept. BRS System shall show aggregation of all daily positions by counterparty DDS Aggregated daily postions of counterparty in tbl_pos_daily will be filled by job_eod_23 In Deployment Guide Refer to 2.3. Schedule of EOD jobs TC234.45, TC , ACCTC IT Security IT Architecture Seite 8

9 Traceability Relationship Types Necessity: It only makes sense to implement a particular requirement if a related requirement is also implemented. This relationship may be unidirectional or bi- if a related requirement is also directional. Effort: When a requirement is easier to implement implemented. Subset: When the requirement is the decomposed outcome of another requirement. Cover: When the requirement fully includes the other requirement. This is a special case of subset, where the top-level requirement is the sum of the sub-requirements. Value: When including a requirement affec cts the desirability of a related requirement either increasing or decreasing it. This may occur because the related requirement is only necessary if the first requirement is implemented, or because only one of the requirements should be implemented (for instance, when discussing two features that potentially meet a business requirement or are in conflict). Seite 9

10 for Vendor Selection for an outside vendor should be formatted as Request for Information (RFI) Still open to a number of alternative solutions and seeking information to evaluate possible options Request for Quote (RFQ) Already understand the nature of the solution options and seeking vendors for it Request for Proposal (RFP) Similar to RFQ but more formal Seite 10

11 Vendor Assessment acc. to BABOK Knowledge and Expertise which is not yet in the Enterprise. Has to be transferred! Licensing and Pricing Models Cost/benefit ration of different license models Product Reputation and Market Is the product well accepted? Are there regular updates and a roadmap? Terms and Conditions Data protection considerations, challenges supplier? Vendor Experience and Reputation Experience of other customers with this vendor? Conformance, Compliance with general standards for quality, security etc Vendor Stability Position when changing the How certain is it that the vendor continues with the product in question? What if the vendor disappears suddenly? Vendor assessment is conducted to ensure that the vendor is reliable and that service levels will meet an organization s expectations Non-functional requirements can be used to define the service levels expected of a third party Seite 11

12 Vendor Assessment in Reality (1/2) Pro s Adaptable Notes Experts Incl. Helpdesk Navision touch Runs w/ Exchange Customization Open Architecture Company Size References First Feedback Flexibility Experience IBM Business Catalogue (5) Internet-Research (10) Phone Calls/Discu ussions (8) Provision of rough requirement list (3) First Live Demonstration Meetings (2) Voice-/Web-Conferencing (2) Budgetary offer (2) Detailed Spec with costs (1) Concrete offer (1) Con s Proprietary Lack Of Expertise Original Project Slide Insufficient preparation/demo Bad Understanding/Feedback Sticking to turn-key solutions Seite 12

13 Vendor Assessment in Reality (2/2) Vendor 1 Vendor 2 Original Project Slide V1 turn-key solution already matched with many of our basic requirements, e.g. indirect Partner model V2 turn-key solution is divided in different disconnected parts, Helpdesk support and Sales/Lead Management. Did not match with our indirect Partner model Live demonstration regarding functionality and adaptability absolutely convincing! Demo not convincing, adaptability seems to be not easy/questionable. Substantial feedback to provided requirement excel. V1 has put Sketchy feedback, no depth. Discussions mostly lead to the a lot of effort to understand our demands question whether we can adapt our processes to V2 S/W. Flexibility and available development capacity to realize the necessary adaptations V2 rejected the request for a tender driven offer. Only a Proof- Of-Concept with cost was proposed Offer incl. 132 days programming: ,- (based on Detailed Spec with cost) Offer incl. 60 days programming: ,- REMARK: 60 days are far too less! were underestimated by V2!! Gut feeling: V1 has the power the experience and the customer Gut feeling: V2 would have the power but does not have orientation to handle such complex projects satisfactorily sufficient customer orientation to satisfactorily handle such a project Seite 13

14 Summary All mentioned techniques will have to be used if requirements are elicited for purchasing a COTS* or custom built solution from an outside vendor. This vendor has to be carefully selected. If work is outsourced or given to a vendor, the Documen ntation usually will be part of the contract agreement, i.e., it has to be as exact and precise as possible. *) COTS = Comercial-Off-the-shelf, Software developed and sold for a particular market.. Seite 14

15 Questions? Questions can as well be posted under Study Group Intern in the German IIBA Forum hp?option=com_agora&id=2&itemid=31 Seite 15