需求设计需求分析写作培训.pptVIP

* 关于详略的问题，是否需要描述清楚函数的所有逻辑分支，应根据实际情况决定。一般而言，要求编码时相对于LLD，函数的处理不应该再增加如if, else, case等逻辑分支。 如果负责编码的人对LLD不熟悉的话，就要求LLD写得详细些，否则，只需要将函数的关键算法描述清楚即可。 * 前面需求建模样例为“在DOS环境下模拟实现ATM柜员机”，此样例为该项目的HLD。 * 我们目前对待文档写作的态度：内心上抵触、应付了事。 反观老外在这方面的认真态度，我们不但需要文档化，还需要将文档化做好。 * 开发人员写文档常犯的低级错误： 1.不使用标准模板； 2.文档各部分内容不全，关键词、摘要、缩略语、文档标题、页眉页脚中错误非常多，让人没有再看下去的心情； 3.文档标题、字体格式混乱，层次不清； 4.编写建议在文档完成后仍然保留。 * 关于格式，应尽可能使用模板自带的格式，如：标题1～4、正文首行缩进、表格文本、代码、图号等。 * 主动语气、被动语气： “本模块提供××功能”； “××功能被本模块提供”。 * 该练习突出基本要求中的几点： 1.句子和段落要短； 2.避免歧义； 3.应追求图文并茂的效果。 * 只是简单地进行了分段，阅读起来更有层次感更清晰。同时修正了“约”、“左右”等模糊的描述。 * 图形表述方式理解更容易，上图已将房间布局信息很清晰表达出来，缺的是尺寸信息，可以在图中标注或附以文字说明，则能完全表达清楚。 图形应具有“自明性”，即只看图，大体上就可理解图意。但不应为追求自明性而使图形过于杂乱，必要时应佐以少量的文字说明。 * 写作工程文档不同于文学创作，务必要严谨，避免使用白话。 * 用词要简洁. * 避免使用人称称谓。 * 避免使用“这”、“那”；避免使用白话。 * 一致性、清晰性。 * 需求设计合一模板 ＝ 需求模板 ＋ 移植设计模板。 对于规模在几百行的特性，建议使用需求设计合一的模板，但可以根据需要，参照独立的需求模板、设计模板增加一部分章节。 对于规模上千行的特性，建议大家还是使用独立的需求模板和设计模板写作。 后面内容主要针对独立的需求模板和移植设计模板进行讲解，设计模板仅简单介绍。 * 完整性：一是功能点不能少，所有的分配需求(AR)都必需实现；二是每个功能点内的描述必须完整，专用的术语、缩略语要进行解释，输入、处理、输出不能有遗漏，可以结合SLOC项目举例说明。 清晰性：需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。反例：“代码行统计性能很高”。 一致性：不能与AR矛盾；前后的多项需求或者一项需求不能出现前后矛盾的说法。反例：AR要求统计物理代码行，需求却统计了逻辑代码行；AR与SRS针对注释行的定义不一致等等。 可行性：每一项需求都必须是在已知系统和环境的限制范围内可以实现的。举例：下水道井盖为什么要做出圆形，而不做成正方形、长方形、椭圆形或六边形等 可验证性：每一项需求是否能够通过设计测试用例或其它方法来确定产品是否确实按照需求实现了。举例：上述不清晰的需求一般也不可验证。 * 除上述不足之外，该需求点还存在如下问题： 1.标题中不应再包含“Functional Requirements1 功能需求1”的描述 2.…… * 关于“流畅”－以周杰伦唱歌为例，其fans肯定认为很流畅，其他不少人则不会这么认为。 * * 这里的图形只是给出一个概要性描述的示例，并不表示概要性描述必须采用这种方式或者此为标准的表达图形。 * 同样，这里的图形也仅仅是一个示例而已。 * * * 第2个大家可能会有歧义，虽然是对稳定性的描述，但实际上是需要调用acl模块提供的维护和匹配接口，所以也是作为依赖。 * 请大家在课下通过ATM样例了解DFD，课堂上不详细介绍。 * 需求设计合一模板中，功能需求还有第五部分：继承性 5.Inherit继承性 注明本需求与移植代码需求的继承性，分级： （1）Old-不需要改动 （2）Update-需要改进 （3）New-新增功能 * * 不用人为构造功能需求。 * 功能点分解一定要合理，不能太粗，也不能强凑篇幅。 * 美女－美的评判标准是什么？ * 设计文档写作重点介绍移植项目设计文档的写作要点，这里对开发项目设计文档写作仅简单介绍。 ①上下文定义： 描述模块（系统）与外部实体之间的交互关系（即上下文），即如何配合来实现既定的功能； 应描述所有外部实体与本模块消息流、数据流，或者函数调用关系； 最好结合图形介绍。 ②设计思路： 可选，描述本软件系统所采取的设计方法，多种设计方案之间的对比，以及相关的技术限制。 ③分解描述： 具体包括模块分解、进程分解、数据分解。每级只关注本级的设计。 分解描述要先描述系统/模块的整体结构，再描述每个组成模块的