搜索
文档标识：当前版本：1.0当前状态：草稿发布日期：2009-1-1发布ü修改历史日期版本作者修改内容评审号变更控制号目录1引言...31.1编写目的...31.2项目背景...31.3术语定义...31.4参考资料...32综合描述...32.1产品介绍...32.2目标范围...32.3用户特性...42.4约定假设...43用户需求（可剪裁）...43.1总体需求（可剪裁）...43.2内容需求（可剪裁）...54功能需求...54.1数据需求（可剪裁）...54.2接口需求（可剪裁）...64.3权限控制需求（可剪裁）...64.3.1系统安全要求（软硬件）...64.3.2用户角色...64.3.3角色权限控制...65非功能需求...65.1用户界面需求（可剪裁）...65.2性能需求（可剪裁）...75.3压力需求（可剪裁）...75.4主流技术应用需求（可剪裁）...75.5安全需求（可剪裁）...75.6故障处理需求（可剪裁）...75.7环境需求（可剪裁）...75.8产品质量需求...75.9其他需求（可剪裁）...86需求优先级...87附加说明（可剪裁）...81引言1.1编写目的本节描述编写该用户需求说明书的目的，并指出预期的读者。1.2项目背景本节描述用户需求说明书中所定义的产品的背景和起源，以及同其他系统或其他机构的基本相互关系等。当在已有的系统上进行特性开发时，如果新特性与已有系统的特性之间存在关系，则应在本节说明其相互之间的关系。1.3术语定义本节可列出本文件中用到的专门术语的定义、外文首字母组词的原词组等。1.4参考资料本节列举编写用户需求说明书时所参考的资料或其他资源，这可能包括用户合同、公司规范、技术书籍等。在这里应该给出详细的信息，包括资料名称、版本号、作者、日期、出版单位或资料来源，以方便读者查阅这些文献，可用以下格式表示：资料名称版本号作者日期出版单位/资料来源备注2综合描述2.1产品介绍本节简要描述产品的特性。2.2目标范围本节简要描述产品的应用目标、作用范围等。2.3用户特性本节可能包括本产品各类最终用户的特点，如操作、维护等人员的知识水平和技术专长等，也可能包括用户组织关系结构图以及组织、部门、岗位的隶属关系与职能。这将是后续工作的重要依赖条件。2.4约定假设本节列举出在对软件用户需求说明书中影响需求陈述的假设因素（与已知因素相对立）。这可能包括将要使用的组件、特殊的用户界面设计约定、产品预期使用频度等。如果这些假设不正确、不一致或被更改，就会使项目受到影响。3用户需求（可剪裁）每一项需求必须进行唯一标识，并给出该项需求的优先级。需求优先级的定义，一般需要根据用户意见结合商业价值、交付成本、交付日期、复杂程度、风险等因素来进行考虑。高优先级需求表示本系统产品中必须实现的需求，中优先级需求表示必须但是根据时间情况有可能会被推迟到下一版本的产品中去实现的需求，低优先级需求表示如果没有充足的时间或资源就可以被放弃的需求。具体描述请参考《需求跟踪矩阵》！需求编号方式可以根据项目实际情况进行自定义，也可以采用“项目代号”＋“-”＋“R”＋“需求类型”＋“序号”的形式。其中“R”表示Requirement，“需求类型”可用下表表示，“序号”以自然数表示，位数不限。需求类型英文名称中文名称FFunction功能PPerformance性能DData数据UUserInterface用户界面IInterface接口SSecurity安全MMalfunction故障处理OOther其他示例：OLTP-RI5表示为OLTP项目的第5项用户界面需求。3.1总体需求（可剪裁）描述项目总体需求，简述项目特性等内容。3.2内容需求（可剪裁）按照内容（如产品包、组件等）展开用户需求。4功能需求详细列出系统各模块/主题/子系统的功能需求。提示：将功能性需求先粗分再细分，下表中的FeatureA,FunctionA.1等符号应当被替换成有含义的名称（可考虑加上需求的优先级别）。在描述中要简要阐述该需求项将依赖于哪些需求项。功能类别标识符子功能名称描述FeatureAFunctionA.1…FeatureBFunctionB.1…FeatureCFunctionC.1…产品包提示：针对本功能进行说明描述（包含其要做什么、什么流程、相关的财务、特殊要求、需要的数据等），可以采用相关的图表来更容易地表达信息。①功能描述：描述需求项的功能。②业务描述：描述该需求项的业务流程、相关的对象的状态、涉及到的业务角色等。③数据描述：描述需求项的数据项、数据精度、输出的格式等要求。④输入描述：描述该需求项的相关依赖（包括业务依赖和需求项的依赖）和输入条件。⑤输出描述：描述需求功能执行后，相应的输出产物、数据、对象状态等。4.1数据需求（可剪裁）详细列出系统的数据需求，可能包括数据类型、载体、格式、数值范围、精度、规模等需求。4.2接口需求（可剪裁）详细列出系统的接口需求，可能包括与其他系统之间的接口、数据通信协议、内部模块之间的接口等需求。4.3权限控制需求（可剪裁）4.3.1系统安全要求（软硬件）提示：说明对本产品系统的功能方面的安全的要求，如用户名密码加密、系统访问安全等。4.3.2用户角色提示：阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。角色例如：系统管理员（SuperAdmin-LowestLevel）内部操作管理员（OperatorAdmin-MidLevel）外部操作管理员（ResellerAdmin-MidhighLevel）终端用户管理员（UserAdmin–HighLevel）角色名称职责描述4.3.3角色权限控制提示：描述上述各用户角色的权限控制要求5非功能需求5.1用户界面需求（可剪裁）详细列出系统的界面需求，可能包括图形用户界面标准、产品系统风格、屏幕布局或解决方案的限制、快捷键、错误信息显示标准等。5.2性能需求（可剪裁）详细列出系统的性能需求，可能包括时间特性要求、软件灵活性、容错性、容量需求等。提示：说明本产品的整体性能必须达到程度，特别是一些关键功能点。5.3压力需求（可剪裁）提示：说明本产品使用必须满足的压力峰值要求5.4主流技术应用需求（可剪裁）提示：说明本产品需要使用何种主流技术。如果不清楚或不明白可以不填后面由项目开发组提出技术方案再进行选择。5.5安全需求（可剪裁）详细列出系统的安全需求，可能包括安全设施需求和安全性需求等。安全设施需求是指产品使用过程中可能发生的，与损失、破坏或危害相关的需求。定义必须采取的安全保护或动作，还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或准则。一个安全设施需求的范例如下：“如果油箱的压力超过了规定的最大压力的95%，那么必须在1秒钟内终止操作”。安全性需求是指与系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求。明确产品必须满足的安全性或保密性策略。一个安全性需求的范例如下：“每个用户在第一次登录后，必须更改他的最初登录密码。最初的登录密码不能重用。5.6故障处理需求（可剪裁）详细列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。5.7环境需求（可剪裁）详细列出各种环境需求，可能包括开发环境、测试环境、运行环境等需求。具体内容可能涉及到网络、服务器、数据库、前台、测试工具等的软件、硬件方面。5.8产品质量需求描述产品预期达到的质量要求，包括多个质量特性，以下的质量属性仅为参考，各项目可以根据需要补充或删除某些质量特性。主要质量属性详细需求正确性可靠性健壮性性能、效率易用性清晰性安全性可扩展性兼容性可移植性…5.9其他需求（可剪裁）详细列出在前文中没有包括的所有需求，可能包括用户对可维护性、可补充性、易读性、可移植性等方面的特殊需求，或者国际化或法律上的需求。6需求优先级根据用户的需要程度，初步列出各需求的优先级，参见《需求跟踪矩阵》。7附加说明（可剪裁）描述该用户需求说明书采集的方法，如访谈、现场体验、惯例综合等。参见的竞争产品和相应的用户需求获取文档，如用户故事、需求采集表等类似文档。Download:template-requirement-analysis.rarREF:软件设计文档国家标准(GB8567--88)GB8567——88产品设计体会（6031）产品新首页诞生记2009年夏天，“e网打进”的产品portal做了一个改版项目，叫“变脸”，回想一下，我们正是按照：“战略、范围、结构、框架、表现”的顺序做的，设计师也从头到尾很充分的参与其中。很快半年过去了，产品、公司、团队里很多事情都发生了变化，不过对于这个项目来说，还是有些可以分享一下的东西……这个项目的缘起是为了统一公司几个产品的portal风格，但我们希望能在老板给出的这个目标下找到“变脸”的更多价值。于是项目开始后我查看了portal页面的访问情况，分析了用户场景，画了下图。产品portal的用户场景在“e网打进”刚上市之时，portal页面只是付费用户的登录入口，有一个简单的填写账号密码的输入框，并没有额外的商业价值，但随着产品的成长，渐渐有了点名气，当时每个月有几万UV（UniqueVisitor，独立访客），其中：非付费用户的访客占大多数，超过80%，短期内相当稳定；付费用户约20%弱，目的其实很明确——登录，很少会东张西望看其他内容；极少数的经销商，有个入口登录后台也就行了。非付费用户的访客访问portal的行为逐渐增多，他们通过各种途径知道了“e网打进”，可能是通过搜索引擎，可能是听到朋友说起，有了点兴趣，但是到了这个页面以后，看不到产品介绍、不知道如何购买，虽然portal本身使用了“e网打进”，服务部门的同学可以及时与访客交流，但页面内容的缺失导致流失率依然很高。有了上述分析，很直接的想法就是portal要转型，重点满足普通访客，促进他们转化为e的付费用户，所以我们加重了营销相关内容，力求创造更多的销售机会，也就是所谓的“潜在用户”。进一步思考：潜在用户=访客数×转化率我们可以一方面通过增加页面的营销内容提高转化率，另一方面也可以通过SEO、公关、推广等方式增加访客数，下面只说前者，但两者的目的都是希望能加粗上图中访客到“潜在用户”的线。之后，我们和销售、服务一起讨论，确认了目的，总结出portal需要哪些页面，以及导航菜单的结构，因为整个站点的复杂度相对较低，所以我们压缩在一级菜单里解决了，如下表。产品portal菜单结构示意接着是确定每个页面上都需要哪些元素，以首页为例，我们列出了下表。首页的元素上面的工作可以看作“结构化思维”，“战略、范围”的设计基本完成，接下来就是“形象化表达”了，“结构、框架、表现”，UE的同学就成了主角。下面几张图是用哪些工具做的就不说了，这里聊一下PD和UE谁做什么事情，怎么配合。一开始，PD和UE一起讨论，手绘出首页的大概样子。PD要表达清楚每一个模块的商业目标，可以给出自己对页面的布局建议，但最终的页面结构，UE可以主导确定。纸面Demo然后是线框图，PD有时候也会直接给出这个，“变脸”项目中，是UE的同学做的。大家仍然是讨论确定，UE这时候会在设计的过程中融入很多自己的想法，PD要做到的就是防止走偏，保证大家对商业目标理解的一致。比如在下图中，大家讨论后确定页面为“左侧大右侧小”的双列结构，并且左侧的内容主攻访客，右侧的内容主攻付费用户。线框图Demo接着，UE出页面效果图，会安排销售、服务等相关方来做一次评审，告诉他们这就是将来看到的页面，征求意见，他们一定会有各种疑问，这时候PD和UE需要确保每一个细节设计都是有理有据，包括每块区域的位置、长宽；每行文字的字体、字号；每个小图的颜色等等，都不只是为了好看，而一定