需求工程计划初步模板.docx
《需求工程计划初步模板.docx》由会员分享，可在线阅读，更多相关《需求工程计划初步模板.docx（22页珍藏版）》请在冰点文库上搜索。
需求工程计划初步模板
软件工程课程网站系统
需求工程计划
[]
组长：
胡琼英
组员：
宋心怡、林蔡勇、邵一哲、杜玲炯、杜逸先
日期：
第章引言
编写目的
业务机遇
业务目标
参考资料
第章项目概述
工作内容
开发人员
产品
需要移交用户的文件
服务
非移交的产品
验收标准
项目相关信息
系统运行环境
第章时间管理计划
工作任务的分解
第章范围管理计划
第章成本管理计划
第章质量管理计划
教师（助教）需求
管理员需求
学生需求
网站游客需求
系统功能需求
第章沟通管理计划
开发者与客户沟通计划
开发者内部沟通计划
第章风险管理计划
风险评估
需求获取方面的风险
需求分析方面的风险
编写需求规格说明方面的风险
需求确认方面的风险
需求管理方面的风险
风险控制
需求获取方面的控制
需求分析方面的控制
编写需求规格说明方面的控制
需求确认方面的控制
需求管理方面的控制
第章配置系统管理指南
配置标志
版本管理
变更控制
微小改正时的变更控制
较大变动时的变更控制
配置状态报告
配置审核
引言
编写目的
项目管理与软件需求，作为软件工程当中最为重要的组成几个部分，已经引起了业内人士的高度重视。
项目管理和需求工程概念的提出，就是为了把软件工程化，以更有效地开发需求，开发软件并实现有效的管理。
为了让教师能把最新、最前沿的关于项目管理和需求工程的信息传播给学生，为了让学生能够利用网络得到老师帮助，为了师生之间、同学之间能够充分交流，沟通心得，这个软件工程课程网站系统将提供这样一个教学、学习、交流的平台，为教师和同学服务，也为项目管理、需求工程、统一建模等软件工程化课程的教学方法提供试验基地。
业务机遇
世纪是以网络的全面深入运用为特征的世纪。
网络环境下的教育不仅是教育信息化的必然产物，也是教育改革发展的必然走向。
通过因特网或其他数字化内容进行学习交流与教学的活动即网络化学习（），可以充分利用现代信息技术所提供的、具有全新沟通机制与丰富资源的学习环境，实现一种全新的学习交流方式。
这种学习交流方式将改变传统教学中教师的作用和师生之间的关系，从而根本改变教学结构和教育本质。
美国教育部年月向国会递交的“国家教育技术计划”中打算以网络化学习作为提高年青一代“世纪能力素质”的根本措施。
技术的教育应用成为教育改革和人才培养的重要途径之一。
在这一大背景下，教学、学习、交流网站应运而生。
超文本特性可实现对教学信息最有效的组织与管理。
网络化的学习有利于充分实现交互与共享，有利于激发学生的学习兴趣和充分体现学习主体作用，有利于培养学习者的信息素养和信息能力。
另一方面教师利用教学、学习、交流网站可以充分发挥网络特性，对教学进行更为有效的管理，同时也有了更为便利的信息发布手段。
业务目标
虽然如今有很多教学网站，但是专门针对一门新开的大学课程和一位专门的教师，又为学生之间提供交流平台的网站为数不多。
这个网站作为一个开课的辅助工具，将有利于教师的教学和学生的学习；也为软件工程系列课程的成熟记录下足迹。
这个网站的主要目的就是为教师和学生提供交流的平台，方便教师，方便学生。
这个网站还为一些对这门课程感兴趣的人士提供一个了解的机会。
•教师能够更好，更容易地得到学生的反馈，调整自己的进度或方法
•教师可以方便地点评学生作业
•有助于提高教师知名度和影响力，方便同学了解教师
•学生的获得资料更加容易，更加丰富
•学生能够有针对性地进行补课，如果有缺课的话
•学生可以方便地向老师提出疑问并且可以迅速的得到解答
•游客可以有机会了解这门课的情况，教师的情况
这个网站预计会在学期结束时完成最终版本。
表任务简略图
软件名称
软件工程课程网站系统
提出者
软件需求分析与设计课程组
开发团队
组长：
胡琼英
组员：
宋心怡、邵一哲、林蔡勇、杜玲炯、杜逸先
参考资料
1、项目描述
2、课程的
3、用户沟通交流
项目概述
工作内容
软件开发的流程为：
沟通、策划、建模、构件以及部署，根据不同的模型可以采用不同的开发方法。
由于此系统较为小型，且需求较为详细明确，故采用最传统的经典生命周——瀑布模型。
在项目开发初期，需求的获取十分重要，需要定义需求开发过程，编写前景和范围文档，确定用户群和他们的特点，为每类用户选择代言人，建立典型用户的中心小组，与用户代表沟通以确定用例，确定系统事件和响应，召开专门的需求获取讨论会，观察用户工作的过程，检查当前系统的问题报告来进一步完善需求，跨项目重用需求。
由于此课程重点在于需求的获取，因此这一部分会尤其详细些，当获取需求后，开始进行项目估算，进度计划，项目跟踪，完成策划这一部之后，开始进行建模分析与设计，接着构建项目，包括编码与测试，最后进行项目的最终部署，包括交付给客户，以及进行反馈。
开发人员
表开发人员信息表
开发人员
学院
专业
组内地位
技术水平
胡琼英
计算机科学与技术学院
软件工程
组长
中等
宋心怡
计算机科学与技术学院
软件工程
组员
中等
邵一哲
计算机科学与技术学院
软件工程
组员
中等
林蔡勇
计算机科学与技术学院
软件工程
组员
中等
杜玲炯
计算机科学与技术学院
软件工程
组员
中等
杜逸先
计算机科学与技术学院
软件工程
组员
中等
产品
需要移交用户的文件
表需移交的文件表
《项目章程》
《可行性分析报告》
《总体项目计划》
《需求工程计划初步》
《前景与范围》
《质量保证计划》
《需求工程计划》
《软件需求规格说明书》
《系统设计计划》
《需求变更控制文档》
《用户手册》
《软件概要设计说明》
《系统编码与实现计划》
《测试计划》
《工程部署计划》
《培训计划》
《系统维护计划》
《项目总体报告》
服务
表开发者向
服务名称
服务内容
服务期限
人员培训
当面培训系统使用方法
一周
系统安装
上门安装
一天
维护
远程在线或者上门服务
一年
非移交的产品
软件开发结束后，以下文档开发人员不需要移交给客户：
《人员分组表》，《概要设计说明书》，《数据库设计手册》，《代码与文档调整意见书》，《源代码文档》，《例会纪要》。
验收标准
表验收标准表格
《项目章程》
验收标准
《可行性分析报告》
文档规范，内容翔实
《总体项目计划》
文档规范，内容翔实
《需求工程计划初步》
文档规范，内容翔实
《前景与范围》
文档规范，内容翔实
《质量保证计划》
文档规范，内容翔实
《需求工程计划》
文档规范，内容翔实
《软件需求规格说明书》
文档规范，内容翔实
《系统设计计划》
文档规范，内容翔实
《需求变更控制文档》
文档规范，内容翔实
《用户手册》
文档规范，内容翔实
《软件概要设计说明》
文档规范，内容翔实
《系统编码与实现计划》
文档规范，内容翔实
《测试计划》
文档规范，内容翔实
《工程部署计划》
文档规范，内容翔实
《培训计划》
文档规范，内容翔实
《系统维护计划》
文档规范，内容翔实
《项目总体报告》
文档规范，内容翔实
项目相关信息
项目批准者：
软件需求分析与设计课程老师
项目批准日期：
年月日
项目截止日期：
年月日考试周前
系统运行环境
本网站要求提供对外服务的能力，保证至少名同学上课辅助服务的要求。
包括数据存储能力，网络服务吞吐能力，数据安全特性等。
服务器选用，可以选择或者。
开发平台可以选择,，或者,，平台。
请提供对外服务所要求的相应的安全保障。
时间管理计划
工作任务的分解
表任务人员分工表
项目任务（及里程碑）
截止日期
分组，建立通讯录、角色分工、例会制度、日报制度等
完成《人员分组表》
撰写《项目章程》
撰写《项目可行性报告》
撰写《项目总体计划》
撰写《需求工程计划初步》
撰写《前景与范围》
撰写《质量保证计划》
撰写《需求工程计划》
第至周小组例会纪要
撰写《软件需求规格说明书》
撰写《系统设计计划》
撰写《需求变更控制会规程》
撰写《系统编码与实现计划》
撰写《测试计划》
撰写《需求变更控制文档》
撰写《用户手册》
撰写《软件概要设计说明》
撰写《工程部署计划》
撰写《培训计划》
撰写《系统维护计划》
撰写《项目总结报告》
全部小组例会纪要
范围管理计划
网站的范围：
.信息发布.资料上传下载.交流互动
表需求工程范围管理表
开发阶段
具体内容
知识技能培训
培训需求分析员
培训用户代表和管理者
培训开发人员
创建项目术语表
需求获取
定义需求开发过程
撰写前景和范围文档
确定用户群和他们的特点
为每类用户选择代言人
建立典型用户的中心小组
与用户代表沟通以确定用例
确定系统事件和响应
召开专门的需求获取讨论会
观察用户工作的过程
检查当前系统的问题报告来进一步完善需求
跨项目重用需求
需求分析
绘制关联图
创建用户界面和技术原型
分析需求的可行性
确定需求优先级
为需求建模
创建数据字典
将需求分解到子系统
应用质量功能调配
规格说明
采用模板
确定需求来源
为需求分配唯一标号
记录业务规则
定义质量属性
需求验证
审查需求文档
测试需求
定义合格标准
需求管理
定义需求变更控制过程
成立变更控制委员会
分析需求变更的影响
建立基线和控制需求文档的版本
维护需求变更的历史记录
跟踪每项需求的状态
衡量需求的稳定性
使用需求管理工具
创建需求跟踪矩阵
项目管理
选择合适的软件开发生命周期
根据需求制订项目计划
需求变更时更新讨论项目承诺
管理与需求相关的风险以及编写风险文档
跟踪需求工程的投入
从其他项目的需求工程中积累经验
成本管理计划
开发者人数：
人
开发时间：
个月
需求工程经费预算：
表需求工程经费预算表
开发阶段
经费（元）
知识技能培训
需求获取
需求分析
规格说明
需求验证
需求管理
项目管理
总价
质量管理计划
软件工程课程网站系统是用于教学、学习、交流的网站，因此对其的客户需求分析可以分为教师、助教、管理员、学生与普通的网站游客。
教师（助教）需求
1、网站上可以发布系统的课程介绍，包括项目管理与案例分析、软件需求分析与设计等几门课的课时安排、教学计划、使用教材、国际国内背景、考核方式、和学生选这门课所需要的知识背景，以及大作业的介绍，并可以在以后增加另外课程的时候可以定制。
2、网站要有教师介绍，对任课老师的以往教学、科研成果、及其教学风格，出版书籍,所获荣誉的详细介绍，但此项信息只有管理员可以修改，教师不能修改。
3、网站要有助教介绍，对助教的以往助教经历、能力以及学生评价等的介绍，但此项信息只有管理员可以修改，助教不能修改。
4、教师能够进行课件、模板、参考资料、以往优秀作业、教学视频、音频资料下载、上传与删除操作，并且可以及时更新。
教师上传资料时可以选择资料类别，该类别用于在显示上传的资料时按照该类别进行显示，教师上传资料不限大小，教师删除的资料进入回收站。
5、教师或者助教对作业的批改采用线上批改而非线下批改。
6、教师消息发布栏用于教师发布作业点评、临时课程变更等通知。
通知按照时间进行排序，另设一栏专门用于发布重要通知或者置顶重要通知。
7、重要信息：
按照上传时间排序，最新的重要信息置于最上面。
8、最新信息:
公布老师最近的一些教学或外出交流的心得,以及网站一些资料与课件等的最近更新信息的介绍。
最新信息按照上传时间排序排在重要信息后面，最新信息不超过条，超过条后系统自动删除最旧的信息。
9、友情连接（如网上选课主页）有老师要求管理员实时更新。
10、在批改作业界面提供教师与助教的专门的作业点评栏目，作业完成情况跟踪的功能，对学生的作业和课后作业讨论进行点评。
11、提供专门的课程作业评分，平时成绩评分，期末考试或论文考核的评分，最终成绩的各项组成的比例的调整，以及根据每项的成绩统计出每个学生的最终成绩。
12、网站上要有网站向导即使用指南。
管理员需求
1、网站上可以管理相关课程信息，包括每门课的任课老师，每门课的选课学生名单，同时可以管理每个人的网站权限。
2、网站上可以管理课程页面的所有信息，包括课程介绍、教师介绍、助教介绍、课件、模板、参考资料、以往优秀作业、教学视频、作业点评，具体的管理措施可以是下载、上传、发布、删除。
3、管理员不可修改除自己外的用户密码，但可在用户忘记密码时经用户同意重置用户密码（随机数）并将用户新密码发送到用户邮箱。
4、对友情连接（如网上选课主页）的实时更新。
5、管理员可管理回收站，可对回收站内的资料进行永久清除资料操作或者恢复资料操作。
6、管理员可设置多人担任。
学生需求
1、能下载老师提供的课件，包括以往的旧版本课件，以及最新的课件。
2、能下载老师提供的参考资料（含电子教材、历年试卷、补课资料,以及老师的教学交流文章）并且网站能及时更新这些资料。
下载的速度能够得到保证:
要求同时可容纳人下载,并且人均速度能达到。
3、能上传对课程有用的资料，但教师助教以及管理员有权删除这些资料。
4、能及时看到老师的通知（含课程相关通知及作业点评）。
5、如果教师提供的是多媒体资料,网站能提供下载及在线观看功能（如课堂录像）。
6、网站界面要求简洁大方，有网站导航、相关链接（含学校选课系统、学院网页、需求相关主题网站）。
文件的排序方式可选，增加一个选择框，学生可根据自己的不同需求来选择按照不同的方式来进行网站显示文件的排序。
7、网站提供通过提问方式的密码取回功能。
假如用户未设置问题，则可通过向用户申请账号时绑定的邮箱或者短信发通知来取回密码。
8、网站能提供让分组的各个团队能有团队内部的交流工具（如论坛,不同团队可以申请认证板块，非团队成员不能浏览使用,但教师或者助教可以进入各个板块进行一定的指导，而网站管理人员也可管理认证板块）。
同时，内部交流工具要支持文件上传功能，可以不仅仅支持文字交流，也可以增加图片，音频等交流。
9、网站能提供一定资料共享功能（如论坛有上传下载附件功能，也可支持批量上传与下载，但对附件大小有限制，每个附件大小不得大于）。
10、网站能较醒目地提供教师的联系方式（尽量详细）。
11、网站可以提供站内文章标题搜索功能。
12、网站能够提供学生自身作业提交功能,并可以跟踪作业的批复情况（包括评分评语等）。
学生提交作业的格式只能是与压缩包格式，且作业大小不能超过，网站支持学生多次提交作业，每次提交均自动覆盖上一次提交，学生也可以下载最近一次提交的作业，超过设定的截止时间后，学生将不能再通过网站提交作业。
13、当教师或者助教发布一次作业时，会向每个学生发一封邮件提醒，邮箱地址为注册账号时的邮箱地址，同时，网站提供优秀作业展示功能。
14、网站可以查看学生自己的每项成绩以及最终成绩，但不能看到其他同学的成绩。
15、学期结束后，学生可以对教师的教学方式，教学质量等进行反馈与评价，也可以对助教的助教方式与质量进行评价与反馈，也可以对本课程的教学方式与质量进行反馈与评价。
网站游客需求
1、能看到老师提供的参考资料（含电子教材、历年试卷、补课资料,以及老师的教学交流文章），但只能看到部分内容，比如的前页，且不能下载。
2、如果老师提供的多媒体资料，能够在线观看部分内容，比如前分钟，但不能下载。
3、游客能看到历年学生对本课程，任课老师以及助教的评价与反馈。
4、网站界面要求简洁大方，有网站导航、相关链接（含学校选课系统、学院网页、需求相关主题网站）。
5、网站能提供一定资料共享功能（如论坛有上传下载附件功能、但对附件大小有限制，不得大于）。
系统功能需求
本网站要求提供对外服务的能力，保证至少名同学上课辅助服务的要求，包括数据存储能力，网络服务吞吐能力，数据安全特性等。
服务器建议选用，可以选择或者。
开发平台可以选择，或者，平台，请提供对外服务所要求的相应的安全保障。
沟通管理计划
开发者与客户沟通计划
在此系统中，客户为老师，与客户的沟通计划为进行至少两次的谈话，谈话的时间与地点可以通过电子邮件或者电话短信来确定。
其他沟通途径可以通过电子邮件与短信电话来进行。
开发者内部沟通计划
开发者内部的沟通可以通过开会议、联系、微信联系、电话联系、短信联系、邮件联系、网盘资源的共享来进行。
其中会议包括现实面对面会议以及网上视频会议，语音会议。
风险管理计划
风险评估
需求获取方面的风险
1、产品前景和项目范围没有达成明确的共识引发的风险
2、需求开发所需的时间分配不合理引发的风险
3、需求规格说明的不完整性和不正确性引发的风险
4、创新产品的需求不完全引发的风险
5、忽视非功能需求引发的风险
6、客户对产品需求意见不一致引发的风险
7、未加说明的需求引发的风险
8、对已有的产品作为需求基线来源引发的风险
9、根据用户提议的解决方案引发的风险
需求分析方面的风险
1、设定需求优先级引发的风险
2、技术上难以实现的特性引发的风险
3、不熟悉的技术、方法、语言、工具或者硬件引发的风险
编写需求规格说明方面的风险
1、需求理解引发的风险
2、尽管问题待确定但迫于时间压力而继续向前引发的风险
3、具有二义性的术语引发的风险
4、需求中包括设计引发的风险
需求确认方面的风险
1、未经确认的需求引发的风险
2、审查熟练程度引发的风险
需求管理方面的风险
1、变更需求引发的风险
2、需求变更过程引发的风险
3、为实现的需求引发的风险
4、扩大目标范围引发的风险
风险控制
需求获取方面的控制
1、在项目早期编写一份包括业务需求在内的前景和范围文档，并将它作为添加新需求和修改现有需求的指导
2、合理安排需求开发所需的时间，需求开发活动的工作量应占项目总工作量的。
3、强调市场调研、构建原型并成立客户小组，小组负责今早并经常获取对新产品前景的反馈信息
4、向客户询问以获得相应的质量特性需求，例如性能、易使用性、完整性和可靠性需求。
尽可能精确的在软件需求规格说明中，对这些非功能性需求及其验收标准编写文档。
5、确定主要客户，并采用产品代言人的方法，保证有足够的客户代表的积极参与，确保由合适的人对需求做出权威性的决策。
6、尽量识别客户可能做出的任何假设。
提出自由回答的问题来鼓励客户分享更多的想法、期望、主意、信息和关注点，而不是我们以其他方式所听到的。
7、通过逆向工程发现的需求编写成文档，让客户评审这些需求，以确保其正确定和相关性。
8、分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。
需求分析方面的控制
1、要确保每个功能需求、特性或用例都设定了优先级，并安排在一个特定的系统版本或迭代中实现它们。
2、评估每个需求的可行性，确定哪些需求的实现时间可能比预期长，尽早采取措施。
3、为满足某些需求而采取新技术时，要考虑到学习曲线的问题，只有通过一定的学习时间才能达到适当的熟练程度。
要尽早确认那些高风险的需求，并留出足够的时间用户从错误中学习经验，实验以及制作原型。
编写需求规格说明方面的控制
1、对需求文档进行正式评审的团队应该包括开发人员、测试人员和客户，以减小需求的不同理解造成的风险。
2、应该记录下负责最终解释每个的负责人的姓名和解决的截止日期。
3、创建一个数据字典来定义一些术语的条目和结构，对软件需求说明的评审可以帮助参与者对关键术语和概念达成一致的理解。
4、对需求的评审，可以确保强调的是需要解决的业务问题是什么，而不是规定如何解决。
需求确认方面的控制
1、在构造设计开始之前，确认需求的正确性和质量，应该为质量保证活动预留出一定的时间并提供资源，要确保客户参与需求审查活动。
2、要对参与需求文档审查的所有团队成员进行培训，请组织内部有经验的审查人员或者外界的咨询顾问来评述早先的审查。
需求管理方面的控制
1、应该推迟实现那些很可能还要发生变更的需求，待确定之后再实现，并在设计时要考虑到应该使系统易于修改。
2、需求变更过程要包括对提议的变更进行影响分析，组建变更控制委员会作出决策，使用工具支持预定义的过程。
3、需求跟踪矩阵有助于在设计、构造或者测试期间避免遗漏任何需求
4、应该制定分阶段或者增量的交付产品的实现计划。
在初始版本中先实现核心功能，在以后的迭代中再逐步增加系统功能
配置系统管理指南
配置标志
软件项的标识基本按照《软件配置标识命名规则》进行。
要通过标识能够确定软件项之间的相互联系。
版本管理
.首先在服务器上建立一个目录，作为项目配置数据库。
在此目录下按照每个项目组建一个分目录，项目组代码及项目组名构成目录名，然后在此项目组目录下按照所属每个项目建一个子目录，同一项目的开发文档存放在一个目录下，项目编号紧跟项目名就是目录名。
在一个项目分目录下可按非受控文档与受控文档建立一级次目录，然后在一级次目录下按文档的不同类型建立二级次目录，使得所有开发文档能分门别类的组织存放，便于查询。
目录结构可见下图的示例。
.项目子目录的受控文档一般只有项目经理和属于该项目的开发人员和配置管理员能够访问到。
配置管理员负责分配访问权限，一般项目经理对该目录具有较大的权限——读取、添加和更改；一般开发人员只有读取的权限。
.在项目开发的某一阶段结束时，通过了该阶段评审的这些开发文档交配置管理员保存到项目数据库，做为正式版本的第一版——版本。
.在以后的开发中，如果软件需要修改，那修改后的软件可用多级编号来表示新版本——、等加以区别标识。
.在各个评审阶段产生的所有评审报告和修改报告都要进行编号保存，编号与相应文档的编号要对应。
变更控制
微小改正时的变更控制
.在评审或测试后发现的问题由评审组组长或项目经理形成《软件问题报告单》或《源代码修改记录单》，并通知配置管理员。
.由配置管理员将需要修改的软件的备份从项目配置数据库中检出，开发人员执行修改。
.修改完毕后进行修改测试，编程错误累计到了一定的量或者测试时间已满一个月（从上一次入配置库后算起），凭《源代码修改记录单》及修改后的源代码，通知配置管理员，配置管理员确定测试报告的完备性，并在核对软件修改内容和修改人员填写的《软件修改报告单》或《源代码修改记录单》中的修改描述一致后，将文件登入项目配置数据库中，生成新版本。
.配置管理员修改《软件配置状态表》和《软件变更记录表》，以使其他相关开发人员及时了解软件变化情况。
较大变动时的变更控制
.开发人员或用户提出影响较大的修改要求（这是指要增加或删除某些功能或者是发现错误的阶段在造成错误的阶段的后面等）。
.配置管理员在收到这类修改要求时，必须组织有项目经理以及开发人员参加的修改评审会，讨论修改的影响范围，修改的必要性、可行性以及修改方法、步骤和实施计划。
.在
升级会员 