分类目录归档:文档模板库

如何做好需求收集[来自《程序员》第2期]

项目前期需求收集过程的效果好坏,会对软件产品的最终质量产生直接的影响。如何收集好需求,本文作者给出了一条行之有效的实际操作途径。

什么是需求收集?

需求收集,是确定和理解不同类别用户的需要和限制的过程,是需要高度协作的活动,是在问题及其最终解决方案之间架设桥梁的第一步,因此其重要性不言而喻。据调查显示50%以上产品在市场上失败的原因,是由于忽视了用户需求。

需求收集在需求开发活动中的示意图如图1:


如图1

需求收集为什么会困难?

困扰项目组需求收集活动的原因可能如下:

v 需求收集人员往往只关注用户反映的表面问题,而不能主动深入挖掘用户的真实需求;

v 需求收集人员考虑的问题时习惯干“以产品为中心”,而不是“以客户为中心”;

v 用户往往不清楚自己的真实需求是什么,或者不知道如何准确地描述出自己的需求—“我心里很清楚,但就是说不出来”;

v 没有从所有可能的渠道去收集需求,需求信息来源不完整;

v 收集的需求没有规范记录下来,造成原始信息丢失或失真,且无法回溯;等等。

怎么做好需求收集活动?

首先,需要建立需求收集机制。其次,使用统一的需求收集系统。最后,在需求收集时,采取一定的技术和方法。

建立需求收集机制

(1). 明确每个需求收集活动参与者的岗位职责

根据项目组可能的需求来源(需求来源可能包括:市场调研,竞争对手信息分析,标准和协议等等,视项目组的实际情况而定),指定每个需求来源的收集负责人。同时,对通过各个渠道收集的需求信息,指定专门的接口人进行汇总和审核。

(2). 建立需求预处理流程

对收集到的需求,除了指定专门的接口人进行汇总和审核以外,还要建立相应的预处理流程,在对需求进行预处理时,相关的讨论,决策可以通过“需求CCB会议”完成(需求CCB是指:专门用于需求讨论和决策的Change Control Board)。

一个对收集到的需求信息的预处理流程例子如图2:

如图2

项目组可以参考上例,结合自身实际情况进行适当剪裁,建立适合自己的预处理流程。

(3). 周期性的重复需求收集活动

当产品处于研发过程中,或已经交付给用户使用后,项目组还需要定期从各个来源重新去收集和审视一下产品的所有相关需求,这样就可以及时获知市场和用户对产品的反应,为下一个步工作提供输入和依据。项目组可以依据自身产品的特定,指定周期性的需求收集策略,选择相应的时机。

使用统一的需求收集系统

很多项目组都采取表格的方式记录收集到的需求信息,而不是通过电子流程的方式提交,这样会到来一些问题,如:收集到的需求信息被延迟处理,项目信息无法跟踪,回溯,等等。因此,项目组有必要使用统一的需求收集系统,作为唯一,明确的入口,对需求信息进行填报和跟踪。

企业可以选择自己开发电子的需求收集系统,也可以选择购买市场上现有的产品,如:Telelogic公司的Focal Point等。如果使用自己开发的需求收集系统,就可以让系统流程和企业的业务流程相结合,而且日后维护和扩展也比较方便。

一个需求收集的二维流程图实例如图3:


如图3

在实际工作中,需求收集系统还可以和需求管理系统,变更控制系统等通过一定的接口实现集成,共同构成企业的综合需求管理平台,从而提供“完善的需求管理解决方案”。一个公司级综合需求管理平台搭建的实例如图4:

如图4

采取一定的需求收集技术和方法

在需求收集时,还应采取一定的技术和方法。一些常用的需求收集技术和方法包括:客户访谈,客户交流,市场调研,技术支持,高层拜访,竞争对手分析,查阅媒体信息,需求专题分析讨论会等等。

下面选取几种技术和方法,通过一些案例分析,进行更为详细地阐述。

(1). 客户访谈

案例分析1:某次客户访谈

ü 访谈时间:选择45-60分钟比较合适。

ü 访谈地点:选择比较宽松的非工作环境进行。

ü 访谈问卷:在访谈之前要事先设计访谈问卷,要注意的是问卷只是提供一个思路。

ü 填表方式:不要采取让客户直接填表的方式。

ü 录音:前提不要让客户发现或是事前征求客户的同意。

ü 访谈结束:再次确认,每次访谈后要优化访谈的提纲以备下次使用。

(2). 客户交流

案例分析2

交流前的沟通:充分与客户沟通交流,重点可以以下角度考虑问题:

ü 本次客户关系什么内容?
参与人是谁?
主要决策者有哪些倾向性的观点?

ü 竞争对手可能方案的卖点?主推什么?

ü 我们要住推什么?怎么避免我们的弱点?

ü 客户预计会提那些问题?我们应该怎么回答?

ü 交流会的讲解重点:在交流会上,可以选择以下讲解重点:

ü 客户面临的问题是什么?

ü 针对客户面临的问题,我们的解决方案是什么?

ü 我们的总体方案如何?

ü 今天交流的内容在公司总体方向中的位置?

此外,在交流时还可以自己设计一些问题并加以回答。特别需要注意的是,在交流的时候不要攻击竞争对手,但是可以多讲一些自己的成功案例和优点。

交流后的工作:交流之后,还需要完成以下工作:

ü 分析记录和答疑;

ü 提出项目的应对策略建议;

ü 对交流会上遗留的问题进行跟踪直至关闭;

(3). 需求专题分析讨论会

需求专题分析讨论会的目的,是在较短的时间内鼓励与会者在需求上达成共识,尽快取得统一意见。需求专题分析讨论会通常邀请客户代表参加

案例分析3

会前准备

ü 确定所有相关的干系人,不要有遗落;

ü 事先做好会议后勤保障;

ü 事先准备会议相关材料,需求文档初稿,调查问卷,相关清单;

ü 找合适的主持人:善于控制时间,维持会议“规则”,制定会议目标和议程,能够调动所有人员积极参与。

会议举行:

ü 制定会议纪律并宣布;

ü 支持人要把握好会场气氛,并及时化解矛盾;

ü 记录人要做好会议记录

ü 参与人员使用投票方式确定需求优先级;

ü 发言人的发言时间不得超过一定长度,不能打断;

会后工作

ü 把会上收集到的意见归类;

ü 记录讨论后的需求;

ü 确定下一步工作;

结束语

需求收集在客户问题及最终解决反感之间起着架设桥梁的作用,从某种程度上来讲,需求收集工作的质量决定了产品的成败,因此我们必须加强对其的重视。为了做好这项工作我们需要建立日常的需求收集工作机制,并采用统一的需求收集系统作为信息入口;同时,由于需求收集是统一的讲求技术和方法的活动,选择和的技术和方法有助于获取完整且有效的需求。

软件需求分析文档

软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化,分析各种可能的解法,并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步,是确定系统必须完成哪些工作,也就是对目标系统提出完整、准确、清晰、具体的要求。

软件需求分析的任务是:深入描述软件的功能和性能,确定软件设计的约束和软件同其他系统元素的接口细节,定义软件的其他有效性需求,借助于当前系统的逻辑模型导出目标系统逻辑模型,解决目标系统“做什么”的问题。

需求分析可分为需求提出、需求描述及需求评审三个阶段。

需求提出主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。用户、开发人员和用户确定一个问题领域,并定义一个描述该问题的系统。这样的定义称作系统规格说明,并且它在用户和开发人员之间充当合同。

在问题分析阶段分析人员的主要任务是:对用户的需求进行鉴别、综合和建模,清除用户需求的模糊性、歧义性和不一致性,分析系统的数据要求,为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来,以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求,哪些是用户尚未提出但具有真正价值的潜在需求。

在需求评审阶段,分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核,以确保软件需求的完整、准确、清晰、具体,并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点,必须尽快更正,再行检查。

软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解, 使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下:

  1 引言

1.1编写目的

说明编写这份软件需求说明书的目的,指出预期的读者。

1.2背景

说明:

a.待开发的软件系统的名称;

b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;

C.该软件系统同其他系统或其他机构的基本的相互来往关系。

1.3定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.4参考资料

列出用得着的参考资料,如:

a.本项目的经核准的计划任务书或合同、上级机关的批文;

b.属于本项目的其他已发表的文件;

c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。

  2 任务概述

2.1目标

叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|

2.2用户的特点

列出本软件的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长,以及本软件的预期使甩频度。这些是软件设计工作的重要约束

2.3假定和约束

列出进行本软件开发工作的假定和约束,例如经费限制、开发期限等。

  3 需求规定

3.1对功能的规定

用列表的方式(例如IPO表即输入、处理、输出表的形式),逐项定量和定性地叙述对软件所提出的功能要求,说明输入什么量、经怎样的处理、得到什么输出,说明软件应支持的终端数和应支持的并行操作的用户数。

3.2对性能的规定

3.2.1精度

说明对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。

3.2.2时间特性要求

说明对于该软件的时间特性要求,如对:

a.响应时间;

b.更新处理时间;

c.数据的转换和传送时间;

d.解题时间; 等的要求。

3.2.3灵活性

说明对该软件的灵活性的要求,即当需求发生某些变化时,该软件对这些变化的适应能力,如:

a.操作方式上的变化;

b.运行环境的变化;

c.同其他软件的接口的变化;

d.精度和有效时限的变化;

e.计划的变化或改进。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

3.3输人输出要求

解释各输入输出数据类型,并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。

3.4数据管理能力要求

说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作出估算。

3.5故障处理要求

列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

3.6其他专门要求

如用户单位对安全保密的要求,对使用方便的要求,对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。

  4 运行环境规定

4.1设备

列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能,包括:

a.处理器型号及内存容量;

b.外存容量、联机或脱机、媒体及其存储格式,设备的型号及数量;

c.输入及输出设备的型号和数量,联机或脱机;

d.数据通信设备的型号和数量;

e.功能键及其他专用硬件

4.2支持软件

列出支持软件,包括要用到的操作系统、编译(或汇编)程序、测试支持软件等。

4.3 接口

说明该软件同其他软件之间的接口、数据通信协议等。

4.4控制

说明控制该软件的运行的方法和控制信号,并说明这些控制信号的来源。

 

讨论一下怎么写需求文档

作者:iFire

先谈谈我的想法。

一、要讨论怎么写需求文档,首先就的搞清楚需求的构成,我是这么分的:
1、功能需求;
2、非功能需求或技术需求;

我一般把功能需求划分为几个部分:
a、业务过程;
b、业务规则;
c、业务数据;

非功能需求(技术需求)我就不多说了,大致就是可用性,可靠性,性能,可支持性等等。

二、弄清楚需求的构成后,我们就得考虑以什么样的文档结构来描述这些需求了,UP的做法是这样的:
1、用例规格说明描述业务过程;
2、业务规则文档描述业务规则;
3、术语表描述业务数据;
4、补充规格说明描述非功能需求(技术需求);

UP的做法还是很有道理的。这体现了两个原则:
1、分离关注点(每个文档描述相对独立的领域);
2、减少重复(很多用例都会引用相同的业务规则及业务数据);

这样便能够尽可能的使文档结构清晰,易阅读,易理解。也便于跟踪和维护。

但另一方面由于将不同的领域分离到不同文件的做法也使得可阅读性有所降低。比如用例规格说明中的业务过程描述时常需要引用业务规则文档中的业务规则及术语表中的业务数据。由于不是很方便在各个文档之间导航,你可能需要打开多个文档进行交叉阅读。这是比较麻烦的,特别是对于用户来说。

而且UP中每个用例都单独作为一个文件存在,这可能是为了便于跟踪及管理的缘故吧。但正如上所述,文件多了看着就觉得不爽了。我觉得完全可以将用例合并到一个文档中。或者几个相对独立的文档中(比如根据子系统划分)。

至于交叉阅读,导航困难的问题是否有什么别的方法解决呢?html文档似乎不错。不过写起来似乎没word方便啊。

三、总结:
无论怎么写需求文档,最终的目的无外乎易阅读,易理解,易沟通,易确认,易跟踪,易测试,易验收。我想我们都应该以这个为目标来进行思考。

如何编写优质的需求文档

作者: Job Vranish  来源: 伯乐在线  发布时间: 2012-03-21

英文原文:How to write good requirements

编写需求文档,在嵌入式开发领域是非常普遍的。需求文档被用来定义开发任务,协调大规模的研发计划。对于最终的产品,需求文档扮演着开发者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候,便可以发挥巨大的作用。然而,如果你在嵌入式开发领域工作的时间足够长,你就会很快发现,这个领域里不合格的需求文档实在是太多了。当你尝试对这些不合格的文档进行修复时,你又会很快发现,书写正确的需求文档绝非易事。在这里,我们提出一些建议,希望能将书写正确需求文档这件事情变得清晰一些。

从较高的层次来看,书写需求文档的目的就是要提供对所需行为的有效描述。该所需行为可用一个黑盒系统描述,并需要注意以下细节:

  • 工程师可以根据系统所说进行实现
  • 测试人员,在不与开发人员沟通的前提下,可以利用满足硬件要求的设备验证需求。
  • 最终产生的成果满足终端用户的要求。
  • 黑盒测试

书写优质的需求文档:

最基本的原则是:需求文档应当尽量简洁,用最易懂的描述来约束系统的预期行为。如果你遵循这个原则,剩下的那些重要因素(可测试性、避免过度设计等等)都将变得顺理成章。

列举一下更详细的规则,通常会更有帮助。下面是书写优质需求文档需要遵循的步骤:

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端输出

这样就好多了(尽管还不完美)。这些需求通俗易懂,不涉及到系统内部实现,且易于测试。对于系统行为的限定也仅仅限于需要做什么,点到为止。(例如,对弯曲传感器的采样频率,在实现上也可以更高,只要不产生非预期行为,一切都可以)。

编写需求就仿佛是在大脑中构建软件的过程。因此要重于实作。

编译:伯乐在线 – 黄小非

一个标准的软件开发流程步骤及文档

一个标准的软件开发流程需要有哪些步骤,写哪些文档?
1、先是需求调研,出《需求文档》;
2、 然后概要设计,出《概要设计文档》;
3、然后详细设计,出《详细设计文档》;
4、然后就是编码,出软件代码,最好能出单元测试文档;
5、然后就是联调,可能有多个部分,需要联合测试;
6、最后就是软件交付了,交付软件、代码、使用说明书

软件开发流程(Software development process)即软件设计思路和方法的一般过程,包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。

第一步:需求调研分析

1相关系统分析员向用户初步了解需求,然后用WORD列出要开发的系统的大功能模块,每个大功能模块有哪些小功能模块,对于有些需求比较明确相关的界面时,在这一步里面可以初步定义好少量的界面。

2 系统分析员深入了解和分析需求,根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚例用系统大致的大功能模块,大功能模块有哪些小功能模块,并且还列出相关的界面和界面功能。

3 系统分析员向用户再次确认需求。

第二步:概要设计

首先,开发者需要对软件系统进行概要设计,即系统设计。概要设计需要对软件系统的设计 进行考虑,包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、 运行设计、数据结构设计和出错处理设计等,为软件的详细设计提供基础。

第三步:详细设计

在概要设计的基础上,开发者需要进行软件系统的详细设计。在详细设计中,描述实 现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系,需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑,以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细,能够根据详细设计报告进行编码。

第四步:编码

在软件编码阶段,开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求,开始具体的编写程序工作,分别实现各模块的功能,从而实现对目标系统的功能、性能、接口、界面等方面的要求。

第五步:测试

测试编写好的系统。交给用户使用,用户使用后一个一个的确认每个功能。

第六步:软件交付准备

在软件测试证明软件达到要求后,软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。

《用户安装手册》应详细介绍安装软件对运行环境的要求、安装软件的定义和内容、在客户端、服务器端及中间件的具体安装步骤、安装后的系统配置。

《用户使用指南》应包括软件各项功能的使用流程、操作步骤、相应业务介绍、特殊提示和注意事项等方面的内容,在需要时还应举例说明。

第七步:验收

用户验收。

软件维护

1、软件数据库管理 [1] 2、用户跟踪培训

3、故障分析解决

软件升级

需求调整分析

软件功能拓展

优化系统

报废处理

软件不能适应业务发展

新软件项目立项

企业数据信息备份

举例解析

1 例如某家公司想找人订做一套人事管理软件,从某种渠道上得知某家软件开发公司提供这种服务,所以进行联系。

2 软件开发公司会派专门的软件工程师到他们那里去了解我们要设计一个什么的东西给用户用,然后回来做个方案给他们,其中方案的内容包括:开发出来的软件大概的界面是怎样?方便什么人使用?什么人可以使用什么功能?方便到什么程度?大概的硬件要求是怎样等?

3 用户看了方案后,确定他们就是要做一套这样的软件,开发方就开始开发这套软件。

4 开发方把开发出来的软件交给用户使用,其中在使用的过程中哪里使用不方便或哪里达不到要求,开发方会第一时间修改这些功能,直到用户要求的所有功能都能很完美的解决掉。

5 用户如果因为公司发展壮大的需要,需要将软件升级开发方会做功能拓展。

参考资料
软件开发流程

http://edu.newer.com.cn/images/shixun_02.gif

本文参考:http://apps.hi.baidu.com/share/detail/19058495

概要设计的格式模板及相关内容说明

  概要设计的主要任务是把需求分析得到的DFD转换为软件结构和数据结构。

  设计软件结构的具体任务是:将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。

  数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。显然,概要设计建立的是目标系统的逻辑模型,与计算机无关。

简述

  概要设计有多种方法。在早期有模块化方法、功能分解方法;在60年代后期提出了面向数据流和面向数据结构的设计方法;近年来又提出面向对象的设计方法等。

概要设计的格式

 

概要设计的格式如下:

1引言 2

1.1编写目的 2

1.2背景 2

1.3定义 2

1.4参考资料 2

2总体设计 2

2.1需求规定 2

2.2运行环境 2

2.3基本设计概念和处理流程 3

2.4结构 3

2.5功能需求与程序的关系 3

2.6人工处理过程 3

2.7尚未问决的问题 3

3接口设计 3

3.1用户接口 3

3.2外部接口 3

3.3内部接口 4

4运行设计 4

4.1运行模块组合 4

4.2运行控制 4

4.3运行时间 4

5系统数据结构设计 4

5.1逻辑结构设计要点 4

5.2物理结构设计要点 4

5.3数据结构与程序的关系 4

6系统出错处理设计 5

6.1出错信息 5

6.2补救措施 5

6.3系统维护设计 5

概要设计说明书

1引言

1.1编写目的

说明编写这份概要设计说明书的目的,指出预期的读者。

1.2背景

说明:

a. 待开发软件系统的名称;

b. 列出此项目的任务提出者、开发者、用户以及将运行该软件的计算站(中心)。

1.3定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.4参考资料

列出有关的参考文件,如:

a. 本项目的经核准的计划任务书或合同,上级机关的批文;

b. 属于本项目的其他已发表文件;

c. 本文件中各处引用的文件、资料,包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。

2.1需求规定

说明对本系统的主要的输入输出项目、处理的功能性能要求,详细的说明可参见附录C。

2.2运行环境

简要地说明对本系统的运行环境(包括硬件环境和支持环境)的规定。

2.3基本设计概念和处理流程

说明本系统的基本设计概念和处理流程,尽量使用图表的形式。

2.4结构

用一览表及框图的形式说明本系统的系统元素(各层模块、子程序、公用程序等)的划分,扼要说明每个系统元素的标识符和功能,分层次地给出各元素之间的控制与被控制关系.

2.5功能需求与程序的关系

本条用一张如下的矩阵图说明各项功能需求的实现同各块程序的分配关系:

程序1 程序2 …… 程序n
功能需求1
功能需求2
……
功能需求n

2.6人工处理过程

说明在本软件系统的工作过程中不得不包含的人工处理过程(如果有的话)。

2.7尚未解决的问题

说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。

3.1用户接口

说明将向用户提供的命令和它们的语法结构,以及软件的回答信息。

3.2外部接口

说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。

3.3内部接口

说明本系统之内的各个系统元素之间的接口的安排。

4运行设计

运行设计

4.1运行模块组合

说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合,说明每种运行所历经的内部模块和支持软件。

4.2运行控制

说明每一种外界的运行控制的方式方法和操作步骤。

4.3运行时间

说明每种运行模块组合将占用各种资源的时间。

编辑本段5.1逻辑结构设计要点

给出本系统内所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。

5.2物理结构设计要点

给出本系统内所使用的每个数据结构中的每个数据项的存储要求,访问方法、存取单位、存取的物理关系(索引、设备、存储区域)、设计考虑和保密条件。

5.3数据结构与程序的关系

说明各个数据结构与访问这些数据结构的形式:

6.1出错信息

用一览表的方式说明每种可能的出错或故障情况出现时,系统输出信息的形式、含义及处理方法。

6.2补救措施

说明故障出现后可能采取的变通措施,包括:

a. 后备技术说明准备采用的后备技术,当原始系统数据万一丢失时启用的副本的建立和启动的技术,例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术;

b. 降效技术说明准备采用的后备技术,使用另一个效率稍低的系统或方法来求得所需结果的某些部分,例如一个自动系统的降效技术可以是手工操作和数据的人工记录;

c. 恢复及再启动技术说明将使用的恢复再启动技术,使软件从故障点恢复执行或使软件从头开始重新运行的方法。

6.3系统维护设计

说明为了系统维护的方便而在程序内部设计中作出的安排,包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。 各个程序之间的对应关系,可采用如下的矩阵图的形式;