需求获取有哪些常用方法:
? 面对面访谈(face-to-face interviewing) ? 专题讨论会(workshop)
? 现场观察(observing on the scene) ? 头脑风暴(brainstorming)
? 多种方法要复合在一起使用，效果更好
DFD是什么？
数据流图(Data Flow Diagram, DFD)：结构化系统分析的基本工具
DFD图有哪些元素构成?
会画DFD图（顶层、0层）20分
? DFD：描述数据在功能模块之间的流动；
0层DFD图
例
顶层DFD图
0层DFD图
DD是什么？ 会定义DD
DD：描述数据的具体格式； 数据字典(Data Dictionary) 决策树与决策表的作用
用决策树来描述一个加工的逻辑处理过程，其基本思路与结构化英语类似，但是更直观易懂。
会画用例图 10分
例
用例之间的关系：
包含，扩展，泛化
软件需求规格说明书（SRS）应具备哪些特点:
? 正确性 ? 无二义性 ? 完整性 ? 一致性
? 按重要度/稳定性排序 ? 可验证性 ? 可修改性 ? 可跟踪性
编写SRS的原则有哪些:
? 原则1：只描述“做什么”而无须描述“怎么做” ? 原则2：必须说明运行环境
? 原则3：考虑用户、分析员和实现者的交流
? 对形式化和自然语言之间作出恰当的选择
? 明确的理解最重要，不存在十全十美的软件规格说明书
? 原则4：力求寻找到恰如其分的需求详细程度
? 一个有益的原则就是编写单个的可测试需求文档
? 建议将可测试的需求作为衡量软件产品规模大小的尺度 ? 原则5：文档段落不宜太长 ? 简短
? 记住：不要在需求说明中使用“和/或”、“等等”之类的词 ? 原则6：避免使用模糊的、主观的术语
? 如用户友好、容易、简单、迅速、有效、许多、最新技术、优越的、可接受的、最大化、最小化、提高等 ? 不可验证
需求验证要验证哪些内容:
? 软件需求规格说明正确描述了预期的系统行为和特征 ? 从系统需求或其它来源中得到软件需求 ? 需求是完整的和高质量的 ? 所有对需求的看法是一致的
? 需求为继续进行产品设计、构造和测试提供了足够的基础
需求验证的技术:
? 需求评审：由不同代表(如分析员、客户、设计人员、测试人员)组成的评审小组以会议形式对需求进行系统性分析。 ? 原型评价：客户和用户在一个可运行的原型系统上实际检验系统是否符合他们的真正需要。
? 测试用例生成：通过设计具体的测试方法，发现需求中的问题。
需求评审过程及退出条件:
过程：
退出条件：
? 已经明确阐述了审查员提出的所有问题 ? 已经正确修改了文档
? 修订过的文档已经进行了拼写检查和语法检查
? 所有TBD的问题已经全部解决，或者已经记录下每个待确定问题的解决过程、
软件需求分析重点
