《网站需求分析精品文稿.ppt》由会员分享，可在线阅读，更多相关《网站需求分析精品文稿.ppt（42页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、网站需求分析网站需求分析第1页，本讲稿共42页l3.1 3.1 网站工程项目阶段划分网站工程项目阶段划分l3.2 3.2 网站需求分析一般内容网站需求分析一般内容l3.3 3.3 具体功能需求分析描述方法具体功能需求分析描述方法l3.4 网站需求分析需求分析第2页，本讲稿共42页3.1网站工程项目阶段划分l网站工程项目实施大致分为五个阶段：l（1）需求分析：准确地把握用户建立网站的目的，明确项目范围、整体性和可操作性。具体工作包括：对用户业务（商业、工业、教育、政务等）策略的回顾，讨论、确定并按优先次序列出需求清单，提交工程项目需求，安排工程项目实施计划。l（2）规划设计。在需求分析阶段成果的
2、基础上，对网站服务器系统选型与配置、网站功能、系统建构（内容设计、交互信息规划、界面设计等）和视觉创意等方面进行更详细的分析设计。所有的分析设计需要记录，并与用户深入探讨和改进。如有必要，网站开发人员应制作一个原型或演示系统，来测试网站建构的概念。第3页，本讲稿共42页l（3）开发整合。在以上两阶段基础上具体构建网站，用各种方法、手段实现已有的构思和规划，最终形成一个可以被发布至互联网或内部网的系统。可能包括新系统与原有信息资源的整合。l（4）测试发布。网站系统测试包括：功能测试是测试已知网站所应具有的功能，通过测试检测每个功能是否都能正常使用；结构测试是按照网站程序内部的结构测试程序，检验程
3、序中的每条通路是否都有能按预定要求正确工作；性能测试：检测网站系统相应用户访问请求的速度。测试时，首先在开发环境中进行，然后迁移至运营环境进行全面在线测试，直至网站系统进入用户的业务运作阶段。l（5）管理维护。网站项目团队帮助用户学会如何运作及维护网站系统，对网站系统进行必要的监控、维护，以保证正常运行，并比较衡量网站系统的目标实现情况，整理形成一份计划，以便网站系统的增强与升级。第4页，本讲稿共42页3.2网站需求分析一般内容l网站需求分析：了解、分析、明确用户需求，并准确、清晰地以文档形式表达出来，提供给项目实施的每个成员，保证实施过程按照满足用户需求为目的的正确方向进行。l开发人员和网站
4、所有者都负有重要的责任。l需求分析的原则：帮助网站所有者整理出他想要的、并且可实现的网站l人们不一定能说清楚自己想要什么；l网站是一个比较庞大的信息系统，需要一定的方法来规范需求分析的过程。l包括三个阶段的内容：l（1）网站背景分析；（2）总体需求分析；（3）具体需求分析l每一阶段的分析都为后一阶段的工作打基础。l每个阶段都需要与网站所有者进行沟通、确认。第5页，本讲稿共42页3.2.1网站背景分析l网站背景分析主要对网站建立者的背景情况进行了解，以及对网站建立的基础条件、可行性等进行分析l建立网站的两种情况：l已有线下业务的组织形式，网站为线下业务服务；l纯网上业务平台。第6页，本讲稿共42
5、页l网站背景分析步骤及内容：1.业务背景概况了解：l网站组织简介（Whoareyou？）l业务情况分析（Whatareyoudoing？）l市场状况分析（Howareyou？）2.网站建立背景：l起因：为什么想要建立网站？l诉求：有什么样的网站构想？第7页，本讲稿共42页3.结合业务背景分析建立网站的可行性是否有能力（人力、物力、财力）运营所构想的网站？所构想的网站能否有好的效果？网站构想的现实性市场环境的竞争因素分析如何在能力的约束下获得效果更好的网站可行方案。第8页，本讲稿共42页例：例：l经管学院网站l业务背景概况了解：l经管学院是个什么组织？l经管学院主要有哪些业务？l经管学院的规模、
6、影响力等l网站建立背景了解：l起因：在校教师、学生不经常在同一地点；考生了解学院的途径很不方便。l诉求：更大范围宣传学院；方便学院教师、学生工作、学习需求；l可行性分析：l能力l效果l可行方案第9页，本讲稿共42页3.2.2总体需求分析l总体需求分析是定义网站的总体范围和目标l总体需求分析是后续建设任务的基础和蓝图l主要分析内容：l建站目标分析l受众分析l网站定位分析第10页，本讲稿共42页l（1）建站目标分析l根据网站背景分析，定义网站的使命和意义，包括l网站的服务范围l网站所要达到的运行效果（近期目标，远期目标）l如：“本网站将全面介绍经管学院的组织结构、师资情况、招生情况、招聘情况、教学
7、及科研发展状况、院系活动、社会合作活动等关于学院的全方面的信息，让所有希望了解经管学院的个人或组织都能够在网站中方便地找到所需的信息；并在逐步地发展中成为各方与学院联系及合作的综合性的电子服务平台。”第11页，本讲稿共42页l（2）受众分析l根据建站目标，确定浏览者的身份和特点l受众分析是网站信息及服务内容设置的重要依据之一l主要分析内容l分析可能浏览网站的人群l了解不同人群的具体特征和需求特点年龄、职业、生活环境等个人特征；组织类型、行业环境等组织特征；个人上网行为特点；对网站的信息（功能）需求特点。l可能需要进行调查，形成用户调查报告l如：经管学院网站的可能受众有：在校学生及教职工、拟报考
8、学院的考生及家长、拟求职的应聘者、合作组织及个人、拟寻求项目或其它形式合作的其它组织及个人、上下级相关部门及个人、其它对学院情况感兴趣的组织及个人。第12页，本讲稿共42页l（3）网站定位分析l根据受众分析、结合竞争者分析为实现网站目标确定网站的总体定位，定位包括：l网站信息、服务内容方面的定位；l形式方面的定位，如色彩、主题风格等l如：“经管学院网站应通过统一的、专业化的语言及界面，向受众发布准确、全面、及时的学院综合信息”l定位要求：l符合浏览者的需求和特点；l突出特色可以在竞争中占据优势，吸引更多浏览者；可能需要对同行业竞争者的情况进行调研，形成市场调研报告分析获得体现特色的策略第13页
9、，本讲稿共42页3.2.3具体需求分析l包括功能需求与性能需求两方面l功能需求：网站能做什么l根据总体需求分析的指导逐一、详细分析网站所提供的信息和功能。l形成网站功能描述书l性能需求：非功能性需求，是网站实现功能的效果、程度l所提供服务及网站策略实现的质量要求第14页，本讲稿共42页3.2.4 非功能需求分析非功能需求分析l（一）性能需求的意义（一）性能需求的意义l例1：l考核系统中，每天在上班后1小时内，将有90%的用户会上线查看自己的考核结果。因此，在进行考核结果查询功能的分析中，应写下这样的话：查询必须高效（预计查询数据量：xxx），并且支持高并发操作（预计并发用户峰值：xxx）。有了
10、这些描述，设计和开发人员会着重注意该功能的性能问题，测试人员也可以着重进行该部分的性能测试。l例2：l在另一个项目中，用户需要对大量的数据进行选择，进而完成制作清册、下派、回退等操作。在前期的需求分析中，需求人员没有仔细分析这些操作的易用性，没有提供给用户批量选择等功能第15页，本讲稿共42页l（二）性能需求指标举例（二）性能需求指标举例l哪些是非功能需求呢？l“URPS+”：即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。l1可用性（Usability）可用性是一个非常宽泛的概念，它泛指
11、那些能让用户顺利使用系统的指标，包括易用性（易操作、易理解）、准确性、安全性（权限体系、访问限制）、兼容性（服务器、客户端的兼容度），等等。l2可靠性（Reliability）可靠性就是系统可以可靠运行，包括系统成熟度（数据吞吐量、并发用户量、连续不停机性能等）、数据容错度、系统易恢复性，等等。第16页，本讲稿共42页l3性能（Performance）l性能，就是用户看到的系统运行的表现、效果，是需求分析阶段最主要的分析内容。l用户对性能的要求没有止境，但现实却是残酷的。l性能受到许多因素的影响，包括业务需求、软件设计、数据库设计、系统部署方式，等等。其中，业务需求和部署方式，对性能的影响是最
12、大的。第17页，本讲稿共42页l（1）业务需求影响性能的。l一个数据导出的功能，看似一个非常普通的功能。但是经过仔细地分析我们发现，客户在执行数据导出前的查询时，如果选择时间跨度数年，查出的数据量可能达到数十万。l要将数十万数据一次性地导入到一个excel文件中，这不论从运行效率、系统稳定性，还是技术可行性分析都是不可取的。l最后，我们经过与客户的协商，一次性导出数据最大不超过2万，同时提供了分页导出的功能，可以让他们选择导出从第几页到第几页的数据。这样，如果数据量大，客户可以经过多次将数据导出，数据导出的性能得以保证。第18页，本讲稿共42页l（2）系统部署架构对性能的影响也是巨大的。l一个
13、管理系统，是市级集中，还是省级集中，甚至全国集中，对性能的考量是不一样的。市级集中不会过于担心性能的问题；省级集中就必须要考量并发访问量，是否要建立集群；全国集中就必须考量是否使用消息队列，所有流程是否有性能瓶颈，以及采用什么技术架构更适于并发访问等等。第19页，本讲稿共42页l4可支持性（Supportability）l可支持性，就是软件的可维护性、易变更性。l在需求分析与设计阶段，可支持性实际上体现在，我们是否能有效识别系统可变的需求，并能够提供合理的方案。l举例1：在分析和设计ERP软件的时发现，应付单需要生成凭证，随后又发现应收单、采购单、销售发票都要生成凭证。既然这么多单据需要生成凭
14、证，是否还有其它我们还不知道的单据也要生成凭证，是否可以有一个统一的接口。果不其然，核销单、工资单、固定资产核定都需要生成凭证。最后我们设计成了一个统一的生成凭证接口。l举例2：客户报表在查询SQL、过滤条件、显示列等部分经常变，因此设计成一套可配置的报表系统，大大提高了系统可维护性。第20页，本讲稿共42页l功能需求固然重要，非功能需求同样重要。l我们在进行非功能需求的分析时，除了制订整体的原则以外，还要落实到各个具体的功能中，将这些功能所潜在的、特殊的非功能需求挖掘出来，提前进行分析设计l对于可行性不高的应及时与客户商讨，才能有效地避免日后存在的这些方面的风险。第21页，本讲稿共42页3.
15、3 具体功能需求分析的描述方法具体功能需求分析的描述方法l3.3.1 用例用例(Use Case)l用例分析是一种从用户使用角度描述需求的技术。l该技术包含一定的分析视角，以及一定的呈现形式l用例分析视角让开发人员暂时不考虑软件系统内部的行为和结构，而专注于清理用户“想怎样”去“使用”这个系统，以充分正确地掌握用户需求，并最终通过“用例”来反映这些需求l什么是用例？l（1）用例是系统在响应用户请求时，在各种情况下的行为或功能描述l（2）或是实现某项特定业务目的的所有功能第22页，本讲稿共42页l用例的呈现形式有“用例图”和“用例描述”。l用例图(UseCaseDiagram)通过简要的图形方式
16、反映网站的使用者及网站功能的关系；以图形方式表示用例，有助于从较高的层次来观察业务或域的主要功能及关系，但并不代替具体的描述文档。l用例描述(UseCaseNarrative)通过更具体的文字来说明用例的实现细节。用例的更全面的信息依赖于描述文档的说明，文档描述了每个用例的具体细节。第23页，本讲稿共42页3.3.2 用例图用例图l用例图展示了一个外部用户能够观察到的系统功能模型图。l帮助开发团队以一种可视化的方式、从用户使用角度理解系统的功能需求。l用例图的绘制元素包括：l参与者、用例、子系统边框、关系l1.参与者(Actor)l表示与应用程序或系统进行交互的用户、物、组织或外部系统。l参与
17、者是角色，不代表特定的用户。一个用户可以扮演多个角色，一个参与者可以代表多个用户。l用一个小人表示。角色名称第24页，本讲稿共42页l2.用例(UseCase)l用例就是外部可见的系统功能或处理过程。l用椭圆表示。l3.子系统(Subsystem)l用来展示系统的一部分功能，这部分功能联系紧密。l用方框来描述子系统范围。l用例在方框以内；参与者在方框以外下载资料子系统登 录搜 索列表查看下载资料浏览者登 录浏览通知第25页，本讲稿共42页l4.关系l表示参与者与一个或多个用例之间的交互，或用例之间的交互。l不代表数据流。l用例图中涉及的关系有：关联、泛化、包含、扩展。第26页，本讲稿共42页l
18、a.关联(Association)l关联关系表示参与者和用例之间的通信。l关联关系用直线或箭头表示。浏览通知浏览者启动网络打印管理员打印机查询通知库第27页，本讲稿共42页l【箭头形式】：尖箭头。l【箭头指向】：指向消息接收方。l如果参与者启动了用例，箭头指向用例；l如果参与者接收了用例的指令，箭头指向参与者。l如果二者是互动的，则是直线。l不同的参与者可以访问相同的用例，一般说来它们和同一用例的交互是不一样的l如果两种交互的目的也相同，说明他们的角色是相同的，就应该将他们合并。第28页，本讲稿共42页lb.泛化(Inheritance)l代表一般与特殊的关系（类似于继承）普通用户浏览者登录用
19、户第29页，本讲稿共42页l在用例泛化中，子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增加新的行为和属性或覆盖父用例中的行为。l父用例通常是抽象的。l例：一个订票的部分内容，父用例是“订票”，其两个子用例分别是“网上订票”和“电话订票”，这两个用例都继承了父用例的行为，并可以添加自己的行为l参与者的泛化中，子参与者继承父参与者的所有关联关系l【箭头指向】：指向父用例或父参与者l【箭头形式】：空心三角第30页，本讲稿共42页lc.包含(Include)l一个用例（基用例，基本用例）可以包含其他用例（包含用例）具有的行为，并把它所包含的用例行为作为自身用例的一部分，这被称为包
20、含关系。l包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。l【箭头形式】：包含关系表示为虚线箭头加inclusivel【箭头方向】：箭头从基本用例指向包含用例。第31页，本讲稿共42页ld.扩展(Extend)l扩展关系是指用例功能的延伸，相当于为基础用例提供一个新的附加功能（或行为）。l【箭头形式】包含关系表示为虚线箭头加extendl【箭头方向】箭头从扩展用例指向基本用例。第32页，本讲稿共42页l扩展关系可以有控制条件，一般情况下，基本用例的执行不会涉及到扩展用例，只有满足用例的控制条件时，扩展用例才被执行，因此扩展关系处理事件流的异常或者可选事件。l同一个基本用例的几个扩展同
21、时满足条件时可以在一起使用。l基本用例不知道扩展的任何细节，没有扩展用例，基本用例是完整的。第33页，本讲稿共42页泛化、包含、扩展的区别：泛化、包含、扩展的区别：l比较用例之间的关系l条件性：l泛化中的子用例和包含中的被包含的用例会无条件发生l扩展中的延伸用例的发生是有条件的；l直接性：l泛化中的子用例和扩展中的延伸用例为参与者提供直接服务l包含中被包含的用例为参与者提供间接服务。l包含性：l泛化中的子用例及包含关系中的基础用例，包含父用例及包含用例的所有内容及其和其他用例或参与者之间的关系；l对扩展而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。第34页，本讲稿共42
22、页5、用例图绘制步骤：、用例图绘制步骤：确定子系统边界：找出系统外部的参与者和外部系统，确定系统的边界和范围。分析需求：确定每一个参与者所期望的系统行为确定用例：把这些系统行为命名为用例分析用例关系：使用泛化、包含、扩展等关系处理系统行为的公共或变更部分具体化用例内容：编制每一个用例的描述绘制用例图区分基本事件流和异常情况的事件流，如有需要可以把表示异常情况的事件流作为单独的用例来处理细化用例图，解决用例间的重复与冲突。第35页，本讲稿共42页l练习一：l某餐厅为顾客提供餐食和酒水，侍应生在顾客点餐后将菜单交厨房确认和制作，顾客消费后到收银台结账。l请为该餐厅的管理信息系统开发画出用例图。第3
23、6页，本讲稿共42页用例绘制都有些什么常见问题用例绘制都有些什么常见问题l1.不知如何入手?l功能角色分析。从系统中包含怎样的角色开始，逐步整理相关的功能。l在这个过程中，首先，系统划分几个子系统几个功能模块。然后，为每个功能模块绘制用例图。l2.没有正确理解用例图的视角。l用例图的视角是用户l从这个视角，用户看到的系统是一项一项的功能，这些功能是客户能够理解的、具体的、对客户存在价值的功能。l举个简单的例子，一个员工档案信息系统，以往我们总爱将用例取名为“添加员工信息”、“更新员工信息”、“删除员工信息”，这就是典型的技术人员编写的用例。“添加员工信息”对于用户来讲应当是做什么呢填写新员工资
24、料；“更新员工信息”对于用户来讲又是做什么呢更改员工资料；“删除员工信息”又是什么呢员工注销。第37页，本讲稿共42页l3.图形绘制杂乱无章。l绘制用例图要学会拆分，由粗到细地一个一个绘制。先整体的绘制，再划分成各个模块一个一个详细绘制，再进一步细化。l一个系统，特别是一个大型系统，提供给用户的功能是繁杂的。描述一个系统应当有许许多多的用例图。如果你想将所有的功能，不管粗的细的，都试图绘制在一个用例图中，几乎没人看得懂。l4.用例是一个场景。l在现实世界中，我们常常面对的是一个个长而复杂的操作流程，但在软件世界里，我们要将它们拆分成一个个的用例，怎样拆分？一个用例必须有一个场景，也就是时间相近
25、、地点单一的一系列操作。每个用例都有确定的场景，明确的目的和结果。l举例（见下页）第38页，本讲稿共42页l如图所示的用例图，“申辩申请”就是过错责任人填写了一张申辩申请单，最终的结果是将申辩申请单提交给考核管理员；“申辩受理”就是考核管理员接收了过错责任人的申辩申请单并予以受理，当然另一个结果是对其不予受理，该申请单被退回给过错责任人。第39页，本讲稿共42页3.3.3 用例描述用例描述(Use Case Narrative)l用例图中很多细节信息都没有明确的表示出来，只是勾勒了一个大致的系统功能轮廓，更重要的是需要用例描述部分来说明。l用例描述的是一个系统做什么（what）的信息（即功能需
26、求），并不说明怎么做（how），怎么做是设计模型的事。l（1）一般来说，用例描述采用自然语言描述参与者与系统进行交互时的行为。它一般包括以下内容：l用例的目标l用例是怎么启动的l参与者和用例之间的消息是如何传送的l用例中除了主路径，其他路径是什么l用例结束后的系统状态l其他需要描述的内容l（2）用例描述的格式l用例描述一般也是具有规范格式的（转下页）：第40页，本讲稿共42页用例用例编编号号为用例制定一个唯一的编号，通常为UCxx用例名称用例名称应为一个动词短语，让读者一目了然地知道用例的目标用例概述用例概述用例的目标，一个概要性的描述范围用例的涉及范围主要参与者主要参与者该用例的主actor
27、，列出名称，并简要描述次要参与者该用例的次要actor，列出名称，并简要描述项目相关人利益说明项目相关人利益项目相关人员名称从该用例获得的利益前置条件即启动该用例所应该满足的条件后置条件即该用例完成之后，将执行什么动作成功保证描述当前目标完成后，环境变化情况基本事件流基本事件流步骤活动1在这里写出触发事件到目标完成以及清除的全部步骤2其中可以包含子事件流，以子事件流编号来表示扩展事件流1a1a表示对上述基本事件流步骤1的扩展，其中应说明条件和活动1b其中可以包含子事件流，以子事件流编号来表示子事件流对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方规则与约束对该用例实现时需要考虑的业务规则、非功能需求、设计约束等其他相关用例此用例所包含的用例、此用例所泛化的用例、此用例所扩展的用例第41页，本讲稿共42页用例描述举例：用例描述举例：第42页，本讲稿共42页