网站icp不备案有关系吗,咖啡网站建设,国外家居创意空间设计,wordpress如何换内页模板简述
当进行需求分析时#xff0c;通常着重考虑三个主要层次#xff1a;业务需求、用户需求和功能需求。业务需求关注项目与组织战略目标的一致性#xff0c;用户需求明确最终用户的期望#xff0c;而功能需求定义具体的系统功能和特性。这三个层次为项目管理和软件工程提…简述
当进行需求分析时通常着重考虑三个主要层次业务需求、用户需求和功能需求。业务需求关注项目与组织战略目标的一致性用户需求明确最终用户的期望而功能需求定义具体的系统功能和特性。这三个层次为项目管理和软件工程提供了关键的指导确保项目成功地满足用户和业务需求。需求分析的重点通常集中在这三个层次以确保项目的成功交付。
此外还包括系统需求、性能需求、可用性需求、安全性需求、数据需求、界面需求以及法规和合规性需求等。这些层次共同构成全面的需求分析有助于确保项目满足各种技术、业务和用户方面的需求以达到项目成功。
业务需求 Business requirement
表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统即组织希望达到的目标。使用前景和范围 vision and scope 文档来记录业务需求这份文档有时也被称作项目轮廓图或市场需求 project charter 或 market requirement 文档。
例如有个公司一定要做一款“智能硬件”其目的也许不是为了销售只是正好上市打造一个概念“涉足智能硬件”的概念务必使用新技术或者涉足新领域便于资本市场炒作。那么这个产品需求分析的时候就不能按部就班按常理出牌。步子就是要大哪怕扯到蛋也要步子大。这就是“业务需求”的一种体现。所以在产品的需求分析阶段要把“指导思想”搞清楚。
再例如我在华为做IPC的时候指导思想是“华为要做监控安防领域的苹果”占领技术制高点、产品制高点避免同质化避免陷入价格战。那么在这款产品的市场定位上首先定义为“平安城市”“高端园区”所以在特殊功能性能指标方面追求极致而在成本复杂度上面做出妥协。
研发的人员一般也担心风险进度对于有挑战的需求往往会望而生畏。而且每个人的理念不一样。当时一位同事做廉价产品做出过成绩降成本很有心得所以死扣这款产品的成本。但是这款产品的指导思想很清晰所以设计理念得以落实。这个产品的市场经理当时根据室外环境、园区环境供电距离远的特点提出了“穷凶极恶”的概念在恶劣的情况下能够正常工作实际上会增加成本也会增加电路的设计难度。但是为了差异化竞争为了占领高端市场。 虽说需求都是可以讨论但是如果研发理解了需求背后的原因可能更容易去权衡各个需求的优先级。“多快好省”肯定是不可能兼得的但是理解需求背后的原因之后就可以更好的进行取舍和排序。
用户需求 User requirement
描述的是用户的目标或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
首先对于用户需求不要“意淫”有的研发人员往往意淫出一些需求因为程序员、硬件攻城狮往往会把自己放在客户的角色上但是开发人员往往不具备客户的行业经验或者不具备客户使用产品的场景。用主观意识去使用和认知产品往往就往往不符合客户需要的原本的模样。
另外对于运营商产品客户的表述往往就是用户需求因为客户是长期从事相关产品的使用属于专业人员专业能力较强而且产品往往配套培训和材料但是对于个人消费品或者是一些企业用户用户说的往往并不是用户需求。因为 由于开发人员往往会把自己放置在用户的角度思考往往就会出现需求的范围蔓延无端的增加了很多原本没有讨论过的需求。避免需求在开发过程中的走样。往往我们需要进行“范围管理”。
项目范围的管理也就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。它包括用以保证项目能按要求的范围完成所涉及的所有过程包括确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理以及范围核实等。项目范围是指产生项目产品所包括的所有工作及产生这些产品所用的过程。项目干系人必须在项目要产生什么样的产品方面达成共识也要在如何生产这些产品方面达成一定的共识。 范围管理的目的是在项目开发过程中出现范围蔓延。制约一个项目的条件是项目“三约束条件”——范围、时间、成本。 范围的蔓延势必影响项目的时间和成本。 在一个项目中这三个条件是相互影响、相互制约的而且往往是由于范围影响了时间和成本。项目一开始确定的范围小那么它需要完成的时间以及耗费的成本必然也小反之亦然。很多项目在开始时都会粗略地确定项目的范围、时间以及成本然而在项目进行到一定阶段之后往往会变得让人感觉到不知道项目什么时候才能真正结束要使项目结束到底还需要投入多少人力和物力整个项目就好像一个无底洞对项目的最后结束谁的心里也没有底。这种情况的出现对于公司的高层来说他们是最不希望看到的然而这样的情况出现并不罕见。造成这样的结果就是由于没有控制和管理好项目的范围。可见项目的三个约束条件中最主要还是范围的影响。 产品工程过程分为需求分析、概要设计、详细设计、编码、测试、安装试运行、验收等七个阶段项目保障过程包括项目计划、项目跟踪与监督、需求管理、质量保证、配置管理、同行评审等保障性工作过程。上图也体现了各个环节对需求的控制和理解这个过程管理的。
功能需求 Functional requirement
规定开发人员必须在产品中实现的软件功能用户利用这些功能来完成任务满足业务需求。功能需求有时也被称作行为需求 behavioral requirement 因为习惯上总是用“应该”对其进行描述“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。
对于硬件项目在项目启动后会写一个《需求规格跟踪表》。
需求为什么需要文档化呢如果你开发出来的产品被别的同事质疑这也没有那也没有时你一肚子委屈过你就非常能够理解。
Ø开发人员通过文档化的过程查错补遗
Ø便于评审在早期发现技术上的问题
Ø后续阶段开发任务可能由他人承担输出文档便于他们开展工作
Ø维护人员开展维护工作需要
Ø文档是必要的交付件 “所有的过程分析都要形成文档。我们现在有一个严重的问题是大家好像不喜欢写文档对于需要的实现方案通常都是一个负责人在脑袋里想想该怎么实现然后邮件或电话找几个相关人员讨论一下就算可以了可能连个会议材料或会议纪要都没有。 而老外可不是这样的他们非常非常重视文档他们认为一个人在脑袋里想的东西是不清晰也不全面的有时候心里想的认为很正确的方案实际上可能存在致命缺陷。他们要求必须把心里的想法形成文档才能有效地避免这种问题。写文档的过程中可以更加有效的、更进一步去整理您原来心里的思路很多问题在您写过文档的过程中您就能发现 另外文档写作多使用图表浪费口水的文字尽量少用和我们一起工作的系统工程师在系统架构分析中就画了五六十张图就算看不懂他写的英文从图中我们就能够很清晰的指导整个产品的系统架构。” ——摘自一位华为员工的瑞典出差报告 上面的表单的后面几列是在开发的各个阶段去检查原先确定的需求、规格等数据是否变化。例如在原理图、PCB、测试阶段去检查是否出现了需求丢失或者发生需求变更。如果发生需求变更需要记录原因决策者。
- 系统需求 System requirement
用于描述包含多个子系统的产品即系统的顶级需求。系统可以只包含软件系统也可以既包含软件又包含硬件子系统。人也可以是系统的一部分因此某些系统功能可能要由人来承担。最终决定市场对产品的综合评价是否满意。
对有很多子系统的巨大产品进行跟踪能力管理是一项巨大的工程但这很必要。并不是所有的公司都会因为软硬件问题而造成严重的结果然而应该严肃地对待需求跟踪尤其对涉及你业务核心的信息系统。考虑了应用技术的成本和不使用的风险后才能决定是否使用任何改进的需求工程实践。随着产品的发展要把时间投向回报丰厚的地方。
需求管理系统包括模型管理、与WBS关联、版本管理、条目化管理、需求追踪、需求控制、模板管理、统计查询功能系统组成结构如下图所示。 需求管理和需求跟踪是研发工程师的入口所以我们需要重视和理解。
需求分配过程其实是一个多层次的循环过程需要循环几次取决于两个因素一个是需求的复杂度一个是企业研发组织的大小和组织方式。
我们举个复杂点的例子来看看这个过程。图3.4是一个企业的研发组织结构 假设研发中心和下面4个部门都有需求管理团队或需求管理人员专职或兼职均可金融产品与解决方案部收到一个客户需求经过分析需要云计算业务部、通用技术开发部一起合作才能完成但又无法直接调动这两个业务部的开发团队。因此需求首先要上升到研发中心层面进行决策由需求管理团队1组织云计算业务部、通用技术开发部的需求管理团队参与决策决策通过后再详细分析需求并进行需求的分发确定需求的哪些内容由哪个部门完成这个时候一个需求分解成了若干个子需求并分配到了各个责任部门。接到子需求的部门需对需求进行分析确认技术可行性、实现的方案及交付团队很有可能不止一个团队参与这个时候需要再次分解分配指导需求无法再分解、交付版本及时间并最后作出承诺这才算这一条需求完成了所有的分发、分析、分解分配与决策过程。
因此在组织复杂、需求复杂的情况我们要制定需求的优先级排序及决策规则。同时为了快速地推出产品就必须界定产品的范围也就是说不是所有的需求都能一次性实现这也需要我们对需求进行优先级排序并且设计针对跨产品线需求与产销矛盾的需求决策机制。
多数情况下客户需求他们打算购买或正在使用的产品或服务具备一系列他们期望的特点、功能和特征。然而在客户决定购买或再次购买产品或服务时这些因素的影响力却不尽相同。无论他们有没有意识到客户总会优先排序产品/服务特点并根据排序结果进行决策。
相对重要性是描述客户优先级的一个方法。客户的各种期望在客户作出购买决定时占有什么样的重要地位。优先级排序结果是客户对某产品/服务的各项功能性特点的相对重要性衡量的结果。
有了客户优先级公司也应有一个独立的评估。对客户而言重要的需求未必对公司重要。需求可以是必须的承诺的或非必须的承诺的。公司对非必须性需求的优先级排序按照高、中、低的尺度进行排序时至少应考虑以下要素
1客户优先级
2对公司的益处最好是定量的
3工作量如粗略估计编码行
4风险高/中/低
比较完善的考虑维度在实际使用时也可以酌情裁判。 如果是一个初创公司想去做教育领域的机器人我们的思路是什么如果是一个大型的教育商业机构想拓展新的业务想拓展教育机器人领域我们的思路是什么如果是一个公立学校想提高学生的素质开展机器人教育我们的思路又是什么请注意这三者的客户群体可能有很大程度上的重合交叠。但是需求的分析结果一定是大相径庭的。我们在做需求分析的时候需要考虑的三大要素是
第一个要考虑的要素组织的战略目标是什么。战略是公司应对商业问题的态度和基本面决定投入资源的多少、切入市场的策略等。资源的多寡往往决定我们解决问题的方式。切入市场的策略往往决定我们的时间成本。
初创公司纵有豪情驰骋天下但也得面对现金流的问题获得巨额投资的企业没有短期现金流的问题但要面对股东、资本的巨大压力也要考虑烧钱之后是否还有生命力的问题公立学校看似没有挣钱的压力但有行政指标的压力其不比资本压力小。
第二个考虑的要素就是项目的目标是什么越具体越好。我是初创公司我的第一个产品只是解决有无的问题也许不完美但是可以销售的产品实物和教案竞争力在市场上属于中等。配合合适的营销策略可以解决第一步的生存问题预计销售额多少面对的客户群里是多大年龄、什么学校的学生……现实一点没什么不好饭要一口口吃活要一件件做。千万不要成为一些莫须有的理想和柏拉图世界的牺牲品。
第三个考虑的要素是环境因素。比如说教育行业的政策变化未来几年的行业变化趋势周边社区的环境、法律的约束、行业要求等。简单地说一下现在面对低龄孩子的教育机器人行业能很好规避国家对学生减负的要求。工业产品销售的时候只要客户没有要求就可以不做3C认证。如果是消费类产品不管最终用户有没有提3C认证只有在中国销售的产品都需要做3C认证。
