G003-182-08

目录

项目需求提案计划书... 1

一、前景概述... 1

二、市场分析... 1

三、项目分析... 1

项目需求萃取分析书... 3

一、问题域... 3

二、涉众分析... 3

三、系统特性... 4

项目需求分析规格书... 7

一、功能需求分析... 7

用户模块... 7

帖子模块... 9

论坛后台... 10

二、非功能性分析... 12

产品外观需求... 12

产品用户界面需求... 12

软硬件环境需求... 12

三、专项需求... 13

附录... 14

 

项目需求提案计划书

一、前景概述

对于学院内同学来说，一个较为实用的论坛他可以很方便的让同学之间的沟通更为方便，同时也给了同学们一个畅所欲言的地方。无论是在论坛讨论兴趣爱好或是相约组队参加活动都是一个非常不错的平台。

对于本项目来说，开发出来目的是经验累积以及小众使用，并不是为了盈利或是建成庞大的产业链，同时论坛开发拥有许多前人所积累经验可供参考，因此可以说项目前景十分良好。

二、市场分析

目前中国市场上的综合论坛主要以百度贴吧、NGA、天涯论坛等论坛为主，但其实用户市场基本属于百度贴吧一家独大。但是其他非综合性，小型的论坛还是很多，这些小型论坛多为针对某一特殊话题，例如某款游戏的论坛而且多由官方管理。综合性论坛虽然用户量巨大，但是很容易造成涉及面太广无法让每一个用户有明确的浏览意图，导致用户粘性并不足。而小型论坛用户有着明确的浏览目的，所以用户黏性很足，但是因为涉及面小，所以只要其他论坛涉及面不与其重复仍有吸引用户的功能。所以小型论坛系统的开发是可行的。

三、项目分析

    我们的论坛系统开发方向是作为一个供惠州学院师生交流学习、沟通畅聊的平台。而这样的小型论坛并没有其他的论坛功能重复。所以只要宣发到位，可以吸引到很大一部分用户入驻。而用户量则是一个论坛能否成功的关键，没有其他论坛竞争压力，所以我们的小型论坛的潜在用户量时十分可观的。

  

 

项目需求萃取分析书

一、问题域

1、用户可以进行注册登录，并且可以查看和修改自己的个人信息。

2、用户可以查看对应版块下的帖子，进行查看、回复、收藏、分享等互动操作。

3、用户可以在对应版块下发表帖子，随后可以进行编辑操作。

4、高级用户可以对帖子进行加精、置顶、删除、分类等操作。

5、管理员可以对所有版块、帖子、用户进行管理。

二、涉众分析

1. 开发者方面：

开发者对项目拥有完全的控制能力并对项目一切问题负责。因此论坛的开发首先服务对象是开发者，需要让论坛可以在开发者的完全控制下去服务用户。在后续更新维护中也应更轻松容易。

1. 用户方面：

1)   普通用户：可以浏览以及发表论坛内容，服从论坛管理条例。作为论坛最多使用用户，论坛主要使用体验为其服务。同时普通用户通过发表新的讨论话题以提升论坛知名度以及新鲜度。

2)   高级用户：由管理员或开发者从普通用户中升级而来，相对于普通用户权限更高，但同时也需对论坛内容建设以及论坛管理进行投入。需要对论坛运行以及论坛发展做出贡献。

3)   前台管理员：辅助开发者对论坛内所有成员进行管理以及论坛管理条例修改。对违规用户进行处罚对表现良好用户进行奖励，同后台管理员一致仅有开发者任命且仅可由开发者撤销。管理员需要对论坛正常运行负责，实时监控用户体验以及论坛运行情况。

4)   后台管理员：对后台数据库以及论坛BUG等问题进行初步维护以及监督。在无法解决问题时应尽量减少问题影响并及时通知开发者进行维护。保护好用户个人资料，拥有修改用户数据库内容权限但需填写修改日志并向开发者报备。同前台管理员一致仅有开发者任命且仅可由开发者撤销。

 

 

三、系统特性

FE-1:系统开放注册以及保存用户资料数据。

FE-2:系统开放发帖回复功能。

FE-3:系统分析帖子分类以及帖子热度。

FE-4:根据用户访问记录进行同类推荐以及热点推荐。

FE-5:系统设立用户组晋升以及权限管理。

FE-6:系统提供管理面板供所有用户使用自己权限内功能。

FE-7:系统可供用户修改个人资料以及个人主页

 

 

 

项目需求分析规格书

一、功能需求分析

    作为基础的论坛系统，我们需要为用户提供一个可以交流所思所想的平台，同时和可以展示基础自我的个人资料界面。通过帖子这一功能构建整体的交流环境，通过用户不断的互动来完善整个论坛系统。我们需要做到用户可以发帖、回帖和与他人私信的功能。同时为了维护社区稳定，需要设置管理员以及深度用户去管理社区发言以维持社区稳定。所以要基础实现以下三个模块。

用户模块

1.1 用户注册

新用户注册，填写用户信息，检验用户信息的有效性，并将用户信息持久化。

1.2 用户登录

提供用户凭证，验证用户信息是否合法，根据用户角色授权。

1.3 用户管理

管理员由系统初始化分配一个，管理员可以对用户信息进行部分更改，主要包括用户角色调整，删除用户等等。

 

 

 

帖子模块

2.1 帖子发表

注册用户可以在感兴趣的版块中发表新帖子。

 

 

2  

2.2 帖子回复

用户可以对自己感兴趣的版块发表回复。

3  

2.3 帖子浏览

用户可以浏览所有可见帖子。

4  

2.4  

2.4 帖子检索

用户可以提供标题关键字检索所以可见版块帖，注册用户可以查看自己发表或回复。

 

 

论坛后台

1  

2  

3  

3.1 论坛版块管理

管理员可以添加、删除、调整、置顶、隐藏论坛版块。

 

3.2 帖子管理

管理员可以对所有帖子进行转移、加精、置顶、删除等操作，版主可以转移本版块帖子，也可以对本版块帖子进行置顶、加精、删除等操作。

 

 

 

 

二、非功能性分析

    在满足用户使用条件前提下，致力要做到给予用户更好的使用体验以增强用户粘性，让用户可以在相同的论坛中能够选择我们的系统。所以除去功能性的需求同时也需要满足非功能性的需求。结合用户使用需要满足以下几种非功能性模块。

产品外观需求

产品外观需做到美观、新颖、简洁。因为受众用户多为在校大学生，所以产品审美应满足年轻人需求。

产品用户界面需求

产品用户界面应尽量简洁，是产品每一个功能展露无遗并且应做到一定的收纳，不使整个界面冗杂。

软硬件环境需求

论坛应做到PC端和手机安卓&IOS端完美同步。无论是在PC上还是在手机上浏览论坛应做到界面完整优雅。

三、专项需求

1、 易用性

作为一个交流平台应当做到用户之间交流没有不便，沟通方便，功能使用简易。

2、 可维护性

可以对系统进行修改操作以纠正错误，提高性能和其他属性，以适应更改后的环境。

3、 可拓展性

支持对系统进行数据字典以及功能的拓展。

4、 可靠性

在进行系统测试时，系统的可操作性和可访问性的程度达到正常使用的程度。

5、 性能效率 

可以支持用户高并发的情况，保证访问的同时不影响用户正常使用。

6、 可移植性

系统的功能性模块采用全后端分离模式，只要移植后的系统环境支持网络协议，就可以移植到不同的系统环境下。

7、 可拓展性

支持对系统进行数据字典以及功能的拓展。

8、 合规

保证系统版块内的帖子信息合法合规。

9、 安全

保护站点内容或系统免受意外或恶意访问、使用、修改、破坏或泄露的解决方案的各个方面。

 

附录

图例说明：

路线图

路线图是在体系结构的两种状态（通常是基准体系结构和目标体系结构或中间过渡体系结构）之间转换时必须发生的更改顺序的直观表示。如果企业架构师正在寻找一个能够激发高管层利益相关者和高级管理人员的关系图，那就是路线图，因为它是一个切实的交付物，描述了需要做什么以及何时完成。

每个体系结构领域通常都有一系列描述体系结构之间过渡的路线图，因此将有业务路线图，信息路线图，应用程序路线图和技术路线图。每个特定于领域的路线图都将包含与该领域相关的元素。因此，业务路线图可能会显示如何建立，更改或逐步淘汰功能。同样，应用程序路线图可能会显示何时将淘汰，替换或重构一个或多个应用程序，或者何时引入新的应用程序。可以创建一个路线图，其中包含来自某些或所有体系结构域的元素，以提供企业级别的变更序列视图。

 

组织结构图

组织结构图是战略模型组图的一部分，它显示了组织的结构，包括官员，角色，职责，业务部门或部门。可以使用树形布局或列表视图在图中显示角色或业务部门。可以将任意数量的标记值添加到元素或连接器，以根据需要添加其他信息。然后，可以在模型的其他部分中使用构成组织结构图的元素，例如将业务所有者分配给业务流程，业务规则，系统等。

 

组织视角图

组织观点描述了一个组织或实体，或一个组织的一部分，如一个部门或科室的作用和行为者。 这些要素以嵌套结构表示。

 

商业动机模型

商业动机模型(BMM)是OMG的一个建模符号，用于支持企业关于如何应对变化的世界的决策。企业使用它的方法是获取一个BMM建模工具，然后创建自己的BMM--用企业特有的业务信息填充模型。有两个广泛的目的。

捕捉对变化的反应的决策和做出决策的理由，目的是使决策可以共享，增加清晰度，并通过吸取经验改进决策。 将决策的结果与其对运营业务的影响（如对业务流程和组织职责的改变）进行参照，提供从影响者到运营变革的可追溯性。 本规范假设企业BMM将独立存在，通过 "占位符"--文本引用1与运营业务的相关部分相连，其中可能包括URI。

 

激励观点

激励观点涵盖了从特定利益相关者的角度出发的激励方面，定义了一个驱动因素、一个评估、若干目标和适用的原则，以及限定原则所需的要求和约束。

 

服务实现观点

服务实现观点对一个或多个业务服务如何由底层流程（有时也由应用组件）实现进行建模。因此，它构成了业务产品观点和业务流程观点之间的桥梁。它提供了一个或多个业务流程的 "外部视图"。

 

需求实现观点

需求实现观点允许设计者通过业务角色、业务服务、业务流程、应用服务、应用组件等核心要素对需求的实现进行建模。通常情况下，需求是由目标细化观点产生的。

此外，该观点还可以用来将需求细化为更详细的需求。聚合关系就是用来实现这一目的的。

 

原理观点模型

原则观点为目标和原则之间的关系建模。聚合关系为目标的分解建模，实现关系为原则如何与一个或多个目标相关联建模。

 

规范管理员

在开发模型时，你可以使用广泛的 Enterprise Architect 工具来创建模型规范。对于初步的规范，如定义需求，你可以采用两种通用方法之一。

基于图表的，在需求图中创建 UML 定义的元素图标，并以图形方式建立模型，或以文本为基础，将元素创建为简单的文本描述，在一个宽泛的定义中勾勒出元素、关系和属性，你--或具有更具体作用的团队成员--可以将其细化并发展为一个更完整的模型。

 

EA需求规范视图

需求规格视图模式创建了元素和规格视图，允许在文档或类似电子表格的视图中可视化需求，允许将复杂的需求分解成更细的需求，直至两个层次。该模式可以扩展到任何数量的层次。

 

复合需求层次结构

复合需求层次结构模式创建了元素和图表，允许需求层次结构被定义到任何级别，允许从一个级别的需求向下钻取（点击）到另一个图表，在层次结构的下一个级别显示其子需求。

需求跟踪图

需求跟踪模式创建了元素和跟踪图，显示需求和模型中其他元素之间的关系，包括拥有需求块、用例和测试用例的利益相关者。

 

非功能需求图

非功能需求分析模式创建了一系列包、元素和图，对非功能需求进行建模。根据需求的类型对需求进行分组，包括可用性、可比性、可扩展性等组别。

 

域模型图

领域模型模式在类图上创建类，描述所讨论领域中的重要概念或 "事物"。类可以被命名，也有详细的注释。连接器用来描述元素之间的关系，就像自然语言中使用动词来描述名词的交互方式一样。

 

用例模型

用例图主要用来描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示这些元素之间的各种关系，如泛化、关联和依赖。它展示了一个外部用户能够观察到的系统功能模型图。帮助开发团队以一种可视化的方式理解系统的功能需求。

 

序列图

顺序图是一种强调对象间消息传递次序的交互图，又称为时序图或序列图。描述了在一个用例或操作的执行过程中对象如何通过消息相互交互，说明了消息如何在对象之间被发送和接收以及发送的顺序。

 

活动图

活动图和交互图是UML中对系统动态方面建模的两种主要形式，交互图强调的是对象到对象的控制流，而活动图则强调的是从活动到活动的控制流。活动图是一种表述过程基理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模。活动图是UML用于对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。

 

部署关系图

在UML中，部署图用于对系统的物理结构建模。部署图将显示系统中的软件组件和硬件组件之间的关系以及处理工作的物理分布。部署图通常是在开发过程中的实现阶段准备的，它显示分布式系统中的节点的物理布局、存储在每个节点上的工件以及工件实现的组件和其他元素。节点表示一些硬件设备（例如，计算机、传感器和打印机）以及支持系统运行时环境的其他设备，通信路径和部署关系用于对系统中的连接建模。

 

数据流模型模式

数据流图是描述系统中数据流程的一种图形工具，它标志了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换逻辑输出所需的加工处理。值得注意的是，数据流图不是传统的流程图或框图，数据流也不是控制流。数据流图是从数据的角度来描述一个系统，而框图是从对数据进行加工的工作人员的角度来描述系统。

我们采用单层数据流模型模式创建了一些元素和一些图表，这些元素和图表显示了一个系统和数据，这些数据流向和来自一个外部实体，允许向下穿透到较低层的图表。