如何写软件项目需求说明书

如何写软件项目需求说明书（精选6篇）

如何写软件项目需求说明书 篇1

进入软件开发行业也有一段时间了，大大小小项目也接触了一些，对于怎么写好项目需求文档做一下总结，发表一下自己的看法。1 获取需求：

作为需求方也就是甲方，通过语言描述或文档的方式将需求（系统需要提供的功能）提交给开发人员（需求分析人员）。

获得需求的方式可以有多种多样：电话询问、现场考察、聆听用户讲解、阅读用户编制的相关文件(如招标书)，其实这些方法都是GET方式，我们可以通过以下两类技术手段来达到：GET(获取)和PUSH(引导、反馈、激发)相互结合的方式来得到我们真正的需求，而这两个过程都是必须交互进行的，一般我们可以筛选一名非常有经验(包括谈判技巧、深厚的业务和技术背景、人缘很好、勤奋努力)的人士担任需求工程师，长期在客户那里工作。2 需求分析人员

（1）根据客户提供的文档或语言描述，将需求按功能划分，以用例图的方式表达系统提供的功能模块及功能模块之间的关系，完成用例图后与客户确认大的功能模块，并对每个功能模块做进一步的沟通详细记录用户所提供的关键性的描述，此过程需要系统分析人员对客户进行引导。

（2）对每个功能模块进行详细分析与描述，具体信息包括：用户角色、功能说描述、IPO的方式进行描述（即输入项、输出项、处理）、要提供必要的功能说明，如果使文档更加直观，更容易让客户理解，可以用UI的方式表达输入输出，配合必要的描述，这样对于客户更加容易理解，需要与客户进行大量的沟通确认。

（3）编写数据字典：在需求阶段，很难使团队的思路一致，建立一个合适的机制是完全必要的，这就是数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

（4）关于文档具体表述的格式与形式，要根据所要表达的功能来确定，最重要的是把事情描述清楚,这事最终的目的；

软件项目的需求变更管理 篇2

需求管理的常见误区

软件项目的范围控制应该是在需求分析阶段就开始的，然而很多项目经理针对需求分析存在不少认识误区。

误区1：开发商和用户仅就软件需求的基本轮廓达成一致即可，具体细节准备日后协商。

从项目管理角度分析，这是非常危险的，许多软件项目失败的最主要原因就是需求分析阶段对问题、流程、细节的描述不够准确，导致后期预算超支或者工期延误。

正确的方法是：在需求分析阶段，双方必须对项目的应用背景、功能需求、性能需求、可靠性需求、可用性需求、操作界面需求、外部接口需求，以及项目评审的方法、标准、过程进行全面、细致地研究讨论，逐一进行明确。

误区2：软件需求是软件必需向用户提供的功能和界面，功能上满足需求就足够了。

从软件需求工程角度分析，这只是认识到了软件系统的功能需求，忽略了软件的非功能需求和设计约束，需求捕获不够全面。软件需求工程理论认为，软件需求包括功能需求、非功能需求和设计约束三方面内容。

正确的方法是：除了要明确软件的功能需求，还需要进一步明确非功能需求（即软件产品所必备的属性和品质，包括可靠性、可用性、安全性、可扩展性、可移植性等）和设计约束（即软件研发必须遵守的特定规约、限制条件、政策标准,如软件必须采用国内自主知识产权的数据库产品）。

误区3：需求调研的对象是用户，用户就是软件产品的最终使用人员。

从项目管理角度分析，该观点缺乏对项目相关人全面、系统的认识，对用户的概念理解不到位。“用户”是一种泛称，它可细分为客户、最终用户和间接用户三种类型。例如，很多企业的一把手并不直接参与软件的采购和操作，但是其对于软件项目实际上起到了关键意义的决定作用，属于最重要的间接用户。

正确的方法是：要充分认识用户的多重性、层次性、复杂性，在进行需求调研时应首先对用户进行分析、分类，根据重要性、优先级、特殊性对各类用户进行排序；其次，是针对不同类别的用户分别制订不同的需求调研计划，全面开展需求调研。需要重点指出的是，对于由多个业务部门共同参与的软件项目，在确认软件需求时一定要得到全部参与部门的共同认可。

误区4：按照“需求、设计、编程、测试”步骤研发出的软件不必考虑需求跟踪问题。

从软件工程角度分析，这是对于需求变更过程缺乏系统的认识的表现，严格线性顺序的开发模型并不能保证各个开发阶段的工作成果与需求保持一致。实际上，由于需求变更的不可预见性和必然性，各个阶段往往以螺旋的方式渐进。

正确的方法是：需求跟踪应该贯穿于整个软件需求管理阶段，需求跟踪的目标是实现《产品需求规格说明书》和软件产品之间的双向可追溯。

做好需求工程

需求分析是软件工程项目最重要、最基础的起始阶段，为后续的规划设计阶段提供参照依据。在软件研发项目过程中一定要树立需求工程的意识，将需求视为一项系统工程。为了能够全面做好需求管理，应根据项目实际情况严格划分项目阶段，清晰界定、定义项目阶段的基线，在每个项目阶段制订、执行阶段性需求管理计划，逐一认真落实。

1．需求工程的结构及目标任务

需求工程是一个包括创建和维护系统需求文档所必需的一切活动的过程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程结构如图1所示，需求开发与需求管理的流程如图2所示。

需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求开发过程有3个主要活动：需求调查、需求分析、需求定义。需求开发过程可分为两个阶段：用户需求调查阶段和产品需求定义阶段，两个阶段在逻辑上通常是以迭代的形式进行的。需求开发过程产生的主要文档有《用户需求说明书》、《产品需求规格说明书》（对于软件产品而言就是《软件需求规格说明书》）。

需求管理的目的是在用户与开发商之间建立对需求的共同理解，维护需求与软件工作成果的一致性，并控制需求的变更。需求管理过程有三项主要活动：

（1）需求确认:开发商和用户共同对需求文档进行评审，双方就需求达成共识后做出书面承诺，使需求文档具有商业合同效果。

（2）需求跟踪:通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。

（3）需求变更控制:依据“变更申请、审批、实施、重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。

需求管理过程产生的主要文档有《需求评审报告》、《需求跟踪报告》、《需求变更控制报告》等。

2．需求的跟踪

需求跟踪的目的是建立与维护“需求、设计、编程、测试”过程的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式：

（1）正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。

（2）逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。

组建变更控制管理机构

项目变更是指项目实施过程中由于环境或者其他因素的变化而对项目部分或者全部功能、性能、架构、技术指标、集成方案、进度、质量等方面做出改变。

1．变更控制管理的任务及目标

信息系统项目实施过程中变更是无法避免的。变更控制管理的任务是：建立规范、严格、可行、高效的变更控制体系机制，组建变更控制管理机构，出台变更管理制度；对用户提交的变更请求进行快速的响应、受理；及时分析、研究、评估变更的可行性、成本、代价、范围；对于确定接受的变更请求制订变更实施计划方案及配套应对措施，实施变更任务，进行变更测试检查，做好变更记录。需求变更控制的最终目标是：通过建立严格规范的变更控制管理流程,拒绝不切合实际的变更，减少变更带来的风险，防止变更范围扩大、蔓延，杜绝随意的变更申请及受理过程等。

2．变更控制管理机构的建立

组建有效的变更控制管理机构和制订配套的变更控制管理制度，是进行变更控制管理的重要基础和前提保障，否则变更控制管理将成为一纸空文。变更控制管理机构（形式上可以是“变更控制管理委员会”、“变更控制管理办公室”、“变更控制管理组”等）是一个特殊组织，对项目负责人直接负责，它不受现存的职能组织结构的束缚,可由来自不同机构、不同部门、不同专业、不同岗位的人员组成，各成员划分权限岗位、明确职责、落实责任、协同工作。一般情况下，变更控制管理机构内部应至少配备以下四种角色的成员：

项目管理人员（类似于“项目经理”）：主要负责制订项目管理制度和项目管理计划，督促、检查、落实、考核项目执行过程，做好项目干系人之间的沟通协调工作。

技术负责人员（类似于“总工程师”）：主要负责项目中信息技术平台的分析、建模、设计、测试、实现。

业务管理人员（类似于“业务经理”）：主要负责收集整理业务需求、编写需求说明书、验证和评审需求、管理和控制需求变更。

通信联络人员：主要负责项目组织内部成员之间的信息发布。

需求变更控制 管理工作程序

需求变更的目的是希望软件产品更加符合用户的需求，但是变更涉及的人员多、范围广、影响大，在进行变更控制管理时必须建立严格、规范的变更控制管理工作程序，这样才能使项目始终按照预定的方向、模式、进度进行。

需求变更控制过程中最难办的事情不是“满足用户提出的变更请求”，而是“在用户认同支持、追加项目投资经费的前提下尽快完成变更任务”。用户往往认为提出变更需求是基本权利，而软件开发商往往认为只有义务解决在《用户需求说明书》、《产品需求规格说明书》中预先定义的各类需求，除此以外都应该拒绝或者在用户追加投资的前提下解决。

现实中信息系统项目的目标是具有一定弹性的，这一点尤其重要，用户和软件开发商之间为了达成共同目标不可能针锋相对，项目管理人员需要利用高超的管理艺术、沟通技巧、人格魅力，在对立博弈的关系之中寻求最佳的平衡点。

另外，有必要强调的是，在项目实施过程中，变更处理越早，难度越小，损失越小；变更处理越迟，难度越大，损失也越大。而且，任何变更都必须经过项目建设全部相关方（建设单位、承建单位和监理单位）多方确认后才能计划实施，严禁任何一方擅自变更。对项目变更的范围要有明确的界定，而且项目建设全部相关方对变更范围的理解上都没有任何异议。

软件需求规格说明书检查单 篇3

文档组织与完整性

1.所有对其它需求的内部交叉引用是否正确？

2.需求为设计提供了充足的基础么？

3.是否所有需求的书写详细程度都是一致的、合适的？

4.是否包括了每个需求的实现优先级？

5.是否定义了所有与外部硬件、软件和通讯的接口？

6.是否定义了功能性需求内在的算法？

7.软件规格说明书是否包含了所有已知的业务需求？

8.是否记录了所有可能的错误条件所产生的系统行为？

9.对所有内部和外部接口的描述，是否都符合模板的要求，即包括来源、目的、输入、输出和激发条件？

正确性

10.是否没有需求间的冲突或重复的需求？

11.是否每个需求都是无二义性的？

12.是否每个需求的描述都是简洁、清晰的？

13.是否每个需求都可以用测试或同级评审来进行验证？

14.是否每个需求都在项目的范围内？

15.是否每个需求都没有内容或语法上的错误？

16.是否需求中必需的信息都没有遗漏？如果有的话，是否标记为“待决定”了？

17.在已知的约束条件下，是否可以实现所有的需求？

18.是否任一个特定的错误信息都具有唯一性和明确的意义？

质量属性

19.对所有性能目标都作了适当的说明么？

20.对所有安全和防护性的考虑作了适当的说明么？

21.对其它相关的质量属性目标是否明确地文档化和量化，且进行了可接受的权衡也被详细说明了？

可追溯性

22.每个需求的标识都是唯一和正确的么？

23.每个软件功能需求都可追溯到客户需求么？

特殊问题

24.是否所有需求都是名副其实的需求，而不是设计或实现方案？

办公信息系统项目研发需求说明书 篇4

办公信息系统项目

信息管理与办公系统

研发需求说明书

二O一六年三月

信息管理与办公系统研发需求说明书

信息管理与办公系统研发需求说明书

1.3.1.易用性

对于信息办公系统，要求工作人员可以通过鼠标选择、拖拉等操作就能够完成大部分任务，系统使用不需要复杂的培训，即可使每个用户方便、灵活地使用，做到真正的办公自动化。

1.3.2.稳定性

保证系统的不间断运行和出现错误时能够及时恢复并没有数据丢失、系统崩溃等现象出现，避免因停电、操作失误、机器硬件错误等造成的数据丢失或系统崩溃现象。

1.3.3.安全保密性

贵单位信息办公系统是涉及重要的信息，因此，安全保密性是对新信息系统的最起码要求。

1.3.4.先进性与发展性

对于系统，最好采用当前最先进的Internet/Intranet技术，也充分考虑系统的可伸缩性、可扩展性和可继承性，让系统能够随所选择的平台不断升级而得到进一步的继承和发展。

1.3.5.标准化和开放性

对于系统公文资料参考国家公文标准和用户系统内公文标准进行设计。开放性是指系统提供给本单位内部其他系统和外部其他相关单位对信息办公系统的访问。当然，这些访问是有条件的，同时也有相当的安全和权限设置。

信息管理与办公系统研发需求说明书

‘用户名’和登录‘密码’是否正确，如果输入正确，将进入系统的主界面（个人桌面）。

2.系统管理

组织机构、人员、职位是基本信息组成部分，在各个机构下设置相应的职位，每个职位可以具有不同的操作权限，通过建立人员与相应职位的对应关系，实现对人员操作权限的统一管理。

3.公文流转

公文流转以用于处理日常工作中的单位内外部的各种公文，利用计算机网络的高速迅捷和计算机控制的严格准确性实现公文的处理。公文管理模块相对传统公文处理而言，在很大程度上提高了公文处理效率和准确性，用户操作简便易行。公文流转包括了公文的发文拟制、发文签发、发文传阅、收文签收登记、公文查询等。

4.收文登记

收文登记用于外部来文的签收、登记处理，包括：新增公文、录入、编辑公文信息。

综合查询系统

综合查询系统是整个信息管理与信息办公系统中的核心系统。在此系统中，系统可以根据各种需求和查询条件。

系统维护系统

系统维护系统主要负责数据备份、系统参数设置、用户角色管理等辅助功能。系统维护系统为数据库管理员和用户权限管理员两种角色服务。

 数据备份管理包括：数据定期备份、备份数据恢复、备份历史记录查询、历史备份数据删除等功能，其中数据备份包括对数据库中数据定期系统备份和人工不定期备份，同时包括对报表文件的备份处理等； 

用户角色管理：管理用户信息，设定角色名称，及权限等功能；

如何写软件项目需求说明书 篇5

集团客户部 2011年5月 说明：

鉴于云计算在技术层面的突破、OA办公自动化市场的火爆走势，某省移动公司基于做客户增值服务提供商的战略，特对OA办公自动化市场进行了全面的调研，并联合在集团化应用上处于领军地位的九思软件、IBM、浪潮软件等厂商，进行了充分的研讨，特针对集团企业在云计算和SAAS应用中的OA需求，拟制本项目需求说明书，并鼓励上述厂商参与方案设计和技术架构。

目 录

一、项目实施的目的和意义...............................5

二、项目建设规模和建设原则..............................7 2.1、建设规模和服务能力................................7 2.2、建设原则..........................................7

三、目标客户与商务模式................................10 3.1、主要目标客户.....................................10 3.2、商务模式.........................................10

四、硬件系统要求......................................12

五、软件系统架构要求..................................13

六、软件功能规划......................................16 6.1、总体要求.........................................16 6.2、前台标准功能模块.................................18

6.2.1.统一登录门户........................................................................18 6.2.2.异地远程办公........................................................................18 6.2.3.公文流转...............................................................................19 6.2.4.公文管理...............................................................................19 6.2.5.公告发布...............................................................................20 6.2.6.企业邮箱...............................................................................20 6.2.7.公文电子印章认证.................................................................20 6.2.8.短信功能...............................................................................21 6.2.9.系统管理...............................................................................21 6.2.10.事务管理...............................................................................23 6.2.11.日程、通讯录管理.................................................................24 6.2.12.工作绩效...............................................................................24 6.2.13.组织文化...............................................................................24 6.2.14.个人工作台............................................................................24 6.2.15.移动OA..................................................................................25

6.3、后台主要功能模块.................................25 6.3.1.后台登录门户.....................................................................25 6.3.2.集团客户注册.....................................................................25 6.3.3.运营状况分析.....................................................................26 6.3.4.运营维护管理.....................................................................26 6.3.5.权限管理.............................................................................26 6.3.6.日志管理.............................................................................27

七、对售后服务的要求..................................28

一、项目实施的目的和意义

党的十七届五中全会通过的“十二五”时期的规划建议，对未来我国信息化发展的战略目标、产业、应用以及电子政务、电子商务等都提出了明确的要求。其核心理念，就是要全面推进国家信息化。其中在谈到电子政务发展时，明确指出电子政务要以信息共享、互联互通为重点，同时大力推进国家电子政务网络建设，整合提升政府公共服务和管理能力。而对于电子政务，其最基本的核心则是办公自动化系统（即：OA系统）。

据不完全统计，自09年以来，全省就有10多个政府部门和企业采购我公司集成的OA系统解决方案，有上百个企业使用我公司的移动OA产品。这些集团客户之所以选择谋生移动公司提供的OA系统，一方面是看中了我公司的网络优势、安全优势和大型国有企业特殊的信誉保证；另一方面是受我省经济发展条件的制约，很多地方政府、大中型企业的信息化程度不太高，通常没有专业的网络信息部门支撑起OA系统的建设、使用和管理，因此需要外购OA系统服务。

为了更好满足集团客户对OA系统的市场需求，充分发挥移动通信优势，积极拓展移动信息化应用，有效提高集团客户信息化应用和管理水平，丰富集团信息化产品体系，结合MAS/ADC两类应用的特点，拟按照“软件即服务(SaaS)”的模式开展某省移动公司统一OA运营管理平台(简称“OA平台”)的建设，通过OA平台、移动专线网络、TD/GSM无线网络相结合的方式，满足企业日常和移动办公的应用需求。

二、项目建设规模和建设原则

2.1、建设规模和服务能力

OA平台项目计划是在某省移动公司现有云计算平台上建设，初步项目设计是项目第一期到2011年底，满足对50家重要集团客户、10000个企业员工账号接入使用（平均一家重要集团客户按照200人计算）。

同时OA平台应当能够支持后续的平滑扩容，在尽量不增加软件模块数量的前提下，通过增加云计算平台资源分配，提高OA平台的业务服务能力，应达到对500～1000家重要集团客户的服务能力。

2.2、建设原则

OA平台的系统建设坚持着眼全局、统筹考虑、整体规划、立足现实、逐步整合的原则。具体为以下设计原则：

A、整体性

在系统的规划上坚持整体规划、重点突出的原则，在对系统做统一的设计的基础上，按照轻重缓急依次实现，同时又兼顾不同部分之间一致性和可协调性。B、标准化

系统的总体设计充分参照国际上的规范、标准，遵守ISO标准设计，严格遵循中国移动制定的各种接入协议和管理规范，支持国内外目前所流行的主流网络体系结构和网络运行系统，采用国际上成熟的模式。C、高可靠性

系统设计将在尽可能减少投资的情况下，从系统结构、网络结构、技术措施、设备选型等方面综合考虑，以确保系统稳定可用，实现7×24小时的不间断服务。

系统应具备电信级的网管、告警、巡检机制，充分确保对潜在问题的预防和自我诊断。应该能够提供多种稽核手段，保证系统数据的准确性。D、先进性

为了保证开发出来的系统能够在较长的一段时间之内仍能够在技术层次上不落伍，确保技术的先进性和实用性，就要求本系统的开发和设计在技术上足够先进，使系统具有良好的可扩展性和灵活性，以适应信息化的迅猛发展趋势，满足当前及未来应用的需求。E、易维护性

为了确保整个系统所有人员均能够熟练地、快速地操作本系统，要求系统设计的首要原则是在功能设计、软件操作以及其他方面设身处地为用户着想，即以用户为中心。此外系统应为各级别的系统管理员提供完善的系统管理权限与工具，用于安全方便的日常管理和系统维护。F、安全性

本系统由于针对各级地方政府、大中型企业的应用，对于信息系统的安全性有着比较高的要求，安全性原则的目的是保障系统的可靠性、隔离性、以及数据库和数字地图的绝对安全。这就使得确保本系统的信息安全性成为十分关键的环节。系统要求提供云平台级、系统级、应用级等不同层次的、灵活的安全措施。采取操作权限控制、密码控制、数据加密、系统日志监督等多种手段确保系统安全，尤其是确保核心网络的安全。G、可扩展性

考虑到OA平台一方面是需要和其他信息系统的连接，系统应具有良好的外接接口，将来随着业务的不断扩充，整个系统中应能够方便地添加新的业务模块；另一方面是随着用户的增长，对于OA平台软硬件系统的业务承载能力也需要具备平滑的可持续扩充性；同时系统的建设是分期进行的，数据积累、用户需求、功能完善以及技术进步都要求系统必须具有扩展的余地。因此整个OA平台具备可扩展性是其最核心的要求之一。

三、目标客户与商务模式

3.1、主要目标客户

OA平台项目的主要目标客户是省内各级地方政府、行政分支机构、大中型企业等此类对OA系统功能要求较高，并且功能有一定共性的需求，同时对安全性、稳定性要求较高的集团客户。

而对于中小型企业的OA需求，主要是考虑通过目前已有的ADC OA产品予以满足。

3.2、商务模式

A、集团客户

某省移动公司向用户提供基础硬件、网络和系统维护服务，集团客户只需要具备日常上网的条件即可，具体可采用移动互联网专线或数据专线的方式实现。

具体的收费模式可以有如下几种： 依据不同用户数量等级，收取月租费的方式；（适用于用户数量较大，稳定的用户）依据实际使用的账户数量，依据每个账户月资费收费；（适用于用户数量较大，但用户数变动较大的情况）收取业务月基本费，加上具体使用账户数量的月资费；（适用于初期用户数量相对较少，后期持续增长的情况）

B、OA软件提供商

对于OA平台，目前的规划当中是使用某省移动公司现有的云计算平台，不再采购基础的硬件、网络设备。因此OA软件提供商主要是负责按照某省移动公司确认的需求提供方案、开发软件、培训用户并向某省移动公司提供维护服务。

具体的商务模式可以有如下两种： 软件提供商可以直接向某省移动公司收取一次性软件开发费用和一段时期的维护费用，不参与运营的业务分成；（无需SI资质）软件提供商可以不收取软件开发费用和维护费用，采取与某省移动公司进行业务分成的方式，按比例分享客户所支付的月租费用。（需要具备SI资质）

四、硬件系统要求

由于OA平台部署在某省移动公司核心机房的云计算平台上，因此在本项目中无需考虑包括服务器、网络设备在内的硬件设备投资，但是需要软件提供商根据OA平台所支持的集团客户书、用户数、功能模块数量、具体业务的使用情况等参数，提供所需的服务器处理能力（TPMC）测算模型，以保证有效的使用云计算平台的资源。

同时要提供OA平台所需的存储能力需求和系统备份配置需求，要求依据不同的建设目标提供测算模型，并提出相应的需求和建设方案，尤其是数据备份上需要提供硬件级别的异地容灾备份方案。

五、软件系统架构要求

集团客户通过专线、公网VPN、移动网络等方式接入部署在云计算平台上的OA平台，完成对集团用户的认证鉴权、企业账户管理、OA应用、短信收发、数据采集统计等功能。

对于OA平台而言，整个系统所需要承载的集团客户数量和规模均是不确定的，其相互关系也较难确定，所以整个平台并不能完全实现统一规划，一次施工。因此对于OA平台软件的系统架构设计要求很高，必须具备足够的灵活性和可扩展性，才可能满足大规模运营服务的需求。

具体要求如下： 系统需采用B/S模式的多层架构体系，客户端支持主流的操作系统和浏览器，对客户端的硬件配置和网络带宽要求尽量降低。系统需具备移动OA的功能，用户在手机端能够完成OA平台的主要业务功能（公文流转、邮件收发、集团通信录等），同时手机客户端要支持主流的手机品牌、型号和操作系统，并且要针对移动数据网络进行优化，尽量减少业务数据流量。系统功能和结构需采用关联性较小的模块化设计和良好的可扩展性。由于对客户数量和个性化需求的不确定性，要求OA平台具有良好的可扩展性，能通过云计算平台资源的扩容来满足不同规模的并发访问和数据容量，能通过软件业务模块的开发来满足用户的共性与个性需求。OA平台需要具备开放式的接口协议和一定的接口协议开发能力，以实现与集团客户的其他信息化系统进行数据交换和共享。OA平台还需要具备与某省移动公司内部系统连接的各项业务支撑、平台通信的接口。实现在BOSS完成业务订购、开通、取消等操作、集团客户SMS功能接入、内部系统平台数据同步等功能。对不同的客户，系统应尽可能的支持各种基础设施和组件的共用共享（例如：统一的数据库、统一的功能模块组件、统一的安全控制组件、统一的流程引擎组件等等）。但不同客户之间逻辑上独立，使用中彼此不能感觉到其他单位的存在，需要实现对不同集团客户具备不同的定制化门户接入，并且对于某些特殊重要的集团客户要能满足其部分的定制化开发需求。虽然不同客户在平台上的相互隔离独立，但是系统需要实现不同客户之间跨单位、跨公司之间的公文往来、业务流转等，在某些特殊情况下还需要能支持不同客户之间的数据共享、系统融合/拆分等。由于主要面对的都是政企大客户，其对于业务数据安全性、保密性有着极高的要求，所以系统需要充分的考虑到系统和数据的安全性。要求具备完善的数据容灾备份方案和能力，软件提供商最好能在具备国家保密局颁发的《涉及国家秘密的计算机信息系统集成资质》的基础上，实现对OA平台业务数据的加密保护，保证在OA平台系统后台也不能够直接查看到集团客户的公文、附件等私密资料。

六、软件功能规划

6.1、总体要求

对软件功能的总体要求如下：

对公文权威性、合法性的要求

需采用经政府权威部门认证，符合《中华人民共和国电子签名法》等相关法规，可用于政府非涉密办公系统的电子印章、数字签名和数据加密产品。

对数据安全性、保密性的要求

软件提供商在能具备国家保密局颁发的《涉及国家秘密的计算机信息系统集成资质》的基础上，实现对OA平台业务数据的加密保护，保证在OA平台系统后台也不能够直接查看到集团客户的公文、附件等私密资料。

快速实施的要求

在客户提出业务申请后，应该在最短的时间内完成需求调研、定制模块开发、流程梳理、数据整理、培训和开通等实施工作。具体要求是在满足客户正常合理的个性化需求的同时，针对标准功能（指OA平台已具备的通用功能模块或可直接使用的个性化功能模块），保证能同时实施2个项目，并且单个项目的实施时间不超过50个工作日。

手机OA实现的要求（可选）

需要支持通过手机客户端方式访问OA平台进行业务操作，要求是OA平台系统原生的手机OA系统，能够在手机端实现绝大多数的核心功能，不得采用中间件访问代理的方式实现手机OA应用。可运营的要求

 有丰富、准确地统计报表功能，支持移动公司对客户按用户数、按使用时间、按使用功能、按数据量大小等多种角度进行计费。 在基础的公文流转功能之上，各种附加功能模块能够独立的进行开通和关闭。

 由于使用这套系统的集团客户相互间可能存在多种关系，因此在设计上要考虑经过少量的配置即能解决同在该平台上的若干个单位之间的公文交流和传输问题。

 具备多级管理员权限，对于平台级管理员和客户管理员需要严格界定和分配其功能权限。

 能够与移动后台的BOSS、ADC平台、行业网关等系统进行数据互联，实现运营中的订购、变更、取消等各项也许流程。

6.2、前台标准功能模块

OA平台应当具备一些常见的标准功能模块，如：公文流转、邮件收发、集团通讯录等。但是应注意这些模块的“标准”只是相对的，每一个集团客户对这些标准模块的具体需求仍然可能不同，而某省移动公司和软件提供商必须满足这些差异化的需求。

* 由于专业知识有限，本需求书所列的标准模块功能描述难免有错漏之处，故仅作参考。各软件提供商应在自己的方案中结合自身情况重新提出标准模块及其准确地描述。

6.2.1.统一登录门户

集团客户使用的移动数据专线登录云计算平台上的OA平台，采用域名、网络地址识别等方式自动区分不同的集团客户，进入集团客户各自的登录门户。虽然不同集团客户的登录界面不尽相同，其后台均是使用同一的功能模块和业务逻辑。

6.2.2.异地远程办公

通过国际互联网，可以进行异地远程办公，只要有互联网的地方都可以登陆办公系统，但对通过外网访问OA时，需提供动态密码检验功能实现VPN通道鉴权，用户需输入绑定手机接收到的短信动态密码，方可进入登陆界面

6.2.3.公文流转

公文流转包括收文、发文、签报以及收发文后文件传阅、文件处理、文件存档等功能。具体的功能需求如下：

系统的公文处理模块应具备发文、收文、以及对处理过程的跟踪督办；

公文处理的流程能够灵活的定制；

公文处理的痕迹完全保留；

系统能够通过特定视图显示文档的完整处理流程和当前的处理状态；

处理过程支持多人顺序或并发的数字签名；

文档要以有效的信息安全手段进行保护，防止非法的访问；

电子公文还应该能够方便的转换为其他形式，如纸质文档、二维条码文档等；

电子公文在平台级别进行数据加密，防止后台非法查阅、修改。

6.2.4.公文管理

所有部门及单位发文均可按冠字进行整理。如财务部文件整理人员可按“局财”、“局财通”等冠字对其部门所发文件进行整理归档。

所有收文、发文按年份自动归档。查询公文的时候根据在途公文和归档的公文进行精确查询和模糊查询。

6.2.5.公告发布

提供公告、新闻、通知等信息的实时发布和更新功能，后台进行增、删、改的功能。信息归档保存和查询的功能。

6.2.6.企业邮箱

向用户提供企业邮箱的功能，能够通过集团客户申请的专有域名进行邮件收发，提供电子邮箱相关的业务使用和管理功能。集成139邮件服务器。

6.2.7.公文电子印章认证

电子印章是一种形象的签名盖章方式的数字认证技术，它以数字签名的方式通过第三方权威认证有效地进行网上身份认证，能够安全、有效的实现信息的数字签名和认证。具有安全、保密、防篡改的特性，可对企业、单位网上传输的信息进行有效保护和安全的传递。

用户安装电子印章客户端软件，并通过USB Key（存储用户的私钥以及数字证书的USB硬件设备）可在流程配置的相应步骤加盖电子印章；可以形象的模拟传统实物印章加盖的过程，并对公文内容进行保护，防止伪造、篡改公文；提高系统的安全性和可靠性。

特别注意：采用的电子印章和数字签名技术产品必须具备国家级的相关认证资质，以满足政府部门的安全性要求。

6.2.8.短信、彩信功能接入

短信动态密码认证

通过短信动态密码认证确保系统从外网的访问安全。

公文、邮件到达提醒

用户在个人设置中设置相关公文和邮件的短信提醒设置后，当新公文或者邮件到底后系统就会通过短信系统发送相关信息给用户。达到实时提醒用户的功能。

短信发送

用户可以通过办公系统快捷对系统内部人员发送短信。

短信重置密码

系统提供短信重置密码功能，方便用户在忘记密码的时候能够快速通过手机短信获取系统密码，减小维护人员工作。

6.2.9.电子传真功能接入

6.2.10.IMS的点击拨号平台功能接入

6.2.11.系统管理

图形用户界面？

OA平台应该提供图形化的用户界面，客户管理员能够通过图形用户界面完成日常必须的操作维护工作。

流程监控

系统要求客户管理员可以实时监控所有在途流程公文信息和异常流程公文信息，客户管理员或者维护人员可以通过界面处理流程的异常情况。

a)根据流程类型来查看所有的在途流程信息； b)可以跟踪流程目前出处的具体步骤状态；

c)对于异常流程能够进行相应的提醒和调度，有相关操作要有日志记录。

流程定制

客户管理员可以通过流程定制工具灵活调整流程定义信息，在业务流程调整后能够通过简单的设置来实现流程的修改。流程的改动有相关的审查日志记录。

员工帐号管理

客户管理员可以通过系统维护界面，对员工帐号进行基本的管理操作（开通、删除），绑定企业员工移动手机号码，对员工的基本信息进行管理操作（添加、删除、修改），同时要记录相关的操作日志。

权限管理 系统管理员可以通过系统维护界面，对员工权限信息进行基本的管理操作（添加、删除、修改），对员工的信息的变更有相关的审查日志记录。

电子印章管理

管理员可以通过电子印章管理系统界面，对电子印章、数字证书进行管理(审批，制作，发放，修改，和废除)，对电子印章信息的变更有相关的审查日志记录。

公文统计

系统要求能够按用户、部门根据时间、发文类型来做相关数据统计功能，出具相应的运行日志。

公文超时处理

公文处理超时时间可以由系统管理员来设置，当公文达到超时时间前一段时间系统自动发送短信或者邮件通知处理人，当公文超时后处理人仍然可以处理公文，但超时记录将记录到系统，每月定期统计各个部门或者个人超时公文的情况。

6.2.12.事务管理

事务管理主要包括会议组织、处理投诉、来信来访及后勤事务管理等功能。

会议管理包括会议室安排、会议资料、会议通知、会议纪要等； 来信来访包括信访登记、分转办、催督办、领导签发、结案、归档等功能；后勤服务管理包括办公用品、固定资产、车辆、考勤等管理内容。

6.2.13.日程、通讯录管理

主要包括领导日程安排和个人日程安排。系统将通过日日历的方式展现日程，方便查询，系统会自动通过手机短信和即时消息的方式来提醒用户预约的活动，直观的浏览模式让你方便的查询集团通讯录。

6.2.14.工作绩效

主要包括工作计划、绩效考核和数字报表等。对于定量考核的能够实现自动计分评级。

6.2.15.组织文化

主要包括工作论坛、工作简报、知识问答、调查投票等。6.2.16.个人工作台

提供自定义的工作界面，个人工作的汇总，方便用户处理。包括待办工作、已办工作、个人考勤、日程安排、个人收藏、外出授权、个人设置等。6.2.17.移动OA 具备移动OA的功能，用户在手机端能够完成OA平台的主要业务功能（公文流转处理、邮件收发、集团通信录等），手机客户端要支持主流的手机品牌、型号和操作系统，并且要针对移动数据网络进行优化，尽量减少业务数据流量。

6.3、后台主要功能模块

后台主要功能模块主要是用于OA平台的日常业务运营管理，主要涉及集团客户账户开通修改、系统资源分配、功能模块配置、业务运行状况监控等方面。

* 由于专业知识有限，本需求书所列的标准模块功能描述难免有错漏之处，故仅作参考。各软件提供商应在自己的方案中结合自身情况重新提出标准模块及其准确地描述。

6.3.1.后台登录门户

OA平台的系统管理员通过后台登陆门户实现管理界面工作台的登录，同时也需考虑支持外网的远程登录。

6.3.2.集团客户注册

集团客户首先在BOSS系统内申请开户，包括开通账户和订购相应业务（如：移动OA平台），系统后台管理员需要用BOSS系统分配的集团编码、账号、密码、MAC地址、IP地址等，为客户配置所需的 权限、业务功能模块和初始逻辑流程，以实现集团客户的成功注册。

6.3.3.运营状况分析

按行业、地区、时间及套餐属性等维度对业务量、业务增长及业务量的变化进行分析，以图形化界面显示。

集团客户业务使用特征分析：从客户属性构成、业务使用量构成维度分析集团客户的业务使用习惯和群体特征。

6.3.4.运营维护管理

OA平台具备图形化界面对各内部业务平台连接状况、功能模块使用情况的监控告警功能。同时对平台、具体用户的业务使用情况也进行监控

6.3.5.权限管理

用于管理平台系统的用户及其权限，认证平台系统各级管理及操作人员的身份以及控制各级用户的访问权限。

平台系统需要提供完善的权限管理机制，保证系统的访问安全和满足用户定制需求，主要包括如下功能：

用户角色管理：将系统中的若干管理及操作权限制定为一个角色，通过对用户指定角色的方式，赋予用户相应的管理和操作权限；

用户权限分配：将系统中的若干管理及操作权限赋给某一用户或将某一角色赋予相应用户，进行用户的权限分配，使其具有登录系统并进行相应操作的能力；

用户登录控制：检查用户身份的合法性，并根据用户ID确定该用户的访问权限；

新增、修改、删除用户：提供灵活方便的配置操作界面，实现用户的增加、修改及删除功能。

6.3.6.日志管理

自动记录OA平台系统管理人员使用中产生的日志，包括操作日志、用户日志等各种相关日志。

七、对售后服务的要求

在软件提供商最终获得本项目后，软件提供商应该向某省移动公司提供相应的售后维护服务，服务的主要内容和要求有：

需根据某省移动公司的要求对系统进行持续的开发和免费的版本升级，要求具备详细的软件版本、补丁的申请和装载记录，对应用软件版本有严格管理；

需在贵阳本地常驻不低于5人的技术支撑人员，明确技术指导和技术支持的范围和程度。主要负责配合某省移动公司在全省范围内的售前、售后的技术支撑、业务培训等工作；

需提供完善成熟的维护保障体系，确保项目的稳定运行和推广，主要包括：

 提供维护服务具体内容；  提供服务承诺；

 提供投诉专线和投诉处理流程；  提供维护服务质量考核的指标；  定期形成各类应用系统的维护报告。

如何写“完”UI设计说明书 篇6

我们中的大多数人都写过UI设计说明书（或UI规格说明书），论坛里也经常会有类似的讨论，对UI设计说明书的框架和结构我就不做过多的说明了。为什么有人写了上百页的UI设计说明书，别人还是看不懂，或者说忽略了细节呢？那今天我们重点讨论一下关于细节阐述和表达的一些经验，以免写出只有自己看得懂的UI设计说明书。我先说说我总结的一些经验吧，希望大家积极讨论： 我们的目标是：（没有蛀牙，^_^ 玩笑！）

既要清晰描述用户界面原型中的细节和交互方式，又要方便项目组的其他开发人员、需求人员以及测试人员等角色交流察看的说明文档。主要内容包括：

1.产品的目标和成功标准，（例如一个全新的预言项目不可能要求用户满意度在90%以上，对升级产品要求就会高一些。）2.产品最终用户群及产品用途（了解用户的年龄、职业、产品的使用环境等都是非常必要的）3.首先满足基本功能。（例如DVD机的基本功能是播放影碟，可能还有播放CD的功能等等）4.主要功能（在产品的几十个功能中通过用户验证和项目组筛选，选取用户最常用到的功能，将其优化，以不同层次展现于界面上。）5.用户界面特性。（每一款界面都有自己的特性，比如触摸屏的操作界面与手机的操作界面就算功能完全一样，结构、布局等特点也不会相同的。）几点注意事项

1.必须紧贴需求，围绕功能点展开。

2.描述语言简短精确（这样别人看的时候才不会烦）

3.保持文本的易维护性，建议使用WORD的大纲视图编写，便于更改和查找。4.说明书一定要有版本管理，对每次更新内容要做详细说明。

5.图标要与名称一同提交，并说明是什么类型，如桌面图标、列表中的图标、工具栏图标、按钮图标、属性框或提示信息框中的图标等等。6.注意纪录，包括项目组和用户以及合作伙伴，如果在解释某一特性时令两人以上会感到困惑，那这一部分就需要更清楚的阐述了。

7.设计与实现同步，这个时最难的了，很多设计由于程序无法实现都被“卡”掉，早期程序也无法确定是否可以实现，伤脑筋！

8.维护UI设计说明书时不要忘记维护原型，作为UI设计说明书的补充原型是很重要的。UI设计中容易被忽略的地方 1.支持错误提示和撤销操作 2.简便的安装和卸载。3.必要的设置和帮助。

4.异常处理、错误消息的描述和问题回应提示。

5.除界面上有的图标和按钮外，还要有快捷键、菜单访问键、右键菜单、是否支持从其它软件界面内托拽复制文件等操作的说明。

6.域、菜单和按钮在什么情况下为不可点击状态。7.状态区，用来描述界面状态的区域，通常位于页面下方。（PS存储时状态区会显示进度条）8.剪贴板行为，用户在我们产品中拷贝的文字或图片的局部，是否可以贴入其他程序。9.指针的行为，说明超过多长时间的等待时应出现沙漏状态，在文本输入区光标应有改变、有链接的地方有变为小手等

10.声音行为，警示音、按钮触发音等

11.统一消息窗的弹出位置、背景色、大小、布局及特色

12.菜单栏和下拉选项等程序动作的描述，是向下还是向右弹出等。

13.动态状态描述，如果要求窗口渐隐或渐显，那就要说明渐隐或渐显过程的时间以及方式（半透明还是马赛克）等。

Art Designer作业规范书 1定义 2作业环境

? Art Designer日常作业的主要编辑工具： ? 软件图标主要编辑工具： ? 各种Logo设计及印刷设计：

其他常用的编辑工具： 2.2 Art Designer 一般作业要求 ? 各个产品需求图档主要是：

Logo & Symbolic Mark：软件的识别标志象征图及标准字搭配方案； Autorun：光碟自动执行界面；

Splash：软件激活时的欢迎及说明画面； Login：登陆界面；

Banner：显示版权信息及系列软件版本号画面； Icon：软件工具栏，应用程序配套图标； Source：各类软件所图形资源。? 命名规范：

aaa_bbb.ccc aaa-软件代号 bbb-图片类别(splash、sanner、logo等）ccc-文件后缀名（文件类型）? 备份共享方式：

3产品相关图文件 编辑规格 3.1 图文件编辑规格

以下为产品图文件编辑模板的举例说明： 图文件编辑规格（附图以“XXXXXX”为例）

Logo & Symbolic Mark：软件的标志和象征图形用于宣传和视觉记忆。（由于标志的范围很广，设计制作时必须用适量设计软件完成，以满足各种不同运用的需求）Autorun:软件CD安装时有不同选项在以此图为基础添加不同选项的链接按钮。（软件直接安装无选项时以此图为底图）软件执行图标(Icon)编辑规格 应用程序图标规格：

? 64*64 32bit、48*48 32bit、32*32 32bit、24*24 32bit、16*16 32bit ? 48*48 16bit、32*32 16bit、24*24 16bit、16*16 16bit ? 32*32 4bit、16*16 4bit（Windows 2000及以下版本支持16bit图标而Windows xp 支持32bit的图标，全规格的图标可以在不同系统中自动匹配，4bit的图标主要用于“安全模式”中显示）Tool Bar 图标规格： ? 24*24 16bit、16*16 16bit ? 16*16 4bit Menu 图标规格： ? 16*16 16bit ? 16*16 4bit 4.Art Designer 作业遵循流程规范 Art Designer作业中 Adobe Photoshop 专用层面图文件命名规范 6 软件包装设计的规范 宣传页的设计要素及注意事项 8 Art Designer日常学习交流

UI设计指南 年-月-日 版本:V1.0 作者: *** 审核: *** 批准: *** 年-月-日 更改记录

日期 被修改的章节 修改的类型* 修改描述 修改人 年-月-日 全部 A 新建 ** * 修改类型分为 AMODIFIED D-DELETED 1 简介 1.1 目的

提供UI设计流程定义，为交互设计提供依据。1.2 背景

使UI工作整体流程更具规范化和为这一规范更具有可视性。1.3 适用范围

任何具有UI设计阶段的项目。1.4 缩写和术语

1.4.1可用性 usability 以有效性、效率和满意度为指标，产品在特定使用背景下为了特定的目的可为特定用户使用的程度。1.4.2 用户 user 与产品交互的个体。1.4.3 任务 task 实现目的所必需的活动。1.5 参考资料

（本规范使用到的参考资料）1.6 本文结构概述

定义UI设计流程和角色定义。1.7 流程概述

介绍整个UI设计阶段的执行过程。2 流程定义 2.1 流程图划分 UI设计流程图

在流程图中其实是有两个纬度，分别是纵向和横向

2.1.1 纵向：是角色的划分对于一个项目来说通常会有三个角色分别是用户研究角色、设计角色、制作角色

用户研究角色：主要是让UI实现以用户为中心的设计主要工作有两点

在进行界面设计前了解整体产品的需求，并针对UI设计了解用户对UI的需求，再把这需求传达给设计师，即《UI需求分析报告》，这过程中的主要方法有焦点小组等。

在UI设计过程当中会不停的要求对设计进行评价这是就要求让用户来评价，我们称这种方法叫使用性测试，在流程图中的表现是对交互模型的使用性测试和验证性地使用性测试。

设计角色：主要是实现界面的交互设计即逻辑设计和界面设计

在做交互设计时一般是要根据《UI需求分析报告》做交互模型，即用一些工具实现一些交互的动作，让用户能直观的了解界面间的逻辑关系，来确认设计的可行性。

在界面设计时主要是设计皮肤即界面的布局图标的摆放等，这时的设计也是要遵循需求，并且要写《UI设计说明》。

制作角色：主要是实现界面的截图及坐标的定义

在这过程中制作角色要和开发人员沟通，两个角色相互配合完成项目的最后阶段。

2.1.2横向：是代表时间轴和整个项目开发的过程是对应的：UI的数据采集阶段实际上就是项目的启动阶段交互设计和使用性测试阶段就是项目的细化阶段界面设计和美术制作阶段就是项目的构造阶段。2.2 关于评审点的说明

在UI流程图中实际上可以把UI的工作划分成四个部分即数据采集、交互设计、界面设计、美术制作。

在数据采集阶段：会有可能是非正式评审主要会有交互设计师需求人员等参与；

在交互设计阶段：也会有评审主要会有用户研究角色、需求角色和开发人员角色来评审逻辑关系的合理性，包括使用合理性和设计合理性；

在界面设计阶段：在设计过程中会不断的和用户及需求人沟通以达到以用户为中心的设计，这结束后会有很正规的评审活动，这是的评审实际上是对整个UI项目的整体评审，包括工作量、质量等多项的正规的评审；

在美术制作阶段：美术制作阶段实际上就是制作角色和开发人员的不断的沟通完成全部开发工作的阶段，因此这过程的评审是由双方面的协调与合作来表现的。2.3 UI设计主要流程 时间1 时间2 时间3 UI启动阶段 UI细化阶段 UI构造阶段

数据采集 分析报告 交互模型 使用性测试 界面原型设计 使用性测试 评审 美术制作 验证性测试

需求分析报告 需求分析报告 2.4 UI设计时间表和里程碑：

数据采集** 交互模型** 使用性测试** 启动阶段《分析报告》 细化阶段《需求分析报告》 细化阶段《需求分析报告》 验证性测试** 美术制作 评审 使用性测试** 界面原型设计 ：表示时间点 “**”：表示可裁减的活动 “《..》”：表示阶段生成文档 2.5 参与人及担任角色和工作量 角色 人员 工作量 项目经理

交互研究工程师 设计角色 制作角色

界面设计之图标设计规范 图标样式应该有趣、色彩丰富且充满活力，因为现在的系统支持图标是32位图标，并且边缘非常平滑。在矢量程序中绘制完每个图标后，再用Adobe Photoshop进行处理可使图像更加完美。本规范是专为设计者编写的。在创建图像时，建议您与高水平的图形设计者一起工作，尤其是具有丰富的矢量和3D软件经验的图形设计者。

图标设计概述的目的是让您熟悉WindowsXP的新样式，为创建图标做好准备。图标样式特性

(1)色彩丰富，是对WindowsXP外观的补充。

(2)不同的角度和透视特性为图像增添了动态活力。

(3)元素的边角十分柔和，并略微有些圆滑。

(4)光源位于图标的左上角，同时有环绕光照亮图标的其它部分。

(5)渐变效果使图标具有立体感，进而使图标的外观更加丰满。

(6)投影使图标更具对比度和立体感。

(7)添加轮廓可使图像更清晰。

(8)日常对象(如计算机和设备)具有更现代化的个人外观。图标尺寸

Windows XP图标有四种尺寸，建议使用以下四种尺寸：

(1)48×48像素

(2)32×32像素

(3)24×24像素

(4)16×16像素 图标色彩深度支持

WindowsXP支持32位图标。32位图标为24位图像加上8位alpha通道。使图标边缘非常平滑，且与背景相融合。

每个WindowsXP图标应包含以下三种色彩深度，以支持不同的显示器显示设置：

24位图像加上8位alpha通道(32位)8位图像(256色)，加上1位透明色

4位图像(16色)，加上1位透明色 调色板

图标中使用的主要颜色。对象的角度和分组

WindowsXP样式图标使用的透视网格：并非所有对象使用16×16的复杂图像都能获得较好效果。某些对象通常以直观图像显示：文档图标、符号图标(如警告或信息图标)、单一对象图标(如放大镜)除非创建重叠辅助对象可以更清楚地表达图标的含义，否则就可读性和完整性而言，还是应使用直观图像。还应考虑如何按组查看图标，以便确定如何将对象分组。投影

使用投影后，WindowsXP图标将更清晰且更具立体感。可在Photoshop中实现这种效果，本指南的后面部分将对此进行描述。若要为图像添加投影，请在 Photoshop中双击图像的图层，并选择Drop Shadow。然后将Angle更改为135，Distance更改为 2，Size更改为2。此时投影为75%不透明黑色。轮廓

绘制XP样式图标时，为图像添加轮廓可使之更清晰，并可保证图像在不同背景色上都具有较好效果。概念

设计图标时，请考虑以下因素：

使用已有概念以确保真实表达了用户的想法。考虑图标在用户界面环境中以何种形式出现，以及如何作为图标集的一部分使用。考虑图形的文化背景。避免在图标中使用字母、单词、手或脸。必须用图标表示人或用户时，请尽可能使其大众化。如果图标中的图像由多个对象组成，应考虑如何使图像尺寸更小。建议在图标中使用的对象不超过三个。对于 16×16的尺寸大小，还可考虑删除某些对象或简化图像使之更容易辨认。透明工具

将Gif Movie Gear(GMG)打开一个对话框，其中显示您的图标。使用吸管工具单击图标的背景色。此颜色将更改为暗黄绿色(或在 GMG中选作透明背景色的颜色)。重复所有4位和8位帧。若要保存图标，请选择 File->Save Icon As...。创建工具栏

Windows工具栏图标除不使用投影之外，使用的样式与其它图标相同。由于工具栏图标非常小，建议您使用简单的图像。如果以直观方式显示图像即可清晰地表达图标的含义，则不必使用其它复杂方式。创建AVI

WindowsXP使用8位AVI。创建.avi文件的过程与创建图标的过程相同-在Photoshop中准备图像，然后将其拖动到GMG 中。请按以下指导创建8位图标。若要使用GMG保存AVI，请转至File->Export As->AVI file。

创建.avi文件时，请考虑以下因素：使用品红(R255 G0 B255)作为背景透明色。在Photoshop中，重要的一点是不要出现杂散像素。

详细设计说明书编写规范

Detailed Design Specification 详细设计说明书编写规范

第1章 引言 1.1 目的

使项目详细设计说明书的编写规范化，从而规范软件管理。尽可能详细地描述程序的各成份的设计考虑，以利于编制程序。

[此处加入编写目的] 1.2 背景

说明该软件系统名称，开发者，详细设计原则和方案

[此处加入项目背景资料]

1.3 参考资料

列出有关的参考资料名称，作者，发表日期，出版单位

[此处加入参考资料]

1.4 定义

列出本文件中专用的术语，定义和缩写词

[此处加入术语和缩写词]

第2章 程序系统的组织结构

2.1 运行环境(编程协定)

[此处加入运行环境].1.1 操作系统&数据库系统

列出系统运行的有关操作系统&数据库系统的名称，版本号，对应版权单位

[此处加入操作系统]

[此处加入数据库系统].1.2 编程工具

列出开发此系统的所需的主要编成工具的名称，版本号，对应版权单位,并简述其特点

[此处加入编程工具].1.3 编辑、调试、联接程序

[此处加入编辑、调试、联接程序].1.4 编译工具

[此处加入编译工具].1.5 模拟、仿真数据

模拟数据使用过去的真实数据，数据如下：

[此处加入数据]

过程如下：

[此处加入过程].1.6 诊断、测试程序

[此处加入诊断、测试程序].1.7 检测程序

[此处加入检测程序]

2.2 单元命名规则

[此处加入单元命名规则]

2.3 程序逻辑

用图表列出本程序系统内每个模块（或子程序）的名称，标识符，以及这些模块（或子程序）之间的层次关系

[此处加入程序逻辑]

第3章 单元设计说明

[此处加入单元设计说明]

3.1 模块单元（或子程序）（标识符）1（名称）

注明该功能模块的编号和模块名称

3.1.1 程序描述

简要描述安排本模块（或子程序）的目的意义，程序的特点

[此处加入程序描述].1.2 功能

(1)功能说明

详细描述此模块（子程序）完成的主要功能

[此处加入功能说明]

(2)功能框图

[此处加入功能框图].1.3 输入项

描述每个输入项的特征，如：标识符，数据类型，数据格式，数值的有效范围，输入方式等

[此处加入输入项].1.4 输出项

描述每个输出项的特征，如：标识符，数据类型，数据格式，数值的有效范围，输出方式等

[此处加入输出项].1.5 算法

[此处加入算法].1.6 流程逻辑

[此处加入流程逻辑].1.7 接口

分别列出和本模块（子程序）有调用关系的所有模块（子程序）及其调用关系，说明与本模块（子程序）有关的数据结构

[此处加入接口].1.8 限制条件

说明本模块（子程序）运行中受到的限制条件

[此处加入限制条件]

3.2 模块单元（或子程序）（标识符）2（名称）

„„„

第4章 软件界面设计规范

说明：软件界面设计属于详细设计，设计人员可根据项目的规模及时间跨度来决定是否单列出来，可灵活掌握

4.1 编写目的

当今软件界的所有软件无不是可视化的用户界面，它的好处不外乎它有美观、直接、操作者易懂和操作方便等好处。（此处输入编写文档的具体目的）。

4.2 内容：.2.1 界面设计思想

“为用户设计，而不是设计者”。

4.2.2 界面设计原则

（1）界面要美观、操作要方便并能高效率地完成工作。

（2）界面要根据用户需求设计。

（3）界面要根据不同用户的层次设计。（有的用户对计算机相当了解而有的从来就没碰过计算机）

（4）避免出现嵌套式的界面设计。

（5）界面和代码要相互制约。

（6）界面要通“人性”。即要有引导用户操作的功能，不能是操作一有误就卡住什么都做不下去，又无任何提示来帮助用户如何进行操作。

4.2.3 界面设计样式

(1)登录界面

（此处加入登陆界面图）

（2）系统功能布局

菜单形式

（此处加入界面图）

标签栏形式

（此处加入界面图）

（3）录入界面

（此处加入界面图）

（4）查询界面

（此处加入界面图）

（5）统计界面

（此处加入界面图）.2.4 常见提示信息样式

（1）当操作会带来严重后果时（默认按钮为“否“）

（此处加入界面图）

（2）当操作会带来一定后果时（默认按钮为“否“）

（此处加入界面图）

（3）当需征求操作者意愿时（默认按钮为“是“）

（此处加入界面图）

（4）当需提供操作者帮助时

（此处加入界面图）

（5）当操作者操作有错时

（此处加入界面图）

（6）当是一般提示时

（此处加入界面图）

范例：

（此处加入界面图）

4.2.5 常见错误信息样式

（此处加入界面图）

4.2.6 其他界面约定

字体：一般界面字体为宋体，字号为9Twip（只要把窗体字体设为宋体，字号为9twip即可）。

颜色：界面颜色采用默认色（除非用户有特殊要求）。

按钮：高度375Twip，除“确定”和“取消”外都需含有快捷键。

常见按钮快捷键：添加(A)、删除(D)、查询(S)、更新(U)、打印(P)、关闭(C)、重新查询(R)、统计(T)、退出(E)。

数据：REAL型数据一律保留两位小数且右对齐。

对齐方式：界面上的标题（Label）右对齐，其他控件左对齐。

第5章 编码标准规范

5.1 编写目的：

使用统一编码约定集的主要原因，是使应用程序的结构和编码风格标准化，以便于阅读和理解这段编码。好的编码约定可使源代码严谨、可读性强且意义清楚，与其它语言约定相一致，并且尽可能的直观。

一组通用目的的编码约定应该定义完成上述目的所必需的、能让程序员自由地创建程序逻辑和功能流程的最小的要求。编码约定的目的是使程序易于阅读和理解，而不是用过份的约束和绝对的限制来束缚程序员本身的创造性。

5.2 内容：

程序设计语言的特性和风格会直接影响到软件的质量和可维护性。

编码原则：

应尽量避免在系统初始化时运行过多的代码。（此处加入详细原则）

（1）选用控制结构只准许一个入口和一个出口。

（2）程序语句组成容易识别的块，每块只有一个入口和一个出口。

（3）复杂的结构应该用基本控制结构进行组合嵌套来实现。

（4）语句中没有的控制结构，可用一段等价的程序段模拟，但要求该程序段在整个系统应前后一致。

（5）严格控制GOTO语句，仅在下列情形才可使用。用一个非结构化的程序设计语言去实现一个结构化的构造。

?

在某种可以改善而不是损害程序可读性的情况下。? 5.2.1 对象命名约定

公式：对象名称=对象前缀+自定义名称（自定义名称要有一定的意义且第一个字母大写）

说明：如果是不需要对其编码的对象，那么对象名用默认对象名。

应该用一致的前缀来命名对象，使人们容易识别对象的类型。下面列出了 Delphi 支持的一些推荐使用的对象约定。

（1）推荐使用的项目前缀

控件类型 前缀 例子

Class Module cmdl cmdlCheck

Data Environment dev devPrints

Data Report drt drtEnglish

Form frm frmEntry

MDIForm mfrm mfrmSinoexport

Module mdl mdlConnection

Project pjt pjtCkmis

（2）推荐使用的控件前缀

控件类型 前缀 例子

3D Panel pnl pnlGroup

ADO Data ado adoBiblio

Animated button ani aniMailBox

Check box chk chkReadOnly

Combo box drop-down list box cbo cboEnglish

Command button cmd cmdExit

Common dialog dlg dlgFileOpen

Communications com comFax

Control（当特定类型未知时，在过程中所使用的）ctr ctrCurrent

Data dat datBiblio

Data-bound combo box dbcbo dbcboLanguage

Data-bound grid dbgrd dbgrdQueryResult

xxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxx xxxxxxxx（3）推荐使用的数据访问对象的前缀

用下列前缀来指示数据访问对象。

数据库对象 前缀 例子

Connection con conReports

xxx db dbAccounts

一些例子：

（此处加入例子）

（4）推荐使用的菜单前缀

应用程序频繁使用许多菜单控件，对于这些控件具备一组唯一的命名约定很实用。除了最前面 “mnu” 标记以外，菜单控件的前缀应该被扩展：对每一级嵌套增加一个附加前缀，将最终的菜单的标题放在名称字符串的最后。下表列出了一些例子。

菜单标题序列 菜单处理器名称

（此处加入标题序列及处理器名称）

当使用这种命名约定时，一个特定的菜单组的所有成员一个接一个地列在 Visual Basic 的“属性”窗口中。而且，菜单控件的名字清楚地表示出它们所属的菜单项。

（5）为其它控件选择前缀

对于上面没有列出的控件，应该用唯一的由两个或三个字符组成的前缀使它们标准化，以保持一致性。只有当需要澄清时，才使用多于三个字符的前缀。

例如，（此处加入例子）

5.2.2 常量和变量命名约定

公式：常量或变量名称=常量或变量范围前缀+常量或变量类型前缀+自定义名称（自定义名称要有一定的意义且第一个字母大写）

除了对象之外，常量和变量也需要良好格式的命名约定。本节列出了（此处加入变量列表）。

变量应该总是被定义在尽可能小的范围内。全局(Public)变量可以导致极其复杂的状态机构，并且使一个应用程序的逻辑非常难于理解。全局变量也使代码的重用和维护更加困难。

Delphi中的变量可以有下列范围：

范围 声明位置 可见位置

过程级（此处加入名称）

模块级（此处加入名称）

全局（此处加入名称）。

较好的编码习惯是尽可能写模块化的代码。例如，如果应用程序显示一个对话框，就把要完成这一对话任务所需要的所有控件和代码放在单一的窗体中。这有助于将应用程序的代码组织在有用的组件中，并减小它运行时的开销。

除了全局变量（应该是不被传递的），过程和函数应该仅对传递给它们的对象操作。在过程中使用的全局变量应该在过程起始处的声明部分中标识出来。

变量范围前缀

随着工程大小的增长，划分变量范围的工作也迅速增加。在类型前缀的前面放置单字母范围前缀标明了这种增长，但变量名的长度并没有增加很多。

范围 前缀 例子

全局 g GstrUserName

模块级 m MblnCalcInProgress

本地到过程 无 DblVelocity

（此处加入说明）

变量

声明所有的变量将会（此处加入说明）。

应该给变量加前缀来指明它们的数据类型。而且前缀可以被扩展，用来指明变量范围，特别是对大型程序。

变量数据类型

用下列前缀来指明一个变量的数据类型。

（此处加入说明）

描述变量和过程名

变量或过程名的主体应该使用大小写混合形式，并且应该足够长以描述它的作用。而且，函数名（此处加入函数名称）。

对于频繁使用的或长的项，推荐使用标准缩略语以使名称的长度合理化。一般来说，（此处加入特例说明）就困难了。

当使用缩略语时，要确保它们在整个应用程序中的一致性。在一个工程中，如果一会儿使用（此处加入说明问题），将导致不必要的混淆。

用户定义的类型

在一项有许多用户定义类型的大工程中，常常有必要给每种类型一个它自己的三个字符的前缀。如果这些前缀是（此处加入前缀名称）。

5.2.3 结构化编码约定

（此处加入约定说明）

记住下列几点：

每一个重要变量的声明应该包括（此处加入变量名称）。

（2）格式化代码

因为许多程序员（此处加入问题）

（此处加入解决问题的说明）

（3）给常量分组

变量和定义的常量应该按功能分组，而不是分散到单独区域或特定文件中。

（4）运算符

（此处加入运算符列表及说明）

（5）为（此处加入问题）查询创建字符串

（此处加入说明）

5.2.4 数据源的约定

（此处加入数据源的约定）

5.2.5 数据库访问约定

访问数据库用ODBC drivers/ADO，但如果在有的技术ADO解决不了的情况下可用其他方法。

数据库访问技术有：（此处加入说明）

5.2.6 其他约定

（1）当日期、时间型数据要求严格时，（此处加入说明）

（2）记录集应用约束

（此处加入约束）

利用记录集

（此处加入记录集说明）

（3）文件命名约定