需求工程师

第一二章的阅读笔记 需求工程 （1） 需求工程定义： 　 需求工程 是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。需求工程通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。 （ 2 ） 需求工程(RE)可分为 　　1.系统需求工程（如果是针对由软硬件共同组成的整个系统） 　　2.软件需求工程（如果仅是专门针对纯软件部分）。 　　软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。 需求工程师的能力 需求工程师岗位职责 1.根据产品规划或者项目要求，对客户进行需求调研，整理客户需求； 2.负责编写用户需求说明书； 3.负责将完成的项目模块给客户做演示，并收集完成模块的意见； 4.协助系统架构师、系统分析师对需求进行理解； 5.指导测试工程师根据测试需求，组建测试环境的工作。 需求工程师工作内容 1.在项目经理和高级开发工程师指导下，根据公司战略进行调研和数据分析，规划相关产品战略，长短期目标与产品策略； 2.搭建系统开发环境，并使用SVN、VSS、TFS等版本控制工具； 3

软件工程类的书本也阅读不少本了，大多是讲述一些软件工程基本的领域知识或者实践方法，唯独邹老师编写的构建之法颇具新意，对于在软件领域的工程师和有志于将来从事软件领域工作的大学生具有相当的意义，书中讨论的许多问题都来自于实战，复杂性和多变性，确实是软件工作者最难以掌控的。 因为时间也紧迫，来不及细细品味，不过在阅读的过程中也想到了一些问题，因为这些年做行业软件比较多，客户满意度和软件需求边界之间的边界让我颇费脑筋，毕竟要让客户满意，交付时间和费用都会上升的比较快，尤其是面对一些客户询问，我想要具备淘宝网上某个同样的功能...，有时候竟然不知该如何回复既能满足客户，也能显得比较专业。第二个问题是关于项目团队成员稳定的，在邹老师讲述的重要紧急象限中，核心程序员离职对项目的打击是比较大的，但是因为目前软件领域竞争激烈，确实存在核心程序员不稳定的情况，在控制成本的前提下，如何做好预案也是我的一个问题，因为采取敏捷开发模式，不太可能有非常详尽的文档来满足接任者的诉求。 路漫漫其修远兮，软件之路充满挑战和坎坷，值得吾辈孜孜以求。 来源： https://www.cnblogs.com/nihilism-zhy/p/11200629.html

title: 敏捷软件需求管理 date: 2017-10-23 10:29:39 tags: 需求管理 严格的来讲，这个标题的说法并不是很严肃，这篇文章的目的不是建立一个敏捷软件需求管理的流程，而是去探索一种需求管理的实践，解决现在工作中遇到的困惑和困难。为了将问题解释的更清楚，我需要先从流程定义说起。 流程定义  上面这个图是一个典型的IPD（集成产品开发）流程图，从大的视角来看，这就是一个典型的瀑布模型，需要有前一个阶段的成果作为后一阶段的输入，后一阶段的工作才能开展，这样当然没有错，不过有时候会显得低效和无法满足项目的需求。 同样，我也拿出我们研发层的各阶段的定义，进而进一步探讨。  从图和表中点后可以看到，需求分析集中在项目的前期的阶段，理所当然，需求就要作为后续工作的输入，因此需求很重要，这都知道，所以在图中也设置了需求的技术评审，但需求的技术评审并不能保证全部的质量。 总结来说，需求很重要，但需求又大多数集中于前端部分，不好管控，怎么保证需求高质量的分析，发现和实现都是比较困难的事情。 需求层次 产品开发规程中，对需求层次的定义是： op=>operation: 用户需求 op1=>operation: 产品需求 op2=>operation: 软件（子系统）需求 op(right)->op1(right)->op2 用户需求是顶层需求，直接反应用户的需要