新闻网站应用系统需求分析.docx

新闻网站应用系统需求分析.docx

《新闻网站应用系统需求分析.docx》由会员分享，可在线阅读，更多相关《新闻网站应用系统需求分析.docx（28页珍藏版）》请在冰豆网上搜索。

新闻网站应用系统需求分析

新闻网站应用系统需求分析

密级：

内部资料

新闻网站应用系统

软件需求分析说明书

V1.0

文档编号：

XXXX_M01

项目名称：

新闻网站应用系统

编写：

编写日期：

审核：

审核日期：

批准：

批准日期：

XXXXX软件

XXXXXXXX数据平台项目组

修订状况

章节编号

章节名称

修订内容简述

修订日期

修订前

版本号

批准人

无

2

系统架构

1.0

3

需求概述

1.0

7

运行环境

1.0

4

功能需求

1.0

名目

第1章引言

1.1.编写目的

由于互联网的进展以及宽敞网友对新闻扫瞄要求的提高，以往的新闻网站都太传统不能与时俱进，因此我们需要建设一个新闻网站，及时的数据更新，满足更多的网民，业务流程设计多个用户，涉及面广，同于门户网站〔搜狐、新浪等〕。

因此要做到面面俱到，就要由一个详细的说明书，来指导该项目的顺利完成。

该网站建设说明书的标志是为了使客户和网站开发者对该醒目的初始规定有一个共同的明白得，使之成为整个开发工作的基础，供读者扫瞄活动新闻等。

1.1.1.作用

本文档是用户需求和系统设计之间的桥梁，以项目开发前期的系统收集和确认为依据，是系统设计和系统测试等工作的重要的输入要素。

为下一时期的系统设计工作提供依据。

当用户的需求发生变更时，应添写补充说明；如变动过大可形成新版本。

软件需求分析说明的要紧作用为：

✓为用户方与开发方建立共同协议奠定基础。

✓提高开发效率、强化进度操纵。

✓为项目的评测与验收提供依据。

✓便于移植。

✓作为系统不断提高的基础。

1.1.2.预期读者

本文档的阅读对象是系统设计人员、系统开发人员、软件测试人员及用户代表。

1.2.编写背景

1.2.1.系统名称及版本号

新闻网站应用系统V1.0

1.2.2.任务提出者

青岛滨海学院

1.2.3.任务承接者及实施者

09信管项目实训第2组

1.2.4.使用者

要紧指预期读者，也供有关领导批阅。

1.2.5.与其它系统的关系

1.3.文档结构

本文档对新闻公布治理系统的需求进行分析和描述，文档内容要紧分为以下几部分：

●第2章对新闻公布治理系统的系统架构进行说明。

其中包括系统的功能结构、治理系统与其它系统之间的关系，以及治理系统的行为架构。

●第3章对«用户需求说明书»中提供的需求进行了归纳，总结出了需求用例清单和需求用例图。

●第4章使用用例的方式对新闻公布治理系统各个业务功能进行详细的说明，其中包括用例的差不多事件流〔即主场景说明〕、前置条件、后置条件等。

●第5章从非系统功能方面对新闻公布治理系统提出要求，其中包括对新闻公布治理系统的性能要求、可靠性要求、可移植性和可爱护性要求、可用性要求、兼容性要求和分布性要求等等。

●第6章说明新闻公布治理系统设计和建设过程中应遵循的其它要求和约束说明，以及与治理系统相关的第三方产品和系统接口与协议的说明。

●第7章阐述新闻公布治理系统期望运行的环境，包括硬件环境、软件环境和网络环境三部分。

1.4.电子文档编写工具

本文档编写过程中使用了以下工具：

MicrosoftWord2003forWindows2000/XP

Power-Designer9.5forWindows2000/XP

MicrosoftVisio2003forWindows2000/XP

RationalRoseEnterpriseEdition2000forWindows2000/XP

1.5.定义说明与符号规定

包括对专用术语及缩略语的说明、所用到的图〔用例图〕：

图例

说明

用例

用户或系统边界

用户和用例的交互

继承关系

扩展用例

包含用例

1.6.术语定义

阐述文档所使用的术语、专用词汇、缩写等。

名词

说明

XXX

XXXXX，简称〝XXXXX〞或〝XXXXX〞

XXX

XXXXX

1.7.参考资料

1、«SQLServer2005数据库应用与开发教程»北京：

清华大学出版社

2、«数据库系统»概论北京：

高等教育出版社

3、«软件工程与UML»

4、相关网络资源

第2章系统架构

2.1.系统功能结构

新闻公布治理系统基于扫瞄器的B/S系统结构系统开发技术，系统的构成结构如以下图所示：

要紧用户

●系统治理员：

新闻公布治理系统的要紧使用者，负责数据平台的参数调整，权限操纵等治理功能，对数据平台宿主服务器进行治理、调整和升级等操作，并及时处理系统显现的问题。

同时，系统治理员还需要使用数据平台治理系统对其他子系统进行操纵和治理。

●用户及游客：

游客注册为用户，扫瞄各种信息，并能够对新闻进行留言等。

要紧功能

用户治理

生成稿件

审核稿件

美化文章

新闻线索治理

页面治理

基础框架

●权限：

负责用户对系统中每个功能访问的权限操纵，防治用户进行非法的操作。

●认证：

负责对用户的身份进行确认，在用户登录时调用。

治理系统提供本地认证方式和LDAP认证方式两种，能够使用XXXXX统一用户治理和认证平台作为认证来源方。

●日志：

记录用户使用系统的情形和系统的执行情形，便于日后的统计分析和系统改进。

●通讯：

为治理系统提供与外部系统交互的接口。

●数据库：

治理系统中对数据库操作的封装模块。

外部连接方式

●JMS服务器：

要紧用于分布式的消息传递和分布系统的日志收集。

●LDAP服务器：

即统一用户认证平台，LDAP服务器中存放XXXXX用户信息，用户对用户身份进行确认，该认证服务器有XXXXX提供和爱护。

不在数据平台的项目范畴之内。

●数据库服务器：

用于新闻公布治理系统中数据的储备。

2.2.系统的行为架构

本系统按照业务需求划分共包括六大类操作，它们是数据治理、运行调度、系统监控、操纵面板、系统治理和业务规那么定义。

Ø数据治理：

数据治理用于数据平台数据库的日常治理和爱护，其中包括数据迁移、数据卸载以及数据的备份和复原等等，不仅仅是数据库的日常爱护，还包括资料库和应用配置等。

Ø运行调度：

统一的任务运行调度平台，对各种作业类型进行各类参数设置、调度任务的安排，能够实现各类任务的并行处理、分布式处理；能够按调度的时刻要求进行实时、预订时刻等各种方式进行调度；系统具有良好的用户定义爱护作业与作业关系的界面。

Ø系统监控：

监控系统的日常运行状况和对系统的运行进行分析，并生成分析报告供相关人员对系统进行优化和调整。

Ø操纵面板：

提供对数据库、服务器和数据平台等参数和指标进行调整以及预警设置等功能。

Ø系统治理：

系统的用户和权限操纵，另外提供与系统设置相关的参数治理和日志治理等功能。

Ø业务规那么定义：

对业务代码表、归属表、维表、清洗表等代码提供爱护界面，由操作员对代码进行爱护，另外还应提供对业务参数表的爱护。

下面使用活动图的形式描述了上述各个部分之间的关联关系，如以下图所示：

第3章需求概述

电子信息时代的到来及进展，推动了新闻网站的进展与成熟。

利用网络技术将稿件及视频信息实时的传输至读者面前是可行也是必要的。

目前的信息传输技术的实时性、安全性和可靠性差不多进展的相对成熟，像光纤专门强大以至于你能够迅速地从全球猎取大量的信息。

随着网络技术的进展，网民越来越多，人们在连入Internet后有一半的时刻都在和Web打交道，扫瞄网页猎取信息等。

在现有技术的基础上实现稿件传输以及Web页面排版的自动化和规律化是可行的。

现在新闻行业大都实现了稿件以及排版的电子化，迅速的对读者行为作出反应也是能够实现的。

现有的技术差不多能专门便利的猎取读者的要求和评论信息，甚至读者的隐式信息如阅读爱好也能获得。

因此，为了适应时代的进展，为了让用户中意，本网站以让用户在网站上扫瞄到最及时、最真实、最完整的新闻为本网站的目的。

3.1.需求用例清单

本文档依据«XXXXX用户需求说明书»为基础，在要紧参与者的视角对系统的需求用例进行分析，用户的业务需要与系统的需求用例的对比关系如下表所示：

用例编号

用例名称

业务需求

优先级

001

用户治理

1-1用户治理

1-2用户审核

1-3用户新增

1-4用户修改

1-5用户爱护

中

002

生成稿件

2-1主动生成新闻线索列表

2-2反馈投稿人

2-3识别稿件属性

2-4传输至数据库

2-5处理紧急情形

高

003

审核稿件

3-1识别编辑人及分配任务

3-2排序新闻等级

3-3返回稿件

3-4连接数据库

高

004

美化文章

4-1修改、美化文章

高

005

栏目治理

5-1修改栏目

5-2添加栏目

5-3删除栏目

5-4反馈栏目信息

高

006

评论治理

6-1治理评论

6-2添加评论

6-3修改评论

6-4删除评论

高

007

新闻线索治理

7-1新闻线索电子化

7-2新闻线索追踪

7-3新闻线索舍弃

高

008

模板治理

8-1模块添加

8-2模块修改

8-3模块删除

高

009

页面治理

9-1治理页面布局

高

3.2.需求用例图

下面分别是在系统治理员和用户治理的视角的系统用例图：

系统治理员视角的用例图：

用户视图：

第4章功能需求

4.1.001用户治理

用例编号：

001

用例名称

用户治理

复杂度：

复杂

优先级

中

功能简述：

1、用户的权限明确

2、权限定义合理

3、治理员能对用户进行添加、删除、改变权限等

4、对新注册用户的及时审核

差不多事件流：

1、用户申请权限变更或系统中添加新的角色、菜单和功能；

2、系统治理员登录到数据平台治理系统中；

3、系统治理员使用权限治理爱护权限信息；

4、重复步骤3、4直到权限信息爱护终止；

5、通知相关人员权限变更。

扩展事件流：

权限信息包括用户权限和角色权限，参考用户授权和角色授权用例说明。

专门事件流：

1、该登录的用户是数据平台的合法用户。

2、系统中差不多存在用户信息

3、系统中差不多存在角色信息

4、系统中差不多存在菜单信息

5、系统中差不多存在功能信息

前置条件：

用户对本网站存有喜爱之心，对本网站的内容感爱好。

后置条件：

1、服务器运行参数改变；

2、监控功能中监控的参数发生变化

3、变更相关人员使用菜单和功能的权限。

专门需求：

无

扩展用例：

无

包含用例：

无

4.2.002生成稿件

用例编号：

002

用例名称

生成稿件

复杂度：

复杂

优先级

中

功能简述：

1、能识别投稿人员的身份、权限和所在地点

2、假设该投稿人有获得新闻线索的权限，那么能主动生成新闻线索列表等待阅读

3、主动将编辑对其文章的评判或新闻中心对其最新安排发送至投稿人阅读

4、稿件编写界面能识别稿件所属的大致栏目，包含时刻、地点、摘要等输入框

5、能将正文、图片及视频信息包含并传输至数据库

6、能选择新闻的重要程度

7、遇到紧急新闻时，有专门通道发送至总编处或直截了当待公布

8、可阅读新闻线索并反馈自己欲跟踪的线索给数据库

差不多事件流：

1、治理员登陆；

2、治理员对采访内容进行整合，编排，修改，书写；

3、反复核查内容，确定无差错；

4、生成稿件。

扩展事件流：

1、一份稿件可由多人负责完成；

2、能力强者可负责多篇稿件。

专门事件流：

1、稿件内容不符合实际；

2、稿件有错误。

前置条件：

1负责稿件的需要一定的相关能力；

2信任负责稿件需有资历深厚的人在旁监督。

后置条件：

1、服务器运行参数改变；

2、监控功能中监控的参数发生变化。

专门需求：

稿件内容需真实，符合实际，不得有虚假、极度夸张的成分。

扩展用例：

无

包含用例：

无

4.3.003审核稿件

用例编号：

003

用例名称

审核稿件

复杂度：

复杂

优先级

中

功能简述：

1、能识别编辑的身份和权限

2、依照编辑的身份主动生成他能审核的新闻列表

3、新闻列表能依照时刻或者重要程度排序显示

4、能够确定新闻的版面和举荐至首要新闻

5、审核不通过时能够将文章打入回收站或者返还给投稿者

6、审核通过的文章能发送至待发表数据库

7、可对文章做出评判，发送至投稿人

差不多事件流：

1、治理员登陆；

2、治理员对稿件进行审核；

3、关于审核通过的稿件基于发表的权力，不通过者，那么驳回。

扩展事件流：

1、治理员可对多篇稿件进行审核；

2、一篇稿件需交由多名人员进行审核。

专门事件流：

稿件审核不通过。

前置条件：

审核人员虚伪本网站治理人员。

后置条件：

1、服务器运行参数改变；

2、监控功能中监控的参数发生变化。

专门需求：

治理员审核稿件时必须秉持公平合理的态度，力求将最真实的内容出现给读者。

扩展用例：

无

包含用例：

无

4.4.004美化文章

用例编号：

004

用例名称

美化文章

复杂度：

复杂

优先级

中

功能简述：

在那个模块中，校对人员能够对稿件的文字进行校对和修改，美工人员能够对图片进行处理加工。

其他工作人员能够将文章进一步处理使其便于在网站上公布。

差不多事件流：

1、治理员登陆；

2、充分了解内容；

3、针对方案及时采取或调整美化方案；

4、最终样品的出现。

扩展事件流：

美化内容可采取不同方案。

专门事件流：

美化内容不完善，有些方面有待加强。

前置条件：

美化人员对美化工具的熟练运用。

后置条件：

1、服务器运行参数改变；

2、监控功能中监控的参数发生变化。

专门需求：

美化人员自身需具有一定的审美眼观，与针对特定用户需作出适时地调整。

扩展用例：

无

包含用例：

无

4.5.005栏目治理

用例编号：

005

用例名称

栏目治理

复杂度：

复杂

优先级

中

功能简述：

在那个模块中具有相关权限的人能添加、修改、删除栏目。

修改栏目后能反馈给投稿人和编辑，使其在选择栏目时能和现在网站上所有的栏目一致。

差不多事件流：

1．系统治理员登录到数据平台治理系统中；

2．使用功能治理功能爱护功能信息。

扩展事件流：

1、进入功能新增功能页面。

在页面上输入新增功能的差不多信息，如功能编号、功能名称、功能类型、数据访问级别等信息。

填写完毕后点击储存按钮后通过数据校验后存入系统数据库中；

2、用户进入功能修改功能页面。

输入差不多的查询条件之后，点击查询按钮能够得到符合查询条件的功能的列表。

选择某个查询出来的功能点击修改按钮那么进入该功能的信息修改页面。

对该记录进行相应的修改后点击提交按钮就把修改后的信息更新到数据库中；

3、用户进入功能删除功能页面。

输入差不多的查询条件之后，点击查询按钮能够得到符合查询条件的功能的列表；

4、选择某个查询出来的功能点击删除按钮，经删除确认后，就把删除操作结果更新到数据库中。

专门事件流：

1、输入信息不完整：

带’*’号的必选项要填写完整，否那么无法通过差不多数据校验，需要提示用户填写完整；

2、重复添加新功能：

假如通过页面差不多数据校验后，发觉重复的功能差不多在数据库中存在，那么一切储存操作回滚，不进行数据储存，并提示用户错误缘故；

3、储存处理失败：

在储存操作执行失败时返回到功能治理页面，并提示用户储存操作处理失败的缘故。

前置条件：

1、该登录的用户是数据平台的合法用户；

2、该用户拥有功能治理的权限；

3、该登录用户进入功能治理功能。

后置条件：

1、服务器运行参数改变；

2、监控功能中监控的参数发生变化。

专门需求：

无

扩展用例：

无

包含用例：

无

4.6.006评论治理

用例编号：

006

用例名称

评论治理

复杂度：

复杂

优先级

中

功能简述：

1、读者能扫瞄评论、修改自己的评论、公布评论；

2、治理员能对评论进行治理，确保评论合法等；

3、治理员能对一些评论做出反应，并反馈信息给读者。

差不多事件流：

1、用户登录；

2、用户在阅读完之后书写评论；

3、提交评论内容；

4、治理员对用户评论进行审核，如假设不符合要求，那么删除，符合要求，那么公布；

5、用户扫瞄、修改评论。

扩展事件流：

1、用户可对多条新闻发表评论；

2、用户可对同一条新闻发表多条评论。

专门事件流：

1、用户评论提交不上；

2、用户评论审核未通过，以至于没有公布。

前置条件：

发表评论用户必须为本网站注册用户。

后置条件：

1、服务器运行参数改变；

2、监控功能中监控的参数发生变化。

专门需求：

1、用户需差不多注册为本网站用户，否那么评论不予发表；

2、评论内容需积极向上，不得损害国家、人民及本网站的利益；

3、治理员需秉持着公平合理的态度审核用户评论；

4、最终说明权归本网站所有。

扩展用例：

无

包含用例：

无

4.7.007新闻线索治理

用例编号：

007

用例名称

新闻线索治理

复杂度：

复杂

优先级

中

功能简述：

有专门多人会提供新闻线索，并大多用或者E-mail的方式提供。

一部分新闻线索经证实后能够直截了当加工成新闻，另一部分那么需要记者进一步跟入。

因此那个模块要能实现新闻线索的电子化，以及对新闻线索的跟踪抑或舍弃处理。

差不多事件流：

1、治理员登陆；

2、治理员对新闻线索进行选择；

3、证实后的线索，加工成新闻；

4、有疑问的线索，需记者进一步跟进。

扩展事件流：

新闻线索选择时会发觉隐藏新闻

专门事件流：

1、有些新闻线索会做舍弃处理

2、由于选择者的疏忽新闻的不及时跟进与证实

前置条件：

提供新闻线索的用户需交代清晰事件的具体时刻、地点、任务、

后置条件：

1、服务器运行参数改变；

2、监控功能中监控的参数发生变化。

专门需求：

新闻线索选择者须有敏捷的洞悉力

扩展用例：

无

包含用例：

无

4.8.008模块治理

用例编号：

008

用例名称

模块治理

复杂度：

复杂

优先级

中

功能简述：

在那个模块中，能实现模块的添加、修改、删除等操作。

公布新闻时能便利的选取在网站中显示的模板。

差不多事件流：

1、系统治理员登录到数据平台治理系统中；

2、系统治理员进入系统信息爱护功能。

扩展事件流：

系统信息爱护包括以下内容：

1、系统治理员进入用户信息爱护子功能爱护用户信息；

2、系统治理员进入角色信息爱护子功能爱护角色信息；

3、系统治理员进入功能治理爱护子功能爱护功能信息；

4、系统治理员进入权限治理爱护子功能爱护权限信息；

5、系统治理员进入参数爱护子功能爱护参数消息；

6、系统治理员进入日志爱护子功能爱护日志信息。

专门事件流：

1、新增信息已存在：

当储存的信息如用户编号、角色编号等信息差不多存在时需要提示用户错误并回到爱护页面，同时需要回填所有提交的数据，并建议使用修改功能爱护该条记录或更换成一个新的编号；

2.储存信息失败：

在储存信息失败时应回到爱护页面，并提示用户处理失败的缘故，提交的所有数据应该在页面中回填。

前置条件：

1、该登录的用户是数据平台的合法用户；

2、该用户用于系统治理的权限。

后置条件：

用户、权限或者参数等信息被爱护和更新

专门需求：

1．系统治理员登录到数据平台治理系统中；

2．系统治理员进入系统信息爱护功能。

扩展用例：

无

包含用例：

无

4.9.009页面治理

用例编号：

009

用例名称

页面治理

复杂度：

复杂

优先级

中

功能简述：

那个地点的页面，要紧指首页。

要能调整和修改页面布局，使其更合理更符合人的适应。

差不多事件流：

1、治理员登陆；

2、治理员对网站首页进行全面的及整体的编排、修改并作出适时地调整。

扩展事件流：

治理员可对网站首页及其他进行多种方案的调整。

专门事件流：

页面不能满足用户需要。

前置条件：

全力人员须具有一定的全局性、审美性及敏捷的洞悉力，并针对大多数用户的适应作出适时地调整。

后置条件：

1、服务器运行参数改变；

2、监控功能中监控的参数发生变化。

专门需求：

治理员对多层次的用户须有多种不同方案。

扩展用例：

无

包含用例：

无

第5章非功能性需求

5.1.性能需求

系统监控数据查询时刻<=10秒；

多行数据列表查询时刻<=30秒；

50用户同时查询一条数据的时刻<15秒钟；

5.2.可靠性需求

在与新闻网站应用系统相关的应用系统通讯显现错误时，如网络问题、数据库访问失败、资料库访问失败等，应能够准确的提供错误的说明，并通知相关人员处理。

在专门问题得到解决之后，新闻网站应用系统应能够自动的检测的并对系统配置尽量在不需要重新启动治理平台的情形下进行复原。

5.3.可移植性需求

本系统只是针对XXXXX的数据平台项目，且本系统预期运行环境是：

Ø服务器系统平台：

SunMicroSystemCorp.Solaris9；

Ø数据库：

SQLServer2020；

Ø应用服务器：

WEB应用服务器；

在系统开发时能够考虑上述运行平台的特性，无移植性要求。

5.4.可爱护性需求

数据平台治理系统应该是可定义的和可配置的，系统中所有的处理应该是对外公布的，达到程序员的零干预，在系统显现专门时能够通过备份和配置进行重建。

数据平台治理系统的设计应该是模块化的、可插拔的，能够方便的完成系统的升级和爱护。

5.5.可用性需求

新闻网站应用系统中每个操作页面中需提供完整的操作和使用说明，方便指导用户的使用，尽量达到零文档和零培训的目的。

新闻网站应用系统应提供尽可能丰富的功能显示，充分为用户着想，提供人性化的服务。

5.6.兼容性需求

5.7.分布性需求

第6章其他要求

6.1.在线用户文档和关心系统需求

系统在设计过程中应该具有良好的在线文档和关心系统结构和丰富的操作关心文档，方便用户在系统操作