需求分析实例.docx
《需求分析实例.docx》由会员分享，可在线阅读，更多相关《需求分析实例.docx（52页珍藏版）》请在冰点文库上搜索。
需求分析实例
第2章需求分析2
2.1需求分析的任务3
2.2需求分析的原则4
2.3可行性研究5
2.3.1可行性研究的任务5
2.3.2可行性研究的步骤6
2.3.3系统流程图8
2.4需求分析方法10
2.4.1结构化分析方法10
2.4.2面向对象分析方法与UML19
2.5软件需求分析建模与规格说明27
2.5.1需求分析建模27
2.5.2规格说明及形式化说明技术27
2.6软件需求正确性验证29
2.6.1软件需求正确性要求和验证方法29
2.6.2用于需求分析的软件工具30
2.7需求分析指南31
本章小结32
习题33
第2章
需求分析
本章要点
✧需求分析的任务和原则
✧可行性研究的任务和步骤
✧结构化分析方法和面向对象分析方法
✧需求建模与规格说明
✧软件需求验证
本章学习目标
✧了解需求分析的任务和原则
✧掌握可行性研究的步骤
✧掌握结构化分析分析方法和面向对象分析方法
✧了解需求建模与规格说明
✧了解软件需求验证方法和有关工具
✧
✧
2.1需求分析的任务
需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?
”这个问题。
虽然在可行性研究阶段已经粗略了解了用户的需求，甚至还提出了一些可行的方案，但是，可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的解法，因此许多细节被忽略了。
然而在最终的系统中却不能遗漏任何一个微小的细节，所以可行性研究并不能代替需求分析，它实际上并没有准确地回答“系统必须做什么?
”这个问题。
需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
可行性研究阶段产生的文档，特别是数据流图，是需求分析的出发点。
数据流图中已经划分出系统必须完成的许多基本功能，在需求分析阶段系统分析员将仔细研究这些功能并进一步将它们具体化。
在这个阶段结束时交出的文档中应该包括详细的数据流图，数据字典和一组简明的算法描述。
需求分析的结果是系统开发的基础，关系到工程的成败和软件产品的质量。
因此，必须用行之有效的方法对软件需求进行严格的审查验证。
下面简要叙述需求分析阶段的具体任务。
一、确定对系统的综合要求。
对系统的综合要求有下述四个方面：
1．系统功能要求
应该划分出系统必须完成的所有功能。
2．系统性能要求
例如，联机系统的响应时间（即对于从终端输入的一个“事务”，系统在多长时间之内可以做出响应），系统需要的存储容量以及后援存储，重新启动和安全性等方面的考虑都属于性能要求。
3．运行要求
这类要求集中表现为对系统运行时所处环境的要求。
例如，支持系统运行的系统软件是什么，采用哪种数据库管理系统，需要什么样的外存储器和数据通信接口等。
4．将来可能提出的要求
应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。
这样做的目的是在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦需要时能比较容易地进行这种扩充和修改。
二、分析系统的数据要求
任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。
分析系统的数据要求通常采用建立概念模型的方法。
复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。
利用数据字典可以全面准确地定义数据，但是数据字典的缺点是不够形象直观。
为了提高可理解性，常常利用图形工具辅助描绘数据结构。
常用的图形工具有层次方框图和Warnier图。
软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。
三、导出系统的逻辑模型
综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、数据字典和主要的处理算法描述这个逻辑模型。
四、修正系统开发计划
根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。
五、开发原型系统
在计算机硬件和许多其它工程产品的设计过程中经常使用样机。
建造样机通常有两个主要目的：
检验关键设计方案的正确性及系统是否真正满足用户的需要。
对于软件系统的开发，使用“样机”（更正确的名称应该是原型系统）的主要目的是，使用户通过实践获得关于未来的系统将怎样为他们工作的更直接更具体的概念，从而可以更准确地提出和确定他们的要求。
把建立原型系统作为一种可能采取的策略的主要理由如下：
（1）由于人类认识能力的局限，不能预先指定所有要求；
（2）在用户和系统分析员之间存在固有的通信鸿沟；
（3）用户需要一个“活的”系统模型，以便获得实践经验；
（4）在开发过程中重复和反复是必要的和不可避免的；
（5）目前有快速建立原型系统的工具可供选用。
用户试用了原型系统以后能够指出系统的哪些特性是他们喜欢的，哪些是他们感到不能接受的，以及他们还需要哪些新的功能。
根据经过实践检验的用户需求而开发出来的系统，更可能真正满足用户的需要。
特别在所开发的系统是全新的，用户一点也没有使用类似系统的经验时，更应该认真考虑开发原型系统的必要和可能。
在软件开发中采用样机策略的主要困难是成本问题。
对于一次设计后大批量生产的产品（例如，计算机硬件和绝大多数工业产品），设计和制造样机的费用可以分摊到每件产品上，因此每件产品的成本增加很少。
软件，特别是应用软件，通常一次只开发出一件产品，采用样机策略则成本增加很多，因此过去很少采用这种策略。
但是，由于正确地提出用户需求是软件开发工程成功的基础，近年来主张采用样机策略的人逐渐多起来了。
此外，目前有一些较好的工具可供建立软件的原型系统用，这就为在软件开发中采用样机策略奠定了必要的物资基础。
近年来不仅在验证软件需求时使用软件原型，原型法还逐渐发展成为开发软件的一种重要方法。
2.2需求分析的原则
需求分析的前提是准确、完整地获取用户需求。
向问题领域的专家学习，进行用户需求查是需求分析的第一步。
用户需求通常可以分为功能需求和性能需求两类。
功能需求定义了系统应该做什么，系统要求输入什么信息，输出什么信息，以及如何将输入变换为输出。
性能需求则定义了软件运行的状态特征，如系统运行效率，可靠性，安全性，可维护性等等。
综合起来，应该获取用户需求的内容包括：
（1）物理环境。
系统运行的设备地点、位置是集中式的还是分布式的，对环境的要求如何（如温度、湿度，电磁场干扰等）。
（2）系统界面。
要求与其他系统进行数据交换的内容与格式，终端用户的类型与熟练程度，用户对界面的特定要求，用户操作的易接受性等。
（3）系统功能。
系统应该完成的功能以及何时完成，对于系统运行速度、响应时间或者数据吞吐量的要求，系统运行的权限规定，系统可靠性要求，是否要求可移植，未来扩充或者升级的要求。
（4）数据要求。
输入偷出数据的种类与格式，计算必须达到的精度，数据接收与发送的频率，数据存储的容量和可靠性，数据或者文件访问的控制权限，数据备份的要求。
（5）系统文档规格。
系统要求交付什么文档，各类文档的编制规范和预期使用对象。
（6）系统维护要求。
系统出错后可以允许的最大恢复时间，对错误修改的回归测试要求，系统运行日志规格，是否允许对系统修改，系统变化如何反映到设计中。
在获取需求过程中遇到的典型问题是：
（1）如何理解问题。
大多数情况下，软件开发人员不是问题领域的行家。
但是要准确、完整的获取需求必须对问题具有深入的理解与把握。
许多问题即使是用户业务人员也可能没有自觉的认识。
（2）分析员与用户的通信问题。
分析员对问题的理解必须从信息处理要求出发，而用户更多的考虑是本身的业务领域。
与用户建立相互信任、有效的沟通是分析员的首要任务。
（3）用户需求的可变性。
用户需求通常是不断变化的，而软件开发人员则希望将需求冻结在某一时刻。
影响用户需求变化的因素可以是用户领域的业务扩充或者转移，市场竞争的要求，用户主管人员的变更等。
现实情况是分析员只能接受需求不断变化的事实，应该千方百计地使其工作适应需求的变化。
现实世界是复杂多变的。
为了将现实世界中问题的求解映射为信息处理模型，对问题进行分解与抽象是普遍有效的基本法则。
分解是将复杂问题求解分解为若干相对简单问题求解的组合。
例如为实现一个计算机考试系统，我们可以将该系统分解为试题库维护，试题生成，考务管理，学生考试和计算机阅卷五个子系统，定义好各子系统之间的相互联系，对每个子系统分别求解。
分解的目的是为了降低问题求解的复杂性。
如子问题仍然较复杂，则可以进一步分解。
抽象是认识问题的一般与特殊的关系。
例如对于上面的考试系统我们可以考虑考试要求的不同试题类型，构造每种类型的典型试题，通过对典型试题的答题要求和阅卷判定方法分析，抽象出各类试题的不同答题模式和计算机阅卷策略与算法。
问题分解与抽象定义了问题的层次结构，应该在问题求解中反映出这种层次结构。
问题结构与问题求解结构的对应关系保证了问题定义的完整性、正确性和可跟踪性。
2.3可行性研究
2.3.1可行性研究的任务
并不是所有问题都有简单明显的解决办法，事实上，许多问题不可能在预定的系统规模之内解决。
如果问题没有可行的解，那么花费在这项开发工程上的任何时间、资源、人力和经费都是无谓的浪费。
可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。
必须记住，可行性研究的目的不是解决问题，而是确定问题是否值得去解。
怎样达到这个目的呢?
当然不能靠主观猜想而只能靠客观分析。
必须分析几种主要的可能解法的利弊，从而判断原定的系统目标和规模是否现实，系统完成后所能带来的效益是否大到值得投资开发这个系统的程度。
因此，可行性研究实质上是要进行一次大大压缩简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。
首先需要进一步分析和澄清问题定义。
在问题定义阶段初步确定的规模和目标，如果是正确的就进一步加以肯定，如果有错误就应该及时改正，如果对目标系统有任何约束和限制，也必须把它们清楚地列举出来。
在澄清了问题定义之后，分析员应该导出系统的逻辑模型。
然后从系统逻辑模型出发，探索若干种可供选择的主要解法（即系统实现方案）。
对每种解法都应该仔细研究它的可行性，一般说来，至少应该从下述三方面研究每种解法的可行性：
（1）技术可行性使用现有的技术能实现这个系统吗?
（2）经济可行性这个系统的经济效益能超过它的开发成本吗?
（3）操作可行性系统的操作方式在这个用户组织内行得通吗?
分析员应该为每个可行的解法制定一个粗略的实现进度。
当然，可行性研究最根本的任务是对以后的行动方针提出建议。
如果问题没有可行的．解，分析员应该建议停止这项开发工程，以避免时间、资源、人力和金钱的浪费；如果问题值得解，分析员应该推荐一个较好的解决方案，并且为工程制定一个初步的计划。
可行性研究需要的时间长短取决于工程的规模，一般说来，可行性研究的成本只是预
2.3.2可行性研究的步骤
怎样进行可行性研究呢?
典型的可行性研究过程有下述一些步骤。
一、复查系统规模和目标
分析员访问关键人员，仔细阅读和分析有关的材料，以便对问题定义阶段书写的关于规模和目标的报告书进一步复查确认，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束。
这个步骤的工作，实质上是为了确保分析员正在解决的问题确实是要求他解决的问题。
二、研究目前正在使用的系统
现有的系统是信息的重要来源。
显然，如果目前有一个系统正被人使用，那么这个系统必定能完成某些有用的工作，因此，新的目标系统必须也能完成它的基本功能；另一方面，如果现有的系统是完美无缺的，用户自然不会提出开发新系统的要求，因此，现有的系统必然有某些缺点，新系统必须能解决旧系统中存在的问题。
此外，运行使用旧系统所需要的费用是一个重要的经济指标，如果新系统不能增加收入或减少使用费用，那么从经济角度看新系统就不如旧系统。
应该仔细阅读分析现有系统的文档资料和使用手册，也要实地考察现有的系统。
应该注意了解这个系统可以做什么，为什么这样做，还要了解使用这个系统的代价。
在了解上述这些信息的时候显然必须访问有关的人员。
在调查访问时分析员和用户之间的关系有点类似于医生和病人的关系，用户叙述的往往是“症状”而不是实际问题，分析员必须分析解释所得到的信息。
常见的错误做法是花费过多时间去分析现有的系统。
这个步骤的目的是了解现有系统能做什么，而不是了解它怎样做这些工作。
分析员应该画出描绘现有系统的高层系统流程图，并请有关人员检验他对现有系统的认识是否正确。
千万不要花费太多时间去了解和描绘现有系统的实现细节，例如，除非是为了阐明一个特别关键的算法，否则不需要根据程序代码画出程序流程图。
没有一个系统是在“真空”中运行的，绝大多数系统都和其他系统有联系。
应该注意了解并记录现有系统和其他系统之间的接口情况，这是设计新系统时的重要约束条件。
三、导出新系统的高层逻辑模型
优秀的设计过程通常总是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统。
通过前一步的工作，分析员对目标系统应该具有的基本功能和所受的约束已有一定了解，能够使用数据流图，描绘数据在系统中流动和处理的情况，从而概括地表达出他对新系统的设想。
通常为了把新系统描绘得更清晰准确，还应该有一个初步的数据字典，定义系统中使用的数据。
数据流图和数据字典共同定义了新系统的逻辑模型，以后可以从这个逻辑模型出发设计新系统。
四、重新定义问题
新系统的逻辑模型实质上表达了分析员对新系统必须做什么的看法。
用户是否也有同样的看法呢?
分析员应该和用户一起再次复查问题定义、工程规模和目标，这次复查应该把数据流图和数据字典作为讨论的基础。
如果分析员对问题有误解或者用户曾经遗漏了某些要求，那么现在是发现和改正这些错误的时候了。
可行性研究的前四个步骤实质上构成一个循环。
分析员定义问题，分析这个问题，导出一个试探性的解；在此基础上再次定义问题，再一次分析这个问题，修改这个解；继续这个循环过程，直到提出的逻辑模型完全符合系统目标。
五、导出和评价供选择的解法
分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的（较抽象的）物理解法供比较和选择。
导出供选择的解法的最简单的途径，是从技术角度出发考虑解决问题的不同方案。
在数据流图上划分不同的自动化边界，从而导出不同物理方案的方法。
分析员可以确定几组不同的自动化边界，然后针对每一组边界考虑如何实现要求的系统。
还可以使用组合的方法导出若干种可能的物理系统，例如，在每一类计算机上可能有几种不同类型的系统，组合各种可能将有微处理机上的批处理系统，微处理机上的交互式系统，小型机上的批处理系统等方案，此外还应该把现有系统和人工系统作为两个可能的方案一起考虑进去。
当从技术角度提出了一些可能的物理系统之后，应该根据技术可行性的考虑初步排除一些不现实的系统。
例如，如果要求系统的响应时间不超过几秒钟，显然应该排除任何批处理方案。
把技术上行不通的解法去掉之后，就剩下了一组技术上可行的方案。
其次可以考虑操作方面的可行性。
分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的那些方案，去掉其中从操作方式或操作过程的角度看用户不能接受的方案。
接下来应该考虑经济方面的可行性。
分析员应该估计余下的每个可能的系统的开发成本和运行费用，并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。
在这些估计数字的基础上，对每个可能的系统进行成本／效益分析。
一般说来，只有投资预计能带来利润的系统才值得进一步考虑。
最后为每个在技术、操作和经济等方面都可行的系统制定实现进度表，这个进度表不需要（也不可能）制定得很详细，通常只需要估计生命周期每个阶段的工作量。
六、推荐行动方针
根据可行性研究结果应该做出的一个关键性决定是，是否继续进行这项开发工程。
分析员必须清楚地表明他对这个关键性决定的建议。
如果分析员认为值得继续进行这项开发工程，那么他应该选择一种最好的解法，并且说明选择这个解决方案的理由。
通常使用部门的负责人主要根据经济上是否划算决定是否投资于一项开发工程，因此分析员对于所推荐的系统必须进行比较仔细的成本／效益分析。
七、草拟开发计划
分析员应该进一步为推荐的系统草拟一份开发计划，除了工程进度表之外还应该估计对各种开发人员（系统分析员，程序员，资料员等等）和各种资源（计算机硬件，软件工具等等）的需要情况，应该指明什么时候使用以及使用多长时间。
此外还应该估计系统生命周期每个阶段的成本。
最后应该给出下一个阶段（需求分析）的详细进度表和成本估计。
八、书写文档提交审查
应该把上述可行性研究各个步骤的结果写成清晰的文档，请用户和使用部门的负责人仔细审查，以决定是否继续这项工程以及是否接受分析员推荐的方案。
2.3.3系统流程图
在进行可行性研究时需要了解和分析现有的系统，并以概括的形式表达对现有系统的认识；进入设计阶段以后应该把设想的新系统的逻辑模型转变成物理模型，因此需要描绘未来的物理系统的概貌。
怎样概括地描绘一个物理系统呢？
系统流程图是描绘物理系统的传统工具。
它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个部件（程序、文件、数据库、表格、人工过程等等）。
系统流程图表达的是信息在系统各部件之间流动的情况，而不是对信息进行加工处理的控制过程，因此尽管系统流程图使用的某些符号和程序流程图中用的符号相同，但是它却是物理数据流图而不是程序流程图。
一、符号
当以概括的方式抽象地描绘一个物理系统时，仅仅使用图2．1中列出的基本符号就
够了，其中每个符号表示系统中的一个部件。
符号
名称
说明
处理
能改变数据值或数据位置的加工或部件，例如，程序、处理机、人工加工等都是处理
输入／输出
表示输入或输出（或既输入又输出），是一个广义的不指明具体设备的符号。
连接
指出转到图的另一部分或从图的另一部分转来，通常在同一页上
换页连接
指出转到另一页图上或由另一页图转来。
数据流
用来连接其他符号，指明数据流动方向。
当需要更具体地描绘一个物理系统的时候还需要使用图2．2中列出的系统符号，利用这些符号可以把一个广义的输入／输出操作具体化为读／写存储在特殊设备上的文件（或数
据库），把一般的处理具体化为特定的程序或手工操作等等。
符号
名称
穿孔卡片
表示用穿孔卡片输入或输出，也可表示一个穿孔卡片文件。
文档
通常表示打印输出，也可表示用打印终端输入数据。
磁带
磁带输入／输出，或表示一个磁带文件。
联机存储
表示任何种类的联机存储，包括磁盘、磁鼓、软盘和海量存储器件等。
磁盘
磁盘输入／输出。
也可表示存储在磁盘上的文件或数据库。
磁鼓
磁鼓输入／输出，也可表示存储在磁鼓上的文件或数据库。
显示
CRT终端或类似的显示部件，可用于输入或输出，也可既输入又输出。
人工输入
人工输入数据的脱机处理，例如，填写表格。
人工操作
人工完成的处理，例如，会计在工资支票上签名。
辅助操作
使用设备进行的脱机操作。
通信链路
通过远程通信线路或链路传送数据。
二、例子
介绍系统流程图的最好方法可能是通过一个具体例子说明它的用法。
下面是一个简单的例子。
某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。
当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果那种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便定货，规定每天向采购部门送一次定货报告。
该装配厂使用一台小型计算机处理更新库存清单主文件和产生定货报告的任务。
零件库存量的每一次变化称为一个事务，通过放在仓库中的CRT终端输入到计算机中；系统中的库存清单程序对事务进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的定货信息写在磁带上。
最后，每天由报告生成程序读一次磁带，并且打印出定货报告。
图2．3的系统流程图描绘了上述系统的概貌。
注意图2．3如何描绘这个物理系统。
图中每个符号用黑盒子形式定义了组成系统的一个部件，然而并没有指明每个部件的具体工作过程；图中的箭头确定了信息通过系统的逻辑路径（信息流动路径）。
系统流程图的习惯画法是使信息在图中自顶向下或从左向右流动。
图2．3中每个符号都有名称，因此可以起文档的作用。
许多分析员喜欢在系统流程图上加上更详细的注释，甚至可以另加一页纸来解释系统流程图。
三、分层
面对复杂的系统时，一个比较好的方法是分层次地描绘这个系统。
首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。
然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。
这种分层次的描绘方法便于阅读者按照从抽象到具体的过程逐步深入地了解一个复杂的系统。
2.4需求分析方法
在软件工程学的需求分析中常用的方法通常采用结构化分析技术、面向对象分析技术，以及原型开发技术等。
下面仅对结构化分析技术做详细的介绍。
2.4.1结构化分析方法
结构化分析技术是70年代中期由E．Yourdon等人倡导的一种面向数据流的分析方法。
按照T．Demarco的定义，“结构化分析就是使用数据流图、数据词典、结构化英语、判定表和判定树等工具，来建立一种新的、称为结构化说明书的目标文档。
”这里的结构化说明书，就是需求规格说明书。
结构化分析技术将软件系统抽象为一系列的逻辑加工单元，各单元之间以数据流发生关联。
按照数据流分析的观点，系统模型的功能是数据变换，逻辑加工单元接受输入数据流，使之变换成输出数据流。
数据流模型常用数据流图表示。
2.4.1.1建立功能模型
数据流程图，又称数据流图，它是以图形的方式来表达数据处理系统中信
息的变换和传递过程。
作为一种描述手段，它可以模拟手工的、自动的以及两兼而有之混合的数据处理过程。
数据流程图有三个重要属性：
．可以表示任何一个系统（人工的、自动的或混合的）中的信息流程。
．每个圆圈可能需要进一步分解以求得对问题的全面理解。
．着重强调的是数据流程而不是控制流程。
以工资处理为例，我们画出这一过程中数据加工过程各项活动的数据流程图（见2.4）。
图2.4可知，数据流程图中的基本符号有：
1、数据流
现金
数据流是有名字有流向的数据，在数据流程图中，数据流用标有名字的箭头来表示，如图2.1中的工资调整表、工资发放表等。
现金
工资条
2、加工
加工又称处理逻辑，表示数据所进行的加工或变换，图2.4中以标有名字的圆圈代表加工。
指向加工的数据流是该加工的输入数据，离开加工的数据流是该加工的输出数据，如图2.4中的工资计算、取款等。
3、文件
文件是数据暂存的处所，可对文件进行必要的存取，在图中以标有名字的双直线段表示，如图2.1中的工资册、工资汇总表等。
对文件的存取分别以指向或离开文件的箭头表示。
由于文件的内容能顾名思义，因而对其进行存取的箭头即使没有名字也不会造成混乱。
4、数据源及数据终点
表明数据处理过程的数据来源或数据去向的标志称为数据源及数据终点，在数据流程图中均以命名的方框来表示，如图2.4中的人事（科）。
一般情况下，为了表达数据处理的数据加工过程，只用一个数据流程
升级会员 