国外大公司确实是按照项目管理流程来组织产品开发的，做产品讲究团队合作，没有一个流程，不就乱一团了吗。但是，对于高端的新产品，他们会先进行预研，而不急于立项，正如南方的老树所讲的，一旦立项，就要按程流走了。国外大公司一般都有专门的预研部门，如微软的中国研究院。
    
    高端新产品的预研往往是要花费很长时间的，产品预研其实与产品开发有本质的区别，因此，ISO9001:2000的项目管理流程并不适合于产品预研。产品预研的流程管理是相当开放、相当民主的，努力给预研人员营造一个宽松的气氛，使其创造力与灵感能得到充分的发挥。这些预研人员准确地讲，应该叫Researcher或Scientist，与Engineer是有差别的，人家Reseacher或Scientist可是“养”起来的！很多在国外大公司中国分公司工作过的人，总以为是规范的项目管理造就了产品的高科技，殊不知，人家把产品放到中国来“开发”之前，已经在国外research很长时间了，核心技术已经全部OK了。在中国所做的“开发”，说得不好听一点，就是给别人扫尾巴，没有多少技术难度，当然可以按照项目管理流程来on scedule进行了。
    
    国内公司目前普遍存在的一个问题就是把产品预研与产品开发混为一谈，盲目套用所谓的项目管理流程，结果严重束缚了研发人员的创造性和主动性，当然做不出什么高科技。

    中国为什么没有人能获得诺贝尔奖？不是中国没有牛人，而是中国的现行制度严重地束缚了那些牛人的创造力！同样，中国的企业为什么做不了高科技？不是中国没有高科技人才，而是这些高科技人才的潜力没有得到充分的发挥！

admin 产品和项目开发流程 产品预研, 项目流程

[#2: Edit Options>MightyAdsense>Adsense Code]

需求分析是发现、求精、建模和规约的过程。这一过程包括：详细精化最初由系统分析员建立并在软件项目计划中确定的软件范围，创建所需数据流、控制流以及操作行为的模型，在此基础上选择的解决方案。
在可行性研究之后，我们对值得开发的软件进行需求分析。

3.1.1 需求分析

需求分析是一种软件工程活动，使得系统分析员能够刻划出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束。需求分析是软件设计师进行软件分解的基础，需求分析建造了软件处理的数据模型、功能模型和行为模型。需求分析为软件设计师提供了可被翻译成数据、体系结构、界面和过程设计的模型，最后，需求规约为软件设计师和客户提供了软件建造完后，进行质量评估的依据。

1.软件需求的概念和分类
在我们分析需求之前，先要了解需求的类别，在获取需求时，按类别来处理就不容易遗漏。对需求有很多种不同的分类方法，其中的一种分类方法告诉我们需求应该包括：

1. 第一是功能需求，这方面的需求指定系统必须提供的服务，通过需求分析应该划分出系统必须完成的所有功能；
2. 第二是性能需求，性能需求指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求；
3. 第三是可靠性和可用性需求，可靠性和可用性需求即需求定量地指定系统的可靠性与可用性；
4. 第四是出错处理需求，这类需求说明系统对环境错误应该怎样响应，例如，如果一个系统接收到从另一个系统发来的违反协议格式的消息，该系统应该做什么？
5. 第五是接口需求，接口需求描述应用系统与其环境通信的格式，常见的接口需求有用户接口需求、硬件接口需求、软件接口需求和通信接口需求；
6. 第六是约束，约束描述了应用系统应遵守的限制条件，在需求分析阶段提出这类需求，并不是要取代设计（或实现）过程，这只是反映了用户或环境强加给项目的限制条件，常见的约束有：精度约束、工具和语言约束、设计约束、应该使用的标准、应该使用的硬件平台等；
7. 第七是逆向需求，逆向需求说明了软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除发生误解的那些逆向需求；
8. 第八是将来可能提出的要求，应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求，这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。

2.需求分析的任务
需求分析的任务是借助于当前系统的物理模型（待开发系统的系统元素）导出目标系统的逻辑模型（只描述系统要完成的功能和要处理的数据），解决目标系统“做什么”的问题，所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求，通过逐步细化对软件的要求，描述软件要处理的数据，并给软件开发提供一种可以转化为数据设计、结构设计和过程设计的数据与功能表示。必须全面理解用户的各项要求，但这些要求不能全盘接受，只能接受合理的要求；对其中模糊的要求要做进一步澄清，然后决定是否采纳；对于无法实现的要求要向用户作充分的解释。最后，将软件的需求准确地表达出来，形成软件需求说明书。其实现步骤如图3.1所示。
 

图3.1 参考当前系统建立目标系统模型

（1）获得当前系统的物理模型：首先，分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入/输出、资源利用情况和日常数据处理过程，并用一个具体的模型来反映自己对当前系统的理解。此步骤也可以称为“业务建模”，其主要任务是对用户的组织机构或企业进行评估，理解他们的需要及未来系统要解决的问题，并用一个具体模型来反映自己对当前系统的理解。这一模型应客观地反映现实世界的实际情况。当然，如果系统相对简单，也没必要大动干戈地进行业务建模，只要做一些简单的业务分析即可。
（2）抽象出当前系统的逻辑模型：在理解当前系统“怎样做”的基础上，取出非本质因素，抽取出“做什么”的本质。
（3）建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，明确目标系统要“做什么”，从而从当前系统的逻辑模型中，导出目标系统的逻辑模型。
（4）对目标系统逻辑模型进行补充，具体内容如用户界面、启动和结束、出错处理、系统输入输出、系统性能、其他限制等等。

3．需求分析的主要工作
软件需求分析可被划分成5个工作阶段：问题分析；问题评估和方案综合；建模；规约；复审。
例1. 汽车零件的主要供应商需要一个库存控制系统，系统分析员发现与当前的手工系统相关的问题包括：（1）不能快速地获得部件的状况；（2）更新卡片文件需要2至或3天的工作量；（3）由于没有办法查找相关厂商的部件信息，而使得对同一厂商同一货品多次再订货，等等。一旦问题被标识出来，系统分析员将确定新系统该产生什么信息，以及将提供什么信息。
例2. 客户希望得到指明什么零件从库存中取出、以及还剩余多少相似零件的日报表。客户指明一旦当该零件离开仓库时库存管理员就该记载每个零件的标号。通过对当前问题和希望的信息（输入和输出）进行的评估，系统分析员开始综合一个或多个解决方案。为了便于开始，必须详细地定义系统的数据、处理功能和行为。
例3. 在例1与例2的基础上，一些可以进一步思考内容是，一旦已经建立这些信息，就该考虑针对实现的基本体系结构，那么客户/服务器方法似乎是合适的，但是它确实属于在软件计划中概括的范围吗？似乎需要一个数据库管理系统，但是，该数据库系统真的是用户/客户需要的吗？继续评估和综合的过程，直至分析员和客户均确信针对后面的开发步骤软件确实已被适当地刻划了。
例3. 说明了在贯穿整个评估和综合过程，分析员的主要焦点是“做什么”，而不是“怎么做”，即应该思考的是：系统会产生和使用什么数据？系统必须完成什么功能？将定义什么界面？会应用什么约束？。在问题评估和综合解决方案的活动中，系统分析员创建系统模型，以便可以更好地理解数据流和控制流、处理功能和操作行为以及信息内容。

4. 系统分析员的主要能力
毫无疑问，在整个系统分析活动中，系统分析员起着关键的作用，这意味着我们对系统分析员有着较高的期望，其本人也应该具备各项突出的能力。这些能力的主要表现如下：

1. 能掌握抽象概念，能对其进行分类，能从中综合出解的能力；
2. 能从冲突或者混淆中吸取恰当事实的能力；
3. 能弄清用户环境的能力；
4. 能伪用户系统恰当配置软硬件的能力
5. 能较好地用书面和口头形式进行沟通的能力；
6. 有“从树木见森林“的能力。

3.1.2 需求获取

软件需求分析中的相互沟通，总是要在两方或多方间进行。系统分析员所问的第一组问题可以关注客户、整体目标和收益。接下来的下一组问题使得系统分析员能够对问题做更好的理解，使得客户能够表达其关于解决方案的感觉，例如：如何刻画由某成功解决方案所产生的“好的”输出？该解决方案强调了什么问题？能向我显示或描述解决方案所应用的环境吗？系统分析员所问的最后一组问题关注于会议的效果。例如：你是回答这些问题的合适人员吗？你的回答是“正式的”吗？我的提问和你想解决的问题相关吗？其他人员可以提供附加信息吗？其他我应该问你的问题吗？
除了上述做法之外，也可以采用一种面向团队的需求收集方法，该方法被应用在分析和规约的早期阶段，被称为便利的应用规约技术，即FAST技术，该方法鼓励建立客户和系统分析员之间的合作，由他们共同工作来标识问题、提出解决方案的要素、商议不同的方法以及刻画出初步的解决方案需求。
FAST方法的基本原则是：

1. 在中立的地点举行会议，由系统分析员和客户出席。
2. 建立准备和参与会议的规则。
3. 建议一个足够正式的议程，以便可以对所有重要点的、而又是足够非正式的问题进行自由交流。
4. 有一个“协调者”控制会议过程。
5. 使用一种“定义机制”（它可以是工作表、图表、墙上胶黏纸或墙板）记录有关信息。
6. 会议的目标是标识问题、提出解决方案的要素、商议不同的方法以及在有利于完成目标的氛围中，刻画出初步的解决方案需求。

3.1.3分析原则

在过去20年，研究者已经开发出一些实用分析方法及相应的建模符号，每种分析方法有独特的观点，然而，所有分析方法都遵循以下操作原则：

1. 必须表示可理解的问题信息域。
2. 必须定义软件将完成的功能。
3. 必须表示软件的行为（作为外部事件的结果）。
4. 必须划分描述信息、功能和行为的模型，从而能以层次的方式揭示细节。
5. 分析过程应该从要素信息移向细节实现。

3.1.4 需求规格说明

软件需求规格说明是分析任务的最终产物，美国国家标准局、IEEE（标准号830－1984）以及美国防部门均已提出了软件需求规约（以及其他软件工程文档）的候选格式。
编写需求的人必须描述的基本问题是：

1. 功能——所设计的软件要做什么；
2. 性能——是指软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等；
3. 强加给实现的设计限制——在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标准；
4. 属性——可移植性、正确性、可维护性及安全性等方面的考虑因素；
5. 外部接口——与人、硬件、其他软件和其他硬件的相互关系。

下面给出一种软件需求规格说明的撰写大纲。
表3.1 软件需求规格说明的大纲

3.1.5 评审

下面的问题会被提出并确认：

1. 叙述的软件目标与系统的目标是否保持一致？
2. 已经描述了所有系统元素的重要接口吗？
3. 已经定义了合适的问题域的信息流和结构吗？
4. 图是否清楚？每个图可以没有文字补充而单独存在吗？
5. 是否主要的功能保留在规定范围中，并且均已合适地描述？
6. 软件的行为和它所必须处理的信息及必须完成的功能是否一致？
7. 设计约束是可现实的吗？
8. 是否考虑过开发的技术风险？
9. 是否考虑过其他可选的软件需求？
10. 校验标准是否被详细地陈述？它们对成功描述的系统是合适的吗？
11. 是否存在不一致性、是否信息被忽略或存在冗余？
12. 和客户全面接触过吗？
13. 是否用户复审过初步的用户手册或原型？
14. 计划的估算受到什么样的影响？

下面的指南是针对详细的规约复审而提出的：

1. 着重于说服性的连接词（例如，当然、因此、明确地、显然地、紧随的），并问“为什么”。
2. 观察含糊的术语（例如，一些、有时、经常、通常、一般地、大多数、大多数的），并进行澄清。
3. 当给出了不完整的列表时，确定已理解了所有的项。关键是查找“等等、如此这样”。
4. 确定陈述的范围没有包含未陈述的假设（例如，从10到100的校验代码范围究竟是整数？实数？还是复数？）
5. 小心含糊的动词如“处理、拒绝、处制、跳过、限制”等，它们可以以很多方式来解释。
6. 小心含糊的代词（例如，I/O模块与数据校验模块通信，且设置它的控制标志，那么标志是谁的？）
7. 查找蕴含了确定性的语句（例如，总是、每次、所有、无、永不），然后要求证明它们。
8. 当某术语被明确地定义在某地方，力图用该定义去替换其他的出现术语。
9. 当用语句描述某结构，画出图以帮助理解。
10. 当刻画计算时，至少试验两个例子。

一旦复审完成，软件需求规格说明就变成了客户与软件工程师之间的软件开发“合约”。但在软件需求规格说明完成后也可能被修改，但是，客户应该注意，每个事后的修改是对软件范围的扩展，因此可能存在着增加成本或延长项目进度等情况。

admin 产品和项目开发流程 需求分析, 需求收集

[#3: Edit Options>MightyAdsense>Adsense Code]

前言

需求收集與分析的目的，主要是用來辨別客戶需要的是什麼，其目標在於描述客戶對於專案所預期呈現的結果，然後以有系統的方式加以整理列出。在許多書裡，大都只強調需求完整的重要性，或是列出一些很空洞的施行綱要，但對於實作時，需求要怎麼收集、要怎麼分析幾乎都很少提到，使得無經驗的專案經理往往不知如何著手，只能利用嘗試錯誤的方法摸索進行。因此本文特別著重在需求收集與分析的施行方法與技巧上，這些都是作者多年經驗所累積下來的知識，無論對於有經驗或無經驗的專案經理而言，都是一份極有參考價值的資料。

套裝類軟體的需求收集

套裝類的軟體產品所面對的客戶，通常是某個族群，即使有了許多已知的客戶，但潛在的客戶往往還更多，因此它的需求會比較模糊而寬廣，難以收集完整，不過相對的，客戶對於某些不符自己所需的地方也不會太過強求，驗收的標準會比較寬鬆些。而我們所要做的，便是儘量收集到客戶的需求（包括未來可能的需求），再依照目標客戶對各項需求的急迫性加以區分，最後視開發的時程與成本，分階段開發出來。以下便是收集這些需求一些有用的做法：

1.由目標客戶找出需求

a.與既有客戶或未來可能的客戶進行訪談或意見調查，將客戶建議的事項視為需求，逐一列出。

收集需求的最佳方式，永遠都是由客戶端獲得。但由於套裝軟體的客戶群並不固定，因此最好能依照應用領域、運用方式、使用頻率、對電腦系統的熟悉程度、地理位置、職位階層等各種客戶特性，區分出多個目標客戶群，然後針對最重要的幾個目標客戶群進行意見調查或訪談。

b.參考與軟體產品相類似的專案之建議書、功能規格書或需求變更表，將可能成為需求的部份逐一列出。

開發套裝軟體產品最佳的策略，便是以專案養套裝，也就是在開發初期，利用專案收集需求（同時也可獲利），之後再集結這些需求開發出套裝軟體。因此如果公司已有類似的專案，直接拿來參考即可省下不少需求收集的時間。

c.逐一過瀘類似專案或舊版軟體之客戶問題反應單，思考問題的原因，並將可成為需求的部份逐一列出。

客戶反應的問題中，有一小部份是客戶要求的新功能或功能規格變更，這些問題都意味著客戶的隱藏性新需求。然而在收集需求時，不能直接把客戶要求的新功能直接視為需求列出，而要先去了解客戶提出這項功能的動機與目的。因為客戶在有需求時，往往會先自行想出做法，然後才要求軟體開發商新加功能，此時這項功能已和原來的需求有所差異，若是客戶自行想出來的做法很爛，那麼將它視為需求開發出來的結果，往往便會成為一項雞肋功能（食之無味、棄之可惜）。

2.由競爭廠商找出需求

a.向行銷企劃部或業務部拿取競爭廠商相關資料，找出可成為需求的部份逐一列出。

行銷企劃部在進行市場調查與研究，或業務部在推展業務時，往往都會研究競爭廠商的動態，以及相互間產品的特性。直接找他們拿取資料，最是方便省時。

b.由競爭廠商公布的產品規格書、白皮書、廣告稿與網站資料，找出可成為需求的部份逐一列出。

由於行銷企劃部或業務部的競爭廠商資料大都已經過分析，未必適於收集需求，因此還是必須直接閱讀競爭廠商的實際產品資料來加以研究。至於有那些競爭廠商，則可從行銷人員與銷售人員處取得，或是經由入口網站搜尋取得。而且只要是與產品目標市場與功能特性有沾上邊的廠商，都應視為競爭廠商加以研究。

c.由競爭廠商相關的新聞資料，找出可成為需求的部份逐一列出。

競爭廠商所發布的新聞資料，往往隱含著對方未來的產品規劃與方向，因此必須仔細加以研究，及早因應。

3.由現行資料找出需求

a.將「發展計畫書」中的專案目標與範圍部份，視為需求逐一列出。

套裝軟體要開發，一定有其目的及市場需求，通常在專案開始時，都會列在發展計畫書中，而這些內容也都算是需求的一部份。在記錄這些需求時，要特別注意其品質特性的需求。

b.找出與專案軟體相關的流行技術、界面標準或法令規章，將可成為需求的部份逐一列出。

藉由這方面的需求收集，可確保專案軟體能符合相關的介面標準與法令規章，同時也能符合技術潮流的走向。

c.參考舊版軟體各版本之軟體規格書與技術文件、使用手冊，將其中所列之需求逐一列出。

如果不是全新開發的套裝軟體，那麼舊版軟體的各項文件，便是個極佳的需求資料來源。

d.試用舊版軟體，將其中之各項功能與應改進缺點視為需求，逐一列出。

如果舊版軟體缺乏文件可供參考，試用便是取得舊版需求的唯一方法。不過即使有完整的文件，也可經由試用過程找出缺點，做為新版改進的需求。

4.由未來產品找出需求

a.與核心技術人員、產品經理、行銷人員、銷售人員討論未來套裝軟體可能衍生的產品、相關的產品、以及可能的合作廠商整合方式，在討論內容中找出可能的需求，逐一列出。

藉由這種方式，可以找出未來功能擴增的可能需求，以及應提供出來的界面需求，強化軟體的擴充性與公用性。

b.列出現行所有的核心技術，並參考其相關文件，找出加入時可成為需求的部份逐一列出。

套裝軟體現行規劃的目標，不一定全用到所有核心技術，因此必須將所有將來可能加入的核心技術都列出，並思考加入時可能會造成的需求。

c.自己思考或詢問同事對該產品的新點子。

如果自己創意夠的話，花些時間好好想想，有時能提出一些不錯的功能，或是被忽略掉的需求。

5.由模擬方式找出需求

a.找出一個或多個專案軟體運用的例子，模擬其運用過程，由過程中找出遺漏的需求。

由於套裝軟體沒有很明顯的客戶群界限，要鑑訂是否有遺漏的需求，最好的方式便是仿造幾個客戶使用的可能例子，在其作業的過程中來驗證是否有遺漏的需求。

b.利用系統分析技術，如結構化分析中的資料流程圖（Data Flow Diagram，簡稱DFD）和物件導向分析中的使用案例（Use Case）等，定出容納所有需求的系統模型，並檢查各需求相互間的關係，以試圖找出未明白列出的隱藏性需求。

這是需求收集的最後一道防線，主要目的便是運用需求的交互關係，來找出隱藏性未列出的需求，使得各項需求緊密連繫在一起。同時藉由建構此一系統模型，也容易檢查出相衝突的需求。這個方法可以延到需求分析的篩選過程中進行。

admin 产品和项目开发流程 需求收集