软件需求论文.docx
- 文档编号:9466134
- 上传时间:2023-02-04
- 格式:DOCX
- 页数:13
- 大小:132.94KB
软件需求论文.docx
《软件需求论文.docx》由会员分享,可在线阅读,更多相关《软件需求论文.docx(13页珍藏版)》请在冰豆网上搜索。
软件需求论文
1论文要求
1)对所选系统进行严密的需求获取以及需求分析。
2)给出所选系统的各层次需求,包括业务需求,用户需求,功能需求以及非功能需求。
3)论文中给出所要实现系统的需求规格说明书。
4)需求规格说明书要详尽,必须包括以下内容:
引言,总体描述,功能需求,接口需求以及其它非功能性需求等,符合需求规格说明书各项细则。
5)附录中给出所选系统需求规格说明书中各图表,或者图表的获取过程.例如数据字典的具体描述或者是UML建模中图的获取过程.
2需求分析规格说明书
2.1引言
2.1.1编写目的
所谓“需求分析”,是指对要解决的问题进行详细的分析,弄清楚问题的要求,包括需要输入什么数据,需要得到什么结果,最后应输出什么。
需求分析阶段是一个非常重要的阶段,良好的需求分析文档,将为整个软件开发项目的成功打下良好的基础。
2.1.2项目信息
本项目的名称:
出租车呼叫服务系统
本项目的应用范围:
实时的方便市民出行的服务
开发者:
武汉理工大学计算机学院徐晓龙
用户:
市民、出租车司机
2.1.3术语说明
TCSS:
TaxiCallingServiceSystem,出租车呼叫服务系统
信息源:
人们在科研活动、生产经营活动和其他一切活动中的成果及各种原始记录
C/S模式:
Client/Server模式,即客户端/服务器模式
2.1.4参考资料
[1]钟络,袁景凌主编,软件工程.北京:
科学出版社,2012.1
[2]李勇华,袁梦霆等主编,软件需求工程.北京机械工业出版社,2008.8
[3]周晓红,赵红玉,俞建新,基于GPS的出租车呼叫与调度系统.2009
2.2总体描述
2.2.1组织结构与职责
本系统用户的组织结构如图1-1所示。
管理组
管理员
出租车司机
用户组
乘客
图1-1组织结构与角色
2.2.2角色定义
用户在系统中扮演的角色,以及可以执行的职责,如表1-1
表1-1角色定义
编号
角色
职责
1
管理员
拥有所有用户的职责,享有系统最高权限及对整个系统管理的权限
2
乘客
乘客具有发送乘车请求、获得接受请求的司机的位置、对服务进行评价、反馈问题等权限。
3
出租车司机
出租车司机接收或拒绝乘车请求、切换载客状态、反馈问题等权限
2.2.3系统概述
出租车呼叫服务系统(TCSS)主要解决市民在日常生活中,打车难的问题,提供给乘客一个快捷、方便的打车系统,并节约出租车司机无目的行驶所浪费的时间和能源,在乘客与出租车司机之间搭建了一个服务完善、实时互动的应用平台,该平台的开发理念是远程、实时、互动、低碳、快捷。
随着非智能手机的GPS应用难题被克服,GPS手机逐步得到普及,手机的位置服务功能成为无线通信应用的一个总要方面。
与此同时,越来越多的城市在出租车上安装了车载GPS系统。
在此背景下,我们可以构建一个基于GPS手机和安装了车载GPS系统的出租车的系统平台,通过该平台乘客呼叫出租车服务具有目的性,与此同时,出租车公司能够根据用户的当前位置利用最短路径搜索算法搜索出租车前往服务。
该系统的结构图如图1-2所示
图1-2系统结构图
2.2.4信息源
本系统的主要信息源说明,如表1-2~1-7所示。
表1-2管理员信息表
单据名称
Admin
用途
存储管理员的相关信息
使用者
系统管理员
表1-3乘客信息表
单据名称
Passengers
用途
存储乘客的相关信息
使用者
乘客
表1-4司机信息表
单据名称
Taximans
用途
存储司机的相关信息
使用者
出租车司机
表1-5问题信息表
单据名称
Questions
用途
存储反馈的问题的相关信息
使用者
管理员、乘客、出租车司机
表1-6乘客_司机信息表
单据名称
Pas_Tax
用途
存储乘客_司机的相关信息
使用者
系统管理员
表1-7打车记录信息表
单据名称
TakingTaxi
用途
存储乘客打车的相关信息
使用者
系统管理员
2.2.5用户类及其特征
本系统适用于拥有并能熟练使用手机的用户,以及培训过的出租车司机。
要求用户界面良好,提供帮助。
2.2.6系统运行环境
本系统采用C/S体系结构,易于把握,成本低廉。
它可以实现不同的人员,从不同的地点,以不同的接入方式(如WLAN,CMNET等)访问和操作共同的数据库。
它能有效地保护数据平台和管理访问权限,服务器数据库也很安全。
具体所需配置如下:
服务器端
硬件环境:
80x86系列微机
CPU:
2.0GHz以上
内存:
2GB以上
硬盘空间:
80GB以上
输入输出设备:
键盘、显示器等
网络设备:
Hub、网卡、网线等
软件环境:
操作系统:
WindowsServer
数据库系统:
MySQL5.5
其他软件支持:
JDK1.6+MyEclipse+Tomcat6.0
客户端
硬件环境:
CPU:
1.0GHz以上
内存:
128MB以上
外存空间:
2GB以上
输入输出设备:
键盘、触屏显示器等
软件环境:
操作系统:
Symbian,Android,WindowsPhone,IOS
数据库系统:
MySQL5.5
2.3功能需求
本系统通过面向对象的分析方法作为主要的建模方法,使用UML(UnifiedModelingLanguage)作为建模语言,UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。
在UML中,从任何一个角度对系统所作的抽象都可能需求几种模型来描述,而这些来自不同的角度的模型图最终能够成为系统的映像。
2.3.1系统用例
根据以上分析,主要介绍乘客、管理员和司机的用例所具有的的主要功能权限。
系统用例图如图1-3所示。
a
图1-3系统用例图
以下对几个主要的用例进行用例描述:
登录
用户登录系统
执行者
司机、管理员、乘客
前置条件
无
后置条件
用户登录系统成功
交互
1)用户进入系统登录界面
2)系统提示用户输入用户名和密码
3)用户输入信息
4)系统对用户输入的信息进行认证
5)认证失败,系统提示用户输入了错误的信息;
认证成功,用户进入系统
发送乘车请求
乘客向服务器发送乘车请求
执行者
乘客
前置条件
乘客成功登陆
后置条件
服务器收到乘客的请求
交互
1)乘客进去发送请求界面
2)系统提示用户是否发送乘车请求
3)乘客选择发送请求
4)服务器接收请求
5)系统提示乘客成功发送请求
处理乘车请求
司机对服务器发送的乘车请求进行处理
参与者
司机
前置条件
司机收到服务器发送的乘车请求
后置条件
服务器收到司机的反馈
交互
1)服务器将乘客发送的乘车请求传递给最近的司机
2)系统提示司机处理请求
3)司机拒绝请求,反馈给服务器拒绝请求;司机接受请求,服务器把乘客的信息发送给司机
4)服务器把信息传送给乘客
2.3.2系统后台管理需求
根据出租车呼叫服务系统提供的服务及实现的功能,经分析与设计,提出以下相应的需求。
Ø乘客管理,主要实现查看乘客、修改乘客、删除乘客、添加乘客、冻结乘客、激活乘客等功能。
Ø司机管理,主要实现查看司机、修改司机、删除司机、添加司机、冻结司机、激活司机等功能。
Ø问题管理,主要实现查看问题、提交问题、修改问题、删除问题等功能。
2.4接口需求
2.4.1外部接口
用户界面:
客户端提供帮助连接,解释使用方法;乘客客户端可支持触屏或键盘操作,司机的由所在公司统一配发,触屏操作。
软件接口:
本系统运行在Symbian,Android,WindowsPhone,IOS主流手机平台上,不同的系统连接MySQL数据库的方法有所不同。
硬件接口:
键盘、触屏显示器与内部主机连接。
通信接口:
TCP/IP协议
2.4.2故障处理
出错输出信息:
根据不同的错误提供不同的错误提示信息
出错处理对策:
1)一般错误:
显示错误信息,提示用户重新操作
2)严重错误:
重新启动,必要时启用备份恢复数据
2.5其他非功能需求
2.5.1性能需求
1)时间特性:
实时刷新界面时间≤2s
信息的上传下载时间≤5s
2)空间特性:
支持的终端数≤5000
支持的并行操作使用者人数≤500
处理的记录数≤5000
3)界面需求:
乘客登录窗口和进入系统的窗口必须简介清晰,而且美观。
4)精度需求:
系统在地图上显示的用户和出租车的地点必须精确,要控制住误差。
当遇上节假日等乘车高峰期应烤炉到数据越界问题。
5)稳定性需求:
该系统部署后,在硬件条件和支持软件条件没有发生变化的情况下,能够一直保持运行状态,直到系统被升级或替代。
2.5.2安全性需求
1)没有登录的用户无权发出乘车请求,只能浏览附近的公交车位置。
2)管理界面只有管理员用管理员账号在后台登录才能看到。
3)乘客在发送乘车请求时需要输入验证码。
4)设计过程中利用可靠的密码技术,防止程序被恶意攻击或者破解行为。
2.5.3防护性需求
因用户写入操作导致的程序崩溃,在程序再次启动时能够检测到上次是否正常退出并且给予提示。
若服务器需要维护,需要暂时关闭软件功能,应提前在软件里公示,不要出现软件突然瘫痪的情况。
服务器管理员应确保服务器密码不被泄漏。
服务器所在房间应做好安全防盗工作,避免盗窃现象的发生。
2.5.4软件质量属性
1)健壮性:
如果在用户成功发送乘车请求前,用户和系统连接中断,那么用户可以在恢复连接后查看未完成的请求,并继续完成。
2)完整性:
只有拥有管理员访问特权的用户才可以查看和修改已注册的乘客和司机的信息。
3)易用性:
新的用户在安装该系统后应该可以平均在10分钟内掌握其基本操作。
3附录
附录一:
用例图的制作过程
用例图(Use Case Diagram)是 由软件需求分析到最终实现的第一步,它描述人们如何使用一个系统。
用例图包含六个元素,分别是:
参与者 (Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系 (Generalization)。
1.确定参与者(Actor)
制作用例图的第一步就是确定参与者。
在本系统中,很显然Actor包括出租车司机、乘客和管理员。
然后用右图的标示画出Actor。
2.用例(Use Case)
参与者描述了“谁来做”,而用例则描述了“做什么”的问题。
识别用例最好的方法就是从分析系统的参与者开始,考虑每一个参与者是如何使用系统的。
使用这种策略的过程中可能会发现新的参与者,这对完善整个系统的建模有很大的帮助。
用例建模的过程是一个迭代和逐步精华的 过程,系统分析者首先从用例的名称开始,然后添加用例的细节信息。
这些信息由简短的描述组成,它们被精华成完整的规格说明。
得到用例后,需将其写在右图所示的椭圆中。
下面,我们根据每一个参与者来获取用例。
与乘客有关的用例包括:
注册、登录、安全退出、发送乘车请求、获得接受请求司机的位置、服务评价和问题反馈。
与司机有关的用例包括:
注册、登录、安全退出、问题反馈、切换载客状态、处理乘车请求,处理乘车请求进一步分为拒绝呼叫和获取乘客位置和号码。
与管理员有关的用例包括:
乘客管理、司机管理、服务模式管理,服务模式管理进一步分为实时解答和稍后解答。
3.用例间的关系
用例间的关系主要包括关联关系、包含关系、扩展关系以及泛化关系。
画用例图时要根据不同的关系使用不同的线。
图中所使用的实心剪头表示的为关联关系,虚线并带有”include”的剪头表示包含关系。
根据参与者与用例的关系和用例之间的关系即可画出最终的用例图了。
4课程总结
学完了软件需求工程这门课,给我印象最深的就是“需求分析员”这一称号。
需求开发与需求管理在一个软件项目中无疑是至关重要的,而在需求工程中需求分析员的作用更是无可替代的。
需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者。
然而,需求分析员的能力要求也是很高的。
要想成为一名需求分析员,除了必备的专业知识外,还要拥有倾听的技巧、交谈和提问的技巧、分析能力、协调能力、观察能力、写作能力、组织能力、建模能力、人际交往能力、创造力……这些能力给我的第一印象就是强人,绝对的强人。
要求这么严格,绝不逊于特种兵选拔了,需求分析员也就成为了我心中IT界的特种兵了!
于是我就想到这么厉害的人肯定千金难求啊,不知道得如何聘请这些高人呢。
在后续的课程中,我们了解到,主题专家可以成为需求分析员,开发人员也能成为需求分析员,甚至连用户都能成为分析员!
其实,需求分析员就是用户与开发组之间的桥梁,将开发人员和用户紧紧地连接在一起。
所以,他要能听懂开发人员说的话,要能把这些话转述给用户后保证他们能理解。
至于定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、编写需求规格说明、为需求建模等职能并不是重点,毕竟这些专业的东西有人可以替代他,他的桥梁般的化身是无可替代的。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 需求 论文