第二章 软件需求与软件需求规约
**大家想一起学习交流的可以加群，QQ：755422568。**
一、软件需求
（1）、软件需求
定义：是有关一个“要予构造”的陈述，描述了待开发产品/系统功能上的能力、性能参数或其他性质。
性质：
1）、必要的，该需求是用户所要求的，验证采用需求复审。
2）、无歧义的，该需求只能用一种方式解释。
3）、可测的
4）、可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段。
5）、可测量的
（2）、需求分类
1）、功能需求
规约了系统或系统构件必须执行的功能。
2）、非功能需求
1、性能需求
规约了系统或系统构件在性能方面必须具有的一些特性。
2、外部接口需求
规约了系统或系统构件必须与之交互的用户、硬件、软件或数据库元素，其中也有可能规约交互格式、时间或其他因素。
接口需求有七个：
（1）、用户接口
（2）、硬件接口
（3）、软件接口，描述与其他软件产品进行的交互。
（4）、通信接口，描述待开发系统与通信设施之间的交互。
（5）、内存约束
（6）、运行
（7）、地点需求，描述系统安装以及如何调整一个地点，以适应新的物理环境。
3、设计约束
限制了软件系统或软件系统构件的设计方案的范围。
考虑几个方面：
（1）、法规政策
（2）、硬件限制
（3）、与其他应用的接口
（4）、并发操作
（5）、审计功能
（6）、控制功能
（7）、高级语言需求
（8）、握手协议
（9）、应用的关键程度
（10）、安全和保密
4、质量属性
规约了软件产品所具有的一个性质必须达到其他质量方面一个所期望的水平。
可靠性、存活性、可维护性、用户友好性
（3）、需求发现
1）、初始发现需求的常用技术包括5种。
（1）、自悟
适用情况：需求人员不能直接与用户进行交流。
存在风险：无法验证发现的需求是否满足用户的要求，是否正确。
（2）、交谈，提出问题/用户回答这一方式
适用情况：客户支持需求人员与最终用户进行有关系统需求的交流。
存在风险：需求可能不断增长，以至于很难控制，导致超出项目成本和进度的限制。
（3）、观察
适用情况：用户允许需求人员进入工作现场，并进行观察，可与有关人员就问题进行交流。
存在风险：客户可能抵触，影响他们的正常业务；可能在开发者签约之前就已熟悉业务。
（4）、小组会，与客户组织的一些代表共同开发需求
适用情况：各方组织在管理层上重视需求工作，并有能力提供人力资源。
存在风险：如会议组织不到位或者某些客观环境的限制，会产生一些相互矛盾的需求。
（5）、提炼，复审技术文档，并提取相关的信息。
适用情况：提炼方法是针对已经有了部分需求文档的情况。
存在风险：无法验证发现的需求是否满足用户的要求，是否正确。
二、需求规约
（1）、需求规约
定义：是一个软件项/产品/系统所有需求陈述的正式文档，表达了一个软件产品/系统的概念模型。
性质：
1）、重要性和稳定性程度，按需求的重要性和稳定性，对需求进行分级。
2）、可修改的
3）、完整的，没有被遗漏的需求。
4）、一致的，不存在互斥的需求。
需求规约是软件开发组织和用户之间一份事实上的技术合同书，回答：“交付给客户的产品/系统是什么”
（2）、需求规约（规格说明书）（选择题、填空题）
表达三种不同风格
（1）、非形式化的需求规约，以一种自然语言来表达需求规约，如文章。
（2）、半形式化的需求规约，以半形式化符号体系来表达需求规约，如术语表、标准化的表达格式
（3）、形式化的需求规约，以一种基于良构数学概念的符号体系来编制需求规约，一般往往伴有解释性注释的支持
（3）、需求规约的作用
（1）、需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。
（2）、对于项目的其余大多数工作，需求规约是一个管理控制点。
（3）、对于产品/系统的设计，需求规约是一个正式的、受控的起始点。
（4）、需求规约是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会尝试另外两个文档——初始测试计划和用户系统操作描述。
注：需求规约不能实现以下两个作用。
1、不是设计文档，是一个“用于”设计的文档。
2、不是进度或者规划文档，不包含在工作陈述、软件项目管理计划、软件生存周期管理计划、软件配置管理计划或软件质量保证计划。
