龙源期刊网 https://www.doczj.com/doc/5415089877.html,
软件需求分析的思维方法
作者：宋振乾
来源：《软件》2017年第08期
摘要：在软件工程中，虽然已经总结出了大量的需求分析方法和工具，但需求模糊问题依然普遍存在，究其原因是在需求实践中，缺乏必要的需求思维方式。只有在正确的宏观思维方式指导下，结合具体的需求分析方法和工具才能捕获到真实需求。本文结合辩证唯物主义哲学思想和需求的实践经验，提出了需求分析中的用户思维、场景思维、迭代思维、信息化思维和系统化思维，目的是在这些思维方式的指导下，辅助软件工程中的需求分析方法和工具发挥更大的作用。
关键词：软件工程；需求分析；信息化；系统化
中图分类号：TP311.52 文献标识码：A DOI：10.3969/j.issn.l003-6970.2017.08.029
本文著录格式：宋振乾.软件需求分析的思维方法[J].软件，2017，38（8）：151-154
引言
软件和我们日常使用的其他产品一样，其设计开发过程本质上是产品的制造过程，有其独特的制造工艺，其中需求分析是软件制造工艺中的重要环节，直接决定着未来软件的成败。在软件工程中，需求分析是指定义和描述软件系统的范围、目标及定义其功能时所要做的全部工作。简言之，需求分析就是分析软件用户的需求是什么，即全面地理解用户的各项要求，并准确地表达用户需求，明确软件开发的内容。正确的需求是构造软件大厦的基石和蓝图，其重要性是不言而喻的。但现实是残酷的，要捕获到真实的软件需求是一件非常困难的工作，用户需要的是个苹果，结果我们给用户的是一个梨。据Standish Group的研究显示，高达31.1%的项目彻底失败，高达52.7%的项目进度超期或成本超支，被认为成功的软件仅有可怜的16.2%。而这些问题中绝大部分都是在需求分析阶段埋下的“祸根”。需求分析在软件项目中如此重要，我们有必要分析造成需求获取困难的原因和应对策略。
1 需求的难点
是什么原因导致我们获取真实需求如此困难，原因总结起来有如下三点，第一点是需求工程的理论和实践还尚不完备。从1946年世界上第一台计算机发明到现在，虽经历了70年的发展，但从上个世纪七十年代开始计算机才逐渐大规模应用到社会生产生活中。伴随着计算机应用的普及，需求工程作为软件工程中的一个分支才逐渐发展起来，其发展历史就更为短暂。需求分析工作与软件开发工作相比，表面上看似没有技术含量，但却是一个集计算机技术、分析设计、人际沟通、语言和文字表达能力以及心理学等多领域知识于一体的技术领域。当今世界上无数软件项目由于需求问题而遭受经济损失甚至是彻底失败，表明对需求工程领域客观规律
需求分析方法论 原则上，需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力；在具体的任务开展上，以不干扰需求方的自主权为主，除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。 为了保证项目的成功，IT中心必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。 其中，需求分析是一个项目的开端，也是项目建设的基石。在以往的信息化建设失败的案例中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用应用管理软件。作为IT中心，必须提醒需求方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时IT 中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、实施上有发言权。 一、如何进行需求分析 需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术人员都合适。在写需求说明书时应该注意两个问题： 1、最好为每个需求注释“为什么”，这样可让双方（IT中心、需求方）了解需求的本质，以便选用最合适的技术来实现此需求。 2、需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。 二、重点监控需求分析 由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 1、用户说不清楚需求 有些用户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如总部各部门及各地的很多店铺在进行应用系统以及网络建设时，需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时，用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。 2、需求自身经常变动 根据以往的历史经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在系统选型及实施时，将软件的核心建筑在稳定的需求上，同时留出变更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。 3、IT中心分析人员或用户理解有误 系统分析人员不可能都是全才，更不可能是行业方面的专家。用户表达的需求，不同的分析人员可能
产品需求分析(上) –理论流程 作者: 唐杰 分类: 产品设计 发布时间: 2014-05-03 14:29 好几个朋友让我分享一下产品需求分析，我想了好久也没发现有什么可说的。这主要是我在工作中很少把需求分析当成规范性的操作流程，通常我都是在脑海里直接判断需求，而且在绝大多数的公司里，也没有规范的需求分析标准，常常都是由诸多因素直接影响并决定了需求。出现这样的情况，也是职业属性决定的，因为产品类的工作带有很多主观性因素。 既然要讲产品需求分析，那么就先要知道这在产品实现过程中处于哪个环节。无论是新产品还是迭代产品，首先由想法产生需求，然后需求汇集并分析，放弃掉不需要的，暂缓不紧急的，然后整理出需要下一步执行的，最终形成产品需求文档并实施。 在汇集分析之前，需求的产生来自各个方面，由不同的人产生想法并表述反馈给产品经理，因此产生需求，主要来自公司内部(老板、其他部门或同事)、产品经理自己(策划、挖掘)、外部(用户、客户、伙伴)。 通过上面的梳理，我们就清晰的认识到，产品需求分析实际上就是需求决策。无论是自己的创新想法，还是市场调研，或者说来自其他方面的需求，最终汇集到产品经理手里的需求分析，就是决策哪些要做、为什么要做、怎么做，同时也要给出哪些不能做、哪些暂缓做、为什么不能或暂缓。 需求分析之前我们先要对需求进行分类，每个公司或产品都有不一样的分类喜好，通常有功能类、数据类、运营类、体验类、设计类等等，分完类之后再对需求进行权重考虑并决策。 需求决策有三个基本考虑因素，分别是战略定位、产品定位、用户需求。这是一个层级的关系，战略定位决定了产品的位置，有些公司的产品在战略上只是需要有这样一个产品，也仅仅是需要有，有不代表非要做好，既然不要做好，也就不会有大的资源投入，更谈不上需求的迭代，所以战略定位是首要的需求决策因素。其次是产品定位，产品定位决定了哪些需求是必要的，哪些需求是多余的，同时也影响着用户需求的取舍。 基于三大考虑因素，我们对需求进行了筛选，之后还需要进行分位，即使用“四象限定位法”进行需求分位，将需求划分成“重要又急需、重要但不急需、不重要但急需、不重要也
软件开发方向 “成绩管理系统”软件需求规约 安博教育集团 二零零八年十月
修订历史记录
目录 1 引言 (5) 1.1 目的 (5) 1.2 文档格式 (5) 1.3 预期的读者和阅读建议 (5) 1.4 范围 (6) 1.5 术语 (6) 1.6 参考文献 (6) 2 系统概述 (6) 2.1 概述 (6) 2.2 功能 (6) 2.3 运行环境 (7) 2.4 假设与依赖 (7) 3 系统特性 (8) 3.1 系统角色 (8) 3.2 学生管理 (8) 3.2.1 增加学生信息 (8) 3.2.2 修改学生信息 (9) 3.2.3 删除学生信息 (9) 3.2.4 导入学生信息 (9) 3.3 教师管理 (9) 3.3.1 增加教师信息 (9) 3.3.2 修改教师信息 (9) 3.3.3 删除教师信息 (9)
3.3.4 导入教师信息 (9) 3.4 课程管理 (10) 3.4.1 增加课程基本信息 (10) 3.4.2 修改课程基本信息 (10) 3.4.3 删除课程基本信息 (10) 3.4.4 维护课程学生信息 (10) 3.5 成绩查询 (11) 3.5.1 学生查询成绩 (11) 3.5.2 教师查询成绩 (11) 3.6 成绩分析与统计 (11) 3.6.1 考试成绩表 (11) 3.6.2 班级各科平均成绩表 (11) 3.6.3 年级成绩排名表 (11) 3.7 系统维护 (12) 3.7.1 数据字典维护 (12) 4 非功能性需求 (12) 4.1 性能需求 (12) 4.2 安全性需求 (12) 4.3 可用性需求 (13) 4.4 用户文档 (13) 4.5 其它需求 (13) 5 外部接口需求 (14) 5.1 用户接口 (14) 5.2 硬件接口 (14)
培训需求分析的方法和工具 培训需求分析是企业培训的出发点，也是最重要的一步工作。如果需求分析不准确，就会让接下来的培训偏离轨道，做无用功，浪费企业的人力、物力和财力，却收不到应有的效果。企业要进行有效的需求分析，就必须采取合适方法和工具，本文全面介绍了通常情况下培训需求分析使用的方法以及对应的工具。 一、需求分析的方法和工具 1.1 调研问卷法 调研问卷法是最普遍也最有效的收集资料和数据的方法之一。一般由培训部门设计一系列培训需求相关问题，以书面问卷的形式发放给培训对象，待培训对象填写之后再收回进行分析，获取培训需求的信息和数据。 调研问卷法进行培训需求分析，可以遵循以下五个步骤，见表1： 在设计调研问卷的问题时，应该注意下几个问题： 1、问题尽量简短，并注意使用简单的、固定用法的术语，避免使用读者不了解或者容易引起歧义的名词； 2、一个问题只涉及一件事，避免“结构复杂”的问句； 3、题目设计要简单，不要使作答者作计算或逻辑推理； 4、避免出现诱导答案的问题，保证作答者完全陈述自己观点。
备注：填表时在对应的内容下面用“√”标明。 1.2 访谈法 访谈法也是数据收集的一种重要方法。它是指为了得到培训需求的数据和信息，与访谈对象进行面对面交流的活动过程。这个过程不只是收集硬性数据，比如事实、数据等，包括印象、观点、判断等信息。 访谈法可以遵循以下几个步骤进行，见表3：
1.3现场取样法 现场取样法一般较多使用于服务性行业的培训需求调查（如饭店、卖场等），是通过选取培训对象现场实际工作的部分片段进行分析，以确定培训需求的一种分析方法。现场取样法主要包括两种形式：拍摄和取样。 拍摄是指在培训对象的工作环境中安装监控录影机、摄像机等拍摄设备，对培训对象的现场工作过程进行实际拍摄，事后通过录影带进行观察分析，得出培训需求结论。表5为拍摄样板的示例。
软件需求分析规格说明书格式 2008年03月28日11:08:00 chenguang79阅读数：1993 1.引言 1.1编写的目的 /*说明编写本说明书的目的 1.2背景说明 /*给出待开发系统的全名及项目提出者，开发者，及用户。同时说明该软件系统将做什么和不做什么。 1.3术语定义 1.4参考资料 /*列出本文档所引用的全部资料以及资料的来源。 2. 任务概述 2.1功能概述 /*简要叙述本系统预计实现的主要功能及功能之间的相互关系，最好用图表明。 2.2约束条件 /* 简要说明对系统设计产生影响的限制备件，如管理模式，硬件限制，技术或工具的制约等。 3. 数据流图与数据字典 3.1 数据流图 3.1.1 数据流图图形 /*将需求分析构造的数据流图按层次逐层画出。 3.1.2加工说明 /*对数据流图中的每一个加工，按编号，加工名，输入流，输出流及加工过程逐一说明。 3.2 数据字典 /*本节对数据流图中使用的数据项，数据结构，文件的内容及组织结构逐项说明. 3.2.1 数据项说明 3.2.2数据结构说明 3.2.3文件说明 4 系统接口 4.1 用户接口 /*说明人机交互界面的用户需求，如屏幕格式，报表，菜单的格式与内容及功能键定义。 4.2 硬件接口 /* 说明本软件系统与硬件设备的接口信息的内容，格式以及运行软件的硬件设
备特征。 4.3 软件接口 /*说明本软件系统与其它支持软件之间的接口规格，支持软件应明确其版本号。 5. 性能需求 5.1 精度要求 /* 说明输入/输出数据以及传输数据的精度要求。 5.2时间特征 /* 定量说明系统应达到的响应时间，更新处理时间，数据传输转换时间，计算时间的特征值 5.3灵活性 /* 说明本软件在需求发生变化时(操作方式，精度要求，时间特征等)的适应能力。 6 软件属性 6.1 可使用性 /* 规定系统的某些特殊需求，如检查点设置，恢复方法和重启动方法，以确保软件可使用。 6.2 系统安全性 /* 规定系统为保证运行安全，信息安全面而采用的技术措施，如密码，防病毒，防黑客等。 6.3 可维护性 /* 规定系统为提高系统的可维护性将采取的措施。 6.4 可移植性 /* 规定程序以及挡方面军的兼容性，扩充性的约束。 7 其它需求 7.1 数据库需求 /*对数据库的静态结构，动态组织，访问信息的方式，使用频率以及数据的存储等方面提出需求。 7.2 系统操作要求 /*列出系统所要求的正确或特殊的操作方式，如用户的操作方式和系统的后援和恢复操作。 7.3 故障及其处理 /* 尽量烈列出能够预测的系统故障(包括软硬件及其它系统)，并指出故障可能造成的影响及故障排除的方法。 8 附录
2010-09-05 需求—需求分析的任务和步骤（转） 文章分类:软件开发管理 需求分析的任务和步骤 任务：1. 通过对问题及其环境的理解，分析和综合，建立分析模型。 2.在完全弄清用户对软件系统的确切需要的基础上，用“软件需求规格说明书（SRS）”把用户的需求表达出来。 分析模型包含问题及其环境所涉及的信息流，处理功能，用户界面，行为模型及设计约束等。 需求说明应该具备准确性，一致性，清楚性，没有二义性，直观，易读和易于修改。为此应尽量采用标准的图像，表格和简单的符号来表示，使不熟悉电脑的用户也能一目了然。 步骤：1.需求获取：从分析当前系统包含的数据开始，系统需求包括用户对软件功能的需求和界面的需求。 2.需求提炼：分析建模：图像化的分析模型包括数据流图，实体关系图，控制流图，状态转换图，用例图，类对象关系及其行为图等。除系统模型外，更有系统关联图，创建用户接口原型，确定需求优先级别等。 3.需求描述：编写SRS：统一格式的文档--模板 4.需求验证：改善需求中的二义性，不一致的问题。 常规的需求获取方法： 1.建立联合分析小组：由用户业务人员，系统分析员和领域专家组成。 2.客户访谈：进一步确定需求。这个过程需要系统分析员有充分的准备和良好的交流能力。 3.问题分析和确认：去掉错误的，无关的部分，整理有用的内容，以便给用户确认，并在次访谈，如此循环2-5次。 快速原型法：步骤： 1.利用各种分析技术和方法，生成一个简化的需求规格说明。 2.对需求规格说明进行必要的检查和修改后，确定原型的软件结构，用户界面和数据结构等。 3.在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试，改进。 4.将原型提交给用户评估并征求用户的修改意见。 5.重复上述过程，直到原型得到用户的认可。 3.3 分析建模 软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明。
软件需求分析重点 第1 章软件需求基础知识 返工的成本占了总开发成本的30%-50%，而对于返工的情况，70%-80%是国需求错误引起的。（11） 在对所有讨论问题有了更深入的了解之前不要急于回答。不能充分理解需求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。（13-14）造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确以及地需求的分析不透彻等。给出估算结果时，应该提供范围（最好的情况，最可能的情况和最糟的情况）或把握程度（“我有九成把握在三个月内完成”）。（14） 从产品的实际用户处收集需求这一过程是不可替代的。（18） 第2 章客户眼中的需求 某些需求问题源于混淆了不同层次的需求（业务需求、用户需求和功能需求）。（19） 要想开发出优秀的软件产品，必须以优质需求为基础精心制定计划。（20）不要指望项目涉众天生知道如何合作进行需求开发。必须花时间讨论如何最有效地进行协作。（22） 需求审阅是最有价值的保证软件质量的活动之一。（25） 需求批准过程的所有参与者都应该明白签字意味着什么，否则会出现很多问题。（25） 不可能在项目初期就能明确所有的需求，需求肯定要随时间的推移而发生变化。（26） 第3 章需求工程的推荐方法 熟练的需求分析员应具备以下特点：耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工作技术。（29）为每类用户选择代言人（31）
观察用户工作的过程（31） 跨项目重用需求（32） 过早地以尚不明确的需求为基础进行开销和进度评估是非常不可靠的。（37）38图表 不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。（38） 第4 章需求分析员 相比缺乏经验的需求分析员，使用经验丰富的需求分析员能使项目所需求的工作量减少三分之一。（42） 优秀的需求分析员应同时具备出色的交流、引导和人际交待能力，具备技术和业务领域的丰富知识，以及适合这项工作的相应个性。耐心和真诚的合作愿望是关键的成功因素。（44） 需求分析员必须研究可能出错的情形。（44） 第5 章确定产品前景与项目范围 第6 章获取客户的需求 能否让开发人员更准确地了解用户需求，将决定软件需求工作能否取得成功，进而影响到软件开发的成功。（62） 项目伊始就应确定谁来担任问题的决策人。（72） 第7 章聆听客户的需求 需求开发工作的成果就是项目涉众之间就被处理的需求达成共识。（75） 需求获取的参与者在理解问题之前要抵制住诱惑，不要急于设计系统。 要强调用户任务，而不是用户界面，要强调根本需要，而不是用户表达出来的期望，这样有助于项目团队避免过早是制定设计的细节。 在软件开发中，需求获取也许是最困难、最关键、最容易出错和最需要沟通的一个环节。（76）
需求分析调研方案 项目调研总体目标： 需求分析是反复进行，逐渐深化，不断改进的过程 1.根据工程总目标，明确调研目标、层次; 2.根据目标设计调研方式,编写调研提纲，确定调研对象; 3.编写每阶段调研日记，汇总完善调研报告; 4.画出标准业务流程图，做到全面清晰； 5.绘制数据流程图； 6.以简明清晰的思路，浅显易懂的自然语言描述业务步骤； 7.找出业务关键点及瓶颈工序； 8.编写供参考的先进的方法与改进建议。 分阶段调研目标与规定 第一阶段：初步调研 调研目标 初步调研首要目标是对企业全局的了解，可具体分解为： 1.企业概况 2.企业的经营特点 3.企业的生产特点 4.企业的组织机构 5.企业行业地位 6.企业技术现状 调研对象 1. CIMS工程总负责人，必要时邀请总经理参加 2. 总部各职能科室负责人 调研方式 1. 参阅公司资料为主 2. 配合问答 调研范围 了解企业总体概况 调研时限 根据公司规模及组织结构的复杂程度，掌握在2～7天左右
调研提纲 一、针对企业概况，了解以下问题： 1.企业背景，历史演变过程 2.企业所属行业 3.企业的资产、产值、利税等生产经济指标 4.企业人数及素质 5.企业体制、组织机构 6.其它有关情况 二、针对企业经营特点做以下调研： 1.经营机制、目标 2.销售策略 3.财务制度、成本分摊办法、独立核算情况 三、针对企业生产特点做以下调研： 1. 企业产品的种类、型号、技术含量、结构特点、市场占有率 2.企业生产方式： ａ是离散、连续或半连续 ｂ生产批量：是多品种小批量还是单件大批量生产 ｃ是按订单还是按库存或其他方式组织生产 3.企业的产量、产值、利润目标 4.对产品使用安全性的要求，对使用环境的要求 四、针对企业组织机构做如下调研 1.绘制组织结构图 2.描述各职能科室职责 3.对企业的生产流程做简明调研 4.各分公司或子公司的总体概况、相互关系、与母体公司的关联程度 五、针对企业的行业了解下述情况 1.企业在行业及整个国民经济中的地位 2.产品的市场占有率 3.行业发展现状、企业的竞争目标 六、针对企业技术现状做如下调研 1.企业设备、先进、精密、自动化程度 2.计算机资源情况、数量、型号，可自动化系统的应用情况 3.技术人员的水平、能力 调研的注意事项 初步调研是针对公司总概况的调研，绝大部分公司对上述内容都有文件档案。顾问调研前一定要详细阅读相关资料，找出关键点与有疑问的地方重新拟定调研提纲，做到简洁、明快，尽量减少介绍人员对熟悉事物的反复介绍。 第二阶段：现状分析 在第一阶段的调研基础上对各职能科室及分公司做进一步调研
保密级别：S 资料编号：SRS-[产品代号] -[序列号] 版本：V[*].[*] [产品型号名称（二号字体）] [部件型号名称（可选、小二号字体）] 软件需求分析说明书 共11页 编制： 审核： 审定： 会签： 批准： XXXXXXXXXX公司 [****]年[**]月[**]日
文档修改记录
目录 1引言 (2) 1.1编写目的 (2) 1.2范围 (2) 1.3定义、首字母缩写词和缩略语 (2) 1.4参考资料 (2) 2项目概述 (3) 2.1产品描述 (3) 2.2产品需求 (3) 2.2.1功能需求 (3) 2.2.2性能需求 (4) 2.2.3可服务性需求 (4) 2.3用户及用户特点 (4) 2.4一般约束 (5) 2.5假设和依据 (5) 3用例描述 (5) 3.1用例1 (5) 3.2用例2 (6) 3.3用例n (6) 4外部接口需求 (7) 4.1用户接口 (7) 4.2硬件接口 (7) 4.3软件接口 (7) 4.4通信接口 (8) 5设计约束 (8) 5.1其他标准的约束 (8) 5.2硬件的限制 (8) 6属性 (8) 6.1可用性 (8) 6.2安全性 (9) 6.3可维护性 (9) 6.4可转移＼转换性 (9) 6.5警告 (9) 7其他需求 (9) 7.1数据库 (9) 7.2操作 (10) 7.3场合适应性需求 (10) 8附录 (10)
[说明：本模板中的蓝色字体与橙色字体为说明性文字，在最终提交的文档中请删除这些说明性的文字。] 1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者范围。 1.2 范围 说明： a．待开发的软件系统的名称； b．说明软件将干什么，如果需要的话，还要说明软件产品不干什么； c．描述所说明的软件的应用。应当： 1）尽可能精确地描述所有相关的利益、目的、以及最终目标。 2）如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。 1.3 定义、首字母缩写词和缩略语 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4 参考资料 列出要用到的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
需求分析方法 一需求分析概括 需求分析应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S＝｛D1，D2，D，…Dn｝ 问题域Di由若干问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di＝｛P1，P2，P3，…Pn｝ 问题Pi有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj＝｛F1，F2，F3，…Fk｝ 需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。在写需求说明书时，应该注意两个问题： 1.最好为每个需求注释“为什么”，这样可以让程序员了解需求的本质，以便选用最合适 的技术来实现此需求 2.需求说明不能有”二义性”，更不能前后矛盾。如果有二义性或前后矛盾，即要重新分 析此需求。 二需求分析方法论 第一阶段：“访谈式”
第一阶段是和具体用户方的领导层、业务层人员的访谈沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。 建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。 实现手段：访谈、调查表格 输出成果：调查报告、业务流程报告 第二阶段：“诱导式” 结合第一阶段的基本信息，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式，启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、习惯性。用户可以操作简单演示的DEMO，感受整个业务流程的设计合理性、准确性等等问题，以及提出改进意见和方法。 实现手段：诱导（拜访）、原型演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：“确认式” 此阶段在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段。这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。通过审查，提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归到需求分析报告中）
软件开发方向“成绩管理系统”软件需求规约 二零零八年十月
修订历史记录
目录 1 引言 (5) 1.1 目的 (5) 1.2 文档格式 (5) 1.3 预期的读者和阅读建议 (5) 1.4 范围 (6) 1.5 术语 (6) 1.6 参考文献 (6) 2 系统概述 (6) 2.1 概述 (6) 2.2 功能 (7) 2.3 运行环境 (8) 2.4 假设与依赖 (8) 3 系统特性 (9) 3.1 系统角色 (9) 3.2 学生管理 (10) 3.2.1 增加学生信息 (10) 3.2.2 修改学生信息 (10) 3.2.3 删除学生信息 (10) 3.2.4 导入学生信息 (10) 3.3 教师管理 (11) 3.3.1 增加教师信息 (11) 3.3.2 修改教师信息 (11) 3.3.3 删除教师信息 (11) 3.3.4 导入教师信息 (11) 3.4 课程管理 (12) 3.4.1 增加课程基本信息 (12) 3.4.2 修改课程基本信息 (12) 3.4.3 删除课程基本信息 (12) 3.4.4 维护课程学生信息 (12) 3.5 成绩查询 (13) 3.5.1 学生查询成绩 (13) 3.5.2 教师查询成绩 (13) 3.6 成绩分析与统计 (13) 3.6.1 考试成绩表 (13) 3.6.2 班级各科平均成绩表 (13) 3.6.3 年级成绩排名表 (14) 3.7 系统维护 (14) 3.7.1 数据字典维护 (14) 4 非功能性需求 (14) 4.1 性能需求 (14) 4.2 安全性需求 (14) 4.3 可用性需求 (15)
1.1主要步骤 遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。 需求涉及的方面有很多。 在功能方面，需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同用户需要通过系统完成何种操作等。 在性能方面，需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。 在运行环境方面，需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。 在界面方面，需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求，识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题，要满足哪些限制条件，这个过程就是对需求的获取。开发人员通过调查研究，要理解当前系统的工作模型和用户对新系统的设想与要求。 此外，在需求的获取时，还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如，多长时间需要对系统做一次备份，系统对运行的操作系统平台有何要求，发生错误后重启系统允许的最长时间是多少等。
遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求，开发人员应该采取科学的需求获取方法。在实践中，获取需求的方法有很多种，比如，问卷调查、访谈、实地操作、建立原型和研究资料等。 问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析，开发人员便可以得到一些有用的信息。采用这种方法时，调查问卷的设计很重要。一般在设计调查问卷时，要合理地控制开放式问题和封闭式问题的比例。 开放式问题的回答不受限制，自由灵活，能够激发用户的思维，使他们能尽可能地阐述自己的真实想法。但是，对开放式问题进行汇总和分析的工作会比较复杂。 封闭式问题的答案是预先设定的，用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理，但是会限制用户的思维。 访谈通过开发人员与特定的用户代表进行座谈，进而了解到用户的意见，是最直接的需求获取方法。为了使访谈有效，在进行访谈之前，开发人员要首先确定访谈的目的，进而准备一个问题列表，预先准备好希望通过访谈解决的问题。在访谈的过程中，开发人员要注意态度诚恳，并保持虚心求教的姿态，同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样，开发人员要根据用户的身份特点，进行提问，给予启发。当然，进行详细的记录也是访谈过程中必不可少的工作。访谈完成后，开发人员要对访谈的收获进行总结，澄清已解决的和有待进一步解决的问题。 关注用户的行为而不是他们的言语。
需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：SRS文档（system requirement Specification）；2.DRM文档；3. Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。 狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析 需求分析就是分析软件用户需求是什么。如果投入大量的人力，物力，财力，时间，开发出的软件却没人要，从发重新开发过，这种返工是让人痛心疾首的。（相信大家都有体会）比如，用户需要一个for Linux 的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发fox window的软件，当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不行找块豆腐一头撞死。 需求分析之所以重要，就因为他具有决策性，方向性，策略性的作用，他在软件开发的过程中具有举足轻重的地位。大家一定要对需求分析具有足够的重视，在一个大型软件系统的开发中，他的作用要远远大于程序设计。 二、需求分析的任务 简言之，需求分析任务就是解决“做什么”的问题，就是要全面地理解用户的各项要求并准确地表达所接受的用户需求。 需求分析的过程 需求分析的工作，可分为四个方面：问题识别、分析和综合、制订规格说明、详审。问题识别 就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些要求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求（做什么），性能需求（要达到什么指标），环境需求（如机型，操作系统等，）可靠性需求（不发生故障的概率），安全保密需求，用户界面需求，资源使用需求（软件运行是所需的内存，CPU等），软件成本消耗与开发进度需求，预告估计以后系统可能达到的目标。 分析与综合
软件需求分析说明书集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#
学生信息管理系统 需求分析说明书 1.引言 编写目的 确定学生信息管理系统功能的有效性需求；以供本系统的开发人员参考。 项目背景 开发软件名称：学生信息管理系统。 用户：教学办公室 项目和其他软件：系统的关系。 本项目采用客户机/服务器原理，客户端程序是建立在window NT系统上以 Java为开发软件的应用程序，服务器端采用Linux为操作系统的工作站，是采用Oracle 的为开发软件的数据库服务程序。 定义 学号：学校给学生的编号，用来区分各个学生的信息的中介。 课程名：学校开设课程的名字 Java+SQL：编写该系统的面向对象的开发语言和数据库语言。
参考资料 ⑴《Oracle从入门到精通》 ⑵《JAVA程序设计项目教程》 ⑶《数据库原理及应用》 ⑷《软件工程案例教程》 2．任务概述 目标 ⑴开发意图：由于学校的不断招生，现有的系统空间小，运行速度缓慢，操作过于复 杂，有的操作还不能执行，所以要开发本系统。 ⑵应用目标：学生信息管理系统将解决现有系统的空间不足，运行缓慢，操作复杂，操 作无效等问题。 运行环境 本系统采用C/S体系结构 操作系统：Microsoft Windows xp 支持环境：IIS 数据库：Oracle 软件设备：eclipse 内存：512 M以上 硬盘空间：40G以上 CPU: 233MHZ以上
内存：256M以上 硬盘空间：以上 假定与约束 使用本系统的用户群集中在 22-35 岁的年轻人，用来做学生信息的存储，对计算机的操作一般比较熟练。根据他们对本程序的认可、方便操作的程度，结合他们日常工作的频繁程度，系统每天操作完成一个功能点应该在 2- 10 次之间。用户对界面的友好性，有非常高的要求。本系统的规模比较小，并且将提供操作手册进行操作项的详细说明 （1）、Client/Server结构总体设计方案对它的约束：本系统做为Client/Server 结构的一个应用系统，不可避免的要受到Client/Server结构的约束。在其实施的各个阶段都要服从它的一些规划，包括功能设计、系统配置和计划。同时，由于信息的共享，机票预订系统还受到其它系统的信息约束。 （2）、人力、时间的约束：本系统开发过程中也要考虑到人力、资金和时间的约束。 （3）、技术发展规律的约束：计算机技术和产品的发展日新月异，将会给信息处理带来更多的手段，同时也会带来更加丰富的信息表达形式。例如图象和语音技术的进步，多媒体技术的发展，这些都要求系统在设计时考虑技术变化的可能性，为可能的变化预留一定的系统处理能力。 3．需求规定 对功能的规定 系统流程图：系统流程图是用户操作此系统的流程和各个用户能够操作的功能，如A-1就是一个系统流程图；用户有系统管理员，教师和学生，每个用户要进入此系统都要登录。每个用户有不同的功能，系统管理员有查询，增加，修改，删除，修改密码，设置权限等功能；教师有查询，修改密码和输入学生成绩的功能；学生只有查询和修改密码的功能。 A-1系统流程图 用例图：用例图是用来表示用户能使用的功能和权限。如图A-2表示系统管理员可以运用的功能，像修改密码，管理学生信息、成绩信息、课程信息、班级信息并且设置权
软件界面是人与计算机之间的媒介。用户通过软件界面来与计算机进行信息交换。因此，软件界面的质量，直接关系到应用系统的性能能否充分发挥，能否使用户准确、高效、轻松、愉快地工作，所以软件的友好性、易用性对于软件系统至关重要。目前国内软件开发者在设计过程中很注重软件的开发技术及其具有的业务功能，而忽略了用户对软件界面的需求，影响软件的易用性、友好性；对界面设计的研究也集中在界面设计技术、设计手段上面。软件开发人员在设计时以经验为参考依据，缺乏对实际用户需求的了解。而软件的友好性、易用性同用户特征紧密相联，同样的软件界面，不同用户可能有绝然相反的评价。因此分析用户特征、了解用户需求和操作习惯，是开发软件界面的必有步骤，必须引起足够重视。 本文讨论了一种界面需求分析的方法，意在探讨研究如何完成针对系统所有用户的界面需求定义,从而开发为用户所接受的界面。讨论该方法的目的在于帮助设计人员快速明确用户的界面需求，让用户充分参与到界面需求分析中，从而在最终界面需求说明中体现用户的思想，满足用户要求。 2、界面需求分析过程 2．1界面元素 通常一个软件界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式。其中，对用户工作效率有显著影响的元素包括：输入输出方式、交互方式、功能分布，在使用命令式交互方式的系统中，命令名称、参数也是界面元素的内容，如何设计命令及参数也很重要。影响用户对系统友好性评价的元素则有：颜色、字体大小、界面布局等，这种划分不是绝对的，软件界面作为一个整体，其中任何一个元素不符合用户习惯、不满足用户要求都将降低用户对软件系统的认可度，甚至影响用户的工作效率，而使用户最终放弃使用系统。围绕界面元素所要达到的设计目的是让最终用户能够获得美感、提高工作效率、易于操作使用系统。 目前在界面元素的选择、布局设计等方面的研究进行得较多,内容涵盖了人机工程学、认知心理学、、美学、色彩理论等方面的探讨。
XXXXXX 单位
XXXXXXX 项目
软件需求规格说明书
龙子湖网络科技
项目 文档 文档 ID 说明 作者 最后更新时间
项目名称 软件需求规格说明书
V1.2 *** 2011-10-20
版本更新概要 版本号 V1.0
V1.1
V1.2
时间 2011-10-02
2011-10-20
2011-11-08
更新人
更新摘要 移动 OA、车辆管理模块
需求容 移动政务资源管理系统
平台需求容 根据业务需求，电子公
文在线预览
项目负责人审核与确认 供应商：
职位
审核时间
审核意见(签字)
客户方：
目录
第一章 引言 ................................................................... 5
1 编写目的 .................................................................. 5 2 软件需求分析理论........................................................... 5 3 软件需求分析目标........................................................... 5 4 参考文献 .................................................................. 6
第二章 需求概述................................................................ 7
1. 项目背景 .................................................................. 7 2. 需求概述 .................................................................. 7 3. 条件与限制(可选)........................................................... 8 4. 移动办公系统结构........................................................... 8 5. 移动办公网络拓扑图......................................................... 9
第三章 系统功能需求........................................................... 10
1. 移动办公系统升级改造需求.................................................. 10 界面显示要求 ........................................................... 11 待办公文列表 ........................................................... 11 待办公文列表排序 ....................................................... 12 公文详细信息界面元素.................................................... 12 信息审批 ............................................................... 12 会议申请 ............................................................... 12 意见录入 ............................................................... 12 移动 ................................................................... 13 会议管理 ............................................................... 13 通知通告 ............................................................... 14 通讯录管理 ............................................................. 14
2. 车辆管理模块升级改造需求.................................................. 14 系统功能架构 ........................................................... 14 网络拓扑结构 ........................................................... 16
软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端，也是项目实施最重要的关键点。据有关的机构分析结果表明，我们设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。因此，一个项目的成功软件需求分析是关键的一步。 一、软件需求分析理论 如果我们用数学方法来描述软件需求分析，可以将一个应用软件定义为S，可能应用软件涉及功能性问题非常广，我们用抽象化理论分析，可以划分为各个功能域，可以用D1、D2、… Dn表示，那么，我们可以用一个表达式描述为S={D1，D2，D3，…Dn} 但是，功能域Di依然存在着有若干个问题P1、P2、P3、… Pm组成，并且每个功能对应于子系统中的一个软构件，我们可以表示为 Di={P1，P2，P3，…Pm} 同样，功能Pj有若干个行为F1、F2、F3、… Fk，每个行为对应于软构件中的实现方法 Pj={F1，F2，F3，…Fk} 一个软件包含了所有功能的集合，同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求，经过需求问题识别，进行分析、消化与综合，制订规格说明，评审，分为四个阶段，形成用户需求与设计同步，设计满足用户需求目标。 需求分析方法始终贯穿着吸收、同化、贯彻方法和手段，用商业化行为解决需求与实现中存在的矛盾，解决用户需求与商业化产品融通，解决规范与个性化追求。 二、软件需求分析目标 软件需求分析的主要实现目标： 1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整性，促使用户在软件设计启动之前周密地、全面地思考软件需