简析软件需求分析过程

ger8

好贴

qwe0987

很好，正需要这方面的资料

张恂

>>需求规格只是宏观的描述，为设计阶段划定范围，不应该包含不确性因素在里面，要么做，要么不做，不能遗留任何待解决的问题，而且还要保证需求的完整性。

这句不赞同。

这还是瀑布（Waterfall）思维，理论上存在的情况，而在现实的商业软件开发中，需求阶段完成的需求规约没有任何问题，没有不确定性，几乎是不可能的。所以，1990年代以来迭代开发逐渐成为世界软件工程的主流。

需求规约也不只是些宏观的描述，还包含许多微观、细节、确定的需求描述。

张恂

gaowd 发表于 2008-8-5 09:56
是原创

赞原创

许多内容不错，不过主要问题是整体思路还是风险较大的传统软件工程瀑布式开发（需求阶段、设计阶段、测试阶段等等...），而没有采用更先进的迭代式开发与演进式需求分析。

张恂

EPS2008 发表于 2008-8-4 22:47
但楼主好像没有提到，若在开发的最后阶段，用户要求变更需求应该如何处理？

好问题！

处理项目后期麻烦的用户需求变更，有许多手段。

首先，双方应该在开发合同中进行明确约定，处理这类需求变更的具体流程，哪些变更可以接受，哪些变更可以拒绝，双方的底线在哪里。

商务上的约定比单纯的需求变更管理或技术手段更重要。

张恂

AlexQin 发表于 2008-8-7 18:06
公司内部一般包括分析设计人员、各部门开发经理、维护经理、项目经理及资深开发人员；外部专家包括典型客户 ...

>>我觉得公司内部人员这部分还需要加上测试部门
也可以说是所谓“资深测试人员”
因为作为质量保证
测试人员是最具说服力的
我认为在需求阶段
有测试人员的介入
会让整个项目可能产生的问题减少<<

赞！

成熟的软件开发过程Tester和SQA都应该尽早加入。

张恂

>>需求的评审一般由专业人士来完成，主要包括公司的内部专家及外部专家，公司内部一般包括分析设计人员、各部门开发经理、维护经理、项目经理及资深开发人员

需求评审应该加上测试和质量人员。

张恂

>>4、用户需求不断的增加，这也是最常见的问题之一，在需求评审的过程中，往往评审人员根据讨论的结果会提出新的需求，会导致不断的更改，所以在编写需求规格的时候要把握一个度，不是任何需求都要列入。

成熟的需求变更管理关键在于走流程，以及相关人员的正确决策。没有或缺少规范的变更流程和决策手段，需求加不加、改不改这个度很难把握。

需求评审会议的结果是评审意见，一般不能直接改需求，需求变更的提议仍需要走流程。

张恂

>>任何形式的需求规格说明书都不能保证完全没有错误和缺陷，我们在编写的过程中只能尽量按照软件工程的规范去执行，尽量避免问题的发生。

没错，关键是整个软件开发过程改瀑布式为迭代式，通过多次迭代的分析、反馈、评审和验证来不断提高、确保需求规格书的质量。