软件工程需求规格说明书文章管理系统.docx

软件工程需求规格说明书文章管理系统.docx

《软件工程需求规格说明书文章管理系统.docx》由会员分享，可在线阅读，更多相关《软件工程需求规格说明书文章管理系统.docx（16页珍藏版）》请在冰豆网上搜索。

软件工程需求规格说明书文章管理系统

文章管理系统

需求规格说明书

编写人：

郝耀峰

学号：

1250312025

湖北第二师范学院

2015年5月

目录

1引言-2-

1.1背景-2-

1.2专业名词解释-2-

1.3参考资料-2-

1.4编写目的-2-

2系统概述-3-

2.1现状分析-3-

2.2系统简述-3-

2.3系统范围定义-3-

2.4条件与限制-4-

3功能需求-4-

3.1系统流程图-4-

3.2用例模型-5-

3.3利益相关方及其视点-5-

3.4整体功能描述-6-

3.4.1文章分类管理-6-

3.4.2文章发布管理-6-

3.4.3文章信息管理-6-

3.4.4文章查询管理-7-

3.4.5文章信息浏览-7-

3.5管理员功能用例-7-

3.6普通用户功能用例-8-

4非功能性需求-8-

4.1维护性-8-

4.2移植性-8-

4.3可靠性-9-

4.4易用性-9-

4.5效率-10-

4.6用户界面需求-10-

5外部接口-10-

5.1硬件接口-10-

5.2软件接口-11-

5.3通信接口-11-

6运行需求-11-

6.1运行环境-11-

6.2支撑软件-11-

6.3故障处理-11-

7项目安排以及项目UML图-12-

7.1项目安排-12-

7.2顺序图-12-

7.3状态图-13-

7.4活动图-13-

7.5类图-14-

7.6序列图-14-

8项目总结-14-

引言

背景

随着企事业单位的信息化普及，越来越多的文章管理系统应用在了知识管理中。

如果采用传统的静态页面进行保存文章内容，那么，管理员每天不得不花费很大的精力来制作网页。

但是如果利用数据库和动态网页技术来保存文章信息，就可以很大程度上减少信息管理人员的工作量，提高了工作效率。

专业名词解释

词汇名称

词汇含义

备注

UML

统一建模语言，是一种面向对象的建模语言，它是运用统一的、标准化的标记和定义实现对软件系统进行面向对象的描述和建模。

UnifiedModelingLanguage

Rose

是RationalRose的工具软件简称，用来描绘建模图形。

US

参考资料

《软件工程方法与实践》窦万峰著机械工业出版社出版。

软件需求说明书模板（GB856T——88）。

编写目的

文档定位是软件工程课的结课期末作业，适用性不强，但是通过对软件工程及UML的学习使我们能够掌握部分的软件工程知识。

虽然现阶段几乎没有项目经验，但是对软件工程的学习以及系统分析设计的学习，我们能够掌握部分项目管理的知识。

系统概述

现状分析

人的一生会涉及到很多领域，学到很多知识和技能，学则思，思而理。

学习要懂得思考，思考后要懂得整理、消化所学知识，达到触类旁通的效果。

21世纪互联网的兴起，可以让我们很容易的获取各类资料，不同的领域会参考不同的网站、不同的文章，学得越多，资料越多，所以有必要分门别类加以管理。

系统简述

系统需要有以下功能与参与者：

系统用例

解释

备注

用例名称

文章管理系统

范围

对文章的管理

功能

实现对文章的管理与操作

主要参与者

管理员、浏览文章的人员

前置条件

管理员经过登录

多分类、多子类的帮助您来管理不同领域的文章、学习笔记；每个分类以及子类对应各自不同的网站链接，方便查阅资料或发表相关文章。

全文检索功能可以快速的查询到您之前录入过的数据，免去一个个文件打开然后查找数据的麻烦，如果录入的资料未找到信息也可以让其搜寻网络。

系统范围定义

在各个行业中，当我们接受到用户的商业项目后，在项目运行的全过程中充满了不确定因素，只有有效的运用项目管理的科学和艺术，才有可能使项目取得成功。

对以上方面要想达到有效的管理水平，必须有一套科学的管理方法，但是即使有了科学的管理方法，由于项目干系人之间的沟通、协作不到位，往往达不到预期的结果。

鉴于这种情况我们开发一套项目管理协作支撑系统，旨在为项目干系人提供一个交流、协作以及项目的进度跟踪监控、项目的质量控制、项目相关资源的管理的软件平台，从而提高项目管理水平，实现了工作的协同化、提高了工作效率。

本系统适用于普通的文档文章管理以及交流学习。

能够对文章进行基本的发布，查询，浏览，删除等管理。

条件与限制

经过分析，系统的参与人员有两种：

任意匿名用户和管理员。

任意匿名用户为系统的普通用户，这里我们不需要特定的用户名，所以不需要进行系统的身份验证。

普通用户通过页面查询出所需要的文章，进行文章详细信息的浏览和发表自己对文章的评论。

管理员具有管理该系统的权限，进入如果是合法的管理员，就可以进入后台管理系统进行文章信息的管理。

功能需求

系统流程图

文件结构和系统流程图

用例模型

利益相关方及其视点

任意匿名用户:

任意匿名用户为系统的普通用户，不需要特定的用户名，所以不需要进行系统的身份验证。

普通用户通过页面查询出所需要的文章，进行文章详细信息的浏览和发表自己对文章的评论。

管理员：

管理员具有管理该系统的权限，进入如果是合法的管理员，就可以进入后台管理系统进行文章信息的管理。

整体功能描述

文章管理系统的主要功能包括文章分类管理，文章发布管理，文章信息管理，文章查询管理，文章信息浏览等五大模块，具体描述如下。

系统功能模块1

文章分类管理

A.文章类别的增加，包括类别的名称和类别编号

B.文章类别信息的修改

C.文章类别的删除

文章发布管理

A.文章基本信息的发布

B.图片上传功能

文章信息管理

A.文章基本信息更改

B.文章的删除

文章查询管理

A.文章分类信息列表

B.文章检索。

包括基于模糊检索和精确检索的全文、标题、作者的文章检索。

文章信息浏览

A.文章详细信息浏览和文章评论浏览

B.发表文章评论

C.分类文章列表

管理员功能用例

A.通过验证登录到系统管理界面。

A1：

管理员用户名输入错误，登录失败，返回登录界面。

A2：

管理员密码输入错误，登录失败，返回登录界面。

B.在界面找到各个管理功能。

C.进行对文章分类的管理与操作。

C1：

进行对文章类别的增加，包括类别的名称和类别编号。

C2：

进行文章类别信息的修改操作。

C3：

进行对文章类别的删除操作。

D.进行对文章信息的管理与操作。

D1：

对文章基本信息更改。

D2：

对文章信息的删除。

E.进行对新文章的发布操作。

E1：

对文章基本信息的发布。

E2：

文章封面及内容图片的上传操作。

F.文章信息浏览管理

F1：

对文章详细信息浏览和文章评论浏览进行修改与删除操作。

F2：

管理文章的评论。

G.点击退出进而退出系统。

普通用户功能用例

A.用户登录或者直接访问本系统。

B.通过系统提供的查找功能提交查找信息。

B1：

通过系统提供的分类列表对文章进行查询。

B2：

通过系统提供的条件检索功能进行对文章的查询。

C.系统接收到用户请求进行文章的检索。

D.系统找到文章并反馈给用户。

D1：

系统检索数据库之后没有找到用户提交的信息，跳转到提示页面，用户返回并且重新提交内容。

E.用户浏览文章。

F.用户对找到的信息作评论。

非功能性需求

维护性

所谓软件的可维护性其实说简单了就是软件代码的可被修改的容易程度。

如前言所说，代码反复修改的情况不可避免，这种软件的不断演化过程——具体就是修正错误；适应新环境；满足新需求——虽然貌似将软件的功能变的越发强大，但是事实上这些改变总是或多或少的有悖于当初的设计初衷，因此势必慢慢的蚕食软件的基础架构和代码质量——造成的结果是让代码越来越难看懂，健壮性越来越脆弱，修改一个bug的代价越来越大。

移植性

可移植性指的是未经修改或修改部分源代码后，软部件从一种环境移植到另一种环境中还能正常工作的难易程度。

系统的可移植性并不是在系统开发的后期才开始考虑的，在整个软件开发生命周期都必须要考虑系统的可移植性，尤其是在早期的需求分析和设计阶段。

在需求分析阶段，最好能够明确的定义可移植性需求。

例如：

虽然当前软件版本仅仅支持运行在Windows平台上，但是需要考虑将来移植到Linux上的需求。

　　一个大型的软件可能包括多个不同级别的设计。

设计阶段要重点关注外部接口，例如：

文件访问接口、内存管理和用户界面等。

这些接口是最容易发生可移植性问题的地方。

业界有很多针对这些接口的标准，软件产品如果能够符合这些标准，将会大大的提高软件自身的可移植性。

例如：

针对字符集的ASCII，针对操作系统接口的POSIX等。

　　从测试层面而言，可移植性测试应该重点关注在测试对象的不同接口上面。

具体而言，可移植性测试至少需要考虑可安装性测试、共存性/兼容性测试、适应性测试和可替换性测试。

可靠性

对产品而言，可靠性越高就越好。

可靠性高的产品，可以长时间正常工作这正是所有用户想要得到的。

从专业术语上来说，就是产品的可靠性越高，产品可以无故障工作的时间就越长。

那么在设计系统的时候就会考虑到系统的健壮性，舍弃无用的功能与完善代码能够很好的使系统更加可靠。

易用性

企业管理者希望有一套产品能够帮助他们提高工作效率，而不是增加他们的负担。

没有复杂的流程设计，没有复杂的表单设计等等。

作为软件供应商往往重视系统功能的全面性，流程的可控性，技术的先进性，却忽略了系统的易用性。

尽可能地符合现行的标准和规范，这是最好的选择。

或者制定自己的标准和规范，并严格执行，保持页面的风格是一致的。

包括快捷键、菜单选项、术语和命名，诸如OK和Cancel按钮的位置、色彩等等。

效率

效率关注的不是软件是否能够完成系统的特定功能，而是在完成该功能时展现出来的及时性、处理能力和使用资源的合理性。

效率体现在占有时间和空间的资源的情况，它与当前系统用户并发数和空间资源占有率有着很大的联系。

所以要从时间减少和空间占用更少的方面来提高系统的效率。

用户界面需求

界面尽可能的做的简捷，方便。

用户界面的质量，直接关系到应用系统的性能能否充分发挥，能否使用户准确、高效、轻松、愉快地工作。

所以软件的友好性、易用性对于软件系统至关重要。

目前国内软件开发者在设计过程中很注重软件的开发技术及其具有的业务功能，而忽略了用户对用户界面的需求，影响软件的易用性、友好性。

对于大多数用户来说，用户界面就是他们对一个产品的全部了解。

所以对他们来说，一个内部设计良好但用户界面不好的应用程序就是一个不好的程序。

一个应用程序的用户界面框架是决定它的商业价值的重要因素。

说到底一句话：

一个优秀的用户界面即是一个直观的、为用户熟悉的界面。

界面元素符合大多数界面设计方案。

用户在首次接触了这个软件后就觉得一目了然，不需要多少培训就可以方便地上手使用，而且用户在使用过程中甚至会获得愉悦快乐的心情。

所以界面的设计需要按照这样的思维来完成。

外部接口

硬件接口

因为用户查找到文章需要下载，管理员需要上传图片等，硬件需求则主要体现在电脑的USB端口。

能实现将外部的文章以及图片内容拷贝到电脑，然后上传到系统资源里面。

软件接口

接口的设计需要考虑用户的使用习惯、使用的方便程度、使用的安全程度，系统本身不是太多，那么需要的即是普通网站系统采用的界面布局即可。

同时要注意系统的简捷以及系统的安全。

在设计时需要考虑到这些方面。

通信接口

系统需要能够连接互联网，能够实现用户在互联网上查找浏览系统里面保存的文章信息。

运行需求

运行环境

1.需要有系统的主机。

2.网络浏览器，如IE，谷歌浏览器等。

3.需要有自己的电脑客户端。

支撑软件

1.网络服务器，如IIS，Tomcat等。

2.某些文章需要安装MicrosoftOffice2003及其以前的版本。

故障处理

如遇到未检索到用户提交信息等故障，将提示信息返回到新的页面。

然后请用户提交新的需求信息再次进行检索。

其他的故障错误同样可以这样处理，先跳转到出错的提示页面，然后可以重新进行功能的的选择。

其他故障处理这里暂不做详细阐述。

项目安排以及项目UML图

项目安排

备注：

此项目任务分配是小组成员之间的项目任务分解，由于时间紧促并没有将任务分解很细，只是有大致的步骤。

顺序图

状态图

活动图

类图

序列图

项目总结

整个项目需要明确的分工合作，因为项目本身没有参与开发，而只是做需求分析与UML建模实现。

这个项目因为是学习，本身不能做得太好，也请老师原谅。

小组首先从项目的分工安排开始，大家一起整理出来做UML需要的知识点和步骤，落实到每一个责任人。

然后大家各自做自己的内容，最后集中整理。