《构建之法》笔记---第十章 典型用户和场景

《构建之法》笔记

第二章 个人技术和流程
第四章 两人合作
第六章 敏捷流程
第十章 典型用户和场景


《构建之法》笔记---第十章 典型用户和场景

  • 《构建之法》笔记
  • 前言
  • 一、典型用户(Persona)和场景(Scenario)
  • 二、用例
  • 三、规格说明书(Specification)
    • 软件功能说明书(Function Spec)
    • 软件技术说明书(Technical Spec)
  • 四、功能驱动的设计(Feature Driven Design)
  • 总结


前言

典型用户(Persona)和场景(Scenario),软件功能说明书(Functional Spec)和技术说明书(Design Doc),功能驱动是设计(FDD),用例(Use Case)


一、典型用户(Persona)和场景(Scenario)

一个典型用户往往描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。
对每一个典型用户决定其的目标(他使用系统想要达到什么目的)。对每一个目标,列出达到目标所必须经历的过程,即场景,也可以叫故事(story)。
从场景到任务。

二、用例

常用的需求分析工具。基本元素:

  • 标题:描述用例要达到的目标
  • 角色(Actor):和软件系统交互的角色,例如用户,其他实体,甚至时间(描述一些和时间相关的场景)
  • 主要成功场景:一系列步骤描述角色怎么和系统交互,从而达到目标。
    • 步骤:描述每一步的交互
  • 扩展场景:描述一些扩展的交互,例如一些意外情况

三、规格说明书(Specification)

软件功能说明书(Function Spec)

主要用来说明软件的外部功能和用户交互情况(把软件当作一个黑盒子)。
从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率(对用户而言)、国际化、本地化、异常情况等,不涉及软件内部实现细节。

模板:

  1. 目标包括什么,不包括什么(规范好一些假设);
  2. 用户和典型场景(主流用户);
  3. 术语及定义(定义好一些概念);
  4. 用户是如何使用软件功能的(软件交互步骤);
  5. 各种边界条件;
  6. 功能有什么副作用,对其他功能有什么显性或隐性的依赖关系;
  7. 什么叫“好”,什么叫“这个功能测试完了,可以交付了”;
  8. 软件发布后,有哪些项目相关的数据可收集,如何在实现阶段就把数据收集的准备工作准备好;

软件技术说明书(Technical Spec)

又叫设计文档(Design Doc),主要用来说明软件内部的设计规范(把软件当作一个透明的箱子 用于描述开发者如何去实现某一功能,或相互联系的一组功能。
注:设计文档应该说明设计是如何体现一些设计原则的。

四、功能驱动的设计(Feature Driven Design)

如何把用户需求变成团队成员可以直接操作的开发工作,FDD是针对这个问题的众多方法论之一。

构成步骤:

  1. 构造总体模型(Develop an Overall Model)
  2. 构造功能列表(Build a Feature List)
  3. 制定开发计划(Plan by Feature)
    考虑因素(各实体和功能之间依赖关系;复杂程度;高风险难度功能适当提前;…)
  4. 功能设计阶段(Design by Feature)
    分析一组相关实体及其功能,通过时序图(Sequence Diagram)和其他工具,展示各个实体和函数如何动态地结合起来实现一个功能。
  5. 实现具体功能(Build by Feature)
    具体团队成员实现类/函数,进行相关单元测试,并在代码复审后,把代码集成到产品构建中

注:FDD对单元测试之外的测试(集成测试、压力测试、对用户界面和用户体验的测试)讲述不足。


总结

你可能感兴趣的:(读书笔记,软件工程)