移动设备的景区导览系统需求分析.docx
《移动设备的景区导览系统需求分析.docx》由会员分享，可在线阅读，更多相关《移动设备的景区导览系统需求分析.docx（41页珍藏版）》请在冰豆网上搜索。
移动设备的景区导览系统需求分析
基于android手持设备的景区导览系统
需
求
说
明
书
变更历史
日期
版本
修改内容
修改人
备注
V1。
0
创建
审核历史
日期
版本
说明
审核人
备注
V1。
0
通过
1.引言
1.1编写目的
本说明书用于明确要开发的软件的具体需求,规范的描述出软件需要实现的各种功能和所要达到的性能，使用户和软件开发者双方对该软件的初始规定有一个共同的理解，并使之成为整个开发工作的基础。
1.2背景
1.2.1待开发系统名称
基于android手持设备的景区导览系统
1.2.2项目背景和内容概要
项目背景：
随着人民生活水平的提高，以及我国休假制度的完善，人们拥有了更长更多的假期，而假期外出旅游成为了越来越多的人们度过假期的第一选择.在这样的背景前提下，各大旅游景区更是成为了热门中的热门，这也造成了在旅游高峰期部分旅游景点人流过大导致拥堵，从而影响到游客旅游体验的问题。
不过从根本上来说,并不主要是因为游客数量的过大，往往是因为景区的服务不够全面细致，管理不够科学，效率不高所造成的，例如景区内部的地标不够详细或者是不够完整都可能会影响的游客游玩时的顺畅性。
另一方面来说，游客人数的急剧增长所带来的安全问题，如游客的人生安全,景区的设施安全等也日益明显突出起来，系统化、电子化、网络化、智能化的景区管理系统也成为了日益迫切的需求，本项目就是在这样的背景下提出的，旨在开发出一个能够方便游客、便于景区管理的景区导览系统。
任务提出者：
佘堃教授
任务开发者：
openlab实验室
用户：
景区游客，景区导览资源管理员
主要用途：
向用户传递景区信息，管理资源数据库
运行软件的设备：
android手持设备，通过设备的wifi功能加入到资源提供网络，windows操作系统的服务器.
1.3参考资料
软件需求说明书规范。
2.任务概述
2.1任务目标
该系统将要完成的是旅游景区的导览功能。
这里提到的导览，是指景区向游客提供的一种服务，这种服务的目的是让游客能够方便的获取景区的各种介绍信息以及景区的实时状态，例如景区内各个分景点的人流是否拥挤、分景点的游览车的数量等等，还要提供相应的查询功能,例如查询欲知景点的位置信息，当前位置到该景点的距离及绘制出最合适的路径轨迹信息等等.在游客拥有自己的PDA设备的前提下，利用手持设备的wifi功能，向游客的设备传输对应景区的导览文件（如视频介绍，文字介绍，以及查询服务）.并且完成提供导览文件资源的服务器资源数据的管理，例如日常维护，更新文件资源等，并且提供对客户终端请求的处理。
客户端的开发是基于谷歌android操作系统平台的，该操作系统是目前最火热的几大主流操作系统之一，具有巨大的市场和发展潜力，有望在未来几年成为移动电子设备上占有量最大的操作系统，因此本软件选择在之上进行开发，另外，编程语言选择Java，因此具有较好的可移植性。
服务端采用微软的MFC框架进行开发，MFC（MicrosoftFoundationClasses），是一个微软公司提供的类库（classlibraries），以C++类的形式封装了Windows的API，并且包含一个应用程序框架，使用MFC可以加快软件的开发流程.
2.2软件使用范围
所有中大型旅游景区都可以使用，只需要简单的对各旅游景区进行定制后即可投入使用.
2.3用户特点
对于客户端的使用会涉及到各种类型的游客人群，虽然android操作系统刚刚退出不久尚未在国内普及,对部分人群可能会比较生疏，但是凭借其简洁明了的UI和快捷的操作特性，并不要求用户对其特别的熟悉，因此可以做到让使用方法简单易懂，操作方法尽量浅显明了，使用户能够在短时间内借助简易的说明快速上手.为了提高系统的实用性，要求具有较强的可靠性和较大的吞吐量.
对于服务端的操作人员,由于软件设计的提供给操作人员的接口仅仅会涉及到简单的文件新建、修改、复制、删除等操作，因此仅仅需要操作人员熟悉简单的电脑操作即可,不需要专门进行培训。
用户需求框图如下图所示：
图2—1系统角色图
图2-1所示系统角色的创建方式和权限情况如下表所示:
表2-1系统角色说明
角色名
创建方式
权限
用户（游客）
客户端初始化时自动创建
访问服务器上的资源，向服务器发送请求
管理员（系统资源操作人员）
服务器登陆后,服务器的操作人员成为管理员
负责管理景区的导览相关资源
2.4假定条件和约束限制
2.4.1硬件约束
需求名称
详细要求
服务器硬件要求
支持Intel平台、AMD平台.双CPU2。
0G以上，内存2。
0G以上，100M网卡、硬盘250G以上，带液晶显示。
服务器系统平台
WindowsXP/Windows7及以后
客户端硬件要求
支持android操作系统的嵌入式平台，支持wifi功能，支持GPS定位，带触摸屏功能，具有音频输出
客户端系统平台
Android操作系统2。
1及以后
2.4.2用户约束
需求名称
详细要求
客户端用户（游客）
会简单的触摸屏操作
服务端用户（管理员）
会基本的计算机操作
2.4.3技术限制
服务器运行环境：
●SunJavaJDK6.0ForWindows（或更高版本）
●数据库MSSQLServer2005（或更高版本）
●Web应用服务器ApacheTomcat6。
0.29（或更高版本）
各种文档:
●符合标准文档编写规范
源代码：
●符合标准编程规范
3.功能需求
3.1功能用例图
图31功能用例顶层用例图
图22用户获取服务用例图
图23景区实时监控用例图
图24景区导览资源管理用例图
3.2用户获取服务
用例标识和历史
需求ID:
1001
用例名称：
用户获取服务
版本号：
V1.00
目的:
描述整个系统中，用户所能进行的相关操作,如用户的登入登出、查询景点、定位，用户获取景区导览信息等
上一次更新:
On（日期）:
批准人:
On（日期）：
用户/行为人：
用户（游客）
业务所有者姓名：
联系信息：
触发者:
用户（游客）
参考资料：
使用频度：
较高
前提条件：
见下级用例
结束条件:
见下级用例
非功能性需求：
假设，问题:
系统（客户端、服务器）正常运行
步骤:
该用例为组合用例，包含以下用例：
登陆服务器、缩放地图（放大/缩小）、定位、查询并定位景点、获取各景点多媒体信息（文字信息/音频信息/视频信息）、计算当前位置与指定景点的路程、获取当前各景点状况（人数、车辆数）
3.2.1用户登录服务器
用例标识和历史
需求ID:
1002
用例名称：
用户登录服务器
版本号：
V1。
00
目的：
为了防止导览资源服务器带宽被非游客所占用,故需要设定一级用于验证用户身份的密码，用于控制可以使用资源服务器的客户端,该密码可以简单的设定为门票上的唯一ID编码。
上一次更新：
On（日期）：
批准人:
On（日期）：
用户/行为人:
用户（游客）
业务所有者姓名:
联系信息:
触发者:
用户（游客）
参考资料:
使用频度：
较高
前提条件：
程序完成安装,网络连接无异常
结束条件：
服务器被关闭
非功能性需求:
提供有条件的强制登录（当密码意外无效时,需要向管理人员申请，获得批准）
假设，问题:
系统（客户端、服务器）正常运行;且门票ID清晰可见并唯一
步骤:
用户登录流程图：
3.2.2缩放地图
用例标识和历史
需求ID:
1003
用例名称：
缩放地图
版本号：
V1.00
目的:
为了能够使用户在客户端设备的屏幕上更合适的显示自己关心的一部分区域,设置了缩放地图功能。
上一次更新：
On（日期）:
批准人:
On（日期）:
用户/行为人：
用户（游客）
业务所有者姓名:
联系信息：
触发者:
用户（游客）
参考资料：
使用频度:
较高
前提条件：
程序正常运行
结束条件:
程序崩溃或设备故障
非功能性需求：
无
假设,问题:
客户端正常运行
步骤:
缩放地图流程图：
3.2.3定位
用例标识和历史
需求ID：
1004
用例名称：
定位
版本号：
V1.00
目的：
利用GPS或者依靠景区部署的阅读器返回用户当前的地理信息，可供实时定位和位置、路径跟踪使用。
上一次更新：
On（日期）：
批准人：
On（日期）:
用户/行为人：
用户（游客）
业务所有者姓名：
联系信息:
触发者：
用户（游客）
参考资料：
使用频度：
总是
前提条件:
GPS卫星信号正常,设备硬件正常
结束条件:
程序崩溃或设备故障
非功能性需求：
无
假设,问题：
客户设备功能正常
步骤：
定位流程图：
3.2.4查询并定位景点
用例标识和历史
需求ID：
1005
用例名称：
查询并定位景点
版本号：
V1.00
目的:
使游客能够根据景点的名称查询到景点的位置，方便游客顺利的到达自己希望参观的景点。
上一次更新:
On（日期）:
批准人：
On（日期）：
用户/行为人:
用户（游客）
业务所有者姓名：
联系信息：
触发者：
用户（游客）
参考资料：
使用频度：
一般
前提条件：
程序正常运行,供查询的服务器工作正常
结束条件:
查询超时或者查询成功
非功能性需求：
模糊查询
假设，问题：
客户端正常运行
步骤：
查询并定位景点流程图：
3.2.5获取各景点多媒体信息
用例标识和历史
需求ID:
1006
用例名称:
获取各景点多媒体信息
版本号:
V1。
00
目的:
为了能够使用户更加了解某个景点的一些详细资料例如景点的主要观赏点、景点的历史典故、景点的一些实景拍摄等来决定自己的游玩方案，用户可以通过客户端了解到相关景点丰富的多媒体介绍信息.
上一次更新：
On（日期）:
批准人：
On（日期）:
用户/行为人:
用户（游客）
业务所有者姓名:
联系信息：
触发者：
用户（游客）
参考资料:
使用频度：
较高
前提条件：
程序正常运行，网络连接正常，资源服务器工作正常
结束条件：
程序崩溃或关闭相关多媒体窗口
非功能性需求:
多媒体信息保持及时更新
假设,问题:
客户端正常运行
步骤：
获取各景点多媒体信息流程图：
3.2.6计算当前位置与指定景点的路程
用例标识和历史
需求ID：
1007
用例名称：
计算当前位置与指定景点的路程
版本号:
V1。
00
目的:
为了能够使用户能够直观的看出自己距离想去的一个景点的路程，该功能使得客户可以通过客户端得到当前位置到一个目的景点的距离并且绘制出最短的轨迹。
上一次更新:
On（日期）：
批准人:
On（日期）：
用户/行为人：
用户（游客）
业务所有者姓名:
联系信息：
触发者:
用户（游客）
参考资料：
使用频度:
一般
前提条件：
程序正常运行
结束条件：
程序崩溃或设备故障
非功能性需求：
绘制出的轨迹尽量合理
假设，问题:
客户端正常运行
步骤:
计算当前位置与指定景点的路程流程图：
3.2.7获取当前各景点状况
用例标识和历史
需求ID：
1008
用例名称：
获取当前各景点状况
版本号：
V1。
00
目的：
由于各分景点的人数容量有限，如果游客进入到了一个过度拥挤的景点，不仅游玩质量会受到影响，而且还可能耽误行程,本功能需求就是基于这样一个事实考虑得出的，为了游客能够时刻对各景点的状态有所掌握，从而做出最好的游玩选择。
上一次更新：
On（日期）：
批准人:
On（日期）：
用户/行为人：
用户（游客）
业务所有者姓名:
联系信息:
触发者:
用户（游客）
参考资料：
使用频度：
可设置刷新频率
前提条件：
程序正常运行,与服务器通讯正常
结束条件:
程序崩溃或设备故障
非功能性需求:
要求
假设,问题：
客户端正常运行
步骤:
获取当前各景点状况流程图：
3.3景区实时监控
用例标识和历史
需求ID:
2001
用例名称：
景区实时监控
版本号:
V1.00
目的：
为了能够使景区管理人员能够全面的、方便的掌控景区的实时状态，以便能够对景区的人流和车流进行适当的管理，另外还提供了景区的事故模拟疏散模型，增加景区事故发生后响应的处理到达的效率。
上一次更新：
On（日期）：
批准人：
On（日期）：
用户/行为人:
用户（景区管理员）
业务所有者姓名:
联系信息：
触发者：
用户（景区管理员）
参考资料:
使用频度：
始终运行
前提条件：
程序正常运行
结束条件：
程序崩溃或设备故障
非功能性需求：
无
假设,问题：
客户主机正常运行
步骤：
该用例为组合用例，包含以下用例:
景区实时状态、查询数据、分析数据、模拟疏散模型等。
3.3.1景区实时状态
用例标识和历史
需求ID:
2002
用例名称：
景区实时状态
版本号：
V1。
00
目的:
将当前的景区各景点、各地区的实时信息同意搜集并上传到用于显示和分析景区实时状态的主机上并进行显示。
上一次更新:
On（日期）:
批准人：
On（日期）:
用户/行为人:
用户（景区管理员）
业务所有者姓名:
联系信息:
触发者:
用户（景区管理员）
参考资料：
使用频度:
始终使用
前提条件：
程序正常运行
结束条件：
程序崩溃或设备故障
非功能性需求:
无
假设,问题：
客户主机正常运行
步骤:
景区实时状态流程图：
3.3.2查询数据
用例标识和历史
需求ID:
2003
用例名称：
查询数据
版本号：
V1。
00
目的:
通过编号2002的需求获得的实时状态数据将会被存档保存，用于此处的查询功能，可以方便的查询到各景点状态的历史信息，用于分析.
上一次更新：
On（日期）:
批准人：
On（日期）:
用户/行为人：
用户（景区管理员）
业务所有者姓名:
联系信息：
触发者：
用户（景区管理员）
参考资料:
使用频度：
一般
前提条件：
存储数据正常
结束条件：
完成一次查询
非功能性需求:
无
假设,问题:
客户主机正常运行
步骤：
查询数据流程图：
3.3.3分析数据
用例标识和历史
需求ID:
2004
用例名称：
分析数据
版本号：
V1。
00
目的:
通过编号2002的需求获得的实时状态数据将会被存档保存，用于此处的分析功能,通过用例2003可以方便的查询到各景点状态的历史信息，用于对景区日常运营状况的分析，帮助景区管理人员对景区进行管理。
上一次更新:
On（日期）:
批准人：
On（日期）：
用户/行为人:
用户（景区管理员）
业务所有者姓名：
联系信息:
触发者:
用户（景区管理员）
参考资料：
使用频度:
一般
前提条件:
存储数据正常
结束条件：
程序崩溃或设备故障
非功能性需求：
无
假设,问题:
客户主机正常运行
步骤:
分析数据流程图：
3.3.4模拟疏散模型
用例标识和历史
需求ID：
2005
用例名称:
模拟疏散模型
版本号：
V1。
00
目的：
为了在景区内发生一些意外事故的时候能够有效的疏散人流，构造了模拟疏散模型来模拟人流的疏散效果,生成一系列的疏散预案，以便当景区真正发生意外情况时，能够采取最有效的措施。
上一次更新：
On（日期）：
批准人：
On（日期）:
用户/行为人:
用户（景区管理员）
业务所有者姓名：
联系信息：
触发者:
用户（景区管理员）
参考资料：
使用频度：
一般
前提条件：
程序正常运行
结束条件:
程序崩溃或设备故障
非功能性需求：
无
假设,问题：
客户主机正常运行
步骤:
模拟疏散模型流程图：
3.4景区导览资源管理
用例标识和历史
需求ID:
3001
用例名称:
景区导览资源管理
版本号：
V1.00
目的：
本用例目的在于方便对各景点所关联的导览资源进行统一的、高效的管理。
考虑到各景点信息的更新，增加或删除等。
上一次更新:
On（日期）:
批准人:
On（日期）：
用户/行为人：
用户（导览资源管理员）
业务所有者姓名:
联系信息:
触发者：
用户（导览资源管理员）
参考资料:
使用频度：
一般
前提条件：
数据库服务器工作正常
结束条件:
程序崩溃或服务器故障
非功能性需求:
无
假设，问题：
服务端、客户端正常运行
步骤：
该用例为组合用例,包含以下用例：
新增导览信息、删除导览信息、更新导览信息、定期维护导览信息等.
3.4.1新增导览信息
用例标识和历史
需求ID：
3002
用例名称：
新增导览信息
版本号：
V1.00
目的:
在系统初始化设置的时候,需要录入各景点的导览信息供客户使用，同时，在新增景点时，也需要通过此用例录入新增景点的导览信息。
上一次更新:
On（日期）：
批准人:
On（日期）：
用户/行为人:
用户（导览资源管理员）
业务所有者姓名：
联系信息：
触发者：
用户（导览资源管理员）
参考资料:
使用频度:
较高
前提条件：
数据库服务器工作正常
结束条件：
程序崩溃或服务器故障
非功能性需求:
无
假设，问题：
服务端、客户端正常运行
步骤：
新增导览信息流程图：
3.4.2删除导览信息
用例标识和历史
需求ID：
3003
用例名称:
删除导览信息
版本号：
V1.00
目的:
在需要删除景点的导览信息供客户使用.
上一次更新:
On（日期）：
批准人：
On（日期）：
用户/行为人:
用户（导览资源管理员）
业务所有者姓名：
联系信息:
触发者：
用户（导览资源管理员）
参考资料：
使用频度：
较高
前提条件:
数据库服务器工作正常
结束条件：
程序崩溃或服务器故障
非功能性需求:
无
假设,问题：
服务端、客户端正常运行
步骤：
删除导览信息流程图:
3.4.3更新导览信息
用例标识和历史
需求ID：
3004
用例名称:
更新导览信息
版本号：
V1。
00
目的：
为了给游客更好的服务,需要及时的更新导览信息，以便让游客能够掌握最新的、有效的导览资料，避免导览资料的过期所带来的一系列问题例如给误导、引发混乱、纠纷等情况.
上一次更新:
On（日期）：
批准人：
On（日期）:
用户/行为人:
用户（导览资源管理员）
业务所有者姓名:
联系信息:
触发者:
用户（导览资源管理员）
参考资料:
使用频度:
较高
前提条件:
数据库服务器工作正常
结束条件：
程序崩溃或服务器故障
非功能性需求：
无
假设,问题：
服务端、客户端正常运行
步骤:
更新导览信息流程图:
3.4.4定期维护导览信息
用例标识和历史
需求ID:
3005
用例名称：
定期维护导览信息
版本号：
V1。
00
目的：
为了保证导览服务的可靠性,需要定期对导览信息进行维护,避免导览资源的失效而引发导览系统的缺陷。
上一次更新：
On（日期）：
批准人:
On（日期）:
用户/行为人：
用户（导览资源管理员）
业务所有者姓名:
联系信息:
触发者:
用户（导览资源管理员）
参考资料：
使用频度：
较高
前提条件：
数据库服务器工作正常
结束条件：
程序崩溃或服务器故障
非功能性需求：
无
假设，问题:
服务端、客户端正常运行
步骤：
定期维护导览信息流程图：
4.界面需求
本章主要对本导览系统的界面做一个简单的需求概括，以下截图均来自初步设计，具体实现中可能会有所变更。
4.1客户端界面
4。
1。
1启动客户端应用程序
在客户端上点击应用程序的图标（如图4-1）即可启动客户端应用程序。
图4—1客户端程序启动图标
点击图标后应用程序将切换到如下界面（如图4-2）,点击导览一项即可进入导览界面.
图4—2应用程序菜单
图4—3运行后的界面
4.1.2导览界面
导览界面如图4—3所示。
从图中可以看到最上方有用于查询景点的搜索框，下方有一些播放按钮，以及用于缩放地图的按钮。
中央区域是地图，上面有游客标记和景点标记.景点标记下方的两行数据是模拟的景点人数/最大容纳人数和当前该景点的公交车数目。
4.1.3地图模式设置
图4-4所示的地图设置选项对话框,可以方便的对地图模式进行选择和切换.这些地图模式都是由Googlemap所提供的。
常用的包括四种视图：
地图视图、卫星视图、交通线路视图和街景视图。
目前在中国大陆地区暂时还没有开放街景视图的相关功能，因此常用的是前三种模式。
图4-4地图设置
例如，当在地图设置中选中了“卫星视图”选项,将会看到如图4—5所示的卫星地图.
4.1。
4查询功能
系统需要方便的使用查询功能，考虑到此功能的使用频度较高，因此将其设计于主界面的正上方，首先在查询的文本框中输入需要查询的景点名称,然后点击右边的查询按钮即可搜索出对应的景点并在地图上绘制一个标记而且定位到该景点.例如,如图4—6，在查询文本框中输入“天安门广场”，点击查询即在地图上标记并显示出了天安门广场。
图4-5卫星视图
4。
1。
5查看导览资源
要查看某景点的导览资源,首先在地图上点击地图标记,将弹出一个用于显示导览资源的气泡，如图
升级会员 