目录

• 一、博客系统提案计划书
• • 1.引言
  • • 1.1 概述
    • 1.2 背景
    • 1.1 博客系统开发的必要性
    • 1.4开发目标
    • 1.5产品范围
• 二、项目需求萃取分析书
• • 2.1 应用背景
  • 2.2 问题域
  • 2.3 涉众
  • 2.4 项目前景与范围
  • 2.5 业务
  • 2.6 系统环境
  • 2.7 用户需求获取
  • 2.8 项目数据
• 三、项目需求分析规格书
• • 3.1 引言
  • 3.2 项目概述
  • 3.3 业务需求分析
  • 3.4 非功能需求
• 四、需求分析应有需求测试与改善计划
• 五、项目Glossary
• 六、参考文献

一、博客系统提案计划书

1.引言

1.1 概述

1.2 背景

1.1 博客系统开发的必要性

1.4开发目标

1.5产品范围

二、项目需求萃取分析书

2.1 应用背景

2.2 问题域

2.3 涉众

2.4 项目前景与范围

2.5 业务

2.6 系统环境

2.7 用户需求获取

2.8 项目数据

三、项目需求分析规格书

3.1 引言

3.2 项目概述

3.3 业务需求分析

3.4 非功能需求

四、需求分析应有需求测试与改善计划

五、项目Glossary

六、参考文献

一．博客系统需求提案计划书
1.引言

1.1概述

“博客”（Blog）源于“Web Log（网络日志）”，是一种十分简易的傻瓜个性信息发布的方式。任何人都可以像使用免费的电子邮件一样，完成个人网页的创建、发布和更新。博客。博客是开放的私人空间，可以充分利用超文本链接、网络互动、动态更新等特点，精选互联网中最有价值的信息、知识等。将个人工作过程、生活故事、思想历程和闪现的灵感等及时记录，用发布的方式分享自己的经验，可以广泛结交汇聚朋友，方便了人与人之间的沟通和交流。

1.2背景

在没有博客之前，人们经常进出论坛发表帖子或者通过即时通信软件聊天，可是这些都是零散和杂乱的。发表博客的构想始于1998年，到了21世纪初人们更广泛的使用互联网，博客才真正流行起来，起初博客进入中国并没有引起重视，到2005年国内各门户网站，如新浪、搜狐等加入到博客阵营，博客开始迅速发展，深刻地影响、走进了群众的生活。起初博客用户只是浏览博客内容，发表评论和将自己日常生活记录下来，公开分享给其他人。随着博客系统的快速扩张，有了更多样化的内容，其目的逐渐地改变，与起初使用博客的目的已有很大的差异，不过博客沟通比电子邮件、讨论群更简单、更广泛，博客已成为家庭、企业、团队之间越来越盛行的沟通工具。

1.3博客系统开发的必要性

博客的出现极大地扩充了人们交流的多样和广泛，我们使用的QQ和微信，是2个人之间的交流和一个小群体的交流，即使我们在群内聊天，也只是一个很小群体，分享的东西只能给群友或者好友看。微博分享稍微扩大了范围，不过微博也是对自己的好友和热点事件比较多，而且内容比较杂乱，没有群体讨论，不够方便。博客向全网友公布分享，博客可以有多种主题内容，所有博客分享的帖子可以公布给所有人，只要有人搜索关键词，就能方便地查看内容。博客也成为了新群体交流的方式，只要有疑惑的、有共同兴趣的可以组建一个博客群，博客群能吸收参加讨论的人就非常广泛，不限于自己是否认识、来自哪里。博客还有一个好处就是管理方便，自己发布的博客可以很好的存储在自己的创作文件夹里，需要的时候，想再看看的时候，查找起来非常方便。
1.4开发目标

管理员通过前台页面进入后台管理，可对注册的博客用户进行维护，包括对注册用户的添加、查找、修改和删除。对管理员个人账号信息管理，管理员个人信息和对博客用户进行权限设置。
实现博客用户的基本功能：①博客的注册；②登录与验证；③游客和用户通过关键字搜索博文；④热门博客页面推荐浏览功能；⑤博文和用户的访问量统计；⑥博客个人发布管理功能；⑦博客用户评论与收藏功能；⑧博客图片上传以及个人相册管理。

1.5项目范围

博客系统已经是比较成熟的产品，为了能够占据一席之地，该博客系统以美食为专题的博客系统。面向的对象是全体网络用户。

二、项目需求萃取分析书
2.1应用背景

过去很多人都喜欢写文章写日记以及交流自己的作品，以求实现相互间的沟通、展现自己的才华和让别人了解自己的想法和观点。博客的出现，让人们可以不断的把自己以前或今日激发的一些想法欧哲感受放到博客上，博客面向的群体巨大，几乎是全部人，还能加入图片，能使坐着能无拘无束地写出自己想写的，旁人也能方便地加以评论，它可以作为展示个人个性的窗户。现在博客已经成为了很多人生活中必不可少的一个部分，也是不少企业和团体组织工作中的需要。

2.2问题域

博客系统要满足用户使用方便、界面美观。首先要吸引一定的博客用户，推荐界面要比较美观整齐，用户注册博客后，要方便博客用户修改信息，发布博客，收藏博客创作和文章、查看历史记录。博客系统很成熟，新浪、搜狐等各大企业有非常完善的博客系统，如何与他人竞争，突出自己的博客特色是重点。网络是个复杂的环境，总会有一些人使用侮辱性言语，如果违反法律法规，需要进行相关的惩罚。

2.3涉众
2.3.1涉众分析
涉众的对象：①博客用户、②博客管理员、③博客开发者、④游客
网络游客可以直接访问博客，查看博客文章和创作，不过不允许评论、发布和其他功能。首先要吸引这些网络游客注册成为我们的博客用户，界面和内容上就要有足够的吸引力。成为博客用户后，要留住这些博客用户，我们需要给用户以便捷、灵活的操作，分成4个页面，让用户一看便能使用。博客的管理员要进行日常的维护和博客信息的变化，管理员要掌握博客用户的基本信息，有一个查找功能，能够快速锁定。管理员需要尽快发现有违规使用和发布危险言论或文章的要予以警告和冻结用户部分功能，系统有一个识别的功能，可以让管理员不那么费劲去查。

2.3.2涉众组织结构

在我们的博客系统中，一个系统划分为3个对象，游客、博客用户和管理员。游客是博客用户的来源，游客只有查看博文和搜索博文的权限，网络游客对该博客系统感兴趣就可以注册成为博客，管理员收到这些博客用户注册的信息，予以博客用户使用的权限，博客用户发布和评论博文，管理员负责管理博客用户信息和博文是否规范。

Organization Chart：

图例说明：让开发人员更加明确客户的需求和使界面更加整洁。
适用环境：具体描述该系统包含的部分，使层次结构更加清晰。
使用目的：使涉众组织层次结构清晰化，开发人员更加容易理解客户需求。
2.4项目前景和范围

2.4.1问题分析

问题	问题定义
游客与博客用户的权限	游客与博客用户的权限
博客的风格	选取合适的博客的主题风格，以某个领域为主要内容，系统的界面要鲜明契合主题
管理员的管理范围	管理员在维护系统和管理博客中能够管理和更新的内容
界面的更新	管理员对博客风格季节与节日变换时背景样式的改变
其他功能	博客系统基本功能以外的功能

2.4.2项目路线图

我们项目的路线图从酒店的可交付成果可分为六类，机会研究，项目立项，项目规划，项目实施，项目收尾，项目运营，每个成果交付都需要对当前阶段进行目标确认，关键研究，风险评估等，Project Roadmap图如下：

适用环境：通常用于确保对重要里程碑、可交付成果和组件有一个概述，以便在激烈的分析和实现过程中存在一个清晰而简单的计划，在高层次上描述项目。
使用目的：允许首席信息官、架构师、分析师和其他高级涉众获取项目的重要和高级方面的基于时间的可视化。
绘制步骤：使用泳道显示项目路线图图中每个方面的项。图例控制指示相位的彩色带。
图例说明：创建了一些元素和路线图图，这些元素和路线图图关注于项目的目标、目标、里程碑和可交付成果。它创建kev里程碑、计划和组成解决方案的高级组件的高级视图。路线图被分为许多部分，这些部分有助于可视化产品的特性、技术能力和一致性。
2.4.3项目功能路线图

我们项目的Capability Roadmap图如下：

适用环境：通常情况下，当业务中发生重大变化时，需要计划和开发对业务需求至关重要的核心或额外功能，并且在图表上的时间尺度所涵盖的时间段内，这也将是有用的参考。
使用目的：允许业务架构师、业务分析人员或其他涉众创建或查看组织计划在指定时间框架内创建或获取的功能的高层概要。
绘制步骤：使用泳道显示功能路线图图，以指示路线图的每个方面中的项目。图例控制指示相位的彩色带。
图例说明：创建了一些元素和路线图图，这些元素和路线图图关注于一个组织已经计划的能力，并详细说明了何时开发或获取这些能力的时间表。路线图被分为许多有助于功能可视化的部分。
2.4.4项目时间线模型
项目时间线模型是开发阶段的目标有了明确的时间段，我们项目的UAF Programme Timelines model图如下：


2.4.5非功能需求分析

功能需求和非功能需求分析都是需求分析的重要一环，我们通过分析我们项目的非功能需求，我们系统的界面应该设计成简洁易操作，提高系统的可移植性，兼容性，拓展性等。我们的Non-Functional Requirements图如下：
适用环境：实现更加完善的系统项目。
使用目的：系统描述了非功能需求。
绘制步骤：进行非功能需求分析，获取非功能需求
（1）依赖功能需求识别、获取非功能需求目标。
（2）根据非功能需求层次结构，精华非功能需求目标。
（3）量化底层非功能需求目标的验收标准。
图例说明：罗列出系统项目的非功能需求，避免系统实现时，发生系统故障，甚至实现项目失败的案例。

2.5业务
2.5.1业务激励模型
业务激励模型用于支持有关如何应对不断变化的世界的业务决策，它有两个广泛的用途：
① 捕捉有关对变革的反应和决策的理由，目的是通过学习经验，使这些决定能够共享、更加明确和改进决策。
② 参考决策结果对运营业务的影响（例如，对业务流程和组织责任所做的更改），提供从影响者到运营变更的可追溯性。
Business Motivation Model图如下：
2.5.2动机观点
动机观点允许设计者或分析师对激励方面进行建模，而不关注该方面的某些元素。例如，此观点可用于通过相关利益相关者、其主要目标、应用原则以及服务、流程、应用程序和对象的主要要求来全面或部分概述激励方面。
Motivation Viewpoint图如下：
2.5.3原则观点

博客系统的开发原则观点是保证系统运行的稳定，方便博客用户的使用，保证系统运行的数据一致性，降低模块耦合度，我们小组的Principles Viewpoint图如下：

2.6系统环境
博客系统是基于Web开发的项目，可以在任意浏览器中运行。

2.7用户需求获取
2.7.1用户背景
博客系统的用户主要来源于网民，喜爱烹饪和热爱美食的网友。

2.7.2 需求目的

博客系统的专题为美食，为喜爱烹饪和美食的网友提供一个交流的平台，展现自己厨艺发帖展现给大家，也可以记录自己在不同的地域所感受到的美食和文化联系起来，发博客给他人看。博客用户可以查看他人的美食博客拓宽视野，学习文化和烹饪。

2.8.3用例
博客系统功能图例说明：
没有用户的游客只能在博客里面查看他人的博客内容，博客用户登录后，可以发博客，查看别人的博客并评论，对自己的信息进行设置。系统的管理员管理博客内容、管理用户的信息，对系统有更新和一些活动在公告处发布，向博客用户推荐一些文章。对积极的博客用户予以奖励，对违反相关规定的博客用户予以警告、限制、冻结等惩罚。

2.8.4企业组织结构图
组织结构分为服务对象、技术部门和后勤部门，我们的Motivation Viewpoint图如下：
2.8.5需求实现流程图
Activity Diagram


2.8项目数据
2.8.1部署
系统在运行时，前后端的数据交互都在云服务器上运行，用户的操作获取的数据和数据的更新如图Deploy Diagram：
2.8.2模型
项目通过业务中涉及到的对象划分以下实体，领域模型图Domain Model如下：
2.8.3数据库
数据库设计包括了如下数据表：博客管理员、博客用户和博文内容。
2.9.4数据流图
系统运行过程中，主要涉及两部分数据流向，一部分是管理员在系统后台管理界面上发出的对数据库操作的数据流，另一部分是用户（包括博客用户和游客）在应用前台使用系统时所产生的的数据流
三、项目需求分析规格书
3.1引言
3.1.1编写目的
该项目需求分析规格书的目的是为了明确博客系统的目标，指导系统的开发工作。

3.1.2项目说明
该项目是一个美食博客

3.1.3项目背景与前景
①博客数量迅速增加。承继2005年博客开始大众化、爆发式发展，2006年，中国博客依然保持着良好的发展势头，博客数量增长迅速。根据互联网协会统计，目前博客数量已经达到3000万，而且增长空间巨大，互联网实验室在《2005-2006中国博客发展与趋势分析研究报告》中预测2006年中国博客将达到6000万的规模。博客用户规模的迅速扩大，为移动博客开拓了有利的发展空间。
②手机用户规模巨大，商机无限。
中国的手机用户规模已经居世界第一。信息产业部统计数据显示，截至到今年6月底，中国移动电话用户已超过4.26亿户。目前，中国的手机用户与网民的比例是4.26：1.23，有巨大规模的手机用户作为潜在的用户群，博客的规模不会受限于网民数量，将会更加巨大。
③手机功能日益丰富。
现在，手机功能日益丰富，越来越多的手机具有照相功能，高端的手机甚至支持长时间数码摄像。同时手机操作简单、方便，这些将大大降低用户使用博客的门槛。

3.2项目概述
3.2.1现状
项目已经完成了需求的采集与需求的分析工作。接下来会进行概要设计以及详细设计。

3.2.2目标

我们的博客系统要满足以下的功能：
①以美食为专题的博客，界面以食材厨房等与美食有关的主题；
②博客用户注册，用户信息的填写；
③首页推荐，推荐一些好的或者热门博文在首页，有一个随时可以替换预备博文的功能，用户在不同时段登陆看到的文章是不一样的；
④博客的发布和评论，可以使用图片和表情；
⑤博客收藏功能；
⑥博客系统快捷查看回复；
⑦以时间为排序的博客浏览功能；
⑧博文搜索功能；
⑨管理员发布公告和调整背景功能；
⑩自动检测敏感信息和关键词功能，对发布敏感内容的博文进行删除；
让更多人在该博客系统里分享有关美食的主题，与食物文化无关的主题进行屏蔽。做成一个专题博客，对发布博客多而且质量高的用户予以奖励，可以发布一些活动比赛对优胜者进行奖励，对于违法敏感博文尽快发现并删除警告。像CSDN一样有众多的博客用户与讨论交流，是我们的目标。

3.2.3建设任务
项目采取瀑布流模式。整个项目周期包括：需求分析，规格说明，概要设计与详细设计，编码实现，综合测试以及后期的维护运营。
该项目的时间分配：
会安排1个月的时间进行前提的需求采集以及需求分析，然后使用1个月的时间，进行项目的概要设计与详细设计，再会用3个月的时间进行系统开发。在用大约半个月的时间进行整体测试。接着就准备上线，先进行内测，邀请一些人作为用户并使用，将发现的问题进行研究讨论，根据实际情况与资金技术情况做出调整。系统上线后，培养一些维护人员对系统进行日常规律性的维护。

3.2.4用户特点

该用户的来源主要是网友，只要有使用智能手机与上网的用户都有可能成为我们的用户，我们的博客以美食为主题，所以是对美食与美食文化感兴趣的网友成为我们的用户。
后台管理员对博客系统进行维护，对博客系统的界面和要发布的活动比赛等告知博客用户，对博客系统的安全和规范上面进行工作。

3.3业务需求分析
3.3.1系统范围

博客系统的最主要的功能是发布博客、评论博客、查看大家的博客和收藏博客，界面背景设置成可替换并推荐一些博文，还要一个以时间为发布顺序的博文界面。博客用户个人页面有信息的修改和完善，快速查看回复内容。管理员可以给博客用户或者公告栏发通知，检测博文内容的合法性，对违法国家法律和不符博客主题的内容进行删除。
3.3.2系统体系结构
我们项目的系统体系采用B/S架构，客户端基于网络在浏览器上运行，无需安装。该系统初期服务端采用单机模式，后期项目运行成熟后，用户规模增大后采用分布式架构。系统的整体需求图Requirements Diagram如下：
3.3.3系统事务流程
1.用户登录
时序图（Sequence Diagram）
描述用户登录流程时的信息流，用户在登录该系统，会先往web服务器发送申请，然后web服务器会根据账户与密码进行验证，若是，验证一致后，服务器就会返回成功信息，并形成cookie信息，若是失败则会返回失败信息，并提示用户登录失败。

2.用户发布博客流程：
Data Flow Diagram
3.4非功能需求

3.4.1性能需求
3.4.1.1精度
保证查准率,查到的记录应与给定的单项或组合查询条件完全匹配。以事务为单位提交数据,若出现异常故障,需返回到未提交前。

3.4.1.2时间特性要求
由较高的时效性，对服务器响应速度的要求较高，在95%的时间里，服务器响应时间少于120ms，高峰期少于300ms。

3.4.1.3灵活性

3.4.2输入输出需求
数据传输按照Json格式传输。

3.4.3故障处理要求
建立足够数据冗余：使用镜像盘，在别的数据库服务器上，对主数据库服务器上的数据进行备份
数据库引擎出现故障可能导致整个系统的瘫痪,影响所有的操作人员,建议配置一个后备服务器应急。网络连接故障会导致无法连入数据库,从而使某个操作人员无法使用系统,需人工排查网络故障。系统需用到一些外部辅助软件,例如office 等,如果未安装这些软件,可能会影响部分功能。

四、需求分析应有需求测试与改善计划
4.1需求测试
需求指明被测对象中什么需要测试。需求测试通常是以软件开发需求为基础的分析，通过对需求的细分化和分解，形成可测试的内容。测试需求因覆盖全部已定义的业务流程，以及功能和非功能方面的需求。
我们的项目中需要做测试的部分有界面的需求测试、博客发布博文和评论的测试、个人收藏和创作的测试、快速查阅回复的测试等。

4.2需求测试的需求点
功能需求：功能性需求是产品必须完成的那些事情，要求一定的功能品质。
非功能需求：如感官，易用性，安全性，性能，法律法规等这些属性方面的需求。
限制条件：限制条件是指全局性的，它们可以对整个项目进行有限制。
挖掘需求：挖掘需求是指在产品阶段未能完全定义出的需求，如同在客户沟通挖掘出更深层次的需求。以免后期需求变动。导致项目失败。

4.3需求测试的主要运用方法
业务模型法：要参与需求评审，评审需求的过程实际也是熟悉业务需求的过程。只有对业务比较熟悉了，才能更好的，更充分的设计出高质量的测试用例。
业务场景法：要善于沟通，多和客户、开发、测试人员进行沟通。遇到不明确的问题、有疑问的需求，可以咨询项目负责人或者客户等。这样才能提前解决需求理解偏差等。
功能分解法：业务功能，辅助功能，数据约束，易用性需求，编辑约束，参数约束，权限约束
细节挖掘：
1.要多阅读文档，其中包括产品策划书、规格说明书、需求文档，接口文档等，与同类的博客系统做对比，发现别人系统的亮点，找到别人系统的不足，以此可以对自己博客系统进行完善，分析我们需要的并作出亮点，对于不足之处加以改进。
2.尽量多参加项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，这样在讨论过程中也能加深对产品的理解。

4.4需求测试的主要工作
目前一些敏捷型开发，甚至都是采用的测试驱动，以测试用例为主导反推写代码。这样在某些方面开发出来的质量会更高。
A.测试需求，检查需求文档描述的正确性，整理出需求的疑问点，明确点，让所有人一致理解正确的需求。可运用的方法：路径分析法（业务模型，场景分析）。
B.测试用例编写，从界面，从业务，从功能出发。
因果分析法，边界值法，等价类划分法，错误推测法（反向测试用例）等。
C.缺少需求文档时，那就要发挥测试人员的主管能动性了。

4.5需求测试的总结
1.结合业务场景，了解业务
2.结合基本需求，挖掘需求
3.结合分解方法，测试需求
4.结合用例编写，覆盖需求
4.6改善计划
对博客系统进行改善，要根据博客用户的增长进行更全面的维护，要保证原系统的正常运作，系统总是会有问题，要不断地去发现系统使用时出现的BUG，或者在功能方面不够的地方，对于这些要不断地去优化。系统的响应速度和审批速度需要更好的算法去加速，在系统平稳运行时，还要去逐渐添加一些新的功能，参考别的系统新出现的功能和亮点，要形成自己特有的功能，有些新技术的出现要及时学习，能够用在系统上就可以开始进行继续的扩展业务。

五、项目Glossary

序号	名词	解释
1	Capability Roadmap(功能路线图)	能力路线图概述了组织计划未来季度和数年拥有的大规模能力。能力路线图不是跟踪特定的项目或计划，而是阐明组织计划在给定时间段内能够实施的计划或项目。能力路线图是制定长期战略的一种面向目标的方式，它侧重于组织的潜力，超越任何特定计划的限制。
2	Project Roadmap（项目路线图）	项目路线图是关键利益相关者从战略角度可视化项目并做出关键决策的简单、易于遵循的真相来源，而无需筛选细节。项目管理路线图提供了明确界定的细分
3	Organization Chart（组织结构图）	组织结构图或"组织结构图"的定义是显示报告或关系层次结构的图表。组织结构图最常见的应用是显示企业、*或其他组织的结构。组织结构图有多种用途，可以以许多不同的方式进行结构化。例如，它们可用作管理工具、规划工具或人员目录。也许您的组织不是以"命令和控制"方式运行，而是依赖于团队。
4	Organization Viewpoint(组织观点)	组织观点侧重于公司、部门、公司网络或其他组织实体的（内部）组织。可以在此视点中将模型呈现为嵌套框图，也可以以更传统的方式（如组织结构图）显示模型。组织观点对于确定组织中的能力、权限和责任非常有用。
5	Business Motivation Model（激励模型）	如果企业为业务活动规定了某种方法，它应该能够说出其目的和结果。业务激励模型 （BMM）是一个 OMG 建模符号，用于支持有关如何应对不断变化的世界的业务决策。捕捉有关对变革的反应和决策的理由，目的是通过学习经验，使这些决定能够共享、更加明确和改进决策。参考决策结果对运营业务的影响（例如，对业务流程和组织责任所做的更改），提供从影响者到运营变更的可追溯性。
6	Motivation Viewpoint（动机观点）	动机观点允许设计者或分析师对激励方面进行建模，而不关注该方面的某些元素。例如，此观点可用于通过相关利益相关者、其主要目标、应用原则以及服务、流程、应用程序和对象的主要要求来全面或部分概述激励方面。
7	Requirements Realization Viewpoint（需求实心观点）	需求实现视点允许设计人员根据核心元素（如业务参与者、业务服务、业务流程、应用程序服务、应用程序组件等）对需求的实现进行建模。通常，需求来自目标优化视点。此外，此视点可用于将要求细化为更详细的要求。聚合关系用于此目的
8	Principles Viewpoint models（原则观点	允许分析师或设计人员对与手头设计问题相关的原则进行建模，包括激励这些原则的目标
9	Requirement Specification View（需求规范视图）	需求规范是描述软件将执行的操作以及预期执行内容的文档。它还描述了产品满足所有利益相关者（业务、用户）需求所需的功能。
10	Use Case Model（用例图）	用例图主要用来描述角色以及角色与用例之间的连接关系
11	Base Mysql Model（基础MySQL模型）	基于MySQL数据库模型，描述数据库的模型
12	Database Server with Deployed Database（已部署数据库的数据库服务器）	显示一个部署图，该图描述了一系列表到数据库服务器的部署。该模式的目的是允许设计人员或技术架构师创建或查看虚拟或物理部署环境的模型，其中包括诸如机器服务器之类的节点，诸如操作系统，容器，基于软件的服务器之类的执行环境。工件和部署规范对如何将软件部署到节点或执行环境进行建模。该图显示了如何将表和其他数据库对象的建模连接到部署模型。
13	分布式	分布式网络存储技术是将数据分散地存储于多*立的机器设备上。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，不但解决了传统集中式存储系统中单存储服务器的瓶颈问题，还提高了系统的可靠性、可用性和扩展性。
14	B/S架构	B/S架构是WEB兴起后的一种网络架构模式，WEB浏览器是客户端最主要的应用软件。这种模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用。客户机上只要安装一个浏览器（Browser），如Netscape Navigator或Internet Explorer，服务器安装Oracle、Sybase、Informix或 SQL Server等数据库。
15	Deploy Diagram（部署图 ）	部署图描述了一个系统运行时的硬件节点，在这些节点上运行的软件构件将在何处物理运行以及它们将如何彼此通信的静态视图
16	Sequence Diagram（时序图）	是一种UML交互图。它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作
17	Activity Diagram（活动图）	活动图是一种表述过程基理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模
18	Data Flow Model（数据流模型）	它是为简化大规模数据处理而设计的。可以让开发者专注于数据处理的逻辑部分，而不用关注并行计算的具体实现。提供了一系列有用的抽象概念，将并行计算的具体细节封装起来
19	Non Functional Requirements Diagram（非功能性需求图）	非功能性需求主要涉及安全性、性能以及兼 容性三大方面。 在上面所有的测试用例设计中，我们完全没有考虑对非功能性需求的测试，但这些往往是决定软件质量的关键因素。
20	Domain Model Diagram（领域模型）	领域模型是领域内的概念类或现实世界中对象的可视化表示，又称为概念模型或分析对象模型，它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。

六、参考文献
需求工程：软件建模与分析/骆斌主编；丁二玉编著
https://www.docin.com/p-798589064.html
https://wenku.baidu.com/view/983664204b35eefdc8d333e8.html
https://wenku.baidu.com/view/b8c8526a1eb91a37f1115c95.html
https://wenku.baidu.com/view/0f3a7e01e518964bce847c21.html
Enterprise Architect introduce