软件项目解决方案模板Word文件下载.docx

软件项目解决方案模板Word文件下载.docx

《软件项目解决方案模板Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件项目解决方案模板Word文件下载.docx（6页珍藏版）》请在冰豆网上搜索。

例如功能的需求来源，与各功能模块之间的关系，功能操作流程例如，序列图，程序设计，外部接口，数据库设计等。

开发人员可通过阅读该文档快速的了解每一个功能的业务逻辑，便于日后在对系统进展修改时确认修改容是否正确。

同时本文档也是与终端用户（在本工程多数情况是技术支持人员）进展系统功能确认，业务流程确定的唯一文档。

第2章概述

2.1工程背景

由于公司多个系统都用到了支付模块，而且功能等方面都一致。

2.2建立目标

把支付模块单独整理出来，然而实现统一管理、维护方便、并且方便以后新系统的开发。

2.3建立原那么

保证支付的平安性，一致性，不影响原系统的支付，在原有系统上以最小的改动方面来实现这个支付的别离。

第3章需求描述及分析

3.1概述

3.1.1需求分析

Ø

原各系统的支付

问题分析

从上图可以看出我们这个养车修车网有好修养、好淘气、等多个工程。

然而他们都需要用到支付宝、微信、银联这三个第三方支付。

那么既然都是同一个平台的系统，每个系统支付都重新写，或者以后又有新工程支付又要写支付。

得出以下结论：

1.代码重用性不高

2.维护不方便

3.2需求描述

3.2.1业务需求

解决问题

为了解决上面存在的问题，将原来各系统的支付独立别离出来整合成一个支付系统。

现在就是由各个系统去和这个独立出来的支付系统交互，然后在由支付系统再去调用第三方支付（微信、银联、支付宝）进展交互。

这样即使有新的系统需要用到支付也不要重新写支付的功能，然后也也方便以后的管理维护。

3.2.2接口需求

3.2.2.1支付

各个系统调用支付系统，然后我们在根据出传入的支付途径的调用对应的第三方支付进展支付〔WEB〕或者返回相应的属性〔APP〕,并且返回成功或失败。

3.2.2.2退款

各个系统调用支付系统，然后我们在根据出传入的支付途径的调用对应的第三方支付进展退款,并且返回成功或失败。

3.2.2.3支付回调

第三方通知我们的支付系统的回调地址，然后我们验证签名和参数解析，如果支付成功就修改付款单支付状态为已支付，然后根据在通知付款单的系统ID将结果通知对应的系统，如果通知失败就隔1秒在失败就隔2秒依次加时间请求，超过20次就添加到系统日志里面。

3.2.2.4退款回调

3.2.3性能需求

[这里描述系统的性能需求。

]

3.2.4平安需求

[这里描述系统的平安方面的需求。

3.2.5其它需求

3.2.5.1对账单

3.3需求分析

3.3.1系统涉众分析

[这里描述和系统相关的用户，包括客户，最终用户细分，他们在系统中的职责，以及他们如何使用系统。

简单的说，就是本系统的所有干系人及职责描述，相当于用例分析中的角色。

3.3.2功能需求分析

[这里描述系统的所有功能需求，可以使用用例图，如果功能需求比拟多，可以采用用例包。

最好在开场时，给出系统用例图。

3.3.3对技术架构的要求

[这里描述对架构设计有指导性的关键需求，会影响到后面的架构设计。

第4章总体设计

4.1总体设计目标

[这里描述系统的总体设计目标。

4.2总体设计原那么

[这里描述系统的总体设计原那么。

4.3总体逻辑架构设计

[这里以逻辑构造图〔一般分层组织〕的方式，描述我们提供的整个软件生态系统，一般不涉及具体的技术。

4.4网络系统设计

[这里用网络拓扑图的形式描述网络方面的设计。

4.5硬件系统设计

[这里描述硬件方面的设计，一般包括：

数据库效劳器、备份效劳器、Web效劳器、应用效劳器、存储设备、防火墙等。

4.5.1效劳器

[这里描述硬件效劳器的选型，依据容多少，目录可自行添加。

4.5.2网络设备

[这里描述网络设备的选型，依据容多少，目录可自行添加。

4.5.3存储系统

[这里描述存储设备的选型，依据容多少，目录可自行添加。

4.6平台选择

[这里列出所有数据库，应用效劳器，web效劳器，操作系统等软件平台的选型，可以包含介绍和选择理由。

4.7标准规设计〔可选〕

[在有些大型系统中，需要做开创性的规方面的设计，用来指导后面系统的开发。

一般就是数据方面的规。

这里可以分两个方面进展描述，一个是规采用的技术，一般是xml；

另一个就是规初步设计。

第5章详细设计

5.1技术架构设计

5.1.1设计思路

[描述整个技术架构的设计思路，一般是介绍架构设计的历史，引导出本系统实际的符合先进展的架构思路。

5.1.2设计原那么

[简要描述设计原那么，一般都是都是固定的，可参考指南。

5.1.3架构决策

[列出所有架构决策的要点，并逐点解释其与架构需求的对应。

5.1.4技术架构

5.1.4.1平台技术架构〔可选〕

[给出方案所选平台的技术架构，一般是采用厂商平台的技术架构，可以从厂商或ppt中拷贝。

5.1.4.2总体技术架构图

[在平台架构的根底上，给出具体针对本工程的技术架构。

]

5.1.4.3技术架构说明

[对上面的技术架构进展说明]

5.2功能设计

[按子系统或模块进展组织，可以使用树形图表示。

5.3平安设计

[视客户具体要求，可独立章节，写方案时应考虑招标方的具体平安需求，并给出具体的建议措施。