完整版博客系统需求分析.docx
《完整版博客系统需求分析.docx》由会员分享，可在线阅读，更多相关《完整版博客系统需求分析.docx（17页珍藏版）》请在冰点文库上搜索。
完整版博客系统需求分析
校园博客系统需求分析
评审日期：
2010年04月01日
1导言1
1.1目的1
1.2范围1
1.3缩写说明1
1.4术语定义1
1.5引用标准1
1.6参考资料2
2系统定义2
2.1项目来源及背景2
2.2系统整体结构2
3应用环境3
3.1系统运行网络环境3
3.2系统运行硬件环境4
3.3系统运行软件环境4
4功能规格4
4.1角色（ACTOR）定义5
4.1.1博客访问者5
4.1.2管理用户5
4.1.3数据库6
4.2系统主USECASE图.6
4.3客户端子系统6
4.4管理端子系统8
4.4.1登录管理10
4.4.2类型管理11
4.4.3评论管理12
4.4.4留言管理12
4.4.5图片管理12
4.4.6用户管理13
5性能需求13
5.1界面需求13
5.2响应时间需求13
5.3可靠性需求13
5.4开放性需求14
5.5可扩展性需求14
5.6系统安全性需求14
6产品提交14
7实现约束14
1导言
1.1目的
重点描述了校园博客系统的
该文档是关于用户对于校园博客系统的功能和性能的要求，
设计需求，将作为对该工具在概要设计阶段的设计输入。
本文档的预期读者是：
设计人员
开发人员
项目管理人员
测试人员
用户
1.2范围
该文档是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决整个项目系统的“做什么”的问题。
在这里，对于开发技术并没有涉及，而主要是通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。
1.3缩写说明
BM
BlogManager（博客管理员）的缩写。
JSP
JavaServerPage（Java服务器页面）的缩写，一个脚本化的语言。
1.4术语定义
无
1.5引用标准
[1]《企业文档格式标准》V1.1北京长江软件有限公司
[2]《需求规格报告格式标准》V1.1北京长江软件有限公司软件工程过程化组织
1.6参考资料
[1]《UML》V1.1北京长江软件有限公司
[2]《需求规格报告格式标准》V1.1北京长江软件有限公司软件工程过程化组织
2系统定义
我们分别阐述一下项目的来源、背景和项目的目标。
2.1项目来源及背景
本项目是为在校大学生开发的一个校园博客系统。
学校不仅是学生学习的天地，更是同学之间交流的广场。
随着Internet信息技术的发展，网络渐渐成了当今在校大学生交流信息的重要渠道。
如何为在校大学生提供一个资源共享信息交流的平台呢？
校园博客系统将填补这方面的不足。
为现实校园信息与学生牵线搭桥的作用，来弥补资源共享中存在的种种不足。
在这种条件下，我们开发了校园博客系统。
学生在线注册登录系统，通过系统发布个人博文（日志）等学习信息资源，后台审核归类，在首页显示分类总信息供学生阅览。
在线用户也可通过阅览等到相应信息。
项目要达到的目标
本项目设定的目标如下：
1.系统能够提供友好的用户界面，使操作人员的工作量最大限度的减少
2.系统具有良好的运行效率，能够得到提高生产率的目的
3.系统应有良好的可扩充性，可以容易的加入其它系统的应用。
4.平台的设计具有一定的超前性，灵活性，能够适应企业生产配置的变化。
5.通过这个项目可以锻炼队伍，提高团队的开发能力和项目管理能力
2.2系统整体结构
根据用户的需求陈述，可以确定本项目分为客户端和管理端，客户端主要功能是提供阅读文章、发表评论、发表留言等等。
管理端的功能提供博客管理人员进行的类型管理、文章管理、评论管理等。
他们的关系如图A-1。
图A-1校园博客系统流程图
3应用环境
本项目的应用环境可以分硬件环境、软件环境和网络环境来描述。
3.1系统运行网络环境
本系统的网络运行图如图A-2，无论是客户端的访问者还是管理端的BM等都可以通过网络登录到本系统中。
访问者通过网络发布相关信息及通过网络发表评论。
图A-2：
网络拓扑图
3.2系统运行硬件环境
本系统的硬件环境如下：
客户机：
普通PCCPU：
P41.8GHz内存：
256MB以上分辨率：
推荐使用1024*768像素
WEB服务器
Internet信息服务（IIS）管理器数据库服务器
CPU：
P41.8GHz内存：
256MB以上
3.3系统运行软件环境
操作系统：
WindowsXP数据库：
SQLServer2005开发语言：
ASP.NET+C#浏览器：
IE7.0
4功能规格
我们采用面向对象分析作为主要的系统建模方法，使用UML（UnifiedModelingLanguage）作为建模语言。
UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。
在UML中，从任何一个角度对系统所作的抽象都可能需要几种模型来描述，而这些来
自不同角度的模型图最终组成了系统的映像。
UseCase描述的是“actor”（用户、外部系统以及系统处理）是如何与系统交互来完成工作的。
UseCase模型提供了一个非常重要的方式来界定系统边界以及定义系统功能，同时，该模型将来可以派生出动态对象模型。
设计Use-case时，我们遵循下列步骤：
第一步，识别出系统的“actor”。
Actor可以是用户、外部系统，甚至是外部处理，通过某种途径与系统交互。
重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能，并指明这些功能的执行者（Actor）是谁。
尽可能地确保所有Actor都被完全识别出来。
第二步，描述主要的UseCase。
可以采取不断地问自己“这个Actor究竟想通过系统做什么？
”来准确地描述UseCase。
第三步，重新审视每个UseCase，为它们下个详尽的定义。
4.1角色（Actor）定义
角色或者执行者（Actor）指与系统产生交互的外部用户或者外部系统。
4.1.1博客访问者
博客访问者是指在这个网络校园博客系统中通过客户端匿名或已注册的人员，这个
Actor主要参与客户端的阅读文章、发表评论、发表留言等功能。
4.1.2管理用户管理用户是指管理端的用户，这个此Actor派生两个子类，BM（博客管理员）和系统管理员，BM是指在校园博客系统中通过管理端参与博客管理员工作的人员，她又可以派生多个子类如文章管理者、评论管理者和留言管理者。
系统管理员是指对校园博客系统系统进行相关设置、维护的人员，它也是通过管理端登录对管理端的用户进行设置，分配权限等，它们的关系如图A－3：
图A-3：
BM角色的关系图
管理用户部分说明如下：
BM
文章管理者
－管理知识库、组织文章的发布、删除和修改。
评论管理者
－根据相关规定对评论进行设置。
留言管理者
－整理留言。
系统管理员
－通过管理端对系统用户进行管理的人员，这个Actor主要负责对管理端用户的增加，权限的设置等功能。
4.1.3数据库
数据库是一个与系统产生交互的外部系统，这个Actor负责系统的数据查询、增加、删除和修改等操作。
本网站采用SQLServer2005数据库，名称为db-Blog，其中包含9张数据表。
4.2系统主UseCase图
校园博客系统可以分为两个主要的组成部分，一个是客户端子系统，一个是管理端子系统。
客户端子系统主要是指博客访问者通过登该博客网站进行操作的功能。
管理端子系统是该博客网站的管理人员发布文章，整理评论，留言等功能。
系统的主UseCase图如图A-4所示。
图A-4：
系统的主UseCase图
4.3客户端子系统
博客访问者通过校园网站登录到系统中进行访问，博客管理员通过它发布文章，提供链接等等，这就是客户端子系统的功能。
在客户端用户可以浏览、阅读文章，点击链接，发表评论，发表留言几项。
它的活动图如图A-5所示。
图A-5：
客户端的活动图
客户端管理的部分功能描述如下：
F-C-1：
浏览功能
1、列出所有的项，包括留言、日志、图片、视频、音乐、个人资料等；
2、可选定一项记录，显示所有域；
F-C-2：
查询功能
1、日志标题关键字查询；
2、图片标题关键字查询；
3、留言标题关键字查询；以上的输入可在指定的位置输入关键字，经过系统内部关键字匹配机制，最终得到相应的查询结果，没有查到时提供提示机制。
F-C-3：
修改功能
1、更改背景图片,更改已发表日志，更改个人信息资料；
2、进入修改功能页面后，修改相应内容，系统内部将新内容替换掉就内容，修改信息
成功或失败时提供提示机制，并在成功后显示修改后结果。
F-C-4：
添加功能
1、添加一个新的记录（图片、日志、个人信息等）；
2、进入增加功能页面后，根据意向添加所需内容，系统内部在原有内容基础上添加内容。
添加信息成功或失败时提供提示机制，并在成功后显示添加后的结果。
F-C-5：
留言功能
此功能是专门为访客设计的，一般管理员不使用此功能。
访客在浏览过博客之后，进入留言界面，写下自己的感言，输入验证码发表。
发表信息成功或失败时提供提示机制，并在成功后显示发表后的结果。
4.4管理端子系统
管理端主要是指提供系统后台系统管理员使用的功能部分，它的功能分为用户管理、登录管理等部分，每个登录者首先经过认真安全认证然后缺陷权限，根据相应的权限现实相应的功能。
F-L-1：
登录管理
登录管理是负责所有的管理端的登录，管理端的人员要登录到管理端必须经过登录界面，输入自己的用户名和密码，通过判断这个用户的权限信息，不同的登录人可能具有不同的权限，根据不同的权限现实不同的功能。
F-M-1：
类型管理：
类型管理用例是管理员登录到系统，管理员根据博客中提取出来生成各种类别的文章，并且可以对文章内容进行增、删、改的功能。
F-M-2：
评论管理：
评论管理用例是管理员登录到系统，整理各类评论并可对评论管理进行增、删、改的功能。
F-M-4：
留言管理：
留言管理管理用例是博客系统管理人员对博客访问者发布的留言进行整理。
F-M-5：
图片管理：
图片管理是人员系统管理员对博主发布的文章内容进行审核时，应对地对文章中的图片进行批准发布或屏蔽的功能。
F-A-1：
用户管理
当进入用户管理模块时，在用户管理中可以增加或删除用户，编辑用户名，用户密码，修改用户权限，具有不同权限的用户进入系统主界面，界面左侧栏中的图标数有所不同，具体的面标与用户所具有的权限对应。
4.4.1登录管理
登录到管理端的所有人都需要通过登录界面进入相应的管理界面，不同的登录人具有不同的权限，根据登录人具有的权限将相应的功能现实在登录到的管理界面，没有权限操作的功能将在现实在这个界面上。
活动视图如图A-8。
4.4.2类型管理
在校园博客系统中，大量文章的发布可通过某些关键字进行分门别类，以提供索引共浏览者搜索。
其具体描述如下：
用例描述：
类型管理
执行者：
系统管理者
前置条件：
系统管理者已登录系统；
后置条件：
如果类型成功后，则数据库中的类型库随之变化。
基本路径：
a）进入系统管理界面，首先展示目前数据库已有的类型；
b）点击类型可以详细浏览这个类型的具体内容，同时也可以对这个类型的具体内容进行修改；
c）提供增加类型的按钮，增加类型时，首先选定类别，然后类型名称、类型内容、确定可选答案（多个）等；
d）可以删除选择的类型。
4.4.3评论管理
在校园博客系统中，要定期整理评论，不仅要删除或屏蔽部分不符合要求的评论，还可以对评论进行设置，推出精品评论或话题评论，增加点击量，提高人气。
具体功能描述如下：
用例描述：
评论管理执行者：
系统管理者
前置条件：
系统管理者已登录系统；后置条件：
如果评论设置成功后，则数据库中的数据随之变化。
基本路径：
a）进入系统管理界面，首先展示目前存在的文章；
b）点击每个文章可以详细浏览每个文章的评论：
c）可以对一些评论进行删除，或者可以重新整理各个评论的顺序；同时可以预览整个文章；
d）提供增加评论的按钮，增加评论时，从数据库中选择评论；
e）可以删除选择的评论。
4.4.4留言管理
留言管理是校园博客系统的功能之一，系统管理人员根据某些管理条例规定，对留言进行批准审核，博客管理人员也可根据自己喜好删除留言。
具体功能描述如下：
用例描述：
留言管理
执行者：
系统管理者、博客管理者前置条件：
管理者已登录系统；后置条件：
如果留言管理成功后，则数据库中的留言信息随之变化，管理员和浏览者均可通过文章页面看到留言的更新。
基本路径：
a）进入系统管理界面，首先展示目前已存在的留言；
b）通过点击每篇博文，可以详细浏览每个留言的详细描述；
c）提供留言删除
4.4.5图片管理
博客管理员发布的文章中包含图片可提高博文的精彩度和点击量。
系统管理员则可根据具体条例或某些规定屏蔽或删除某些不符合要求的图片。
具体的功能描述如下：
用例描述：
图片管理执行者：
系统管理者
前置条件：
系统管理者已登录系统；
后置条件：
图片整理完成后，则浏览者和管理员均可在博文发布页面看到更新后的内容。
基本路径：
a）进入系统管理界面，首先展示正在浏览中的博文目录；
b）通过点击目录进入相应的博客文章界面；这个界面也显示了每个博主的用户名以及目前的处理状态等信息；
c）对图片有三种处理结果：
批准图片发布、删除图片、屏蔽图片；
d）对于图片的采取的不批准的处理结果，可以采用留言等方式通知博主，并通过处理方式发布相应警告。
4.4.6用户管理
系统管理员可以进行权限设置，在用户管理中对用户进行增删改查。
具体功能描述：
用例描述：
用户管理
执行者：
系统管理员
前置条件：
系统管理员已登录系统；
后置条件：
如果用户信息维护后，则用户的相应信息记录到数据库中。
基本路径：
a）进入用户管理界面，显示目前的系统用户，以及每个用户具有的权限；
b）点击不同的用户，可以显示这个用户的信息以及相应权限，必要时可以修改其权限；
c）可以增加用户，也可以删除用户。
5性能需求
根据用户对本系统的要求，
确定系统在响应时间、可靠性、安全等方面有较高的性
能要求。
5.1界面需求
系统的界面要求如下：
１）页面内容：
主题突出，站点定义、术语和行文格式统一、规范、明确，栏目、菜单设置和布局合理，传递的信息准确、及时。
内容丰富，文字准确，语句通顺；专用术语规范，行文格式统一规范。
２）导航结构：
页面具有明确的导航指示，且便于理解，方便用户使用。
３）技术环境：
页面大小适当，能用各种常用浏览器以不同分辨率浏览；无错误链接和空链接；采用CSS处理，控制字体大小和版面布局。
４）艺术风格：
界面、版面形象清新悦目、布局合理,字号大小适宜、字体选择合理，前后一致，美观大方；动与静搭配恰当,动静效果好；色彩和谐自然,与主题内容相协调。
5.2响应时间需求
无论是客户端和管理端，当用户登录，进行任何操作的时候，系统应该及时的进行反应，反应的时间在5秒以内。
系统应能监测出各种非正常情况，如与设备的通信中断，无法连接数据库服务器等，避免出现长时间等待甚至无响应。
5.3可靠性需求
系统应保证7X24内不当机，保证20人可以同时在客户端登录，系统正常运行，正确提示相关内容。
5.4开放性需求
系统应具有十分的灵活性，以适应将来功能扩展的需求。
5.5可扩展性需求
系统设计要求能够体现扩展性要求，以适应将来功能扩展的需求。
5.6系统安全性需求
系统有严格的权限管理功能，各功能模块需有相应的权限方能进入。
系统需能够防止各类误操作可能造成的数据丢失，破坏。
防止用户非法获取网页以及内容。
6产品提交
提交产品为：
a）应用系统软件包
b）数据库初始数据
c）系统开发过程文档
d）系统使用维护说明文档
提交方式：
CD介质
7实现约束
系统的实现约束如下：
a）操作系统为ＷindowsServer2003（SP1）
b）开发环境运行平台为：
WindowsXP
c）数据库为SQL2005
升级会员 