搜索
讨论你认为“什么是需求”？日常工作中，遇到与“需求”相关的问题有哪些？关于“需求”最大的困惑是什么？以下问题中，对你影响最大的是哪个？不切实际的用户需求很多需求最终是不需要的用户介入太少需求不完整需求变更频繁需求—导致项目失败的罪魁祸首根据StandishGroup对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。也就是说，有近45%的项目最终因为需求的问题最终导致失败。对不知道航行目的地的人来说，没有顺风！我们在哪里重重摔了一跤在StandishGroup的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关：不完整的需求(13.1%)；缺乏用户的介入(12.4%)；不实际的客户期望(9.9%)；需求和规范的变更(8.7%)；提供了不再需要的(7.5%)缺乏资源(10.6%),没有执行层支持(9.3%),缺少规划(8.1%)项目成功的因素用户的参与：15.9%管理层支持：13.9%清晰的需求描述(13.0%)；合适的规划(9.6%)；现实的客户期望(8.2%)；较小的里程碑(7.7%)；有才能的员工(7.2%)软件需求曾经让我们如此狼狈参与各方都以自已角度讲述问题分布式WebServices三层对话框菜单条DCOMB/S数据交换……财务计算管理报表工作流自动库存控制库存报警业务线索管理业务经线索跟踪销售月报生成交易流数据问题的根源是什么？用户说的不是他想的：客户提供（陈述的需求）的需求并不是真实的需求，还需要作进一步的分析，以确定客户的真正需求和期望，接下来需要澄清并重新描述。可以这么说客户在理解基础业务过程和描述自己的需求方面有很大的差异。需求分析方法有问题：系统开发人员使用低效的需求分析和项目管理方法。共同责任强调不足：对客户和提供商在项目成功的共同责任方面强调不够。优秀的团队遇到糟糕的需求用户参与不足用户需求扩展有歧义的需求镀金问题过于抽象的需求忽略某种用户不准确的计划……我们应该怎么办？对“需求”建立正确的认识；客户和供应商—一根绳子上的两个蚂蚱；和客户一起建立起“共同的目标”；寻找并使用正确的、有效的需求捕获、描述（建模）、管理方法；动态、持续地适应需求的变化；需求是什么？非功能需求业务需求项目视图/范围文档用户需求系统需求质量属性用例文档功能需求其它非功能需求设计约束SRS业务需求业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。背景描述：XX保险公司希望充分利用日益完善的移动通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。业务需求/目标：通过该系统的实施，将人工保费续缴、投保手续办理两项业务运转周期缩短10％以上，使企业内部沟通效率大幅改善，以帮助企业运转效率得以提高。业务目标示例某船厂商业管理系统目标：A1.取代过时的系统A2.集成订单文档及数据库A3.使用经验数据进行报价A4.支持系统化的销售A5.快速捕获成本数据A6.加快发票的制作某医院管理系统目标：B1.降低IT成本人事部门：B2.实现一些任务的自动化B3.消除出错源B4.遵守最后期限B5.减少繁琐工作医院部门：B6.减少加班及工作量不足的情况B7.更快速的勤务规划B8.改进勤务表质量业务需求就是定义系统目标现状：功能分解盛行的今天，常常会犯“盲人摸象”的错误，这使得需求太过脆弱，难以经受考验。目标！目标！还是目标！--系统开发应目标驱动！目标是团队唯一的行动纲领。目标的定义不能够流于形式，应该具有以下特征：业务导向、可度量、合理、可行。要注意目标太夸大会浪费资源，目标太缩小会影响士气。（教堂与小屋）目标通常就是业务需求！业务需求就是定义系统目标目标在哪里？业务需求是构建在“项目发起人”的脑子里的，也就是谁提出项目，谁就拥有对“业务需求”的最清晰的理解。引出宏观的目标：思考企业运作中存在什么问题？这些问题主要是体现在哪些方面？这些问题对企业造成了什么影响？认为可以怎么解决？希望达到什么样的效果？将大任务分解成为小目标，并且引导客户良好地定义，这也是我们形成“项目子目标描述”的关键基础。衡量这些目标的合理性与可行性。业务需求就是定义系统目标形成一个不超过50字的项目目标，并且列出5-9个主要子目标，并且将其制作成一页文档，作为“项目的行动纲领”，还应该得到“项目发起人”的认可。在此基础上，可以编写“项目的目标和范围文档”(或称项目综述，即POS，内容包括问题/机会、项目目标、项目目的、成功标准、假设/风险/障碍)，对于产品而言，我们还可以构建一个从市场角度分析的“愿景”文档。该部分工作是处于“需求过程”的金字塔尖，多花费一些时间和精力是值得的，也是必要的。业务需求就是定义系统目标有了清晰的目标之后，还应该对系统划定范围，最常用的方法是工作上下文范围图（结构化分析方法）：用户需求用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户有不同类型：管理型、事务型信息系统、人决策层、使用层常用者、偶用者组织方法：用例、用户故事、特性例子：对快到期的客户，系统将通过短信将续保信息发给该客户的代理人系统需求解释一：系统需求是相关联的硬件、软件系统对待开发系统的相关需求。解释二：从系统实现的角度描述的需求。开发人员（设计及分析人员）在业务需求、用户需求的基础上生成的。功能需求功能需求是需求的主体，是需求的本质功能需求定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作零散（需求项）整理（特性、用例）敏捷方法：用户故事质量属性产品必须具备的属性或品质可靠性：成熟性、容错性、易恢复性易使用性：易理解性、易学习性、易操作性效率：时间特性、资源特性可维护性：易分析性、易更改性、稳定性、易测试性可移植性：适应性、易安装性、一致性、易替换性McCall体系：运行(正确性、可靠性、效率、完整性、使用性)、修正(维护性、测试性、灵活性)、转移(移植性、复用性、共运行性)设计约束也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。例如：必须采用国有自主知识版权的数据库系统…再如：必须运行在UNIX操作系统之下两个世界三种设计for(i=0;i=i+1;i++){printi;}问题域机器域需求规格说明书程序优秀的需求完整性：完整描述即将交付使用的功能，发现缺少某项信息，可以采用TBD来标注正确性：经过用户或用户信任的代理人审阅可行性：在已知能力和约束条件中实现必要性：每项需求记录的功能都应是用户真正需要的有优先次序：提供了实现优先级无歧义：对所有读者只有一种一致的解释可验证性：可以设计测试方法来检查检查表示例讨论前面的描述中，最大的感触是什么？业务需求需求定义用户需求需求捕获软件需求需求分析与编写规约