[需求管理-6]：需求分析 - 技术可行性研究与方案设计模板
Posted 文火冰糖的硅基工坊
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了[需求管理-6]：需求分析 - 技术可行性研究与方案设计模板相关的知识，希望对你有一定的参考价值。
目录
1.3 可行性研究工作中确定的要求：针对期望和需要，即目标（想要什么？）
4.4.3 硬件解决方案备选方案（包括新硬件开发的可能要求）
第1章 技术可行性研究概述
1.1 什么是可行性研究
可行性研究报告：是指从技术、经济、工程等角度对项目进行调查研究和分析比较，并对项目建成以后可能取得的财务、经济效益及社会环境影响进行科学预测，为项目决策提供公正、可靠、科学的软件咨询意见。
主要从经济、技术、社会环境等方面分析所给出的解决方案是否可行，当（1）解决方案可行，（2）并有一定的经济效益和/或社会效益是才开始真正的基于计算机的系统的开发。
三大要素：经济
经济可行性分析主要包括：“成本VS收益”分析和“短期利益VS长远利益”分析。
成本VS收益分析最容易理解，如果成本高于收益则表明亏损了，如果成本大大高于收益那就亏大了。
短期利益容易把握，风险较低。国内软件公司经常出现一窝蜂地去做信息管理系统、多媒体光盘、系统集成项目或Internet服务。
长远利益难以把握，风险较大。能为了长远利益不惜短期亏损的人，要么是雄心勃勃的将帅之才，要么是“纸上谈兵”、“眼高手低” 的那一类庸人。国内有不少Internet企业，只投入不产出。为了成就将来的霸业，甘愿拼财力、比耐性。最后存活下来的几个公司将瓜分市场。
技术可行性是指决策的技术和决策方案的技术不能突破组织所拥有的或有关人员所掌握的技术资源条件的边界。
社会可行性是在特定环境下对项目的开发与实施，社会的可行性分析包括：社会因素的可行性、法律可行性、社会推广可行性、使用可行性等。法律可行性涉及到能不能发布，甚至如果触犯了法律收到的法律制裁会是什么。常见法律问题就是软件抄袭问题，若是抄袭别人软件，将会受到严厉惩罚。所以在可行性分析中应当具有相关法律声明，例如：该系统的开发将不会侵犯任何个人、集体、国家的利益，也不会违反国家的政策与法律。
1.2 什么是技术可行性研究
在分工细致的大型组织内部，市场和技术是分开的两个独立的部门，对市场的预测和技术的分析是两个独立的部门是完成的，特别是复杂系统的软硬件技术方案的可行，需要有专门的软硬件的技术专家才能完成。因此，传统的可行性研究，可以切分成两大部分，一部分重点关注客户的需求，关注产品做成后的盈利。另一根重点关注技术和工程实施，关注技术方案本身，这就本文重点探讨的问题。
技术可行性分析通常要考虑以下几方面因素：
（1）技术要求
（2）竞争对手的功能比较
（3）外部环境的依赖
（4）可能的技术方案
（5）技术方案的风险
1.3 技术可行性研究发生的时机和条件
（1）时机
在商业价值分析FS0阶段时，要确定一下步是否需要进行“技术可行性研究”的任务。
如果需要，则先启动“技术可行性研究”， 然后再进行”技术影响分析“.
如果不需要，则直接进入”技术影响分析“。
（2）判决条件
- 产品经理或架构师的主观经验判决
- 新需要复杂性高，对现有系统的影响比较大，影响的范围比较广。
- 新需要难度大，需要提前安排人手分析新需要的技术方案的可行性和不同方案的比较。
1.4 为什么要做技术可行性研究
就是用最小的代价在尽可能短的时间内确定问题是否能够解决。
要达到这个目的，必须分析几种主要的可能解法的利弊（比较优劣），从而判断原定的系统规模和目标是否现实，系统完成后所能带来的效益是否大到值得投资开发这个系统的程度。因此，可行性研究实质上是要进行一次大大压缩简化了（不是全部细节设计）的系统分析和设计的过程，也就是在较高层次上以较抽象（相对于代码实现）的方式进行的系统分析和设计（相对于编码）的过程。
因此，“技术可行性研究”就是基于当前系统，针对“需求”，进行快速系统设计和不同方案比较的过程。实际上，通过文档的方式，记录了为满足需求进行系统设计的过程。
避免把大量的不确定性、对系统架构有较大影响的因素、技术方案的选择放到软件开发阶段，打破软件Pipeline开发的节奏，导致软件开发环节耗时和波动巨大，无法持续、无法稳定地输出可以工作的软件、硬件。
软件开发环节是人力密集性（脑力密集性）环节，这种不确定性和波动性，会带来组织大量资源的浪费的增加和价值输出的波动性增加。在大型系统中，软件实现阶段和需求分析阶段，人员的比例关系可以达到10:1，甚至更高20:1或50:1.
因此，需要牺牲部分的人力资源（部分的架构师和系统工程师），提前在小范围的人群中（部分架构师和部分吧系统工程师）进行技术可行性分析，消除技术上的各种不确定性。明确新需求的技术方案，包括多种可选或备选方案的比较。
备注：
技术可行性分析的目的是在实施环节更加平稳、安全、高效地实施，从而降低整体的时间和费用成本，如果达不到这个目的，甚至增加了不必要的成本，那么技术可行性分析就是：或多余的、没有必要的，或没有必要提前分析（可以在实施的由技术人员分析）。
因此，针对不同复杂性的需要，技术可行性分析不是必须的，因需要而定。有些简单的需要可以直接跳过，由开发人员自己方案的选择。
1.5 核心概念澄清
（1）可行性
可行性（Feasibility）指对过程、设计、程序或计划能否在所要求的时间范围内成功完成的确定。
是对系统、方案、计划的可实施性进行论证。
注：在可行性研究中，对功能需要采用的备选方案和功能候选（或其他项目）的实现进行评估。
（2）评估
设计方案，并对方案进行评估和论证，以决定是否采纳。
（3）解决方案Solution
解决方案（Solution），就是针对某些已经体现出的，或者可以预期的问题、不足、缺陷、需求等等，所提出的一个解决整体问题的方案（建议书、计划表）或接近问题的办法，同时能够确保加以快速有效的执行。通常指解决问题的方法。
解决方案必需有明确的对象，或者施行的范围和领域。（这些要素可能包括但不限于：不同的行业，领域，阶层，类别等等）
在某些领域，解决方案不止是针对问题本身，也必须考量到需要服务的对象，例如面向的客户的具体情况和需求。
对于问题的实际分析，决定了解决方案的针对性和有效性，如果解决方案本身有欠缺，那么可能在执行中导致更多的问题，达不到预期的效果。
解决方案的产生过程，大致可分为：确定问题对象和影响范围（哪一方面的问题）→ 分析问题→ 提出解决问题的办法和建议→ 成本规划和可行性分析→ 执行→ 后期跟进和交互修正→ 总结
1.5 UML与系统架构描述
UML是一种图形化的建模语言，非常适合软件的方案设计、系统架构、软件设计等环节。
并给出了标准化、可视化的方式来描述一个目标系统和业务场景。建议熟悉一下UML语言。
第2章 技术可行性研究范文
1 导言（Introduction）
1.1 可行性研究的目的
主要阐述，这篇问文章的目的：
阐述与澄清需要的范围和要求，分析问题或需要的多个备选（解决一个问题，可能会有多种手段和方法）的解决方案，并给出建议的解决方案的内容、选择的理由等。
1.2 可行性研究范围：针对要解决的问题（遇到的什么难题）
范围就是周围界限，是上下四周的界限、活动范围、势力范围。
确定问题的边界：哪些是本方案解决的问题，哪些不是本方案要解决的问题。
对新功能的范围进行更详细的明确，以便准确了解该功能的全部内容。
- 如何实现功能或需要的多个可选的技术解决方案
- 根据确定的选择标准来评估多个备选方案，并选择最佳备选方案。
- 推选出来的候选解决方案造成的影响和外部要求或条件（当条件发生改变，最终的方案可以就可以发生改变）
1.3 可行性研究工作中确定的要求：针对期望和需要，即目标（想要什么？）
可行性研究不包含精确要求，但一些精确要求可基于可行性研究的结果来产生。
可行性研究工作中确定的需求被记录到当前的需求管理系统中，并提供给可行性研究作为参考。
2 可行性研究工作计划
在大型企业中，可行性研究不是一个人的事，而是一群来自不同职能部分的人，共同完成的，且可行性研究也是整个组织各种生产活动中的一环，因此，也离不开事前的计划。这样才能分配到合适的人力资源共同完成此任务。
2.1 启动会议
<在可行性研究工作开始之前，始终需要安排启动。
启动的目的是：
- 明确可行性研究的范围并确定未决问题 （范围）
- 确定合作作者和其他利益相关者，他们需要时间和知识来准备可行性研究（人员）
- 商定时间表和工作实践、工作模式（如规划的同步会议、演练会议）的时间> （时间）
＜添加启动会议记录链接＞ //会议纪要
备注：
在会议之前，预先需要进行多方沟通，确保会议的正常进行，确保会议上不出现幺蛾子或出现反水或反对的情形。
会议是让参加活动的各方有一个相同的信息、能够进行步调的同步，相互认识。是一种正式的宣布或宣誓。
因此，从某种意义上讲，启动会议是一种仪式，就像“婚礼是仪式一样，宣誓婚姻的正式开始”
2.2 沟通计划
处于沟通的目的，也便于评审研究中的各种技术决定，这些技术决定本身就是技术方案的组成部分。
为此，需要明确参与到技术研究中的不同人信息。主要有三大角色：撰写、评审、观察。
岗位角色 角色 姓名 职责范围 其他附属信息 xxx领域架构师
xxx系统工程师
撰写/撰写/观察
yyy 第x章节 .......... 2.3 可行性研究计划时间表
<为了沟通和审查作为解决方案选择的一部分做出的决定，需要有一份功能工作的参与者列表。
<本章确定可行性研究工作组中的人员（主要作者、共同作者和功能负责人、测试和应用程序的代表、架构师等）。
还需要召开一次概述会议（介绍可行性研究的主要内容）。
在完成工作之前，评审技术可行性的内容是否符合他们技术领域的要求，并对内容的结果负责。
最终的验收可以作为日常审查/检查过程的一部分或启动一个单独处理流程>
主要的关键时间节点，要与项目计划一致，比如：
- 启动时间
- 初定版本的时间节点
- 最终的完成时间节点
3. 特征描述
<从一般层面和软件当期系统增量的角度描述功能。
如果功能替换了现有功能，请在此处进行说明。
在此描述该功能对运营商的好处和市场需求。
提出的功能试图解决的问题是什么，或者它将为运营商带来什么新的附加值。
与介绍章节相比，更详细地描述该功能。>
3.1 假设和前提条件
＜功能需要的时间机会窗口＞
＜发布的时间计划＞
＜其他前提条件或假设性条件＞
3.2 选择标准
<在可行性分析工作开始钱，与产品经理和产品架构师一起制定备选方案的选择标准。
这是为了确保可行性研究侧重于特征筛选过程最初的目标>
比如：性能优先、成本优先、时间优先、商业目标的标准等等。
目标不同，标准不同，多个方案的选择结果不同、方案或技术可行性研究的重点不同。
3.3 限制和依赖、约束条件
<在本章中，描述了该功能是否具有某些限制或限制。
还可以估计该特征可能被使用的程度。如果该功能在“大量”使用时可能导致负载问题，如CPU负载或消息传递，请在此提及。
比如硬件的限制或约束条件有：体积、总量、功耗、费用等等。
3.4 客户的利益和需求
<在此描述解决需要给客户带来的好处
以及该功能将带来的内部附加值或
建议的功能试图解决的问题。>
3.5 特性互操作
该章节阐述该功能与其他功能的交互和依赖关系。
3.6 现有解决方案
＜如果功能所涵盖的功能已经部分实现，请描述现有解决方案的主要部分及其限制。＞
3.7 合规性信息
<确定了相关规范和/或标准，并简要描述了该功能如何符合这些规范>
在移动通信中，3GPP就是所有厂家必须遵循的规范。
3.8 用例（User Case或User Story）
此处包括与分析需求相关的用户用例。这将明确系统在现实生活中应该做什么。
应在此插入主要错误或异常案例（尤其是您已经知道可能很关键或很难解决的错误或异常案例），否则，工作量估算是不可信（例如，系统启动、切换、恢复案例等的错误案例）。>
异常用例是容易被忽略的，但异常却是影响系统鲁棒性和复杂性的关键性因素。
3.8.1 用例模板
（1）用例名称
（2）用例的操作者
（3）功能目的简述
（4）前置条件（执行前的准备）
（5）操作活动或过程或步骤
（6）后置条件（执行后的效果）
（7）异常情形
（8）与之关联的用例
（9）性能要求
4. 建议的实施备选方案
<在以下分章节中，需要更详细地描述了基于产品经理提供的选择标准得道的方案的推荐理由，以及推荐的实施方案，包括：
- 需要一些用户界面等>
- 网元内部，不同技术领域/组件的影响是什么
- 需要什么样的服务/程序块 （结构结构）
- 什么类型消息交互。 （动态时序）
- 什么文件、数据库等 （静态数据）
4.1 建议和理由
在此描述推荐的备选方案是什么，以及选择该备选方案的原因。
4.2 实现架构
<在此描述功能的静态视图。使用类图和实现图来描述。
在“对信令和协议的影响”或“对网络元素的影响”中描述对象的责任>
此时，把系统内的功能组件看成一个个独立的黑盒子 。描述实现功能需要所涉及到的系统内的功能组件，以及功能组件对外呈现的特征（属性）
4.3 特性功能（功能组件对外的交互）
<请在此描述功能的动态视图。
这里是比第4章更详细的功能描述。
使用协作图、序列图/时序图、状态机图等>
4.4 对软件和硬件的影响
描述功能/需求对软件和硬件的影响
4.4.1 对软件SW的影响
这里描述功能/需求对软件功能组件内部子模块、行为模式的影响。
4.4.2 软件配置和升级注意事项
这里描述功能/需求对OAM管理、软件升级的影响。
4.4.3 硬件解决方案备选方案（包括新硬件开发的可能要求）
这里描述功能/需求对硬件解决方案备选方案（如果可用），以及是否需要开始新的硬件开发>。
4.4.4 对硬件HW的影响
这里描述功能/需求对硬件内部功能模块的影响。
4.4.5 硬件配置和系统维护
这里描述功能/需求对硬件配置，如硬件模块的组合、硬件的算力等影响。
同时还描述对系统维护方面的影响。
4.5 外部接口和要求
＜描述该功能对外部接口的影响，以及由于该功能需要设置到软硬件平台或OEM产品的要求。＞
4.5.1 对外部接口的影响
描述该功能对设备与外部网元之间接口的影响。
4.5.2 对平台的要求
包括软件平台的要求和硬件平台的硬件
软件平台：操作系统的类型、版本
硬件平台：云平台还是嵌入式平台等、嵌入式硬件平台的型号。
4.5.3 对第三方产品的要求
对第三方产品的要求：型号、平台、接口扥
4.6 性能和容量考虑
＜从性能和容量的角度描述功能的功能。＞
不同的目标系统，硬件指标是不同的。
4.7 安全考虑
＜本章描述了功能对安全性的影响。＞
4.8 可用性考虑
<研究硬件和软件所需的可用性。与设计中心、软件和硬件代表（如适用）就相关概念活动达成一致意见>
可用性是交互式IT产品/系统的重要质量指标，指的是产品对用户来说有效、易学、高效、好记、少错和令人满意的程度，即用户能否用产品完成他的任务，效率如何，主观感受怎样，实际上是从用户角度所看到的产品质量，是产品竞争力的核心。
4.9 其他考虑
<在本章中考虑其他系统范围的影响。包括
- 网元的可用性（弹性原则和过载控制）
- 网元和/或功能单元的启动时间
- 可操作性
- 系统统计
- 负载消耗
- 内存消耗
- 软件许可
- 第三方和开源软件（知识产权、法律……）>
4.10 工作量估算
<在本章中描述推荐备选方案的工作量估算，即需要的人力资源的估算。
需要考虑所有流程阶段，不仅仅是软件编程，包括需要规范、软件设计、测试。
与相关研发专家/技术领域专家讨论，以获得每个受影响区域的工作量的估计值。
为了估算集成测试、回归测试、系统测试的工作量，需要与相关职能领域的测试专家进行估算。
根据已经澄清的事实进行工作量的估算。
对于仍然存在未解决或不清楚的问题，则应明确说明并记录在第4.13章中加以明确。不在估算的范围之内。
为了使得估算尽可能的准确，最好能够对用户的需求和可能的技术方案进行拆分。然后基于拆分的子功能或用户故事进行工作量的评估
使用下表进行工作量估算。
需求任务 需求子任务 评估人 工作量评估值
4.11 对测试的影响
<本章描述了项目对测试的影响。
- 受影响的功能特征
- 启动过程的影响
- 在开发阶段直接使用主分支软件构建的风险等级
- 测试水平
- 测试接口、测试工具和测试设备
- Traffic流量测试
- 安全测试：（即决定是否需要对该功能进行单独的安全测试）
4.12 知识产权
<并非所有功能都需要进行专利检查；
特定产品计划的知识产权计划，帮助你检查，你的功能是否需要知识产权分析。
但是，尽管知识产权计划会说您的功能不需要专利检查，但请您提出批评，并考虑是否仍然需要专利搜索。可能是可行性研究工作中出现的一些问题在更新IPR计划时不相关或不可见。有关知识产权检查需要的任何问题，请联系相关产品计划经理。>
>
4.13 未决问题和风险
<本章包含与解决方案相关的风险（包括技术风险（如有））和问题，
这些问题目前还不清楚，应在下一个过程阶段予以澄清。
您也可以在可行性研究工作中使用本章来提出某些时间存在的未决问题。>
>
5.分析了实施备选方案
<介绍替代实施方法的主要原则（如有可能），并对其优缺点进行了评估。
这里还提供了粗略的工作量估算。
为了比较备选方案，演示文稿必须处于同一水平。
描述必须足够准确，以便能够进行比较和选择。
如果不同的备选方案包含相同的元素或选择，则可以参考先前的备选方案。
一方面，不要试图发明出一个想象出来的替代方案，只描述真实可能的替代方案。
另一方面，确保花费足够的精力寻找可能的替代方案。>
5.1 备选方案
6. 术语和缩写
<本章包含本文件中使用的术语和缩写的解释。按字母顺序呈现>
7. 参考文献
＜公共参考：
公共材料可以分发给任何人。通常情况下，公共信息应该为每个人提供。
标记外部参考的版本信息，如标准、公共规范等>
＜内部使用参考：
这些物品可以分发给组织内员工。向公众披露少量此类信息不会对公司造成重大损害。
8. 修订历史
Version
Date
Modified by
Status
Accepted by
Main changes
以上是关于[需求管理-6]：需求分析 - 技术可行性研究与方案设计模板的主要内容，如果未能解决你的问题，请参考以下文章
毕业设计C++基于MFC实验室机房管理系统毕业论文|寻找C站宝藏