结构化分析之需求分析PPT文档格式.pptx

结构化分析之需求分析PPT文档格式.pptx

《结构化分析之需求分析PPT文档格式.pptx》由会员分享，可在线阅读，更多相关《结构化分析之需求分析PPT文档格式.pptx（37页珍藏版）》请在冰豆网上搜索。

等一下，另外我不要大蒜：

不是让你们不要放大蒜吗？

怎么还有？

：

我们这里有拉面、牛肉面、刀削面：

牛肉面需要加辣椒吗？

好嘞，来这是你要的面：

你刚刚没说啊难道是我听错了2016/10/2需求分析和规格说明阶段的基本概念3小明提出问题小明不知道餐馆能做什么服务员需要代表“餐馆”说明餐馆能“做什么”小明确定了需要的面食，但是小明仍然不能确定面食中的佐料有哪些服务员知道了小明的需求，同时也就确定了“做什么”同时根据服务员过去的经验，提出了小明可能关心的问题，予以确认可以看出在小明说“谢谢”这之前他与服务员的沟通是很顺利的此时只有服务员自己知道，刚刚问辣椒的时候面的佐料都已经放好了，最后的“听错了”只是为自己找台阶下而已小明比作用户，服务员比作软件人员，那么他们沟通的最基本目标是通过沟通明确出要“做什么”，不需要关注怎么做服务员在这个过程中有一个简短的分析过程就是“确认是否需要辣椒”，这个过程映射到软件层面就是“分析阶段是面向问题”，这里的问题主要依据双方过往的经历和经验发现自己不能理解或者对方不能理解的事物拿出来共同讨论和确认最终结果要的是什么根据小明吃饭的最后遭遇说明，用户的要求可能来自多方面，映射到软件层面就是功能要求、性能要求、可靠性要求等等，在未明确用户各方面的要求情况下不应该也不允许立刻动手做服务员当时要是能够通过手动记录或者打单系统输出一份单据，那么这样也就没有了后续的不愉快，所以用户与软件人员沟通的产物还应该有一个具体的说明性质的并且双方能够看懂的文档最好2016/10/2需求分析和规格说明阶段的基本概念4需求分析和规格说明阶段又称为需求确定阶段和或分析阶段，其目的是澄清用户的需求。

这个阶段的基本任务是：

用户和软件人员双方一起来充分地理解用户的要求，并把双方共同的理解明确地表达成一份书面文档需求说明书。

分析阶段的两大任务就是“理解”和“表达”，分析就是理解问题，“规格说明”就是按某种标准的方式把问题表达出来2016/10/2需求分析和规格说明阶段的基本概念5作为用户和软件人员之间的合同，为双方相互了解提供基础反映出问题的结构，可以作为软件人员进行设计和编写的基础作为验收的依据，即作为选取测试用例和进行形式验证的依据注：

需求说明书应该即完整、一致、精确、无二义、又要简明易懂并易于维护2016/10/2需求分析和规格说明阶段的基本概念6这是一个忧伤的故事.小明年幼的时候家里很穷，看着电视里小朋友能玩各种玩具是非常的羡慕，其中对于玩具车的偏爱，对年幼的小明来说就是遥不可及的梦想小明虽然没有车，但是小明见过邻居家的打米机，通过柴油机带动打米机就能工作。

小明虽然没有车，但是知道爸爸买回来的录音机可以插入磁带就能转动发出声音。

就这样在一个罪恶的晚上，小明摔坏了爸爸的录音机，挨了一顿打，身上很疼，但是心理却很开心。

小明拿着录音机中的马达电动机，拿着一根妈妈弄头发的胶圈（quan）,再拿着很长时间收集的几个大小不一的玩具车轮，开始了实现他的梦想之旅.年幼的小明不知道的是当他做完这辆小车后，他已经学会了初中物理的力学知识，他还不知道的是他已经学会了一套分析问题看待问题的方法等等为了梦想，一切的付出都是值得的。

2016/10/2结构化分析（SA方法）概述7小明造车的故事告诉我们看问题要看到本质“车能跑，不止是因为有轮子”那么当我们把复杂的问题抛出来以后怎么解决呢？

那就是“把复杂的问题简单化，把简单的问题具体化”，这句话对应到我们软件层面就是“结构化分析”“复杂问题简单化”对应到我们的软件结构化分析就是“分解”，如何做好简单化呢？

就是把大问题分解成若干小问题，然后分别解决。

“简单问题具体化”对应到我们的软件结构化分析就是“抽象”，如何做好具体化呢？

还得从分解说起，当我们把问题分解到足够细的时候，这时候我们一般就能看到问题的本质，然而分解后的问题大问题没了，小问题很多，这时候我们就要去做一个分层筛选，把每一个层次的重要部分抓取出来，省去细节，获取所有层面最本质的属性，对于后续工作的开展再逐层添加细节2016/10/2结构化分析（SA方法）概述8目前大多数计算机系统都是用来代替一个当前已经存在的人工数据处理系统，对于这类系统的分析过程可分为四步进行：

理解当前的现实环境，获得当前人工系统的具体模型；

从当前系统的具体模型抽象出当前系统的逻辑模型；

分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型；

为目标系统的逻辑模型做补充2016/10/2结构化分析（SA方法）概述9一套分层的数据流图一本数据词典一组小说明补充材料注：

以上就是用SA方法获得的需求说明书包含的几部分组成数据流图：

描述系统的分解，即描述系统由那几部分组成，各部分之间有什么联系等；

数据词典：

描述系统中的每一个数据小说明：

详细描述系统中的每一个加工补充材料：

额外的描述系统功能的材料2016/10/2结构化分析（SA方法）概述10如果我们打算把小明造车的实例拿来做一个类似软件层面的分析可得到如下初步的“数据流图”该“数据流图”我们也可以认为是玩具车制造厂商的设计过程2016/10/2数据流图11含义元素数据流图是SA方法中用于表示逻辑系统模型的一种工具，它从数据传递和加工的角度，以图形的方式来刻画数据流从输入到输出的变换过程:

数据流，是由一组固定成分的数据组成，箭头的方向表示数据的流向，箭头的始点和终点分别代表数据流的源和目标。

除了流向数据存储或从数据存储流出的数据不必命名外，每个数据流必须要有合适的名字，以反映数据流的含义；

:

外部实体，代表系统之外的实体，可以是人、物或其它系统软件，他指出数据所需要的发源地或系统所产生的数据归属地；

对数据进行加工处理，加工是对数据进行处理的单元，它接受一定的数据输入，对其进行处理，并产生输出；

数据存储。

表示信息的静态存储，可以代表文件、文件的一部分、数据库的元素等；

另外*和可以分别表示与和或，在数据输入或输出的时候使用，一般情况下不建议使用，这样会增加阅读的复杂度；

2016/10/2数据流图12对于任何一个系统，在刚开始时只是将现实情况反映出来，而不是急于去想象未来的计算机系统是怎么样，系统不一样，画出来的数据流图肯定不一样，但原则上都是“由外向里”进行的，“由外向里”是一种比较自然而且有条理的思考过程，通常人们观察事物的也基于此进行。

第一步：

画系统的输入输出，首先画系统的输入数据流和输出数据流，也就是先决定系统的范围，同样，对每一个加工来说也是先画出它们的输入输出，再考虑这个加工的内部；

第二步：

画系统的内部，此时需要将系统的输入输出数据流用一连串加工连接起来，一般可以从输入端逐步画到输出端，也可以反过来追溯。

在数据流的组成或者值发生变化的地方应画上一个加工，他的作用就是实现这一变化2016/10/2数据流图13图形绘制材料数据玩具车模型图第三步：

画加工的部分，同样用“由外向里”的方式，可以继续分析每个加工的内部，如果加工的内部还有一些数据流，即可将这个加工用几个子加工代替，并且在子加工之间画出这些数据流2016/10/2数据流图14采集人员设计图数据分类马达数据车轮数据马达设计车轮设计整车设计马达设计图车轮设计图玩具车模型图材料数据车身设计车身数据车身设计图对一个大型的系统，如果用一张数据流图画出所有的数据流和加工则图纸将变得很庞大复杂，难以理解，为了控制复杂性，SA方法采用了“分层”的技术逐层分解的方式不是一下子引进太多的细节，而是有控制的逐步增加细节，实现从抽象到具体的逐步过渡，用数据流图来描述“逐层分解”，就得到了一个分层的数据流图一套分层的数据流图由顶层、底层、和中间层组成。

顶层说明了系统的边界，即系统的输入和输出数据流，顶层图只有一张。

底层图由一些不必再分解的加工组成，在顶层和底层之间的是中间层，中间层的数据流图描述了某个加工的分解，而它的组成部分又要进一步被分解。

小系统可能没有中间层。

2016/10/2数据流图15编号，为了便于管理，需要为分层的数据流图定义编号1）子图的编号就是父图中相应加工的编号2）子图中加工的编号由子图号、小数点、局部号连接而成注：

顶层不需要编号，下一层可以用编号0，则图0中加工编号就是0.1、0.2、0.3等等，同时由于文档结构编写的习惯原因，我们去掉第一级的“0.”，保留1、2、3这样的一级目录，那么接下来的下一层就是1.1、1.2、1.3这样的编号了，如果我们的编号层级太复杂，可以在每一个中间层分层的加工中使用最后的编号比如“.1”、“.2”“.3”，但是相对应的小说明则必须写全编号2016/10/2数据流图161马达设计1.2磁铁设计图0图11.1线圈设计父图和子图的平衡，就是父图中的加工对应的输入输出，在子的数据流图中最开始的输入和最后的输出是能对应上的，这就叫平衡。

有一种例外的情况就是，父图的输入输出，与子图对应不上的时候，若是子图多出了很多输入或者输出数据流，此时若是在“数据词典”中对数据的输入输出做好了定义，也就是说，几个输入或者输出数据流对应了一个输入输出数据流，此时可以认为是平衡的。

举个例子，我们对“马达设计”做个小小的变更马达数据=线圈数据+磁铁数据2016/10/2数据流图171马达设计图0子图马达数据1.1马达内部设计磁铁数据线圈数据父图图11.2马达整体设计内部数据马达设计图马达设计图局部文件，在画分层数据流图时当分层到涉及到住够细的时候，一般为最底层，这时候可能会涉及到文件存贮部分，这时候就应该画出文件，而中间层由于从“抽象”原则上来讲，并不会关注加工下面的细节，所以不必画出文件部分分解的程度，一个加工每次分解到多少个子加工，经验得出的答案是7个1）分解应自然，概念上合理、清晰2）只要不影响数据库图的“易理解性”，可言适当的多分解成几个部分，这样分层图的层数可能就少些3）一般来说，在上层可言分解的快些，在下层分解的慢些，因为上层是一些综合性的描述，“易理解性”相对的来说不太重要，而下层由于跟具体，更贴近需求本身所以要慎重2016/10/2数据流图18父图和子图的输入输出数据流要“平衡”更加“抽象”原则，每张图只画出作为加工间交界面的文件和数据流，而不必画出加工内部的文件如果要了解某个加工内部的细节，可以阅读与这个加工的编号相同的一张图一个加工一般最多分解成7个子加工当每个加工都已经足够简单时，分解就可以结束2016/10/2数据流图19适当的命名数据流图中每一成分的命名是否恰当与数据流图的易理解性有直接的关系1）为避免引起错觉，名字要适合于整个数据流，而不是仅仅反应它的某些成分2）避免用空洞的名字，如“数据”“信息”“输入”“输出”，因为缺乏具体的含义3）如果发现难以为某个数据流命名，这往往是数据流图分解不当的征兆，需要从新尝试分解4）通常应先为数据流命名再为加工命名，这也反映了由外向里的思考过程5）为加工命名时，建议使用动词加名词的方式，若是涉及多个动词则建议把多个分开，分成多个加工画数据流而不是控制流常规的框图使用的箭头大多表示的是一个动作，这样，就与数据流图的符号定义产生了对立，因此要区分开，毕竟，数据流图是从数据的角度来描述一个系统2016/10/2数据流图20先考虑稳定状态画数据流图时先不考虑系统如何开始工作，如何结束，只假定它能开始运行就是了，这是为了集中精力考虑稳定状态下的种种问题，所以将系统的开始和结束推迟到适当的时候再考虑忽略琐碎的枝节画数据流图时，应集中精力于主要的数据流，而暂不考虑一些例外的情况、出错处理等枝节性问题，我们只需要画出这些枝节性数据流就可以了，而不必继续分析，因为这些问题对理解整个系统没有很大的影响，因此可以放心的推迟考虑随时准备重画一句话就是错误越早发现后期的代价就越