软件需求获取来源 软件需求获取方法
如何进行软件需求分析
1.概念需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求.关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起.系统的分析人员说：＂我们想与你谈谈你的需求.＂客户的第一反应便是：＂我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统＂.百事通而实际上，UGGs，需求并未编写成文档，因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人.需求的另外一种定义认为需求是＂用户所需要的并能触发一个程序或系统开发工作的说明＂.有些需求分析专家拓展了这个概念：＂从系统外部能发现系统所具有的满足于用户的特点、功能及属性等＂.这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性：需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性，是在开发过程中对系统的约束.从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的＂需求＂术语存在，真正的＂需求＂实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.任何文档形式的需求（例如如下将要描述的需求规格说明书）仅是一个模型，一种描述.2.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难.目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题.对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？然而，即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生.近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了.相反的情况，我曾见一个要集成到＂错误跟踪系统＂中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误.事实上，需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适，如图4-1所示：图4-1 需求工程域的层次分解示意图需求开发可进一步分为：问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面：确定产品所期望的用户类别.获取每个用户类的需求.了解实际用户任务和目标以及这些任务所支持的业务需求.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件.了解相关质量属性的重要性.商讨实施优先级的划分.将所收集的用户需求编写成文档和模型.评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要＂建立并维护在软件工程中同客户达成的合同＂ .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中.通常的需求管理活动包括：定义需求基线（迅速制定需求文档的主体）.评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.以一种可控制的方式将需求变更融入到项目中.使当前的项目计划与需求一致.估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体现在项目解决方案上.让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.在整个项目过程中跟踪需求状态及其变更情况.以上几点说...
uml与系统分析设计复习题 软件需求来源有哪些
对于复杂功能的用例面向对象的程序1，得到相同的部分.用协作图将操作函数化，用返回值将属性变量化。
对有些功能进行模块化扩展，称为扩展用例。
对增加的类重新画序列图。
从类图得到程序的结构，从顺序活动图得到程序的过程（C++）.重画有控制类的序列图、协作图、活动图。
。
分解活动图。
四，子系统的划分：类图，到类分析图为止。
对用户与用例可以用继承关系，异常事件，错误输入与错误处理等序列图集。
二， 注意活动图要细化到与序列图相同程度。
按照不同用户画出不同用例图。
按照不同物理位置画出部署图；按照不同类型用户对程序进行分类，得到组件图。
从序列图得到协作图，并且进行简单类分析，得到类分析图，分解成多个包含用例，活动图与协作图。
类图是源码的来源。
用例的主功能用序列图表示。
序列图的消息变成操作，消息中的信息变成属性。
分析类图。
细化状态图。
状态图为主，应用类图是重心，画出全部用户的细化用例图.给出类状态图的活动表达式。
状态图的事件是序列图的消息，是类的操作，活动表达式是转换事件的实现，因此是类的操作的实现，得到用例的完整功能、总体设计 为用户所见的系统计算机层面，包括界面。
部署图，进行简单类分析。
用例的状态可以用状态图标识，从中得到新的属性与操作，根据某一个操作：进程，设置硬件，分解成包含用例，活动图（模块图），组件图，部署图。
将类align到组件中，将组件到部署图中。
每一个用例的完整序列图，包括主功能，备用功能、需求分析阶段：以用例图为主，说明与其它系统的接口。
画出系统总体设计图，根据应用类图与顺序活动图。
建立程序设计的完整模型。
细化用例图。
从序列图得到协作图。
与活动表达式不同。
将应用类图变成设计类图，用具体的语言，比较每一个用例的活动图.需求分析2.总体设计3.详细设计阶段4.实现阶段一、实现阶段建立并发视图。
组件图：可执行文件，配置文件。
建立UML总体模型，特别是实体类。
增加类：界面类，事务管理类。
画出系统状态图（有活动表达式），对重要的类画出类的状态图，每一个分支一个序列图。
用一个活动图归并全部序列图，遇到分支用菱形框。
三、详细设计阶段 程序的内部结构与实现方案的详细类图为主，重点是增加控制类...
软件的需求分析怎么写啊？
1. 引言1.1 编写目的：编写此文档的目的是进一步定制软件开发的细节问题，便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体.1.2 项目背景1.2.1项目委托单位：****公司1.2.2开发单位：***公司1.3 定义1.4 参考资料2. 任务概述2.1 目标： 决策支持：根据公司的要求及时提供所需报表及文件，并在适当时候对各部门领导给予销售及进货等方面的提示提高效率：利用软件进行管理，避免人工管理的失误以及 延迟性，从而实现高效率的管理.2.2 运行环境： 硬件方面：Pentium级处理芯片 1兆显存的兼容显卡 256色，800*600的兼容显示器 标准兼容打印机软件方面： WIN95操作系统2.3 条件与限制： 编程用计算机一台 完成期限2000/7/1 无资金供给3. 数据概述数据流程图如下： 3.1 静态数据：包括系统登录密码，各数据库所在位置，系统分析原始数据3.2 动态数据：包括各数据库内各项显示数据，用户登录信息，系统时间3.3 数据库描述： 人事管理数据库：公司内人员的个人详细信息，包括档案信息 销售管理数据库：当日销售记录及以前的销售统计，用于销售分析 财务管理数据库：公司内部账目及收支情况详表 技术管理数据库：公司所需各技术档案的详细记录（包括文档） 3.4 数据字典：数据流词条描述： 1.数据流名：登录信息 来源：用户的输入 去向：系统内部检验部分 组成：用户名，密码 流通量：每次登录输入一次 2.数据流名：登录结果 来源：系统 去向：用户 组成：返回信息 流通量：每次登录返回一次 3.数据流名：输入修改信息 来源：用户 去向：系统判断部分 组成：根据各数据库内容而不同 流通量：依用户输入而定 4.数据流名：反馈信息 来源：系统判断部分 去向：用户 组成：系统经判断后发回的字符数据 流通量： 依系统当前信息而定 5.数据流名：识别信息 来源：系统内部检验部分 去向：系统判断部分 组成：系统各数据库的标识信息 流通量：用户每次输入流通一次 6.数据流名：处理信息 来源：系统判断部分 去向：各数据库处理部分 组成：读取/修改标识，读取/修改的变量名称 流通量：用户每次输入流通一次 7.数据流名：读取修改 来源：系统判断部分 去向：系统各数据库 组成：读取/修改标识，读取/修改内容 流通量： 用户每次输入流通一次数据文件词条描述： 1.数据文件名：人事数据 简述：存储人员信息 数据文件组成：人员的各项信息（以CString类型为主） 2.数据文件名：销售数据 简述：存储当日及从前的销售记录 数据文件组成：销售的各项信息 3.数据文件名：财务数据 简述：存储财务管理信息 数据文件组成：财务管理的各项记录 4.数据文件名：技术数据 简述：存储公司内部使用的技术档案信息 数据文件组成：技术档案名称，内容加工逻辑词条描述： 1.加工名：检验 简要描述：判断用户的许可性 输入数据流：登录信息 输出数据流：登录结果 加工逻辑：判断是否与系统内部用户信息相符合 2.加工名：判断 简要描述：判断用户的操作并进行相应的读取/存储工作 输入数据流：输入修改信息 输出数据流：反馈信息 加工逻辑：判断用户的操作->调用数据库->读取/修改->反馈 3.加工名：人事档案管理 简要描述：对人事数据库进行相应要求的操作，并与判断部分交互 输入数据流：处理信息，读取修改 输出数据流： 读取修改， 处理信息 加工逻辑：判断用户要读取/修改的内容->反馈用户所需信息 4.加工名：销售统计 简要描述：对销售数据库进行相应要求的操作，并与判断部分交互 输入数据流：处理信息，读取修改 输出数据流： 读取修改， 处理信息 加工逻辑：判断用户要读取/修改的内容->反馈用户所需信息 5.加工名：财务统计 简要描述：对财务数据库进行相应要求的操作，并与判断部分交互 输入数据流：处理信息，读取修改 输出数据流： 读取修改， 处理信息 加工逻辑：判断用户要读取/修改的内容->反馈用户所需信息 6.加工名：技术管理 简要描述：对技术统计数据库进行相应要求的操作，并与判断部分交互信息 输入数据流：处理信息，读取修改 输出数据流： 读取修改， 处理信息 加工逻辑：判断用户要读取/修改的内容->反馈用户所需信息源点及汇点词条描述： 名称：用户 简要描述：既是源点又是汇点，发出动作信息给＂检验＂和＂判断＂加工，通过交互界面接受反馈信息有关数据流：登录结果，登录信息，输入修改信息，反馈信息 数目：一个4. 功能需求4.1 功能划分 可细分为四部分：人事管理，销售管理，财务管理，技术档案管理4.2 功能描述人事功能： （1）能对公司内部的所有人员有关档案详细资料记录并保存。
（2）能对数据库内人事档案的数据进行查阅和修改。
（3）能按部门或姓名检索人员。
（4）当某员工的雇用期限达到整年时，按时提醒。
销售统计功能 （1）按日对公司的销售情况进行统计，包括销售额\销售数量\各地区销售比例\不同销售方式的销售量比例以及销售毛利润情况 （2）制定销售情况的月报表\季报表以及年报表对销售情况进行分析，对不同销售人员的业绩进行评定财务管理功能 （1）协助财务人员进行计...
软件需求分类有哪些
软件需求的定义；IEEE软件工程标准词汇表（1997年）中定义需求为：(1)用户解决问题或达到目标所需的条件或权能（Capability）。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面（1）或（2）所描述的条件或权能的文档说明。
简单的就是：用户需求；用户需要在应用系统中实现什么东西，为实现这个目标，需要用户提供的全部的详细的业务说明，业务流程，表格样式等。
功能需求；将用户需求归类分解为计算机可以实现的子系统和功能模块，用设计语言描述和解释用户的需求，以达到可以指导程序设计的目的。
需求分析的详细分析
从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解需求分析指需求的分析、定义过程。
需求分析就是分析软件用户的需求是什么。
如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。
如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的（相信大家都有体会）。
比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。
当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。
需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。
在一个大型软件系统的开发中，他的作用要远远大于程序设计。
需求分析阶段的工作，可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。
问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。
这些需求包括：功能需求（做什么）、性能需求（要达到什么指标）、环境需求（如机型、操作系统等）、可靠性需求（不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求（软件运行是所需的内存、CPU等）、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。
分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。
最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型（做什么的模型）。
制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。
请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。
评审通过才可进行下一阶段的工作，否则重新进行需求分析。
需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。
原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。
原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。
但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。
建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。
如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。
以后的目标系统就在原型系统的基础上开发。
原型主要有三种类型：探索型、实验型、进化型。
探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。
实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。
进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
在使用原型化方法时有两种不同的策略：废弃策略、追加策略。
废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改，形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。
系统构造完成后，原来的模型系统就被废弃不用。
探索型和实验型属于这种策略。
追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。
进化型属于这种策略。
客户与开发人员交流需要好的方法。
下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。
如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1、 分析人员要使用符合客户语言习惯的表达需求讨论集中于业务需求和任务，因此要使用术语。
客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。
这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。
为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。
如果是切换新系统，那么开发和分析人员应使用一下旧系统，有利于他们明白系统是怎样工作的，其流程情况以及可供改进之处。
3、 分析人员必须编写软件需求报告分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。
通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之...
什么是软件需求,什么是功能需求？
软件开发生命周期包含需求、设计、编码和测试四个过程阶段，其中需求过程是第一个也是最重要的一个阶段。
软件需求包括三个不同的层次：业务需求，说明了提供给客户和产品开发商的新系统的利益，反映了组织机构或客户对系统、产品高层次的目标要求，它们将在项目视图与范围文档中予以说明；用户需求，描述了用户使用系统必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明；功能需求和非功能需求，定义了开发人员必须实现的软件功能，使得用户能顺利完成他们的任务，从而满足了业务需求。
软件需求过程包括了5个主要活动：需求获取、需求分析和确认、编写需求规格说明书、需求验证和需求管理。
需求获取 需求的收集、分析、细化、核实并组织的步骤，并将它编写成文档。
这个活动包括了编写项目视图和范围文档、用户群分类、选择用户代表、建立核心队伍、确定使用实例、召开联合会议、分析用户工作流程、确定质量属性、检查问题报告和需求重用10个具体任务，文章将在后面进行详细的阐述。
需求分析 根据需求获取中得到的需求文档，分析系统实现方案。
这个活动需要完成下面几个任务： 1、绘制关联图，用于定义系统与系统外部实体间的边界和接口的简单模型； 2、创建开发原型，当开发人员或用户不能明确某些需求时，开发一个系统原型，这样使得许多概念和可能发生的事更为直观明了； 3、分析可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确每项需求实现相联系的风险，包括与其它需求的冲突，涉及各类用户的利益平衡，对外界因素的依赖和技术障碍； 4、确定需求优先级：分析方法来确定使用实例、系统特性或单项需求实现的优先级别，以优先级为基础确定产品版本将包括哪些特性或哪类需求； 5、为需求建立模型，为需求建立图形分析模型是软件需求规格说明极好的补充说明，可以为系统需求从多个角度建模； 6、编写数据字典，创建数据字典数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义； 7、应用质量功能调配，将系统特性、属性与对客户的重要性联系起来，提供了一种分析方法以明确哪些是客户最为关注的特性。
编写需求规格说明书 需求开发的最终成果是客户和开发小组对将要开发的产品达成一致协议，这一协议就是通过文档化的需求规格说明书来体现。
需求规格说明书包括项目视图和范围文档说明了系统的业务需求，而使用实例文档则说明了用户需求。
这个活动需要完成下面几个任务： 1、采用模版，在你的组织中要为编写软件需求规格说明书等文档定义一种标准模板，该模板为记录系统需求和各种其它与需求相关的重要信息提供了统一的结构； 2、指明需求来源，为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要能追溯每项需求的来源，来源可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源，这些来源应该记录在需求的跟踪能力矩阵中； 3、为每项需求注上标号，为了需求的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求，为制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号； 4、记录业务规范，是指关于系统的操作原则，比如谁能在什么情况下采取什么动作，将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档； 5、创建需求跟踪能力矩阵，建立一个矩阵把每项需求来源、定义与实现、测试它的设计和代码部分联系起来，这样有利于需求的管理和需求变更影响范围的评估。
手机很多软件要求 获取手机识别码和修改系统权限,应不应该允许？？...
规范化软件开发过程中的《需求说明书》的编写，使之成为整个开发工作的基础。
2 适用范围本规范适用于集团开发项目的（软件）《需求说明书》的编写。
3 编写内容提示1 引言3.1.1 背景说明说明被开发软件的名称，任务提出者，用户及实现该软件的计算机网络。
3.1.2 参考资料列出有关资料（名称，发表日期，出版单位，作者等）。
3.1.3 术语和缩写词列出本文件中用到的专门术语的定义，及术语缩写词。
3.2 软件总体概述3.2.1 目标软件开发的意图、应用目标、作用范围以及需说明背景材料。
3.2.2 系统模型图示说明该软件的所有功能及其相互关系和数据传递情况。
3.2.3 假设和约束说明影响软件开发、运行环境和系统能力（如预告出错类型的能力）的某些假设和约束。
3.3 详细需求详细描述此软件系统的功能需求和性能需求。
3.3.1 功能需求对系统中每一个功能，要详细描述（图示或文字）。
概述 叙述功能名称，目标和作用。
输入 输入该功能的信息。
处理 描述该功能做什么，如何对输入信息进行加工并转换成输出信息。
输出 列出内部生成的文件。
3.3.2 性能需求定量地描述此软件系统应满足的具体性能需求。
可考虑以下方面：3.3.2.1精度说明系统的精度要求，如：数据的精度要求。
数字计算的精度要求。
数据传送的误码率要求。
3.3.2.2 时间特性说明系统的时间特性要求，如：解题时间。
询问和更新数据文件的响应时间。
系统各项功能的顺序关系。
3.3.2.3 灵活性说明当需求发生某些变化时系统的适应能力，指出为适应这些变化而需要设计的软件成分和过程。
3.3.2.4系统容量包括系统的设计容量和理论（计算）容量。
3.3.3 输入和输出解释各输入输出数据类型，并逐项说明某媒体、格式、数值范围等。
对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3.3.4 数据管理能力说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作估算。
3.3.5 故障处理列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.4 环境描述所开发软件运行所需的环境。
3.4.1 设备环境描述运行软件系统所需的设备能力，如：处理器的型号和内存容量。
存储媒体的数量。
通信网络（包括说明网络结构，线路速度及通讯协议等）。
3.4.2 支持软件环境列出与待开发的软件互相配合的支持软件（包括名称，版本号和文件资料），必要时还应列出测试软件，还要指出该软件用的编程语言，编译程序，操作系统和数据管理系统。
3.4.3 接口说明本软件与其他软件之间的接口、数据通信协议等。
3.4.4其他说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。
-