需求分析
在系统工程及软件工程中，需求分析指的是在建立一个新的或改变一个现存的系统或产品时，确定新系统的目的、范围、定义和功能时所要做的所有工作，其中包括考虑来自不同利益相关者的需求，确认是否冲突，在冲突的需求之间进行取舍，并针对软件需求及系统需求进行分析、记录、确认以及管理[1]。
需求分析是软件项目或系统项目中的关键过程，关系项目的成败[2]。理想的需求要整理成文件、可以执行、可以量测、可以测试、可以追踪、和识别到的商业的需求或机会有关，而且要有系统设计的相关设计细节。
挑战
顺利地完成需求分析是一个艰巨的挑战。首先要确认所有持有关键信息的人本身就不容易，然后还要从这些人获得可用的信息，把这些信息转化为清晰的和完整的形式。同时分析者还要考虑到可能的限制。除此之外他们还要考虑一个项目的
- 是否可行
- 是否在规定的时间里可以完成
- 价格上是否负担得起
- 是否合法
- 是否符合道德
一个新项目开始的时候人们往往还非常兴奋，往往试图轻视需求分析的必要性。但对过去项目的分析证明一个彻底的和无情的需求分析可以降低一个项目的耗费和降低其技术风险。
主要困难
随着工程师对需求分析的越来越重视，今天我们对需求分析的主要困难也理解得比较清楚：
- 需求分析需要由有充分的经验、技术知识和语言技巧的专家来完成；
- 顾客一开始所提出的需要，往往不完全、太乐观以及过分受老的系统或过程的影响；
- 软件工程师与他们的顾客往往使用不同的词汇。有时他们以为互相之间完全达成协议，但是在展示最终结果时却发现并非如此。
持有关键信息的人
顾客有可能妨碍需求分析顺利进行，有以下几种可能性：
- 顾客不明白他自己需要什么
- 顾客不愿将他们的需要固定在一系列写在纸上的条例中
- 在价格和时间确定后，顾客坚持要求新的需要
- 分析者与顾客的通讯太缓慢
- 顾客不参加回顾或无法参加回顾
- 顾客缺乏技术上的知识
- 顾客缺乏对软件开发的知识
软件开发者
但是软件开发者也有他们的责任。由软件开发者导致的困难有：
- 软件开发者往往喜欢将顾客的需要改变得能使它们符合一个已存在的系统或模式，而不愿按照顾客的需要来发展一个新的系统。
- 需求分析往往是由程序员完成的，而不是由作业分析员完成的。程序员往往缺乏理解实际事物的运行过程和商业过程的技巧。
解决方法
解决这些困难的一个方法是使用专业的作业或系统分析员，这些专业人员通过专门训练来填补商业和电脑世界之间的鸿沟的。这个方法可以达到一定的效果，但从顾客方面来说要找到相应的有类似技巧的人就相当困难了。此外今天为需求分析所使用的方法依然还有很大的缺陷，它们还不够有效。
主要技术
需求分析有可能在一个项目中成为一个漫长、艰巨的工作。需求分析专家与他们的顾客交谈、记录他们的交谈结果、分析他们收集的信息，从中提取互相矛盾的地方，总结出一个总体观念，然后再与顾客交谈他们发现的问题。这个过程可以不断重复，在有些项目中这个过程可以伴随着整个生命周期。
新系统很可能改变人之间的关系和人的工作环境，因此认定谁是重要的信息持有者是非常重要的。只有这样在需求分析的过程中才能够将顾客所有的需要都纪录下来，只有这样才能保证他们认识到新的系统对他们来说带来怎样的变化。出于下述原因这个要求往往达不到：
- 与顾客的交谈不够多和不够彻底，一些重要的需求被忽视；
- 顾客的反应不说明问题，顾客对新系统的特征不满。
为了使所有这些讨论有条理、有组织和有效地被记录下来，这些讨论的过程和其内容的演化也必须被记录下来。
分析员可以使用不同的技术来从顾客手中获得需求。比较老的方式有采访顾客，或者与顾客一起开座谈会，列举顾客的需求。比较新的技术有建立模型和使用用例。在最佳状态下在采纳了不同的技术后他们可以完全理解顾客的需要和与持重要信息的人建立了必要的联系。
采访持重要信息的人
采访持重要信息的人是需求分析中一个必不可少的过程。但在一个大的系统中许多人必须被采访，这需要许多时间和金钱，但最重要的是这个过程最可能显示现有的业务流程与新系统中的业务流程之间的差别。不同的顾客有可能有不同的或甚至相对的需求，在这种情况下分析员必须协调各方的需要。
需求工作会议
出于上述原因一般假如一个系统非常复杂的话需求分析最常用的方法是召开需求工作会议，在需求工作会议上分析员和持重要信息的人一起分析系统的需要和发展解决方案。
这样的工作会议最好不要在采访对象的工作场进行，这样采访对象才不会被打扰。工作会有一个负责人来保持会议的进程，一个记录员来记录会议的讨论，投影仪和相应的软件是常用的工具。一般需要进行多次会议后才能得到最终结果。
一般认为需求工作会议可以节省不少时间，因此是一个非常有用的工具，但是往往很难同时将所有的持重要信息的人聚集到一起。
一个常见的缺陷是一些持重要信息者在这样的会议上不十分积极，因此他们的需求没有获得必要的重视。这样得到的解决方案必然有限。此外需求工作会议是一个很好的分析现有系统的工具，但用它来寻求解决方案就不是十分有用了。
将需求列成合同式的文件
最常见的纪录需求分析的方式是将顾客需求列入一个合同式的表。对于一个复杂的系统, 该文件可以长达数百页。现代的分析员不愿使用这样的列表，因为它们被证明相当无用，但它们依然相当常见。
优点：
- 提供一份需求的清单。
- 提供一份顾客和开发者间的合同。
- 对一个大的系统来说它提供了一份高级的描写。
缺点：
- 这些列表可以长达上百页，实际上没有人能够完整地阅读这样的文件来获得一个完整的系统理解。
- 列表中的需求一般都很抽象和缺乏关联
- 这样的列表一般表示不列出需求之间怎样组成一个整体。
- 从列表中很难看出哪些需求更重要。
- 抽象后的列表为读者提供了许多理解的余地，因此不同的读者对文件的理解可能不同。一个项目越大，读者越多，理解的方式就越多。
- 从抽象后的列表中很难看出它是否完全。它们往往忽视了许多细节。
- 顾客和开发者对这个列表的理解往往完全不同。
- 这样的合同式的列表给顾客一个错误的安全感，好像他们的要求都已列入了。但是由于列表本身对细节问题不能细述因此许多关键的细节问题实际上并未列出和解决。这些问题一直到后来软件开发时才被发现。那时开发者一般要与顾客再次讨论并试图按他们的意愿和条件来解决。
- 这个列表对此后的系统设计不提供任何帮助，它们的结构无法直接进入新软件。
原型（Prototype）
从1980年代中开始，越来越多的人将作原型看作是解决需求分析困难的办法。原型模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样，而实际上在这些屏幕显示的背后还一切都空着呢。这样顾客可以在系统还没有建立之前就做出设计决定。当原型首次被使用的时候它们的效果被视为非常惊人。引入原型往往提高顾客与开发者之间的信息交换。原型的屏幕显示后来往往很少被改变，因此可以大大地降低费用。
但此后十多年的实际应用，证明虽然原型是一种有用的技术，但它也有它的缺陷：
- 经理人员在看到原型后，往往不理解为什么还要到一段时间后，最终设计才能完成。
- 设计师往往将拼凑在一起的原型码用到后来真正的系统中，因为他们怕在再次编码时“浪费时间”。
- 原型帮助解决设计决定和用户界面的设计，但是它们并不提供任何关于需求的信息。
- 设计师和顾客有可能花费太多的时间和精力来设计用户界面，而忽视对作业过程的关心。
用例（Use Case）
参见用例
用例是一种记录新系统或软件更换时的需求的技术。每个用例包含一个系统在作业时与用户或与其它系统之间交换信息的场景。一般用例避免使用术语，而尽量使用顾客、用户或他们的专家的语言。一般用例由软件开发者和顾客一起写成。
在1990年代中用例很快地成为了记录需求分析的最主要的方式。尤其在它的发源地，在面向对象的程序设计中它的普及性非常高。但用例不仅可以用在面向对象的程序设计系统中，实际上用例本身并非面向对象的。
每个用例集中于描写如何来完成一个作业目标或任务。对传统的软件工程来说每个用例描写系统的一个特点。对大多数软件项目来说一个新的系统有多个（往往十几个）用例。不同的软件项目的格式或项目的进展都可能影响用例的细节性。
用例描述系统在运行时与外部执行者之间的信息交换。外部执行者是任何系统外的、与系统交换信息的对象或人物。它们可以是用户、用户的角色或其它系统。
用例将系统当作一个“黑匣子”，它从外部来看与系统之间的信息交换（包括系统的回答）。这样它简化对系统的需求的描写而且防止对系统的工作方式作任何过早的假设。
每个用例应该符合下述条件：
- 描写完成作业目标的作业任务
- 不包含任何编程码
- 有一定的细致性
- 足够短，一个程序员应该可以在一个版本的工作中，独立完成这个用例所描写的作业过程。
在描写功能需求时用例非常好用，但它们不适合描写非功能需求。
确认持关键信息者
从1990年代开始确认持关键信息者被确定为一个非常关键的过程。它同时也是需求分析的第一步。此前经理人员往往被认为是持关键信息者。许多系统是按照这些经理人员的设想设计的，而实际的用户很少或根本没有对设计做任何贡献。这样的系统往往是大失败。因此在1970年代和1980年代在软件工程师中渐渐地持关键信息者的概念扩展到主要用户，后来还扩展到次要用户。在1990年代中工程师们更加从一个系统整体的观念上来确定持关键信息者。他们渐渐认识到不但在雇佣他们的顾客中有持关键信息者，其他持关键信息者包括：
- 与顾客横向相连（或应该横向相连）的组织
- 顾客的后勤办公室或类似的组织
- 高级经理人员
成功地确认持关键信息者是完整地完成需求分析的基础。
参见
参考文献
- ^ Kotonya, Gerald; Sommerville, Ian. Requirements Engineering: Processes and Techniques
. Chichester, UK: John Wiley and Sons. 1998. ISBN 9780471972082.
- ^ Alain Abran; James W. Moore; Pierre Bourque; Robert Dupuis (编). Chapter 2: Software Requirements. Guide to the software engineering body of knowledge 2004. Los Alamitos, CA: IEEE Computer Society Press. March 2005 [2007-02-08]. ISBN 0-7695-2330-7. （原始内容存档于2009-03-23）.
It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.
延伸阅读
英文书籍
- Laplante, Phil. Requirements Engineering for Software and Systems 1st. Redmond, WA: CRC Press. 2009. ISBN 1-42006-467-3. （原始内容存档于2011-07-08）.
- McConnell, Steve. Rapid Development: Taming Wild Software Schedules 1st. Redmond, WA: Microsoft Press. 1996 [2009-04-20]. ISBN 1-55615-900-5. （原始内容存档于2005-04-20）.
- Wiegers, Karl E. Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle 2nd. Redmond: Microsoft Press. 2003 [2022-07-29]. ISBN 0-7356-1879-8. （原始内容存档于2021-05-05）.
- Andrew Stellman and Jennifer Greene. Applied Software Project Management. Cambridge, MA: O'Reilly Media. 2005 [2022-07-29]. ISBN 0-596-00948-8. （原始内容存档于2021-05-25）.
- Brian Berenbach, Daniel Paulish, Juergen Katzmeier, Arnold Rudorfer. Software & Systems Requirements Engineering: In Practice. New York: McGraw-Hill Professional. 2009 [2022-07-29]. ISBN 0-07-1605479. （原始内容存档于2021-05-09）.