软件需求开发

软件需求开发（精选十篇）

软件需求开发 篇1

关键词：需求工程,需求开发,需求分析,需求管理

1 概述

需求工程在软件开发中是一个首当其冲的问题。如果没有一个清晰、完善的需求分析, 项目队伍或开发人员将为此付出不可估量的代价。有资料表明, 许多问题都是由于收集、编写、协商、修改软件需求过程中的失误而产生的, 诸如信息收集不全、交流不充分、文档不完善、需求不断变更等, 且有40%～60%的问题都是在需求阶段埋下的隐患。在软件规模不断扩大、应用领域不断拓展的今天, 软件开发的前期工作变得越来越重要。当然, 软件需求分析作为软件开发的第一步, 也是决定性的一步, 也就理所当然的左右了一个软件项目的成功与否。

2 需求工程一般模型

在讨论需求工程的一般模型时, 先来看下什么是需求工程。一般来讲, 需求工程就是指应用已证实有效的技术、方法进行需求分析, 确定客户需求, 帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科;它通过合适的工具和记号系统的描述待开发系统及其行为特征和相关约束, 形成需求文档, 并对用户不断变化的需求演进给予支持。需求工程可分为系统需求工程和软件需求工程。本文所要讨论的软件需求工程是一门分析并记录软件需求的学科, 整个软件需求工程研究领域可划分为需求开发和需求管理两部分, 如图1。

2.1 需求开发

需求开发一般包括需求获取、分析、编写文档、验证等阶段。

2.1.1 需求获取

需求获取是软件开发的第一步, 是通过调研, 获得清晰、准确的客户需求。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求, 分析者、开发者和客户就能探索出描述这些需求的多种解决方案。

需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境, 而这些问题与产品有关。对需求问题要进行全面考察, 不仅要考虑问题的功能需求方面, 也要考虑其非功能需求方面。所以, 需求获取是一个高度合作的活动, 并不是客户需求的简单拷贝。同时, 当进行需求获取时, 也应尽量避免受不成熟细节的影响。只有当这些细节被排除时, 才会使随后的设计过程畅通无阻。

2.1.2 需求分析

(1) 需求分析任务。

由于需求分析是软件开发的一个奠基性工作, 所以我们必须对它进行认真审视。需求分析阶段要完成具体明确的任务及就是最终形成一份开发方和用户认可或达成共识的需求规格说明书, 这也是软件开发中最为困难的部分—-即准确说明开发什么、系统必须做什么。当然, 最为困难的概念性工作便是编写出详细的技术需求, 这包括所有面向用户、面向机器和其它软件系统的接口。如果一旦做错, 将最终会给系统带来极大损害, 且以后再对它进行修改也非常困难。可以说需求文档在开发过程中起着指导作用。

(2) 需求分析过程。

需求分析的过程就是将收集到的调研信息加以处理并理解他们。

把调研信息分成不同的类型, 同时将客户需求同可能的软件需求相联系。然后将客户信息结构化, 编写成文档和示意图, 作为提交给让客户代表评审并纠正存在错误的一个书面文档。重复详述需求, 以确定用户目标和任务, 并把它作为使用实例。进行深入收集和分析, 消除任何冲突或不一致性, 拟定出详细的使用实例, 使其融合到必要的功能需求, 为编制测试用例作准备。

进行需求分析时, 尽量理解用户用于表述他们需求的思维过程, 充分研究用户执行任务时做出决策的过程, 并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。避免使用用户提供的需求细节, 因为会给随后的设计过程带来不不要的限制, 用周期性地检查需求获取, 以确保用户参与者将注意力集中在今天所讨论的话题适合的抽象层上。此外, 不可忽视非工程需求的描述, 它表明了系统的限制和用户对质量的期望。

为了更好和用户交流, 最初的屏幕构思有助于描述开发人员对需求的理解, 可以利用Visio来设计界面。如果项目开发周期允许, 可以开发原型来交流和确认。随后针对用户的需求说明细化用户界面设计, 有助于对需求达成共识, 为以后的设计工作带来便利。

(3) 需求分析方法。

通常的软件需求分析方法有三种:面向功能分析、面向对象分析、面向数据分析。

面向功能分析是最早的分析方法, 它将软件需求当做一颗倒栽的功能树, 从上到下, 功能由粗到细。其功能分析体现了自顶向下、逐步求精的思想, 适合于结构化分析、结构化设计、结构化编程等传统式软件工程思想。

面向对象分析, 也从系统的基本功能入手, 每一个功能对应一个对象, 然后将对象上升为类, 再用对象总线或对象框架将类组装起来, 用以表示用户需求。CASE工具Rational Rose用Use case来进行需求分析, 所有Use case的集合, 就是系统的需求。

面向数据分析, 就是面向元数据和中间数据分析, 对开发人员来讲, 就是要将这两类数据及其之间的关系弄透。

2.1.3 编写文档

需求开发的最终成果是:客户和开发小组对将要开发的产品达成一致协议。协议综合了业务需求、用户需求和软件功能需求。开发人员必须编写从使用实例派生出的功能需求文档, 还要编写产品的非功能需求文档, 包括质量属性和外部接口需求。

一般可以用好的结构化和自然语言、建立图形化模型、编写形式化规格说明等方法编写文档。文档不仅是系统测试和用户文档的基础, 也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。而且作为产品需求的最终成果必须具有综合性:必须包括所有需求。开发者和客户不能作任何假设。

2.1.4 需求验证

再完成文档的编写后, 并不能说已经完成了需求开发阶段的工作。只有以结构化和可读性方式编写这些文档, 并由项目的风险承担者评审通过后, 各方面人员才能确信他们所赞同的需求是可靠的。其验证的手段主要有软件评审和软件测试, 在文档编写后, 必须对需求进行评审以验其质量。软件测试也是对需求的第二次验证。

需求验证主要围绕编写文档的质量特性展开, 这些质量特性包括正确性、无二义性、完整性、可验证性、一致性、可修改性和可跟踪性等。

2.1.5 需求分析原则

有资料表明:频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求文档和不完善的需求分析是导致需求过程中软件成本估计极不准确的主要因素。所以, 开发人员一般应当遵循以下一些原则。

(1) 有足够用户参与 。

在实施项目时, 若无足够的用户参与, 系统人员获得的需求是片面的, 不完整的, 这样系统在需求之初就埋下风险。

(2) 控制需求变更范围 。

在开发中若不断地补充需求, 项目就越变越庞大以致超过其计划及预算范围。所以, 必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明, 并将此说明作为评价需求变更和新特性的参照框架, 以达到把需求变更范围控制到最小, 有利于减少因变更导致软件质量的下降。

(3) 确认需求。

模棱两可是需求规格说明中最为可怕的问题。模棱两可的需求会使不同的风险承担者产生不同的期望, 它会使开发人员为错误问题而浪费时间, 并且使测试者与开发者所期望的不一致。如果这种不一致性直到项目后期才被发现, 那时付出的代价将会很惨重。所以, 需求的确认非常重要。

(4) 不要画蛇添足。

指开发人员增加自己觉得一些用户欣赏但需求规格说明中并未涉及的新功能, 但往往这并不能获得用户的认可。开发人员应努力使功能简单易用, 而不要未经客户同意, 擅自脱离客户要求, 自作主张。

当然除了以上提到的, 还包括不要过于精简规格说明、不要忽略用户分类、要准确的调研、分析、计划等。

2.2 需求管理

软件需求的最大问题就是需求不断的变更, 同时也是软件开发之所以困难的主要根源, 因此有效的管理需求是项目成功的基础。而且, 管理问题是贯穿于整个软件开发周期中的。

需求管理是在工作进程中维持需求约定集成性和精确性的所有活动。一方面, 需求管理要保持软件需求与客户需求之间的一致性, 要保持软件开发过程中的其它系统元素以及活动与软件需求的一致性。另一方面, 软件需求是受控的, 也就是说在给定时间使用工作产品的版本是已知的 (版本控制) , 并且以受控的方式引进改革 (变更控制) 。需求管理的任务是分析变更影响并控制变更过程, 主要包括变更控制、版本控制和需求跟踪等活动。

2.2.1 需求变更控制

对大多数项目来说, 需求的改进是合理的且是不可避免的。新的开发技术和项目目标的调整等都可能产生需求的变更, 但是如果不对需求变更的范围加以控制, 将会使项目陷入混乱, 甚至导致软件开发的失败。Capers Jones曾在报告中声称需求变更对80%的管理信息系统和70%的军事软件项目造成风险, 因为迟到的需求变更会对已进行的工作有较大影响。

(1) 需求变更的影响分析。

需求变更贯穿于软件开发的全过程中, 不处理好需求变更, 将会障碍软件的开发。它包括影响软件质量及开发进度、影响文档和代码的一致性、影响开发者和用户的合作关系等。

(2) 处理需求变更的原则。

要正确的处理需求变更, 必须采用规范的变更管理过程。如下面提到的, 必须建立需求变更控制机制;增强系统对需求变更的应变能力;选择合适的客户经理;提高用户的认识水平;采用先进的需求管理工具等。

(3) 需求变更解决方案。

引起需求变化的主要原因有:未受控制的需求变更、遗漏的需求、与用户交流不够、编写文档考虑不周、低效的需求分析等。针对以上问题, 可以采用如图2的方案进行解决。

2.2.2 需求文档版本控制

版本控制是管理需求的一个必要方面, 它保证在需求文档中记录和反映所有的需求变化。需求文档的每一个版本都必须统一确定, 组内每个成员必须能够得到需求的当前版本, 需求变更应该及时通知到项目开发所涉及的人员。每一个公布的需求文档应该包括一个修正版本的历史状况, 即变更内容、变更日期、变更人姓名、变更原因等。

本文建议在经过每一次需求变更及确认后, 项目管理者可以给每一次变更的需求设定一个统一的版本号。每一次变更后, 版本就升级。这样可以方便、快速、有效的进行软件开发, 同时也随时可以查到客户新增的哪些功能。

2.2.3 需求跟踪

需求跟踪就是将需求与系统设计元素、编码、测试等阶段的工作成果与需求文档进行比较, 建立与维护“需求文档—设计文档—代码—测试用列”之间的一致性, 确保产品依据需求文档进行开发, 图3表示软件开发过程中需求的跟踪关系。当需求发生变化时, 使用需求跟踪可以确保不忽略每个受到影响的系统元素, 需求变更的准确实施可以降低由此带给项目的风险。

一个管理系统的需求跟踪通常应该满足:

①能够完整地定义需求之间的各种关系, 并提供可视化表示方式;

②在需求变更时, 系统能够按照所定义的需求跟踪链, 跟踪到所有受影响的需求。同时, 管理人员也需要进行需求状态跟踪, 以了解项目工程进行到了何种程度, 从而对项目进度进行控制。

2.2.4 需求管理工具

当然, 需求管理人员不可能用手工来管理软件开发, 还必须得用到一些管理工具。因为采用需求管理工具, 可以提高需求管理工作流程的自动化程度, 使需求管理可以在项目实施过程中得到有效的排行。

目前, 需求管理工具还是比较多的。例如, CA公司的CA-Super Project & Project Software、Development公司的Qwiknet Professional、Rational公司的Analyst Studio需求工作包等。需求跟踪工具有, LMSC公司的ARTS (The automated Requirement Traceability System) 、TOOR (Traceability of Object-Oriented Requirement) 、Remap系统、RETH和Radix工具等。

3 总结

软件开发人员应充分认识到需求工程在软件开发过程中的作用。如果没有一个准确、清晰的软件需求工程工作, 将给项目队伍或软件公司带来不可估量的损失。本文从需求工程的过程各阶段的作用来叙述, 讨论了以后研究的重点还应放在需求分析、需求管理问题的研究上。当然, 必须理论联系实际, 需求工程现状中另一明显的不足是理论解决方案通常是在对实际问题简化的基础上得到的, 理论研究和实践脱节。要获取需求突破, 改善需求工程的开发效率和质量, 主要的一点就是探索有效的解决途径, 缩小理论与应用之间的鸿沟, 使开发出的系统与应用领域相匹配。

参考文献

[1]曹伟.如何进行软件需求分析, 中国系统分析员, 2002 (3)

[2]Wiegers K E.陆丽娜, 王忠民, 王志敏等译, 北京:机械工业出版社, 2000

[3]黄怡强.浅谈软件开发需求阶段的主要任务, 中山大学学报论从, 2002, 22 (1)

[4]姬晓鹏等, 需求管理的一个系统解决方案[A].计算机工程, 2003.

[5]卢梅, 李明树等.软将需求工程—方法及工具评述[A].计算机研究与发展, 1999, 36 (11)

[6]刘小波等.软件系统需求变更影响分析及解决方案[A].华南理工大学学报 (自然科学版) , 2002, 30 (4)

软件开发需求分析[小编推荐] 篇2

 用户注册和登录：为用户提供注册、登录、找回丢失密码、修改个人信

息等功能。

 图书信息查询及管理：对信息进行灵活的分类、存储，方便用户迅速从

少则几万，多则几十万甚至上百万种图书中找出自己所需图书。

 购物车管理：用语存储用户选择好的图书，完成购物后可以自动生成订

单以供管理者进行管理。

 订单管理：为用户提供订单查询功能，同时为管理者提供订单查询功能

及处理功能。

软件需求开发 篇3

【摘 要】本文通过介绍炼钢厂开发MES系统实施过程中通过需求分析确立明确系统开发目标、解决炼钢MES开发不同阶段需求动态变化难题，阐述软件生命周期中需求分析阶段的重要性。

【关键词】软件生命周期；需求分析；炼钢ME S

【中图分类号】F406.2【文献标识码】A【文章编号】1672-5158（2013）02-0383-01

【Abstract】T his paper introduces the development of MES for steelmaking plant in the process of implementation to establish a clear system development goals， to solve the steelmaking MES of different stages of development requirements of dynamic problem through the analysis of demand， explains the importance of the Requirement analysis in the Systems Development Life Cycle.

【Key words】Systems Development Life Cycle； Requirement Analysis； Steelmaking MES

0.引言

钢铁行业产销一体系统是一个大型的复杂信息化系统，由行业自身生产复杂性决定，钢铁产品需要经过多工厂、多工序联合制造和大规模定制生产才可达到交货目标，生产特点决定炉次、浇次、轧次要进行规模组织，同时遵守复杂工艺约束，生产准备还要兼顾物料需求和能源需求。大型信息化系统由软件平台、硬件平台、软件系统、数据库系统、网络系统等子系统组成。炼钢是整条钢铁生产链承上启下的环节，炼钢MES制造执行系统更是整个信息化系统至关重要的中间层，炼钢MES作为一套软件系统它将面临软件生命周期的各个阶段难题，软件生命周期主要包括：需求分析、概要设计、详细设计、程序设计、调试与测试、系统安装与部署。本文通过详述炼钢MES开发过程中需求分析阶段遇到的难题和解决方案，说明需求分析在软件生命周期中的重要作用。

1.概述

需求分析是指对要解决的问题进行详细分析，对于待开发的炼钢MES即理清炼钢厂与各轧钢产线、炼铁厂、原料供应单位、能源供应单位等业务关系，炼钢MES需求分析要解决炼钢各相关单位的业务问题以及问题的来龙去脉。需求分析是一项重要工作，通常被认为是系统开发最困难的工作，因为在软件生命周期中需求分析阶段、设计阶段、编码阶段、测试和集成阶段、系统运营阶段中，其他4个阶段都是面向软件技术，通过技术手段即可解决，只有需求分析阶段是面向用户，各关键用户都本着各厂利益出发，系统开发如果兼顾平衡即将损失开发效率，且各厂关键用户多数只熟悉各自业务活动和业务环境，系统开发过程中很难找到一个覆盖全部业务领域的专家，因此系统开发的需求分析阶段面临以下几个难点：关键用户之间的协调、用户需求是动态变化的、MES系统开发不同阶段需求变更代价呈线性增长。以下将结合炼钢MES开发过程遇到的实际问题来探讨软件需求分析方法。

2.软件需求分析

软件需求分析中的关键就是展开分析、发现问题、解决问题，是为能够将系统错误和漏洞在需求分析阶段发现并解决，使开发的成本收益比达到最大。炼钢MES需求包括：问题定义、可行性研究及软件计划。

2.1 问题定义

炼钢MES开发的第一步就是进行问题定义，问题是指用户的基本要求，问题定义实际上就是了解MES系统关键用户们到底要建立什么系统，并确定下一步应该做什么。因此，问题定义的来源是用户。系统开发初期由炼钢厂和各轧钢厂工作人员组成关键用户团队，各厂关键用户在问题定义阶段必须解决的关键是：系统要解决的问题是什么？通过问题定义阶段的工作，系统分析应该提出关于问题性质、开发目标等并形成书面报告。这一阶段的分析应站在较高的角度去抽象、概括所要做的事，不拘泥于问题实现的细节。尽管各厂关键用户旨在维护各分厂利益总是纠结于某些细节，但软件需求分析在这一阶段必须居高临下鸟瞰整个系统全貌，协调各方对问题取得一致看法，最后出具一份各方都满意的文档，促使各厂负责人同意开发工作继续进行，然后炼钢MES开发工程转入软件需求分析下一个阶段：可行性研究。

2.2 可行性研究

炼钢MES开发过程中，并不是所有问题都有简单明显的解决办法，许多问题不能在预定的系统规模之内解决。如果问题没有可行的解决办法，那么花费在此的时间、资源、人力和经费和都是不合理的，应该在此阶段予以避免。可行性分析是在问题的目标和约束之间的一种权衡，可行性研究的目的在于用最小的代价确定关键用户们所提出的问题是否可以解决，系统目标和规模是否现实，权衡后决定是修改目标或放宽约束。软件设计以炼钢厂关键用户期望通过MES系统实现的目标和作用范围为依据提出一种以上设计方案，从技术可行性、经济可行性、操作可行性等方面进行比较，并选出综合得分最优方案。关键用户需求是动态变化的，对用户要求的功能、性能以及限制条件进行分析，是否能够做成一个可接受的系统，并判断系统操作方式在关键用户组织内是否可行。

2.3 软件计划

关键用户同意可行后开始拟定软件计划，计划是为了将炼钢MES成功开发所需做的工作、需要的资源、需要的工作量以及开发进度进行合理安排。由于炼钢MES开发是公司产销一体系统一个子系统，因此炼钢MES开发进度要符合整个产销系统时间要求，例如：炼钢MES何时开始实施，何时结束，在与铁前MES、轧钢MES或物流系统等不同系统在时间周期上如何衔接等。进度计划是软件计划中最为重要的部分，它将对软件项目的开发产生重大影响，在炼钢MES软件计划阶段使用了工程网络图、Gantt图、任务资源表等软件进度控制手段。软件计划另外一个重要因素是指定用户分工、明确责任，此时，各厂关键用户发挥重要协调作用，不仅要推动本厂软件计划进行，还要配合其他产线计划。

3.结束语

综上所述，炼钢MES开发过程中软件需求分析之所以重要是因为它具有决策性、方向性、战略性作用，尤其在炼钢MES这种业务复杂、上下衔接系统较多的软件开发项目中，理清各关键用户问题，并找到彼此平衡的解决方法，其作用要远大于程序设计。

参考文献

软件需求开发及工程实践 篇4

随着软件规模的不断扩大, 应用领域的不断扩展, 软件开发的前期工作变得越来越重要, 软件需求开发是软件开发的第一步, 同时也是决定性的关键工作。目前, 80%以上项目失败的根本原因是需求不清楚, 最终导致产品的反复修改, 需求开发阶段隐藏的Bug会随着后续阶段工作的开展, 相应的Bug数会出现倍增效应, 因此, 需求分析是否彻底与成功直接影响到软件开发的质量。需求开发的目的在于产出并分析客户、软件产品及产品组件的需求, 这些需求明确相关干系人的需要, 包括与产品生命周期各阶段及产品属性有关的需要, 也包括选择某设计解决方案而产生的约束限制条件等。需求开发一般包括需求的获取与分析、需求确认、编写文档等阶段, 本文将从以上几个方面分别阐述, 重点讲述在工程实践中编写需求文档时客户需求与产品需求的区别与方法[1,2,3]。

2 需求的获取与分析[4,7,8]

需求获取是通过调研, 获取清晰、准确的需求信息。获取需求是软件开发中最困难、最关键、最易出错及最需要交流的工作, 需求的获取只有通过与客户有效的合作才能成功, 对需求问题要进行全面考察, 不仅要考虑问题的功能需求方面, 也要考虑其非功能需求方面。需求获取是一个高度合作的活动, 并不是客户需求的简单拷贝。

分析需求的过程既是通过识别开发场景建立并维护必要的功能定义, 分析需求项以确保其是否必要和充分, 其过程包括:

分析干系人的需要、期望、限制及外部接口, 以移除矛盾, 并总结成相关主题;

分析衍生需求, 以决定是否满足更高层需求的目标;

分析需求以确保其是完整、可行、可实现及可验证的;

识别对成本、进度、功能、风险或绩效有重大影响的关键需求;

分析操作观念及场景, 以调整客户需要、限制及接口, 并发现新的需求;

简单地说需求分析过程最终确定的是对目标系统的综合要求, 并提出这些需求的实现条件, 以及应达到的标准, 也就是解决要求所开发的软件要做什么, 做到什么程度。

客户需求和产品需求因需求的基础不同, 获取和分析的方式也各不相同。

2.1 客户需求

开发客户需求是指收集干系人 (例如:客户、最终使用者、供应商、配置人员、测试人员等) 的需要、期望、限制及接口, 并转换成客户需求, 用于产品需求的开发, 获取客户需求的方法包括:

诱导, 诱导技术包括有技术展示、问卷调查、访谈、操作审查、原型和模型、头脑风暴、试用版本的试用、使用案例等, 诱导要积极识别尚未经客户明确提出的新增需求, 这些需求来源一般包括有经营策略、标准、环境要求、技术、现有产品或产品组件 (可复用产品组件) ;

收集关键人员的需要;

转化关键人员需要、期望为客户需求, 把相关干系人的各种输入, 经过合并, 确保无遗漏的信息, 以及解决冲突等过程, 并记录为客户需求, 获取的客户需求还包括与验证和确认有关的需要、期望和限制。

在实践中, 需求开发工作者经常会忽略执行验证和执行确认时的客户限制, 造成后期验证阶段还要进行需求的重大变更, 给项目的进度、成本等带来很大的损失, 为确保需求开发的充分性, 所有与产品生命周期相关的过程都应考虑, 并及时地进行决策。另外一些客户的隐形需求经常被忽略, 善于去引导客户, 发现其潜在的隐性需求也会规避很多的需求变更。

2.2 产品需求

开发产品需求是指在客户需求的基础上, 进行进一步的细化分析, 并衍生成更精确的需求, 用于产品开发, 其过程包括:

建立产品与产品组件需求, 以客户需求为基础, 建立并维护产品组件需求;

强调对客户、经营、项目目标以及相关属性的满足, 同时产品需求还应分析是否存在因设计决策引入的衍生需求;

识别接口需求, 即定义功能之间 (或对象之间) 的接口, 必须识别产品和产品组件的内部接口和外部接口 (例如:功能分割或对象之间的接口) 、开发已识别的界面需求等。

衍生需求是经常容易被忽略考虑的, 而技术的选用必定会引进其他的衍生需求, 衍生需求考虑是否充分会直接影响到后期的产品开发进度。

在实践中, 需求开发人员经常会把用户需求和产品需求混为一谈, 而实际上两者是有实质的不同, 一是客户需求是以客户术语的形式表示, 且以较不具技术的方式描述, 产品需求则是以专业术语的方式表示这些客户需求, 以用来进行设计的决策, 二是用户需求是软件产品确认的依据, 而产品需求则是软件验证的依据。

3 确认需求[5,6]

确认需求一方面是为了保证需求符合客户的期望, 没有冲突和二义性, 二是为了需求得到各方面的同意, 以保证需求在项目过程中顺利进行。确认需求包括的方法有:

分析需求以识别最终产品是否存在不能在使用者环境下运行的风险;

以产品展示的方式 (如:原型、仿真、模型等) 获得相关需求人员的反馈, 以确保需求的足够性和完整性;

当设计成熟时, 在需求确认环境下进行设计的评价和度量, 以确定偏差, 并找出未说明的需要和客户需求。

确认需求的环节决不能省略, 通过需求的确认环节, 进一步确认需求是否满足相关干系人的需要和期望, 最大程度地减少需求变更。

4 需求文档

需求开发的最终成果是将获取并确认的需求文档化, 需求文档不仅是系统测试和用户文档的基础, 也是设计和编码的基础, 作为产品需求的最终结果必须具有综合性, 且包含所有的需求项。

5 需求开发的工程实践

在工程实践中, 参照CMMI模型RD过程域, 结合本企业实际开发的情况, 在定义产品生命周期时, 将需求分析定义在两个阶段进行, 即用户需求分析阶段和方案设计阶段, 产出的成果物分别是软件技术规格书和软件需求分析说明书, 这两个成果物在软件开发V模型的对应位置如图1的虚线框所示。

5.1 软件技术规格书

软件技术规格书是依据输入的用户需求相关文件, 对项目产品的用户需求进行分析。

通过既有的产品原型向用户进行演示与需求讲解, 以获得对需求的确认;建立需求跟踪矩阵, 对分解出的用户需求开始进行纵向、横向跟踪。

技术规格书内容包括软件的功能要求、性能要求、接口要求、RAMS要求、使用条件、验证测试要求、兼容性要求、服务培训要求等。

5.2 软件需求分析说明书

软件需求分析说明书是依据软件技术规格书, 对软件需求进行分析和分解。

对操作逻辑相关需求, 编制软件操作说明, 对有显示界面相关需求的编制软件用户界面说明。

软件需求分析说明书的内容包括功能需求、数据流程图、软件界面简略图、操作说明、状态迁移、软硬件接口、RAMS要求、约束条件等。

软件需求分析的目的是详细界定待开发软件的边界, 从而可以进行下一步工作——软件结构设计, 对于一个典型的单CPU上的全部软件来说, 边界如图2所示。

软件需求是进行软件验证的依据, 为便于软件验证, 需求分析说明书中的内容一定要具有可验证性, 对于软件需求分析说明书的不同部分, 可验证性的要求也是不同的, 详细的情况如下:

1) 用户界面

达到可以作为使用手册使用的程度;

定义出具体的每个界面和界面间迁移的事件;

定义出每个界面中控件的颜色、大小等详细信息。

2) 功能需求

定义出每个功能的使用过程和计算公式。

3) 状态迁移

明确每个状态及状态迁移的事件、时间等。

4) 可用性、可靠性、可维护性、安全性

定义具体的方法或者度量的指标。

5) 操作说明

定义硬件控制寄存器的具体参数;

定义硬件端口输出和输入波形。

6) 硬件信息、硬件接口

定义硬件的接口类型和数量。

7) 通信协议

定义协议的名称、格式、内容等。

5.3 技术规格书与需求分析说明书的异同点

在开发过程中, 若是纯软件立项的项目则通过用户需求分析总结出软件技术规格书, 若软件属于某系统或部件的附属产品否则是由系统、部件的开发人员出具软件技术规格书, 软件开发人员再依据软件技术规格书进行软件需求分析, 编写出软件需求分析说明书。

这两个文档在开发过程中的作用是不一样的, 不能够省略任何一个, 也不能互相替代, 其主要的区别是:

1) 软件技术规格书是从客户的业务角度出发;

软件需求分析说明书是从实现产品的技术出发。

2) 软件技术规格书是使用客户术语进行描述;

软件需求分析说明书是使用软件技术术语进行描述。

3) 软件技术规格书是基于客户环境和水平;

软件需求分析说明书是基于业界主流的环境和发展。

4) 技术规格书指导用户验证;

软件需求分析说明书指导软件验证。

下面以性能要求和RAMS要求为例具体说明其编写方法的不同。

1) 性能需求

软件技术规格书示例:系统能够快速启动;

软件需求分析说明书示例:系统启动时间<10s。

2) RAMS要求包括可用性、可靠性、可维护性、安全性。

(1) 可用性需求:描述软件使用上的便利性要求, 仅仅考虑软件使用上的要求, 而不是结构上的要求。

软件技术规格书:软件要方便操作和使用。

软件需求分析说明书:提供API编程参考手册、允许二次开发应用人员配置硬件端口 (针对平台软件) ;可以进行必要的参数配置 (针对嵌入式产品软件) ;提供用户手册和安装说明 (针对PC软件) 。

(2) 可靠性需求:描述软件使用上的稳定性要求。

软件技术规格书:平均无故障时间为1万h。

软件需求分析说明书:软件验证缺陷率=0.1个缺陷/KLOC

(3) 可维护性需求:描述软件使用时升级和诊断的恢复要求。

软件技术规格书:软件要便于维护, 可通过以太网或串口下载和上传文件。

软件需求分析说明书:通过LOG文件进行故障记录、出现故障时, 把故障码发送到显示器显示, 允许通过U盘更新程序 (针对嵌入式软件) , 用户可以进行数据库备份和恢复功能 (针对PC软件) 。

(4) 安全性要求:描述软件使用时保密和防范生命财产损失的要求。

软件技术规格书:软件要有一定的安全防护考虑。

软件需求分析说明书:一个部件发生故障是通过软件进行隔离;更新程序时输入密码;按照适用人员级别不同允许使用不同的功能。

6 结论

需求开发模型与企业实际业务目标的结合, 可有效地帮助企业规范需求开发流程。

提高需求开发的效率, 减少需求文档的矛盾与冲突, 便于软件的测试验证, 从而实现了软件产品质量的提高。本文介绍的方法是笔者在实际工作中得到的一些过程经验, 鉴于CMMI模型的理念是不断地进行过程改进, 需求开发过程还需要同企业的快速发展而不断地进行改进和优化。

参考文献

[1]陈宏烨, 赵文刚.基于软件开发的需求开发及需求管理[J].甘肃科技, 2008, 24 (2) :31-34.

[2]刘家雷.评述需求工程及其验证[J].和田师范专科学校学报, 2006, 26 (4) :170-171.

[3]黄怡强, 郭钦祥, 等.浅谈软件开发需求分析阶段的主要任务[J].中山大学学报论丛, 2002, 22 (1) :262-265.

[4]何新贵.软件能力成熟度模型CMM的框架与内容[J].计算机应用, 2001, 21 (3) :2-4.

[5]杨海平, 黄会民.软件开发需求工程研究[J].信阳农业高等专科学校学报, 2005, 15 (1) :44-45.

[6]王玲.软件项目中的需求开发和管理[J].长沙通信职业技术学院学报, 2005, 4 (2) :63-67.

[7]杨一平.现代软件工程技术与CMM的融合[M].北京:人民邮电出版社, 2002.

需求分析在软件开发中的重要性 篇5

摘要：

“需求分析”,就是对需要解决的问题进行详细分析,弄清楚需要解决的问题。开发人员需要了解顾客的需求,然后体现在软件中。如果说软件开发过程中,开发人员需要了解自己做什么,顾客需要告诉开发人员自己需要什么,而需求分析就是连接开发人员和顾客之间的重要纽带。只有真正理解顾客的需求,才能设计出顾客所需要的软件。

在过去很长一段时间,开发人员的认为需求分析是整个开发过程中最简单的一个环节。然后越来越多的开发人员认识到它才是整个开发过程中的核心部分。正所谓“磨刀不误砍柴工”。只有真正理解了顾客的需求,才能顺利开发出顾客真正需要的软件。如果一味追求进度,而忽略需求分析,很可能南辕北辙,开发变得毫无意义。

关键字：需求分析，详细分析，开发过程，进度，开发人员。

一、绪论

随着计算机在日常工作中的普及，软件开发行业作为其必不可少的组成部分，被人们所认可。在我国，软件行业日渐成熟，小作坊式的开发形式，已经不能满足我国对于软件规范化、实用性的要求，软件开发流程化及各个职能部门工作的有效划分和正确协作，是现在软件行业面临的一个较大的问题。软件需求分析是软件开发的出发点，为设计起到指导性作用，所以需求分析在软件行业及开发流程中起着非常重要的作用。

“需求分析”,就是对需要解决的问题进行详细分析,弄清楚需要解决的问题。开发人员需要了解顾客的需求,然后体现在软件中。如果说软件开发过程中,开发人员需要了解自己做什么,顾客需要告诉开发人员自己需要什么,而需求分析就是连接开发人员和顾客之间的重要纽带。只有真正理解顾客的需求,才能设计出顾客所需要的软件。

在过去很长一段时间,开发人员的认为需求分析是整个开发过程中最简单的一个环节。然后越来越多的开发人员认识到它才是整个开发过程中的核心部分。正所谓“磨刀不误砍柴工”。只有真正理解了顾客的需求,才能顺利开发出顾客真正需要的软件。如果一味追求进度,而忽略需求分析,很可能南辕北辙,开发变得毫无意义。

一、什么是软件需求分析

通俗地说，软件需求分析是解决做什么，怎么做的问题。告诉客户及开发人

员，需要实现哪些功能，以何种方式，在什么平台去进行操作，开发结束后，应交付哪些东西。

需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.(这个问题是最典型也是最常见的,现在这个问题一般很好避免,都知道项目的一些敏感性的东西,例如想会有哪些地方设计的不好可能导致以后的使用出现BUG.)

二、需求分析的任务

简言之,需求分析的任务就是解决“做什么”的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.(一)了解顾客的要求

这是需求分析的重点任务,也是最基本的任务。只有正确了解、理解顾客的要求,才能顺利完成需求分析。

(二)分析系统的数据要求

软件产品是指软件开发商根据市场需要开发的、具有一定适用性和潜在客户的、可销售的软件成品。它区别于应特定客户需求或根据订单开发的软件商品，通常应具有更高的通用性和适应性。但它的通用性和适应性不是轻而易举就能达到的。要实现软件的产品化，就必须在软件产品的设计上下一番功夫。

本文结合一个“多媒体远程教学系统”实例，探讨软件产品设计中的一些经验与看法。

三、需求分析的过程

需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.（一）、问题识别

就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.（二）、分析与综合逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).（三）、制订规格说明书

即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.（四）、评审

对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。

四、需求分析的方法

需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。

在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。

追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.五、总结

软件:需求仍将持续旺盛 篇6

经济放缓不影响IT投资持续增长。数据显示，2012年全球企业IT支出预计将达到2.7万亿美元，同比增长约为3.9%。虽然从数据显示在低迷的宏观经济影响下企业IT支出增长在放缓，但企业在IT领域的投资仍在继续，这说明企业已经认识到IT对于其业绩增长的贡献是不可替代的。

信息化需求依旧旺盛，政策倾向性明显。我国人工薪酬持续增长将迫使企业的业绩增长由早期的劳动力优势驱动转为知识型和资本型驱动，因此企业将有更大积极性借助信息化来提升效率。另一方面，从已出台政策我们不难发现，扶持由普惠向侧重倾斜，目的是重点培育龙头企业，因此细分领域具有较强整合能力的行业领先企业将迎来巨大发展机会。

政府及大行业信息化投资仍然是主要驱动力。从细分领域看，面向政府、金融、电信、电力等行业的公司将继续受益于旺盛的下游需求；而智慧城市、智能交通、物联网等有关的扶持细则将陆续出台，主题投资将覆盖多个细分领域。此外，医疗信息化作为新医改“四梁八柱”架构的核心支撑点，有望受益于区域医疗信息化试点的建设和卫生部推广信息化标准衍生的相关产品更换需求。

计算机软件需求分析及开发研究 篇7

关键词：计算机,软件需求,分析,开发研究

在信息技术快速发展的时代, 计算机已经成为人们日常生活及工作中不可缺少的常用设备, 它凭借其强大的数据处理功能而广泛应用于各个行业。鉴于信息科技产业对整个社会信息应用模式的转变, 计算机必将成为未来企业办公、用户操作的主要模式。软件是计算机最为核心的组成部分, 注重市场上软件需求与分析工作是极为关键的。本次分析了计算机软件需求情况, 对软件开发工作提出了相关对策。

1 计算机软件需求分析

计算机是由软件、硬件两部分构成, 软件是计算机中的程序、文档, 其对计算机操作系统功能发挥有很大的影响。就目前市场情况来, 计算机软件需求来源于两大客户群体, 即企业用户、个人用户, 如图1。首先, 办公自动化系统融入企业日常经营, 计算机网络创建了虚拟化办公平台, 方便了办公职员的数据操作, 如:收集、分类、处理、存储等;其次, 个人计算机在使用过程中也要借助软件功能, 借助互联网平台实现数据的稳定传输, 加快了个人网络操作的工作流程。无论是企业或个人用户, 对于计算机软件功能的要求越来越高, 这说明了加强计算机软件开发的必要性。

2 新软件开发措施的研究

从长远角度预测, 以计算机为操作平台的数据处理模式, 必将取代传统手工数据录入, 推动了社会信息化时代的改革发展。软件作为计算机的核心构成, 其相对应的使用功能也要不断更新, 这样才能保障软件系统的应用价值。新款软件开发要结合实际使用情况, 对软件功能及系统结构实施优化调整, 如图2。笔者认为, 新软件开发包括:

(1) 拟定方案。软件需求分析就是对开发什么样的软件的一个系统地分析与设想, 根据需求分析结果便能拟定切实可靠的开发方案, 保证了新款软件使用价值的发挥。新软件开发方案是一个对用户需求进行去粗取精、去伪存真、正确理解, 然后把它用软件工程开发语言表达出来的过程, 拟定这些方案要结合企业、个人用户对软件功能的要求, 提高软件方案的针对性。

(2) 创建平台。软件开发平台源于繁琐的实践开发过程中, 应当设计出可以提供开发研究的数字化平台, 确保研发出来的新软件符合使用要求。开发人员在实践中将常用的函数、类、抽象、接口等进行总结、封装, 成为了可以重复使用的“中间件”, 这种软件平台的功能更强大、更能满足企业级客户需求。此外, 也可以利用数字技术为支撑, 加快计算机操作平台的自动化改造。

(3) 执行流程。软件开发方案及操作平台准备结束后, 技术人员则要对软件研发流程严格地执行, 每一个环节都要控制操作步骤, 这样才能保证软件功能的最大化。软件开发思路和方法的一般过程, 包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。研发人员执行中, 应是当地调试软件以及时修改程序指令。

3 结语

软件开发是计算机应用工程研究的重要内容, 也是决定计算机系统功能发挥的关键要素。为了向企业或个人用户提供优越的办公条件, 应首先分析计算机软件的需求情况, 这样才能提高软件产品开发的针对性, 更好地服务于用户操作。

参考文献

[1]王媛, 潘侠, 孙杰.软件需求分析支持工具ORDT的设计与实现[J].哈尔滨工业大学学报, 1999 (3)

[2]姜巍巍, 马绍力, 徐定海, 林武强.数控机床IETM系统的需求分析[J].机械设计与制造, 2010 (5)

[3]姜巍巍, 马绍力, 徐定海, 郭红芬.基于UML的数控机床IETM系统需求分析[J].机电工程技术, 2009 (6)

[4]赵瑞红, 韩宇亮.用用例法分析系统功能需求——以中国海洋大学宿舍管理系统为例[J].科技信息, 2011 (31)

[5]余芳, 沈桂兰, 黄勰.基于可预测性组件技术的软件组装[J].计算机工程与设计, 2008 (11)

[6]解永良, 王行刚.网络设计模拟工具NDS-2的设计和实现[J].微电子学与计算机, 2003 (10)

[7]魏晖瑜.基于MDA的需求自动建模工具的设计和实现[D].西安电子科技大学, 2010

[8]马学涛.采用DataSnap技术的药品试剂管理系统[D].郑州大学, 2010年

试议软件敏捷项目中的需求开发 篇8

随着软件规模及复杂程度日趋多样化、复杂化, 软件开发模式也涌现出多种开发模式。其中敏捷开发模式因为能够快速响应、快速交付, 以实现客户最大利益为目标, 在众多项目中得以推崇。然而敏捷开发中的重要环节: 需求的开发和管理, 常常成为开发团队极为头痛的问题。作为客户和开发团队的沟通桥梁, 需求分析同样应采用敏捷的过程方法参与到项目的开发过程。敏捷需求分析将在需求时 机与过程 、文档要求、变更、参与者角色等方面展现其不同传统的特性。将结合工业自动化控制背景及企业实际情况, 对敏捷需求分析做出初步的分析和论述。

2 敏捷需求概述

在国内工业自动化行业中, 传统的DCS系统产品已经得到较为广泛的推广, 随着企业对信息化的要求越来越高, 工业自动化应用水平的下一个阶段, 将是在商业价值引领下的市场拓宽、市场细分, 以及作为支撑的需求深入研究。众多自动化企业也都在“蓝海”寻求新增值点。 作为新行业的拓宽、细分必然需要新的解决方案和产品来支撑。于是对企业的研发团队而言, 新产品以及新需求就会层出不穷, 出于市场利益考虑, 企业也会要求研发团队能够快速响应需求, 能够聚焦需求, 快速地交付。在产品研发项目的实 施过程中 ,各种挑战和问题纷至沓来, 项目管理者不管是做时间、成本、质量的三角平衡, 还是人与技术的双向选择, 始终无法绕开的一个问题是: 如何快速响应需求的变化, 使客户在优化的体验过程中满足其商业目标, 从而实现企业本身的价值?

近年来许多软件公司的都发生过“需求失控”的情形。有很多研发团队在工作中采用庞大、 重型的过程方法, 在大公司中尤为如此。但未来的变化如同Nassim Nicholas Taleb描述的黑天鹅一样不可预测且重要, 已知和过去琐碎的重复并不足以预测未来的重大影响[1]。强调结构 化方法和 重型的管 理策略 ,往往在内心中拒绝变更, 把变更作为被管理甚至被“管制”的对象[2]。为了尽可能地避免变更 , 常常要求开发之前的需求获取、分析与定义“完美无暇”。采用了CMMI理念和流程, 仍旧会发生产品和商业价值的脱节。本质上而言, 不同方法出发点都是一致的。CMM/CMMI告诉人们做什么, 而敏捷则告诉人们如何去做。将二者结合起来, 在具体过程中进行裁剪和有机组合, 敏捷化的需求分析将发挥沟通、渗透和指导作用。

IEEE对需求的定义是: 用户解决问题或达到目标所需的条件或性能; 系统或系统部件要满足合同、标准或其他正式规定文档的条件或性能。需求是设计、构造产品的前提, 简单地说是必须完成的事及其所必须具备的品质。需求存在的原因要么是该类型的产品要求一定的功能和品质, 要么是客户希望需求成为提交的产品的一部分[3]。软件需求的组织关系如图1所示。

从图1中可以看出, 针对软件需求的层次及组成, 传统需求开发、分析方法和敏捷需求开发、分析方法基本特征是一致的。二者间最明显的差距在于开发和分析的方法, 以及方法的执行体。传统方法只会定义一个模糊的“需求分析师”角色, 而在敏捷项目中, 则可能由一个团队来承载, 强调了客户/用户的参与。

3 敏捷需求开发

3.1 需求参与和实现

首先描述需求的参与者。敏捷项目需求开发者包括用户代表 (可以是工程方代表)、需求分析师 (可以是产 品设计师)、开发人员 (包括架构师)、测试人员以及相关的项目管理者角色。由于很多时候用户代表的缺失或缺位, 需求分析师起到了中要的替代作用。需求分析师的重要职责就是与不同用户交流, 包括最终用户、工程使用方、市场方, 同时进行大量产 品调研以 了解和分 析需求 , 将其制作 成用户故 事(user story) 并将需求传递给开发人员 (前提是符合项目任务书的范围)。同时, 需求分析师也要在某种参与度较深的情况下代替客户负责功能验收测试。而对内, 需求分析师扮演了客户, 那么除了需求提供者的职责, 如果需要的话, 相应地也要有评价和验收否决的权利。开发、测试人员进入需求团队, 便于他们理解用户故事和验收标准。一个完整的需求描述用例可以很方便地转换为测试用例。从整个过程来说, 采集、分析和实现的过程就是用户场景拟合和检验, 以及类似于极限编程中结对式的及时纠偏。各种角色的积极参与在不同角度和层次下的场景拟合, 表明需求不是程序员 的事情 ,更不能寄望于抽象出一个需求分析师的角色甚至实例化为一个职位, 就可以全能地做出需求定义。主要的需求参与方及职责对比如表1所示。

其次是需求开发的工作方式。敏捷宣言强调了客户在一起工作的重要, 强调通过强化沟通, 提供项目团队整体的认知水平, 实现效率和质量的保证, 从而促进项目成功。在用户代表不能够完全参与过程时, 需求分析师的参与使之成为需求的组织者。同时也要求需求分析师不仅仅具备软件开发知识, 还要具备对产品/项目所处目标行业的深刻理解。最关键的是良好的需求分析能力和资源快速整合能力。其工作方式在传统方式之外, 可以使用用户需求验证会议和需求迭代计划会议的形式。

用户需求验证会议是在需求分析阶段, 召集需求相关利益方 (市场、工程、研发等), 面对进行中的用户需求进行讨论。会议的主要载体可以是用户需求说明书, 或其他需求记录清单。会议的主要目的是针对既有需求消除需求错误, 诠释需求详细要求, 制定需求的优先级, 达成一致理解。

需求迭代计划会议通过迭代开发过程中的迭代计划会议实现。由需求分析师召集开发、测试团队成员 , 通过讲解 、解释本轮迭代的目标和内容, 与会人员讨论并确认, 从而避免迭代目标的误解和扩大, 保证迭代目标的正确性和明确性。

3.2 需求分析和管理

传统的需求分析时机发生在项目早期, 通过对用户需求的集中解读, 基于产品组成功能的分解, 划分多个模块或子系统, 形成定型的产品需求规格书, 用于指导后续产品设计和开发。重要交付件产品需求规格书要求具备一 定的模板 ,要及时地维护和更新, 否则到项目后期就会出现和交付件不同步更新的问题。在传递需求信息的过程中, 依赖文档描述,极易形成信息偏差和丢失, 从而间接影响项目交付件的商业价值。一旦需求发生变更, 有严格的流程, 例如CMM/CMM的需求变更流程, 并将变更作为风险和项目考核指标, 也会降低产品商业价值的实现。

敏捷开发中需求分析方法近乎贯穿项目开发的整个生命周期。具体分析时, 会根据用户原始需求, 基于商业价值是否独立性, 划分为多个故事。每个故事可能会跨越多个子系统或模块, 但每个故事又是可以测试、可以验收的, 当然也是具备价值的。在每轮迭代计划会议中, 会不断地细化需求, 不断地重新梳理需求的优先级。作为需求分析的结果不要求具备详尽的、规范的文档, 可以通过多种工具进行记录和展示。项目中多采用Scrum Works工具, 能够很好地支持需求分析结果的记录、分享和跟踪。项目组的强化沟通不仅会弥补需求文档不规范的不足, 同时还会通过大量的测试用例进行需求的正确性和实现度验证。敏捷本身是拥抱需求变化, 所以对于变更认为是必然或计划中的事情。没有变更, 软件的演变将丧失动力。

需求分析的质量保证, 在传统开发模式中, 主要通过管理手段保证。诸如制定复杂、漫长的测试流程和 测试计划 ,由于项目开发的不可确定性, 其延期必然导致测试的 延期 ,同时测试发生在后期, 不能及时响应需求的变更, 发现的问题进行修复成本将十分高。相比而言, 敏捷需求分析由于是参与项目全生命周期的迭代演化, 每一轮迭代都会进行不断地梳理、修订。从源头保证迭代的目标明确, 即每轮迭代的交付版本其需求都是明确的, 风险很小, 价值最大, 并能够及时地调整。在项目中, 对于需求的管理, 除了需求分析师,还有QA、项目经理以及测试负责人共同全程、参与, 确保了需求能够始终被正确理解、传递和验证。从敏捷需求出发导出的场景拟合验收测试, 能从更广阔的层级 (业务价值视角)来验证需求的达成性而不仅仅是软件的可用性等指标。通过系统测试保证产品功能、性能质量, 通过验收测试确保产品与需求的满足度。迭代演进中应对需求变更, 是从客户视野上的更高的质量改进, 如图2所示。

4 结语

需求分析是整个软件工程的开端, 也是整个软件工程中最为重要的一环。敏捷过程意味着全过程的敏捷, 而不仅仅只是片面理解诸如XP、SCRUM等方法而局限于开发、设计环节。敏捷项目的需求分析方法吸收迭代分析的优势, 客服传统需求分析方法在敏捷开发项目中的弱项, 它以沟通、迭代、响应变化、独立业务价值导出的可见的用例等特征, 贯穿于产品全生命周期。通过在罐区自动化管理软件、综合SCADA监控软件的开发项目中, 结合CMMI体系的适度裁剪与SCRUM迭代开发模式, 化变化为动力, 已经取得良好的成果。

虽然将来敏捷需求分析方法会继续演变, 但关注客户、关注商业价值、关注变化的理念将会持续保持并被重视。在工业自动化行业的业务细化、业务拓宽的背景下, 将继续出现需求涌出同时保持持续演进的特征。应用敏捷需求分析方法论, 让研发团队更加关注商业价值, 是应对挑战的有效方法。

摘要：软件产品开发中,需求管理是决定成败的前提和关键。在敏捷开发模型中,传统软件开发过程中的需求开发和管理实践,会因为不能很好适应快速交付等敏捷原则,反而会对开发过程造成困惑和障碍。根据实际项目操作经验,参考敏捷开发模型,提出需求开发的迭代开发方法。

软件需求开发 篇9

1多元化需求下的软件开发管理系统的研究现状分析

1.1 国外技术研究现状

国外软件开发管理系统研发起步较早,种类较多且产品线也比较长,然而其中所存在的主要问题多为注重局部问题的解决,现就IBM Rational系列产品为例进行探析,该产品生产公司为IBM,在当前相关软件当中,算为一款在整体上较为完整的产品,可将其划分为五部分,即:其一,需求分析。从本质上来讲,其为一种对文档进行管理的工具,主要为UML建模给与相应支持;其二,设计与构建。从实质上来讲,其为UML建模的工具;其三,软件质量保证。其用处为实施代码分析,并应用在产品测试中;其四,软件配置管理。主要用于配置管理及工单的实现;其五为项目及过程管理,主要用于项目管理及过程管理。另外,除此产品之外,还有Borland Star Team及Sablime系列产品等。对上述产品综合分析可知,如果软件产品在具体的集成度方面存在较高状况,则其覆盖面与之成正比关联,但是,从软件开发管理框架角度来考量,其仅仅对其中的局部问题及环节予以涉及,在各个产品之间始终处于独立状态,不能及时、有效地进行结合,项目则在软件开发及设计中,扮演着重要角色,其中,开发管理方面则很少进行设计,这些产品仅能在一些较大规模企业中得到运用,虽然功能严谨,但是在灵活性方面则相对缺乏,国内一些企业运用上述产品,在具体使用过程中出现较多问题,至此,诸多软件产品在国内很难得到广泛应用和推广。

1.2 国内技术研究现状

随着近些年来技术水平的不断提升,国内软件企业在具体的软件开发管理领域进行了更为深入、全面的研究及探索,代表企业有北大青鸟及背景视锐达等,相比与国外企业,国内企业对配置管理方面作为研究出发点,但是在设计软件开发管理方面的内容则比较有限,实质上以多元化软件开发相应管理系统在国内仍然处于一定空白状态,现就JBRM需求管理系统予以考究,此产品顾名思义与需求管理相关,主要作用为,对辅助于软件开发管理系统,可实施五部分划分,即:其一,需求信息管理。主要运用文件夹等方式,能够为用户验证和查找提供更多便捷;其二,需求动态管理。通过对软件需求实施动态查询,为管理人员对项目风险进行评估及软件开发人员就项目进度进行掌握等提供便利;其三,需求变更管理。通过对项目范围扩展进行控制,以按需分配的形式实现资源合理利用,并对准确文档予以提供;其四,需求追踪。其方式主要有逆向或正向,通过控制需求,以此达更好利用需求之目的。针对软件开发管理,不管管理方式还是相应管理对象,其与国外同种类型的辅助工具相比较,在本质上并没有较大差距,但是从辅助的效果来考量,均存在比较明显的局限性。

2 多元化软件开发管理系统具体内容及技术路线分析

2.1管理系统具体内容

该系统在覆盖面较广,其中主要对软件管理涉及较多,通过结合企业管理和项目管理,并有效运用项目管理相应辅助作用,以此,实现企业开发管理目的,在软件开发当中,对其过程进行优化,研发自动化程度更高的软件,从而为实现企业规模化生产,在技术方法提供更好支撑。针对该管理系统,其功能模块为三部分,除了在项目管理功能模块当中,其所涵盖的项目管理及配置管理外,还有软件功能自动化模块当中,其所包含的测试自动化、需求管理及设计管理,除上述内容之外,还有在企业管理功能模块当中所涵盖的过程管理、合同管理及客户管理,这些功能模块相比于企业管理软件、项目管理工具及独立运行的系统辅助工具,多元化软件开发管理系统当中针对软件开发管理所应该具备的相应特点给与和充分考虑,其将企业管理作为研究的出发点,通过有机结合项目管理功能,并充分运用软件工程所具有的辅助功能,提供一种具备系统化和全方位的解决方案。

2.2 多元化软件开发管理系统研究的技术路线

该系统以六大技术路线应用状况下予以完成,第一,以SOA技术为基础,由于多元化软件开发管理系统在具体的规模及功能上均得到有效扩展,因此,针对软件的应用来讲,其也应具备相应的灵活性和可扩展性,SOA能够实现分解系统的作用,重新编排服务,针对系统所遇到的灵活性及可扩展性方面的问题能够给与有效解决。针对运用SOA架构来讲,其将软件企业的实际需求融入其中,针对软件开发管理系统相应伸缩性及实用性,利用服务的定制及装配予以完成,对软件企业实际需求予以充分满足。第二,Webservices为基础,采用SOA予以辅助,兼容不同类型系统,实现SOA架构构建;因此,在实际应用在中,能够将系统间数据进行转换,并能实施数据解析;第三,以RUI技术为基础,其主要以浏览器为基础所设计的一款富用户界面,就其外观来讲,形同于应用程序界面,然而却能够实现系统在服务功能方面的增强作用;第四,以J2EE标准为基础,运用该标准对系统的分布式结构进行设计,在对系统软件在独立性方面得到保证的状况下,对系统基础软件部署相应灵活性给与增强,不仅能够将软件研发及系统维护方面的成本给与有效降低,还可达到系统质量不断提升的效果。第五,以数据库为基础,系统平台需要将大量的数据进行收集,此外,还需要管理在系统开发当中所产生的大量数据,有效的数据能够实现系统研发成本降低的效果,因此,为了促进性价比的最大提升,可在研发当中运用大数据,以此针对软件开发管理当中相应需求给与适应。

3 多元化软件开发管理系统设计

3.1 架构设计

多元化软件开发管理系统在架构方面主要划分为四层,从顶层至底层分别为交互层、应用层、支撑层及基础设施层。交互层主要为用户;基础设施层内容主要为为信息,在各种设备、服务器及系统的作用下提供相应信息,该层不仅要有网络设备和主机,还需要相应的储存设备,以此达到对应用服务器及数据库系统提供信息的效果;在应用层当中包含有整个系统的核心内容,也就是上述中提到的企业管理功能模块、软件功能自动化模块及项目管理功模块,在各个功能模块当中还具有诸多内容;除此之外,应用层需要相应的支撑组件,且在组件的共同作用下最终形成相应应用支撑层,不仅需要管理权限及用户,还需要针对配置管理将适配器予以提供,此外,在应用层当中的各种功能的辅助下,才能达到将服务及引擎予以提供的效果比如工作流引擎及文档引擎等,针对系统技术体系架构来考量,其与总体架构存在相对应状况,主要也分为四层,从顶层至底层分别为展现层、业务逻辑层、数据访问层及信息服务层。针对系统总体架构来讲,其针对应用层的相应设计更为注重。见图1、图2所示。

3.2 功能实现

就多元化软件开发管理系统功能实现而言,其在具体的功能内容上,在具体的企业管理功能模块、软件功能自动化功能模块及项目管理功能模块上予以集中体现,项目管理功能模块当中给与集中体现,针对项目管理功能模块来讲,其在具体的设计上主要分为三个环节,即其一,以项目计划模型为基础,利用建模分解项目计划,并实施相应预警及跟踪操作,利用系统管理程序,实现项目计划评审自动化;其二,结合项目自身实际需求,对条目花任务进行设计,依据自动化功能任务来实现相应更新,从而达到醒目审核、预览及进度审核及发布等功能得以实现的目的;其三,依据具体的配置状态记录,将储存站予以生成,最终实现配置管理完成的目的。针对软件功能自动化模块来讲,其在具体的设计上也分为三个步骤,其一,将调研模块进行设置,就需求调研计划进行制定,对系统开发原型进行管理,对调研记录进行管理,描述各个功能点,将在需求更换当中的审核、评估、确认及申请等予以完成;其二,将设计模型及范例进行定制,以文档生成模型为基础,管理文档质量及设计状态,最终实现设计的转换;其三,测试系统功能及软件功能,对各技术线路进行广泛应用,并就测试自动化予以实现。针对企业管理模块来讲,其在具体的设计上也同样分为三步骤,分别为,其一,依据企业实际需要,就软件过程进行定义,对过程展现、执行任务及配置给与完成,重点设置标准模块、彼岸准子系统及部门等;其二,依据具体的合同信息,管理合同的关系人、附件、状态及条款等;其三,依据客户对应资料及类别,分析和跟踪管理客户信息,实现系统的自动报警及回访功能。可利用黑盒测试法,分析系统的运行效果,针对那些已经实现的预设功能,可通过将相关异常数据输入,以此对其可靠性进行测试,对系统是否出现异常进行观察。针对系统功能的实现来讲,其主要在需求管理界面、项目管理界面及系统初始界面当中予以体现,通过对这些界面进行观察,便可从中将比较详细的信息予以获取。

4 系统测试及运行效果分析

4.1 系统测试

系统测试运用黑盒测试法予以操作,采用手工形式,针对系统预设功能给与确认。通过将异常数据输入,进行系统可靠性测试,就当输入异常数据系统是否会出现中止及对用户错误能否屏蔽进行检验。采用loadrunner工具对系统性能进行测试。

4.2 系统界面实现及效果

4.2.1 系统初始界面

开发完毕后,其初始界面在视觉效果方面较好,且界面在色彩上也十分丰富,方便操作。见图2所示。

4.2.2 系统管理界面

该功能模块对公司各阶段的管理、项目生命周期管理及各个中心予以实现,针对员工的质量的管理、工时及任务等得以实现,此外,还有各种相应参考表格;利用信息化达到管理效率提升的目的。见图3。

4.2.3 需求管理界面

该界面主要对需求变更、需求分析及需求调研等方面管理予以实现,如图4所示。

本功能模块实现了电子化文档,在需求管理上可划分为FPA五要素、条目级和例级,实现依据需求而相应变更追溯的目的,并为需求分析提供相应依据支撑。根据具体的需求管理,以此达到对软件版本管理予以管理的目的,还可实现版本之间的比对,以产出物、任务及需求之间相应自动关联的作用,达到需求跟踪自动化得以实现的目的,还能够实现统规模估算差异的比对的目的,依据FPA五要素,实现更为准确的系统规模估算,因此,达到软件开发效率提升的效果。

5结束语

基于我国当前软件开发管理系统应用状况及发展状况综合考量可知,目前在高融合性方面还比较缺乏,此外,还应对功能更为全面的管理软件进行不断创新及研发,以多元化角度框架下,对软件开发管理系统进行设计,不仅要达到企业软件开发管理自动化的实现,还要提升我国管理软件的国际领域竞争力,更好地促进国内软件产业的跨越式发展。

摘要：科学技术的进步对于信息产业发展具有直接推动作用,特别是基于信息技术的软件产业更是得到长足发展,从国内外软件产业的发展情况来考量,针对软件系统的开发均将局部问题作为着重点,当前市场上,对开发管理整体解决的产品还较少,因此,针对软件开发管理系统来讲,应从多元化角度予以设计。

关键词：多元化,软件开发,管理系统,设计

参考文献

[1]吴晓慧.软件开发管理系统的面向多元化的设计[J].计算机光盘软件与应用,2014(6):256-257.

[2]王雪竹.软件开发管理系统的多元化设计分析[J].硅谷,2015(3):53-53.

[3]朱德润.行政机关绩效考核平台的设计与应用[J].电子技术与软件工程,2014(24):61-61.

[4]徐燕.一体化多种收费账务平台系统在电费管理中的应用[J].企业改革与管理,2014(11):137-139.

[5]李英.探索分析计算机软件应用与发展[J].计算机光盘软件与应用,2014(12):79-80.

[6]张颖.基于SOA体系结构软件开发研究[J].青年科学月刊,2014(8):167-167.

软件需求开发 篇10

关键词：用户需求,开发方法,软件界面,设计应用

计算机从产生到后续的运行发展,无论是在哪一个发展阶段中从其本质上来讲其系统开发以及实际的界面设计都是依据用户需求来进行具体操作的。也就是说,满足用户的实际使用需求是计算机在进行界面设计过程中比较重视的设计因素。

1初探用户需求的发展

计算机起源于美国,同时美国也对计算机不断进行更新, 其内部软件以及相应的用户界面其实都是基于用户需求的基础上逐渐发展的;体现出的是用不同的方式来满足广大用户的使用需求。

在最初的软件界面中,往往是通过命令语言方式来展现界面,如在auto CAD 1.0软件中就是通过命令语言方式来满足软件系统和用户建立起对话关系。同时,通过这种方式来满足了用户使用软件设计的辅助功能,可以说这种命令语言式的展现界面带给了用户一定的使用体验,但是其也存在一定的缺点,那就是软件界面中具有较低的容错率的同时,还要求必须具备较高的学习记忆功能。简单来讲,就是所有使用进行软件界面操作的用户都必须通过较为复杂的学习后, 才能与软件系统进行实际的对话,这就增加了软件界面操作的难度性。软件系统不会直接提供给用户便捷的功能技术支持,而也正因为此种状况这种界面被定义为是“人机对峙” 型软件界面系统。

随着社会的不断更新以及科技技术的不断发展,尤其是互联网多媒体技术的不断创新发展,传统的人际对峙型软件界面也得到了较大的发展和更新空间,在计算机以及相应的软件界面中将传统的静态的使用界面逐渐向动态的使用界面进行转化,在其中增加了相应的视频或者是动画等等具备动态形式的媒体技术,通过这种动态使用界面的发展使得计算机在进行信息表现的过程中具备了较为丰富的表现形式。同时,将其输出带宽进行了拓宽,而这对于用户来讲是一种较大的便利,可以自由的选择自己喜欢的表现形式,完全依据自身的个人需求以及个人喜好。之后多通道形式的用户界面开始成为了计算机界面的新型领域,多通道界面在动态式界面的基础上拓宽了信息的交互渠道,也就是说,用户可以利用多种渠道和软件系统建立起对话,这种多通道式的界面最大化的满足了人机沟通,提供了较为便捷的沟通渠道,满足了用户使用计算机的最大需求[1]。

2探析用户需求和软件工程

现今,软件工程主要是指将软件开发以及后续的运行维护不断地向工程化发展。在这个过程中,必须要使用规范系统化的方法进行操作,简单来讲,就是通过系统化的方式按照特定的开发路线以及开发手段等来进行软件的实际生产, 而这也是现今软件生产以及软件设计的一大特点,这种软件工程也被认为是比较有效以及科学的开发设计方法。其主要功能是将软件进行经济化以及高效化的设计生产,通过这种方式来最大化的满足用户不同的计算机使用需求,即从用户需求角度来进行软件的实际开发以及相应界面的设计。

通常来讲,在软件工程中,过程层是其主要的基层结构, 主要是将技术进行融合,促进计算机软件及时准确开发的一种过程,在这个过程层中还具体规定了较为关键的开发环节, 有效保障了工程技术开发设计的有效性。其中,关键的开发设计环节是整个软件工程中的重要基础,将软件系统中上区域和下区域段进行了关系确立。同时,还将计算机软件产品的质量进行了有效的保障。而建立在这种高质量品质基础上的软件开发以及界面设计极大的满足了用户的实际需求,对于用户来讲也是一种计算机质量使用需求的实现[2]。

在软件工程中除了过程层作用较大之外,方法层也对软件开发界面设计起着一定的作用,方法层主要是一种能够对软件技术提供解决渠道的一种软件结构,在这种方法层中主要是包含了一定的任务。例如,需求性任务以及概要性设计任务以及测试性任务等。可以说,在软件工程中方法层对其中任何技术区域都有着控制作用,包含了建模技术的控制以及描述技术的控制。而这种方法层的同时,也对软件的设计合理完整性进行了最大化的保障,通过这种方式来满足用户使用计算机的多种需求。

通常作为一种层次性较高的软件工程技术在进行界面设计的过程中除了拥有方法层以及过程层的技术保障之外。同时,要切实的考虑用户的实际使用需求以及用户的不同类别, 而一般企业软件界面的使用用户可以分为决策层用户以及管理层用户和操作层这3种用户,而可以说不同的用户在进行软件界面操作的时候其价值取向是各不相同的。例如,企业决策层的用户以及管理层用户就会比较重视软件系统中现实性和安全性是否功能完善,考虑的是计算机软件系统能为企业带来的实际价值利益。对于企业而企业操作层的用户就会比较重视相应软件系统中的业务处理操作的便捷性以及实用性,他们考虑的是系统能否为自己的实际工作带来怎样的便利性。由此可见,不同用户对于计算机软件以及软件界面的使用需求是不同的,通过软件工程这种技术方式来不断的优化计算机功能以及进行界面设计可以为最大化的满足用户的使用需求[3]。

3探析需求性界面设计的发展未来

多通道形式的用户界面是1990年以来计算机界面的新型发展领域,将虚拟环境和现实世界进行了较好的链接,现今, 对于计算机界面的设计发展已经不仅仅是局限在将用户和界面系统建立起相应的对话关系,而是最大化的将用户和界面系统之间的距离进行不断的拉近,而在这种环境背景下用户的需求开始变得多样化以及不确定化,对于界面的设计也就从特定用户需求考量逐渐转变到对用户的实际需求进行提前预测的考虑,而建立在这种对用户需求考量基础上的界面设计实现了在视觉以及听觉和动画上较为逼真的模拟设计,这对于用户现今需求来讲是一种最大化的满足,使得用户能够体验到更为真实的虚拟计算机世界[4]。

4结论