CS软件设计规范
1. 界面规范
1.1. 总体原则
1、以用户为中心。设计由用户控制的界面，而不是界面控制用户。
2、清楚一致的设计。所有界面的风格保持一致，所有具有相同含义的术语保持一致，且易于理解。
3、拥有良好的直觉特征。以用户所熟悉的现实世界事务的抽象来给用户暗示和隐喻，来帮助用户能迅速学会软件的使用。
4、较快的响应速度。
5、简单且美观。
1.2. 原则详述
1.2.1. 用户控制
用户界面设计的一个重要原则是用户应该总是感觉在控制软件而不是感觉被软件所控制。操作上假设是用户--而不是计算机或软件--开始动作。用户扮演主动角色，而不是扮演被动角色。在需要自动执行任务时，要以允许用户进行选择或控制它的方式来实现该自动任务。提供用户自定义设置。因为用户的技能和喜好各不相同，因此他们必须能够个性化界面的某些方面。Windows为用户提供了对许多这方面的访问。您的软件应该反应不同的系统属性--例如颜色、字体或其他选项的用户设置。
采取交互式和易于感应的窗口，尽量避免使用模态对话框，而使用"非模式"辅助窗口。"模式"是一种状态，它排除一般的交互，或者限制用户只能进行特定的交互。当最好使用一个模式或该模式只是可替换的设计时--例如，用于在一个绘图程序中选定一个特定感觉--请确保该模式是显然的、可见的，是一个明确的用户选定的结果，并且容易取消。
在后台运行长进程时，保持前台式交互。例如，当正在打印一个文档，即使该文档不能被改变，用户也应该可以最小化该窗口。
用户喜欢探索一个界面，并经常从尝试和错误中学习。一个有效的界面允许交互式的发现，
它只提供一组合适的选择，并在用户可能破坏系统或数据的情况时发出警告。如果可行，还应提供可逆转或可还原的操作。即使在设计得很好得界面中，用户也可能犯错误。这些错误既可以是物理上得（偶然地指向了错误的命令或数据），也可以是逻辑上的（对选定哪一个命令或哪些数据做出了错误的决定）。有效的设计避免很可能导致错误的情况。它还包容潜在的用户错误，并且使用户易于还原。
1.2.2. 清楚一致的设计
一致允许用户将已有的知识传递到新的任务中，更快地学习新事物，并将更多的注意力集中在任务上。这是因为他们不必花时间来尝试记住交互中的不同。通过提供一种稳定的感觉，一致使得界面熟悉而又可预测。一致在界面的所有方面都是很重要的，包括命令的名称、信息的可视表示，操作行为，以及元素在屏幕和窗口内部的放置。
相同含义的词使用统一的术语。比如对于仓库中存放的物料，不可同时又称为物品、货物、备品、产品和材料等等，而统一约定一个称谓，且此称谓是用户熟悉的和易于理解的。
使用一组一致的命令和界面来展示常见功能。例如，避免一个"复制"命令在一种情况下立刻执行一个操作，但在另一种情况显示一个对话框要求用户键入目标然后才执行。应该使用同样的命令来执行对用户来说相似的功能。
操作环境内的一致。保持Windows提供的交互操作和界面约定之间的高度一致，用户将能很快熟悉软件的使用。
使用隐喻的一致性。如果一个特定的行为更多的是一个不同的事物的特征，而不是它的隐喻的含义，那么用户可能在学习将行为和该事物相关联时遇到困难。例如，对于放在回收站中的对象而言，焚烧炉和废纸箩代表不同的模型。
建立项目保留字。通过建立保留字来明确和统一术语和操作命令。
提供可视反馈。在后台运行长进程时（时间超过1～10秒，视具体情况而定），必须提供进度条等信息指示。
除非特别必要时，不要提供声音反馈。在有严重的问题发生时，可以使用声音来提示用户，但是通常应该允许用户取消声音。
保持文字内容清楚。信息的表达要言简意赅，易于理解而又不罗嗦；避免使用冗长的文字给用户反馈。
1.2.3. 有良好的直觉特征
用熟悉的隐喻为用户的任务提供直接而直观的界面。通过允许用户利用他们的知识和经验，隐喻使得预测和学习基于软件的表示的行为更加容易。
在使用隐喻时，不需要将基于计算机的实现局限在真实世界的对应物上范围之内。例如，与其基于纸张的对应物不同，Windows桌面上的文件夹可以被用来组织各种对象，例如打
印机、计算器、以及其他文件夹。同样，Windows文件夹可以其真实世界对应物不可能的方式被排序。在界面中使用隐喻的目的是提供一个认知的桥梁；隐喻并不以其自身为最终目的。
隐喻支持用户认知而不是记忆。用户记起与一个熟悉的事物相关联的意义要比他们记起一个特定命令的名称要容易得多。
同常见软件保持一致性。出色的用户界面在程序中将实现同用户以前用过的其它成功软件一致的动作。
1.2.4. 较快的响应速度
保持界面能很快对用户操作作出反应。
提供快捷键。
特别对于有大量录入项的界面，能让用户不使用鼠标即可完成快速数据录入。在用户界面中加入一些功能，这些功能可以让熟练用户在不同的区域快速的输入数据。这些功能包括重复功能、快捷键、带有有意义的图标的按钮等等，所有这些可以使速度快的用户可以控制界面并加快数据的输入。
除非必要，不要重绘屏幕。
1.2.5. 简单且美观
简单。
界面应该很简单（不是过分单纯化）、易于学习、并且易于使用。
它还必须提供对应用程序的所有功能的访问。在界面中，扩大功能和保持简单是相互矛盾的。一个有效的设计应该平衡这些目标。支持简单性的一种方法是将信息的表示减少到进行充分交流所需的最少信息。例如，避免命令名和消息的文字描述。不相关或冗长的句子扰乱了您的设计，使得用户难以很容易地提取重要信息。另一个设计简单而有用的界面的方法是使用自然的映射和语意。界面元素的排列和表示影响它们的意义和关联。简单还与熟悉相互关联。熟悉的事物通常似乎更简单。尽可能尝试建立利用用户已有的知识和经历的联系。您可以使用渐进揭示来帮助用户管理复杂的事物。"渐进揭示"涉及到仔细的信息组织，以便只在恰当的时候才显示信息。通过隐藏向用户表达的信息，您减少了用户必须处理的信息数量。例如，您可以使用菜单来显示操作或选择的列表，还可以使用对话框来显示一组选项。渐进揭示并不意味着对显示信息使用非传统的技术，例如需要一个修饰键作为访问基本功能的唯一方法，或者强迫用户通过一个更长的分级交互序列。这会使用户界面更加复杂和麻烦。
美观。
可视设计是应用程序界面的重要部分。可视属性提供了非常好的印象，并传达特定对象的交互行为的重要线索。同时，出现在屏幕上的每一个可视元素也是很重要的，它们可能竞争用户的注意。提供清楚地促进用户对表达的信息的理解的连贯环境。图形或可视设计器的技巧对于这一方面是无价的。
1.3. 细节约定
1.3.1. 界面风格
1.3.1.1. 普通外观
使用一致性
一致的外观将使用户界面更易于理解和使用。用户界面控件看起来应该是一致的。
使用安排和流程 在西方文化中（包括中国），人们习惯于从左到右，从上到下进行阅读，因此，应该将重要信息放在上面和左边。左上角最容易吸引起人们的注意力。
使用对齐
通常，使用左对齐来使用户界面控件更易于浏览。对于数值文本，应该使用小数点对齐或右对齐。对于非数值文本，应该避免使用右对齐或居中对齐。不必对什么都使用中间对齐，或者使它们保持对称形式。在右边或底部保留空白区域更适合习惯。
使用分组
将相关的用户界面控件分成组，以体现它们之间的关系。同时，还要显示相关信息。将控件放在它所作用的对象旁。使用空格、分组框、线条和标签，或者其它分隔符对用户界面控件进行分组。
使用强调
使用焦点、位置、分组、层次、启用/禁用、大小、颜色或者字体等，来将注意力集中在需要首先看到的用户界面控件上。尽量以可视的方式指明用户接下来应该进行的操作。
使用可视的提示
尽量使用近似的大小和间距来指出用户界面控件是相似的，而使用不同的大小和间距来指出用户界面控件视是不同的。
使用空格
使用空格来创建一个"透气室"，以使窗口布局更易于理解，并且查看起来更舒服。空格的多少要适当，不要显得太分散。但是，要避免过多地使用空格。如果可能，尽量使窗口小一些。
警惕空洞
不要到处粘贴公司或产品的名称及徽标。虽然在启动屏或"关于"框中出现公司或产品名称及徽标是完全可以接受的，但其他窗口中的可用空间应该出现其他内容。如果没有其他内容，那么应尽量使窗口小一些。
注意大小
使用用户界面控件的分辨率具有独立性。使用系统规格（使用GetGystemMetrics API 函数）或文本规格（使用GetTextMetrics或GetTextExtentPoint32 API 函数）来确定用
户界面控件的大小。任何显示文本的对象（如对话框或定义的文本文档）都应该使用文本规格。
考虑使用资源或预定义的布局网格
资源模板或预定义的布局网格有助于您在不同的窗口之间实现一致性。
1.3.1.
2. Windows的可视提示
暗示与用户只需通过查看可视提示来确定对象的使用方式的能力有关。在Windows中，请保持使用下面的可视提示：
可以单击凸起的项目。
可以单击当鼠标从其上移过时突出显示的项目。
不能单击下凹的项目。
可以编辑具有白色背景和闪烁垂直条（光标）的项目。
不能编辑具有灰色背景的项目。
灰色项目是被禁用的。
1.3.1.3. 交互
尽量提供对所有功能的键盘访问
理想情况下，除了绘图这样的图形功能，其他所有的功能都应该只能通过键盘来访问。
尽量提供对所有功能的鼠标访问
理想情况下，除了文本输入外，其他所有功能都应该只能通过鼠标来访问。
确保具有明显后果的操作要求用户进行明确的选择*
用户需要完全明确他将要进行危险性操作或破坏性操作。
对于使有耗时的操作都给出反馈*
在进行长时间的操作时，要确保有等待光标、进度表或其他的可视反馈。用户应该能够取消长时间的操作。如果可以取消未完成的操作，那么将按钮标记为"取消"，否则将按钮标记为"停止"。
可视的指示模式*
向用户提供一种可视的反馈，以指出用户进入一种模式，通常可以通过更改光标或标题栏文本来做到这一点。
确保单击和双击的一致性*
单击用于非按钮选定，而双击用于选定并执行默认操作。换句话说，双击（在列表框、组合框，或其他接受双击的控件中）的效果应该与选定控件中的一个项目，然后按下Enter键的效果一样。
鼠标右键仅用于快捷菜单*
确保鼠标右键仅用于快捷菜单，而不要用于其他用途。
不要使用鼠标中键*
如果用户的鼠标有中键，那么让用户使用"控制面板"中的"鼠标"实用程序自己分配中键的行为。
保持分配的快捷键的一致性
组合功能键和Ctr键用于快捷键。习惯上不将At键用于组合键，业务At键常常被用于访问键。尽量避免使用At键和Ctr键，因为这种组合会使快捷键非常麻烦，而且也很不方便。
将快捷键作为补充方式*
千万不要将快捷键作为访问命令的唯一方法。应该让用户有更多的明显选择。
避免水平滚动条
与垂直滚动条不同，水平滚动条并不受欢迎，因为它会使项目阅读起来比较困难。
解决的办法有：尽量使用垂直滚动条、加宽窗口、减小文本的宽度，或者使文本自动换行等。当然，如果确实需要，还可以使用水平滚动条。
1.3.1.4. 程序
只有主程序窗口才有标题栏图标、菜单栏、工具栏和状态栏*
因为单击主窗口的任务栏按钮也会激活二级窗口，所以二级窗口绝对不要显示在任务栏中。二级窗口不要因为使用菜单栏、工具栏或状态栏而使其变得复杂。可以使用标题栏图标来明显区分主窗口和二级窗口。另外，绝对不要使用默认的Windows图标(飘动的窗口图标)作为窗口图标。
简化默认配置 让用户按自己的速度来学习和使用程序。
应用程序应该使用多文档界面（MDI）或单文档（SDI） 这些程序界面应该与应用程序的使用模式匹配。
默认情况下，应用程序应该保持为最大化
当应用程序占用整个屏幕时，常常能够提高用户的工作效率。
实用程序应该使用SDI或对话框界面
这些程序界面应该与实用程序的使用模式匹配。对于实用程序，建议不要使用MDI界面，因为管理这些窗口需要付出很多努力。
实用程序应该在小屏幕范围内运行
实用程序常常与其他程序一起运行，因此它们需要在小屏幕范围内运行。实用程序应该有灵活的窗口布局，以适应多种不同的大小。实用程序很少以最大化的形式运行。
使用实际文档的SDI程序必须支持运行多个实例*
运行多个实例使用户能够同时操作多个文档。
使用"退出"命令终止程序
使用"退出"终止程序；使用"关闭"移走主窗口和非模式对话框；使用"取消"移走模式对话框。当关闭主窗口并不表示终止进程时，对于主窗口使用"关闭"来代替使用"退出"。例如：关闭打印机状态窗口不会取消打印任务。
1.3.1.5. 默认
保存和恢复用户选择
程序应该能够能够恢复到其最后退出的状态。MDI程序应该能够恢复文档窗口的大小和位置。对话框通常应该使用最后输入的值作为默认值。
提供适当的默认值
提供提供适当的默认值来减少用户不必要的操作，从而帮助用户完成工作。提供最可能使用并给出设置实际使用方式的默认值。通常，最好的默认值是用户最后输入的值。
考虑选择默认值时的安全性*
不应该将不可恢复或破坏性的操作设置为默认值。不要使用令用户感到莫名其妙的默认值。
1.3.1.6. 窗体
对话框窗体大小尽量不要超过640*460，留20给任务栏。并且高和宽（或W宽和高）的比应该大致保持为3:4（或4：3）。一般应该将窗体的"Position"属性定义为"poDesktopCenter"，"WindowState"属性为"wsNorma"，某些主界面设置为"wsMaximized"。"ShowHint"属性设为"True"。如果是模式对话框，则将"BorderStye"属性设置为"bsDiaog"。
窗体文件(*.dfm)保存为文本格式，以便在VSS中比较不同版本之间的差别。如果窗体大小超过屏幕大小，则在Dephi开发环境中打开时，大小会有改变，并且影响到运行时刻效果。由于每个人的屏幕大小设置不一样，有些是1024*768，有些是800*600，因此在设计期间请注意窗体大小，尽量不要超过800*600，以免出现上述问题。
1.3.1.7. 布局和间距
窗体控件布局和间距尽量保持与Windows标准一致。控件与窗体的上、下、左、右边距为7象素。右下角主命令按钮之间的间距为6象素，如果主命令按钮在右上角，之间的间距则为4象素。主命令按钮一般情况为75×21象素，如果按钮的文本很长，应该适当加宽按钮的宽度。如下图。其它详细资料请完全参照错误！书签自引用无效。和命令按钮。
控件的"T abOrder"属性值应该与控件排列顺序一致，即遵循从上到下、从左到右这样一个流程。如果在PageContro的多个页面中存在类似的控件，应该尽量使得它们在各个页面中出现的位置/大小比较一致，以免在页面间切换时产生闪烁感。
1.3.1.8. 图标、图片
不同界面中的同一功能应该使用同样的图标和图片。图标、图片的色调、风格尽量保持一致。图标、图片的隐喻应能确切表示功能的含义，如果不能，就直接使用文本，以免混淆用户。如果功能是一个动作时，可能比较难找到确切表示该功能的图标，这时应该尽量采用此动作相关的名词做图标。例如Windows中的"剪切"功能就是用一把剪刀来表示的。
1.3.1.9. 提示信息（Hint）
工具栏按钮应该设置工具提示"Hint" 属性。Hint能帮助用户更方便地理解和使用。详细资料可以参照工具栏、工具提示。
如果使用了"TSpeedButton"控件，并且只有图标，同样应对它设置"Hint"属性。如果不是特殊情况，应尽量避免使用"TSpeedButton"控件，而使用"TButton"控件代替。
1.3.1.10. 标点符号
在标识控件用途的标签文本（abe）和提示信息（Hint）中，应使用半角符号。如果是指导性标签文本（如解释按钮功能的句子），则使用全角符号，并且句子应遵循中文标点符号标准。如下图Microsoft标准对话框例子。其他详细资料可参照静态文本。
1.3.1.11. 对话框
对话框应该在所有视频模式下都能够正确显示
当在VGA模式（640×480）下显示时，对话框应该不超过640×460（留20像素给任务栏）。这将确保对话框能够显示在所有的视频模式下。
确保模式对话框的模式*
确保使用具有父窗口的模式对话框都提供正确的父窗口句柄，而不时提供NU句柄。如果没有提供父窗口句柄，那么父窗口仍处于活动状态，因此该对话框实际上并不是模式对话框。
不要使用可滚动的对话框*
也就是说，不要使用需要滚动条来进行完全查看的对话框。这种对话框使用起来非常不方便，并且也时完全不必要的。应该重新设计这种对话框。
不要在作为二级窗口的对话框中使用菜单栏*
使用这种对话框需要付出很多努力。注意，在用作主窗口的对话框（如"查找"实用工具）中，菜单栏时可以接受的。还要注意的是，在所有对话框中，快捷菜单和菜单按钮都是可以接受
的。二级对话框不要使用菜单栏，但可以使用菜单按钮。
不要在作为二级窗口的对话框中使用标题栏图标*
标题栏图标用于区别主窗口和二级窗口。
不要在任务栏上显示作为二级窗口的对话框*
注意，单击主窗口的的任务栏图标也将激活二级窗口。
对话框中使用下页图所示的页面布局和间距。
对于相似的对话框，使用控件位置来强调其相似性。 如果意义相同的同一控件出现在一些相似的对话框中，那么它应该显示在相同的位置。另一方面，应避免将可能会产生混淆的不同控件放在同一位置。
对非模式对话框最好使用可停放的对话框
可停放对话框在功能上与非模式对话框是等效的，但其位置设置更为灵活。
策略地设置输入焦点
将最初的输入焦点设置在最可能首先使用的控件上。
在对话框标题文本中不要出现省略号
例如，作为选择"打印选项..."命令结果而显示地对话框的标题应该为"对于选项"。但是，表示命令正在执行过程中菜单对话框（如"连接到Internet..."对话框）是一种例外情况。
为所有可处理访问键的控件分配访问键*
访问键可以使用户的手保持在键盘上，从而使访问程序更加方便。您可以直接在其标题中为诸如命令按钮、单选按钮、复选框等控件分配访问键。通过提供静态文本标签或带有访问键、在Tab顺序上先于控件的组框，您可以为诸如编辑框、列表框、组合框等控件分配访问键。在其他情况下不要为组框分配访问键--这会使人产生混淆。"确定"按钮没有访问键，因为在作为默认按钮时，它通过提Enter键来选定的。"取消"按钮也没有访问键，因为Esc键预览清除模式对话框。如果可能，避免使用小写的g、j、p、q或y作访问键，也避免使用这些字母前后的字母作为访问键。下划线不能与这些字母的下行字母分开。当然，访问键必须是唯一的。
避免使用粗体文本 尽量少使用粗体文本。
在Windows 3.1 的对话框中，粗体文本用于在旧式的视频硬件上绘制被禁用的文本（即抖动的灰色文本）。因为现在的视频硬件可以绘制没有抖动的灰色文本，所以Windows 为了使外观更加清洁，现在Windows 在对话框中使用正常文本。粗体文本仅用于强调。对于大多数对话框不要粗体文本。
提供环境敏感的帮助
对于复杂的对话框，应该为整个对话框提供环境敏感的帮助（通过帮助按钮或F1键访问），或者为个别控件提供控件特定的帮助（通过"这是什么？"按钮或Shift＋F1 键来访问），或者同时提供这两种帮助。
1.3.1.1
2. 对话框的主要命令按钮
将主命令按钮与对话框主体分开*
主命令按钮包括像"确定"、"取消"、"关闭"、"帮助"、"停止"、"隐藏"，以及其他相关按钮的等命令按钮。这种分开使主命令按钮更易于查找和识别。
认真选择对话框的方向
在西方文化中，人们习惯于从左到右、从上到下进行阅读，因此，将主命令按钮靠底部或右边放置更容易被发现。您应该选择对话框的外观比例与屏幕的外观比例（通常高与宽的比例为3：4）相似的方向。这将使对话框的外观看起来更加舒服，并且更易于在屏幕上进行定位。如果按钮具有不同的大小，那么可以将它们放在对话框菜单底部。当不能确定时，也可以将按钮放在底部，因为这种定位方式最为常见，也更易于阅读。
将排列在底部的主命令按钮右对齐
右对齐主命令按钮适合从左到右的阅读习惯。当只有一个主命令按钮时，您或许希望例外地将其居中放置。
右对齐主命令按钮
避免使用多行或多列的主命令按钮
多行或多列的主命令按钮对用户是一个打击。如果有许多主命令按钮，那么注意，通常在右边排成一列与在底部排成一行相比可以放置更多的按钮。另外，您可以考虑使用命令菜单。如果必须使用很多按钮，那么注意使用多行别使用多列的效果好。
对模式对话框，通常提供"确定"和"取消"按钮*
要使用对话框，用户需要能够方便地识别前进（使用"确定"按钮）和后退（使用"取消"按钮）的方式。您可以使用更明确的按钮代替"确定"按钮，但绝对不要在模式对话框中替换"取消"按钮，除非用"停止"来表明正在进行的操作无法取消。
对于非模式对话框或或作为主窗口的对话框，提供"关闭"按钮而不提供"确定"和"取消"按钮*
将"确定"和"取消"按钮用于非模式对话框或作为主窗口的对话框可以使对话框看起来像是模式对话框。而且，当用于非模式环境中时，"确定"和"取消"时没有什么意义的。使用"关闭"按钮可以消除这种混淆。
通常将"确定"按钮排第一，"取消"其次，"帮助"最后*
"确定"或其等价按钮通常作为第一个主命令按钮。"取消"按钮应该位于"确定"的右边或下面。将"确定"和"取消"按钮放在一起。"帮助"按钮应该时最后一个按钮。如果没有"确定"按钮，那么应该将"取消"按钮放在"帮助"按钮的前面。这可以使主命令按钮更易于查找和识别。确保"取消"按钮真正用于取消操作* 当取消时，程序的状态栏应该与之前显示的模式对话框完全相同。如果不是这样，那么应该用"停止"按钮来代替"取消"按钮。模式对话框中的"取消"按钮应该与标题栏中的"关闭"按钮效果相同。而属性表是个例外，因为"取消"按钮不会取消已经应用的更改。
1.3.1.13. 属性表和属性页
让属性页独立工作
避免使一个属性页的行为或操作受其他属性页的限止。用户不可能发现属性页之间的这种独立关系。在属性页的使用顺序方面应该没有限止。用户应该能够随时查看任意的属性页。
属性页的布局相互独立
一些属性页通常不会占用同样大小的空间。占用空间较小的属性页应该与最大的属性页的布局的格式方式不同，因为将会产生额外的空间（见下图）。
属性页的布局保持独立，避免居中。
用属性表代替使用带选项卡的对话框
使用属性表而不使用带选项卡的对话框除了具有一致性之外，没有什么明显的实用性优势。另外，对于实际显示对象属性的对话框使用属性表，而对于其他用途，所有带选项卡的对话框。
对属性显示总采用属性表，即使仅有一个页*
采用属性表能够明确告诉用户查看的使属性而不是一般的对话框。属性表有一个"应用"按钮来帮助用户测试设置。
绝对不要使用两行以上的标签*
最好使用一行标签，但两行也是可接受的，两行以上就太多了，可用级连属性设置或多个对话框代替。
总为属性提供"应用"按钮
再说一次，提供"应用"按钮帮助用户对设置进行测试。
对显示属性的属性表总是在其标题中写上"属性"一词和对象的名称*
请注意，不是所有的属性表都是用来显示属性的。
总将命令按钮放在右边*
适用于所有页的命令按钮必须置于标签页区域的外面，而仅适用于单个页的命令按钮必须置于该标签页的里面。
1.3.1.14. 向导
对高级的、复杂的或不常用的任务使用向导 向导对非常高级或复杂的任务十分有用，省去了用户许多麻烦的操作。当向导用于不常用的任务时，其效果最好。对常用任务使用向导则显得大而不当。
1.3.1.15. 控件
尽量采用标准控件
尽可能采用标准控件（6个最早的控件和新的Win32常用控件）。采用非标准控件的程序与绝大多数Windows程序看起来不一致。只用完全合理时才使用自定义控件。
定制标准控件时要小心
改变标准控件的标准外观或行为时一定要小心，这是个常常出错的地方。
将无效控件置为不可用*
将不适用于当前程序状态的控件置为不可用。
取消不必要滚动条
尽量使控件的尺寸足够大，避免使用滚动条。
1.3.1.16. 命令按钮
采用最小的宽度和标准的高度
带文字的命令按钮应该采用50个对话单位（75个像素点）的最小宽度、14个对话单位(21个像素点)的标准高度。尽量将不同大小的带文字命令按钮的个数控制在两个以内。对父窗口拖动（owner-draw）按钮或无文字的按钮（如"…"），其大小可以任意设置，原则是使命令按钮外观简朴一致。高度大于14个对话单位(21个像素点)的按钮看起来不够专业。尽管不限制命令按钮的最大宽度，但宽度超过200个对话单位的按钮使不妥当的。
针对国际化适当加宽按钮
尽管50个对话单位（75个像素点）的宽度是适合英语文字的最小宽度，但对需要针对其他语言进行本地化的程序来说，可能就太小了。对于需要翻译为其他语言的程序，将命令按钮的最小宽度定为60个对话单位可能更适合。
将无效按钮置为不可用，以取消报错*
绝对不要使可用的按钮仅产生一条出错信息。
总采用省略号来表示需要更多信息*
命令中的省略号表示执行命令时需要更多信息，而不是简单的确认。省略号并不表示一定会出现对话框。
绝对不要指定双击行为*
用户意料不到命令按钮会响应双击，因此不可能发现这样的行为。
命令按钮大小使用Window标准75x21象素。一般情况下，"确定"和"取消"按钮的属性设置如下：
btnOk: TButton
Caption = '确定'
Defaut = True
ModaResut = mrOk
end
object btnCance: TButton
Cance = True
Caption = '取消'
ModaResut = mrCance
End
"确定"和"取消"按钮一般被映射为Enter键和Esc键，因此不应该对它们指定访问键，除此以外的命令按钮都应该指定一个访问键。
1.3.1.17. 复选框
用复选框开关选项，用单选按钮改变模式*
用复选框进行选项的开关操作是很有效的，但如果用来将模式改变为另外一种状态就难免让人迷惑了。例如，可用一个复选框来表示是否显示工具栏，但若用复选框来切换打印机的横向模式和纵向模式就会使人糊涂，对横向和纵向模式应该用一组单选按钮代替。
避免一组复选框中选项个数超过8个
应该考虑用复选框列表代替，它占用的空间更少，但复选框列表需要滚动时使用就稍稍麻烦了。尽管控件足够或保持与同一窗口中其他复选框一致时，采用复选框时可取的，但大于8个左右的复选框就未免太多了。
考虑将修改组的复选框置于应该分组框中
这样的分组使得复选框之间的关系更为明显。
宁可竖向对齐
虽然更合适的情况下采用横向对齐或直角对齐也是可以接受的，但竖向对齐的一组复选框更易于浏览。
1.3.1.18. 单选按钮
避免一组单选按钮中的选项个数超过8个
考虑用列表或组合框代替，它们占用的空间更少，但要记住控件使用更麻烦些。尽管控件足够或保持与同一窗口中其他单选按钮一致时，采用单选按钮是可取的，但多于8个的单选按钮未免太多了。
避免使用单选按钮进行开/ 关或是/ 否选择 用复选框代替。
总将单选按钮置于一个分组框中*
由于单选按钮是一组相互排斥的选项，所以分组框使选择更为明确。
宁可竖向对齐
虽然更合适的情况下采用横向对齐或直角对齐也是可以接受的，但竖向对齐的一组单选按钮更易于浏览。
1.3.1.19. 组合框
总给组合框提供一个标签*
必须用标签来表明组合框的用途。
使组合框的下拉列表最少有5行长
少于5行的列表就没有可用的滑块，不易于滚动。请注意，如果组合框没有足够的列项来填满列表，那么将自动缩短列表的长度。
避免组合框的列项少于4
考虑用单选按钮代替，它们虽然多占空间，但更易于操作。如果空间更为重要或为了保持与同一窗口中的其它组合框一致时，采用组合框则更为可取。
1.3.1.20. 编辑框
总给编辑框提供一个标签*
必须用标签来标明编辑框的用途。如果标签在左边，将标签文字与编辑框文本垂直对齐。
避免有输入限制的编辑框
将编辑框用于用户对任何文本的输入或数字编辑框用于数字的编辑。对于输入受限的情况，使用其他的控件，如组合框、列表、滑块和微调框。对于日期和时间，使用日期和时间拾取控件。
用微调框和浏览按钮使编辑框可视
微调框和浏览按钮是简单的可视机制，它们帮助用户在编辑框中进行有效的输入。避免让用户必须输入。仅对数字编采用带微调框的编辑框，对于文本，使用组合框代替。
按期望输入来设置编辑框的宽度
编辑框的宽度是对期望输入的可视提示。例如，如果用户是输入地址，两个字符宽的State 字段明显暗示用户输入两个字符的州名缩写。如果期望的输入没有特别的大小，就选择与其他编辑框或控件一致的宽度。
总采用数字编辑框用于数字输入*
当用户在数字字段中输入非数字文本时，不应该有任何出错消息。
1.3.1.21. 滑块
总给滑块提供一个标签*
必须用标签来标明滑块的用途。而且，滑块还应该有标明高、低值意义和当前选择的标签--当然都不带冒号。
1.3.1.2
2. 静态文本
左对齐静态文本标签
左对齐使得标签外观更有条理，且易于浏览。
宁可将静态文本标签置于相关控件的左边，而不是上面 这样对齐使标签更易于被发现，且方便了标签和控件的浏览。很明显，长控件是例外情况，如列表视图、树形视图（Tree）和多行编辑框。
总在用于标识控件的静态文本标签后带上冒号*
使用冒号明显表示为控件标签的文本。为控件提供附加信息的标签不应该有冒号，如用来解释滑块控件的标签。标签也可作为屏幕读出器的输入信息。
对非标签文本总用只读编辑框*
只读编辑框允许用户将文本复制到剪贴板上，并在文本比控件长时可进行滚动。
不要把静态文本置于凸起的边界上*
在凸起边界上的静态文看起来像按钮，因而用户会试图单击它。
1.3.1.23. 列表框
总给列表框提供一个标签*
必须用标签来标明列表框的用途。
使列表框至少5行长
少于5行的列表没有滑块，不便于滚动。如果列表框没有滚动条，那么使用一个更短的列表框也是可以接受的。
对多个选择考虑采用复选框
复选框列表可以突出其多个选择的能力。如果不能接受复选框列表，那么可以采用多选列表，并用静态文本表示选项个数，清楚指明可进行多项选择。
对多选列表考虑提供"全部选中"和"全部取消选中"命令
由于希望全部选中或全部取消使常见的事情，所以这两个命令方便了用户进行多项选择。1.3.1.24. 列表视图
总给列表视图提供一个标签*
必须用标签来标明列表视图的用途。
使列表视图至少5行长
少于5行的列表视图没有滑块，不便于滚动。如果列表视图没有滚动条，那么使用一个更短的列表视图也是可以接受的。
仅在列表可排序时采用可单击的表头*
可单击的表头只应用于排序。首次单击时应按正序对列表进行排序，而第二次单击时按反序进行排列。
对列项大约超过30的列表视图总使其可进行排序*
用户能够对列表进行排序方便了对信息的查找。
1.3.1.25. 滚动条
滚动条仅用于滚动*
使用滑块或微调框来设置数值。
使滚动条足够长，保证有可用的滑块。 没有滑块的滚动条不便于使用。
1.3.1.26. 分组框
利用分组框分组相关控件
尽管分组框通常是用于单选按钮的分组，但也可用于任何控件的分组。避免使用只有一个控件的分组框，除非是为了保持与同一对话框中其他分组框一致。
考虑采用静态线或文本标签来代替分组框
分组框多时要占去许多空间。如果空间紧张的话，一个替代分组控件的好办法是同时采用静态文本标签和静态线。
考虑采用静态文本标签和静态线代替分组框
不要在分组框标签的后面使用冒号*
分组框标签的意思明白，使用冒号完全没有必要且让人糊涂。
1.3.1.27. 菜单
总用单个单词作为菜单标题*
菜单栏上多个单词的菜单标题看起来像多个菜单标题。
不要在菜单栏的文本间留有空隙*
不一至的菜单栏文本既无用，又难看。
避免占多行的菜单栏*
尽管将父窗口缩小到足够窄时，任何菜单栏都要占用几行，当要避免正常使用时因菜单项都而占用几行的菜单栏。
保持菜单稳定*
将无效菜单置为不可用，而不要删除它们。但是，对整个程序实例都无效的菜单，就应该删
除。
合理安排菜单项的顺序
将相关菜单项组合在一起。重要的命令应该位于菜单的顶部，而不重要的菜单则位于菜单的底部。
将无效菜单置为不可用来代替报错*
菜单绝不应该有仅产生出错消息的可用命令。
分配访问键*
访问键使用户可以手不离开键盘进行操作，并提供程序的可访问性。尽可能避免用小写字母g、j、p、q、y或单词中与它们靠近的字母来分配访问键，因为下划线与下一行的字母不好区分。当然，一个菜单中的访问键应该是唯一的。
总采用省略号来表示需要更多信息*
命令中的省略号表示执行时需要更多的信息，而不是简单确认。省略号不表示一定有对话框出现。
使用标准菜单
避免不提供"文件"、"编辑"和"帮助"菜单。由于这些是标准菜单，所以用户会期望它们出现。例如，期望在"文件"菜单中发现像"打印"和"退出"这样的命令，虽然这些命令可能与"文件"无关。同样，用户期望在"编辑"菜单中发现"剪切"、"复制"和"粘贴"命令，至少要在"帮助"菜单中发现"关于"命令。
统一放置"查找"和"选项"命令
总将"查找"命令放在"编辑"菜单中，而有"工具"菜单时，总将"选项"置于其中，否则置于"查看"菜单中。
用复选标记来开关选项，
用单选组来改变模式*
用复选标记进行选项的开关操作是有效的，但如果用来将模式改变为另外一种状态就难免让人迷惑了。例如，可用一个复选标记来表示是否显示工具栏，但若用复选框来切换打印机的横向模式和纵向模式就会使人糊涂，对横向和纵向模式应该用一个单选组来代替。
不要使用多列的下拉菜单*
多列增加了菜单不必要的复杂性。
不要使用"Bang"（爆炸的声音）菜单*
Bang菜单是菜单栏上那些看起来像下拉菜单，但实际是选择后立即执行的命令，如"退出"！显然，用户希望菜单标题就只是菜单，而不是命令。
不要右对齐菜单标题*
这样的菜单风格陈旧且不易于使用。
1.3.1.28. 上下文菜单
考虑将上下文菜单作为冗余使用
上下文才菜单不应该是访问命令的唯一方式。通常上下文菜单中的命令应该在菜单栏中也提供，使用上下文菜单是为了提高访问效率。
避免在上下文菜单中包含快捷键
应该将快捷键分配在菜单栏中，上下文菜单的快速访问是通过鼠标进行，而不是通过键盘。
1.3.1.29. 工具栏
保持工具栏稳定*
将无效的工具栏按钮置为不可用，而不是将它删除。但是，应该考虑删除用户进入一种模式用不到的整个工具栏。
将无效命令置为不可用，而不是报错*
工具栏绝不应该包含只出现错误消息的命令。
对实用程序采用大工具栏按钮
好的使用程序工具栏常常与应用程序的按钮不同，其按钮更简朴，更大。实用程序工具栏应该只包含几个带有描述性文字和图形的显眼命令。
对应用程序采用可移动的、可定制的工具栏，而对实用程序采用固定的工具栏
应用程序需要灵活的工具栏来支持其典型的使用方式。用户使用实用程序的时间一般不长，因而不需要定制工具栏。
提供显示或隐藏工具栏选项
如果有多个工具栏，分别为它们提供显示或隐藏的选项。
总使用工具提示* 工具提示帮助用户了解工具栏按钮的作用。
1.3.1.30. 工具提示
用工具栏的工具提示来提供信息，但要简短 避免提示很明显的事情。考虑采用省略号来表示执行命令时需要更多信息。如果该命令已分配有快捷键，则显示该快捷键。
使工具提示文本成为高级用户的媒介
工具提示用于简短的识别和提醒，而不是用来教学。
用工具提示显示有用信息
不仅仅可在工具栏上使用工具提示，它的使用简单，能够向用户提供有用信息。但不可滥用--工具提示太多也就失去了其价值。不要对命令按钮会静态文本这样的控件使用工具提示。不要自动消去包含许多文字的工具栏提示 默认时，10秒种后工具提示将自动消去。如果
工具提示的文字很多，10秒钟对用户来说就看不完了。
1.3.1.31. 文本
避免不必要的缩写词
要么给文本更多的空间，要么改写文本使其占用更少的空间，缩写词使文本不易理解。
避免不必要的大写字母文本
除非只去首字母构成的缩写词，否则不要用字母全为大写的单词，这样的单词看起来像在冲用户大喊大叫一样。
避免复杂的标号
尽量采用简单的标点，如句号、逗号、问号，以及破折号。避免使用分号、感叹号、圆括号、括号，等等。
采用一致的大小写规则*
对窗口标题、菜单、命令按钮、列标题属性页选项卡以及工具栏提示文字采用与书题一样的大小写规则，而对于标题、单选按钮、复选框、分组框和菜单项帮助中的文本采用与句子一致的大小写规则。（对于标题，除了不是标题开头和结尾的冠词和介词外，每个单词的第一个字母大小。对于句子，每个句子的第一个单词以及通常大写的单词--如专有名词的首字母大写。）
避免不好的背景
将文本放在实地、颜色适中的背景上，确保在文本和背景之间存在良好的对比。
避免冒犯性语言
避免激烈的词语，如fata（致命的）、execute（执行）、ki（杀死、毁掉）、terminate（终止）、和abort（中止）。
1.3.1.3
2. 消息框
仔细选择消息框的类型
采用带"确定"按钮的信息消息框向用户提供有关命令结果的信息。采用带"是"、"否"，以及可能"取消"按钮的警告消息框在继续进行前需要用户输入的情形下告诫用户。采用危急消息框通知用户进行工作前需要修改一个错误。
不要使用疑问消息框类型*
不再推荐对消息框使用疑问标记符（MB_ICONQUESTION），因为它在Windows98后一致用来表示上下文修改帮助。
避免不必要的消息框
不要用出错消息来报告正常行为，而应该用来报告不正常或不期望的结果。不要对很容易恢复的操作进行确认。
问用是/否回答的问题
问用户问题时，采用"是"和"否"按钮代替"确定"和"取消"按钮，这样使问题易于理解。与对话框中不一样，"确定"和"取消"按钮很少同时用在消息框中。
确保消息框选项按钮与文本一致
例如绝不要用"是"和"否"来作为非提问消息的响应。同样，不要使用多个效果相同的选项按钮。例如，除非有不同的操作结果，否则不要同时提供"否"和"取消"按钮。"否"按钮应该执行操作，而"取消"应该取消操作。
仔细选择默认按钮
将最安全的或最常用的选项作为默认按钮。
避免无用的帮助
除非提供真正有用的附加信息，否则不要提供"帮助"按钮。不要附加带无用帮助信息的没意义的消息框。
对危急错误考虑采用系统模式消息框
采用系统模式消息框向用户提示严重的、可能造成破坏性的、急需注意的错误。系统消息框除了有WS_EX_TOPMOST样式外，与应用程序模式对话框完全一样。与在16位Windows 中不一样的是，系统模式不影响用户与其他程序的交互。
1.3.1.33. 错误消息
避免错误号
除非这个错误号对用户真正有用，否则不要给出错误号。
避免责怪用户
避免在出错消息文字中出现单词you（你）或your（你的）。如果需要，当指用户操作时使用被动语气。采用与"错误发生了"等价的表达，比采用与"你捅漏子了"等价的表达要好得多。
避免敌对性语言
避免在错误消息文字中使用词语bad（糟糕的、坏的）、caution（小心）、error（错误）、fata（致命的）、iega（非法）、invaid（无效）和warning（警告），而应该使用更具体的描述性词语。并且应该尽量解释到底是什么出了错。
在出错消息文字中使用平实的语句
表达要简短、清楚、协调、具体。除非缩写词，否则不要使用全部大写的单词，那样的单词看起来像在冲用户大喊大叫一样。使用完整的句子和一般的现在或过去时态。避免缩写词。避免在用户错误消息文字中装做有趣或高人一等 用户并不觉得错误消息有趣，故装幽默并不能被广泛接受。
允许用户压制非危急的错误消息
对经常出现的非危急错误，向用户提供一个压制该错误消息的选项。
软件结构设计规范
精选编制： 审核： 批准：
目录 1.简介 (6) 1.1.系统简介 (6) 1.2.文档目的 (6) 1.3.范围 (6) 1.4.与其它开发任务/文档的关系 (6) 1.5.术语和缩写词 (6) 2.参考文档 (8) 3.系统概述 (9) 3.1.功能概述 (9) 3.2.运行环境 (9) 4.总体设计 (10) 4.1.设计原则/策略 (10) 4.2.结构设计 (10) 4.3.处理流程 (10) 4.4.功能分配与软件模块识别 (11) 5.COTS及既有软件的使用 (12) 5.1.COTS软件的识别 (12) 5.2.COTS软件的功能 (12)
5.3.COTS软件的安全性 (12) 5.4.既有软件的识别 (12) 5.5.既有软件的功能 (13) 5.6.既有软件的安全性 (13) 6.可追溯性分析 (14) 7.接口设计 (15) 7.1.外部接口 (15) 7.2.内部接口 (15) 8.软件设计技术 (16) 8.1.软件模块 (16) 8.2.数据结构 (16) 8.3.数据结构与模块的关系 (16) 9.软件故障自检 (17)
1.简介 1.1.系统简介 提示：对系统进行简要介绍，包括系统的安全目标等。 1.2.文档目的 提示： 软件结构设计的目的是在软件需求基础上，设计出软件的总体结构框架，实现软件模块划分、各模块之间的接口设计、用户界面设计、数据库设计等等，为软件的详细设计提供基础。 软件结构设计文件应能回答下列问题： 软件框架如何实现软件需求； 软件框架如何实现软件安全完整度需求； 软件框架如何实现系统结构设计； 软件框架如何处理与系统安全相关的对软/硬件交互。 1.3.范围 1.4.与其它开发任务/文档的关系 提示：如软件需求和界面设计文档的关系 1.5.术语和缩写词 提示：列出项目文档的专用术语和缩写词。以便阅读时，使读者明确，从
B/S 系统界面设计规范 1.引言 界面美观、操作易用性、维护成本低是评价B/S系统的关键。本规范参考了一些成熟产品科学的开发方法，将开发过程中的方式、规则等强行的约束。希望藉此来提高用户操作感受，提升B/S产品的质量。 1.1. 编写目的 广义的界面概念包含了除页面布局设计之外，交互性的设计，及人体工程学方面的研究。本规范制订的依据从广义概念出发，总结以往项目的成败经验，目的是从整体上提升公司B/S类产品的质量、开发效率。从以技术为中心发展为以客户为中心，将类似项目成功的经验继承和积累下来，将B/S系统与C/S系统开发过程上的区别降低到仅显示控制的极小的层面。新的开发方式强调分层，规范出界面设计人员做什么，服务器编程人员做什么，这样就把页面和控制代码两个层面清晰的分开。 1.2. 背景 B/S模式系统以其易部署、易扩展、能够高度集成各种技术的特点，在公司产品线中占越来越大的比重，.Net、J2ee等技术的发展更是将B/S系统的开发和桌面应用程序开发的工程方法统一起来，突出服务器端技术，这些变革要求界面设计人员和服务器端编程人员可以应用更加科学的方法合作，团队的合作方式甚至决定了一个系统开发的成败。目前公司较多的服务器端编程人员仍然处于“后ASP 时代”的开发方式，表现为前台页面仍然与服务器代码高度的关联，带来的后果是重复建设、高昂的维护成本或失去控制的项目，没有充分的发挥出集成开发工具的优势。在以往的开发方式下界面设计侧重在静态页面的建设上，每个页面作为一个独立的模块来处理，在页面交互中则是程序员根据自己的习惯来控制，程序对个人的编程风格的依赖很强，这些在以往开发WEB站点的方式扩展到B/S系统有时是不正确的，甚至是背道而弛的，当然也不利于规模化的团队合作。 1.3. 定义 术语定义： 效果图：由界面设计人员设计的页面效果图，综合了概要设计的业务需要和整个站点的风格，它规定了页面布局上的每个细节。 容器：即HTML 标记的嵌套结构，如在表格->行->单元格内放置图片，那么可以认为单元格是放置图片的容器。 样式表：即级联式样式表CSS，它是W3C机构在HTML标记语言上扩展的格式语言。 非标准交互控件：是通过标准控件组合、扩展等方法以提高特定业务执行效率而进行封装的控件，或概括为用户根据以往的操作经验不能够直接领会出操作方式的交互控件。 2. 界面设计规范细则 总体目标 以规范作为基本原则，在此框架内进行合理的扩展和变化，将站点内的每个模块服从于整个站点，模块页面与“高内聚”的控制代码紧密的结合在一起，同时对应于应用程序基于系统的架构分析。 2.1. 通用原则 1 界面色彩要求：计算机屏幕的发光成像和普通视觉成像有很大的不同，应该注意这种
软件设计文档国家标准GB8567-88 一、文档编写标准化 在整个项目开发及使用过程中，应该有完备的文档支持，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性和可追溯性。 完备的文档对软件的开发及使用起了很大的作用。一般要求编写好十三种文档。 1、可行性分析报告 说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 2、项目开发计划 为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 3、软件需求说明书（软件规格说明书） 对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 4、概要设计说明书 是概要设计阶段的工作总结。主要包括功能分配、模块划分、程序总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理等，为详细设计作好准备。 5、详细设计说明书 着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 6、用户操作手册 详细描述了该软件的功能、性能和用户界面，使用该软件的具体方法等。 7、测试计划 包括测试内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。8、测试分析报告 测试计划的执行情况，对测试结果的分析，提出测试结论。 9、开发进度月报 按月提交的项目进展情况报告。包括计划与实际执行情况的对比、阶段成果、遇到的问题、解决的方法以及下一步的打算。 10、项目开发总结报告 项目完成以后，总结实际执行情况。如进度、成果、资源利用、成本和投入的人力，对项目开发作出评价，总结经验与教训。 11、软件维护手册 主要包括软件系统说明、程序模块说明、操作环境、支持软件说明、维护过程说明等。12、软件问题报告 记录软件出现问题的日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。13、软件修改报告 软件产品投入使用后，发现了需修改、更正的问题，要将出现的问题、修改意见、修改可能出现影响作出详细描述，提交审批。 二、可行性分析报告的撰写要求 可行性研究报告的编写内容要求如下： 1 引言
软件架构设计说明书 The final edition was revised on December 14th, 2020.
目录
1.引言 [对于由多个进程构成的复杂系统，系统设计阶段可以分为：架构设计（构架设计）、组件高层设计、组件详细设计。对于由单个进程构成的简单系统，系统设计阶段可以分为：系统概要设计、系统详细设计。本文档适用于由多个进程构成的复杂系统的构架设计。] [架构设计说明书是软件产品设计中最高层次的文档，它描述了系统最高层次上的逻辑结构、物理结构以及各种指南，相关组件（粒度最粗的子系统）的内部设计由组件高层设计提供。] [系统：指待开发产品的软件与硬件整体，其软件部分由各个子系统嵌套组成，子系统之间具有明确的接口； 组件：指粒度最粗的子系统； 模块：指组成组件的各层子系统，模块由下一层模块或函数组成；] [此文档的目的是： 1）描述产品的逻辑结构，定义系统各组件（子系统）之间的接口以及每个组件（子系统）应该实现的功能； 2）定义系统的各个进程以及进程之间的通信方式； 3）描述系统部署，说明用来部署并运行该系统的一种或多种物理网络（硬件）配置。对于每种配置，应该指出执行该系统的物理节点（计算机、网络设备）配置情况、节点之间的连 接方式、采用何种通信协议、网络带宽。另外还要包括各进程到物理节点的映射； 4）系统的整体性能、安全性、可用性、可扩展性、异常与错误处理等非功能特性设计； 5）定义该产品的各个设计人员应该遵循的设计原则以及设计指南，各个编程人员应该遵循的编码规范。 ] [建议架构设计工程师与组件设计工程师共同完成此文档。] [架构设计说明书的引言应提供整个文档的概述。它应包括此文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。]
系统页面设计规范V1.0 柯建树2013/07/30
目录 一、基础规范 01、系统宽、高度 02、文本框设计规范 (1)基础规范 (2)应用场景 03、页码设计规范 (1)普通页码翻页 (2)小型页码翻页 04、文字的编排与设计 (1)文字大小 (2)文字颜色 (3)文字行距 (4)英文字体规范 (5)文字链接 05、整齐的概念和应用 06、模块化表现 二、参考指南 01、页面修饰 (1)简单的光影效果
(2)质感的表现 (3)透明效果的应用 02、个性皮肤的应用 03、图标的统一使用 04、图标表意 05、表格
基础规范 一、系统宽、高度 显示器分辨率比例 在软件系统的使用上，遵循以大多数为视觉标准，同时遵循其他分辨率的显示效果。 软件系统一般采用满屏显示内容，宽度为100%，高度100%，在设计网页时，应与使用量最大的分辨率作为参照，即1024px*768px。在这个尺寸上，系统应当具有全部显示的能力。 不同浏览器，不同分辨率下网页第一屏最大可视区域
在IE下，宽度21表示17px的滚动条加上4px的浏览器边框，做到全部兼容，以小分辨率设计，目前我们系统的设计标准是1003*600。 即PS的设计文档1003px*600px，72dpi。 二、文本框设计规范 尺寸大小 (1)小型输入框应至少设置5个中文字符宽度，内边距（padding）上下3px，左右7px，单行不少于18px； (2)大型输入框应至少设置8个中文字符宽度，内边距（padding）上下3px，左右7px，单行不少于18px； (3)搜索框设计宽度至少设置8个中文字符宽度，内边距（padding）上下3px，左右7px，单行不少于18px，宽度不少于130px； 帮助信息 (1)帮助信息一般有二类，限定标签提示、标示性文字等； (2)“限定标签提示”一般放在搜索框的左面； (3)“标示性文字”可设置灰色（#CCCCCC）显示，点击输入框后提示文字消失。提示文字应简明扼要，文字一般用于内容、用途、搜索范围等对用户有真正帮助意义的提示，“请输入关键字”这样的提示不应出现。 1、2、
民用建筑设计规范
民用建筑设计规范 1 建筑地面形式 1.1 平坡式≤5% 1.2 台阶式≥8% 1.3 混合式 2 建设用地适宜规划坡度 2.1 住宅用地0。2%-25% 2.2 道路用地0。2%-8% 2.3 公共设施用地最小坡度0.2% 最大坡度20% 2.4 (基地地面坡度不应小于0.3%; 地面坡度大于8%时应分成台地) 3 消防通道宽度(高层建筑防火规范) 3.1 4M 4M 距建筑物>5M 4 建筑物层数的限制 4.1 托儿所、幼儿园的儿童用房 4.1.1 不准设于4层 4.1.2 大于等于4班需独立设置 4.1.3 小于3班可设于其它建筑物内, 但一定要有独立的出口 4.1.4 不准设置于地下室半地下室 4.2 高层的人流集中的用房----大会仪, 多功能厅, 舞厅等 4.2.1 宜设置在123层 4.2.2 设在其它楼层需满足 4.2.2.1 《=400m
4.2.2.2 两个出口 4.2.2.3 设置阻燃材料 4.2.2.4 自动灭火系统 4.3 中小学教学楼要求 4.3.1 小学教学楼少于四层 4.3.2 中学教学楼小于五层 4.4 住宅 4.4.1 16m距离室外地平需设电梯 4.5 学校宿舍 4.5.1 21m需设电梯 4.5.2 层高单层床2。8m,双层床3。6米最小3。4m 5 建筑层高要求 5.1 室内净高限制层高: 《住宅设计规范》2.0.10层高上下两层楼面或楼面与地面之间的垂直距离。室内净高: 《住宅设计规范》 2.0.11楼面或地面至上部楼板底面或吊顶底面之间的垂直距离。 3.6.1普通住宅层高不宜高于2.8m。*《住宅设计规范》3.6.2房、厅净高≥2.4m, 局部≥2.1m( 不超过面积的1/3) *《住宅设计规范》3.6.3利用坡屋顶内作臥室、厅, 其1/2面积净高应≥2.1m。3.6.4厨房、卫生间净高≥2.2m。3.6.5厨房、卫生间排水横管下净距≥1.9m且不影响门、窗。《托儿所、幼儿园建筑设计规范》3.1.5生活用房的室内净高不应低于: 活动室、寝室、乳儿室 2.8m, 音乐活动室3.6m。《中小学校建筑设计规范》5.2.2学校主要房间的
软件界面设计规范 1概要 界面设计中一定要保持界面的一致性。 一致性既包括使用标准的控件，也指使用相同的信息表现方法，如在字体、标签风格、颜色、术语、显示错误信息等方面确保一致。 界面力求简洁明了，保证系统功能设计的合理与明确，布局明确、交互操作合理、协调统一。功能要表现清楚，分类清晰有条理，避免过多的控件嵌套导致的视觉混乱；单一功能的操作目的明确，符合易用性原则，避免不必要的信息显示而对用户造成视觉干扰；力求操作简单，简单的功能一步完成，比较复杂的功能三步之内，复杂的功能操作使用操作向导来辅助客户完成。 2色调风格 2.1色调： 软件界面设计中常用的主色调包括：蓝色、红色、绿色、黑色 蓝色：运用的行业较为广泛，如通讯、电子、房产、钢铁、生产管理等行业大部分以蓝色为主色调来设计软件。 红色：在政府单位运用比较多。 绿色：一般运用于教育、医疗、农林等行业。 黑色：能源、石油、房地产行业有时候会用中性的黑色作为主色调。
表现区：通常用浅色，如：白色、淡灰、或者淡蓝之类，因为大面积的文字信息在浅色上便于长时间阅读，不容易形成视觉疲劳。 2.2风格： 软件界面的风格通常比较简约。不同行业，使用的环境不同稍有差异。 3登录界面 基本元素：logo、系统名称、输入框、提交按钮。如下： 4页面逻辑结构 功能页面功能页面 弹出页面弹出页面弹出页面
软件界面通常是上面这样的逻辑结构 首页：宏观预览各项设备管理数据，快速访问期望的数据功能 功能页面：查看某一功能模块的全部数据，查看某一对象的各类相关数据 弹出页面：填写和提交表单，对功能中的某一单项数据进行增加/删除/查询/修改/审核/打印/导出等功能操作。 5页面的基本属性 页面宽度：属性值为auto，最小值1024像素。默认状况下无横向滚动条。 注意：宽度、位置、边距为不可变数据 背景：页面整体为白色背景#FFFFFF 或者浅灰、浅蓝等，总之是非常接近白色的颜色。 注：白色为常用色值，对于特殊个性化页面可根据特殊要求变更色彩；背景色彩尽量少用饱和度高的颜色， 页面位置：居中 页面边距：上 0px；下 0px；左 0 px；右 0 px； 注意：有时候会专门设置一定数值的边距，这时通常 与模块间的间距相同，如上下左右都是5px。
广州润衡软件连锁有限公司软件架构设计文档 项目名称 软件架构设计文档 版本
修订历史记录
目录 1.简介5 1.1目的5 1.2范围5 1.3定义、首字母缩写词和缩略语5 1.4参考资料5 1.5概述5 2.整体说明5 2.1简介5 2.2构架表示方式5 2.3构架目标和约束5 3.用例视图6 3.1核心用例6 3.2用例实现6 4.逻辑视图6 4.1逻辑视图6 4.2分层6 4.2.1应用层6 4.2.2业务层7 4.2.3中间层7 4.2.4系统层7 4.3架构模式7 4.4设计机制7 4.5公用元素及服务7 5.进程视图7 6.部署视图7 7.实施视图8 7.1概述8 7.2层8 7.3部署8 8.数据视图8 9.大小和性能8
软件架构设计文档 10.质量8 11.其它说明8 12.附录A 指南8 13.附录B 规范9 14.附录C 模版9 15.附录D 示例9
软件架构设计文档 1.简介 软件构架文档的简介应提供整个软件构架文档的概述。它应包括此软件构架文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述 1.1目的 本文档将从构架方面对系统进行综合概述，其中会使用多种不同的构架视图来描述系统的各个方面。它用于记录并表述已对系统的构架方面作出的重要决策 本节确定此软件构架文档在整个项目文档中的作用或目的，并对此文档的结构进行简要说明。应确定此文档的特定读者，并指出他们应该如何使用此文档 1.2范围 简要说明此软件构架文档适用的范围和影响的范围 1.3定义、首字母缩写词和缩略语 本小节应提供正确理解此软件构架文档所需的全部术语的定义、首字母缩写词和缩略语。这些信息可以通过引用项目词汇表来提供 1.4参考资料 本小节应完整地列出此软件构架文档中其他部分所引用的所有文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供 1.5概述 本小节应说明此软件构架文档中其他部分所包含的内容，并解释此软件构架文档的组织方式 2.整体说明 2.1简介 在此简单介绍软件架构的整体情况，包括用例视图、逻辑视图、进程视图、实施视图和部署视图的简单介绍。另外，简要介绍各种视图的作用和针对的用户 2.2构架表示方式 本节说明当前系统所使用的软件构架及其表示方式。还会从用例视图、逻辑视图、进程视图、部署视图和实施视图中列出必需的那些视图，并分别说明这些视图包含哪些类型的模型元素 2.3构架目标和约束 本节说明对构架具有某种重要影响的软件需求和目标，例如：安全性、保密性、市售产品的使用、可移植
软件用户界面设计规范 1.导言 1.1 目的 为开发人员提供界面设计和开发的指南，引导开发人员设计简洁美观的用户界面； 1.2 适用范围 适用于xxxxxx。 2.软件界面设计的重要性 2.1 发展趋势 软件用户界面的发展经历了从简单到复杂、从低级到高级的过程，用户界面在软件系统中的价值比重越来越高。 2.2 开发竞争 得益于互联网的发展和普及，软件开发的技术门槛在不断下降，大部分软件企业的技术手段也趋向于雷同，“软件设计”变得越来越重要。当大家都掌握了相似的技术和需求信息后，企业之间的开发竞争“比的就是设计”。 –软件用户界面设计要综合考虑“易用性设计”、“艺术设计”和“技术实现”，很有挑战性。 2.3 用户挑剔 用户界面在很大程度上影响着软件的命运，因为广大用户对软件的评价主要来源于他们操作用户界面的感受。同类软件越多，选择余地越大，购买者对软件
用户界面就越挑剔。 3.软件界面设计的现状、问题及原因 3.1 不容乐观的现状 尽管国内有很多技术出色、聪明过人的软件工程师，但是不少人开发出来的软件产品却既难用又难看，客户很不满意。导致经常要修改软件的用户界面，造成极大的生产力浪费。 到处是用户界面设计缺陷： –界面措辞含糊，甚至有错别字。连简单的消息框都设计不好，可能存在文不对题的语病。 –界面布局混乱，缺乏逻辑，凡是能放的东西都堆集上去，让用户不知从何下手。–没有防错处理，不对用户输入的数据进行检验，不根据用户的权限自动隐藏或者禁用某些功能。执行破坏性的操作之前，不提醒用户确认。 –不提供进度条、动画来反映正在进行的比较耗时间的过程，对于重要的操作也不返回结果，让用户干着急。 3.2 问题和原因之一 由于国内没有开设软件界面设计的课程，大家对这部分知识没有深刻的意识，只是在工作中凭着个人的经验与感觉设计软件的用户界面，这样产生的界面往往得不到大众用户的认可。 3.3 问题及原因之二 开发人员在设计用户界面方面不仅存在先天的教育缺陷，更加糟糕的是还常常“错位”的毛病。他以为只要自己感觉用户界面漂亮、使用起来方便，那么用户也一定会满意。 3.4 问题及原因之三
施工图设计规范
前言 在室内设计工作的过程中，施工图的绘制是表示设计者设计意图的重要手段之一，是设计者与各相关专业之间交流的标准化语言，是控制施工现场能否充分正确理解消化并实施设计理念的一个重要环节，是衡量一个设计团队的设计管理水平是否专业的一个重要标准。专业化、标准化的施工图操作流程规范不但能够帮助设计者深化设计内容，完善构思想法，同时面对大型公共设计项目及大量的设计定单行之有效的施工图规范与管理亦可帮助设计团队在保持设计品质及提高工作效率方面起到积极有效的作用。 本书是以制图标准为基础，结合具体工程实例书写而成。书中内容更贴近于实际工程，对于图样画法的基础与理论读者可参见相关专业书籍。书中除涉及施工图构成的一些基本元素外，还对施工图的前期规划，绘制过程中的深化设计，以及施工图纸如何与施工现场衔接，和后期竣工图文件归档均作了一定的描述。另外书中还针对计算机绘图方式与制图标准的结合作了具体的描述，特别是模型空间与布局空间相互转换的绘图方法不但方便平面图的修改，提高工作效率，还能够在保证图纸的一致性以及图层管理，比例输出等方面起到重要作用。书中所附光盘内图纸均含标准图层。符号在布局空间内按1：1比例绘制，所制成的标准图按图幅规格在布局空间内可直接调用。图例也分别在模型空间与布局空间内按比例绘制，均可直接调用。写此书的目的一方面的对于以往学习工作过程中积累的关于室内设计施工图方面的知识经验作一次较详尽的梳理，另一方面希望起到抛砖引玉的作用，把自己一些浅薄的
认知以书面的形式与同道做一个交流，希望大家批评指正，以期引起专家同道对室内设计专业制图更深层次的关注。 目录 一、图纸幅面规格 二、符号的设置 三、材质图例的设置 四、尺寸标注与文字标注的设置 五、线型与笔宽的设置 六、电脑图层的设置 七、比例的设置 八、图面构图的设置 九、施工图编制的顺序 十、图表 十一、平、立、剖面图及节点大样图的绘制及相关标准 十二、施工图在各设计阶段应注意的事项 十三、施工图与现场深化设计 十四、施工图的归档与分类 十五、关于布局空间与模型空间在实际绘图中的应用 十六、施工图工程实例 宾馆类：天骄宾馆 办公空间：商务部会议室
软件界面设计规范_V1.0 1概要 界面设计中一定要保持界面的一致性。 一致性既包括使用标准的控件，也指使用相同的信息表现方法，如在字体、标签风格、颜色、术语、显示错误信息等方面确保一致。 界面力求简洁明了，保证系统功能设计的合理与明确，布局明确、交互操作合理、协调统一。功能要表现清楚，分类清晰有条理，避免过多的控件嵌套导致的视觉混乱；单一功能的操作目的明确，符合易用性原则，避免不必要的信息显示而对用户造成视觉干扰；力求操作简单，简单的功能一步完成，比较复杂的功能三步之内，复杂的功能操作使用操作向导来辅助客户完成。 2色调风格 2.1色调： 软件界面设计中常用的主色调包括：蓝色、红色、绿色、黑色 蓝色：运用的行业较为广泛，如通讯、电子、房产、钢铁、生产管理等行业大部分以蓝色为主色调来设计软件。 红色：在政府单位运用比较多。 绿色：一般运用于教育、医疗、农林等行业。 黑色：能源、石油、房地产行业有时候会用中性的黑色作为主色调。 表现区：通常用浅色，如：白色、淡灰、或者淡蓝之类，因为大面积的文字信息在浅色上便于长时间阅读，不容易形成视觉疲劳。
2.2风格： 软件界面的风格通常比较简约。不同行业，使用的环境不同稍有差异。 3登录界面 基本元素：logo、系统名称、输入框、提交按钮。如下： 4页面逻辑结构 软件界面通常是上面这样的逻辑结构 首页：宏观预览各项设备管理数据，快速访问期望的数据功能 功能页面：查看某一功能模块的全部数据，查看某一对象的各类相关数据 弹出页面：填写和提交表单，对功能中的某一单项数据进行增加/删除/查询/修改/审核/打印/导出等功能操作。
软件设计规范 概述 软件设计是把需求转化为软件系统的最重要的环节，系统设计的优劣在根本上决定了软 件系统的质量。 在此，主要阐述软件系统设计的5个核心内容：体系结构设计、用户界面设计、数据库设计、模块设计、数据结构和算法设计。旨在帮助开发人员搞清楚“设计什么”以及“如何 设计”。 一般把设计过程划分为两个阶段：概要设计阶段和详细设计阶段，如下所示： *概要设计阶段的重点是体系结构设计。 *详细设计阶段的重点是用户界面设计、数据库设计、模块设计、数据结构与算法设计 等。 可根据项目的情况进行文档裁减和过程合并，如项目开发过程只有一个设计阶段和设计 文档。 体系结构 体系结构如同人的骨架。如果某个家伙的骨架是猴子，那么无论怎样喂养和美容，这家 伙始终都是猴子，不会成为人。 由此可见，体系结构乃是系统设计的重中之重。 目前业界比较流行的软件结构模式有C/S（客户/服务器）、B/S（BROWSE/SERVER）、层次结构（上下级层次结构、顺序相邻的层次结构、含中间件的层次结构） 体系结构设计原则 ● 合适性 即体系结构是否适合于软件的“功能性需求”和“非功能性需求”。高水平的设计师高就高在“设计出恰好满足客户需求的软件，并且使开发方和客户方获取最大的利益，而不是 不惜代价设计出最先进的软件。 ● 结构稳定性 详细设计阶段的工作如用户界面设计、数据库设计、模块设计、数据结构与算法设计等等，都是在体系结构确定之后开展的，而编程和测试则是更后面的工作，因此体系结构应在 一定的时间内保持稳定。
软件开发最怕的就是需求变化，但“需求会发生变化”是个无法逃避的现实。人们希望在需求发生变化时，最好只对软件做些皮皮毛毛的修改，可千万别改动软件的体系结构。如果当需求发生变化时，程序员不得不去修改软件的体系结构，那么这个软件的系统设计是失 败的。 高水平的设计师应当能够分析需求文档，判断出哪些需求是稳定不变的，哪些需求是可能变动的。于是根据那些稳定不变的需求设计体系结构，而根据那些可变的需求设计软件的 “可扩展性”。 ● 可扩展性 可扩展性是指软件扩展新功能的容易程度。可扩展性越好，表示软件适应“变化”的能 力越强。 可扩展性越来越重要，这是由现代软件的商业模式决定的： *社会的商业越发达，需求变化就越快。需求变化必将导致修改（或者扩展）软件的功能，现代软件的规模和复杂性要比十年前的大得多（对比一下操作系统的变化就明白了），如果软件的可扩展性比较差的话，那么修改（或者扩展）功能的代价会很高。 *现代软件产品通常采用“增量开发模式”，开发商不断地推出软件产品的新版本，从而不断地获取增值利润。如果软件的可扩展性比较差的话，每次开发新版本的代价就会很高。虽然开发商抓住了商机，但却由于设计水平差而导致没有赚取多少利润，真是要活活气死。 ● 可复用性 由经验可知，通常在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般地可以相信成熟的东西总是比较可靠的（即具有高质量），而大量成熟的工作可以通过 复用来快速实现（即具有高生产率）。 可复用性是设计出来的，而不是偶然碰到的。要使体系结构具有良好的可复用性，设计师应当分析应用域的共性问题，然后设计出一种通用的体系结构模式，这样的体系结构才可 以被复用。 用户界面设计 为了提高用户界面的易用性和美观程度，总结了十个设计原则。用于提高易用性的界面 设计原则有8个： *用户界面适合于软件的功能 *容易理解 *风格一致
Xxx系统 详细设计说明书 (内部资料请勿外传) 编写：日期：检查：日期：审核：日期：批准：日期： XX公司 版权所有不得复制 文档变更记录
目录 1. 引言 (5) 1.1 编写目的和范围 (5) 1.2 术语表 (5) 1.3 参考资料 (5) 1.4 使用的文字处理和绘图工具 (5) 2. 全局数据结构说明 (7) 2.1 常量 (7) 2.2 变量 (8) 2.3 数据结构 (8) 3. 模块设计 (9) 3.1 用例图 (9) 3.2 功能设计说明 (10) 3.2.1 模块1 (10) 3.2.2 模块2 (11) 4. 接口设计 (12) 4.1 内部接口 (12) 4.2 外部接口 (12) 4.2.1 接口说明 (12) 4.2.2 调用方式 (12) 5. 数据库设计 (12) 6. 系统安全保密设计 (12) 6.1 说明 (12) 6.2 设计 (12) 6.2.1 数据传输部分 (12) 6.2.2 IP过滤分部 (13) 6.2.3 身份验证部分 (13) 7. 系统性能设计 (13) 8. 系统出错处理 (13)
1.引言 1.1背景 此文档的背景 1.2编写目的和范围 说明写这份详细设计说明书的目的。 本详细设计说明书编写的目的是说明程序模块的设计考虑，包括程序描述、输入/输出、算法和流程逻辑等，为软件编程和系统维护提供基础。本说明书的预期读者为系统设计人员、软件开发人员、软件测试人员和项目评审人员。 1.3术语表 1.4参考资料 列出有关资料的名称、作者、文件编号或版本等。参考资料包括： a．需求说明书、架构设计说明书等； b．本项目的其他已发表的文件； 1.5使用的文字处理和绘图工具 文字处理软件：[编写设计文档使用的文字处理软件，如RedOffice ] 绘图工具：[使用的UML工具，如Rose、Jude、Visio]
Web应用界面设计规范（Design Specific ation for Web UI） 主讲人：ARay 目录： 一、软件界面规范的重要性及其目的 二、用户体验为何如此重要 三、Web规范体系介绍 四、界面设计开发流程 五、应该遵循的基本原则 六、界面设计规范 一、软件界面规范的重要性及其目的 ①使最终设计出来的界面风格一致化，开发编码人员相互之间开发更轻松，遵循统一的操作规范，以标准化的方式设计界面，提高工作效率。减少和改变责任不明，任务不清和由此产生的信息沟通不畅、反复修改、重复劳动、效率低下的现象。 ②产品设计通过规范的方式来达到以用户为中心的目的。 二、用户体验为何如此重要 ①日常生活中的遭遇 X员工悲惨的一天： 早晨起来，发现闹钟没有按原先设定响起来。 一边烧水，一边穿衣服，临走前去喝水却发现水还没有烧开。 到了地铁站，发现公交卡没有钱了。 无奈之下只能去排队买票。 排了3趟地铁，终于到公司了，但是你却迟到了。 结果：尽管你已经非常努力，但是你还是迟到了。 那么，让我们看看这一连串 的倒霉事， 是什么让我们如此狼狈？ ②什么是用户体验
用户体验（user experience）是以用户为中心的设计中最重要的一个部分，强调的是过程，是软件对用户行为产生的反应与用户期待值要尽可能的一致。 糟糕的用户界面表现： 表现一：过分使用各种奇形怪状、五颜六色的控件。 表现二：界面元素比例失调。比如按钮巨大无比，其尺寸甚至超过显示重要内容的文本框的界面。 表现三：界面元素凌乱。比如说，按钮和文本框摆放地点随意，该对齐的控件对不齐。 表现四：违背使用习惯。你按F1，它没有弹出帮助，却执行了一件绝对出乎你意料的动作。表现五：消息框信息含糊、混乱。比如软件弹出一个消息框。把原本“确定”和“取消”写成为“是”和“否”，让用户不知道什么意思。 表现六：还有一种糟糕的用户界面，乍一看很厉害，实际上完全是缺乏规划的结果。这种
SUCHNESS 硬件设计文档 型号：GRC60定位终端 编号： 机密级别：绝密机密内部文件 部门：硬件组 拟制：XXXX年 XX月 XX日 审核：年月日 标准化：年月日 批准：年月日
文档修订历史记录
目录 1系统概述 (3) 2系统硬件设计 (3) 2.1硬件需求说明书 (3) 2.2硬件总体设计报告 (3) 2.3单板总体设计方案 (3) 2.4单板硬件详细设计 (3) 2.5单板硬件过程调试文档 (3) 2.6单板硬件测试文档 (4) 3系统软件设计 (4) 3.1单板软件详细设计 (4) 3.2单板软件过程调试报告 (4) 3.3单板系统联调报告 (4) 3.4单板软件归档详细文档 (4) 4硬件设计文档输出 (4) 4.1硬件总体方案归档详细文档 (4) 4.2硬件信息库 (5) 5需要解决的问题 (5) 6采购成本清单 (5)
1系统概述 2系统硬件设计 2.1、硬件说明书 硬件需求说明书是描写硬件开发目标，基本功能、基本配置，主要性能指标、运行环境，约束条件以及开发经费和进度等要求，它的要求依据是产品规格说明书和系统需求说明书。它是硬件总体设计和制订硬件开发计划的依据，具体编写的内容有：系统工程组网及使用说明、硬件整体系统的基本功能和主要性能指标、硬件分系统的基本功能和主要性能指标以及功能模块的划分等 2.2、硬件总体设计报告 硬件总体设计报告是根据需求说明书的要求进行总体设计后出的报告，它是硬件详细设计的依据。编写硬件总体设计报告应包含以下内容：系统总体结构及功能划分，系统逻辑框图、组成系统各功能模块的逻辑框图，电路结构图及单板组成，单板逻辑框图和电路结构图，以及可靠性、安全性、电磁兼容性讨论和硬件测试方案等 2.3、单板总体设计方案 在单板的总体设计方案确定后出此文档，单板总体设计方案应包含单板版本号，单板在整机中的位置、开发目的及主要功能，单板功能描述、单板逻辑框图及各功能模块说明，单板软件功能描述及功能模块划分、接口简单定义与相关板的关系，主要性能指标、功耗和采用标准 2.4、单板硬件详细设计 在单板硬件进入到详细设计阶段，应提交单板硬件详细设计报告。在单板硬件详细设计中应着重体现：单板逻辑框图及各功能模块详细说明，各功能模块实现方式、地址分配、控制方式、接口方式、存贮器空间、中断方式、接口管脚信号详细定义、时序说明、性能指标、指示灯说明、外接线定义、可编程器件图、功能模块说明、原理图、详细物料清单以及单板测试、调试计划。有时候一块单板的硬件和软件分别由两个开发人员开发，因此这时候单板硬件详细设计便为软件设计者提供了一个详细的指导，因此单板硬件详细设计报告至关重要。尤其是地址分配、控制方式、接口方式、中断方式是编制单板软件的
软件界面设计规范 1.界面规范 .总体原则以用户为中心。 设计由用户控制的界面，而不是界面控制用户。清楚一致的设计。所有界面的风格保持一致，所有具有相同含义的术语保持一致，且易于理解拥有良好的直觉特征。以用户所熟悉的现实世界事务的抽象来给用户暗示和隐喻，来帮助用户能迅速学会软件的使用。较快的响应速度。简单且美观。 .原则详述 1.2.1.用户控制用户界面设计的一个重要原则是用户应该总是感觉在控制软件而不是感觉被软件所控制。操作上假设是用户--而不是计算机或软件--开始动作。用户扮演主动角色，而不是扮演被动角色。在需要自动执行任务时，要以允许用户进行选择或控制它的方式来实现该自动任务。提供用户自定义设置。因为用户的技能和喜好各不相同，因此他们必须能够个性化界面的某些方面。Windows为用户提供了对许多这方面的访问。您的软件应该反应不同的系统属性--例如颜色、字体或其他选项的用户设置。采取交互式和易于感应的窗口，尽量避免使用模态对话框，而使用"非模式"辅助窗口。"模式"是一种状态，它排除一般的交互，或者限制用户只能进行特定的交互。当最好使用一个模式或该模式只是可替换的设计时--例如，用于在一个绘图程序中选定一个特定感觉--请确保该模式是显然的、可见的，是一个明确的用户选定的结果，并且容易取消。在后台运行长进程时，保持前台式交互。例如，当正在打印一个文档，即使该文档不能被改变，用户也应该可以最小化该窗口。谅解。用户喜欢探索一个界面，并经常从尝试和错误中学习。一个有效的界面允许交互式的发现，它只提供一组合适的选择，并在用户可能破坏系统或数据的情况时发出警告。如果可行，还应提供可逆转或可还原的操作。即使在设计得很好得界面中，用户也可能犯错误。这些错误既可以是物理上得（偶然地指向了错误的命令或数据），也可以是逻辑上的（对选定哪一个命令或哪些数据做出了错误的决定）。有效的设计避免很可能导致错误的情况。它还包容潜在的用户错误，并且使用户易于还原。 1.2.2.清楚一致的设计一致允许用户将已有的知识传递到新的任务中，更快地学习新事物，并将更多的注意力集中在任务上。这是因为他们不必花时间来尝
软件工程文档模板 目录 1.范围 (1) 2.总体要求 (1) 2.1总体功能要求 (1) 2.2软件开发平台要求 (1) 2.3软件项目地开发实施过程管理要求 (2) 2.3.1软件项目实施过程总体要求 (2) 2.3.2软件项目实施变更要求 (2) 2.3.3软件项目实施里程碑控制 (2) 3.软件开发 (3) 3.1软件地需求分析 (3) 3.1.1需求分析 (3) 3.1.2需求分析报吿地编制者 (4) 3.1.3需求报吿评审 (4) 3.1.4需求报吿格式 (4) 3.2软件地概要设计 (4) 3.2.1概要设计 (4) 3.2.2编写概要设计地要求 (4) 3.2.3概要设计报吿地编写者 (4) 3.2.4概要设计合需求分析、详细设计之间地关系合区别 (4) 3.2.5概要设计地评审 (4) 3.2.6 概要设计格式 (4) 3.3软件地详细设计 (5) 3.3.1详细设计 (5) 3.3.2特例 (5) 3.3.3详细设计地要求 (5) 3.3.4数据库设计 (5) 3.3.5详细设计地评审 (5) 3.3.6详细设计格式 (5) 3.4软件地编码 (5) 3.4.1软件编码 (5) 3.4.2软件编码地要求 (5) 3.4.3编码地评审 (6) 3.4.4编程规范及要求 (6) 3.5软件地测试 (6)
3.5.1软件测试 (6) 3.5.2测试计划 (6) 3.6软件地交付准备 (6) 361交付清单 (6) 3.7软件地鉴定验收 (7) 3.7.1软件地鉴定验收 (7) 3.7.2验收△员 (7) 3.7.3验收具体内容 (7) 3.7.4 软件验收测试大纲 (7) 3.8培训 (7) 3.8.1系统应用培训 (7) 3.8.2系统管理地培训（可选） (8) 附录A 软件需求分析报吿文档模板 (9) 附录b 软件概要设计报吿文档模板 (21) 附录C 软件详细设计报吿文档模板 (33) 附录D软件数据库设计报吿文档模板 (43) 附录E 软件测试（验收）大纲..................................... 错误！未定义书签。5
软件界面设计规 1.界面规 1.1.总体原则以用户为中心。 设计由用户控制的界面，而不是界面控制用户。清楚一致的设计。所有界面的风格保持一致，所有具有相同含义的术语保持一致，且易于理解拥有良好的直觉特征。以用户所熟悉的现实世界事务的抽象来给用户暗示和隐喻，来帮助用户能迅速学会软件的使用。较快的响应速度。简单且美观。 1.2.原则详述 1.2.1.用户控制用户界面设计的一个重要原则是用户应该总是感觉在控制软件而不是感觉被软件所控制。操作上假设是用户--而不是计算机或软件--开始动作。用户扮演主动角色，而不是扮演被动角色。在需要自动执行任务时，要以允许用户进行选择或控制它的方式来实现该自动任务。提供用户自定义设置。因为用户的技能和喜好各不相同，因此他们必须能够个性化界面的某些方面。Windows为用户提供了对许多这方面的访问。您的软件应该反应不同的系统属性--例如颜色、字体或其他选项的用户设置。采取交互式和易于感应的窗口，尽量避免使用模态对话框，而使用"非模式"辅助窗口。"模式"是一种状态，它排除一般的交互，或者限制用户只能进行特定的交互。当最好使用一个模式或该模式只是可替换的设计时--例如，用于在一个绘图程序中选定一个特定感觉--请确保该模式是显然的、可见的，是一个明确的用户选定的结果，并且容易取消。在后台运行长进程时，保持前台式交互。例如，当正在打印一个文档，即使该文档不能被改变，用户也应该可以最小化该窗口。谅解。用户喜欢探索一个界面，并经常从尝试和错误中学习。一个有效的界面允许交互式的发现，它只提供一组合适的选择，并在用户可能破坏系统或数据的情况时发出警告。如果可行，还应提供可逆转或可还原的操作。即使在设计得很好得界面中，用户也可能犯错误。这些错误既可以是物理上得（偶然地指向了错误的命令或数据），也可以是逻辑上的（对选定哪一个命令或哪些数据做出了错误的决定）。有效的设计避免很可能导致错误的情况。它还包容潜在的用户错误，并且使用户易于还原。 1.2.2.清楚一致的设计一致允许用户将已有的知识传递到新的任务中，更快地学习新事物，并将更多的注意力集中在任务上。这是因为他们不必花时间来尝
UI设计(流程/界面)规范 一：UI设计基本概念与流程 1.1 目的 规范公司UI设计流程，使UI设计师参与到产品设计整个环节中来，对产品的易用性进行全流程负责，使UI设计的流程规范化，保证UI设计流程的可操作性。 1.2范围 l 界面设计 l 此文档用于界面设计,本文档的读者对象是项目管理人员、售前服务人员、UI界面设计人员、界面评审人员和配置测试人员。 1.3 概述 UI设计包括交互设计，用户研究，与界面设计三个部分。基于这三部分的UI设计流程是从一个产品立项开始，UI设计师就应根据流程规范，参与需求阶段、分析设计阶段、调研验证阶段、方案改进阶段、用户验证反馈阶段等环节，履行相应的岗位职责。UI设计师应全面负责产品以用户体验为中心的UI设计，并根据客户（市场）要求不断提升产品可用性。本规范明确规定了UI设计在各个环节的职责和要求，以保证每个环节的工作质量。 1.4 基本介绍 A、需求阶段 软件产品依然属于工业产品的范畴。依然离不开3W的考虑（Who,where,why.）也就是使用者，使用环境，使用方式的需求分析。所以在设计一个软件产品之前我们应该明确什么人
用(用户的年龄，性别，爱好，收入，教育程度等)。什么地方用（在办公室/家庭/厂房车间/公共场所）。如何用（鼠标键盘/遥控器/触摸屏）。上面的任何一个元素改变结果都会有相应的改变。 除此之外在需求阶段同类竞争产品也是我们必须了解的。同类产品比我们提前问世，我们要比他作的更好才有存在的价值。那么单纯的从界面美学考虑说哪个好哪个不好是没有一个很客观的评价标准的。我们只能说哪个更合适，更合适于我们的最终用户的就是最好的。B、分析设计阶段 通过分析上面的需求，我们进入设计阶段。也就是方案形成阶段。我们设计出几套不同风格的界面用于被选。 C、调研验证阶段 几套风格必须保证在同等的设计制作水平上，不能明显看出差异，这样才能得到用户客观真实的反馈。 测试阶段开始前我们应该对测试的具体细节进行清楚的分析描述。 调研阶段需要从以下几个问题出发： 用户对各套方案的第一印象 用户对各套方案的综合印象 用户对各套方案的单独评价 选出最喜欢的 选出其次喜欢的 对各方案的色彩，文字，图形等分别打分。 结论出来以后请所有用户说出最受欢迎方案的优缺点。 所有这些都需要用图形表达出来，直观科学。