- 浏览: 1152184 次
- 性别:
- 来自: 火星郊区
博客专栏
-
OSGi
浏览量:0
文章分类
- 全部博客 (695)
- 项目管理 (48)
- OSGi (122)
- java (79)
- Vaadin (5)
- RAP (47)
- mysql (40)
- Maven (22)
- SVN (8)
- 孔雀鱼 (10)
- hibernate (9)
- spring (10)
- css (3)
- 年审 (6)
- ant (1)
- jdbc (3)
- FusionCharts (2)
- struts (4)
- 决策分析 (2)
- 生活 (10)
- 架构设计 (5)
- 破解 (2)
- 狼文化 (4)
- JVM (14)
- J2EE (1)
- 应用服务器 (1)
- 我的链接 (5)
- 数学 (2)
- 报表 (1)
- 百科 (6)
- Flex (7)
- log4j (2)
- PHP (1)
- 系统 (2)
- Web前端 (7)
- linux (6)
- Office (1)
- 安全管理 (5)
- python (2)
- dom4j (1)
- 工作流 (3)
- 养生保健 (4)
- Eclipse (8)
- 监控开发 (1)
- 设计 (3)
- CAS (1)
- ZK (41)
- BluePrint (3)
- 工具 (1)
- SWT (7)
- google (2)
- NIO (1)
- 企业文化 (2)
- Windoes (0)
- RCP (7)
- JavaScript (10)
- UML (1)
- 产品经理 (2)
- Velocity (10)
- C (1)
- 单元测试 (1)
- 设计模式 (2)
- 系统分析师 (2)
- 架构 (4)
- 面试 (2)
- 代码走查 (1)
- MongoDB (1)
- 企业流程优化 (1)
- 模式 (1)
- EJB (1)
- Jetty (1)
- Git (13)
- IPV6 (1)
- JQuery (8)
- SSH (1)
- mybatis (10)
- SiteMesh (2)
- JSTL (1)
- veloctiy (1)
- Spring MVC (1)
- struts2 (3)
- Servlet (1)
- 权限管理 (1)
- Java Mina (1)
- java 系统信息 (6)
- OSGi 基础 (3)
- html (1)
- spring--security (6)
- HTML5 (1)
- java爬虫搜索 (1)
- mvc (3)
最新评论
-
Tom.X:
http://osgia.com/
将web容器置于OSGi框架下进行web应用的开发 -
chenyuguxing:
你好, 为什么我的bundle export到felix工程中 ...
在Apache Felix中运行bundle -
string2020:
<niceManifest>true</ni ...
Bundle Plugin for Maven -
jsonmong:
OSGI,是未来的主流,目前已相当成熟。应用OSGI比较好的, ...
基于OSGi的声明式服务 -
zyhui98:
貌似是翻译过来的,有很少人在linux上做开发吧
如何成为“10倍效率”开发者
研发计划。对于最终的产品,需求文档扮演着开发者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候,便可以发挥巨大的作用。然而,如果你在嵌入式开发领域工作的时间足够长,你就会很快发现,这个领域里不合格的需求文档实在是太多了。当你尝试对这些不合格的文档进行修复时,你又会很快发现,书写正确的需求文档绝非易事。在这里,我们提出一些建议,希望能将书写正确需求文档这件事情变得清晰一些。
从较高的层次来看,书写需求文档的目的就是要提供对所需行为的有效描述。该所需行为可用一个黑盒系统描述,并需要注意以下细节:
• 工程师可以根据系统所说进行实现
• 测试人员,在不与开发人员沟通的前提下,可以利用满足硬件要求的设备验证需求。
• 最终产生的成果满足终端用户的要求。
书写优质的需求文档:
最基本的原则是:需求文档应当尽量简洁,用最易懂的描述来约束系统的预期行为。如果你遵循这个原则,剩下的那些重要因素(可测试性、避免过度设计等等)都将变得顺理成章。
列举一下更详细的规则,通常会更有帮助。下面是书写优质需求文档需要遵循的步骤:
1. 定义系统的边界。这也是黑盒系统所必要的。
2. 定义输入和输出。这也应当是你看待内部系统的唯一方式。
3. 用最易懂的方式描述系统的预期行为
4. 除了输入和输出之外,你的需求是不是还涉及了系统的其他部分?如果是,那么你的需求就设计过度了。重构需求,让它变得精简。
5. 你的需求是不是过于模棱两可?加入更多的限定规范。注意:有些模棱两可的描述并不是坏事,假设描述所包含的所有情况均可被接受,且测试的时候不需要附加的信息加以说明,那么就没关系。你不需要(也不应该)把系统的行为限制得过头。
6. 你的需求是否可测试?(这里指的是黑盒测试)如果不是,你最好返回到第4步。如果这种返工发生很多次,那就说明你的黑盒无法正确描述系统,或者你的测试工具不够优秀。无论是哪种情况,不可测试的需求文档几乎就是一文不值的。
7. 你的需求文档通俗易懂么?如果你的需求文档非常难以读懂,那就说明你写得不好,只能给那些照着你的需求负责实施的人带来无尽的痛苦。如果是这样,回到第3步。
8. 你是不是真的做到了第4步?你确认么?再检查一下。
例子:下面的例子,让我们描述一个自制的嵌入式设备的需求,这个设备能从弯曲传感器上读取弯曲的频率,并根据不同的频率值让一个LED闪烁。
显然,我们已经完成了步骤2和步骤3了!
• 输入:从弯曲传感器读取数据。
• 输出:LED。
但是我们跳过了步骤1:
• 在这个例子里,我们将把黑盒画到设备的微处理器上。
让我们继续往下进行,
第四步:除了输入和输出以外,我们是否还涉及了其他的系统边界?
• 微处理器并不关心从弯曲传感器读取什么样的数据,从处理器的角度来看,仅需要做的是测量ADC脚的电压而已。
• LED仅由数字输出脚控制。
下面,让我们来修正这个问题:
第0版本的需求:
1. 该设备应当根据ADC脚的不同频率的电压,来切换数字输出端的状态。
第五步: 需求写模棱两可么?
恩,我们的描述太模棱两可了.输出端切换的速度要多快? 跟电压的关系如何? 输入电压的范围是多少? 让我们加一些更细节的描述吧:
版本0.1
1. 输出端应当由一个自由活动的定时器进行控制
2. 自由运行定时器的频率最高不得高于每秒10次,不得低于每秒1次.
3. 自由运行定时器的触发频率应当在最高和最低值之间呈线性变化,并与ADC端的输入电压成正比.
4. ADC端的输入电压应当每100毫秒读取一次
5. 当ADC端的输入电压端被读入时,控制自由运行定时器周期时间的注册值也应当被更新.
6. ADC输入端的电压有效范围应当被控制在0到1伏之间.
第六步: 你的需求是可测试的么?
• 首先,自由运行的定时器在这里不需要提及. 因为对它基本上无法进行黑盒测试,它既不是输入也不是输出,而且跟这两者也没有什么联系。
让我们用“数字输出端变化的频率应控制在每秒10次和每秒1次之间”来代替自由运 行定时器的测试标准。
• 对于上述的第四条需求,可能需要一些小修改才能作为测试标准。让我们用“ADC端的输入电压应当保证在每100毫秒内至少被读取一次”来加以描述,这样的描述能让我们预期的测试行为显得更加通俗易懂。
• 需求的第五条也需要一些小修改。我们如何才能检测电压的输出范围是在0到1伏之间呢? 总不能给个2伏的电压,然后看看元器件有没有被烧毁吧?
那么,说“检验系统在ADC端输入电压为1到2伏之间的时候,工作是否正常”,这样就检验就容易多了。需求描述应当是“正面”的,应当描述设备“应该”的行为,而不是设备“不应该”的行为。否则的话,测试将会无法进行。
版本0.2
1. 数字输出端的切换频率应当控制在每秒10次到每秒1次之间
2. 数字输出端的切换频率应当在最大值和最小值之间呈线性变化,并与ADC端的输入电压成正比
3. ADC端的输入电压应当保证在每100毫秒内至少被读取一次
4. 检验当ADC端的输入电压范围在0到1伏之间的时候,系统工作是否正常
第七步:你的需求是否通俗易懂?
相比于我们原来的描述:“根据弯曲传感器的输出不同频率来控制LED闪烁”,我们上面的那些需求描述显得难以阅读和理解。
我发现,让需求文档变得通俗易懂,最简单办法莫过于,把过于细节的东西抽取出来,然后以条目的形式单独定义。
版本1
1. 弯曲传感器应当保证至少在100毫秒内读取一次数据(放到注释单独列出)
2. 切换LED的状态,使其与弯曲传感器的读数保持一致
3. 当弯曲传感器的读数为1伏特时,LED状态切换的次数应当保持在平均一秒十次;当传感器的读数为0伏特时,LED的切换次数应保持在一秒1次。
定义:
• 弯曲传感器:输入电压位于ADC的X端。安全电压范围为0到1伏特(放到注释单独列出)
• LED状态:数字状态由Y端输出
这样就好多了(尽管还不完美)。这些需求通俗易懂,不涉及到系统内部实现,且易于测试。对于系统行为的限定也仅仅限于需要做什么,点到为止。(例如,对弯曲传感器的采样频率,在实现上也可以更高,只要不产生非预期行为,一切都可以)。
编写需求就仿佛是在大脑中构建软件的过程。因此要重于执行操作。
发表评论
-
原来公司需要这样的你
2012-10-18 14:22 1027转自:http://512zw.iteye.com/blo ... -
从经理的角度看技术债务
2012-08-11 09:36 1054trong> 英文原文:Technical Debt a ... -
如何做一个优秀的领导者
2012-07-14 19:21 929TeamLeader是比较尴尬的角 ... -
软件开发过程文档如何写作?——“文档==鸡肋”?
2012-03-29 08:42 969“鸡肋——食之无味, ... -
软件工程过程名称
2012-03-28 14:06 1169AN...需求分析 英文(_A ... -
项目管理
2012-03-20 16:50 1024部门有位同事(姑且称为小A),工作时间内积极性相对还是蛮高 ... -
【开源项目】
2012-03-08 14:15 1807metamorphosis 简称Meta,一个高性能、高可 ... -
软件项目经理新手上路5 - 头痛医头,脚痛医脚
2012-01-16 08:27 1169项目总有各种各样的 ... -
软件项目经理新手上路4 - 老好人
2012-01-16 08:23 1108老好人式的项目经理并不少见。他们人很好,希望让每一方满意。 ... -
软件项目经理新手上路3 - 这不是份简单的工作
2012-01-16 08:19 1105绝大多数开发人员的职业目标都是成为项目经理。项目经理的工作看 ... -
软件项目经理新手上路2 - 力量从哪里来?
2012-01-13 08:10 1010技术冲突是技术出身的项目经理经常碰到的事情。一开始只是技术讨论 ... -
软件项目经理新手上路1 - 序
2012-01-13 08:09 1168软件项目经理,这是广大开发人员向往的职位。随便抓个开发人 ... -
解读敏捷3 - 解读敏捷实践之结对Review
2012-01-13 08:06 1032程序员A碰到了程序员B。“Scrum糟透了”程序员A说。 ... -
从电影《三傻大闹宝莱坞》看IT新手应如何学习?
2011-12-31 08:45 1045《三傻大闹宝莱坞》电视上又在放,又看了一遍,觉得很赞。很喜 ... -
技术人的最终出路
2011-12-27 08:46 1128虽然是希望这个论坛成为一个纯技术性论坛,但作为一名 ... -
如何成为“10倍效率”开发者
2011-12-26 08:22 1388Brad Feld的一篇文章The Rise of Devel ... -
项目-团队-技术-个人(提拔篇)
2011-12-23 08:54 959是团队,就需要领导。领导从哪里来呢?途径可以有多种: 1 ... -
项目-团队-技术-个人(专业篇)
2011-12-23 08:50 9771引言 今天,我的话题是“专业”。 这里的“专业”,指的不 ... -
从技术员到项目管理转型的体会
2011-12-19 11:23 1061一、与领导有效 ... -
技术人员出差携带物品自检表
2011-12-15 12:53 1182出差,又是出差。 做技术工作,出 ...
相关推荐
为了实现这一目标,我们编制了这份管理后台功能需求文档模板v1.1,其目的在于提供清晰、详细的指导,确保所有利益相关方——包括贷款用户、产品经理、运营人员和开发技术人员——对管理后台的功能和需求有共同的理解...
编写需求文档,在嵌入式开发领域是非常普遍的。需求文档被用来定义开发任务,协调大规模的研发计划。对于最终的产品,需求文档扮演着开发者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候,便可以...
综上,36氪产品需求文档的重点在于理解用户需求,简化注册登录流程,提高用户体验,并确保产品稳定性和信息的及时、专业。通过不断优化细节,36氪致力于满足目标用户群体对高质量商业资讯的需求。
《腾讯公司产品需求文档模板》是腾讯公司在进行产品开发时使用的标准文档,它详细规定了产品的功能、设计、用户需求及预期目标等方面,是产品开发流程中的重要参考资料。以下将详细解析该模板中的核心知识点: 1. *...
在实际操作中,团队应根据这个模板来编写具体的产品需求文档,确保每个部分都详实、准确,便于理解和执行。同时,文档应该随着项目的进展不断更新,以反映最新的需求变更和决策。 总之,一个好的需求文档模板是成功...
以下是一些撰写优质需求文档的关键点: 1. **目的明确**:首先,需求文档应当清楚地阐述背景、目的和功能的上下文。这样做能帮助团队理解为什么需要这些功能,而不是仅仅关注功能的细节。在描述功能时,应先解释其...
掌阅书城客户端产品需求文档详细阐述了该应用的开发与优化目标,旨在为用户提供更优质的阅读体验。文档的V2.0.0版在2011年6月22日由蒋斌初步编写,并于同年7月17日进行了修订。以下是文档中的关键知识点: **前言**...
以下是从开发和技术角度出发,对如何构建优质需求文档的详细解析。 1. **开发思维:组件与模块** - **需求拆分**:如同编写文章,需求应被分解为清晰的组件和模块,对应产品中的功能、界面或规则。产品结构图能...
《Knight 短途出行平台APP产品需求文档》是为开发一款名为Knight的短途出行服务平台所编写的详细文档,旨在明确产品的功能、目标用户、设计原则以及实现策略。该文档由陈一默在2017年11月13日编写,属于起点学院的...
贝店APP产品需求文档的编写,基于对目标用户群体的深刻理解,充分考虑了宝妈这个特定用户群体在使用APP过程中可能遇到的各种情况。产品设计的每一个细节,都旨在提升用户满意度,增强用户粘性。通过对用户体验的极致...
《PPS移动端产品需求文档》是对PPS iPhone客户端"爱频道"改版的详细规划,旨在提供一个清晰、全面的产品需求框架,以指导产品的设计和开发。这份文档由作者Xxxxxx于2019年12月编写,文档版本为0.3,后续的修改部分会...
企业网站需求文档的编写是一个严谨的过程,它不仅指导技术团队的开发工作,也是项目管理、沟通和决策的基础。每个细节都需精心考虑,以确保最终的网站既满足业务需求,又能提供优质的用户体验。
3. 参考类似软件,结合本软件的要求,分析、编写数学“加”功能块的详细需求文档,实现模块的功能。 本文论述了课题的研究思路、工作和取得的研究成果,文章的内容结构安排如下: 本文分为三大部分: 第一部分,...
该产品需求文档(PRD)详尽地阐述了产品的设计思路、功能结构和交互细节,旨在为用户带来更优质的旅游体验。 1. **文档综述** - **版本修订记录**:文档的更新和改进历程被详细记录,以便追踪产品的发展和调整。 ...
总的来说,编写一份简洁而有重点的需求文档,需要对产品目标有深刻理解,清晰地表达功能逻辑,详尽地描述业务流程,并结合实际案例进行具体分析。这样的文档不仅能有效指导开发,还能促进团队间的沟通,确保产品开发...
本需求文档的编写旨在明确系统开发的目标,为设计、开发和测试团队提供清晰的指导,确保系统功能满足超市管理者和员工的实际需求。 1.2 背景 在当前信息化社会,超市管理已不再局限于传统的手工记账和管理方式,...
《在线智能客服系统》的需求文档详细阐述了构建一个高效、智能的在线客户服务系统的各项要求,旨在提高企业与客户之间的交互效率,提供优质的客户服务体验。以下是根据文档内容提炼的关键知识点: ### 第一部分:...
《游戏点卡在线销售系统需求文档》是针对一款旨在提供便捷游戏点卡购买服务的在线平台所编写的文档。随着互联网的普及,网络购物已成为现代生活的常态,特别是对于游戏点卡这类需要快速交易的商品,传统的实体店铺...