软件需求管理论文

【www.zhuodaoren.com--论文】

软件需求管理论文(一)
毕业论文管理系统需求分析

毕业论文管理系统需求分析

目录

1 引言 …………………………………… 1.1 编写目的 …………………………………… 1.2 项目背景 …………………………………… 1.3 参考资料 …………………………………… 2 项目概述 2.1 待开发软件的一般描述 2.2 待开发软件的功能 2.3 用户特征 2.4 运行环境 2.5 条件与限制 3 功能需求 3.1 功能划分 …………………………………… 3.2 …………………………………… 4 …………………………………… ……………………………………. .

1、 引言

1.1 编写目的

·开发软件的目的：在用计算机管理毕业设计和毕业论文的工作上，国外由于教育机制的不同，其相应的管理软件不能满足我们的需要，国内由于各种不同层次的学校管理制度的不同，也缺乏能够满足不同学校需要的管理软件，因此，在这种状况下，结合哈尔滨院自身对毕业设计和毕业论文管理规定，开发一个适合自己学校的管理软件，同时也是促进传统教学模式改革的一个方法。具有十分重要的意义和较大的实用价值 ·编写本软件说明书的目的：了解,提炼，分析和审查已收集到的需求信息，并确保所有相关人员都理解相关含义。

·软件需求说明书所预期的读者：1.2 项目背景

·待开发软件产品的名称、代码： ·任务提出者：王克朝

项目的相关人员：

1.3 参考资料

软件工程导论

2、 项目概述

的手工模式，首先，由符合指导资格的教师出题，然后再由教师指导学生选题，学生做完开题报告后，设计和论文的撰写由指导教师指导完成，中途对设计和论文进行中期检查，最后进行论文的批改、答辩以及论文的归档，在这一过程中，每一项工作一般都得教师与学生面对面交流，或者学生所做的设计和论文采用邮寄、E-Mail、电话等方式与教师进行交流。这种方式积极的一面在于教师和学生直接面对面的探讨和解决问题，但也存在着很多局限性，特别是随着Internet的出现和现代远程教育的发展以及现代本科教育模式的发展，继续采用传统手工管【软件需求管理论文】

理模式对毕业设计和毕业论文进行管理就显得费时，整理资料的工作量大，效率低，对于教学管理者来说难以及时准确地掌握毕业设计和论文的整体进展情况，给管理带来一定的难度，而这种情况的最终结果是导致毕业设计和毕业论文的质量难以保证，也没有充分利用无处不在的Internet优势和丰富的网络资源。【软件需求管理论文】

此软件可以实现教学管理信息化、网络化。采用该系统对高校本科毕业论文进行管理，可以解决手工选择毕业论文带来的消耗时间长、工作效率低、不公平等现象，极大地方便学生和指导教师，显著地提高了工作效率。

0层【软件需求管理论文】

软件需求管理论文(二)
企业需求管理论文

企业需求管理论文

摘要：大数据时代，数据为王。大数据作为一种理念，也作为一种方法，改变着需求管理的思维和途径。这种正被改变着的需求管理，正是企业模式变革与发展的推动者。

大数据时代到来！美国互联网中心指出，互联网上的数据每年将增长50%，每两年将翻一番，我们目前的数据有90%以上都是近几年产生的。除了互联网，无数安装在设备上的数码传感器也能产生诸如位置、运动、温度、化学物质等的海量数据。大数据时代的开启，影响着我们理解世界和在这个数据世界中生产和生活的方式，同时带来一场巨大的商业变革，将颠覆原有企业的运营思维和组织架构，加速重构新的价值链，建立新的行业影响力。

需求管理是集需求分析、需求判断、需求预测于一体的管理活动集合，需求管理水平的高低取决于整个需求链中各主体信息管理和经验判断能力及其整合的效果。需求管理对企业、尤其是传统企业有着重要的意义，它能够使企业的输入和输出相匹配，减少因两者差异而产生的成本和风险。然而，传统的需求管理往往出现较大偏差，无法最大程度地实现其意义。究其原因，无非是重视经验而非数据、收集数据杂乱无章、整理数据低效、预测方法单一等等。大数据时代的到来，为需求管理提供了新的思维和途径，与此同时，也对企业提出了更高的要求和更大的挑战。

一、需求管理基本逻辑的转变

一般地，我们认为需求预测发生偏差的根本原因在于信息不对

软件需求管理论文(三)
软件需求管理思考

　　摘 要：针对需求评审过程中存在的不容易记录和跟踪评审问题、需求的变更申请不能很好与需求条款相对应问题、需求管理工具中管理的需求文档不能直接进入软件配置管理系统导致需求文档的源头不唯一问题以及通过手工方式进行需求追踪的问题等，考虑到需求管理活动包含的需求变更管理与版本控制属于软件配置管理需要控制的核心要素，从理论上将需求管理与软件配置管理有机融合，以两者融合解决需求管理过程中存在的问题为出发点，在此基础上提出了一种新的需求管理模式，并将该模式通过嵌入式软件产品平台来实现，以有效解决需求管理过程中存在的问题。

　　关键词：需求管理；需求评审；需求变更；版本控制；需求跟踪
　　0 引言
　　Standish Group从1994年到2001年的CHAOS Reports证实导致项目失败的最多的原因就是“变更用户需求”[1]。因此避免失败和提高项目的成功率需要进行需求管理。
　　目前对需求进行管理主要是使用IBM Rational RequisitePro、IBM Rational Doors等工具或使用excel进行人工管理， 但对需求的变更管理和版本管理往往借助第三方工具（如IBM Rational ClearCase、IBM Rational ClearQuest），不能在同一个平台中对需求进行有效管理，导致相关技术文档的源头不唯一，需求追溯性变差，同时增加了管理成本。
　　1 需求管理过程概述
　　需求管理的主要活动包括需求确认（主要由用户和项目组共同对软件研制任务书和需求规格说明进行评审）、需求变更（包括需求更改和版本控制）和需求跟踪控制。
　　2 需求管理存在的问题
　　2.1 需求评审的问题
　　当前对需求的评审一般都是基于文档化的文件进行评审，评审的时候不容易记录问题对应的需求项，问题的提出人等信息。这带来的问题为：给手工记录带来了很大的压力；评审结束之后，很多问题不知下文；不能充分统计需求评审问题以便跟踪问题并作为组织改进的依据。
　　2.2 需求变更控制问题
　　当基于问题、客户新需求等对需求进行变更时，目前国内相关单位基本上都参考[2]提交更改申请，但更改申请往往是纸质的或是基于变更管理系统的，没有与需求管理工具进行集成（IBM Rational Doors除外），且对需求变更的描述一般比较粗，不能有效记录需求变更历史（如需求项、问题提交人、需求修改时间等信息）。
　　2.3 需求版本控制问题
　　目前业界内相关商业需求管理工具[3]（如IBM Rational Doors等）基本不具备或不能与版本管理工具进行集成，从而使得相关技术文档不能直接进入版本管理系统中，使得技术文档管理源头不唯一，可能导致各个系统中软件技术状态不唯一，增加了管理的难度。
　　2.4 需求跟踪问题
　　目前业界内很多相关单位通过手工方式使用excel进行需求追踪管理，导致需要额外存储需求跟踪矩阵，且记录不方便。 3 解决问题的方法
　　因此，需求管理的理想模式（见附图）是：在需求评审的过程中能够通过一个工具自动记录需求评审的问题，自动记录需求变更的历史并做好需求追踪、在时机成熟时将需求文档提交到开发库、受控库或产品库。为了实现该模式，在嵌入式软件产品平台中借助配置管理手段辅助需求管理，确保需求的变更控制、版本管理与配置管理融合的同时，解决2.1、2.2、2.3、2.4的问题。
　　3.1 有效的评审
　　针对2.1中存在的不能有效记录评审人、评审问题、问题落实情况、问题对应的需求项、分析统计问题等问题，在软件需求管理的过程中，相关人员在嵌入式软件产品平台上按附图对需求管理范畴内所有文档（软件研制任务书、需求规格说明、软件设计说明、软件代码、单元测试用例、部件测试用例、配置项/系统测试用例）进行项目级评审，对软件研制任务书、需求规格说明、配置项/系统级测试用例及项目级评审达不成一致意见的问题进行院级评审。在需求评审的过程中设置一名精通软件工程过程改进并从事过软件研发与管理的人员担任项目管理秘书，负责跟踪、协调评审过程中问题，并从评审问题中提炼相关内容纳入到组织的评审检查单中。
　　首先进行项目级评审。软件研制任务书、软件需求规格说明等需求文档（一个需求文档包含若干个需求项）的编制人首先按照[4]格式要求在嵌入式软件产品平台中进行需求定义（需求定义内容主要包括需求项名称、需求项内容），然后提交需求定义内容，使其转换为需求项列表（需求项列表主要内容包括每一个需求项唯一编号、需求项名称、需求项内容、版本（初始版本为1）、审查列表等信息）在评审人员的审查界面中显示。评审人员参考组织的评审检查单在审查列表中填写评审问题，并给出评审结论（通过或不通过）。对每一需求项，如果有一个人的结论为不通过，则该需求项评审的结论为不通过（其中初始结论为待审状态），否则为通过。对于不通过的需求项，如果编制人接受修改意见，则修改完成之后，所有评审人员对修改的需求项重新进行项目级评审直至问题关闭。对于编制人和评审人员达不成一致意见的需求项，则由项目管理秘书提交院级评审进行决策。
　　院级评审时机为项目级评审结束（包含项目级评审通过、项目级评审未通过但需要项目管理秘书提交院级评审进行决策）之后，对属于院级评审范畴内的内容进行评审。如果院级评审不通过，则按图1反馈问题给修改人进行修改，然后重新进行项目级评审和院级评审，直到通过。与项目级评审相比，院级评审需要院级型号副总师和用户参与评审。
　　在评审的过程中，通过在嵌入式软件产品平台中进行问题记录和跟踪，确保了被评需求文档的质量，并有利于组织过程改进。
　　3.2 需求与变更、版本紧密关联
　　对2.2、2.3中存在的需求管理与变更管理、版本管理分离的问题，相关人员在嵌入式软件产品平台中按图1对需求的变更与版本控制采取以下处理方式： 　　（1）对于提交项目级评审之前的需求项，文档编制人员在嵌入式软件产品平台中可以任意对需求进行修改，且不形成需求项版本；
　　（2）对于已提交项目级评审，未进行院级评审的需求项，文档编制人员可以对需求项进行修改，但每修改1次都会记录修改前后的状态，且当前需求项版本在原有版本上加1（如只修改了1次的需求项版本为2）。当所有的需求项都通过项目级评审之后（即需求文档具备提交开发库条件），需求文档编制人在嵌入式软件产品平台中提交入开发库申请，开发库配置管理员依据配置管理规定在嵌入式软件产品平台中对需求文档给出开发库配置标识（以便冻结状态，供软件测试人员进行单元测试、部件测试等）；
　　（3）对于项目级评审结束（包含项目级评审通过、项目级评审未通过但需要项目管理秘书提交院级评审进行决策）之后提交院级评审的需求文档，如果院级评审不通过，则文档编制人员修改需求项，系统自动记录需求项修改历史；如果院级评审通过（即需求文档具备提交受控库条件），需求文档编制人在嵌入式软件产品平台中提交入受控库申请，受控库配置管理员依据配置管理规定在嵌入式软件产品平台中对需求文档给出受控库配置标识（以便冻结状态，供测试人员开展配置项/系统测试等）；
　　（4）当需求文档入受控库或产品库之后，如果需求需要变更（含测试发现问题等原因需要更改的非新增需求，新增需求等），则文档编制人员必须提交需求变更申请并选择需要修改的需求项（说明更改原因、进行影响域分析等），并通过型号副总师审批之后，需要修改的需求项才处于可修改（对于非新增需求）或可评审（新增需求）状态。然后相关人员重新进行需求修改、进行项目级评审、提交开发库、进行院级评审、提交受控库、提交产品库操作等。
　　在需求的变更与版本控制的过程中，通过在嵌入式软件产品平台中融合需求管理与配置管理，解决了需求变更历史不能有效记录，需求文档不能直接进入软件版本管理系统导致源头不唯一可能产生的技术状态不唯一的问题。
　　3.3 基于平台的需求跟踪
　　对2.4中存在的用excel进行需求跟踪不利于记录的维护和存储的问题，通过在嵌入式软件产品平台中设置需求追踪功能，相关文档编制人只需在下游的需求项列表中选择上游的需求项并进行关联，系统自动建立任务书-需求规格说明-设计说明-代码-测试用例之间的需求跟踪矩阵并可随时查询。通过此方式解决了使用excel等进行追踪不方便管理的问题。
　　4 结语
　　本文针对业界内需求评审、需求的变更与版本控制等过程中存在的问题，从理论上将需求管理与软件配置管理（包括软件变更管理和配置管理）有机融合，并在此基础上创新性提出了一种新的需求管理模式，并将该模式通过工具来实现，确保了需求能够有效评审与跟踪，需求的变更和版本管理能够与软件配置管理业务有效融合， 使得企业能够高效进行需求管理，从而保证了软件产品的质量，并减少了管理成本。
　　参考文献：
　　[1]需求管理： IBM Rational 技术白皮书 [EB/OL]. [2004-08-01].http：//www.ibm.com/developerworks/cn/rational/r-rm/index.html.
　　[2]中国人民解放军总装备部. GJB 5235-2004， 军用软件配置管理[S]. 北京：总装备部军标出版发行部，2004.
　　[3]国内外需求管理工具比较 [R/OL]. [2014-07-11].http：//download.csdn.net/detail/kingr2014/7620925.
　　[4]中国人民解放军总装备部. GJB 438B-2009 军用软件开发文档通用要求[S].北京：总装备部军标出版发行部，2009.

本文来源：http://www.zhuodaoren.com/fanwen293949/

推荐访问:软件需求分析论文 软件项目需求管理