- 浏览: 1538371 次
- 性别:
- 来自: 杭州
文章分类
- 全部博客 (525)
- SEO (16)
- JAVA-EE-Hibernate (6)
- JAVA-EE-Struts (29)
- JAVA-EE-Spring (15)
- Linux (37)
- JAVA-SE (29)
- NetWork (1)
- CMS (14)
- Semantic Research (3)
- RIA-Flex (0)
- Ajax-Extjs (4)
- Ajax-Jquery (1)
- www.godaddy.com (0)
- SSH (34)
- JavaScript (6)
- SoftwareEngineer (9)
- CMMI (0)
- IDE-Myeclipse (3)
- PHP (1)
- Algorithm (3)
- C/C++ (18)
- Concept&Items (2)
- Useful WebSite (1)
- ApacheServer (2)
- CodeReading (1)
- Socket (2)
- UML (10)
- PowerDesigner (1)
- Repository (19)
- MySQL (3)
- SqlServer (0)
- Society (1)
- Tomcat (7)
- WebService (5)
- JBoss (1)
- FCKeditor (1)
- PS/DW/CD/FW (0)
- DesignPattern (11)
- WebSite_Security (1)
- WordPress (5)
- WebConstruction (3)
- XML|XSD (7)
- Android (0)
- Project-In-Action (9)
- DatabaseDesign (3)
- taglib (7)
- DIV+CSS (10)
- Silverlight (52)
- JSON (7)
- VC++ (8)
- C# (8)
- LINQ (1)
- WCF&SOA (5)
- .NET (20)
- SOA (1)
- Mashup (2)
- RegEx (6)
- Psychology (5)
- Stock (1)
- Google (2)
- Interview (4)
- HTML5 (1)
- Marketing (4)
- Vaadin (2)
- Agile (2)
- Apache-common (6)
- ANTLR (0)
- REST (1)
- HtmlAnalysis (18)
- csv-export (3)
- Nucth (3)
- Xpath (1)
- Velocity (6)
- ASP.NET (9)
- Product (2)
- CSS (1)
最新评论
-
lt26w:
理解成门面模式应该比较容易明白吧
FacadePattern-Java代码实例讲解 -
lt26w:
看下面的例子比较明白.
FacadePattern-Java代码实例讲解 -
javaloverkehui:
这也叫文档,别逗我行吗,也就自己看看。
HtmlCleaner API -
SE_XiaoFeng:
至少也应该写个注释吧。
HtmlCleaner API -
jfzshandong:
...
org.springframework.web.filter.CharacterEncodingFilter 配置
先
谈谈我的想法。
一、要讨论怎么写需求文档,首先就的搞清楚需求的构成,我是这么分的: 1、功能需求; 2、非功能需求或技术需求; 我一般把功能需求划分为几个部分: a、业务过程; b、业务规则; c、业务数据; 非功能需求(技术需求)我就不多说了,大致就是可用性,可靠性,性能,可支持性等等。 二、弄清楚需求的构成后,我们就得考虑以什么样的文档结构来描述这些需求了,UP的做法是这样的: 1、用例规格说明描述业务过程; 2、业务规则文档描述业务规则; 3、术语表描述业务数据; 4、补充规格说明描述非功能需求(技术需求); UP的做法还是很有道理的。这体现了两个原则: 1、分离关注点(每个文档描述相对独立的领域); 2、减少重复(很多用例都会引用相同的业务规则及业务数据); 这样便能够尽可能的使文档结构清晰,易阅读,易理解。也便于跟踪和维护。 但另一方面由于将不同的领域分离到不同文件的做法也使得可阅读性有所降低。比如用例规格说明中的业务过程描述时常需要引用业务规则文档中的业务规 则及术语表中的业务数据。由于不是很方便在各个文档之间导航,你可能需要打开多个文档进行交叉阅读。这是比较麻烦的,特别是对于用户来说。 而且UP中每个用例都单独作为一个文件存在,这可能是为了便于跟踪及管理的缘故吧。但正如上所述,文件多了看着就觉得不爽了。我觉得完全可以将用 例合并到一个文档中。或者几个相对独立的文档中(比如根据子系统划分)。 至于交叉阅读,导航困难的问题是否有什么别的方法解决呢?html文档似乎不错。不过写起来似乎没word方便啊。 三、总结: 无论怎么写需求文档,最终的目的无外乎易阅读 ,易理解 ,易 沟通 ,易确认 ,易跟踪 ,易测试 ,易 验收 。我想我们都应该以这个为目标来进行思考。 大家是什么看法呢? 声明:JavaEye文章版权属于作者,受法律保护。没有作者书面许
可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-04-01
需求文档的后段维护,重点在专人负责,有一定的工具辅助效果可以更好。个人认为word文档适合作为对外交流的格式,内部使用并不合适,还是把数据录入系
统方便很多。
引用
交叉阅读,导航困难的问
题。易理解,易沟通,易确认
用wiki效果还不错,提供整体导出。 引用
易跟踪,易测试
这是问题追踪系统(如BugZilla、Jira)的强项 把两者结合起来的 1、开源的Trac系统 2、atlassian的Confluence + Jira 还有很专业的需求管理系统,要银子砸的,不过复杂到没有什么用的欲望了 1、DOORS 2、RequisitePro开始的RUP套件,基本围绕word搞得需求系统,很强悍 细节参见http://blog.csdn.net/msde/archive/2006/11/28/1418486.aspx 最近发现Jolt Project Management Tools提名的软件还有很多,如Rally、VersionOne等,不过偏项目整体管理了。 |
|
返回顶楼 | |
发表时间:2008-04-01
alexv 写道
需求
文档的后段维护,重点在专人负责,有一定的工具辅助效果可以更好。个人认为word文档适合作为对外交流的格式,内部使用并不合适,还是把数据录入系统方
便很多。
我倒觉得内部使用还不是太大的问题,对用户来说问题大些。如果不便于阅读,用户是很烦的。甚至都没有耐心仔细读下去。 alexv 写道
引用
交叉阅读,导航困难的问
题。易理解,易沟通,易确认
用wiki效果还不错,提供整体导出。 恩,wiki内部交流确实不错,但作为需求管理是否合适呢?有啥优劣么?如果你对外交流仍然用word那你是否需要维护两套文档呢?这非常的不便 啊。 alexv 写道
引用
易跟踪,易测试
这是问题追踪系统(如BugZilla、Jira)的强项 把两者结合起来的 1、开源的Trac系统 2、atlassian的Confluence + Jira 我说的易跟踪,易测试主要是指需求或需求文档本身需要具备这些特质。另外貌似.net社区基本上不使用这套工具。呵呵。 alexv 写道
还有很专业的需求管理系统,要银子砸的,不过复杂到没有什么用的欲望了 1、DOORS 2、RequisitePro开始的RUP套件,基本围绕word搞得需求系统,很强悍 细节参见http://blog.csdn.net/msde/archive/2006/11/28/1418486.aspx 最近发现Jolt Project Management Tools提名的软件还有很多,如Rally、VersionOne等,不过偏项目整体管理了。 恩,有两个主要因素制约使用这些工具: 1、很贵的说; 2、使用复杂,而且从中所能获得的收益似乎远远不及这些工具厂商宣传的那样。 btw:貌似你的处女帖给了我啊,呵呵。 |
|
返回顶楼 | |
发表时间:2008-04-01
先讲讲我这里的情况:
1、我们的最终用户不是IT人事,不关心提交文档的细节,他只关心宏观的功能是否有,基层使用是否满 意……so,需求文档的内部意义 比 对外重要很多。 2、需求文档一旦提交用户确认后,对外变动仅仅需要提交变动说明即可,不用重新搞一个新版 本;必要的时候,从wiki导出吧。 我更关心需求的完备性、可检索性。文档格式难以胜任: 1、需求和设计间是有一个过程的,需要 对需求逐条分析、讨论、设计,中间有很多有价值的过程信息,往word里写很麻烦,而且很难事后检索; 2、功能需求是分阶段发布的,如何跟踪功能 需求在各阶段的覆盖情况,对我很重要; 3、对需求的定向检索、需求关联(in-link,out-link)、版本变动、需求变更; 4、 开发阶段对需求的追踪、反馈。 如果关注的仅仅是文档本身的质量,word可以搞定; 但关注文档的维护性,可能需要一些工具的支持 吧。 |
|
返回顶楼 | |
发表时间:2008-04-03
alexv 写道
先讲
讲我这里的情况:
1、我们的最终用户不是IT人事,不关心提交文档的细节,他只关心宏观的功能是否有,基层使用是否满意……so,需求文档的内部意义 比 对外重要很多。 2、需求文档一旦提交用户确认后,对外变动仅仅需要提交变动说明即可,不用重新搞一个新版本;必要的时候,从wiki导出吧。 我更关心需求的完备性、可检索性。文档格式难以胜任: 1、需求和设计间是有一个过程的,需要对需求逐条分析、讨论、设计,中间有很多有价值的过程信息,往word里写很麻烦,而且很难事后检索; 2、功能需求是分阶段发布的,如何跟踪功能需求在各阶段的覆盖情况,对我很重要; 3、对需求的定向检索、需求关联(in-link,out-link)、版本变动、需求变更; 4、开发阶段对需求的追踪、反馈。 如果关注的仅仅是文档本身的质量,word可以搞定; 但关注文档的维护性,可能需要一些工具的支持吧。 恩,我没有太多使用这些工具的经验,但从使用的角度来讲,我希望将需求撰写、维护、管理和需求展示分离。我只需要维护一套需求文档(要很方便撰 写,大部分工具比Word还是差远了啊),但可以以不同的格式展示出来(比如对用户使用其最适宜的格式进行展示)。如果工具能做到这点还是不错的。当然我 希望工具也能尽可能简单。呵呵。 |
|
返回顶楼 | |
发表时间:2008-04-04
继续抛砖。
前面我谈到了将业务规则放到业务规则文档中。但这样做导致交叉阅读,非常不便。并且不容易让读者更好的全面理解需求。因为用例和业务规则的交互是 很频繁的并且他们的联系是十分紧密的。那么有什么办法解决么? 我的想法是将业务规则直接放到对应的用例中作为一个逻辑上的小节。那么问题就来了,如果多个用例引用相同的业务规则呢?这导致很多重复,难于维护 啊。 那么我们先考虑一下用例作为用户的一个比较单一的业务目标。不同的用例是否真的有那么频繁的引用相同的业务规则呢?实际使用中,我发现其实是很少 的。 如果确实遇到了该怎么办呢? 有两个方法可以考虑采用: 1、检查用例是否划分得当;我觉得大多数情况都是提取的用例粒度过大导致的。 2、将不同用例中相同的部分提取为子功能用例。 |
|
返回顶楼 | |
发表时间:2008-04-07
多个用例引用相同的业务规则原文,交给人去维护,会死人的......一修改,就改的鸡飞狗跳,典型的冗余导致的修改异常
引 用同样的规则,就用word的链接搞吧,会轻松一点的... |
|
返回顶楼 | |
发表时间:2008-04-07
alexv 写道
多个
用例引用相同的业务规则原文,交给人去维护,会死人的......一修改,就改的鸡飞狗跳,典型的冗余导致的修改异常
引用同样的规则,就用word的链接搞吧,会轻松一点的... 我上面的意思是说,多个用例引用相同的业务规则的情况本来就不多。而且通过适当的划分用例的粒度,以及提取子功能用例的方法。基本上可以消除重 复。所以不存在维护冗余信息的问题。 我之所以把业务规则放到用例中。主要基于用例和业务规则实在是联系紧密。把他们分开实在是很不便于阅读及理解。 |
发表评论
-
Can a system be an actor in a use case?
2011-01-19 19:21 1518View Full Version : Can a syste ... -
UML用例图中包含、扩展和泛化三种关系详解
2010-04-12 21:13 8755包含关系:比如在自动售货机里面,向柜里增加货品,那么必然包括打 ... -
UML 实践——用例图、顺序图、状态图、类图、包图、协作图
2010-04-12 20:33 2448UML 实践——用例图、 ... -
Doors 和RequisitePro使用比较报告(个人观点)
2010-03-17 17:47 2507今天读到许多介绍需求管理工具的文档,前些年试用过两款工具 ... -
需求管理工具试用 – CaliberRM
2010-03-17 16:57 1668需求管理 工 具 ... -
请问大家都用什么需求管理工具
2010-03-17 16:56 1901请问大家都用什么需求管理工具 楼主 lsoft(lio ... -
JAVA WEB 系统设计开发知识体系
2009-12-05 23:11 18651.1 Browser 1.1.1 HTML 1.1.2 ... -
用JavaScript打开浏览器本地文件,把数据自动填写到表单
2009-12-03 12:38 5899用JavaScript打开浏览器本 ...
相关推荐
在软件开发过程中,一个详尽且清晰的软件需求文档是至关重要的。它为项目团队提供了指导,确保所有相关人员对最终产品的期望保持一致。本压缩包包含了一系列与创建专业软件需求文档相关的资源,适用于软件开发者使用...
针对这一问题,业界存在不同的观点和方法,本文将结合江洋在知乎上的回答以及业界最佳实践,详细探讨产品经理应该先写需求文档还是先画原型的问题。 首先,我们来看江洋的观点:在产品的开发初期,产品经理应先构建...
综上所述,OA项目需求文档加PPT详细文档的目的是为项目的规划、设计和实施提供全面指导,确保OA系统能满足组织的实际需求,提升办公效率,优化工作流程。通过对需求的深入分析和清晰的演示,可以更好地推动OA项目的...
【需求文档2.0:三个原因,解答我为什么用excel写需求文档】 需求文档是产品经理在项目管理中不可或缺的一部分,它清晰地定义了产品的功能和预期。然而,选择使用Excel来编写需求文档可能会让一些人感到疑惑。以下...
本篇内容将深入探讨需求文档PRD的重要性和构建方法,以及通过两个具体的案例来提供实践指导。 首先,我们理解一下需求文档PRD的基本结构和内容。一个完整的PRD通常包括以下几个部分: 1. **产品概述**:介绍产品的...
《ANSI 需求文档模板》和《ISO 需求文档模板》是软件开发中至关重要的文档标准,它们为编写清晰、准确的需求规格说明书提供了结构化指导。需求文档是软件项目的基础,它定义了软件产品应有的功能、性能、界面以及与...
在IT行业中,接口需求文档是系统开发过程中至关重要的部分,它定义了不同系统或模块间的交互方式,确保各个组件能够顺畅地协同工作。本压缩包文件"接口需求文档模板.rar"提供了一份简单实用的模板,旨在帮助开发者和...
产品需求文档(PRD,Product-Requirement-Document)是产品经理工作中不可或缺的一部分,它反映了产品经理的专业素养和整体思维能力。PRD不仅用来明确产品的核心需求,也是连接产品、技术、设计等多个团队的重要桥梁...
《产品需求文档109.rar》是一个非常宝贵的资源包,主要涵盖了产品经理在工作中需要的各种文档模板和实例。这个压缩包的各个子文件名揭示了其包含的重要知识点,让我们一一解析。 1. **市场需求文档(MRD).doc**:...
产品需求文档(Product Requirements Document,简称PRD)是软件开发过程中的重要文档,它详细描述了产品的功能、非功能需求、目标用户、预期效益、风险评估等关键信息,为整个项目提供清晰的指导。淘宝的这份PRD...
【需求文档模板】是软件开发过程中的重要文档,它详细阐述了软件的预期功能和非功能需求,为后续的设计、编码、测试和维护提供明确的指导。以下是对模板各部分的详细解读: 1. **产品描述** - **编写目的**:这...
总之,PRD产品需求文档对于产品团队来说是一份不可替代的重要文件。它不仅要准确地传递产品的信息和要求,还需要为团队的各个成员提供一个明确的方向和指引。一个优秀的PRD能够极大地提高团队的工作效率和产品的成功...
需求分析文档3.0.docx 需求分析文档是软件开发过程中不可或缺的一部分,它旨在收集和分析用户需求,确保软件系统满足用户的需求和期望。下面是对需求分析文档的详细解读和知识点总结: 一、导论 需求分析文档的...
总的来说,《计算机经典——软件需求文档》全面覆盖了软件需求工程的各个方面,对于想要提升软件开发效率和质量的专业人士来说,是一份不可或缺的学习资料。通过深入学习这本书,开发者可以更好地理解和实践需求工程...
需求分析文档,与业务讨论结论,要做最后的讨论,提前将结论发出来
### 百度内部培训:怎样写好MRD(市场需求文档) #### 一、MRD(市场需求文档)概览 **市场需求文档(Market Requirement Document,简称MRD)** 是一款产品需求的完整描述文档,它是软件开发和测试过程中的重要...
产品需求文档(PRD,Product Requirements Document)是产品设计阶段的核心文档之一,它详细阐述了产品的功能、目标、用户群体以及预期的业务流程。在创建一个高质量的产品需求文档时,遵循一定的规范至关重要,以...
总结来说,OA需求文档是OA系统开发的关键,它不仅明确了项目的目标和范围,还为后续的设计、编码和测试提供了指导。实时文档的概念则强调了文档在整个项目生命周期中的动态性和协作性,确保团队始终基于最新的需求...
所以在开发周期早期提高项目需求分析的质量,减少重复劳动,通过控制项目范围的扩展及需求变更来达到按计划完成预定目标是当前我国软件业急需解决的问题—这也是本书讨论的主要内容。 目 录 译者序 前言 第一部分 ...