苏州工业园SAAS管理平台项目E-Commerce Functional Specification(SandBox)

1、.Functional SpecificationSandboxPrepared for江苏风云网络服务有限公司星期日, 18 四月 2021Version 1.0 DraftPrepared byTang Yanjunarchitecturev-yatanContributorsZhao Fei*;MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.Complying with all applicable copyright laws is

2、the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, wi

3、thout the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the fu

4、rnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. The descriptions of other companies products in this document, if any, are provided only as a convenience to you. Any such references should not be considered an endorsem

5、ent or support by Microsoft. Microsoft cannot guarantee their accuracy, and the products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products, please consult their respec

6、tive manufacturers. © 2007 Microsoft Corporation. All rights reserved.Microsoft and Windows are either registered trademarks of Microsoft Corporation in the United States and/or other countries.The names of actual companies and products mentioned herein may be the trademarks of their respective

7、 owners.Page ii, , Version .1 DraftPrepared by Tang Yanjun"4cd4d13963e7977a64b2a64844bf6939.pdf" last modified on 18 4月. 21, Rev 1Revision and Signoff SheetChange RecordDateAuthorVersionChange reference2008-6-24Tang Yanjun1.0Initial draft for review/discussionReviewersNameVersion approvedP

8、ositionDateTable of Contents1Executive Summary21.1Document Purpose21.2Document Scope21.3Customer and Reader Profiles21.4Reference Document21.5Terms and abbreviations22Project Vision/Scope Summary32.1Scope of Project32.2Vision Statement32.2.1Business Objectives32.2.2Technical Objectives33Project Hist

9、ory44Project Justification and Design Goals54.1Business Requirements Summary54.1.1Scalability54.2User Requirements Summary54.2.1User Experience54.2.2Availability54.2.3Reliability54.3System Requirements Summary64.3.1Systems and Services Dependencies64.3.2Interoperability64.3.3Location64.4Operations R

10、equirements Summary64.4.1Installation/Setup Requirements Summary64.4.2Uninstallation Requirements Summary64.4.3Integration Requirements Summary64.4.4Supportability Summary64.5Legal and/or Regulatory Requirements Summary65Solution Design75.1Conceptual Design Summary75.2Logical Design Summary75.3Physi

11、cal Design Summary75.4Security Strategy Summary76Planned Features and Capabilities86.1Total Function Modules86.2沙箱管理96.2.1功能模块96.2.2用户角色106.2.3功能用例106.2.4业务场景106.3管理员模板管理186.3.1功能模块186.3.2用户角色186.3.3功能用例186.4测试人员模板管理216.4.1功能模块216.4.2用户角色216.4.3功能用例226.5测试人员CRM测试管理276.5.1功能模块276.6开发人员模板管理276.6.1功能模块

12、276.6.2用户角色276.6.3功能用例276.7开发人员CRM开发管理316.7.1功能模块316.7.2用户角色317Feature Cuts and Unsupported Scenarios328Assumptions and Dependencies339References34Page v, , Version .1 DraftPrepared by "4cd4d13963e7977a64b2a64844bf6939.pdf" last modified on 18 4月. 21, Rev 92Note:  All templates h

13、ave hidden text that guides you through completing the template. If you do not already view hidden text, you can click the Show/Hide button (paragraph marker) to show all hidden formatting elements. MSWork also provides a separate button to view just hidden text. On the Add-Ins tab, click Microsoft

14、Work: Show Hide Hidden Text.Template GuidanceDescription: The Functional Specification is the repository for a set of deep, technical drill-down documents that details every element of the solution deliverables, explaining in exact and specific terms what the team is building and deploying. The Func

15、tional Specification is the final technical document against which every development team member will build. The Functional Specification is built upon the foundation of eight separate foundation documents. You may choose to provide customers with all documents (four requirements document, one Usage

16、 Scenarios document, three design documents, plus the parent Functional Specification document), or you may simply choose to combine the requirements documents, usage scenarios and design documents into a single Functional Specification with sub-topics. The eight foundational documents are:§ Us

17、age Scenarios§ User Requirements§ Business Requirements§ Operations Requirements§ System Requirements§ Conceptual Design§ Logical Design§ Physical DesignTemplates provided for all foundation documents.Justification: The Functional Specification is in essence a cont

18、ract between the customer and the team, describing from a technical view what the customer expects. The quality of the Functional Specification (completeness and correctness) has a significant impact on the quality of the development activities and all follow on phases.Team Role Primary: Program Man

19、agement is responsible for ensuring that the Functional Specification is completed by its estimated completion date. Program Management must also ensure that the design elements of the Functional Specification are consistent with the Vision/Scope document and all relevant plans from the Master Proje

20、ct Plan and Operational Plan. Development will have the primary responsibility for creating the content of the design documents within the Functional Specification. Release Management will participate with Development both in content creation and review to ensure operational, deployment, migration,

21、interoperability and support needs are addressed within the designs. Team Role Secondary: Product Management will review and understand the design documents within the Functional Specification in order to convey solution design to parties external to the team and to ensure that product features are

22、represented in the design according to initial project sponsor requirements. Test will review the Functional Specification to ensure test plans are in place to validate the designs. User Experience must review the design documents to ensure user requirements are met.1 Executive Summary1.1 Document P

23、urpose本文档的目的是从技术的角度清晰的刻画Sandbox子系统的需求和特性，包括功能性的和非功能性的。本文档是联系客户和项目团队的桥梁，将清晰地刻画出客户的期望，对项目的开发活动的质量起着决定性的作用。1.2 Document Scope文档将包含Version Scope所包含的全部范围，包括项目目标、范围和需求概要描述。本文档不包含系统实施方案的具体描述。1.3 Customer and Reader Profiles本说明书的预期读者为项目风险承担人、最终用户、项目管理人员、业务或需求分析人员、测试人员、用户文档编写者。1.4 Reference DocumentVision Sc

24、ope (Sandbx).doc系统界面原型1.5 Terms and abbreviationsSaaS管理平台 (SaaS Management Platform，SMP)：基于SaaS模式的软件的管理平台。EC：注册在SaaS平台上能使用Saas平台功能的中小企业客户，最终CRM template的购买者和使用者。OP：SaaS管理平台的运营商，Sandbox的管理者和template的管理者及template的测试者。ISV：独立软件提供商，template的创建者。SandBox：沙箱，隔离于真实环境的一种生产环境。Use this section to provide a stra

25、tegic statement of the contents of the Functional Specification. This section should identify which foundational documents (requirements, usage scenarios and designs) comprise the Functional Specification and provide a brief statement about the content of each. Justification: This information provid

26、es the reader a guideline of the structure of this document and the strategic context for reading its detail.2 Project Vision/Scope Summary2.1 Scope of Project作为苏州工业园区的基础性平台，Saas将成为中小企业信息化综合应用与服务平台。作为Saas的战略组成部分， Sandbox系统将起到为加入Saas平台的中小企业提高中小企业更廉价的使用功能强劲的CRM，为中小企业拓宽发展空间，降低企业的生产成本，改变中小企业的营销方式，改变中小企业

27、的生产方式的重要作用。隶属于Saas平台的Sandbox系统将借着SaaS平台扩大影响力的契机提高CRM的影响力。反过来，Sandbox系统的成功，带动着Saas平台的发展。2.2 Vision Statement建成为EC服务的Sandbox管理平台，实现CRM template的产供销的一条龙服务。2.2.1 Business ObjectivesObjectiveRationalCategory ManagementDev Sandbox ManagementTesting Sandbox ManagementDev User ManagementDev Sandbox Manageme

28、ntTesting User ManagementTesting Sandbox ManagementTemplate ManagementTemplate TestingTemplate ImportTemplate Export2.2.2 Technical ObjectivesObjectiveRationalExtendableSecurelyMulti Role & Multi UserCapability & Performance strong更多信息，请参见Vision Scope (Sandbox).docProvide an overview of the

29、projects vision and scope. This should include a summary of the business opportunity, solution concept and scope sections of the Vision/Scope document.Justification: This information provides essential context for the reader. The vision/scope information is the strategic statement of the solution, w

30、hich must be understood before the reader approaches the Functional Specification details. By including this information, both internal and external project members share a common understanding of the project, thus setting a common set of expectations.3 Project HistoryUse this section to describe th

31、e important events and decisions that have been made to date to deliver the project to this point. This history may be associated with the process of understanding the customers circumstances and business needs, or any prior attempts at delivering a similar solution. If this is the first implementat

32、ion, this section may be omitted. Justification: All team members (internal and external) should share the same understanding of the project, and this historical information ensures that this can occur. Providing this information will close any gaps or discrepancies in the teams historical knowledge

33、 base.Please refer 苏州工业园区SaaS管理平台_工作说明(SOW).doc for more detail4 Project Justification and Design GoalsUse this section to summarize the requirements documents by stating their contents in terms of business, user and technical needs. These needs justify the project. This section should also convert

34、those needs into a statement of the solution design goals that guided the development of the design documents. Justification: This information provides an understanding of the requirements analysis that was completed and further clarification of project goals in addition to those already summarized

35、in the Vision/Scope section above.4.1 Business Requirements SummaryProvide a summary of the contents of the Business Requirements document. This should include a succinct statement of the contents of each of the key sections of the requirements document (Cost Benefit Analysis, Scalability, and so on

36、).For some projects, it may be appropriate to include the entire contents of the business requirements, if a choice has been made to consolidate all technical documentation into one large central document.We need a Microsoft Dynamics CRM Sandbox Management System. By using this system, the Developer

37、 can create Microsoft Dynamics CRM template and extend Microsoft Dynamics CRM more easily and quickly, and meanwhile dont care how to integrate it with SAAS Platform. This MIS System also support the administrator to manage Development Sandbox and Testing Sandbox, to manage the CRM template life cyc

38、le and support template published as a product.The CRM sandbox provides a separated CRM application development platform that isolates various CRM ISV and with integrated testing environment, sandbox tester verifies ISVs CRM app under a unified system. As a sub project of SaaS management platform, S

39、andbox MIS manages Sandbox/Testing env, ISV user as well as sandbox related resources. Sandbox administrator creates sandbox for ISV and publishes tested solution to Marketplace Sandbox system also implements series of external process to support a intact SMP process. A product on-shelf process publ

40、ishes CRM application from Sandbox to Marketplace and it coordinate with “charging policy” and “Product definition process” to make a “product” orderable in SMP marketplace.Sandbox system is partially based on Microsoft Dynamics CRM 4.0, with alteration of default deployment, ISV and tester could ex

41、ports/imports CRM App without using other 3dr party tools outside Sandbox.4.1.1 ScalabilitySandbox MIS System anticipates an average load of 10 developer and 500 concurrent users after the system is fully operational, and expects that to grow by 5 percent each year for the next five years.4.2 User R

42、equirements SummaryProvide a summary of the contents of the User Requirements document. This should include a succinct statement of the contents of each of the key sections of the requirements document (User Experience, Reliability, Accessibility, and so on).For some projects, it may be appropriate

43、to include the entire contents of the user requirements, if a choice has been made to consolidate all technical documentation into one large central document.4.2.1 User ExperienceDev and Testing Sandbox quickly manage，An easy way to manage template，Create Microsoft Dynamics CRM template，please refer

44、 Sandbox的UI prototype。4.2.2 AvailabilityBecause the Web site is accessed by customers across the world, it needs to be available 24 hours a day, 7 days a week.4.2.3 ReliabilityBecause of the need for 24*7 availability, automatic failover will be required. In addition, existing disaster recovery and

45、backup plans and procedures must be revised to incorporate the Sandbox Msanagement Application.4.3 System Requirements SummaryProvide a summary of the contents of the System Requirements document. This should include a succinct statement of the contents of each of the key sections of the requirement

46、s document (Systems and Services Dependencies, Interoperability, and so on).For some projects, it may be appropriate to include the entire contents of the system requirements, if a choice has been made to consolidate all technical documentation into one large central document.4.3.1 Systems and Servi

47、ces DependenciesSMP PlatformHosting Microsoft CRM AD Service4.3.2 InteroperabilityIntegrated SAAS Platform,Single Sign On CRM,Template publish and Product release to SAAS Solution Supermarket4.3.3 LocationThe Web Site Enhancement application will be used by customers using a range of browser clients

48、 in a variety of locations around the world4.4 Operations Requirements SummaryProvide a summary of the contents of the Operations Requirements document. This should include a succinct statement of the contents of each of the key sections of the requirements document (Security, Manageability, Support

49、ability, etc.).For some projects, it may be appropriate to include the entire contents of the operations requirements, if a choice has been made to consolidate all technical documentation into one large central document.4.4.1 Installation/Setup Requirements Summary Use this section to summarize the

50、environmental requirements for solution installation. This information may be derived from the Deployment Plans installation sections. The Physical Design document contains the detail on how these requirements will be satisfied.Need IIS, .net framework, SQL Server 2005, Hosting CRM, SaaS Platform.Pl

51、ease refer to SaaS Deploy Document.doc for more detail.Setup and installation must not interrupt the users daily tasks and work flow.4.4.2 Uninstallation Requirements SummaryUse this section to describe how the solution is removed from its environment. This should include a definition of what must b

52、e considered prior to removing the solution and what must be considered in a backup/restore capacity prior to un-installing to ensure safe recovery/rebuild at a later time.4.4.3 Integration Requirements SummaryUse this section to summarize integration and interoperability requirements and the projec

53、t goals related to these requirements. The Migration Plan may be referenced or summarized here, as it contains integration and interoperability specifications. The Physical Design document contains the detail on how integration will be delivered.Please refer to 4.3.2 InteroperabilityPlease refer to

54、Version Scope (Sandbox).doc for more detail。4.4.4 Supportability SummaryUse this section to summarize the supportability requirements and the project goals related to these requirements. The Operations Plan and Support Plan may be referenced or summarized here, as they contain supportability specifi

55、cations. The Physical Design document contains the detail on how supportability will be delivered.Please refer to Version Scope (Sandbox).doc for more detail。4.5 Legal and/or Regulatory Requirements SummaryUse this section to summarize any legal and/or regulatory requirements to which the project mu

56、st adhere. Legal requirements may come from the customers corporate policies or from regulatory agencies governing the customers industry.Follow the Microsoft Dynamics CRM police.Follow the SMP Development Guid.5 Solution DesignUse this section to identify the design documents that have been develop

57、ed and summarizes the overall solution design in a succinct statement. Also, define why each of these design documents is necessary for the project. Justification: This information provides the reader with strategic context for the follow on reading. It explains the differences between the design do

58、cuments and explains how each provides a unique picture of the solution.5.1 Conceptual Design SummaryProvide a summary of the contents of the Conceptual Design document. This should include a succinct statement of the contents of each of the key sections of the document (Solution Overview, Solution Archi