浅析软件需求分析方法之原型法

浅析软件需求分析方法之原型法
浅析软件需求分析方法之原型法

浅析软件需求分析方法之原型法

发布时间:2012-03-22 17:48 来源:技术服务认证中心作者:宿爱霞软件开发中最为困难的是要准确知道应该要开发些什么,也就是我们通常所说的软件需求分析(Software Requirement Analysis)。因为一旦最初的需求做错了,不但会给系统功能带来极大的损害,而且不断的修改也会浪费资源、增加成本。有数据显示,软件项目中返工开销几乎占了总开发的一半,而导致返工的主要原因就是需求分析不明确。因此,一个软件开发项目想要成功的关键就是要做好需求分析。

软件需求分析是一个项目的开端,也是项目最重要的关键点。它是研究用户想要得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,并建立可确认的、可验证的一个基本依据。有调查报告显示,软件产品存在的不完整性、不正确性等问题,80%以上是由于需求分析错误所导致的。所以,一个成功的需求分析是软件项目能否成功的关键一步。然而,对于规模较大或结构较复杂的系统,在系统开发前期,用户往往对未来的新系统仅有一个比较模糊的想法。由于专业知识所限,系统开发人员对某些涉及具体领域的功能需求也不太清楚。虽然可以通过详细的系统分析和定义得到一份较好的规格说明书,却很难做到将整个管理信息系统描述完整,且与实际环境完全相符,很难通过逻辑推断看出新系统的运行效果。因此在新系统建成以后,用户对系统的功能或运行效果往往会觉得不满意。同时随着开发工作的进行,用户会产生新的要求或因环境变化希望系统也能随之作相应更改,系统开发人员也可能因碰到某些意料之外的问题希望在用户需求中有所权衡。因此,规格说明的难以完善和用户需求的模糊性成为了软件开发中的两个重大难点。原型方法(Prototyping)正是对上述问题进行变通的一种新的系统开发方法。

1.原型法基本思想

原型法凭借着系统分析人员对用户要求的理解,在强有力的软件环境支持下,快速地给出一个实实在在的模型(或称原型、雏形),然后与用户反复协商修改,最终形成实际系统。这个模型大致体现了系统分析人员对用户当前要求的理解和用户想要希望实现后的形式。

2.原型定义的策略

原型方法以一种与严格定义法截然不同的观点看待需求定义问题。原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始,允许用户在开发过程中提出更好的要求,根据用户的要求不断地对系统进行完善,它实质上是一种迭代的循环型的开发方式,如图所示。

3.原型法的特点

原型法的特点简要概括为:直观性、动态性、渐进明细性、严谨性。

原型法是一种循环往复、螺旋式上升的工作方法,它更多地遵循了人们认识事物的规律,因而更容易被人们掌握和接受。原型法强调用户的参与,特别是对模型的描述和系统需求的检验。它强调了用户的主导作用,通过开发人员与用户之间的相互作用,使用户的要求得到较好的满足。这样不但能及时沟通双方的想法,缩短用户和开发人员的距离,而且能更及时、准确的反馈信息,使潜在问题能尽早发现并及时解决,增加了系统的可靠性和适用性。

简单的说,原型法是将系统调查、系统分析和系统设计合而为一,使用户一开始就能看到系统开发后是一个什么样子。而且用户参与了系统全过程的开发,知道哪些是有问题的,哪些是错误的,哪些需要改进等,就能消除用户的担心,并提高了用户参与开发的积极性。同时,用户由于参与了开发的过程将有利于系统的移交、运行和维护。

4.使用原型法进行需求分析的流程

(1)快速分析,弄清用户的基本信息需求

需求分析原型法的第一步是在需求分析人员和用户的紧密配合下,快速确定软件系统的基本要求。也就是把原型所要体现的特性(界面形式、处理功能、总体结构、模拟性能等)描述出一个基本的规格说明。快速分析的关键是要选取核心需求来描述,先放弃一些次要的功能和性能。尽量围绕原型目标,集中力量确定核心需求说明,从而能尽快开始构造原型。

这个步骤的目标是要写出一份简明的骨架式说明性报告,能反映出用户需求的基本看法和要求。在该步骤中,用户的责任是先根据系统的输出来清晰地描述自己的基本需要,然后分析人员和用户共同定义基本的需求信息,讨论和确定初始需求的可用性。

(2)构造原型,开发初始原型系统

在快速分析的基础上,根据基本规格说明应尽快实现一个可运行的系统。原型系统可先考虑原型系统应必备的待评价特性,暂时忽略一切次要的内容。例如安全性、健壮性、异常处理等。如果这时为了追求完整而把原型做得太大的话,一是需要的时间太多,二是会增加

后期的修改工作量。因此,提交一个好的初始原型需要根据系统的规模、复杂性和完整程度的不同而不同。

本步骤的目标是:建立一个满足用户的基本需求并能运行的交互式应用系统。在这一步骤中用户没有责任,主要由开发人员去负责建立一个初始原型。

(3)用户和开发人员共同评价原型

这个阶段是双方沟通最为频繁的阶段,是发现问题和消除误解的重要阶段。其目的是验证原型的正确程度,进而开发新的原型并修改原有的需求。由于原型忽略了许多内容和细节,虽然它集中反映了许多必备的特性,但外观看起来还是可能会有些残缺不全。因此,用户可在开发人员的指导下试用原型,在试用的过程中考核和评价原型的特性,也可分析其运行结果是否满足规格说明的要求,和是否满足用户的愿望。并可纠正过去沟通交流时的误解和需求分析中的错误,增补新的要求,或提出全面的修改意见。

5.采用原型方法时需要注意的几个问题

(1)并非所有的需求都能在系统开发前被准确地说明

(2)项目参加者之间通常都存在交流上的困难,原型提供了克服该困难的一个手段

(3)需要实际的、可供用户参与的系统模型

(4)有合适的系统开发环境

(5)反复是完全需要和值得提倡的,但需求一旦确定,就应遵从严格的方法

总的来说,原型法是通过强化用户参与系统开发的过程,让用户获得系统的亲身体验,找出隐含的需求分析错误。原型需求分析法是鼓励改进和创造,通过不断交流来提高需求实现的质量和软件产品的质量,目的是为了更好的提高客户满意度

-需求分析方法论

需求分析方法论 原则上,需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力;在具体的任务开展上,以不干扰需求方的自主权为主,除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。 为了保证项目的成功,IT中心必须加强项目管理和项目分析工作,在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。 其中,需求分析是一个项目的开端,也是项目建设的基石。在以往的信息化建设失败的案例中,80%是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一,就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理,用户不习惯或不愿意去用应用管理软件。作为IT中心,必须提醒需求方重视需求分析的重要性,采用必要的手段和方法来进行需求调研,同时IT 中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向,才能在将来的功能界定、实施上有发言权。 一、如何进行需求分析 需求分析不象侦探推理那样需从蛛丝马迹着手,而是应该先了解宏观的问题,再了解细节的问题。 一个应用软件系统(记为S)的涉及面可能很广,可以按不同的问题域(记为D)分类,每个问题域对应于一个软件子系统。 S={D1,D2,D3,…Dn} 问题域Di由若干个问题(记为P)组成,每个问题对应于子系统中的一个软构件。 Di={P1,P2,P3,…Pm} 问题Pj有若干个行为(或功能,记为F),每个行为对应于软构件中的实现接口。 Pj={F1,F2,F3,…Fk} 需求说明书应该对于那些只想了解宏观需求的领导,和需要了解细节的技术人员都合适。在写需求说明书时应该注意两个问题: 1、最好为每个需求注释“为什么”,这样可让双方(IT中心、需求方)了解需求的本质,以便选用最合适的技术来实现此需求。 2、需求说明不可有二义性,更不能前后相矛盾。如果有二义性或前后相矛盾,则要重新分析此需求。 二、重点监控需求分析 由于项目的特殊性和行业覆盖的广阔性,以及需求分析的高风险性,软件需求分析的重要性是不言而喻的,同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 1、用户说不清楚需求 有些用户对需求只有朦胧的感觉,当然说不清楚具体的需求。例如总部各部门及各地的很多店铺在进行应用系统以及网络建设时,需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时,用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性,为项目未来建设埋下了潜在的风险。 2、需求自身经常变动 根据以往的历史经验,随着用户对信息化建设的认识和自己业务水平的提高,他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上,历史上没有一个软件的需求改动少于三次的!所以必须接受“需求会变动”这个事实,在进行需求分析时要懂得防患于未然,尽可能地分析清楚哪些是稳定的需求,哪些是易变的需求,以便在系统选型及实施时,将软件的核心建筑在稳定的需求上,同时留出变更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色,所以也必须积极参与到需求分析的准备中来,以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。 3、IT中心分析人员或用户理解有误 系统分析人员不可能都是全才,更不可能是行业方面的专家。用户表达的需求,不同的分析人员可能

软件需求分析(案例答案)

案例one:教学管理系统(用例驱动的交互式需求获取) 以一个教学管理系统JXGL的分析与设计作为示例,说明用例驱动技术在软件项目开发中的应用。 高等学校的教学管理内容十分丰富,工作繁多。作为一个示例,规定开发教学管理系统JxGL只处理每学期的课程选修注册和学生的成绩管理。教学管理系统JXGL的用户是学校的学生、教师和教学管理员。学生使用JXG系统查询新学期将开设的课程和授课教师的情况,选择自己要学习的课程,并进行登记注册。学生还可以使用JXGL系统查询自己的课程成绩。教师使用JXGL系统查询新学期将开设的课程、参加听课的学生情况,以及学生的考试成绩。教学管理员使用JXGL系统进行教学管理,包括新学期的课程选课注册管理和学生成绩管理。 1.需求描述: 对教学管理系统JXGL要求提供两个方面的服务: (1)选课管理,负责新学期的课程选课注册工作; (2)成绩管理,负责学生成绩管理。 在选课管理方面应填写的用户需求描述如下。 (1)录入与生成新学期课程表 教学管理员在新学期开始前录入新学期课程,打印将开设的课程目录表,供师生参 考选择。若某课程的实际选课学生少于10人,则停开该课程,把该课程从课程目 录表中删除;若某课程的选课学生多于30人,则停止选课。 (2)学生选课注册 新学期开始前一周为选课注册时间,在此期间学生可以选课注册,并且允许改变或 取消注册申请。 每个学生选课不超过4门课程。每门课程最多允许30名学生选课注册。 学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注册。在 选课注册结束后,教学管理员打印学生选课注册名单和开课通知书,送交有关部门 和授课教师。 (3)查询 可以查询课程信息、学生选课信息和学生、教师信息。 学生、教师、教学管理员可以查询课程表,获得课程信息。查询的关键词以是:课 程名,授课教师名,学分。 教师、教学管理员可以查询学生选课情况。查询的关键词可以是:学生名、程名, 授课教师名,学分。学生只允许查询自己的选课信息,不允许查询别人选课信息。 学生、教师、教学管理员可以查询学生或教师的信息。查询的关键词可以是学生名、 教师名,性别、班级、职称。 (4)选课注册信息的统计与报表生成。 教学管理员对学生的选课注册信息进行统计(按课程,按学生,按班级),印汇总统 计报表。 在成绩管理方面应填写的用户需求描述如下: (1)成绩录入:

软件开发案例分析需求模板汇总

E-Storage Management System Software Requirements Specification 电子化仓储管理系统软件需求规格说明书 版权所有不得复制 Copyright ? BroadenGate Technologies, Co., Ltd. All Rights Reserved

Revision Record 修订记录

Catalog 目录

错误!未找到引用源。 Keywords 关键词:仓储管理 Abstract 摘要:本文主要描述电子化仓储管理系统的设计需求,包括功能需求和性能需求,以及其他设计约束等。 List of abbreviations 缩略语清单:

1Introduction 简介 1.1Purpose 目的 1.2Scope 范围 本文档包含电子化仓储管理系统V1.0的对外接口和功能描述,以及和外部的约束关系。2General description 总体概述 2.1Software perspective 软件概述 2.1.1About the Project 项目介绍 2.1.2Environment of Pruduct 产品环境介绍 2.2User characteristics 用户特征 2.3Software function 软件功能 2.4Assumptions & Dependencies 假设和依赖关系 3Specific Requirements 具体需求

3.1Functional Requirements 功能需求 我们采用面向对象分析的方法来作为主要的系统建模方法,使用UML(Unified Modeling Language)作为建模语言。UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。在UML中,从任何一个角度对系统所作的抽象都可能需要几种模型来描述,而这些来自不同角度的模型图最终组成了系统的映像。 Use Case描述的是“actor”(用户、外部系统以及系统处理)是如何与系统交互来完成时,该模型将来可 派生出动态对象模型。 设计Use-case时,我们遵循下列步骤: 第一步: 识别出系统的管理员。管理员可以是用户、外部系统,甚至是外部处理,通过某种途径与系统交互。重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能,并指明这些功能的执行者是谁。尽可能地确保所有管理员都被完全识别出来。 第二步: 描述主要的Use Case。可以采取不断地问自己“这个管理员究竟想通过系统做什么?”来准确地描述Use Case。 第三步: 重新审视每个Use Case,为它们下了详尽的定义。 电子化仓库管理系统是通过对入库业务、出库业务、仓库调拨、库存调整业务信息的管理,提高仓库管理信息的实时性和准确性,达到即时库存管理的功能,并有效控制并跟踪业务的物流和成本管理全过程,实现完善的企业仓储信息管理。系统中设计了装箱算法,为客户提供合理有效的装箱方案,保证了货物集装箱的利用。本系统可以提供有关库存情况的准确信息,增强了作业的准确性和快捷性、减少了整个物流中由于商品误置、送错、偷窃、损害和库存、出货错误等造成的损耗,并最大限度减少存储成本。 总体功能时序图:(如图3-1所示)

培训需求分析的方法和工具

培训需求分析的方法和工具 培训需求分析是企业培训的出发点,也是最重要的一步工作。如果需求分析不准确,就会让接下来的培训偏离轨道,做无用功,浪费企业的人力、物力和财力,却收不到应有的效果。企业要进行有效的需求分析,就必须采取合适方法和工具,本文全面介绍了通常情况下培训需求分析使用的方法以及对应的工具。 一、需求分析的方法和工具 1.1 调研问卷法 调研问卷法是最普遍也最有效的收集资料和数据的方法之一。一般由培训部门设计一系列培训需求相关问题,以书面问卷的形式发放给培训对象,待培训对象填写之后再收回进行分析,获取培训需求的信息和数据。 调研问卷法进行培训需求分析,可以遵循以下五个步骤,见表1: 在设计调研问卷的问题时,应该注意下几个问题: 1、问题尽量简短,并注意使用简单的、固定用法的术语,避免使用读者不了解或者容易引起歧义的名词; 2、一个问题只涉及一件事,避免“结构复杂”的问句; 3、题目设计要简单,不要使作答者作计算或逻辑推理; 4、避免出现诱导答案的问题,保证作答者完全陈述自己观点。

备注:填表时在对应的内容下面用“√”标明。 1.2 访谈法 访谈法也是数据收集的一种重要方法。它是指为了得到培训需求的数据和信息,与访谈对象进行面对面交流的活动过程。这个过程不只是收集硬性数据,比如事实、数据等,包括印象、观点、判断等信息。 访谈法可以遵循以下几个步骤进行,见表3:

1.3现场取样法 现场取样法一般较多使用于服务性行业的培训需求调查(如饭店、卖场等),是通过选取培训对象现场实际工作的部分片段进行分析,以确定培训需求的一种分析方法。现场取样法主要包括两种形式:拍摄和取样。 拍摄是指在培训对象的工作环境中安装监控录影机、摄像机等拍摄设备,对培训对象的现场工作过程进行实际拍摄,事后通过录影带进行观察分析,得出培训需求结论。表5为拍摄样板的示例。

软件需求分析考试题

一、单选题(每空1分,共20分,请在备选答案中选择唯一一个正确的选项) 1、产品特性可以称为质量属性,在众多质量属性中,对于开发人员来说重要的属性有哪些 (B ) A 有效性、效率、灵活性、互操作性 B 可维护性、可移植性、可重用性、可测试性 C 完整性、可靠性、健壮性、可用性 D 容错性、易用性、简洁性、正确性 2、需求包括11个方面的内容,其中网络和操作系统的要求属于(B),如何隔离用户之间的数据属于(C),执行速度、相应时间及吞吐量属于(D),规定系统平均出错时间属于(A )。 A 质量保证B环境需求C安全保密需求 D 性能需求 3、需求分析过程应该建立3种模型,它们分别是数据模型、功能模型、行为模型。以下几种图形中,(B)属于功能模型,(A)属于数据模型,(C)属于行为模型。 A 实体-联系图(ERD) B 数据流图(DFD) C 状态转换图(STD) D鱼骨图 4、常用的需求分析方法有:面向数据流的结构化分析方法(SA),面向对象的分析方法(OOA),下列(D)不是结构化分析方法的图形工具。 A决策树B数据流图C数据字典D快速原型 5、软件开发中,原型是软件的一个早期可运行的版本,它反映最终系统的部分重要特性。其中,(B)和(C)用完就可以丢弃,而(A)围绕原型修改、增加。 A 进化型 B 探索型C实验型 D 以上都是 6、(D)用于描述数据的处理过程。 A 数据字典B决策树C决策表 D 数据流图 7、DFD的基本符号不包括下列哪种(A) A 数据字典 B 加工 C 外部实体 D 数据流 E 数据存储文件 8、DD的主要字典条目包括以下哪种(E) A数据流B文件 C 数据项D加工E以上都是 9、常用的动态分析方法不包括以下哪种(B) A 状态迁移图 B 层次方框图C时序图 D Petri网 10、需求分析阶段的文档包括以下哪些(E) A 软件需求规格说明书B数据要求说明书C初步的用户手册D修改、完善与确定软件开发实施计划E以上都是 11、需求验证应该从下述几个方面进行验证:(C) A 可靠性、可用性、易用性、重用性B可维护性、可移植性、可重用性、可测试性 C一致性、现实性、完整性、有效性D 功能性、非功能性 12、风险管理的要素包括哪项(D) A风险评价B风险避免C风险控制D以上都是 13、下列描述中错误的是(D) A每一个集成的需求变更必须能跟踪到一个经核准的变更请求。 B变更过程应该做成文档,尽可能简单,当然首要的是有效性。 C所有需求变更必须遵循过程,按照此过程,如果一个变更需求未被采纳,则其后过程不再予以考虑。 D可以从数据库中删除或修改变更请求的原始文档。 二、填空题(每空2分,共30分) 1、软件开发的生命周期包括(需求分析)、软件设计、代码实现、(测试)、(实施)、 维护,共六个阶段。

需求分析案例

系统需求分析报告 ——关于信息工程学院学籍管理系统 §1概述 随着社会的发展,经过本院全体师生的共同努力,学校的规模不断的扩大,日常教学活动中提取相关信息,以反映教学情况。传统的手工操作方式,易发生数据丢失,统计错误,劳动强度高,且速度慢。使用计算机可以高速,快捷地完成以上工作。在计算机联网后,数据在网上传递,可以实现数据共享,避免重复劳动,规范教学管理行为,从而提高了管理效率和水平。学籍管理信息系统以计算机为工具,通过对教务管理所需的信息管理,把管理人员从繁琐的数据计算处理中解脱出来,使其有更多的精力从事教务管理政策的研究实施,教学计划的制定执行和教学质量的监督检查,从而全面提高教学质量。 §1.1背景 项目开发的提出者为学校的业务管理人员,开发者为毛彩霞,已明确用户有:在校任课老师和就读学生、班主任、教务处及相关的管理人员;潜在用户有:已经毕业的学生、用人单位、学生家长。 用户特点: 在校任课老师、班主任、教务处各作为单独的一类用户,在校就读学生、已经毕业的学生、用人单位、学生家长作同一类用户。在校任课老师、用人单位、教务处的管理人员和已经毕业的学生大专以上学历,班主任、在校就读的学生高中以上学历,学生家长学历不定,用可能低于高中学历。 项目经费有学校出,开发周期一年。 §1.2 系统目标 软件开发的意图为便于学校的管理,方便查看有关学校及学生的情况。 如教务处对学生成绩的修改、删除、查找、添加等。 §1.3业务模式 (略) §1.4现行组织机构及业务现状 在学籍管理中,需要从大量的日常教学活动中提取相关信息,以反映教学情况。传统的手工操作方式,易发生数据丢失,统计错误,劳动强度高,且速度慢。 §2用户需求 §2.1业务需求 1、使用范围 按成都信息工程学院全日制学生学籍管理等相关文件完成本科和

软件需求分析重点-

软件需求分析重点 第1 章软件需求基础知识 返工的成本占了总开发成本的30%-50%,而对于返工的情况,70%-80%是国需求错误引起的。(11) 在对所有讨论问题有了更深入的了解之前不要急于回答。不能充分理解需求,就会作出过于乐观的估计,最终不可避免地陷入超支的泥潭。(13-14)造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确以及地需求的分析不透彻等。给出估算结果时,应该提供范围(最好的情况,最可能的情况和最糟的情况)或把握程度(“我有九成把握在三个月内完成”)。(14) 从产品的实际用户处收集需求这一过程是不可替代的。(18) 第2 章客户眼中的需求 某些需求问题源于混淆了不同层次的需求(业务需求、用户需求和功能需求)。(19) 要想开发出优秀的软件产品,必须以优质需求为基础精心制定计划。(20)不要指望项目涉众天生知道如何合作进行需求开发。必须花时间讨论如何最有效地进行协作。(22) 需求审阅是最有价值的保证软件质量的活动之一。(25) 需求批准过程的所有参与者都应该明白签字意味着什么,否则会出现很多问题。(25) 不可能在项目初期就能明确所有的需求,需求肯定要随时间的推移而发生变化。(26) 第3 章需求工程的推荐方法 熟练的需求分析员应具备以下特点:耐心,思维条理性强,有良好的交际和沟通能力,理解产品应用领域,并且掌握丰富的需求工作技术。(29)为每类用户选择代言人(31)

观察用户工作的过程(31) 跨项目重用需求(32) 过早地以尚不明确的需求为基础进行开销和进度评估是非常不可靠的。(37)38图表 不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。(38) 第4 章需求分析员 相比缺乏经验的需求分析员,使用经验丰富的需求分析员能使项目所需求的工作量减少三分之一。(42) 优秀的需求分析员应同时具备出色的交流、引导和人际交待能力,具备技术和业务领域的丰富知识,以及适合这项工作的相应个性。耐心和真诚的合作愿望是关键的成功因素。(44) 需求分析员必须研究可能出错的情形。(44) 第5 章确定产品前景与项目范围 第6 章获取客户的需求 能否让开发人员更准确地了解用户需求,将决定软件需求工作能否取得成功,进而影响到软件开发的成功。(62) 项目伊始就应确定谁来担任问题的决策人。(72) 第7 章聆听客户的需求 需求开发工作的成果就是项目涉众之间就被处理的需求达成共识。(75) 需求获取的参与者在理解问题之前要抵制住诱惑,不要急于设计系统。 要强调用户任务,而不是用户界面,要强调根本需要,而不是用户表达出来的期望,这样有助于项目团队避免过早是制定设计的细节。 在软件开发中,需求获取也许是最困难、最关键、最容易出错和最需要沟通的一个环节。(76)

软件需求分析方法

需求分析方法 一需求分析概括 需求分析应该先了解宏观的问题,再了解细节的问题。 一个应用软件系统(记为S)的涉及面可能很广,可以按不同的问题域(记为D)分类,每个问题域对应于一个软件子系统。 S={D1,D2,D,…Dn} 问题域Di由若干问题(记为P)组成,每个问题对应于子系统中的一个软构件。 Di={P1,P2,P3,…Pn} 问题Pi有若干个行为(或功能,记为F),每个行为对应于软构件中的实现接口。 Pj={F1,F2,F3,…Fk} 需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。在写需求说明书时,应该注意两个问题: 1.最好为每个需求注释“为什么”,这样可以让程序员了解需求的本质,以便选用最合适 的技术来实现此需求 2.需求说明不能有”二义性”,更不能前后矛盾。如果有二义性或前后矛盾,即要重新分 析此需求。 二需求分析方法论 第一阶段:“访谈式”

第一阶段是和具体用户方的领导层、业务层人员的访谈沟通,主要目的是从宏观上把握用户的具体需求方向和趋势,了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。 建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局,最好能指定本次项目的接口人。 实现手段:访谈、调查表格 输出成果:调查报告、业务流程报告 第二阶段:“诱导式” 结合第一阶段的基本信息,做出简单的用户流程页面,同时结合以往的项目经验对用户采用诱导式,启发式的调研方法和手段,和用户一起探讨业务流程设计的合理性、准确性、习惯性。用户可以操作简单演示的DEMO,感受整个业务流程的设计合理性、准确性等等问题,以及提出改进意见和方法。 实现手段:诱导(拜访)、原型演示 输出成果:调研分析报告、原型反馈报告、业务流程报告 第三阶段:“确认式” 此阶段在上述两个阶段成果的基础上,进行具体的流程细化、数据项的确认阶段。这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表,并能清晰地向用户描述系统的业务流设计目标。通过审查,提出反馈意见,并对已经可接受的报告、文档签字确认。 实现手段:拜访(回顾、确认),提交业务流程报告、数据项表;原型演示系统 输出成果:需求分析报告、数据项、业务流程报告、原型系统反馈意见(后三者可以统一归到需求分析报告中)

需求分析方法主要步骤

1.1主要步骤 遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。 需求涉及的方面有很多。 在功能方面,需求包括系统要做什么,相对于原系统目标系统需要进行哪些修改,目标用户有哪些,以及不同用户需要通过系统完成何种操作等。 在性能方面,需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。 在运行环境方面,需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求,以及对操作系统、数据库和浏览器等软件配置的要求。 在界面方面,需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求,识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题,要满足哪些限制条件,这个过程就是对需求的获取。开发人员通过调查研究,要理解当前系统的工作模型和用户对新系统的设想与要求。 此外,在需求的获取时,还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如,多长时间需要对系统做一次备份,系统对运行的操作系统平台有何要求,发生错误后重启系统允许的最长时间是多少等。

遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求,开发人员应该采取科学的需求获取方法。在实践中,获取需求的方法有很多种,比如,问卷调查、访谈、实地操作、建立原型和研究资料等。 问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析,开发人员便可以得到一些有用的信息。采用这种方法时,调查问卷的设计很重要。一般在设计调查问卷时,要合理地控制开放式问题和封闭式问题的比例。 开放式问题的回答不受限制,自由灵活,能够激发用户的思维,使他们能尽可能地阐述自己的真实想法。但是,对开放式问题进行汇总和分析的工作会比较复杂。 封闭式问题的答案是预先设定的,用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理,但是会限制用户的思维。 访谈通过开发人员与特定的用户代表进行座谈,进而了解到用户的意见,是最直接的需求获取方法。为了使访谈有效,在进行访谈之前,开发人员要首先确定访谈的目的,进而准备一个问题列表,预先准备好希望通过访谈解决的问题。在访谈的过程中,开发人员要注意态度诚恳,并保持虚心求教的姿态,同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样,开发人员要根据用户的身份特点,进行提问,给予启发。当然,进行详细的记录也是访谈过程中必不可少的工作。访谈完成后,开发人员要对访谈的收获进行总结,澄清已解决的和有待进一步解决的问题。 关注用户的行为而不是他们的言语。

需求分析与测试的重要性

需求分析与测试的重要性 读《软件工程案例教程》有感 对于学习软件工程这门课程,我认为有许多东西要学习。其实在我看来学习这门课程的精髓是学习一种方法。是一个如何去分析和处理问题的过程,应该说其范畴已经远远不止局限于该门课程,成为了一个综合的一个能够解决问题的思想集合。读完软件工程案例教程这本书,我觉得自己受益匪浅。 整本书的内容逻辑很清晰明了,由浅入深循序渐进,首先我就大概描述下我们所学的内容,第一章是从整体分析软件工程这门学科的发展和所处的社会环境,接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模和测试等。对于这本书我主要对需求分析和测试比较感兴趣,在这我要着重的谈一些自己的心得体会以及自己的看法。 一.需求分析 1.1需求分析的重要性 一款成功的软件是建立在成功的需求分析之上的,而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决,而开发人员开始帮助用户解决这个问题,沟通就开始了。由此我们可以看出需求分析的重要性。 需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识:用户知道需求是什么,我们所要做的就是和他们交谈从他们那里得到需求,只要问用户系统的目标特征,什么是要完成的,什么样的系统能适合商业需要就可以了,但是实际上需求获取并不是想象的这样简单,这条沟通之路布满了荆棘。首先需求获取要定义问题范围,系统的边界往往是很难明确的,用户不了解技术实现的细节,这样造成了系统目标的混淆。 其次是对问题的理解,用户对计算机系统的能力和限制缺乏了解,任何一个系统都会有很多的用户或者不同类型的用户,每个用户只知道自己需要的系统,而不知道系统的整体情况,他们不知道系统作为一个整体怎么样工作效率更好,也不太清楚那些工作可以交给软件完成,他们不清楚需求是什么,或者说如何以一种精确的方式来描述需求,他们需要开发人员的协助和指导,但是用户与开发人员之间的交流很容易出现障碍,忽略了那些被认为是"很明显"的信息。最后是需求的确认,因为需求的不稳定性往往随着时间的推移产生变动,使之难以确认。为了克服以上的问题,必须有组织的执行需求的获取活动。 1.2需求分析的原则 (1)需求分析必须能够表达和理解问题的数据域和功能域。数据域包括数据流、数据内容和数据结构,而功能域反映上述3方面的控制信息。 (2)需求分析要把一个复杂问题按功能进行分解并逐层细化。通常,软件系统要处理的问题如果太大、太复杂就很难理解,若划分成几部分,并确定各部分间的接口,就可完成整体的功能。在需求分析过程中,软件系统的用户需求中的数据、功能和行为都应细化。 (3)需求建模。模型可以帮助系统分析人员更好地理解软件系统的数据、功能和行为,这些模型是软件工程中下一阶段进行系统设计的基础。 1.3需求分析的注意事项

软件需求分析报告书实例

需求分析说明书 1. 引言 (3) 1.1 编写目的 (3) 1.2 项目风险 (3) 1.3 预期读者和阅读建议 (5) 1.4 产品范围 (5) 1.5 参考文献 (5) 2. 系统总体概述 (6) 2.1 目标 (6) 2.2 用户类和特性 (7) 2.3 运行环境 (7) 2.3.1 硬件环境 (7) 2.3.2 软件环境 (7) 2.4 设计和实现上的限制 (7) 2.5 假设和约束(依赖) (8) 2.5.1 产品的SEO排名 (8) 2.5.3系统的安全 (8) 3. 外部接口需求 (8) 3.1 用户界面 (8) 3.2 硬件接口 (8) 3.3 软件接口 (8) 3.4 通讯接口 (9) 4. 系统特性 (9) 4.1 说明和优先级 (9) 4.2 激励/响应序列 (9) 4.3 功能需求 (9) 4.4 功能详述 (12) 4.4.1以使用软件的汽车用户为例: (12) 5. 其它非功能需求 (13) 5.1 性能需求 (13) 5.2 安全措施需求 (13) 5.3 安全性需求 (14) 5.4 操作需求 (14) 5.5 软件质量属性 (14) 5.6 业务规则 (14) 5.7 用户文档 (14) 6. 词汇表 (14) 6.1 SSH (14)

6.2 JAVA (14) 6.3 MYSQL (15) 7. 待定问题列表 (15)

1. 引言 1.1 编写目的 本需求分析说明书对本项目第一阶段的内容进行分析,对需求细节和实现方式进行了较为详细的阐述。本需求说明书供业务和科技部门人员、软件需求提供人员、软件的概要设计人员、软件的开发人员、软件的测试人员使用,并作为产品验收确认的依据。 需求分析是在可行性研究的基础上,将用户对系统的描述,通过开发人员的分析概括,抽象为完整的需求定义,再形成一系列文档的过程。可行性研究旨在评估目标系统是否值得去开发,问题是否能够解决,而需求分析旨在回答"系统做什么"的问题,确保将来开发出来的软件产品能够真正满足用户的需要。 构建一个软件系统最困难的工作是确定构建什么。其他任何工作都不会像这部分工作那样,在出错之后会如此严重地影响随后实现的系统,并且在以后修补竟会如此的困难。 需求分析是一个非常重要的过程,它完成的好坏直接影响后续软件开发的质量。一般情况下,用户并不熟悉计算机的相关知识,而软件开发人员对相关的业务领域也不甚了解,用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会为需求分析带来很大的困难。所以,开发人员和用户之间充分和有效的沟通在需求分析的过程中至关重要。 有效的需求分析通常都具有一定的难度,一方面是因为交流存在障碍,另一方面是因为用户通常对需求的陈述不完备、不准确和不全面,并且还可能不断地变化。开发人员不仅需要在用户的帮助下抽象现有的需求,还需要挖掘隐藏的需求。此外,把各项需求抽象为目标系统的高层逻辑模型对日后的开发工作也至关重要。合理的高层逻辑模型是系统设计的前提。 在进行需求分析的过程中,首先要明确需求分析应该是一个迭代的过程。由于市场环境的易变性以及用户本身对于需求描述的模糊性,需求往往很难做到一步到位。需求分析不仅仅是属于软件开发生命周期早期的一项工作,而且还应该贯穿于整个生命周期中,它应该随着项目的深入而不断地变化。 此外,为了方便后续的评审和测试等工作,需求的描述应该尽量做到:具体、详细、可以测量和可以实现,并且基于时间。 1.2 项目风险 政策风险分析: 随着社会的进步与人们生活水平的提高大幅度增加,尤其在我国汽车进入家庭的条件下,需要更多的适合现代汽车技术要求和社会经济承受能力的汽车维修检测设备,为了让四轮定位仪市场变得规范、有序,中国汽车保修设备行业协会与全国汽车维修标准化技术委员会于2004年,制定了四轮定位仪的行业标准(标准号JT/T505-2004),国家交通部2004年国标GB/T16739.1-.2-2004《汽车维修业开业条件》规定:一、二类汽车维修企业必须配备

如何进行软件需求分析

软件需求分析(Software Reguirement Analysis)是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端,也是项目实施最重要的关键点。据有关的机构分析结果表明,我们设计的软件产品存在不完整性、不正确性等问题80%以上是需求分析错误所导致的,而且由于需求分析错误造成根本性的功能问题尤为突出。因此,一个项目的成功软件需求分析是关键的一步。 一、软件需求分析理论 如果我们用数学方法来描述软件需求分析,可以将一个应用软件定义为S,可能应用软件涉及功能性问题非常广,我们用抽象化理论分析,可以划分为各个功能域,可以用D1、D2、… Dn表示,那么,我们可以用一个表达式描述为S={D1,D2,D3,…Dn} 但是,功能域Di依然存在着有若干个问题P1、P2、P3、… Pm组成,并且每个功能对应于子系统中的一个软构件,我们可以表示为 Di={P1,P2,P3,…Pm} 同样,功能Pj有若干个行为F1、F2、F3、… Fk,每个行为对应于软构件中的实现方法 Pj={F1,F2,F3,…Fk} 一个软件包含了所有功能的集合,同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求,经过需求问题识别,进行分析、消化与综合,制订规格说明,评审,分为四个阶段,形成用户需求与设计同步,设计满足用户需求目标。 需求分析方法始终贯穿着吸收、同化、贯彻方法和手段,用商业化行为解决需求与实现中存在的矛盾,解决用户需求与商业化产品融通,解决规范与个性化追求。 二、软件需求分析目标 软件需求分析的主要实现目标: 1)对实现软件的功能做全面的描述,帮助用户判断实现功能的正确性、一致性和完整性,促使用户在软件设计启动之前周密地、全面地思考软件需

需求分析与原型模型设计

需求分析与原型模型设计 首先,先来看下客户的现实困扰:开课计划书以群发邮件的形式发给所有老师。每个 老师收到邮件后,在规定的截止时间之前,要将自己的名字填入自己希望报的课程的那一 行“任课教师”列,如果有起讫周序的要求,可以填入对应列中。如果对于安排等有其他要求可以填入“备注”等。如果没有特别要求,备注栏等就可以空着。然后填好后,老师 以邮件形式发回给负责人。负责人查阅每封邮件,打开每个excel,查看每个老师的填报,最后手动汇总成一个excel。 困扰在于:群发邮件、群收邮件、催收邮件、汇总每个老师的excel,工作量巨大。 一、需求分析(NABCD模型) 好了,客户已经向我们阐述了他所要的需求,然而具体要如何去分析,去理解客户真 正想要的是什么呢?我们小组两人抽空看了《构建之法》,就着里面介绍的NABCD模型来试着按部就班的分析下客户的需求,以尽可能的有条理的去说服客户。 N(Need需求):客户说,他的困扰在于群发邮件,催收邮件。我们先来看这两点,试着分析下客户想表达的是什么。首先,现在的邮件应用已经很完善了,不管是群发,群收,都能实现,那么客户为何还要提出这个困扰呢?我们结合客户的工作,给出了我们的 理解:客户实际上困扰的不是有没有群发邮件这个功能,反而是选择群发对象的繁琐。比如,每次要群发的时候总要从众多好友列表中找出那么几个。虽然我们可以事先建个分组,把需要群发的对象拉入里面,可是不要忘了客户后面还有催收。催收对象是那些还没完成的,那么总不能再建个分组吧。所以,针对这点,我们要解决的就是实现事先把要群发的 对象找出来,客户不管是群发还是催收只要点击就完事,不用再手工去查找群发对象,具 体做法在A阶段分析。 我们再来看客户的其他困扰:群收邮件。这个词看着感觉很奇怪,有群收邮件这个概 念么?什么叫群收邮件,难不成邮件还能强制要求一群人发过来让你接收?当然不可能, 还是再次结合客户的工作,我们可以很容易的理解出,客户想表达的只是如何从收件箱中 那么多的接收邮件中找出相关老师发过来的邮件。什么意思,这么说吧,客户发任务给各 个老师,然后定一个期限前都要回复邮件对吧。那在这期间,难道就不会接收到其他无关 的邮件么,比如你的博客被评论了,收到一份邮件,比如你的学生发了些问题来请教等等。这样一来,收件箱就变得乱了起来,所以我们要解决的就是如何屏蔽其他无关的邮件,只 接收相关的邮件,怎么做还是留到下阶段A中分析。 最后,再来看看客户最后一个困扰:汇总每个EXCEL,工作量巨大。这点就很好理解了,没什么好分析的,就是客户手工汇总的话太麻烦,工作量大,所以要解决的就是自动 把汇总工作完成,让客户可以直接看到汇总后的内容即可。同样,做法A阶段分析。 A(Approach,做法):下面就是分析具体如何做了。我们小组定位的是APP应用,所以结合N阶段总结的需求,我们组的APP要能实现以下几点功能: 1. 把要群发的对象分组,并能在该分组内实现区分有回复以及没回复的对象,并将他们分组。

软件需求分析方法

欢迎阅读 软件需求分析(Software Reguirement Analysis)是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的、可验证的一个基本依据。 1)对实现软件的功能做全面的描述,帮助用户判断实现功能的正确性、一致性和完整?性,促 使用户在软件设计启动之前周密地、全面地思考软件需求; 2)了解和描述软件实现所需的全部信息,为软件设计、确认和验证提供一个基准;

3)为软件管理人员进行软件成本计价和编制软件开发计划书提供依据; 需求分析的具体内容可以归纳为六个方面:软件的功能需求,软件与硬件或其他外部系统接口,软件的非功能性需求,软件的反向需求,软件设计和实现上的限制,阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息,使得软件设计人员和软件测试人员不再需要需求方的接触。这就要求软件需求分析内容应正确、完整、一致和可验证。此外,为保证软件设计质量,便于软件功能的休整和验证,软件需求表达无岔意性,具有可追踪性和可修改性。2.1、????? 软件功能需求 1 不 (5)??? 尽可能不使用“待定”这样的词。所有含有待定内容的需求都不是完整的文件,如果出现待定的部分,必须进行待定部分内容说明,落实负责人员、落实实施日期。 2)功能描述的无岔意性和可追踪性 需求功能描述的无岔意性、可追踪性和规范化: (1)??? 功能描述必须清晰地描述出怎样输入到怎样输出,并且输入、输出描述应对应有数据流描述、控制流描述图,这些描述必须与其它地方描述一致;

(2)??? 可以用语言、方程式、决策表、矩阵或图等对功能的描述。如果选用语言描述必须使用结构化的语言,描述前必须说明该步骤(或子功能)的执行是顺序,选择, 重复,还是并发,然后说明步骤逻辑。整个描述必须单入单出。 (3)??? 描述时,每一个功能名称和参照编号必须唯一,且不要将多个功能混在一起进行描述,这样便于功能的追踪和修改。 (4)??? 功能描述应注意需求说明和程序设计的区别。需求设计仅仅是软件的功能设计,它给出软件运行的的外部功能描述,以及为了实现这一外部功能必须做哪些事情(采 2.2、 2.3、 (2)??? 处理容限、精度、采样参数的分辨率,误差处理等; (3)??? 可靠性的MTBF要求,可维护性、安全性要求等。(对可能的不正常的输入给以正常响应是可靠性的重要内容,这属于功能性需求。) 2.4、????? 软件反向需求 软件的反向需求描述软件在那些情况下不能做什么。这一条是随软件实际要求而定。有两类情形需要采用反向需求的形式。第一种情况:某些用户需求适宜采用反向形式说明,如数据安全性要求属于这类形式。第二种情况:对一些可靠性和安全性要求较高的软件,有些必须描述软件不能做些什么。如控制点火时序,我们必须交代清楚在那些情况下不能点火,否则会造成故障。

软件需求分析习题大全

软件需求分析习题大全 Coca-cola standardization office【ZZ5AB-ZZSYT-ZZ2C-ZZ682T-ZZT18】

习题集 一、单项选择题 1、需求分析最终结果是产生()。 A.项目开发计划 B.可行性分析报告 C.需求规格说明书 D.设计说明书答案:C 2、需求分析中,开发人员要从用户那里解决的最重要的问题是()。 A.让软件做什么 B.要给软件提供哪些信息 C.要求软件工作效率怎样 D.让软件具有何种结构 答案:A 3、需求规格说明书的内容不应包括对()的描述。 A.主要功能 B.算法的详细过程 C.用户界面和运行环境 D.软件性能答案:B 4、需求规格说明书的作用不应包括()。 A.软件设计的依据 B.用户与开发人员对软件要做什么的共同理解 C.软件验收的依据 D.软件可行性研究的依据 答案:D 5、下面关于面向对象方法中消息的叙述,不正确的是()。 A.键盘、鼠标、通信端口、网络等设备一有变化,就会产生消息 B.操作系统不断向应用程序发送消息,但应用程序不能向操作系统发送消息 C. 应用程序之间可以相互发送消息 D.发送与接收消息的通信机制与传统的子程序调用机制不同 答案:B 6、面向对象技术中,对象是类的实例。对象有三种成份:()、属性和方法(或操作)。 A. 标识 B. 规则 C. 封装 D. 消息 答案:A 7、软件需求分析阶段的工作,可以分成以下四个方面:对问题的识别、分析与综合、 制定规格说明以及()。 A.总结 B.实践性报告 C.需求分析评审 D.以上答案都不正确 答案:C 8、软件需求规格说明书的内容不应包括对()的描述。 A.主要功能 B.算法的详细过程 C.用户界面及运行环境 D.软件的性能 答案:B 9、产品特性可以称为质量属性,在众多质量属性中,对于开发人员来说重要的属性有哪些(B ) A 有效性、效率、灵活性、互操作性 B 可维护性、可移植性、可重用性、可测试性 C 完整性、可靠性、健壮性、可用性 D 容错性、易用性、简洁性、正确性

采用简化原型法进行需求分析

采用简化原型法进行需求分析 1 前言 需求分析阶段是治理信息系统(MIS)开发最重要的阶段。MIS开发的需求阶段首先是了解和澄清用户的需求,然后严格地定义被开发的软件系统的需求规格说明书。常用的软件需求分析方法有面向数据流的结构化分析方法、面向数据结构的Jackson方法、面向对象的方法和原型法等。原型法由于改变了系统的分析、设计和实现三个顺序阶段的观点,改变了传统的自顶向下的开发模式,降低了软件需求的风险,因此得到了广泛的应用,非凡是在致力于某一领域MIS开发的软件公司,如致力于电力MIS开发的公司。但作者在长期的MIS 需求分析过程中,发现原型法有以下缺陷: 1)原型的设计和修改工作量大,增加了系统的开发成本; 2)由于用户不关心或不理解原型的概念和实现,而且存在较大期望,使得与实际系统差别较大的原型增加了需求分析人员与用户的交流难度;无论是水平原型,还是垂直原型都不能反映实际系统的全貌; 3)软件需求主要包括:功能需求、界面需求、性能需求、环境需求、可靠性需求、安全保密需求、资源使用需求、软件成本消耗与开发进度需求和目标需求。原型法中的原型难以表达软件的后七项需求; 4)原型法强调用户和开发人员不断对原型进行不断修改和补充,直到用户感到满足为止。在时间紧和任务重的大型MIS项目中,这种情况实际难以保证,非凡是在用户单位和开发单位距离较远时。 本文结合治理信息系统项目实施的实践,提出一种新的需求分析方法-简化原型法。这种方法根据数据库应用的特点,将需求分析分为两个阶段,并简化了作为需求分析工具的系统原型。 2 简化原型法需求分析的第一个阶段 治理信息系统属于数据库应用。数据库应用需求分析应该围绕数据,而不是功能展开,因此应该首先解决"有什么",然后再明确"做什么"。第一个阶段就是要解决"有什么",即由项目经理与用户进行协商,确定系统的技术协议,因此可以称为技术协议阶段。技术协议需要开发方的项目经理与用户单位的技术主管签字并盖章,并以合同附件的形式存在。技术协议的主要内容有:系统的边界、系统处理的业务、与其它系统的接口、工程的进度控制、培训安排和技术服务承诺。 2.1 系统的边界

需求分析习题及答案

第三章需求分析 一. 填空题 1.需求分析的步骤, , , 。 2.需求分析阶段需编写的文档有,,。 3.系统规格说明,数据要求,, ,这四份文档资料是在书写文档阶段必需完成的。 4.在书写文档阶段,数据要求主要包括通过需求分析建立起来的,以及描绘数据结构的层次方框图。 5.对于计算机程序处理的数据,其数据域应包括, , 和数据结构。 6.数据内容即是。 7.把一个功能分解成几个子功能,并确定, 就属于横向分解。 8.软件需求的逻辑视图给出, 而不是实现的细节。 9. 功能一般用, 来表示。 10.结构化分析方法是, 进行需求分析的方法. 11.描述结构化分析方法的工具有,,,判定表,判定树。 12. SA方法中自顶向下的分析策略主要是和。 13.数据流图的基本组成部分有,,,。 14.数据流图的特性,,,。 15.数据流图和数据字典共同构成了系统的模型,是需求规格说明书的主要组成部分。 16.分析员通过需求分析,逐步细化对软件的需求,描述软件主要处理的,并给软件开发提供一种可转化为,和的数据与功能表示。 17.需求分析阶段研究的对象是软件项目的。 18.数据流图的基本符号包括,,,。19.在需求分析阶段常用的图形工具有,,。20.需求分析应交付的主要文档是。 二. 选择题 1. 需求分析中开发人员要从用户那里了解() A.软件做什么B.用户使用界面C.输入的信息D.软件的规模 2. 需求分析阶段的任务是确定() A.软件开发方法 B.软件开发工具C.软件开发费 D.软件系统的功能 3. 需求分析阶段最重要的技术文档之一是非曲直()。 A.项目开发计划 B.设计说明书 C.需求规格说明书 D.可行性分析报告

相关文档
最新文档