建议：通读教材:第8章 软件工程;第10章 系统分析;第11章软件需求工程;第12章 软件架构设计;第13章 系统设计;
软件需求：是指用户对系统在功能、行为、性能、设计约束等方面的期望。是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
随着系统规模的扩大，需求分析与定义在整个系统开发过程中越来越重要，直接关系到系统的成功与否。需求分析活动不再仅限于系统开发的最初阶段，而是贯穿于系统开发的整个生命周期。于是形成了软件工程的子领域：软件需求工程。
软件需求工程是包括创建和维护需求文档的必需的一切活动的过程，可分为需求开发和需求管理两大工作。需求开发包括需求获取、需求分析、需求定义、需求验证4个阶段；而需求管理包括定义需求基线，处理需求变更和需求跟踪等方面工作。这两部分相辅相成。其中需求开发是主线，是目标；需求管理是支持，是保障。
（2）需求分类
需求的层次(这三个不同层次从目标到具体，从整体到局部，从概念到细节)
（1）业务需求：是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，为以后的开发工作奠定了基础。
（2）用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求；
（3）系统需求：从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
1)功能需求：也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。
2)非功能需求（性能需求，质量属性）：指系统必须具备的属性或品质，又可以细分为软件质量属性（如可维护性、可靠性、效率等）和其他非功能需求。
3)设计约束（外界强制规定的）：也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。
u 按质量功能部署（从用户角度出发）
（1)常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。
（2)期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
（3)意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。
需求分类--【PIECES框架】
PIECES框架是IT项目系统需求分析时的一个模型，PIECES框架能够完整、准确、快速地确定信息系统的需求，确认业务中存在的问题、机会和改进目标。
PIECES框架是系统非功能性需求分类的技术
性能( Preformance): 用于描述企业当前的运行效率，可以分析当前业务的处理速度。 信息(Information ):信息和数据指标用于描述业务数据的输入、输出以及处理方面存在的各种问题。
经济(Economics [ˌiːkəˈnɒmɪks]): 经济指标主要是从成本和收益的角度分析企业当前存在的问题。
控制(Control ): 提高信息系统的安全和控制水平。
效率(Efficiency ):提高企业的人、财、物等的使用效率,
服务(Service ): 提高企业对客户、供应商、合作伙伴、顾客等的服务质量。
（3）需求开发-需求获取方法（特点?优点？缺点？根据描述能区分）需求获取属于软件需求工程的需求开发阶段，
（1） 用户访谈：1 对 1-3，有代表性的用户。用户访谈是最基本的一种需求获取手段，其形式包括结构化（指事先准备好一系列问题，有针对地进行）和非结构化（只列出一个粗略的想法，根据访谈的具体情况发挥）两种，最有效的访谈是结合这两种方法进行，毕竟不可能事先一一计划清楚。用户访谈具有良好的灵活性，有较宽广的应用范围，但用户时间不好安排；谈话信息量大，不好记录；需要沟通技巧和足够的领域知识、丰富的应对经验等；
为了进行有效的用户访谈，需要在三个方面进行组织，分别是准备访谈、主持访谈和访谈的后续工作；
1） 准备访谈
确定访谈目的；
确定访谈中应包括哪些用户；
为访谈准备一些详细问题；
问题可分为开放式问题和封闭式问题，开放式问题鼓励用户讨论和说明细节；封闭式问题旨在获得具体的事实。
2）主持访谈
具体访谈时，一定要准时到达，可能的话，早一点到，访谈过程，要做好几项工作：
限制访谈时间，时间控制在90分钟内，如果需要更多时间，应安排下一次，几次比较短的访谈，比一次马拉松式访谈效果要好得多。
寻找异常和错误情况，要找机会问一些类似，如果。。。那会怎么样的问题，有意识地去确定所有特殊的情况，并与用户深入探讨。
深入调查细节；
认真做好记录
注意措辞，尊重用户；避免使用IT专业术语；保持谈话轻松气氛；
3） 访谈的后续工作
访谈后首要任务是吸收，理解和记录访谈所获得的信息；对于用户回答不上来，或错过的问题，不要丢弃或遗忘，准备下一次再问；谈话备忘录要送客户一份。
（2） 问卷调查：用户多，无法一一访谈。通过精心设计调查表，下发到相关人员手同，让他们填写答案，可以有效克服用户访谈方法中存在的问题，一张好的问卷调查表需要花费大量的时间来进行设计与制作，包括确定问题及其类型、编写问题、设计问卷调查表的格式三个重要活动。与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据；问卷调查允许回答者匿名填写，大多数用户可能会提供真实信息；问卷调查的结果比较好整理和统计。问卷调查最大的不足就是缺乏灵活性;其次还有由于双方未见面，无法从表情等细节获取隐性的信息，用户也无法即时澄清含糊或错误的回答；用户可能心理上不够重视，反馈信息不全面；调查表不利于展开回答，不利于了解细节；回答人数可能不及预期，效果打折扣；
较好的做法是用户访谈与问卷调查相结合，先问卷调查，整理分析的基础上，小范围用户访谈。
提高问卷返还率的方法：
向所有解释问卷的目的，以及如何使用；
说明问卷所有人要回答；
拜托客户领导督促手下回答并返还；
尽量参加一次企业全体会议，会上回答大家的问题，并解释这些信息的用处；
更改问卷中的问题，尽量减少回答问卷所花费的时间；
设置奖励措施；
（3）现场观摩：针对较为复杂的流程和操作。想获取系统某些较为复杂的流程和操作过程，则现场观摩方法比较合适。对于一些较为复杂的流程和操作而言，是比较难以用语言和文字进行表达的，对于这种情况，可以采用到客户的工作现场，一边观察，一边听客户讲解，从而更直观的了解客户需求。（只是去观摩、看，不做）
（4）联合需求计划（JRP Joint Requirement Planning）是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，各方参与（关键用户代表、系统分析师、开发团队代表），成本较高。为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈，它是联合应用开发（Joint Application Development，JAD）的一部分。（以会议的形式获取需求，成本高，获取需求有效）
JRP原则：JRP的的主要意图是收集需求，而不是对需求进行分析和验证，实施JRP应把握以下主要原则：
Ø 事先制定议题；
Ø 严格按照约定时间进行；
Ø 对议题逐一进行讨论；
Ø 会议记录
Ø 避免术语，尽量通俗易懂，利于交流；
Ø 开发方应该解决冲突的能力：极力避免与各方，尤其是甲方闹不愉快。就事论事，目的在于解决问题；
Ø 中场休息：本次会议一个上午，中午结束，并无中场休息
Ø 鼓励取得一致意见；
Ø 保证大家遵守会议决议：即会后应有相关跟进，对作出的决议，产生的问题等及时处理；
JRP一般步骤：
Ø 让与会者互相认识，力求会议在轻松气氛中进行；
Ø 列举问题，逐一讨论或按照议程，逐一进行；
Ø 鼓励大家对新系统畅想，形成清单；
Ø 对清单进行整理，明确优先级，评审、最后形成结论或结议；
当然今天的联合需求计划会议并没有完全按照这样的步骤，但精神是一致的，哪就是理清需求，解决问题，形成结论，为下一步工作做好铺垫，精神贯彻就行，具体做法可以加以裁剪。
（5）情节串联板：通常是一系列图片，分析人员通过这些图片来讲故事，一般情况下，图片的顺序与活动事件的顺序一致，通过一系列图片来说明会发生什么，图片类型包括流程图、交互图、报表和记录结构，简而言之，情节串联板技术就是使用工具向用户说明（或演示），系统如何适合企业的需求，并表明系统将如何运转。
情节串联板的类型：被动式、主动式和交互式，复杂程度依次递增；
被动式是静态图片，系统分析师充当系统的角色进行讲解和演示；
主动式可以自动播放，描述系统典型场景等；
交互式可以让用户体验系统的行为，可以是抛弃式原型等；
情节串联板的制作：情节串联板应该易于创建和修改，不要企图做得太好太精美，情节串联板即不是原型，也不是真实事物演示。
（6）收集资料：把与系统有关的、对系统开发有益的信息收集起来。
（7）参加业务实践：有效地发现问题的本质和寻找解决问题的办法。（自已去做）
（8）阅读历史文档：对收集数据性的信息较为有用。
（9）抽样调查：降低成本。采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。抽样能够提高需求获取效率，但抽样往往是由系统分析师来抽的，所以会受到他的主观因素影响。（一个企业有3万人，不可能发全，统计也麻烦，可能抽了300人，各种群体均发一些，不是需求抽样哈。）
一般看丟采样抽样这些关键字后，一般要和数理统计联系在一起。
样本大小＝ɑ（启发式因子）（可信度系数/可接受的错误）2 =ɑ（启发式因子）（可信度系数/（1-可信度））2 注：其中可信度系数题目给出，可信度越高，可信息度系数越大； ɑ一般默认取 0.25；但也可以变。比如：已知每张订中可能有1张存在问题，则启发式因式=0.1（1-0.1）
序号
需求获取方法
特点
优点
缺点
1
用户访谈
1 对 1-3，有代表性的用户，比较耗时，成本高。其形式包括结构化和非结构化两种
用户访谈具有良好灵活性、有较宽广的应用范围
难以安排时间、记录困难，访谈时间有限，对系统分析师要求较高，需要有足够领域知识；
2
问卷调查
多方参与，用户多，无法一一访谈。成本低。
针对很多用户，代价比较小、结果比较好整理与统计
不灵活
3
现场观摩
针对较为复杂的流程和操作。
直观了解客户需求
4
联合需求计划（JRP）
高度组织的群体会议，各方参与，成本高
用户积参与，提高开发效率、多方参与，讨论出需求，可以降低需求获取时间，特别适合需求不明确、有争议（歧义）的需求。
以会议的形式获取需求成本高
5
情节串联板
一系列图片，通过这些图片来讲故事
直观、生动、用户友好、交互性强，对用户界面起了早期评审作用
花费时间多，使获取需求速度大大降低
6
收集资料
把与系统有关的、对系统开发有益的信息收集起来。
7
参加业务实践
有效地发现问题的本质和寻找解决问题的办法。
8
阅读历史文档
对收集数据性的信息较为有用。
9
抽样调查
（采样）
从种群中系统地选出有代表性的样本集的过程，样本数量=0.25(可信度因子/错误率)2降低成本。
加快了数据收过程，提高了效率，降低了开发成本；采用技术采用了数据统计原理，减少数据收集偏差。采样技术不仅可能用于收集数据，还可以对人员进行采样，样本选得好，对数据可靠
采样技术正因为基于统计学原理，样本规模的确定依赖于期望的可信度和已有经验知识，很有大程度上取决于系统分析师的主观因素和个人的经验能力，对系统分析师要求较高
需求记录技术:
由于需求获取人员和需求分析人员可能不是同一人，或者一个项目有多个系统分析师参与需求获取，因此需要统一需求记录工具，以便统一口径。
常用的需求记录工具有：任务卡片、场景说明、用户故事、Volere白卡等；
任务卡片：在各种需求记录工具中，任务卡片是一种比较简单的工具，特别适合对业务活动级的信息收集与整理；
场景说明：是用户对其工作场景和过程的详细描述，这些描述将在编写测试用例和用户培训手册中再次用到；
用户故事:描述了对用户有价值的功能，包括三个方面的内容：书面描述（用于计划和备忘）、交谈（细化故事）和测试用例（验证故事实现）
（4）需求开发-需求分析需求分析：一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需求分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。 需求分析分为结构化需求分析和面向对象的需求分析两类，考试基本只考这两类。
需求分析的任务（需求分析包括几方面的工作内容）
(1)绘制系统上下文范围关系图
(2)创建用户界面原型
(3)分析需求的可行性
(4)确定需求的优先级
(5)为需求建立模型【逻辑模型】
(6)创建数据字典【对逻辑模型进行解释】
(7)使用QFD(质量功能部署)
（1）需求分析方法-PDOA方法(Problem Domain Oriented Analysis 面向问题域分析方法)是一种面向问题域的分析，与SA和OOA相比：PDOA更多的强调描述，而少强调建模，包括两个部分:
(1)关注问题域。用一个文档对含有的问题域进行相关的描述，并列出需要在该域中求解的问题列表，也就是需求列表。只有这个文档是在分析时产生的。
(2)关注系统(即系统实现)的待求行为。用一个文档对了解系统的待求行为进行描述。该文档将在需求定义阶段完成。
在PDOA方法中，对整个过程有着一个清晰的定义:
(1)收集基本的信息并开发问题框架，以建立问题域的类型。
(2)在问题框架类型的指导下，进一步收集详细信息，并给出一个问题域相关特性的描述
(3)基于以上两点，收集并用文档说明新系统的需求。
从上面的描述中可以看出，问题框架是PDOA的核心元素，是将问题域分为一系列相互关联的子域，而一个子域可以是那些可能算是精选出来的问题域的一部分。
