微博实现及管理系统需求文档 3.docx
- 文档编号:8906371
- 上传时间:2023-02-02
- 格式:DOCX
- 页数:21
- 大小:124.40KB
微博实现及管理系统需求文档 3.docx
《微博实现及管理系统需求文档 3.docx》由会员分享,可在线阅读,更多相关《微博实现及管理系统需求文档 3.docx(21页珍藏版)》请在冰豆网上搜索。
微博实现及管理系统需求文档3
需求分析文档
课题名称:
微博使用及管理系统
指导教师:
张永强
专业班级:
09级计算机1班
小组成员:
王玮
张强
何宇清
张开元
王舜
目录
第一部分项目概述3
1.1目的和范围3
1.2项目目标4
第二部分用户需求描述6
用户简介6
业务流程说明6
第三部分系统需求描述13
3.1系统范围13
3.2功能需求14
3.3数据需求24
第四部分系统约束28
4.1界面28
4.2运行环境的要求29
4.3处理时间的要求29
4.4存储的要求30
4.5健壮性要求30
4.6安全性要求30
第一部分项目概述
1.1目的和范围
项目背景:
随着互联网技术的进一步发展,信息交流的形式极大地丰富了起来。
以电子邮件为代表的传统的通讯方式还在发挥着它们的作用。
而一些新型的技术,例如即时通讯软件,社交网站等形式已经普遍的被广大网民所接受和认可。
其中,又以facebook,twitter和中国的微博为近两年来的佼佼者。
人们已经习惯于从微博上收听新闻,交流信息,分享热点话题。
作为信息时代的领航者,软件行业对微博类软件的开发也是如火如荼。
本次我们小组进行的就是一个微博使用及管理系统的开发。
开发该系统的目的:
本次我们小组开发的微博使用及管理系统,主要是为满足使用者发布文字信息,图片,浏览他人微博并进行评论等常用微博功能,以及管理员对普通用户进行的账户管理,微博管理,资格认证等管理类操作。
以网页的形式实现一个简单的微博使用及管理系统,便于使用者分享信息,满足互相之间交流的需要。
覆盖业务:
1.微博使用部分:
发布微博,浏览他人微博,评论微博,发布照片,浏览照片,更改个人信息。
2.账户管理部分(前提是拥有管理员权限):
系统信息查看功能:
包括查看本系统普通用户数量,发布微博总量,已认证用户数量。
管理功能:
删除违法微博,删除违法照片,删除普通用户账户。
认证功能:
对普通用户进行认证。
1.2项目目标
普通用户使用本系统,可以方便的实现信息共享,及时获取其他用户的微博信息,照片信息,并评论他人的微博。
管理员用户使用本系统,可以对普通用户发布的微博,照片等进行审查管理,并且删除其中涉及政治,宗教以及其它违法违规信息。
第二部分用户需求描述
用户简介
本系统用户定义:
这里所说的用户是指已经在本系统注册成功的使用者,不包括未注册或注册不成功的游客。
本系统的用户包括两种:
普通用户以及管理员用户。
管理员权限属于哪个用户由本系统开发者决定。
游客需求
对于未注册的游客,不允许使用本系统。
不能浏览使用者发布的微博,照片以及个人信息。
游客只有在注册成功后才能浏览到相关内容。
普通用户需求:
通过输入自己的用户名,密码进入到自己的主页。
主页应该包括浏览区,微博发布区,以及个人资料三个部分。
在浏览区可以看到其他用户发布的微博,照片。
对其他用户发布的微博进行评论,评论字数50字以内。
在微博发布区书写自己的微博,并可以添加相关照片。
微博字数150字以内。
在个人资料处点击打开个人资料页面,并可以对用户名,密码等个人资料修改。
个人资料包括:
用户名,密码,联系邮箱,所在地市。
允许添加其他用户为关注人。
登陆后在浏览区显示关注人所发微博。
管理员用户需求:
通过输入管理员用户名,密码进入到自己的主页。
主页应包括查看区,管理区,认证区三个部分。
查看区可以查看用户数量,微博总量,认证用户数量。
管理区可以删除普通用户发布的不合法微博,相片。
可以删除违法用户的账户。
管理员无权更改用户的个人资料。
认证区可以对符合认证条件的用户进行认证,或者对已认证的用户取消其认证资格。
(是否符合认证条件由管理员自行决定)。
业务流程说明
游客注册流程图
登陆业务:
微博发布业务:
修改个人资料业务:
评论微博业务:
管理员查看业务:
管理员管理业务:
游客注册界面
第三部分系统需求描述
3.1系统范围
管理员用户数据流图
如图所示,管理员用户进入个人主页后,操作产生的数据流图。
管理及认证带来的数据变化及时的反应在查看页面。
管理员所进行的操作均由后台数据库进行相应的更新操作。
查看时的数据来源于数据库的查询操作所返回的数据。
3.2功能需求
普通用户用例图
发布微博
参与者
普通用户,本系统
描述
普通用户在微博发布区输入文字信息,点击发布后将数据保存到后台数据库,成为一条记录。
如果有图片,则存入个人相册中。
数据
输入的150字以内的文本字符串,或许还有图片
激励
用户点击发布区的提交按钮
响应
数据库保存成功后,窗口提示:
发布成功
注释
发布内容不能为空,否则发布不成功
用例“发布微博”的表格描述
浏览他人微博
参与者
普通用户,本系统
描述
普通用户在浏览区能够看到他关注的好友所发布的所有微博,照片以及个人信息。
也可以以打开新窗口的形式进入其他用户的个人主页
数据
其他用户发布的微博信息
激励
用户点击链接进入其他用户主页
响应
来自其他用户数据库表的更新信息
注释
评论微博
参与者
普通用户,本系统
描述
普通用户在浏览区能够看到他关注的好友所发布的微博,点击评论按钮可以进行评论。
评论字数在50字以内。
被评论的用户可以看到评论信息。
数据
用户发布的评论信息
激励
用户点击评论按钮提交数据
响应
来自用户数据库表的更新信息
注释
评论微博必须在微博允许存在的前提下
个人信息管理
参与者
普通用户,本系统
描述
普通用户在个人信息管理页面可以看见其原来的个人信息,包括用户名,密码,邮箱,地址。
并可以进行更改,更改后的信息必须符合系统要求。
数据
用户提交的个人信息
激励
用户点击提交按钮提交数据
响应
来自用户数据库表的更新信息
注释
其他普通用户包括管理员无权更改任何人的个人资料
查看所有微博
参与者
管理员用户,本系统
描述
在查看页面显示所有用户发布的微博,产生统计信息,包括微博总量,各用户分别发布微博数量,各用户发布照片数量。
数据
用户发布的微博信息,图片。
数据库的统计数据
激励
管理员用户进入查看界面
响应
系统将相关数据显示在查看页面
注释
查看所有用户数量
参与者
管理员用户,本系统
描述
在查看页面显示所有用户发布的数量,产生统计信息,包括普通用户数量,管理员用户数量
数据
数据库统计信息
激励
管理员用户进入查看界面
响应
系统将相关数据显示在查看页面
注释
查看认证用户数量
参与者
管理员用户,本系统
描述
在查看页面显示所有认证用户的数量。
数据
数据库的统计数据
激励
管理员用户进入查看界面
响应
系统将相关数据显示在查看页面
注释
删除违法微博
参与者
管理员用户,本系统
描述
在管理页面根据相关法律法规删除普通用户发布的违法微博
数据
用户发布的微博信息。
激励
管理员点击删除按钮
响应
后台数据库删除相关用户表中的某条记录并提示删除成功。
注释
删除违法照片
参与者
管理员用户,本系统
描述
在管理页面根据相关法律法规删除普通用户发布的违法照片
数据
用户发布并保存在相册中的图片。
激励
管理员点击删除按钮
响应
后台数据库删除相关用户表中的某条记录并提示删除成功。
注释
删除违法账户
参与者
管理员用户,本系统
描述
在管理页面根据相关法律法规删除普通用户账户
数据
数据库维护的某张用户表
激励
管理员点击删除按钮
响应
后台数据库删除相关用户表
注释
认证用户
参与者
管理员用户,本系统
描述
管理员用户对普通用户进行认证操作,被认证的用户用户名后有加“V”字样
数据
普通用户在后台数据库的表
激励
管理员发出操作,修改数据库
响应
用户的认证状态被修改
注释
取消认证用户
参与者
管理员用户,本系统
描述
管理员用户对普通用户进行取消认证操作,已被认证的用户用户名后不再有加“V”字样
数据
普通用户在后台数据库的表
激励
管理员发出操作,修改数据库
响应
用户的认证状态被修改
注释
取消认证的前提是该用户已被认证
3.3数据需求
3.1数据概念设计
在概念设计阶段中,设计人员从用户的角度看待数据及处理要求和约束,产生一个反应用户观点的概念模式。
然后再把概念模式转换成逻辑模式。
将概念设计从设计过程中独立开来,使各阶段的任务相对单一化,设计复杂程度大大降低,不受特定DBMS的限制。
利用E-R方法进行数据库的概念设计,可分为三步进行:
首先设计局部E-R模式,然后把各局部E-R模式综合成一个全局模式,最后可对全局E-R模式进行优化,得到最终的模式,即概念模式。
3.1.1设计局部E-R模式
(1)实体和属性的定义
管理员(账号,密码,用户)
用户(账号,密码,微博,日志,相册,评论)
微博(发表,删除)
日志(发表,删除)
相册(发表,删除)
评论(发表,删除)
(2)E-R图
3.1.2设计全局E-R模式
所有局部E-R模式都设计好了后,接下来就是把它们综合成单一的全局概念结构。
全局概念结构不仅要支持所有局部ER模式,而且必须合理地表示一个完整、一致的数据库概念结构。
(1)确定公共实体类型
为了给多个局部E-R模式的合并提供开始合并的基础,首先要确定各局部结构中的公共实体类型。
在这一步中我们仅根据实体类型名和键来认定公共实体类型。
一般把同名实体类型作为公共实体类型的一类候选,把具有相同键的实体类型作为公共实体类型的另一类候选。
(2)局部E-R模式的合并
合并的原则是:
首先进行两两合并;先和合并那些现实世界中有联系的局部结构;合并从公共实体类型开始,最后再加入独立的局部结构。
(3)消除冲突
冲突分为三类:
属性冲突、结构冲突、命名冲突。
设计全局E-R模式的目的不在于把若干局部E-R模式形式上合并为一个E-R模式,而在于消除冲突,使之成为能够被所有用户共同理解和接受的同一的概念模型。
(4)全局E-R模式的优化
在得到全局E-R模式后,为了提高数据库系统的效率,还应进一步依据处理需求对E-R模式进行优化。
一个好的全局E-R模式,除能准确、全面地反映用户功能需求外,还应满足下列条件:
实体类型的个数要尽可能的少;实体类型所含属性个数尽可能少;实体类型间联系无冗余。
3.2数据库逻辑结构设计
1.数据库的逻辑结构的实现
管理员登陆表
账号
密码
vchar
vchar
用户登陆表
账号
密码
vchar
vchar
用户注册表
账号
密码
确认密码
邮箱
vchar
vchar
vchar
vchar
用户管理表
用户名
vchar
微博管理表
微博编号
用户
评论
评论用户
微博
Vchar
vchar
vchar
vchar
vchar
日志管理表
日志编号
日志
用户
评论
评论用户
vchar
vchar
vchar
vchar
vchar
相册管理表
相册编号
相册
用户
评论
评论用户
vchar
vchar
vchar
vchar
Vchar
第四部分系统约束
4.1界面
登陆界面:
包括“用户名”,“密码”两个输入框,一个登陆按钮,一个申请注册账号的链接。
普通用户个人主页:
包括一个浏览区,一个文本编辑器当做微博区,一个“个人资料”的链接。
个人资料页面包括用户名,密码,个人地址,邮箱四个文本框,一个提交按钮,一个重置按钮。
管理员用户主页:
包括一个查看区,一个管理页面的链接,一个认证区的链接。
4.2运行环境的要求
运行环境:
1)Windows2000/2003/xp及以上版本
2)SQLserver2003以上版本
3)完全支持TCP/IP协议的IE6以上浏览器,或其他满足条件的浏览器
4)实现IIS功能
4.3处理时间的要求
用户/事件响应时间应该在5秒以内。
屏幕刷新时间一分钟一次。
系统响应时间与实时的网速有一定联系。
4.4存储的要求
系统对存储空间的要求应该在满足系统正常运转的前提下尽量压缩存储空间。
但是要做好数据库的备份,这些维护数据库正常运行的数据冗余是很有必要的。
4.5健壮性要求
本系统是小组首次开发的软件系统,其健壮性不可能很高。
系统应该能满足5个用户同时使用。
系统在信息量过大时允许发生健壮性问题,并应该能够得到及时解决。
4.6安全性要求
由于本系统涉及用户个人资料,以及密码等对安全性要求高的数据。
因此网站代码应该对技术人员以外的使用者隐藏。
应该多使用组件等技术来减少代码错误和漏洞的可能性。
后期测试时应该对系统的安全性测试着重进行。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 微博实现及管理系统需求文档 实现 管理 系统 需求 文档