码迷,mamicode.com
首页 > 其他好文 > 详细

阅读笔记

时间:2017-09-29 19:44:47      阅读:165      评论:0      收藏:0      [点我收藏+]

标签:是什么   判断   扩展   信息   需求   范围   兴趣   软件   之间   

  这本书并不涉及定义粗求的流程,分析技术以及需求管理,不关注任何特定的方法论、办法,或者定义软件的工工具。

需求开发是探险之旅,不只是简单的手机或抄写的过程。

这本书分为两部分,第一部分:准备开始,分为4章,第一章讲述了一些基本原则,对阅读本书之后的部分有帮助,第二章描述了需求规格包括的素材的类型,第三章解释了什么是需求模式:基本要素,每个模式包括什么,他们如何组织形成领域,以及相关概念。第四章解释了如何使用需求模式,以及如何编写自己的需求模式。第二部分:需求模式目录 十一组经常出现的需求类型的模式。

而我到现在只是看完了前四章,也就是第一部分(准备开始)。

需求是定义系统需要做什么而不是怎么做。需求定义了必须解决的问题:系统的目的是什么,以及为了达到目的系统需要的所有功能。需求不定义解决方案。需求中不止一个合适的细节层次。可以在不同的细节层次定义需求。需求最重要的是定义了系统必须做什么和它必须能完成的行为。

定义需求的一些基本原则:1.定义问题,而不是解决方案;2.定义系统,而不是项目;3.区分正式和非正式部分;4.避免重复。

不同方法了呢的区别主要在整个流程实用的规模的大小不同,可以大到是整个系统(传统方法),也可以小到时手头的一块编码单元(极限流程)。 传统的定义需求的方法是,有一个专门的需求阶段,交付一份详细的需求规格,然后开始设计和开发系统。

需求规格的内容可以分为四部分:“介绍部分”,“上下文部分”,“功能域部分”和“主要非功能要求部分”。介绍部分:系统目的、文档目的、需求格式、词汇表、参考书目和文档历史。上下文部分:组件、用户角色、范围边界和系统间接口(也可以加上通信链路、主要的数据存储)。功能域部分:对每一个功能逻辑编写一个高层描述(给予每种用户的兴趣),按照功能域命名每个小节(如:客户功能)。主要非功能要求部分:是适用于整个系统。很难固定这部分的内容,因为这很大程度以来系统的特征。

需求模式剖析:基本细节、适用性、内容、模板、实例、额外需求、开发考虑、测试考虑。需求模式之间的关系:引用和扩展。

什么时候使用需求模式:当定义需求时、当考虑需求是否完全时、当评审需求规格时、当实现需求时、当测试需求时。

使用需求模式的好处:需求更容易阅读;需求更容易与同样类型的其他需求比较;可以判断是否有遗漏;编写需求更容易;读者可以参考编写的模式获得更多的信息;编写需求规格时可以参考模式;

使用需求模式的坏处:可能被诱导疏于思考;可能滥用模式;很多需求可能措辞相似。

阅读笔记

标签:是什么   判断   扩展   信息   需求   范围   兴趣   软件   之间   

原文地址:http://www.cnblogs.com/bai123/p/7612233.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!