软件工程需求分析案例教学

王 勇 李程俊

（中国地质大学计算机学院 湖北·武汉 430074）

软件工程是指导计算机软件开发和维护的工程。而需求分析是软件生命周期中及其重要的环节。在需求分析中，首先要获取用户的具体需求，并进行分析和认证，然后建立项目的逻辑模型。需求分析关系着软件工程项目的成败。由于用户往往专业知识不足，使得需求沟通总是存在障碍。软件需求分析人员不仅需要抽象显性的需求，还必须具备挖掘隐藏的需求的能力。针对高等院校软件工程课程，特别是需求分析相关课程实践环节薄弱的现状，本文致力于探索需求分析的案例教学，从而提升软件工程课程的实验教学水平。

1 软件工程教学存在的问题

一直以来，软件工程教学中存在着一些不足之处。总体而言，文字性内容及说明指导性的教学内容过多而实践却很薄弱。具体而言表现在以下几个方面。

（1）课程的内容无法赋予学生实践参与感。软件工程课程致力于详细的说明各种概念、理论或方法。学生真正思考和动手的机会比较少。

（2）课程中建模工具没有和软件工程生命周期融会贯通。软件工程课程涉及到UML（统一建模语言）图教学。然而，UML图和软件工程生命周期的教学结合不紧密，没有强调对应关系。

（3）需求分析停留在纸面上。虽然课程强调了需求分析的重要性，但是没有给学生真正的机会进行需求分析的练习。软件工程本质上是实践课程，书本上的知识经过实践的演练才能成为有用的技能。实践薄弱的现状使得软件工程教学效果非常不理想。教学过程和实际应用严重脱节。

2 需求分析案例教学

需求分析是一种基于经验知识积累的创造性工作。本文有针对性地设计了一些需求分析的案例，并为每个案例给出了具体教学方法，具体如下所示。

2.1 案例教学设计

自行设计了一些案例，然后在案例的基础上展开需求分析的教学。具体情况如下。

（1）国际会议投稿审稿系统。此案例的具体教学方法如下。教师分别从投稿者和审稿人的角度描述这个软件系统的部分显性的需求。具体而言，投稿者需要通过系统投稿以及查看投稿的结果等等。同时，审稿人需要查看名下的审稿稿件条目，确认对某些稿件进行审稿而拒绝进行另外一些稿件的审稿，以及给所审的稿件评级写意见等等。教师在描述中必须强调，盲审制度决定投稿者和审稿人是不允许直接进行沟通的。认真研究完上述描述之后，学生会产生各种疑惑。比如，学术方向各不相同，投稿之后稿件是如何推送给合适审稿人等等。老师不能直接回答他们的疑惑，而是提供各种材料让他们自己思考，解决。比如，提供稿件的样式以及审稿人登记信息的样式。当学生看到上述两个材料中都提供了关键字之后，有可能会想到，可以用关键字匹配的方法迅速将稿件推送给审稿人。当然这种推送不可能百分百正确，所以审稿人有权拒绝部分审稿要求。又如，由显性需求可见，审稿人只负责给出稿件的评级及意见，不能决定拒绝或接收稿件。所以，为了给出最终的审稿意见，显然软件系统中还有其它角色参与操作。教师此时可以告知，每篇稿件有多个审稿意见，稿件数量很多，必须综合总体对比审稿评级，才能确定文章录用与否。学生得到这些补充信息之后，可能会提炼出软件的另一个参与者——编辑并为之设计需求。比如，处理审稿人拒绝审稿的信息，重新分排审稿人，根据审稿意见决定稿件录用与否等等。

在这个案例的教学中，模拟了根据不完整的线索进行分析，获取隐形的需求。并锻炼了学生利用用例图表达需求的能力。

（2）某连锁仓储超市应用系统。完成连锁仓储超市的日常管理。教师首先展示网上随处可见的普通超市管理软件。然后强调连锁仓储超市和普通超市有很多不同。动员学生去超市和仓储走访观察，促使其自行发现不同之处。

本案例教学主要锻炼学生通过调查获取需求。此外，通过这个案例，学生会感受到，名称相似的软件，可能内涵完全不同，从而真正理解软件需求分析的独特性。

（3）煤矿安全生产系统和智慧工地系统。分别用以完成煤矿和工地的管理。教师首先说明两个系统的主要用途都包括考勤，以及基于考勤数据发放工资。然而，工作环境的不同使得考勤的实现截然不同，各自都有难点。煤矿在出入口打卡即可统计出勤情况，然而难点在于工人在煤矿内部是否积极劳动也需要检查。由于工作空间本身有限等等原因，另派人手下矿检查是不现实的。而工地视野开阔，工人的工作是否积极一目了然，难点在于统计出勤情况。这是因为工地是开放的空间，仅在出入口打卡意义不大。此外，工地上不同工种的工人的考勤方式各不相同。比如砌砖的工人应计时考勤，制作预制板的工人应该计件。学生必须根据教师的说明，设计合理的考勤方案，进而围绕自己设计的方案完成需求分析。

由本案例可见，需求简单未见得代表需求分析简单，而且相同的需求在不同的场景下实现途径大相径庭。主要锻炼学生在不同场景下，用自己的需求分析能力支撑需求。

2.2 学生的实践流程

（1）获取需求。

（2）学生提炼出软件的全部参与者。

（3）学生为参与者设计用例。

（4）学生之间分组探讨，给出最终的需求分析结果。每个学生的需求分析结果往往不同。建议以两人小组方式进行开展探讨。探讨之后，组内学生拿出一个以用例图表达的最终方案。署名顺序由学生对于最终方案的贡献程度确定。

（5）评估打分。对每个小组给出的需求分析用例图进行评定，根据其质量和学生的署名顺序给该组的每个学生进行评分。

2.3 实施情况

软件工程需求分析案例教学已经直接植入本校现有的软件工程课程中进行试点。针对参加试点的计算机科学与技术、信息安全和信息管理与信息系统三个专业共7个班，208位本科生的问卷调查结果如表1所示。

表1反映了可喜的收获。当然，也能看到明显的不足——团队配合的组织方式还有待进一步加强。无论如何，软件工程需求分析案例教学的试点基本取得了成功。接下来，还有待通过进一步的教学研究来观察和提高软件工程需求分析案例教学的教学效果。

表1 软件工程需求分析案例教学效果调查结果

3 结语

一个满足用户要求的计算机软件，必须在合理的需求分析指导下才能够完成。错误的、不完全的需求分析结果将严重影响软件的质量。然而，能够胜任需求分析任务的人才一直以来数量较少，无法满足软件产业的需求。这种现象的一个重要原因在于，需求分析强调实践知识的积累，而高等院校计算机相关专业提供的实践机会则严重不足。本文所倡导的需求分析案例教学的目的在于为在校计算机相关专业的本科生提供需求分析的实践机会。具体选择了侧重点各不相同的三个案例进行教学。学生通过这三个案例的互动教学，能积累一定的需求分析经验。可以预见，需求分析案例教学的推广，能为在校计算机相关专业的本科生提供足够的需求分析的经验知识积累和实战机会，为学生们将来从事需求分析工作打下坚实的基础。接下来，教学研究小组需要进一步开展软件工程需求分析的案例教学研究，继续增加案例，完成相关的实验指导书，更好地指导学生的实践学习。