任务1需求规格说明书.docx

1、任务1需求规格说明书需求规格说明书版本: 1.0修订历史记录日期版本说明作者2012年/05月/7日1.0初次生成文档丁娜（白萌/刘震宇/徐冰欣/田利洁）2012年/05月/8日1.0第二次生成文档丁娜（白萌/刘震宇/徐冰欣/田利洁目录需求规格说明书 1版本: 1.0 1修订历史记录 11. 引言 11.1 目标 11.2 文档约定 11.3 预期的读者和阅读建议 11.4 1.4产品的范围 11.5 参考文献 12. 综合描述 12.1 产品的前景 22.2 产品的功能 22.3 用户类和特征 22.4 运行环境 22.5 设计和实现上的限制 23. 外部接口需求 33.1 用户界面 33.

2、2 硬件接口 33.3 软件接口 33.4 通信接口 34. 系统特性 44.1 说明和优先级 44.2 激励/响应序列 44.3 功能需求 45. 非功能需求 45.1 性能需求 45.2 安全设施需求 55.3 安全性需求 55.4 软件质量属性 55.5 业务规则 55.6 用户文档 56. 其他需求 51. 引言1.1 目标本文档首先给出整个系统功能结构的概貌，试图从整体架构上给出整个系统的轮廓，然后对功能需求、性能需求和其他非功能需求进行了详细的描述。其中对功能需求的描述运用了UML的用例模型方式，描述每一用例的基本事件流，并给出直观的用例图。这些文字与图形都为了文档能够详细准确地描

3、述用户的需求，同时也为用户更容易的理解这些需求的描述创造了条件。1.2 文档约定（1） 页面的左右边距为1.91cm，上下边距为2.54cm,正文文本左对齐段落首行缩进2磅，行距设置值为1.25。（2） 标题最多分三级，分别为黑体小三、黑体四号、黑体小四。（3） 正文字体为宋体小四，无特殊情况下，字体颜色均为黑色。1.3 预期的读者和阅读建议本文档面向的读者对象：（1） 项目经理：项目经理可以根据该文档了解与其产品的功能，并据此进行系统设计、项目管理。（2） 设计员：对需求进行分析，并设计出系统，包括数据库的设计。（3） 程序员：配合设计员的设计报告，了解系统功能，编写用户手册。（4） 测试员

4、：根据本文档编写测试用例，并对软件进行功能性测试和非功能性测试。（5） 用户：了解与其产品的功能和性能。（6） 其他人员：如部门领导、公司领导等据此了解产品的功能与性能。 在阅读文档时，首先要了解产品的功能概貌，然后可以根据自身的需求对每一项功能进行进一步的了解。1.4 产品的范围该产品是在积累了丰富的业务经验的基础上开发的，在需求上，充分考虑了具体用户的实际情况。该产品是一个生后旅游出行实用查询工具平台，主要包括（1）查询景点、酒店、美食、游记、百宝箱信息（2）登录或注册（3）预订门票、旅行社、酒店（4）发表网友游记（5）管理对景点、酒店、美食、游记、百宝箱信息的删除、修改、增加1.5 参考

5、文献（1） 王水，张晓民.软件工程素质导论.郑州：河南科学技术出版社，2011年.（2） 威格斯.软件需求.刘伟琴，译.北京：清华大学出版社，2004.（3） 丁二玉.需求工程-软件建模与分析.北京：高等教育出版社，2009.2. 综合描述2.1 产品的前景旅游业是当今国际国内发展最快的产业之一，也是世界各国相互了解、交流，从而促进经济全球化的重要手段，所以各国政府都非常重视旅游业的发展。爱旅游业务范围是为旅游业企业用户快速上网、实用的基本网上服务；功能范围是为企业在网上提供网上应用服务。因此旅游咨询网可以得到了较高重视。 由于旅游借助互联网，能够解决传统旅游业不能解决的适应游客行、吃、住、游

6、一体化的需求；同时还由于旅游也作为一个整体的商业生态链，涉及到旅行服务机构、酒店、景区等等，利用互联网可以将这些环节连成一个统一的整体，进而可以大大提高服务水平和业务来源。互联网为传统旅游业提供新的机遇及提高服务水平和运作水平的手段2.2 产品的功能（见附录B【用例图】）（1）查询景点、酒店、美食、游记、百宝箱信息（2）登录或注册（3）预订门票、旅行社、酒店（4）发表网友游记（5）管理对景点、酒店、美食、游记、百宝箱信息的删除、修改、增加2.3 用户类和特征（1）管理员:景点信息的增加、删除、修改、查询网友游记信息的增加、删除、修改、查询美食信息的增加、删除、修改、查询酒店信息的增加、删除、修

7、改、查询用户信息的增加、删除、修改、查询旅行社信息的增加、删除、修改、查询百宝箱功能的增加、删除、查询（2）会员：景点信息的查询网友游记信息的查询、发表、删除（针对自己）美食信息的查询酒店信息的查询旅行社信息的查询百宝箱功能的查询门票、酒店、旅行社的预订（3）普通用户：景点信息的查询网友游记信息的查询美食信息的查询酒店信息的查询旅行社信息的查询百宝箱功能的查询2.4 运行环境1.该网站对运行环境无特殊要求，系统为window98以上版本2、硬件系统环境：台式电脑、笔记本电脑均适用2.5 设计和实现上的限制开发工具：VS2008 开发语言：ASP.NET和C#数据库：SQL SERVER 200

8、8浏览器：Internet Explorer 6.0或以上版本1G内存，2.0GHz主频机器服务器：Apache环境2.6 假设和依赖假设：用户在执行任何一条功能后，都可以终止进一步的操作依赖：预定酒店信息必须依赖于会员首先登陆爱旅游网；查看酒店信息数据必须依赖于酒店信息的添加3. 外部接口需求3.1 用户界面经分析，总结出用户界面包含的逻辑特征如下：（1）界面规范应遵循WEB软件界面的规范，界面风格简洁明快，素雅大方；（2）页面的布局，按与用户的交互需求不同，划分为不同的功能区域，实现和用户之间的友好交互；（3）前台界面操作可逆，其动作可以是单个的操作，或者是一个操作序列；（4）后台各管理模

9、块的不同管理功能操作界面，采用在不同窗口进行管理，各功能操作切换比较简单又相对独立。（5）提供信息反馈，如提供用户当前登录状态信息；（6）提供简单的错误处理；用户界面的具体细节将在用户界面规格说明中详细介绍。3.2 硬件接口（1）服务器端建议使用专用服务器。（2）支持一般的PIII(台式机的CPU)或更高档微机、笔记本电脑。3.3 软件接口（1）使用SQL SERVER 数据库存储数据信息。（2）运行于Windows XP/ 7，且具有WIN32的操作系统之上。（3）网站中的预定（门票、旅行社、酒店等的预定）功能需实现网上支付，故 得有和网上银行的软件接口。3.4 通信接口系统中用到的网络通信

10、协议如下：（1）TCP/IP网络协议。（2）CORBA组件通讯采用UDP协议。（3）HTTP协议。4. 系统特性4.1 说明和优先级高：是关键需求，必须实现，否则表示网站设计失败；中：支持必要的操作系统，是最终版本所要求，但是如果是紧急需要，可以考虑在下一个版本中实现；低：功能或质量上的增强，如果资源允许，这些功能的实现能够使得产品更完美主要实现的功能：功能优先级（1） 查询旅游信息高（2） 登录或注册中（3） 预订功能中（4） 发表网友游记低（5） 管理员更新旅游信息高4.2 激励/响应序列1 用户登陆 判断权限，进入系统2 帮助 显示操作流程图4.3 功能需求（附录B【用例分析】）(1)搜

11、索旅游信息(包括查询景点信息，旅游团信息，酒店信息，美食信息，百宝箱信息)（2）登录或注册（注册后才能登录，登录之后可以实现预订和发表网友游记等功能）（3）预订功能（包括门票预订，旅游团预订，酒店预订）（4）网友游记（管理员可以对游记进行删除和查询，会员可以查询游记，发表、修改和删除个人游记）（5）管理员更新旅游信息（包括对景点信息，旅游团信息，酒店信息，美食信息，百宝箱信息的添加、修改和删除）5. 非功能需求列举出所有非功能需求，而不是外部接口需求和限制。5.1 性能需求1. 数据精确度（1） 查询信息时应保证查全率，所有相应域包含查询关键字的记录都应该查到。（2） 查询信息应保证查准率，查

12、到的记录应与给定的查询条件完全匹配。2. 时间特性本网站具体时间特性要求要根据网速来决定。我们将最大限度的减少系统响应时间，最小化更新处理时间和数据转换时间。3.系统容量需求注册用户：3500以上在线用户：1500以上并发数：500以上4.适应性满足用户的使用需求。5.2 安全设施需求无5.3 安全性需求1. 设置权限，对于某些特定的用户，只分配其部分权限。让其只能做自己能做的操作。2. 对于敏感的数据，在存入数据库前进行加密操作。3. 对于数据库中的数据，一定要进行实时的备份操作。每当数据库中发生一些修改操作时，就进行备份操作，这样的话，再后来的数据丢失时，就可以进行及时的恢复，从而避免了数

13、据丢失造成的损失。5.4 软件质量属性1. 正确性要求发布的网站达到用户的预期目标，运行时基本无错误。2. 可靠性对于编写好的软件，我们会进行大量的测试，不断地查找里面出现的bug，并及时的对其进行修改，尽可能的减少bug的数量。在网站的建设初期，我们对初步估计的用户量比较少，所以对数据优先选择了中小型的数据库，服务器也是我们寝室普通的笔记本电脑，随着用户量的增加，我们会及时的更新我们的服务器和数据库，从而保证网站的可靠性。避免用户量太大，而造成服务器瘫痪，影响网站的可靠性。3. 效率对于浏览、查询、添加、删除、更新等一般操作，要求及时响应，在35秒内。4. 完整性要求能在发生意外（如停电）的

14、情况下，保证不丢失数据。5. 易使用性对于网站的主界面设计，我们是参考了一些成功的网站设计，借鉴了他们的成功的经验。深入的研究他们用户界面的设计，并借鉴了那些成功网站的经验。6. 可维护性在设计网站的时候，将每个模块都分别独立开来，对于一些静态的页面，我们把其做成了模板，在使用的时候进行载入就行。这样我们就可以集中精力放在代码的编写上。避免了一些不必要的模块的干扰。在代码设计过程中，尽可能的减少模块之间的耦合性。做到模块和模块之间的分离。这样，对日后的维护就有了很大的方便性。7. 可测试性设计时尽可能减少测试本软件的各项功能所需的工作量。8. 复用性设计时应采取模块化的方法进行设计，对系统内各

15、模块接口尽可能达到高内聚、低耦合的程度，以提高各模块的复用性。9. 可理解性对于本网站提供的各种命令，各种信息提示，应易于用户理解。10. 互联性要求提供数据得到如何导入和导出接口，以易于同其他系统的连接。11. 可移植性要求本软件运行于多个操作系统。5.5 业务规则管理员：1. 管理员处于工作状态的情况下，允许发布、删除、修改、查看景点信息。2. 管理员处于工作状态的情况下，允许发布、删除、修改、查看酒店与美食信息。3. 管理员处于工作状态的情况下，允许增加、删除、修改、查看会员信息。4. 管理员处于工作状态的情况下，允许删除、查看旅游游记。注册会员：1. 注册会员凭用户名和密码登陆网站。2

16、. 注册会员点击相应的链接，可获取关于景点、美食、酒店等的信息。并且可行预订业务。3. 注册会员可以发表，删除自己的旅游游记。4. 当管理员试图登陆网站是忘记密码，可以点击“忘记密码”通过正确填写相应注册的信息来取回密码。5. 注册会员享受普通用户的一切权利。普通用户：1. 普通用户登录网站的时候，可以看到一些热点旅游景点的信息。2. 注册会员点击相应的链接，可获取关于景点、美食、酒店等的信息。3. 普通用户可以浏览旅游游记。4. 当用户需要搜索网站中的某一内容时，可以通过“站内搜索”中输入的相关信息进行搜索。5.6 用户文档用户文档名称描述及文档标准用户手册使用非专门术语的语言，充分的描述该

17、系统所具有的功能及基本的使用方法操作手册向操作人员提供该软件每一个运行的具体过程和有关知识，包括操作方法的细节6. 其他需求无附录A：术语表无附录B：分析模型(1) 搜索信息用例图：用例描述：用例名称搜索景点信息用例图用例目的会员对景点信息进行搜索，并能够得到自己所需要的信息。参与者会员前置条件会员需要以会员身份登录网站事件流1. 会员点击“景点信息”进入景点信息页面。2. 会员在景点信息的搜索页面输入需要搜索的景点信息。成功后置条件页面显示相关的景点信息失败后置条件页面显示“没有相关内容”扩展点已经搜索成功的景点信息，可以扩展到1. 搜索旅行社信息用例2. 搜索酒店信息用例3. 搜索美食信息

18、用例其他此用例使用频率：高（2）登录（注册）用例描述:会员登录用例名称用户登录用例目的完成登录，进入系统参与者会员（已经注册的用户）前置条件进入本网站首页事件流1、点击“登录”，进入注册界面2、输入姓名、密码3、点击“确定”后置条件完成登录，进入系统界面用例描述:游客注册用例名称用户注册用例目的完成注册，成为本网站会员参与者普通用户前置条件进入本网站首页事件流1、点击“注册”，进入注册界面2、输入姓名、密码、确认密码、邮箱信息3、点击“确定”后置条件完成注册，进入登陆界面（3） 预订功能用例描述:预定酒店用例名称预定酒店用例目的完成网上对酒店的预定参与者本网站会员前置条件通过身份验证，找到所需

19、酒店事件流3. 进入预定酒店页面2、选择所需酒店3、填写个人信息如姓名、电话号、预定时间、截止时间4、点击“提交”按钮 后置条件完成酒店预定，返回网站首页(4)网友游记模块的用例图：发表游记的用例描述：用例名称发表游记用例图用例目的完成游记的发表参与者会员前置条件会员成功登陆旅游网。事件流1. 进入网友游记界面。会员：选择进入相应的网友游记界面。系统：将网友游记界面中的信息显示出来2. 发表游记。会员：要求发表游记。系统：进入发表游记界面。3. 编辑游记。会员：输入游记感想。系统：显示输入的内容。4. 提交。会员：提交编辑好的游记。系统：保存该游记到内部数据库。成功后置条件完成了游记的发表，返

20、回网友游记界面。失败后置条件页面显示“发表失败”。扩展点已经发表成功的网友游记，可以扩展到1. 修改游记用例2. 删除游记用例3. 查看游记用例其他此用例使用频率：高(5)更新信息用例图：用例描述：用例名称添加景点信息用例图用例目的管理员针对信息的更新，对相关信息进行管理，保证信息的最新性和准确性，易于日常的操作和维护参与者管理员前置条件管理员需要以管理员身份登录网站事件流4. 管理员点击“更新”进入更新页面5. 管理员点击“景点信息”进入景点信息的更新页面。6. 管理员在景点信息的更新页面输入需要添加的信息7. 确认无误后，管理员点击“提交”成功后置条件页面显示“添加成功”失败后置条件页面显示“添加失败”扩展点已经添加成功的景点信息，可以扩展到4. 修改景点信息用例5. 删除景点信息用例6. 查看景点信息用例其他此用例使用频率：高附录C：待确定问题的列表编辑一张在软件需求规格说明中待确定的问题的列表，其中每一表项都是编上号的，以便于跟踪调查。