《软件需求分析》课程设计任务书.docx
《《软件需求分析》课程设计任务书.docx》由会员分享，可在线阅读，更多相关《《软件需求分析》课程设计任务书.docx（31页珍藏版）》请在冰豆网上搜索。
《软件需求分析》课程设计任务书
课程设计报告
课程名称：
软件需求分析
课题名称：
公交查询系统
姓名：
班级：
带教老师：
报告日期：
电子信息学院
目录
课程设计的主要步骤：
5
（1）软件项目需求启动：
5
（2）软件项目需求展开：
5
（3）软件项目需求定型：
6
（4）软件项目需求评审：
6
公交查询系统需求分析报告7
1.引言7
1.1目的7
1.2背景7
1.3参考资料7
1.4术语8
2.任务概述8
2.1目标8
2.2系统（或用户）的特点8
2.3假定和约束8
3需求规定9
3.1软件功能说明9
3.1.1功能需求（用户查询）9
3.1.2功能需求（管理员）10
3.2对功能的一般性规定11
3.3对性能的一般性规定12
3.3.1精度12
3.3.2时间特性要求12
3.3.3灵活性12
3.4系统属性需求12
3.4.1可重用性12
3.4.2安全性12
3.4.3易使用性12
3.4.4可转移性12
3.4.5适应性12
4数据管理能力要求（针对软件系统）13
4.1故障处理要求13
4.2其他专门要求13
5运行环境规定13
5.1设备13
5.2支撑软件13
5.3接口13
5.4控制14
6系统测试的需求14
6.1分析各种信息14
6.2.测试策略14
6.3测试内容15
7附件（附录）16
文档一：
需求获取安排计划16
文档二：
项目范围和前景文档18
文档三：
用户需求列表21
文档四：
用例文档23
文档五：
分析模型28
文档六：
项目评审30
8.小结与体会32
本科生课程设计成绩评定表34
根据课程设计的要求，在该阶段，每个小组（3-4人）构想一个需要解决的实际问题，并由其他小组提供解决方案。
1）每个小组通过随机选择的方式，选择解决其他小组提出的问题。
2）提出问题的小组扮演用户方，负责解决问题的小组扮演需求工程团队。
以需求工程团队为主，完成项目的业务需求分析，建立有效的高层解决方案及系统特性，完成项目前景和范围文档。
3）随机选择一个其他的小组作为评审组，与用户方一起完成项目前景和范围文档的评审。
4）结果文档：
问题分析过程文档，前景和范围文档。
5）要求度量：
问题数量，每个问题解决方案的平均输入/输出数量和平均特性数量。
6）注意事项：
所反映的系统规模要适中，大概有3~5个问题需要解决。
每个问题的难度也要适中，其解决方案涉及的输入/输出数据流在4~8个之间，解决方案需要的系统特性在3~5个。
小组之间的选择由助教随机决定，杜绝小组间自行结对的行为。
课程设计的主要步骤：
（1）软件项目需求启动：
1）在该阶段，每个小组构想一个需要解决的实际问题，并申请其他小组提供解决方案。
2）每个小组通过随机选择的方式，选择解决其他小组提出的问题。
3）提出问题的小组扮演用户方，负责解决问题的小组扮演需求工程团队。
以需求工程团队为主，完成项目的业务需求分析，建立有效的高层解决方案及系统特性，完成项目前景和范围文档。
4）随机选择一个其他的小组作为评审组，与用户方一起完成项目前景和范围文档的评审。
5）结果文档：
问题分析过程文档，前景和范围文档。
6）要求度量：
问题数量，每个问题解决方案的平均输入/输出数量和平均特性数量。
7）注意事项：
所反映的系统规模要适中，大概有3~5个问题需要解决。
每个问题的难度也要适中，其解决方案涉及的输入/输出数据流在4~8个之间，解决方案需要的系统特性在3~5个。
小组之间的选择有助教随机决定，杜绝小组间自行结对的行为。
（2）软件项目需求展开：
1）需求工程团队以经过评审的前景和范围文档为依据安排计划，展开需求获取活动。
2）利用需求获取方法，通过多次结合获取与分析的迭代过程，获取用户需求，建立用户需求列表。
3）完成用例文档（用户需求文档）。
4）结果文档：
需求获取安排计划书；用例文档（用户需求文档）；用户需求列表；使用的面谈报告和原型物件。
5）要求度量：
需求获取的次数；面谈方法获取的用例数量、原型方法获取的用例数量；用户需求数量、非功能需求的数量和种类比率、用例数量、平均用例的场景数量、平均用例的字数和最大用例的字数。
（3）软件项目需求定型：
1）需求工程团队根据用户需求，通过面向对象建模与分析手段，为问题设计解决方案，完成软件需求规格说明文档。
2）开发方建立分析模型，细化系统需求，完成软件需求列表。
3）结果文档：
分析模型；软件需求列表；软件需求规格说明文档。
4）要求度量：
软件需求的数量、非功能需求的数量；类图的类数量、关联数量，每个类的平均属性数量；行为图（包括交互图、状态图和活动图）的数量，交互图内平均参与对象数量和最大参与对象数量、交互图内平均消息数量和最大消息数量，状态图内平均状态数量和最大状态数量、状态图内平均转移数量和最大转移数量，活动图内平均的甬道数量、活动数量和数据对象数量、活动图内最大的甬道数量、活动数量和数据对象数量、方法契约说明的数量、方法契约说明的平均行数；
5）注意事项：
交互图、状态图、活动图和方法契约的使用可以根据项目情况安排，不要求必须使用。
但是对于没有使用的团队，必须要有足够的理由，助教会对其进行检查。
（4）软件项目需求评审：
随机选择一个团队为评审小组，每个问题的用户方、需求工程团队和评审小组联合进行综合评审，共同总结整个需求开发中的得失。
1）项目中所有提交的结果都纳入评审范围，但是尤其突出项目前景和范围文档、用例文档和软件需求规格说明文档。
2）对每份文档，要求下列度量：
页数；发现的错误类型（按照2.5节和15.5节的特性进行分类）及其数量；
3）核准各个阶段的度量数据是否与实际的工作结果基本一致。
4）评分标准：
项目启动阶段20%；项目展开阶段30%；项目定型阶段50%
公交查询系统需求分析报告
1.引言
1.1目的
随着社会生产力和科学技术的飞速发展，人类社会变得越来越错综复杂。
人类经历了从古代到现代的转变，从步行到汽车，轮船，飞机等交通工具的出现，越来越多的人们享受到了现代化的便捷，公交车作为一个城市最普通也是最有价值的交通工具，给数以百计的人们带来了方便，然而，随着城市越来越大，公交车的数量也越来越多，人们不禁对出行产生了疑问，到某个地方应该坐哪辆车？
中间应该换乘哪一班？
怎样能事先做好安排？
这些都给人们带来了不少麻烦。
目前，随着人们生活水平的提高，越来越多的人们追求高文明的生活，根据各个地区的具体情况，建立一个公交查询系统，对公交车路线进行总结是非常必要的，此系统建立的目标是为了服务于大众，给更多的人们出行带来便利。
1.2背景
（1）开发软件的系统名称：
公交查询系统
（2）项目的开发者：
任志伟高培伟赵文章曹斐
（3）用户：
面向那些在上海经常出行又不是上海本地人，即那些不熟悉上海公交线路的人
（4）实现完成的系统实施地点：
小组成员个人机和学校机房
（5）系统的软硬件情况：
硬件环境：
PII或更高档微机、笔记本电脑；运行时内存需要：
1GB;
安装所需硬盘：
160GB；打印机：
可选
软件环境：
中文Windows98/2000/Me/XP；OFFICE97及以上版本。
1.3参考资料
相关的文件包括：
《地理信息系统——ArcEngine方法》——韩鹏，王泉，王鹏，漆伟，乌萌，编著；
《地理信息系统概论》第三版——黄杏元，马劲松编著；
《.地理信息系统:
原理、方法与应用》——邬伦，刘瑜，张晶等编著；
《ArcGIS轻松入门教程——ArcGISEengine》ESRI中国（北京）培训中心；
《软件工程导论》（第5版）张海藩编著；
《软件需求工程》毋国庆、梁正平、李勇华袁梦霆、编著；
《统一建模精解》付宇光翻译。
1.4术语
SQL：
一种关系数据库的标准语言，全称为：
StructuredQueryLanguage
C++：
一种编程语言
VC：
全称为MicrosoftVisualC++，它是微软公司为Windows应用程序提供的强有力的开发环境与工具，具有图形用户界面的程序开发语言
StarUML：
一种专门的画图工具
DB：
DataBase，数据库
UML：
UnifiedModelingLanguage，一种建模语言，为建模活动提供了从不同角度观察和展示系统的各种特征的方法。
2.任务概述
2.1目标
本系统的研发的目标是满足客户的需求，即在乘公交的情况下，两地之间的公交换乘次数及其所需时间和距离，并将其高亮度的显示在地图上，如果条件允许，还应考虑在其他的情况下（如步行或驾车）的方案显示。
当然还要能够及时的进行数据的修改、更新、查找、添加，从而满足用户的需求。
另外就是还需要一些注释，可能工作量会很大，所以应该在有时间剩余的情况下再作修改和添加。
总的来说，软件开发的意图为便于广大乘客乘车、合理有效的安排行程以及管理人员对此系统进行数据的修改、删除、查找、添加等。
从而实现地图的输入，输出，显示，缩放，注释，查询子系统，管理子系统，线路查询，站点查询，换乘查询，删除站点，删除线路，修改站点，添加站点，清晰站点查询，模糊站点查询，周围建筑查询，最短路径的分析，以及要求对开发产品的界面格式统一，统一的错误声音提示等操作。
2.2系统（或用户）的特点
本系统适用于那些在上海经常出行又不是上海本地人，即那些不熟悉上海交线路的人而又需要这方面的帮助的人，也可以说是广大乘客。
2.3假定和约束
本软件为应用软件，需一定经费和时间。
经费预算：
50万人民币
本软件开发周期：
自2012年12月10日起至2013年2月30日为期81天。
其他限制：
（1）系统的反映速度应该控制在一个比较适当的时间，一般应以3S响应；
（2）可维护性，当客户的功能需求或者性能需求发生改变时，系统能够及时，低成本的达到新的需求。
3需求规定
3.1软件功能说明
结合公交管理公司和广大市民的实际需要，实现对公交信息等数据进行有效管理，实现如下功能：
公交车路线查询（包括：
站站查询、车次查询、站点与站点间的路线查询）、用户注册登录、对公交线路的意见评价、管理员对用户的管理、修改增加删除公交车的路线等等功能。
除此之外，在公交车的查询基础上提供了地图查询，地图可以根据用户进行放大查询，可以比公交车的路线更加形象，更方便用户的查询。
同时提供了城市的旅游景点的简单介绍和乘车路线，为旅客提供了很大的便利性，这促进城市的旅游发展。
我们采用面向对象的分析方法作为主要的建模方法，使用UML（UnifiedModelingLanguage）作为建模语言。
图1系统模块图
3.1.1功能需求（用户查询）
用户模块是由线路车次查询、车站查询、站站查询等查询方式，用于不同要求的查询方式。
有如下的查询方式：
车次查询：
输入已知的车次进行查询；
站名查询：
输入用户想到的车站或者所在的车站，查询经过该站的所有公交车信息；
起始站至终点站查询：
输入起始站与终点站，系统会输出所有的公交路线方案及所用的时间距离等全部信息；
数据库会提供给用户全部信息，用户可以根据自己的实际情况自己进行选择。
另外：
如果用户想成为管理员或者想给该系统提出意见，可以申请注册成为注册用户，方便与管理员进行交流。
1）用户界面操作流程图如下：
图2用户界面操作流程图
2）用户的用例图如下：
图3用户的用例图
3.1.2功能需求（管理员）
通过输入管理员账号和密码可以进入管理员模块。
该模块主要是添加线路、修改线路、删除线路三个功能组成，管理员可以通过不同的界面对系统的数据进行修改。
1）管理员界面操作流程图如下：
图4管理员界面操作流程图
管理员需要的数据：
用户名和密码。
添加路线：
添加车次、首末班时间、停靠站名、全程的路程、一般情况系起点站到终点站的时间等全部的详细的信息，方便用户查询。
修改路线：
修改已存在的班次、首末班时间、公交车路线（停靠站信息），节省数据库运行工作时间，提高效率。
删除路线：
删除不需要或者已经更改的路线，次模块还提供删除多条路线的功能，方便管理员删除多条路线，节省时间提高效率。
2）管理员的用例图如下：
图5管理员的用例图
3.2对功能的一般性规定
由于用户水平不均，因此要求该系统具有操作简单，界面友好的优点，同时，系统应该可以提供实时服务的功能，可以在线呼叫服务员，以求解决系统问题或者其他有关方面的问题，还可以有错误提示音，引导用户进行正确的操作。
界面上可以有用户使用参考资料，便于用户在最短的时间内掌握系统的必要操作。
本处仅列出对开发产品的所有功能（或一部分）的共同要求，如要求界面格式统一，统一的错误声音提示，要求有在线帮助等。
3.3对性能的一般性规定
3.3.1精度
见假定与约束
3.3.2时间特性要求
1）系统要求有即时性,马上能反应出查询结果，一般操作的响应时间应为1s-2s内；
2）地图查询时间一般情况为10s以内，若查询时间超过1分钟原因为处理的数据量过大，则应视为无响应；
3）更新处理时间：
2S内；
4）打印机的操作及数据导出应在可接受的时间内完成。
3.3.3灵活性
系统可维护性强，当需求发生变化时，为适应新需求而做出的系统更改应该对系统的安全性，稳定性，系统的开发进度影响尽量小，对适应需求所做成的改变成本应该最大限度的低。
3.4系统属性需求
3.4.1可重用性
该系统可以用到各种大型的旅游系统或者是城市主页中去作为简单的一部分使用。
3.4.2安全性
在该系统中，只有管理员可以修改相关数据，管理员输入用户名、密码和验证码进行输入输出数据类型为字符型，输入数值范围在20数据字符之内。
系统的数据输出在320个字符串内，适用于各种字体的输入。
同时系统会对管理员登录的地点等信息进行记录，出现异常会对此进行验证。
3.4.3易使用性
该查询系统界面简单，只要是知道电脑的基本操作的用户都可以使用该系统进行查询，而且界面的每一页都会显示相关的提示信息，如果操作错误，系统也会进行提示。
3.4.4可转移性
选择硬件软件接口条件符合，同时一切限制条件满足的情况下，把软件从一种环境移植到另一种环境指需要将该系统软件和数据库进行拷贝，然后将软件重新安装就可以，很容易操作。
3.4.5适应性
该系统具有一定的可扩展性，适应地理信息的变化，运行管理员对其进行更新和维护。
4数据管理能力要求（针对软件系统）
需要根据使用情况和单位要求定期对数据库进行维护、更新。
4.1故障处理要求
（1）由于系统管理员操作不当造成系统崩溃，解决方法：
有专业人员在最短时间内修复，并进行故障记录。
（2）由于系统超负荷工作造成瘫痪，解决方法：
重启优化系统，对系统中已有数据注意进行清理，还原重要数据。
（3）配置太低，系统无法正常工作。
解决方法：
及时更换设备，或者通过较少关闭某些不太必要的功能维持系统正常运行。
（4）断电造成系统数据丢失，解决方法：
经常对数据进行备份，数据丢失时通过原有数据完成对数据的修复。
（5）用户的某些误操作造成系统不稳定，解决方法：
即使进行数据清理
4.2其他专门要求
基于数据库的完整性、一致性要求，系统需要一定的保密性，管理员（DBA）可根据实际情况添加系统密码；对于用户，我们不需要用户有登陆用户名和用户密码。
还有就是，用户界面使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等都要做到。
5运行环境规定
5.1设备
处理器型号：
AMDAthlon（tm）64X2DualCoreProcessor4600+等以上配置均可；
256色,最高32位，1440*900的兼容显示器
内存：
1GB；硬盘：
160G；
输入输出设备：
鼠标、键盘、任意型号打印机（可选），任意型号光盘刻录机（可选）；
5.2支撑软件
操作系统WIN95/ME/98/2000/XP等系列中文操作系统；OFFICE97及以上版本。
编译软件：
visualstudio2005和Arcengine。
测试软件：
visualstudio2005和Arcengine
5.3接口
硬件接口:
需要标准打印机接口进行报表打印。
软件接口:
Windows标准接口。
5.4控制
若将此系统做成应用程序，则用户启动程序即可进入此系统，此系统窗体上方的查询应有三个下拉菜单包括换乘查询、站点查询、站线查询。
点击其中一个便可进行相应的查询。
我们通过上述方式对此系统进行控制，通过界面上的推出系统按钮控制退出系统。
6系统测试的需求
6.1分析各种信息
反复检查并理解各种信息，和用户交流，理解他们的要求。
可以按照以下步骤执行：
（1）确定软件提供的主要商业任务；
（2）对每个商业任务，确定完成该任务所要进行的交易；
（3）确定从数据库信息引出的计算结果；
（4）对于对时间有要求的交易，确定所要的时间和条件。
这些条件包括数据库大小、机器配置、交易量、以及网络拥挤情况；
（5）确定会产生重大意外的压力测试，包括：
内存、硬盘空间、高的交易率；
（6）确定应用需要处理的数据量；
（7）确定需要的软件和硬件配置，通常情况下，不可能对所有可能的配置都测试到，因此要选择最有可能产生问题的情况进行测试，包括：
最低性能的硬件、几个有兼容性问题的软件并存、客户端机器通过最慢的LAN/WANF连接访问服务器；
（8）确定其他与应用软件没有直接关系的商业交易。
包括：
管理功能，如启动和推出程序
配置功能，如设置打印机
操作员的爱好，如字体、颜色
（9）确定安装过程，包括定置从哪安装、定制安装、升级安装；
（10）确定没有隐含在功能测试中的户界面要求。
大多界面都在功能测试时被测试到。
还有没有测到，如操作与显示的一致性，如使用快捷键等；界面遵从合理标准，如按钮大小，标签等。
6.2.测试策略
表1测试策略
测试策略项
例子
测试阶段
系统测试
测试类型
功能测试
测试技术
75%用SQASuite自动测试，25%手工测试
完成标准
95%测试用例通过并且最高级缺陷全部解决
特殊考虑
测试必须在下午进行
6.3测试内容
根据软件项目的实际特点确定确认测试的内容。
对部分软件项目除基本的功能测试外，可能还包括性能测试、安全性测试、极限测试、并发操作测试等。
6.3.1功能测试
测试各项功能是否完全实现，是否满足用户的功能需求，通过场景进行模拟测试。
6.3.2用户界面测试
由开发人员和用户代表操作用户界面，调查用户满意程度，测试界面的友好程度以及操作的简单方便性是否达到既定要求。
6.3.3性能测试
输入数据，测试系统的安全性，稳定性，正确性是否达标。
6.3.4配置测试
测试系统要求的最低软件和硬件配置是否和需求相同。
6.3.5安装测试
在符合系统配置的软件和硬件环境下测试系统的安装时间是否适中，安装过程有无异常，安装是否完全。
7附件（附录）
文档一：
需求获取安排计划
《需求获取安排计划》
1.需求获取技术
1.1需求获取的目的：
（1）清楚地理解所要解决的问题；
（2）完整地获取用户需求。
1.2需求获取面临的挑战：
问题的复杂性和问题空间，理解的不完备性与不一致性，交流障碍，需求易变性。
所以，分析人员必须掌握一些基本技术，包括初步需求获取技术、需求建模、问题抽象与问题分解快速原型技术。
需求获取技术包括两方面的工作：
建立获取用户需求的方法的框架；支持和监控需求获取的过程的机制。
2.需求获取安排计划
客户访谈，也就是获取用户需求，其主要方法是调查研究。
其主要内容包括：
（1）了解系统的需求。
软件开发常常是系统开发的一部分。
仔细分析研究系统的需求规格说明，对软件的需求获取是很有必要的；
（2）市场调查。
了解市场对待开发软件有什么样的要求；了解市场上有无与待开发软件类似的系统。
如果有，在功能上、性能上、价格上情况如何；
（3）访问用户和用户领域的专家。
把从用户那里得到的信息作为重要的原始资料进行分析；访问用户领域的专家所得到的信息将有助于对用户需求的理解；
（4）考察现场。
了解用户实际的操作环境、操作过程和操作要求。
对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。
在做调查研究时，我们可以采取如下的调查方式：
1）制定调查提纲，向不同层次的用户发调查表；
2）按用户的不同层次，分别召开调查会，了解用户对待开发系统的想法和建议；
3）向用户领域的专家或在关键岗位上工作的人个别咨询；
4）实地考察，跟踪现场业务流程；
5）查阅与待开发系统有关的资料；
6）使用各种调查工具，如数据流图、任务分解图、网络图等；
7）为了能够有效地获取和理清用户需求，应当打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，协同工作。
3.问题分析与确认
问题分析与确认，主要组织分析并评审，最终确定问题是否比较完整。
文档二：
项目范围和前景文档
《项目范围和前景》
1.业务需求
1.1系统研发背景
随着社会生产力和科学技术的飞速发展，人类社会变得越来越错综复杂。
人类经历了从古代到现代的转变，从步行到汽车，轮船，飞机等交通工具的出现，越来越多的人们享受到了现代化的便捷，公交车作为一个城市最普通也是最有价值的交通工具，给数以百计的人们带来了方便，然而，随着城市越来越大，公交车的数量也越来越多，人们不禁对出行产生了疑问，到某个地方应该坐哪辆车？
中间应该换乘哪一班？
怎样能事先做好安排？
这些都给人们带来了不少麻烦。
目前，随着人们生活水平的提高，越来越多的人们追求高文明的生活，根据各个地区的具体情况，建立一个公交查询系统，对公交车路线进行总结是非常必要的，此系统建立的目标是为了服务于大众，给更多的人们出行带来便利。
1.2系统研发意义
公交查询系统的建立，不仅对人们的生活带来了便利，也为政府部门的管理规划带来了方便，地理信息系统（GeographyinformationSystem，GIS）和管理信息系统（ManagementInformationSystem，MIS）技术的发展，为城市规划带来了便利，随着经济的快速发展，城市化的进程也在加快，公交查询系统的建立，可以为政府部门提供直观的城市道路现状和公交运行情况，使领导和有关业务管理部门能够在该系统的帮助下，方便、迅速地了解城市的环境地理信息，还可从现有环境数据的基本要素和空间关系中挖掘和产生新的信息，引导环境管理者产生形象思维，拓宽思路和视野，发现和解决新问题。
2.项目范围
2.1系统目标
本系统的研发目标是采用先进的信息技术与系统工程理论，建成一个具有公交信息存储、动态整编与评价、信息查询等功能的公交信息管理系统，为城市管理的科学决策提供更有效的信息支持。
在该系统中包括地图、文字、表格、图像等。
系统建成后，应具备以下功能:
（1）系统应具有GIS的基本功能，对地图的操作包括图层控制、放大、缩小、漫游、全局显示、查找位置等等。
所有的观测数据和评价结果都要放进数据库，能够提供数据输入、输出接口；
（2）应用支持网络的SQLServer2005数据库实现局域网内数据的共享；
（3）根据数据生成统计图和报表；
（4）实现两地之间公交车次的查询，公交路线的查询，公交站点的查询，能在地图上动态显示，借助该系统，城市管理人员能够方便快捷地录入、查询和统计公交车相关信息，并制作和打印各种专题地图和统计图表等。
2
升级会员 