软件需求论文

1、1 论文要求1) 对所选系统进行严密的需求获取以及需求分析。2) 给出所选系统的各层次需求，包括业务需求，用户需求，功能需求以及非功能需求。3) 论文中给出所要实现系统的需求规格说明书。4) 需求规格说明书要详尽，必须包括以下内容：引言，总体描述，功能需求，接口需求以及其它非功能性需求等，符合需求规格说明书各项细则。5) 附录中给出所选系统需求规格说明书中各图表, 或者图表的获取过程. 例如数据字典的具体描述或者是UML建模中图的获取过程.2 需求分析规格说明书2.1 引言2.1.1 编写目的 所谓“需求分析”，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，需要得到

2、什么结果，最后应输出什么。需求分析阶段是一个非常重要的阶段，良好的需求分析文档，将为整个软件开发项目的成功打下良好的基础。2.1.2 项目信息本项目的名称：出租车呼叫服务系统本项目的应用范围：实时的方便市民出行的服务开发者：武汉理工大学计算机学院徐晓龙用户：市民、出租车司机2.1.3 术语说明TCSS: Taxi Calling Service System，出租车呼叫服务系统信息源：人们在科研活动、生产经营活动和其他一切活动中的成果及各种原始记录C/S模式：Client/Server模式，即客户端/服务器模式2.1.4 参考资料1 钟络，袁景凌主编，软件工程.北京：科学出版社，2012.12

3、 李勇华，袁梦霆等主编，软件需求工程.北京机械工业出版社，2008.83 周晓红，赵红玉，俞建新，基于GPS的出租车呼叫与调度系统.20092.2 总体描述2.2.1 组织结构与职责本系统用户的组织结构如图1-1所示。管理组管理员出租车司机用户组乘客图1-1 组织结构与角色2.2.2 角色定义用户在系统中扮演的角色，以及可以执行的职责，如表1-1表1-1 角色定义编号角色职责1管理员拥有所有用户的职责，享有系统最高权限及对整个系统管理的权限2乘客乘客具有发送乘车请求、获得接受请求的司机的位置、对服务进行评价、反馈问题等权限。3出租车司机出租车司机接收或拒绝乘车请求、切换载客状态、反馈问题等权限

4、2.2.3 系统概述出租车呼叫服务系统（TCSS）主要解决市民在日常生活中，打车难的问题，提供给乘客一个快捷、方便的打车系统，并节约出租车司机无目的行驶所浪费的时间和能源，在乘客与出租车司机之间搭建了一个服务完善、实时互动的应用平台，该平台的开发理念是远程、实时、互动、低碳、快捷。随着非智能手机的GPS应用难题被克服，GPS手机逐步得到普及，手机的位置服务功能成为无线通信应用的一个总要方面。与此同时，越来越多的城市在出租车上安装了车载GPS系统。在此背景下，我们可以构建一个基于GPS手机和安装了车载GPS系统的出租车的系统平台，通过该平台乘客呼叫出租车服务具有目的性，与此同时，出租车公司能够根

5、据用户的当前位置利用最短路径搜索算法搜索出租车前往服务。该系统的结构图如图1-2所示图1-2 系统结构图2.2.4 信息源本系统的主要信息源说明，如表1-21-7所示。表1-2 管理员信息表单据名称Admin用途存储管理员的相关信息使用者系统管理员表1-3 乘客信息表单据名称Passengers用途存储乘客的相关信息使用者乘客表1-4 司机信息表单据名称Taximans用途存储司机的相关信息使用者出租车司机表1-5 问题信息表单据名称Questions用途存储反馈的问题的相关信息使用者管理员、乘客、出租车司机表1-6 乘客_司机信息表单据名称Pas_Tax用途存储乘客_司机的相关信息使用者系统

6、管理员表1-7 打车记录信息表单据名称TakingTaxi用途存储乘客打车的相关信息使用者系统管理员2.2.5 用户类及其特征本系统适用于拥有并能熟练使用手机的用户，以及培训过的出租车司机。要求用户界面良好，提供帮助。2.2.6 系统运行环境本系统采用C/S体系结构，易于把握，成本低廉。它可以实现不同的人员，从不同的地点，以不同的接入方式（如WLAN, CMNET等）访问和操作共同的数据库。它能有效地保护数据平台和管理访问权限，服务器数据库也很安全。具体所需配置如下：服务器端硬件环境：80x86系列微机CPU: 2.0GHz 以上内存：2GB以上硬盘空间：80GB以上输入输出设备：键盘、显示器

7、等网络设备：Hub、网卡、网线等软件环境：操作系统：Windows Server数据库系统：MySQL 5.5其他软件支持：JDK1.6+MyEclipse+Tomcat 6.0客户端硬件环境：CPU: 1.0 GHz以上内存: 128MB以上外存空间：2GB以上输入输出设备：键盘、触屏显示器等软件环境：操作系统：Symbian, Android, Windows Phone, IOS数据库系统：MySQL 5.52.3 功能需求本系统通过面向对象的分析方法作为主要的建模方法，使用UML（Unified Modeling Language）作为建模语言，UML为建模活动提供了从不同角度观察和展

8、示系统的各种特征的方法。在UML中，从任何一个角度对系统所作的抽象都可能需求几种模型来描述，而这些来自不同的角度的模型图最终能够成为系统的映像。2.3.1 系统用例根据以上分析，主要介绍乘客、管理员和司机的用例所具有的的主要功能权限。系统用例图如图1-3所示。a图1-3 系统用例图 以下对几个主要的用例进行用例描述：登录用户登录系统执行者 司机、管理员、乘客前置条件无后置条件用户登录系统成功交互1) 用户进入系统登录界面2) 系统提示用户输入用户名和密码3) 用户输入信息4) 系统对用户输入的信息进行认证5) 认证失败，系统提示用户输入了错误的信息；认证成功，用户进入系统发送乘车请求乘客向服务

9、器发送乘车请求执行者 乘客前置条件乘客成功登陆后置条件服务器收到乘客的请求交互1) 乘客进去发送请求界面2) 系统提示用户是否发送乘车请求3) 乘客选择发送请求4) 服务器接收请求5) 系统提示乘客成功发送请求处理乘车请求司机对服务器发送的乘车请求进行处理参与者司机前置条件司机收到服务器发送的乘车请求后置条件服务器收到司机的反馈交互1) 服务器将乘客发送的乘车请求传递给最近的司机2) 系统提示司机处理请求3) 司机拒绝请求，反馈给服务器拒绝请求；司机接受请求，服务器把乘客的信息发送给司机4) 服务器把信息传送给乘客2.3.2 系统后台管理需求根据出租车呼叫服务系统提供的服务及实现的功能，经分析

10、与设计，提出以下相应的需求。Ø 乘客管理，主要实现查看乘客、修改乘客、删除乘客、添加乘客、冻结乘客、激活乘客等功能。Ø 司机管理，主要实现查看司机、修改司机、删除司机、添加司机、冻结司机、激活司机等功能。Ø 问题管理，主要实现查看问题、提交问题、修改问题、删除问题等功能。2.4 接口需求2.4.1 外部接口用户界面：客户端提供帮助连接，解释使用方法；乘客客户端可支持触屏或键盘操作，司机的由所在公司统一配发，触屏操作。软件接口：本系统运行在Symbian, Android, Windows Phone, IOS主流手机平台上，不同的系统连接MySQL数据库的方法有所

11、不同。硬件接口：键盘、触屏显示器与内部主机连接。通信接口：TCP/IP 协议2.4.2 故障处理出错输出信息：根据不同的错误提供不同的错误提示信息出错处理对策：1）一般错误：显示错误信息，提示用户重新操作 2）严重错误：重新启动，必要时启用备份恢复数据2.5 其他非功能需求2.5.1 性能需求1) 时间特性：实时刷新界面时间2s信息的上传下载时间5s2) 空间特性：支持的终端数5000支持的并行操作使用者人数500处理的记录数50003) 界面需求：乘客登录窗口和进入系统的窗口必须简介清晰，而且美观。4) 精度需求：系统在地图上显示的用户和出租车的地点必须精确，要控制 住误差。当遇上节假日等乘

12、车高峰期应烤炉到数据越界问题。5) 稳定性需求：该系统部署后，在硬件条件和支持软件条件没有发生变化的情况下，能够一直保持运行状态，直到系统被升级或替代。2.5.2 安全性需求1) 没有登录的用户无权发出乘车请求，只能浏览附近的公交车位置。2) 管理界面只有管理员用管理员账号在后台登录才能看到。3) 乘客在发送乘车请求时需要输入验证码。4) 设计过程中利用可靠的密码技术，防止程序被恶意攻击或者破解行为。2.5.3 防护性需求因用户写入操作导致的程序崩溃，在程序再次启动时能够检测到上次是否正常退出并且给予提示。若服务器需要维护，需要暂时关闭软件功能，应提前在软件里公示，不要出现软件突然瘫痪的情况。

13、服务器管理员应确保服务器密码不被泄漏。 服务器所在房间应做好安全防盗工作，避免盗窃现象的发生。2.5.4 软件质量属性1) 健壮性：如果在用户成功发送乘车请求前，用户和系统连接中断，那么用户可以在恢复连接后查看未完成的请求，并继续完成。2) 完整性：只有拥有管理员访问特权的用户才可以查看和修改已注册的乘客和司机的信息。3) 易用性：新的用户在安装该系统后应该可以平均在10分钟内掌握其基本操作。3 附录附录一：用例图的制作过程用例图(Use Case Diagram)是 由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例图包含六个元素，分别是：参与者

14、 (Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系 (Generalization)。1. 确定参与者(Actor)制作用例图的第一步就是确定参与者。在本系统中，很显然Actor包括出租车司机、乘客和管理员。然后用右图的标示画出Actor。2. 用例(Use Case)参与者描述了“谁来做”，而用例则描述了“做什么”的问题。识别用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的

15、建模有很大的帮助。用例建模的过程是一个迭代和逐步精华的 过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。这些信息由简短的描述组成，它们被精华成完整的规格说明。得到用例后，需将其写在右图所示的椭圆中。下面，我们根据每一个参与者来获取用例。与乘客有关的用例包括：注册、登录、安全退出、发送乘车请求、获得接受请求司机的位置、服务评价和问题反馈。与司机有关的用例包括：注册、登录、安全退出、问题反馈、切换载客状态、处理乘车请求，处理乘车请求进一步分为拒绝呼叫和获取乘客位置和号码。与管理员有关的用例包括：乘客管理、司机管理、服务模式管理，服务模式管理进一步分为实时解答和稍后解答。3.

16、 用例间的关系用例间的关系主要包括关联关系、包含关系、扩展关系以及泛化关系。画用例图时要根据不同的关系使用不同的线。图中所使用的实心剪头表示的为关联关系，虚线并带有”include”的剪头表示包含关系。根据参与者与用例的关系和用例之间的关系即可画出最终的用例图了。4 课程总结学完了软件需求工程这门课，给我印象最深的就是“需求分析员”这一称号。需求开发与需求管理在一个软件项目中无疑是至关重要的，而在需求工程中需求分析员的作用更是无可替代的。需求分析员是对项目涉众的需求进行收集 、 分析、记录和验证等职责的主要承担者。然而，需求分析员的能力要求也是很高的。要想成为一名需求分析员，除了必备的专业知识外，还要拥有倾听的技巧、交谈和提问的技巧、分析能力、协调能力、观察能力、写作能力、组织能力、建模能力、人际交往能力、创造力这些能力给我的第一印象就是强人，绝对的强人。要求这么严格，绝不逊于特种兵选拔了，需求分析员也就成为了我心中IT界