1 / 82

The Definition Phase

The Definition Phase. System Engineering. Software project planning. Software scope. Software requirements analysis. Refined. 确定做什么 ?. 软件需求分析. 众所周知，在解决问题之前必须首先理解所要解决的问题。对问题理解得越透彻，就越容易解决它。当我们完全、彻底地理解了一个问题的时候，通常就已经解决了这个问题。. 软件需求分析.

gardenia-dudley
Download Presentation

The Definition Phase

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Definition Phase System Engineering Software project planning Software scope Software requirements analysis Refined 确定做什么? SOFTWARE ENGINEERING

  2. 软件需求分析 • 众所周知，在解决问题之前必须首先理解所要解决的问题。对问题理解得越透彻，就越容易解决它。当我们完全、彻底地理解了一个问题的时候，通常就已经解决了这个问题。 SOFTWARE ENGINEERING

  3. 软件需求分析 • 为了更好地理解问题，人们常常采用建立问题模型的方法。所谓模型，就是为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图示符号和组织这些符号的规则组成，利用它们来定义和描述问题域中的术语和概念。更进一步讲，模型是一种思考工具，利用这种工具可以把知识规范地表示出来。 SOFTWARE ENGINEERING

  4. 软件需求分析 • 模型可以帮助我们思考问题、定义术语、在选择术语时作出适当的假设，并且可以帮助我们保持定义和假设的一致性。 • 在对目标系统进行分析的初始阶段，面对大量模糊的、涉及众多专业领域的、错综复杂的信息，系统分析员往往感到无从下手。模型提供了组织大量信息的一种有效机制。 SOFTWARE ENGINEERING

  5. 软件需求分析 • 为了开发复杂的软件系统，系统分析员应该从不同角度抽象出目标系统的特性，使用精确的表示方法构造系统的模型，验证模型是否满足用户对目标系统的需求，并在设计过程中逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型。 SOFTWARE ENGINEERING

  6. 软件需求分析 • 对于那些因过分复杂而不能直接理解的系统，特别需要建立模型，建模的目的主要是为了减少复杂性。人的头脑每次只能处理一定数量的信息，模型通过把系统的重要部分分解成人的头脑一次能处理的若干个子部分，从而减少系统的复杂程度。 SOFTWARE ENGINEERING

  7. 软件需求分析 • 一旦建立起模型之后，这个模型就要经受用户和各个领域专家的严格审查。由于模型的规范化和系统化，因此比较容易暴露出系统分析员对目标系统认识的片面性和不一致性。通过审查，往往会发现许多错误，发现错误是正常现象，这些错误可以在成为目标系统中的错误之前，就被预先清除掉。 SOFTWARE ENGINEERING

  8. 软件需求分析 • 通常，通过快速建立原型，让用户和领域专家经过亲身体验，对系统模型进行更有效的审查。模型常常会经过多次必要的修改，通过不断改正错误的或不全面的认识，最终，软件开发人员对问题有了透彻的理解，从而为后续的开发工作奠定了坚实基础。 SOFTWARE ENGINEERING

  9. 软件需求分析的任务 • 为了开发出真正满足用户需求的软件产品，首先必须确切地知道用户的需求。对软件需求的深入理解，是软件开发工作获得成功的前提和关键，不论我们把设计和编码工作做得多么出色，不能真正满足用户需求的软件只会给用户带来失望，给开发者带来烦恼。 • 需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题。 SOFTWARE ENGINEERING

  10. 软件需求分析的任务 • 需求分析是定义软件的最后一个阶段，也是最重要的一个阶段，其基本任务是对目标系统提出完整、准确、清晰、具体的要求。 • 需求分析的结果是系统开发的基础，关系到工程的成败和软件产品的质量。因此，必须采取行之有效的办法对需求分析进行严格的审查和验证。 • Boehm对软件需求的定义：研究一种无二义性的表达工具，它能为用户和软件人员双方都接受并能够把“需求”严格地、形式地表达出来。 SOFTWARE ENGINEERING

  11. 软件需求分析 • 在编程过程中，事情总是会变得清晰；只有在检验了软件的早期版本后项目共利益者才能够更好地理解需求；事情变化太快，需求工程是浪费时间；底线是开发一个可运行的程序，其他都是次要的。 • 构成这些论点的原因在于其中也包含了部分的真实情况（尤其是不超过一个月的小项目）。 SOFTWARE ENGINEERING

  12. 信息技术项目成功的3要素 • 用户参与程度 • 高级管理层的支持 • 明确的需求说明 SOFTWARE ENGINEERING

  13. 软件需求分析的困难 • 懂得应用领域专业知识的人很可能不是实际编写软件的人。这些应用领域的专家因而必须将他们的需求告诉软件开发的技术人员。 • 口头、书面语言中所固有的模糊性给领域专家与开发软件的技术人员之间的交流增添了一层复杂性。 • 我们都拥有自己不同的背景知识，它导致基于以往的经验对相同的现象做出不同的解释。 SOFTWARE ENGINEERING

  14. 软件需求分析的困难 • 在系统开发的每个阶段应该让未来用户参与，不论这些未来用户是否是领域专家。在软件开发过程中，软件开发的计划有必要允许最终用户来评价该系统。 • 不幸的是，许多软件企业的人相信只需要在系统开发早期阶段和开发完成时，向用户了解专业知识。这种态度很可能会导致许多软件开发项目的失败。 SOFTWARE ENGINEERING

  15. 软件需求分析的任务 • 1、确定系统的综合要求 • 系统功能要求 • 系统性能要求：如响应时间、存储容量、安全性能等。 • 系统运行要求：主要是对系统运行时的环境要求，如系统软件、外存和数据通信接口等。 • 将来可能提出的要求：为扩充及修改作准备。 • 2、分析系统的数据要求 • 3、导出系统的逻辑模型:用DFD、DD等描述 • 4、修正系统的开发计划：通过需求对系统的成本及进度有了更精确的估算，可进一步修改开发计划。 SOFTWARE ENGINEERING

  16. 软件需求分析的任务 -----分析系统的数据要求 • 任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。 SOFTWARE ENGINEERING

  17. Software Requirements Analysis 软件需求分析 • 有几种原因使需求分析变得困难：（1）客户说不清楚需求或无需求，用户意见不统一，错误的需求等；（2）需求自身经常变动；（3）分析人员或客户理解有误，缺乏共同语言，交流障碍。 • 让我们先接受“需求会变动”这个事实吧，免得在需求变动时惊慌失措。错误观点：反正“需求会变动”，软件也很灵活，所以只做简单的需求分析就开始编程更有效。 SOFTWARE ENGINEERING

  18. Software Requirements Analysis 软件需求分析 • 如果客户本身就懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。 • 如果客户全不懂软件，但信任软件开发方，这事也好办。分析人员可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。 • 最怕的就是“不懂装懂”或者“半懂充内行”的客户，他们会提出不切实际的需求。如果这些客户甚至觉得自己是上帝的父母，那么沟通和协商都会很困难。 SOFTWARE ENGINEERING

  19. Software Requirements Analysis 软件需求分析 • 在进行需求分析时必须注意： （1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上。（2）在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。 SOFTWARE ENGINEERING

  20. Software Requirements Analysis 软件需求分析 • 系统分析人员不可能都是全才。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致开发人员白干活。 • 所以分析人员写好需求说明书后，要请客户方的各个代表验证。如果问题很复杂，双方都不太明白，就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。 • 由于客户大多不懂软件，他们可能觉得软件是万能的，会提出一些无法实现的需求。有时客户还会把软件系统分析人员的建议或答复给想歪了。 SOFTWARE ENGINEERING

  21. Software Requirements Analysis 软件需求分析 • 应该先了解宏观的问题，再了解细节的问题。 • 了解需求的方式有好几种： （1）直接与客户交谈。（2）有些需求客户讲不清楚，分析人员又猜不透，这时就要请教专家。（3）有很多需求可能客户与分析人员想都没有想过。要经常分析优秀的和蹩脚的同类软件，看到了优点就尽量吸取，看到了缺点就引以为戒。 SOFTWARE ENGINEERING

  22. Analysis Concept and Principles • A complete understanding of software require-ments is essential to the success of a software development effort. • The requirements analysis task is a process of discover,refinement,modeling,and specification. • Both the developer and customer take an active role in requirements analysis and specification. • Requirements analysis is a software engineering task that bridges the gap between system-level software allocation and software design. SOFTWARE ENGINEERING

  23. Software Requirements Analysis • Requirements analysis enables the system engineer to specify software function and performance,indicate software’s interface with other system elements,and establish constraints that software must meet. • Requirements analysis allows the software engineer(often called analyst in this role) to refine the software allocation and build models of the data,functional,and behavioral domains that will be treated by software. SOFTWARE ENGINEERING

  24. Software Requirements Analysis • Requirements analysis provides the software designer with models that can be translated in to data,architectural, interface,and procedural design. • Finally,the requirements specification provides the developer and the customer with the means to access quality once software is build. SOFTWARE ENGINEERING

  25. 系统分析员应有的能力 • 分析、综合、抽象能力； • 较好的口头和书面表达能力； • 很强的专业基础和软件过程经验； • 所开发的项目的专业背景，等。 • 分析员通常负责开发软件需求规格说明书，并参加所有的复审 • 制定软件需求规格说明书，不仅仅是软件开发人员的事，用户也起着至关重要的作用。 SOFTWARE ENGINEERING

  26. Software Requirements Analysis • Software requirements analysis may be divided into five areas of effort: • Problem recognition(问题识别); • Evaluation(评价) and synthesis(综合); • Modeling(建模); • Specification(软件需求规格说明);and • Review(评审或复审). SOFTWARE ENGINEERING

  27. Problem recognition • Initially,the analyst studies the system speci-fication(if one exists) and the software project plan.It is important to understand software in a system context and to review the software scope that was used to generate planning estimates. Next,communication for analysis must be established so that problem recogn-ition is ensured.The goal of analyst is recogn-ition of the basic problem elements as perceived by the user/customer. SOFTWARE ENGINEERING

  28. Evaluation and synthesis • Throughout evaluation and solution synthesis, the analyst’s primary focus is on “what,” not “how.”what data does the system produce and consume,what functions must the system perform,what interface are defined,and what constraints apply? • During evaluation and solution synthesis activity, the analyst creates models of the system in an effort to better understand data and control flow, functional processing and behavioral operation, and information content. SOFTWARE ENGINEERING

  29. Communication Techniques • Facilitated Application Specification Techniques (FAST:方便的应用规范技术):This approach encourages the creation of a joint team of customers and developers who work together to identify the problem, propose elements of the solution,negotiate different approach,and specify a preliminary set of solution requirements. SOFTWARE ENGINEERING

  30. Communication Techniques • Quality Function Deployment(QFD) is quality management technique that translates the needs of the customer into technical require-ments for software. • QFD emphasizes understanding of what is valuable to the customer and then deploying these value throughout the engineering process. • QFD identifies three types of requirements:1)Normal; 2)Expected; 3)exciting. SOFTWARE ENGINEERING

  31. Analysis Principles • The information domain of a problem must be represented and understood. • The function must is defined. • The behavior of software must be represented. • The models must be partitioned in a manner that uncovers details in a layered fashion. • The analysis process should move from essential information toward implementation detail. SOFTWARE ENGINEERING

  32. Essential and Implementation Views • An essential view of software requirements presents the functions to be accomplished and information to be process without regard to implementation. • The implementation view of software require-ments presents the real world manifestation of processing functions and information structures. In some cases,a physical representation is developed as the first step in software design. SOFTWARE ENGINEERING

  33. The Software Requirements Specification 其他系统元素（硬件等）的功能 商业需要 系统定义 代价、资源、进度 软件功能 软件计划 需求分析 软件作用范围 软件需求规格说明书 SOFTWARE ENGINEERING

  34. The Software Requirements Specification • 最好全部由用户/需求者编写，但实际上都由开发者和用户/需求者共同编写。 • 该说明书是分析和综合结果的描述，包括软件功能、性能、接口、有效性和逻辑模型的描述 • 软件需求规格说明书的描述方法： • 自然语言 • 格式化语言 • 形式化语言 SOFTWARE ENGINEERING

  35. The Software Requirements Specification （SRS outline） • Introduction • Information description • Functional description • Behavioral description • Validation criteria • Bibliography • Appendix • 编写初步用户使用手册和确认测试计划 SOFTWARE ENGINEERING

  36. The Software Requirements Specification • 正确性 • 无二义性 • 完整性 • 一致性 • 非计算机人员可以理解 • 可修改性 • 可跟踪性 SOFTWARE ENGINEERING

  37. Specification Review • 复审：该阶段完成标志（由用户/需求者，管理部门，开发人员共同承担） • Review of a software requirements specifica-tion(and/or prototype) is conducted by both software developer and customer.Because the specification forms the foundation for design and subsequent software engineering activities,extreme care should be taken in conducting the review. SOFTWARE ENGINEERING

  38. Specification Review • 采用需求确认检查单进行需求评审 • 正式技术评审 SOFTWARE ENGINEERING

  39. 验证软件需求的原则 • 作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性以及其他需求给予评价。 • 一致性：所有的需求是一致的，没有任何矛盾。 • 完整性：需求必须是完整的，没有任何功能和性能的遗漏。 • 现实性：完成需求所要求的软件和硬件条件，目前是可以达到的。 • 有效性：需求是有效的，可以解决用户的问题 。 SOFTWARE ENGINEERING

  40. Summary • Analysis must focus on the information, functional,and behavioral domains of a problem.To better understand what is required,models are created, the problem is partitioned,and representations that depict the essence of requirements and later, implementation detail,are developed. SOFTWARE ENGINEERING

  41. Summary • In many cases,it is not possible to completely specify a problem at an early stage.Prototyping offers an alternative approach that results in an executable model of software from which requirements can be refined. • 开发原型系统将使系统的需求更完整、准确、合理，对提高开发成功率，对提高软件质量都有很大好处。但是要增加开发的成本。 • 对于用户和系统分析员都不熟悉的系统，以及批量生产的软件，应开发原型系统。 SOFTWARE ENGINEERING

  42. Summary • A software requirements specification is developed as a consequence of analysis. Review is essential to ensure that developer and customer have the same perception of the system.Unfortunately, even with the best of methods,the problem is that problem keeps changing. SOFTWARE ENGINEERING

  43. 需求分析方法（1） • 功能分析方法(Function Decomposition) • 以系统需要提供的功能为中心来组织系统。首先定义各种功能，然后把功能分解为若干子功能,同时定义功能之间的接口。子功能还可继续分解。数据结构是根据功能/子功能的需要设计的。易开始，难深入，也难于检验分析结果的正确性，同时对需求变化的适应能力差，局部错误和局部修改很容易产生全局性的影响。 SOFTWARE ENGINEERING

  44. 需求分析方法（2） • 结构化分析方法（数据流法） • 其基本策略是跟踪数据流，从问题空间到某种表示的映射方法，由数据流图（DFD图）表示。SA法更加强调问题域的研究，有严格的原则，当系统较复杂时，很难检验分析的正确性，对需求变化的适应能力较差，没有一种严格的、可操作的转换规则，所以从分析到设计的过渡比较困难。 SOFTWARE ENGINEERING

  45. 需求分析方法（3） • 信息建模法 • 是从数据的角度对现实世界建立模型的,基本工具是E-R图。 • 面向对象的分析方法 • 面向对象的分析方法（OOA）的关键是识别问题域内的对象，分析它们之间的关系，并建立起系统模型。OOA采用封装、继承、消息通信等原则，使问题域的复杂性得到了控制。----UML SOFTWARE ENGINEERING

  46. Analysis Modeling • Structured Analysis(SA):is a classical modeling method • Object-Oriented Analysis(OOA) • Other analysis method:Data Structured Systems Development (DSSD);Jackson System Development(JSD);Structured Analysis and Design Technique (SADT) SOFTWARE ENGINEERING

  47. Analysis Modeling • The analysis model must achieve three primary objectives:(1)to describe what the customer requires,(2)establish a basis for the creation of a software design,and(3)to define a set of requirements that can be validated once the software is built. SOFTWARE ENGINEERING

  48. 结构化分析方法（SA） • 结构化开发方法（Structured Develop-ing Method） 是现有的软件开发方法中最成熟、应用最广泛的方法，主要特点是快速、自然和方便。 • 结构化开发方法由结构化分析方法（SA法）、结构化设计方法（SD法）及结构化程序设计方法（SP法）构成。 SOFTWARE ENGINEERING

  49. 结构化分析方法（SA） • 结构化分析方法是面向数据流的需求分析方法。 • SA法是一种建模的活动，主要是根据软件内部的数据传递、变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。 • SA法的描述方法：1、分层的数据流图；2、数据词典；3、描述加工逻辑的结构化语言、判定表及判定树等 SOFTWARE ENGINEERING

  50. The elements of the analysis model • Data Flow Diagram(DFD)/ Data Dictionary(DD) /Process Specification • Entity-Relationship Diagram(ERD)/ Data Object Description • State-Transition Diagram(STD)/ Control Specification SOFTWARE ENGINEERING

More Related