安徽做网站找谁,wordpress适合中国的小插件介绍,做网站的流程百科,如何撤销网站上信息吗1、需求分析的重要性 软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。 通常#xff0c;软件生存周期包括可行性分析与开发项计划、需求分析、设计#xff08;概要设计和详细设计#xff09;、编码、测试、维护等活动。 常用的三种软件生命周期软件生存周期包括可行性分析与开发项计划、需求分析、设计概要设计和详细设计、编码、测试、维护等活动。 常用的三种软件生命周期瀑布模型、迭代式模型和快速原型模型中需求分析中都占据了举足轻重的作用是系统分析、软件编程、软件测试和系统维护的输入物。 1.1 瀑布模型 瀑布模型由于酷似瀑布闻名Waterfall Model首先由Royce提出。在该模型中首先确定需求并接受客户和SQA小组的验证。然后拟定规格说明同样通过验证后进入计划阶段…可以看出瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到因为整个的模型几乎都是以文档驱动的这对于非专业的用户来说是难以阅读和理解的。 瀑布模型图示如下 从上图可看出需求分析的产出物《需求规格说明书》有的项目组还会产出软件原型例如静态HTML原型等是后续设计、编码、测试和系统维护的基础。 可将瀑布模型的“需求分析”阶段细分为“软件概念”和“用户需求分析”两个阶段前者用于收集用户的原始需求包括用户在功能、行为、性能、设计约束等方面的期望并经过初步分析后形成《用户需求说明书》而后经过进一步分析将用户需求精确化、完全化最终形成《需求规格说明书》。 可将瀑布模型中的“系统设计”细分为“架构设计”和“详细设计”两个阶段前者在总体上把握更关注架构层面包括系统的总体架构以及各个子系统或各个模块之间的关系。后者更注重细节包括系统设计的方方面面都要在详细设计中有所体现。 作为系统分析师或系统架构师主要在“需求分析”和“系统设计”阶段体现自己的作用后续的各个阶段主要通过与项目组成员的沟通贯彻自己的设计。 1.2 迭代式模型 迭代式模型是是RUPRational Unified Process统一软件开发过程统一软件过程)推荐的周期模型。在RUP中迭代被定义为迭代包括产生产品发布稳定、可执行的产品版本的全部开发活动和要使用该发布必需的所有其他外围元素。 在某种程度上开发迭代是一次完整地经过所有工作流程的过程至少包括需求工作流程、分析设计工作流程、实施工作流程编码流程和测试工作流程。实质上可将它理解为多个小型的瀑布式项目。每一次的迭代都会产生一个可以发布的产品这个产品是最终产品的一个子集。 迭代式原型图示如下 在每一个迭代中“需求分析”阶段与瀑布模式一样是后续系统分析、编码和测试阶段依赖的基础。如果需求分析有较大偏差势必造成迭代过程中产生的一个产品子集有较大偏差。 1.3 快速原型模型 快速原型Rapid Prototype模型在功能上等价于产品的一个子集。注意这里说的是功能上。瀑布模型的缺点就在于不够直观快速原型法就解决了这个问题。一般来说根据客户的需要在很短的时间内解决用户最迫切需要完成一个可以演示的产品。 在得到用户的需求之后原型将被抛弃。因为原型开发的速度很快设计方面是几乎没有考虑的如果保留原型的话在随后的开发中会为此付出极大的代价。 在快速原型模型中原型最重要的目的是为了确定用户的真正需求。从某种程度上可以将快速原型理解为需求分析的一种更直观的方式也是业界比较认可和取得良好效果的一种方式。 2、需求分析的目标 通过对应问题及其环境的理解与分析为问题涉及的信息、功能及系统行为建立模型将用户需求精确化、完全化最终形成需求规格说明这一系列的活动即构成软件开发生命周期的需求分析阶段。 需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面需求分析以系统规格说明和项目规划作为分析活动的基本出发点并从软件角度对它们进行检查与调整另一方面需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误从而提高软件生产率降低开发成本改进软件质量。 3、如何进行需求分析 3.1 需求分析的困难 需求分析的目标说得通俗一点就是确定“做什么不做什么”。但需求分析却不像想象的那么简单主要因为如下原因 3.1.1 客户需求自身经常变动 这世间的一切只有“变化”是绝对的从这点来理解软件系统的需求不断变化也是可以理解的。老听设计人员和开发人员抱怨客户的需求老是变化其实应该将“需求变化”理解为一种常态。 引起需求变化的原因诸多例如 1因为某些前置条件未满足之前按照“妥协”方案实现但若在某个时间点上这些前置条件被满足于是引起了需求的变化。 2某个后台操作之前不需要走审批流程但因为客户的某个内部流程改变需要走审批流程势必引起需求 - 设计 - 编码 - 测试的一系列变更。 【对策】因为需求变动无可避免系统分析师在进行需求分析时需要明确 1尽可能地分析清楚哪些是稳定的需求哪些是易变的需求。以便在进行系统设计时将软件的核心建筑在稳定的需求上否则将会吃尽苦头。 2在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊日后扯皮的事情就多。小的变动影响不大也不致影响进度但是对于一些改动会引起设计重大改变的需求需要在合同中清楚说明。 3.1.2 客户说不清楚需求分析人员理解错误 客户的计算机水平、对需求的理解、表达程度都参差不齐。有些客户对需求只有朦胧的感觉当然说不清楚具体的需求。有些客户心里非常清楚想要什么但却说不明白。有的客户本身就懂软件开发能把需求说得清清楚楚这样的需求分析将会非常轻松、愉快。 不同性格、不同水平、与客户交流前准备情况不同的的系统分析师去跟客户讨论需求时会得到很不不一样的结果。 作为系统分析师可以引导客户先阐述常规的需求再由客户否定不需要的最终确定客户真正的需求。一个好的系统分析师能从客户的一两句话中提出很多自己的观点或可进行拓展进而进一步挖掘客户需求或者若与之前的需求矛盾可进行正确需求导向。 【对策】若客户说不清楚需求为了不造成理解错误系统分析师可采用多次沟通的方式例如第一次通过客户初步了解需求回去分析哪些是合理需求那些是自相矛盾或不合理的需求以及哪些是需要进一步明确的需求。经过细化后第二次交流可提供PPT或简单的Word文档与客户进行第二次深入交流。第三次交流可通过建立快速模型进一步与客户交流得到精确的需求。需求分析也可参考“迭代式模型”来进行不断迭代一直到挖掘出客户所有的潜在需求为止。 3.1.3 客户在没看到原型或完整系统时有一些潜在需求未被挖掘 甚至有不少这样的客户去进行需求沟通时提不出太多的需求但是在你做完整个系统时潜在需求突然迸发出来。 【对策】为了避免此种情况对项目造成破坏性影响建议相关人员为一些大的功能模块建立快速原型让客户进行确认并在合同中一定要说清楚“做什么”和“不做什么” 3.1.4 多个相关方需求相互冲突需求有二义性 若些需求若牵涉客户不同部门若有不一致意见若私自按某一方的意见进行修改很可能在后期涉及到按另一个部门的想法进行改造。 【对策】对于这种客户内部有冲突的需求需求组织客户方相关部门一起讨论由客户更高领导层决定实现哪一方的需求或者采用折衷方案。需求说明不可有二义性更不能前后相矛盾。如果有二义性或前后相矛盾则要重新分析此需求。 3.2 需求分析的活动 3.2.1 需求获取 通过与用户的交流对现有系统的观察及对任务进行分析从而开发、捕获和修订用户的需求。 软件需求常见的获取方法在《软件需求获取方法》一文中写得很详细如下 Ø 面谈 个人觉得面谈是获取软件需求的最有用的方法也是需求分析时常用的方法。通过多方面谈得到的信息最多进行我们现在所做的系统与移动集团客户部、业务支撑部、网管中心、系统运营人员等都进行过面谈。 面谈需准备的内容面谈对象和面谈问题。 面谈对象需要尽量让面谈对象包括可与系统相关的涉众并具有代表性保证涵盖到每个角色。一般包括谁为系统付费购买系统谁使用系统谁会受到系统结果的影响谁来监管该系统谁来维护系统 Ø 问卷调查 调查问卷无法取代面谈在需求获取阶段的作用问卷调查的问题和答案具有一定的引导性在某种程度上会影响结果。 问卷调查的结果好坏与问卷的设计有直接的关系在做这个项目时运营人员在进行前期推广会议上也给企业客户发过调查问卷但因为诸多原因效果不甚理想基本没为我们项目需求分析出多少力。 Ø 小组讨论 小组讨论是指将与项目某个问题相关的人员聚集在一起开会讨论。优势容易在内部取得对方案的认同有利于项目的开展在讨论会上每个相关人员都可发表自己的意见保证了获取信息的全面性。缺点不容易把握。 对于涉及系统边界的需求或一些相互冲突的需求采取该种方式是非常可取的。 Ø 情景串联 由于软件产品的抽象性大部分涉众在脑海子未有一个清晰的产品轮廓影响涉众对产品的理解。基于此可考虑编写清晰、完整的情景描述文档。 1、采用PPT加图片的方式描述情景一个好的PPT能更直观的描述各种情景 2、采用原型法比较推荐这种方法。 Ø 参与、观察业务流程 涉众描述的业务流程可能由于某些原因会遗漏掉重要的信息需求分析人员可申请参与到他们具体的工作观察、体验业务操作过程。需求分析员在观察业务操作过程时可根据实际的情况提问并详细记录记录业务操作员操作过程操作过程中碰到的难题可获取真实的材料和理解整个业务。 Ø 现有产品和竞争对手的描述文档 阅读现有产品文档有利于了解当前系统情况从中也可以了解业务流程对操作员反映的系统问题有着更深层次的理解。 3.2.2 需求建模 要有效地收集需求您要做的第一步是建模它包括创建体系结构的表示形式以捕获需求、就解决方案方法进行交流、以及分析所提出的系统设计。其目的是使用模型来表现系统中的关键方面。然后您可以在形式化的分析、模拟和原型设计中使用这些模型以研究预期的系统行为并且可以在编写文档或总结时使用这些模型以便就系统的性能和外观进行交流。 Ø 域建模 域建模指的是您对问题域创建相应的模型并且把它划分为若干个内聚组的过程。然后您可以在抽象模型中捕获业务流程、规则和数据。 域模型是一种用于理解问题域的工具。您需要从信息系统之外的角度来理解这个域这一点是很重要的。 Ø 用例建模 用例模型描述了各种参与者人和其他系统和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。 用例模型应该将系统放到上下文环境中显示系统和外部参与者之间的边界并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者例如用户和维护人员所看到的系统行为。 Ø 组件和服务建模 组件模型为子系统、模块和组件的层次结构分配需求和职责。每个元素作为一个自包含的单元以用于开发、部署和执行的目的。组件模型的元素由它们所提供和使用的接口来进行规定。在这里没有考虑其中的内部细节。 服务模型将应用程序定义为一组位于外部边界用例、架构层之间的抽象服务接口并且提供了通用的应用程序和基础结构安全、日志记录、配置等等。支持应用程序需求的这组服务可以与现有的内部和外部提供的接口规范相匹配。所得到的分析结果可以确定预置策略并将项目活动划分为特定类型的部分这取决于给定的服务是否已经存在内部或者外部的并且其中每个服务都具有适当的活动、存在但需要进行修改定义一个新的接口并规划其实现、或者必须构建新的服务。 Ø 性能建模 可以通过各种各样的方式来度量性能最显而易见的方式是应用程序执行其关键操作任务的速度。然而作为一名架构师必须考虑性能建模过程中其他的几个方面 l 构建和部署应用程序的速度如何 l 构建、维护和运行需要多少花费 l 该应用程序能在多大程度上满足其需求 l 对于必须使用该应用程序的人来说需要为其付出多大的开销 l 该应用程序会对其他应用程序和基础结构产生怎样的影响 【说明】需求建模是一门深奥的学问在做这个项目时需求建模基本只是用到了“用例建模”对一些典型流程进行用例建模。域建模、组件和服务建模和性能建模基本是空白状态希望在下一个项目中有所改进。 3.2.3 形成《需求规格说明书》 生成需求模型构件的精确的形式化的描述作为用户和开发者之间的一个协约。 3.2.4 需求验证 以需求规格说明为输入通过符号执行、模拟或快速原型等途径分析需求规格的正确性和可行性。 3.2.5 需求管理 支持系统的需求演进如需求变化和可跟踪性问题。 要在需求变更时同步更新《需求规格说明书》以及相关文档要知道一个正确的文档是指导软件系统不同阶段的参考但一个没有同步更新的文档是对软件系统有破坏性作用的相关人员会受到错误引导。 4、参考文档 1、《需求分析的作用及如何进行需求分析》张友生 http://www.educity.cn/se/requirement/200903310923051492.htm 2、《软件生命周期_百度百科》http://baike.baidu.com/view/3110371.htm 3、《软件项目需求分析困难的原因》 http://developer.51cto.com/art/200512/15979.htm 4、《需求建模》http://blog.csdn.net/weishaofei/article/details/4371584 5、《软件需求获取方法》http://blog.sina.com.cn/s/blog_646b84760100s645.html 6、《系统域建模技术》 http://wenku.baidu.com/view/8423fb97dd88d0d233d46ace.html转载于:https://www.cnblogs.com/h2zZhou/p/5343654.html
