2.2 任务二：“小学生数学选题系统”的需求分析
2.2.1 子任务一：编写项目计划书
任务描述
以小组为单位，编写小学生数学选题系统项目计划书。
任务分析与设计
项目计划书是为了说明该项目计划的目的并指出预期的读者；其作用是为了说明本文档的意图和希望达到的效果；其意义是使项目相关人员了解项目开发计划书的作用、希望达到的效果。开发计划书的作用一般都是实现项目成员以及相关人员之间的共识与约定，是项目生命周期所有活动的行动基础，项目团队根据本计划书展开工作。
任务实现
1.编写目的
为了及时、保质完成小学生数学选题系统的开发，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，以文件化的形式，对工作任务进行分解，对相关内容以书面形式进行安排，作为项目开发过程中的共同和行动基础。
2.项目概述
1）工作内容
简要地说明在本项目的开发过程中必须进行的各项工作。
（1）组织开发小组对小学生数学选题系统的背景进行分析，了解原有工作流程。
（2）系统开发小组设计实施方案和开发流程。
（3）系统开发小组对系统进行集中开发。
（4）系统审核小组对系统进行评估、测试和审核。
（5）系统维护小组对系统进行定期维护。
2）参加人员
扼要说明参加本项目开发工作的人员的情况，包括他们的技术水平、主要经历等。
（1）项目组组长：有一定的责任心和很强的团队意识，有一定的表达能力、善于调动和管理小组成员。
（2）项目开发小组成员：具备一定的软件项目开发知识和使用相关软件的经验，了解软件的使用和操作流程，掌握VC++6.0开发环境。
3）产品
逐项说明本项目的预期开发成果，包括提交给用户的程序、文件和服务，以及应向本单位提交但不需向用户提交的程序和文件。
（1）小学生数学选题系统的安装包。
（2）登录系统的密码。
（3）用户使用说明书。
（4）C源程序。
（5）相关开发文档。
4）服务
列出需向用户提供的各项服务，如培训、安装、维护和运行支持等，应逐项规定开始日期、所提供支持的级别和服务的期限。
由各项目组负责人根据自己的实际情况填写表2.2。
表2.2 服务项目列表
5）完成期限
本项目的最迟完成期限为20天。
6）本计划的批准者和批准日期
（1）项目的批准者：软件技术专业负责人。
（2）批准日期：2008年9月10日。
3.项目实施计划
1）工作任务的分解与人员分工
对于项目开发中需完成的各项工作，从需求分析、设计、实现、测试到维护，包括文件的编制、审批、打印、分发工作，用户培训工作，软件安装工作等，按层次进行分解，指明每项任务的负责人和参加人员。为清晰起见，尽量采用表格的方式。
2）进度
对需求分析、设计、编码实现、测试、移交、培训和安装等工作，给出每项工作的预定开始日期、完成日期，规定各项工作任务完成的先后顺序，以及表明每项工作完成的标志性事件（即所谓的“里程碑”）。
开发过程的主要里程碑有：
（1）项目立项。
（2）需求调研结束。
（3）需求分析结束。
（4）概要设计结束。
（5）详细设计结束。
（6）编码结束。
（7）系统联调结束。
（8）系统测试结束。
（9）系统试运行结束。
（10）系统维护结束。
项目实施计划如表2.3（各组负责人负责填写）所示。
表2.3 项目实施计划
4.配置管理
项目开发各阶段的交付项，包括各种文档和代码，组成软件的配置。配置管理规定如何管理这些交付项。开发组会产生大量的交付项，而且由于不断地修改，每个交付项又有多个版本。如何从这些交付项建立最终系统，并保证用来生成最终系统的各交付项的一致，是配置管理的主要任务。
每个项目组，由专门人员负责项目开发交付项的管理工作，确保系统准时交付。
5.预算
逐项列出本项目所需要的劳务和经费的预算及来源。
本项目由学生自筹经费完成。
6.关键问题
逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目的影响。
（1）处理登录与主操作界面的关系。
（2）处理评分模块与判卷模块的关系。
（3）处理出题模块与题材量的变化的关系。
（4）软、硬件条件如下。
① 软件条件：VC++6.0开发环境。
② 机器最低配置：Pentium III 450MHz以上的CPU处理器，64MB以上的内存，200MB的自由硬盘空间，能支持24位真彩色的显示卡、彩色显示器。
引导文献
1.需求分析
1）需求分析的目标和任务
需求分析就是分析软件用户的需求是什么。如果投入大量的人力、物力、财力、时间，开发出的软件却没人要，则所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，而要重新开发，则这种返工是让人痛心疾首的。
需求分析之所以重要，是因为它具有决策性、方向性、策略性的作用，它在软件开发的过程中具有举足轻重的地位。必须对需求分析具有足够的重视。在一个大型软件系统的开发中，它的作用远远大于程序设计。
需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件与其他系统元素的接口细节，定义软件的其他有效性需求。
需求分析究的对象是开发项目的用户及其要求。要全面理解用户的各项要求，但不可能实现所有的用户需求，最后要清晰、准确地表达需实现的用户要求，这是软件设计的基础。
软件开发项目的目标是实现系统的物理模型，解决目标系统的“做什么”的问题。系统目标模型的实现步骤如图2.1所示。
图2.1 系统目标模型的实现步骤
2）需求分析的工作流程
（1）识别“问题”。系统分析人员综合确定对开发软件的需求，提出这些需求的实现条件和标准，如功能、性能、环境、可靠性、安全性、用户界面、资源及相应的开发进度等需求，可预先估算系统能达到的目标。同时，要确定质量控制标准、里程碑、评审验收标准及可维护性方面的需求。
（2）综合分析。分析人员应该从信息的处理入手，理清信息的结构脉络，逐渐细化软件功能，准备好封装的接口，找出设计所受的限制。对用户提交的需求进行筛选，与用户交流后消除需求误区（即不合理部分），增加真正的需要，最终形成系统的解决方案，给出目标系统的详细逻辑模型。
（3）编制需求分析阶段的文档。
（4）对需求进行分析评审。对功能的正确性、文档的一致性、完备性、准确性和清晰性，以及其他需求给予评价。以评审负责人的结论意见及签字为结束点。
3）获取需求的方法
（1）了解系统的需求。
（2）市场调查。
（3）拜访用户和用户领域的专家。对原始资料进行理解分析，结合专家信息进一步捕获用户需求。
（4）现场考察用户实际的操作环境、操作过程和操作要求。
具体操作有：下发用户调查表、召开调查会、跟踪业务流程、咨询关键岗位人员、查阅开发软件的相关资料。组长可以根据成员的特点进行分工，从多角度同步完成需求的获取。
2.项目目标的设定
设定项目目标就是把项目要完成的工作用清晰的语言描述出来，让项目团队的每一个成员都有明确的概念。注意，不要简单地说成在什么时间完成、开发什么系统或完成什么安装。“要完成一个系统”只是一个模糊的目标，还不够具体和明确。明确的项目目标应该指出服务对象，所开发系统的最主要功能和系统本身的比较深层次的社会目的或系统使用后所产生的社会效益。
3.项目计划与质量管理
项目计划是在可行性分析之后制订的，项目计划将作为依据贯穿需求分析、系统设计、程序设计、测试、维护等软件开发的环节。
项目计划要提供合理的进程表，明确参与软件开发人员的任务，保持开发步调一致，共同、及时地完成项目。项目计划是要付诸实施的，不要过于夸张，其重点在“准确”、“翔实”，而非“快速”、“完美”。
事实上，提高质量是软件开发的主要目标。软件开发是一种智力创作活动，仅仅通过执行严格的操作规范并不足以保证软件产品的质量。程序开发人员必须了解软件各个方面的元素，如正确性、性能、易用性、灵活性、可复用性、可理解性等，才能在进行系统设计、程序设计时提高软件质量。因此，软件的高质量实际上是“设计”出来的。
1）项目计划
做项目计划，就要“知己知彼”。确实了解设计项目的规模、难度与时间限制。这样，才可以确定在这个项目中要投入的人力、物力。在这方面，一个有经验的软件开发人员会为项目计划的设计带来很好的参考建议。
项目的时间限制：一种是类似于商业合同的限制，将完成日期写在合同中，延期时，开发方要做出相应的赔偿；另一种是自行开发的软件产品，只确定大致的发行日期并允许有延误，但是如果因此而拖延太久，也会失去商机而造成损失。
项目的资源分为“人”、“可复用的软构件”和“软、硬件环境”，如图2.2所示。
图2.2 项目的资源
人是最有价值的资源。制订项目计划时，一定要确定开发人员，并根据成员的特点和技术进行分工。
可复用的软构件能提高软件的质量与生产效率。还可以使用“拿来”的组件，甚至可以有偿购买专业性较强的软件。
软、硬件环境常常被忽略，但却是必不可少的资源。一般来讲，只要符合项目的开发要求即可。当所开发的项目需要使用特殊的设备时，要事先做好准备。
2）进度安排
我们常常会发现项目的开发进度落后了，究其原因不外如下几点：
（1）制定了不现实的期限。项目开发人员按照不合理的进度表开展工作。
（2）客户的需求发生了变化，进度表却没有做出相应的修改。
（3）低估了项目的规模和难度，投入的人力和物力不能满足开发需求。
（4）出现了没有预见到的难以克服的技术难题。
（5）开发人员安排没有冗余，没有考虑开发人员在现实中的意外事件。
（6）开发人员之间的交流出现了障碍，人员之间不能“兼容”和理解，从而导致各阶段任务不能按时完成。
基于以上的事实提出以下建议。
（1）由项目负责人制定进度表，因为他是最了解项目和开发人员的人。最终的进度表要经过开发小组的讨论和大多成员的认定。
（2）应尽可能将技术难度高的事件提前完成，进度安排并非一定要符合逻辑，应发扬中国人的美德——先苦后甜。
（3）开发软件项目，应设立为若干个里程碑。而且，一个里程碑的多个任务可同时进行。里程碑就像心灵的灯塔，指引程序员的设计进度。
（4）进度表中应该保留缓冲时间，可以借鉴Microsoft公司的开发小组制定的“50% 缓冲规则”。对许多项目经理而言，能够容忍进度表中存在缓冲时间，是相当不容易的。
（5）如果发现项目应交付的期限不合理时，要据理力争，放宽期限、调整进度。当客户需求发生变化时，要及时变动进度表。
3）项目实现“零缺陷”
高目标：人在做一件事情时，由于存在很多不确定的因素，一般不可能100% 地达到目标。但是，不设定较高的目标，没有“零缺陷”的质量目标，也许会成堆出现开发陷阱。
4）可执行的规范
好规范的前提是有能力实现并执行。无论多么好的规范，一味地照搬可能会出现硬伤。在书籍中可以很容易找到软件工程的众多规范，但真正适用于当前项目的规范、可以成功执行的规范才是真正的好规范。要把握软件的灵活与严密的尺度。程序员必须深入了解软件多方面的质量因素，把那些能提高软件质量因素的各种规范植入脑中，才能在各个实践环节自然而然地把高质量设计到软件中。
5）选题检查
质量检查并不是要等到项目结束时执行的。对应进度表，在设定的每个里程碑中进行质量检查并做出评审。
4.项目计划书的编写提纲（完整版）
项目计划书的编写没有定式，只有通用的约定。在编制时，还要注意具体“项目”具体分析。
（1）项目提出的背景和必要性：包括国内外现状、知识产权状况和发展趋势，技术突破对产业技术进步的重要意义和作用，项目可能形成的产业规模和市场前景。
（2）国内外市场分析：包括国际市场状况及该产品未来增长趋势、国际市场的竞争能力、产品替代进口或出口的可能性，国内市场需求规模和产品的发展前景、在国内市场的竞争优势和市场占有率。
（3）项目主要开发和建设内容：包括项目的主要科技攻关内容、项目目标及开发任务。
（4）项目实施的技术方案：包括项目的技术路线、工艺的合理性和成熟性，关键技术的先进性和创新点；产品技术性能水平与国内外同类产品的比较；项目承担单位在实施本项目的优势。
（5）项目实施的现有基础：包括项目承担单位注册地点、股权结构、资产和负债情况、员工构成、主要业务和主要产品、生产规模、主要装备和技术水平、近年来的经营状况，对引进技术的消化、吸收、创新的后续开发能力，企业资质、信用和融资能力等。
（6）项目组织机构和人员安排：包括项目的组织形式、产学研联盟运作机制及分工安排，项目的实施地点，项目承担单位负责人、项目领军人物的主要情况，项目开发的人员安排。
（7）项目实施进度计划：包括项目阶段考核指标（含主要技术经济指标，可能取得的专利，尤其是发明专利和国外专利情况）及时间节点安排，项目的验收指标。
（8）项目资金需求及来源：包括项目新增总投资估算、资金筹措方案（含自有资金、银行贷款、科教兴市专项资金、推进部门配套资金等）、投资使用计划。
（9）项目经济和社会效益分析：包括项目未来三年或五年的生产成本、销售收入和利税估算，财务内部收益率、投资回收期、投资利润率、财务净现值等指标的动态财务分析，社会效益分析。
（10）项目风险分析及应对措施：包括项目技术、市场、资金等风险分析及应对措施。
2.2.2 子任务二：编写需求规格说明书
任务描述
在完成了针对“小学生数学选题系统”软件市场的前期调查，以及与客户进行了全面、深入的探讨和分析的基础上，制定需求规格说明书。
任务分析与设计
开发人员针对“小学生数学选题系统”用户的需求进行细致的调研分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换为相应的需求文档。
任务实现
1.编写目的
“小学生数学选题系统”需求规格说明书的预期读者为客户、业务或需求分析人员、测试人员、用户文档编写者、项目管理人员。
2.系统概述
1）功能简介
简要描述系统的主要功能，并说明本系统与其他相关系统之间的关系。建议用框图的方式说明系统的组成。
“小学生数学选题系统”主要是对使用者的身份进行验证和对数学试卷的出题、判题、评分进行管理，根据其功能分为登录模块和主控模块。“小学生数学选题系统”流程如图2.3所示。
图2.3 “小学生数学选题系统”流程
2）用户特点
描述本系统的最终用户的特点，说明操作人员、维护人员的技能，以及本系统的使用频度。
本系统的最终用户为学校，操作人员只要掌握最基本的软件操作技能即可。系统维护人员要熟练掌握系统的功能与使用方法。系统的使用频度较高。
3）系统运行环境
说明运行该系统所需要的硬件设备。
硬件条件（最低配置）：Pentium III 450MHz以上的CPU处理器，64MB以上的内存，200MB的自由硬盘空间，能支持24位真彩色的显示卡、彩色显示器。
3.功能模块说明
“小学生数学选题系统”功能模块如图2.4所示。
图2.4 “小学生数学选题系统”功能模块
1）登录模块
（1）概述。本模块体现为用户使用软件的验证功能。
（2）登录模块如表2.4所示。
表2.4 登录模块
2）主控模块
（1）概述。主控模块主要由使用说明、题量设置、四则题库、评分系统模块组成，能够完成自动出题、阅卷功能。
（2）使用说明模块如表2.5所示。
表2.5 使用说明模块
（3）题量设置模块如表2.6所示。
表2.6 题量设置模块
（4）四则题库模块如表2.7所示。
表2.7 四则题库模块
（5）评分系统模块如表2.8所示。
表2.8 评分系统模块
引导文献
1.需求分析应该注意的事项
（1）最好为每个需求注释“为什么”，以便让程序员了解需求的本质，从而选用最合适的技术来实现此需求。
（2）需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。
（3）跳出程序员的逻辑。需求分析和程序设计不尽相同，合理、可行是才是重要的。要跳出程序设计的圈子，站在系统的角度上来看问题。
2.通过什么方式了解需求
（1）直接与客户交谈，“侃”出需求。
（2）用户讲不清楚，分析人员猜不透，就要请教行家。“听君一席话，胜读十年书。”
（3）应避免幼稚需求，分析优秀和蹩脚的同类软件，对优点尽量吸取，对缺点引以为戒。
3.软件需求规格说明及评审
软件需求规格说明是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。
作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。评审的主要内容是：
（1）系统定义的目标是否与用户的要求一致。
（2）系统需求分析阶段提供的文档资料是否齐全。
（3）文档中的所有描述是否完整、清晰、准确反映用户要求。
（4）与所有其他系统成分的重要接口是否都已经描述。
（5）被开发项目的数据流与数据结构是否足够、确定。
（6）所有图表是否清楚，在不补充说明时能否理解。
（7）主要功能是否已包括在规定的软件范围之内，是否都已充分说明。
（8）软件的行为和它必须处理的信息、必须完成的功能是否一致。
（9）设计的约束条件或限制条件是否符合实际。
（10）是否考虑了开发的技术风险。
（11）是否考虑过软件需求的其他方案。
（12）是否考虑过将来可能会提出的软件需求。
（13）是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。
（14）是否有遗漏，重复或不一致的地方。
（15）用户是否审查了初步的用户手册或原型。
（16）软件开发计划中的估算是否受到了影响。
为保证软件需求定义的质量，评审应由专门指定的人员负责，并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析员之外，用户/需求者，开发部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。评审的结果一般包括修改意见，待修改完成后再经评审通过，才可进入设计阶段。
即时训练
以小组为单位，编写自行设计的小学生选题系统的需求说明书。
拓展业务
设计彩票系统的需求说明书。