网站需求分析

网站需求分析第1页，课件共42页，创作于2023年2月3.1网站工程项目阶段划分3.2网站需求分析一般内容3.3具体功能需求分析描述方法3.4网站需求分析第2页，课件共42页，创作于2023年2月3.1网站工程项目阶段划分网站工程项目实施大致分为五个阶段：（1）需求分析：准确地把握用户建立网站的目的，明确项目范围、整体性和可操作性。具体工作包括：对用户业务（商业、工业、教育、政务等）策略的回顾，讨论、确定并按优先次序列出需求清单，提交工程项目需求，安排工程项目实施计划。（2）规划设计。在需求分析阶段成果的基础上，对网站服务器系统选型与配置、网站功能、系统建构（内容设计、交互信息规划、界面设计等）和视觉创意等方面进行更详细的分析设计。所有的分析设计需要记录，并与用户深入探讨和改进。如有必要，网站开发人员应制作一个原型或演示系统，来测试网站建构的概念。第3页，课件共42页，创作于2023年2月（3）开发整合。在以上两阶段基础上具体构建网站，用各种方法、手段实现已有的构思和规划，最终形成一个可以被发布至互联网或内部网的系统。可能包括新系统与原有信息资源的整合。（4）测试发布。网站系统测试包括：功能测试是测试已知网站所应具有的功能，通过测试检测每个功能是否都能正常使用；结构测试是按照网站程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作；性能测试：检测网站系统相应用户访问请求的速度。测试时，首先在开发环境中进行，然后迁移至运营环境进行全面在线测试，直至网站系统进入用户的业务运作阶段。（5）管理维护。网站项目团队帮助用户学会如何运作及维护网站系统，对网站系统进行必要的监控、维护，以保证正常运行，并比较衡量网站系统的目标实现情况，整理形成一份计划，以便网站系统的增强与升级。第4页，课件共42页，创作于2023年2月3.2网站需求分析一般内容网站需求分析：了解、分析、明确用户需求，并准确、清晰地以文档形式表达出来，提供给项目实施的每个成员，保证实施过程按照满足用户需求为目的的正确方向进行。开发人员和网站所有者都负有重要的责任。需求分析的原则：帮助网站所有者整理出他想要的、并且可实现的网站人们不一定能说清楚自己想要什么；网站是一个比较庞大的信息系统，需要一定的方法来规范需求分析的过程。包括三个阶段的内容：（1）网站背景分析；（2）总体需求分析；（3）具体需求分析每一阶段的分析都为后一阶段的工作打基础。每个阶段都需要与网站所有者进行沟通、确认。第5页，课件共42页，创作于2023年2月3.2.1网站背景分析网站背景分析主要对网站建立者的背景情况进行了解，以及对网站建立的基础条件、可行性等进行分析建立网站的两种情况：已有线下业务的组织形式，网站为线下业务服务；纯网上业务平台。第6页，课件共42页，创作于2023年2月网站背景分析步骤及内容：业务背景概况了解：网站组织简介（Whoareyou？）业务情况分析（Whatareyoudoing？）市场状况分析（Howareyou？）网站建立背景：起因：为什么想要建立网站？诉求：有什么样的网站构想？第7页，课件共42页，创作于2023年2月结合业务背景分析建立网站的可行性是否有能力（人力、物力、财力）运营所构想的网站？所构想的网站能否有好的效果？网站构想的现实性市场环境的竞争因素分析如何在能力的约束下获得效果更好的网站可行方案。第8页，课件共42页，创作于2023年2月例：经管学院网站业务背景概况了解：经管学院是个什么组织？经管学院主要有哪些业务？经管学院的规模、影响力等网站建立背景了解：起因：在校教师、学生不经常在同一地点；考生了解学院的途径很不方便。诉求：更大范围宣传学院；方便学院教师、学生工作、学习需求；可行性分析：能力效果可行方案第9页，课件共42页，创作于2023年2月3.2.2总体需求分析总体需求分析是定义网站的总体范围和目标总体需求分析是后续建设任务的基础和蓝图

主要分析内容：建站目标分析受众分析网站定位分析第10页，课件共42页，创作于2023年2月（1）建站目标分析根据网站背景分析，定义网站的使命和意义，包括网站的服务范围网站所要达到的运行效果（近期目标，远期目标）如：

“本网站将全面介绍经管学院的组织结构、师资情况、招生情况、招聘情况、教学及科研发展状况、院系活动、社会合作活动等关于学院的全方面的信息，让所有希望了解经管学院的个人或组织都能够在网站中方便地找到所需的信息；并在逐步地发展中成为各方与学院联系及合作的综合性的电子服务平台。”第11页，课件共42页，创作于2023年2月（2）受众分析根据建站目标，确定浏览者的身份和特点受众分析是网站信息及服务内容设置的重要依据之一主要分析内容分析可能浏览网站的人群了解不同人群的具体特征和需求特点年龄、职业、生活环境等个人特征；组织类型、行业环境等组织特征；个人上网行为特点；对网站的信息（功能）需求特点。可能需要进行调查，形成《用户调查报告》如：经管学院网站的可能受众有：在校学生及教职工、拟报考学院的考生及家长、拟求职的应聘者、合作组织及个人、拟寻求项目或其它形式合作的其它组织及个人、上下级相关部门及个人、其它对学院情况感兴趣的组织及个人。第12页，课件共42页，创作于2023年2月（3）网站定位分析根据受众分析、结合竞争者分析为实现网站目标确定网站的总体定位，定位包括：网站信息、服务内容方面的定位；形式方面的定位，如色彩、主题风格等如：

“经管学院网站应通过统一的、专业化的语言及界面，向受众发布准确、全面、及时的学院综合信息”定位要求：符合浏览者的需求和特点；突出特色可以在竞争中占据优势，吸引更多浏览者；可能需要对同行业竞争者的情况进行调研，形成《市场调研报告》分析获得体现特色的策略第13页，课件共42页，创作于2023年2月3.2.3具体需求分析包括功能需求与性能需求两方面功能需求：网站能做什么根据总体需求分析的指导逐一、详细分析网站所提供的信息和功能。形成《网站功能描述书》性能需求：非功能性需求，是网站实现功能的效果、程度所提供服务及网站策略实现的质量要求第14页，课件共42页，创作于2023年2月3.2.4非功能需求分析（一）性能需求的意义例1：考核系统中，每天在上班后1小时内，将有90%的用户会上线查看自己的考核结果。因此，在进行考核结果查询功能的分析中，应写下这样的话：查询必须高效（预计查询数据量：xxx），并且支持高并发操作（预计并发用户峰值：xxx）。有了这些描述，设计和开发人员会着重注意该功能的性能问题，测试人员也可以着重进行该部分的性能测试。例2：在另一个项目中，用户需要对大量的数据进行选择，进而完成制作清册、下派、回退等操作。在前期的需求分析中，需求人员没有仔细分析这些操作的易用性，没有提供给用户批量选择等功能第15页，课件共42页，创作于2023年2月（二）性能需求指标举例哪些是非功能需求呢？“URPS+”：即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。1可用性（Usability）可用性是一个非常宽泛的概念，它泛指那些能让用户顺利使用系统的指标，包括易用性（易操作、易理解）、准确性、安全性（权限体系、访问限制）、兼容性（服务器、客户端的兼容度），等等。2可靠性（Reliability）可靠性就是系统可以可靠运行，包括系统成熟度（数据吞吐量、并发用户量、连续不停机性能等）、数据容错度、系统易恢复性，等等。第16页，课件共42页，创作于2023年2月3性能（Performance）性能，就是用户看到的系统运行的表现、效果，是需求分析阶段最主要的分析内容。用户对性能的要求没有止境，但现实却是残酷的。性能受到许多因素的影响，包括业务需求、软件设计、数据库设计、系统部署方式，等等。其中，业务需求和部署方式，对性能的影响是最大的。第17页，课件共42页，创作于2023年2月（1）业务需求影响性能的。一个数据导出的功能，看似一个非常普通的功能。但是经过仔细地分析我们发现，客户在执行数据导出前的查询时，如果选择时间跨度数年，查出的数据量可能达到数十万。要将数十万数据一次性地导入到一个excel文件中，这不论从运行效率、系统稳定性，还是技术可行性分析都是不可取的。最后，我们经过与客户的协商，一次性导出数据最大不超过2万，同时提供了分页导出的功能，可以让他们选择导出从第几页到第几页的数据。这样，如果数据量大，客户可以经过多次将数据导出，数据导出的性能得以保证。第18页，课件共42页，创作于2023年2月（2）系统部署架构对性能的影响也是巨大的。一个管理系统，是市级集中，还是省级集中，甚至全国集中，对性能的考量是不一样的。市级集中不会过于担心性能的问题；省级集中就必须要考量并发访问量，是否要建立集群；全国集中就必须考量是否使用消息队列，所有流程是否有性能瓶颈，以及采用什么技术架构更适于并发访问等等。第19页，课件共42页，创作于2023年2月4可支持性（Supportability）可支持性，就是软件的可维护性、易变更性。在需求分析与设计阶段，可支持性实际上体现在，我们是否能有效识别系统可变的需求，并能够提供合理的方案。举例1：

在分析和设计ERP软件的时发现，应付单需要生成凭证，随后又发现应收单、采购单、销售发票都要生成凭证。既然这么多单据需要生成凭证，是否还有其它我们还不知道的单据也要生成凭证，是否可以有一个统一的接口。果不其然，核销单、工资单、固定资产核定都需要生成凭证。最后我们设计成了一个统一的生成凭证接口。举例2：

客户报表在查询SQL、过滤条件、显示列等部分经常变，因此设计成一套可配置的报表系统，大大提高了系统可维护性。第20页，课件共42页，创作于2023年2月功能需求固然重要，非功能需求同样重要。我们在进行非功能需求的分析时，除了制订整体的原则以外，还要落实到各个具体的功能中，将这些功能所潜在的、特殊的非功能需求挖掘出来，提前进行分析设计对于可行性不高的应及时与客户商讨，才能有效地避免日后存在的这些方面的风险。第21页，课件共42页，创作于2023年2月3.3具体功能需求分析的描述方法3.3.1用例(UseCase)用例分析是一种从用户使用角度描述需求的技术。该技术包含一定的分析视角，以及一定的呈现形式用例分析视角让开发人员暂时不考虑软件系统内部的行为和结构，而专注于清理用户“想怎样”去“使用”这个系统，以充分正确地掌握用户需求，并最终通过“用例”来反映这些需求什么是用例？（1）用例是系统在响应用户请求时，在各种情况下的行为或功能描述（2）或是实现某项特定业务目的的所有功能第22页，课件共42页，创作于2023年2月用例的呈现形式有“用例图”和“用例描述”。用例图(UseCaseDiagram)通过简要的图形方式反映网站的使用者及网站功能的关系；以图形方式表示用例，有助于从较高的层次来观察业务或域的主要功能及关系，但并不代替具体的描述文档。用例描述(UseCaseNarrative)通过更具体的文字来说明用例的实现细节。用例的更全面的信息依赖于描述文档的说明，文档描述了每个用例的具体细节。第23页，课件共42页，创作于2023年2月

3.3.2用例图用例图展示了一个外部用户能够观察到的系统功能模型图。帮助开发团队以一种可视化的方式、从用户使用角度理解系统的功能需求。用例图的绘制元素包括：参与者、用例、子系统边框、关系1.

参与者(Actor)表示与应用程序或系统进行交互的用户、物、组织或外部系统。参与者是角色，不代表特定的用户。一个用户可以扮演多个角色，一个参与者可以代表多个用户。用一个小人表示。角色名称第24页，课件共42页，创作于2023年2月2.

用例(UseCase)用例就是外部可见的系统功能或处理过程。用椭圆表示。3.子系统(Subsystem)用来展示系统的一部分功能，这部分功能联系紧密。用方框来描述子系统范围。用例在方框以内；参与者在方框以外下载资料子系统登录搜索列表查看下载资料浏览者登录浏览通知第25页，课件共42页，创作于2023年2月4.

关系表示参与者与一个或多个用例之间的交互，或用例之间的交互。不代表数据流。用例图中涉及的关系有：关联、泛化、包含、扩展。第26页，课件共42页，创作于2023年2月

a.关联(Association)关联关系表示参与者和用例之间的通信。关联关系用直线或箭头表示。浏览通知浏览者启动网络打印管理员打印机查询通知库第27页，课件共42页，创作于2023年2月【箭头形式】：尖箭头。【箭头指向】：指向消息接收方。如果参与者启动了用例，箭头指向用例；如果参与者接收了用例的指令，箭头指向参与者。如果二者是互动的，则是直线。不同的参与者可以访问相同的用例，一般说来它们和同一用例的交互是不一样的如果两种交互的目的也相同，说明他们的角色是相同的，就应该将他们合并。第28页，课件共42页，创作于2023年2月

b.泛化(Inheritance)代表一般与特殊的关系（类似于继承）普通用户浏览者登录用户第29页，课件共42页，创作于2023年2月在用例泛化中，子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增加新的行为和属性或覆盖父用例中的行为。

父用例通常是抽象的。例：一个订票的部分内容，父用例是“订票”，其两个子用例分别是“网上订票”和“电话订票”，这两个用例都继承了父用例的行为，并可以添加自己的行为参与者的泛化中，子参与者继承父参与者的所有关联关系【箭头指向】：指向父用例或父参与者【箭头形式】：空心三角第30页，课件共42页，创作于2023年2月

c.包含(Include)一个用例（基用例，基本用例）可以包含其他用例（包含用例）具有的行为，并把它所包含的用例行为作为自身用例的一部分，这被称为包含关系。包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。【箭头形式】：包含关系表示为虚线箭头加《inclusive》【箭头方向】：箭头从基本用例指向包含用例。

第31页，课件共42页，创作于2023年2月

d.扩展(Extend)扩展关系是指用例功能的延伸，相当于为基础用例提供一个新的附加功能（或行为）。【箭头形式】包含关系表示为虚线箭头加《extend》【箭头方向】箭头从扩展用例指向基本用例。第32页，课件共42页，创作于2023年2月扩展关系可以有控制条件，一般情况下，基本用例的执行不会涉及到扩展用例，只有满足用例的控制条件时，扩展用例才被执行，因此扩展关系处理事件流的异常或者可选事件。同一个基本用例的几个扩展同时满足条件时可以在一起使用。基本用例不知道扩展的任何细节，没有扩展用例，基本用例是完整的。第33页，课件共42页，创作于2023年2月泛化、包含、扩展的区别：比较用例之间的关系条件性：泛化中的子用例和包含中的被包含的用例会无条件发生扩展中的延伸用例的发生是有条件的；直接性：泛化中的子用例和扩展中的延伸用例为参与者提供直接服务包含中被包含的用例为参与者提供间接服务。包含性：泛化中的子用例及包含关系中的基础用例，包含父用例及包含用例的所有内容及其和其他用例或参与者之间的关系；对扩展而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。第34页，课件共42页，创作于2023年2月5、用例图绘制步骤：⑴确定子系统边界：找出系统外部的参与者和外部系统，确定系统的边界和范围。⑵分析需求：确定每一个参与者所期望的系统行为⑶确定用例：把这些系统行为命名为用例⑷分析用例关系：使用泛化、包含、扩展等关系处理系统行为的公共或变更部分⑸具体化用例内容：编制每一个用例的描述⑹绘制用例图⑺区分基本事件流和异常情况的事件流，如有需要可以把表示异常情况的事件流作为单独的用例来处理⑻细化用例图，解决用例间的重复与冲突。第35页，课件共42页，创作于2023年2月练习一：某餐厅为顾客提供餐食和酒水，侍应生在顾客点餐后将菜单交厨房确认和制作，顾客消费后到收银台结账。请为该餐厅的管理信息系统开发画出用例图。第36页，课件共42页，创作于2023年2月用例绘制都有些什么常见问题1.不知如何入手?功能角色分析。从系统中包含怎样的角色开始，逐步整理相关的功能。在这个过程中，首先，系统划分几个子系统几个功能模块。然后，为每个功能模块绘制用例图。2.没有正确理解用例图的视角。用例图的视角是用户从这个视角，用户看到的系统是一项一项的功能，这些功能是客户能够理解的、具体的、对客户存在价值的功能。举个简单的例子，一个员工档案信息系统，以往我们总爱将用例取名为“添加员工信息”、“更新员工信息”、“删除员工信息”，这就是典型的技术人员编写的用例。“添加员工信息”对于用户来讲应当是做什么呢——填写新员工资料；“更新员工信息”对于用户来讲又是做什么呢——更改员工资料；“删除员工信息”又是什么呢——员工注销。第37页，课件共42页，创作于2023年2月3.图形绘制杂乱无章。绘制用例图要学会拆分，由粗到细地一个一个绘制。先整体的绘制，再划分成各个模块一个一个详细绘制，再进一步细化。一个系统，特别是一个大型系统，提供给用户的功能是繁杂的。描述一个系统应当有许许多多的用例图。如果你想将所有的功能，不管粗的细的，都试图绘制在一个用例图中，几乎没人看得懂。4.用例是一个场景。在现实世界中，我们常常面对的是一个个长而复杂的操作流程，但在软件世界里，我们要将它们拆分成一个个的用例，怎样拆分？一个用例必须有一个场景，也就是时间相近、地点单一的一系列操作。每个用例都有确定的场景，明确的目的和结果。举例（见下页）第38页，课件共42页，创作于2023年2月如图所示的用例图，“申辩申请”就是过错责任人填写了一张申辩申请单，最终的结果是将申辩申请单提交给考核管理员；“申辩受理”就是考核管理员接收了过错责任人的申辩申请单并予以受理，当然另一个结果是对其不予受理，该申请单被退回给过错责任人。第39页，课件共42页，创作于2023年2月3.3.3用例描述(UseCaseNarrativ