需求系统分析员

需求分析的几个问题需求分析的任务与用户沟通获取需求的方法需求工程分析建模软件原型需求管理需求分析什么是软件需求IEEE软件工程标准词汇表(1997)将需求定义为:(1)用户解决问题或达到目标所需的条件或能力.
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力.
(3)一种反映上面(1)或(2)所描述的条件或能力的文档说明.
其他几种关于"需求"的定义:需求是用户所需要的并能触发一个程序或系统开发工作的说明;需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等;需求是指明必须实现什么的规格说明.
它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.

有哪些层次的软件需求业务需求(businessrequirement):反映了组织机构或客户对系统或产品高层次的目标要求,它们在项目视图与范围文档中予以说明.
用户需求(userrequirement):描述了用户使用产品必须要完成的任务,可在用例模型或方案脚本中予以说明.
功能需求(functionalrequirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求.
非功能需求(non-functionalrequirement):是从各个角度对系统的约束和限制,反映了应用对软件系统质量和特性的额外要求.
过程需求:有交付、实现方法和标准等需求;产品需求:包含性能、可用性、实用性、可靠性、可移植性、安全保密性、容错性等方面的需求;外部需求:有法规、成本、操作性等需求.

软件需求各组成部分之间的关系什么时候进行需求分析项目的早期阶段贯穿于整个软件开发过程的需求活动导致需求错误的原因有哪些1缺乏足够的用户参与:客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫,开发人员可能也不重视用户的参与.
可能原因:与用户合作不如编写代码有意思;开发人员觉得已经明白用户的需求了.
用户需求不断增加:在开发过程中,用户需求经常发生变化,不断的变更会使其整体结构越来越乱,整个程序也难以理解和维护.
在项目的开始对项目视图、范围、目标、约束限制和成功标准给予明确说明,并将此说明作为评价需求变更和新特性的参照框架.
需求模棱两可:不同的人对需求说明产生了不同的理解,或者同一个人能用不止一个方式来解释某项需求说明.
返工耗费开发总费用的40%,而70%~85%的重做是由于需求方面的错误引起的,它是需求规格说明中最严重的问题.
组织不同的人员从不同的角度审查需求.

导致需求错误的原因有哪些2添加不必要的特性:开发人员力图增加一些"用户欣赏"但需求规格说明中并未涉及的新功能,然而常常是用户并不认为这些功能性很有用.
开发人员应当为客户构思方案,并为他们提供一些具有创新意识的思路,具体提供哪些功能要在客户的需要和允许时限内的技术可行性之间求得平衡.
规格说明过于简单:客户往往不明白需求分析的重要性,只是提供一份十分简略的规格说明,仅涉及产品概念上的内容,然后让开发人员在项目进展中去完善,从而导致开发人员先建立产品结构再完成需求说明.
忽略了用户分类:大多数产品是由不同的人使用其不同的特性,使用频繁程度也有所差异,使用者受教育程度和经验水平也不尽相同.
在项目早期就针对所有这些主要用户进行分类.

参与需求分析的人系统分析师、需求阐释者、客户代表、用户代表、开发方领导、项目经理、架构设计师、领域专家、财务人员、市场人员、软件质量保证(SQA,SoftwareQualityAssure)人员、程序员、测试人员、部署人员、技术文档编写人员、培训人员等.
需求分析的场所调研时,在客户现场编纂软件需求规约文档时,可以在开发单位复审相关的需求文档时,根据需要来安排参与需求分析的人有哪些,场所在哪如何进行需求分析需求分析的目的与准则目的准确地回答"系统必须做什么"这个问题.
对目标系统提出完整、准确、清晰、具体的要求.
准则必须理解并描述问题的信息域,根据这条准则应该建立数据模型.
必须定义软件应完成的功能,这条准则要求建立功能模型.
必须描述作为外部事件结果的软件行为,这条准则要求建立行为模型.
必须对描述信息、功能和行为的模型进行分解,用层次的方式展示细节.

需求分析的任务1确定对系统的综合要求功能需求:划分出系统必须完成的所有功能.
性能需求:指定系统必须满足的定时约束或容量约束,通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求.
可靠性和可用性需求:定量地指定系统的可靠性,它量化了用户可以使用系统的程度.
出错处理需求:说明系统对环境错误应该怎样响应,这类错误并不是由该应用系统本身造成的.
接口需求:接口需求描述应用系统与它的环境通信的格式.
约束:描述在设计或实现应用系统时应遵守的限制条件.
常见的约束有:精度;工具和语言约束;设计约束;应该使用的标准;应该使用的硬件平台.
逆向需求:说明软件系统不应该做什么.
将来可能提出的要求:应该明确地列出那些虽然不属于当前系统开发范畴,但是据分析将来很可能会提出来的要求.

需求分析的任务2分析系统的数据要求:采用建立数据模型的方法.
数据字典:可以全面准确地定义数据,但不够形象直观.
层次方框图和Warnier图:描绘数据结构,有助于提高可理解性.
数据结构规范化:能够减少数据冗余,避免出现插入异常或删除异常以及简化修改数据的过程.

需求分析的任务3导出系统的逻辑模型综合上述两项分析的结果可以导出系统的详细的逻辑模型,通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型.
修正系统开发计划根据在分析过程中获得的对系统的更深入更具体的了解,可以比较准确地估计系统的成本和进度,修正以前制定的开发计划.

与用户沟通获取需求的方法1访谈正式的:系统分析员将提出一些事先准备好的具体问题.
非正式的:分析员将提出一些用户可以自由回答的开放性问题,以鼓励被访问人员说出自己的想法.
分发调查表:当需要调查大量人员的意见时.
情景分析:对用户将来使用目标系统解决某个具体问题的方法和结果进行分析.
(1)它能在某种程度上演示目标系统的行为,从而便于用户理解,而且还可能进一步揭示出一些分析员目前还不知道的需求.
(2)由于情景分析较易为用户所理解,使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色.

与用户沟通获取需求的方法2面向数据流自顶向下求精结构化分析方法:通常从数据流图的输出端着手分析,沿数据流图从输出端往输入端回溯,确定每个数据元素的来源,与此同时也就初步定义了有关的算法.
通常把分析过程中得到的有关数据元素的信息记录在数据字典中,把对算法的简明描述记录在IPO图中.

与用户沟通获取需求的方法3简易的应用规格说明技术:提倡用户与开发者密切合作,共同标识问题,提出解决方案要素,商讨不同方案并指定基本需求.
初步的访谈,通过用户对基本问题的回答,初步确定待解决的问题的范围和解决方案.
开发者和用户分别写出"产品需求".
选定会议的时间和地点,并选举一个负责主持会议的协调人,邀请开发者和用户双方组织的代表出席会议,并在开会前几天预先把写好的产品需求分发给每位与会者认真审查.
会议开始后,首先讨论是否需要这个新产品,如果大家都同意,每位与会者就应该把他们在会前准备好的列表展示出来供大家讨论.
大家共同创建一张组合列表.
把与会者分成更小的小组,每个小组的工作目标是为每张列表中的项目制定小型规格说明并向全体与会者展示.
每个与会者都制定出产品的一整套确认标准,并把自己制定的标准提交会议讨论,以创建出意见一致的确认标准.
最后,由一名或多名与会者根据会议成果起草完整的软件需求规格说明书.
优点:开发者与用户不分彼此,齐心协力,密切合作;即时讨论并求精;有能导出规格说明的具体步骤.

与用户沟通获取需求的方法4快速建立软件原型:快速建立起来的旨在演示目标系统主要功能的可运行的程序.
第一个特性是"快速".
第二个特性是"容易修改"(原型的"修改—试用—反馈"过程可能重复多遍).
使用的方法和工具第四代技术:包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的非过程语言.
可重用的软件构件:可以是数据结构(或数据库),或软件体系结构构件(即程序),或过程构件(即模块).
形式化规格说明和原型环境需求工程定义:指应用已证实有效的原理和方法,系统地描述出待开发系统及其行为特征和相关约束.

需求开发的主要活动确定产品所期望的用户类;获取每个用户类的需求;了解实际用户任务和目标以及这些任务所支持的业务需求;分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息;将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件;了解相关质量属性的重要性;商讨实施优先级的划分;将所收集的用户需求编写成规格说明和模型;评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚.

需求管理的主要活动定义需求基线;评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它;以一种可控制的方式将需求变更融入到项目中;使当前的项目计划与需求一致;估计变更需求所产生影响并在此基础上协商新的承诺;让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪;在整个项目过程中跟踪需求状态及其变更情况.

需求获取的工作内容聆听用户的需求分析人员应该与各种层次的客户进行充分的交流和沟通,包括决策领导、使用部门的领导、具体使用人员、系统维护人员等,尽量清楚地理解用户的问题和要求.
分析和整理所获取的信息对于用户提供的各种问题和要求,分析人员需要对其进行归纳和整理,借助一些工具和方法,从用户一般性的陈述里面提取用户的真正需求,并由此确定软件的功能、性能、接口关系、约束条件等.
形成文档化的描述不论是用户的提出问题,还是最终获取的需求,都应该形成文档化的描述,这种描述需要各种人员的一致理解和认同.

需求分析的主要活动绘制系统关联图用于定义系统与系统外部实体间的界限和接口的简单模型.
创建用户接口原型当开发人员或用户不能确定需求时,开发一个用户接口原型可以使许多概念和可能发生的事更为直观明了.
分析需求可行性在允许的成本和性能要求下,分析每项需求实施的可行性,明确与每项需求实现相联系的风险,包括与其它需求的冲突、对外界因素的依赖和技术障碍.
确定需求的优先级别确定用例、产品特性或单项需求实现的优先级别,以优先级为基础确定产品版本将包括哪些特性或哪类需求.
为需求建立模型软件需求规格说明极好的补充说明;包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图等.
创建数据字典对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义.
在需求阶段,数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语.

软件需求规格说明(SoftwareRequirementSpecification)模板1(IEEE标准830-1998)a.
引言:概要叙述软件需求规格说明,便于读者理解文档如何编写以及如何阅读和解释.
a.
1目的:对产品进行定义,在该文档中详尽说明了这个产品的软件需求,包括修正或发行版本号.
如果这个软件需求规格说明只与整个系统的一部分有关系,那么就只定义文档中说明的部分或子系统.
a.
2文档约定:描述编写文档时所采用的标准或排版约定,包括正文风格、提示区或重要符号.
a.
3预期的读者和阅读建议:列举了软件需求规格说明所针对的不同读者,例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员.
描述了文档中剩余部分的内容及其组织结构,提出了最适合于每一类型读者阅读文档的建议.
a.
4产品范围:提供了对指定的软件及其目的的简短描述,包括利益和目标.
a.
5参考文献:列举了编写软件需求规格说明时所参考的资料或其它资源,可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档,或相关产品的软件需求规格说明.
在这里应该给出详细的信息,包括标题名称、作者、版本号、日期、出版单位或资料来源,以方便读者查阅这些文献.

软件需求规格说明模板2(IEEE标准830-1998)b.
综合描述:概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖.
b.
1产品的前景:描述了软件需求规格说明中所定义的产品的背景和起源.
说明了该产品是否是产品系列中的下一成员,是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品,或者是否是一个新型的、自含型产品.
如果软件需求规格说明定义了大系统的一个组成部分,那么就要说明这部分软件是怎样与整个系统相关联的,并且要定义出两者之间的接口.
b.
2产品的功能:概述了产品所具有的主要功能.
其详细内容将在d中描述,所以在此只需要概略地总结.
很好地组织产品的功能,使每个读者都易于理解.
用图形表示主要的需求分组以及它们之间的联系,例如数据流程图的顶层图或类图,都是有用的.
b.
3用户类和特征:确定可能使用该产品的不同用户类并描述它们相关的特征.
b.
4运行环境:描述了软件的运行环境,包括硬件平台、操作系统和版本,还有其它的软件组件或与其共存的应用程序.
b.
5设计和实现上的限制:确定影响开发人员自由选择的问题,并说明这些问题为什么成为一种限制.
可能的限制包括如下内容:必须使用或者避免的特定技术、工具、编程语言和数据库.
所要求的开发规范或标准.
企业策略、政府法规或工业标准.
硬件限制,例如定时需求或存储器限制.
数据转换格式标准.
b.
6假设和依赖:列举出在对软件需求规格说明中影响需求陈述的假设因素,以及项目对外部因素存在的依赖.

软件需求规格说明模板3(IEEE标准830-1998)c.
外部接口需求:确定可以保证新产品与外部组件正确连接的需求.
c.
1用户界面:陈述所需要的用户界面的软件组件.
描述每个用户界面的逻辑特征.
以下是可能要包括的一些特征:将要采用的图形用户界面(GUI)标准或产品系列的风格.
屏幕布局或解决方案的限制.
将出现在每个屏幕的标准按钮、功能或导航链接(例如一个帮助按钮).
快捷键.
错误信息显示标准.
对于用户界面的细节,应该写入一个独立的用户界面规格说明中.
c.
2硬件接口:描述系统中软件和硬件每一接口的特征.
这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议.
c.
3软件接口:描述该产品与其它外部组件(由名字和版本识别)的连接,包括数据库、操作系统、工具、库和集成的商业组件.
明确并描述在软件组件之间交换数据或消息的目的.
描述所需要的服务以及内部组件通信的性质,确定将在组件之间共享的数据.

c.
4通信接口:描述与产品所使用的通信功能相关的需求,包括电子邮件、Web浏览器、网络通信标准或协议及电子表格等等.
定义了相关的消息格式,规定通信安全或加密问题、数据传输速率和同步通信机制.

软件需求规格说明模板4(IEEE标准830-1998)d.
系统特性d.
1说明和优先级:简短说明该系统的特性,并指出该特性的优先级是高、中,还是低.
另外,还可以包括对特定优先级部分的评价,例如利益、损失、费用和风险.
d.
2激励/响应序列:列出输入激励(用户动作、来自外部设备的信号或其它触发器)和定义这一特性行为的系统响应序列.
d.
3功能需求:详列出与该特性相关的详细功能需求.
这些是必须提交给用户的软件功能,使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务.

软件需求规格说明模板5(IEEE标准830-1998)e.
其他非功能需求e.
1性能需求:阐述了不同的应用领域对产品性能的需求,并解释它们的原理以帮助开发人员作出合理的设计选择.
确定相互合作的用户数或者所支持的操作、响应时间以及与实时系统的时间关系.
e.
2安全设施需求:详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求.
定义必须采取的安全保护或动作,还有那些预防的潜在的危险动作.
明确产品必须遵从的安全标准、策略或规则.

e.
3安全性需求:详尽陈述与系统安全性、完整性或与私人问题相关的需求,这些问题将会影响到产品的使用和产品所创建或使用的数据的保护.
定义用户身份确认或授权需求,明确产品必须满足的安全性或保密性策略.
e.
4软件质量属性:详尽陈述与客户或开发人员至关重要的其它产品质量特性,这些特性必须是确定、定量的并在可能时是可验证的.
e.
5业务规则:列举出有关产品的所有操作规则,例如什么人在特定环境下可以进行何种操作.
这些本身不是功能需求,但它们可以暗示某些功能需求执行这些规则.

e.
6用户文档:列举出将与软件一同发行的用户文档部分,例如用户手册、在线帮助和教程,明确所有已知的用户文档的交付格式或标准.

软件需求规格说明模板6(IEEE标准830-1998)f.
其他需求定义在软件需求规格说明的其它部分未出现的需求,例如国际化需求或法律上的需求.
还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错,以及登录和监控操作等方面的需求.
这一部分可以省略.

软件需求规格说明的作用它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件;不仅是系统测试和用户文档的基础,也是所有子系列项目规划、设计和编码的基础.
软件需求规格说明是用户、分析人员和设计人员之间进行理解和交流的手段;测试人员可以根据软件需求规格说明中对产品行为的描述,制定测试计划、测试用例和测试过程.
文档人员根据软件需求规格说明和用户界面设计,编写用户手册等;软件需求规格说明指导着整个系统的开发过程,评审过的需求规格说明需要进行变更控制.

需求说明的质量特性正确性:需求规格说明对系统功能、行为、性能等的描述必须与用户的期望相吻合,代表了用户的真正需求.
完整性:需求规格说明应该包括软件要完成的全部任务,不能遗漏任何必要的需求信息,注重用户的任务而不是系统的功能将有助于你避免不完整性.
一致性:需求规格说明对各种需求的描述不能存在矛盾,如术语使用冲突、功能和行为特性方面的矛盾以及时序上的不一致等.
无二义性:需求规格说明中的描述对所有人都只能有一种明确统一的解释,由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的用户性的语言表达出来.
可修改性:需求规格说明的格式和组织方式应保证后续的修改能够比较容易和协调一致.
可跟踪性:每项需求都能与其对应的来源、设计、源代码和测试用例联系起来.
可验证性:需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认.

需求验证的方法审查需求文档:对需求文档进行正式审查是保证软件质量的有效方法.
组织一个由不同代表(如分析人员,客户,设计人员,测试人员)组成的小组,对SRS及相关模型进行仔细的检查.
以需求为依据编写测试用例根据用户需求所要求的产品特性写出黑盒功能测试用例.
客户通过使用测试用例以确认是否达到了期望的要求.
同时,要使用测试用例来验证需求模型的正确性,如对话框图和原型等.
编写用户手册在需求开发早期即可起草一份用户手册,用它作为需求规格说明的参考并辅助需求分析.
确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的,将合格的测试建立在使用情景描述或用例的基础之上.

分析模型实体关系图(Entity-RelationshipDiagram,ERD):作为数据建模的基础,描述数据对象及其关系;数据流图(DataFlowDiagram,DFD):作为功能建模的基础,描述数据怎样转换以及转换的功能;状态转换图(State-TransitionDiagram,STD):作为行为建模的基础,表示系统的各种行为状态以及状态间的转换方式.

以"数据字典"为核心的分析模型实体关系图(ERD)基本元素数据对象:表示具有不同属性的事物,用带有标记的矩形来表示.

属性:表示数据对象的性质,用圆角矩形来表示.
关系:表示数据对象之间的相互连接,用直线连接相关联的数据对象,并在直线上用带标记的菱形框来表示关系.
两个数据对象之间有以下三种关联:一对一(1:1)一对多(1:N)多对多(M:N)数据流图(DFD)描述了信息流和数据转换,通过对加工进行分解可以得到数据流图.
四种元素如下:外部实体:与系统进行交互,但系统不对其进行加工和处理的实体,用带标记的矩形表示;加工(处理):对数据进行的变换和处理,用带标记的圆圈表示;数据流:在数据加工之间或数据存储和数据加工之间进行流动的数据,用带标记的箭头表示;数据存储:在系统中需要存储的实体,用带标记的双实线表示.

状态转换图(STD)通过描述状态以及导致系统改变状态的事件来表示系统的行为,它没有表示出系统所执行的处理,只表示了处理结果可能的状态转换.

状态:用带标记的圆圈或矩形表示;状态的变换:用箭头表示;引起变换的条件:箭头上的文本标记表示.

数据字典描述数据流图的数据存储、数据加工(最底层加工)和数据流,主要内容有:基本信息:名字、别名、描述;定义:数据长度、数据类型、数据结构;使用特点:取值范围、使用频率、使用方式等;控制信息:来源、用户、引用程序、读写权限等;其他说明.
在数据字典中,数据元素的定义可以是基本元素及其组合,数据进行自顶向下地分解,直到不需要进一步解释且参与人员都清楚其含义为止.
数据组合有三种方式:顺序:以确定的次序连接多个数据项;选择:从多个数据项中选取一个;重复:将某个数据项重复多次.

数据规范化为减少数据冗余,避免出现插入异常或删除异常,简化修改数据的过程,通常需要把数据结构规范化.
通常用"范式(normalforms)"定义消除数据冗余的程度.
第一范式(1NF)数据冗余程度最大,第五范式(5NF)数据冗余程度最小,大多数场合选用第三范式比较恰当.
范式级别越高,存储同样数据就需要分解成更多张表,"存储自身"的过程也就越复杂;随着范式级别的提高,数据的存储结构与基于问题域的结构间的匹配程度也随之下降,因而在需求变化时数据的稳定性较差;范式级别提高则需要访问的表增多,性能(速度)将下降.

数据规范化2(1)第一范式每个属性值都必须是原子值,即仅仅是一个简单值而不含内部结构.
(2)第二范式满足第一范式条件,而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定).
例:假定选课关系表为SelectCourse(学号,姓名,年龄,课程名称,成绩,学分),关键字为组合关键字(学号,课程名称).
这个数据库表不满足第二范式,因为存在如下决定关系:(课程名称)→(学分)(学号)→(姓名,年龄)数据规范化3(3)第三范式符合第二范式的条件,每个非关键字属性都仅由关键字决定,而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值).
例:假定学生关系表为Student(学号,姓名,年龄,所在学院,学院地点,学院电话),关键字为单一关键字"学号",因为存在如下决定关系:(学号)→(姓名,年龄,所在学院,学院地点,学院电话)这个数据库是符合2NF的,但是不符合3NF,因为存在如下决定关系:(学号)→(所在学院)→(学院地点,学院电话)结构化分析方法——面向数据流进行需求分析的方法结构化分析方法以数据字典为核心,采用实体关系图、数据流图和状态转换图等图形来表达需求,直观明了且易于理解和掌握.
数据流图是结构化分析的基本工具,体现了自顶向下逐步求精的分析过程,确定了系统的任务流和数据流;实体关系图描述了系统的数据关系,从而帮助开发人员分析和理解系统数据的组成,并为系统设计阶段定义系统数据库的物理结构打下基础;状态转换图描述了系统状态之间的变化过程,它对于实时系统和控制系统尤为重要.

结构化分析过程:创建实体关系图(1)在需求收集的过程中,要求客户列出应用软件或业务过程涉及到的"事物",将其演化成数据对象;(2)一次考虑一个对象,分析员和客户定义这个对象和其他对象之间是否存在连接;(3)如果存在连接,应创建一个或多个关系;(4)对每一个关系,确定其关联类型;(5)重复步骤(2)到步骤(4),直到定义了所有关系.
(6)定义每个实体的属性;(7)形式化并复审实体关系图;(8)重复步骤(1)到(7),直到数据建模完成.
举例分析:学生成绩管理系统实体:学生、课程、成绩.
教务人员虽然是系统的用户,但其信息与系统处理无关,因此不用作为实体.

实体属性定义:学生:学号、姓名、性别、出生日期、入学年月课程:课程编号、课程名称、课程学分、课程描述成绩:学号、课程编号、分数、考核日期实体关系图:结构化分析过程:创建数据流模型1(1)第0层DFD将整个系统表示成一个加工;(2)确定并标记主要的输入和输出;(3)分离出下一层中的加工、数据对象和存储,并对其进行细化,一次细化一个加工;(4)标记所有加工和箭头;(5)重复步骤(3)和(4),直到所有的加工只执行一个简单的操作,可以很容易地用程序实现.

结构化分析过程:创建数据流模型2绘制数据流图应当遵循以下原则:(1)分层时,子图的输入、输出数据流必须和父图中相应加工的输入、输出数据流一致;(2)加工的编号应该唯一且具有层次性;(3)加工不应该只有输入或只有输出,通常既有输入又有输出;(4)数据流图不应反映处理的顺序;(5)加工之间应通过数据存储进行通信,避免从一个加工直接流到另一个加工;(6)数据应通过加工进行流动,避免从一个数据存储直接流到另一个数据存储;(7)数据流图中所有元素的命名应当对客户有意义,且与业务相关;(8)不要在一个图中绘制7个以上的加工,否则难于绘制和理解.
举例分析:学生成绩管理系统1第0层DFD图教务人员维护学生信息和课程信息,并登录学生的选课成绩;学生查询自己的成绩单.

举例分析:学生成绩管理系统2第1层DFD图对第0层DFD图中的一个加工"学生成绩管理"进行展开.
举例分析:学生成绩管理系统3第2层DFD图对第1层DFD图中的一个加工"查询学生成绩"进行展开.
举例分析:学生成绩管理系统4数据字典结构化分析过程:创建行为模型通常来说,行为建模用于实时系统.
实时系统中可能存在许多脚本,很多实体需要进行状态划分和描述状态转换图,有时为了描述系统的并发行为,还需要使用其他一些工具进行描述,如Petri网.
在事务系统中,系统行为相对简单,只有某些行为较复杂的实体才需要建立其状态转换图.
步骤(1)分析外部事件,所谓外部事件是指外部实体与系统的一次交互.
(2)分析事件的响应者,该响应者为了响应该事件要进行怎样的活动,这种活动又会激发哪些事件等,这样构成了系统行为的脚本.
(3)根据事件和活动划分实体的状态,也可根据其他知识划分实体状态,考虑发生怎样的事件使该实体进入这个状态,怎样的事件使该实体从这个状态转换到另一状态等.

举例分析:学生成绩管理系统结构化分析过程:编写加工规格说明用于描述底层数据流图的加工,包括叙述性正文、加工算法、数学方程、表或图表等;它可以成为编写软件需求规格说明的第一步,并为加工的程序设计提供指南.
加工规格说明采用结构化英语(PDL)、判断表和判断树等进行描述.

软件原型的定义和作用定义:一个软件原型是所提出的新产品的部分实现,它比开发人员常用的技术术语更易于理解.
主要作用:明确并完善需求:原型作为一种需求工具,它初步实现所理解的系统的一部分.
用户对原型的评价可以指出需求中的许多问题,在你开发真正产品之前,可以最低的费用来解决这些问题.
探索设计选择方案:原型作为一种设计工具,用它可以探索不同的用户界面技术,使系统达到最佳的可用性,并且可以评价可能的技术方案.
发展为最终的产品:原型作为一种构造工具,是产品最初子集的完整功能实现,通过一系列小规模的开发循环,你可以完成整个产品的开发.

抛弃式原型(throwawayprototype)当遇到需求中的不确定性、二义性、不完整性或含糊性时.
演化式原型(evolutionaryprototype)在已经清楚地定义了需求的情况下,为开发渐增式产品提供了坚实的构造基础.
适合于基于Web应用的系统开发,这种系统往往随着开发的进展本身的需求也在发生变化;一开始就必须具有健壮性和产品质量级的代码.

软件原型的类型从其内容来看可以注重用户界面;也可以注重某些算法功能和效果;从其表现形式来看可以是电子的;也可以是书面的;从其评价后的处理来看,可以将其抛弃;或继续将其进化为最终产品的一部分.

原型法的风险引起风险的原因用户看到一个正在运行的原型便以为产品即将完成,他们会要求不再进行产品重建,而只是对原型进行一些修改就交付;开发人员为了快速构造原型,可能会采用不合适的操作系统或程序设计语言,也可能使用一些效率低的算法.

在需求开发中建立有效原型的原则:在项目计划中包括原型风险,安排好开发、评价和可能的修改原型的时间.
尽快并且廉价地建立抛弃式原型.
对于已经理解的需求不要建立原型.
不能随意地增加功能.
不要从原型的性能推测最终产品的性能.
在原型屏幕显示和报表中使用合理的模拟数据,那些评价原型的用户会受不现实数据的影响而不能把原型看成真正产品的模型.
不要期望原型可以代替需求文档.

需求管理的内容需求管理包括在软件开发过程中维持需求约定集成性和精确性的所有活动.

需求管理的内容:需求变更控制需求变更应该实现以下要求:应仔细评估已建议的变更;挑选合适的人选对变更做出决定;变更应及时通知所有涉及的人员;项目要按一定的程序来采纳需求变更.

需求管理的内容:需求文档的版本控制需求文档的每一个版本必须被统一确定,组内每个成员必须能够得到需求的当前版本,必须清楚地将变更写成文档,并及时通知到项目开发所涉及的人员.
每一个公布的需求文档的版本应该包括一个修正版本的历史情况,即已做变更的内容、变更日期、变更人姓名以及变更原因,可以考虑给每个需求标记上版本号,当修改需求后就增加版本号.
最有力方法是用一个商业需求管理工具的数据库存储需求,这些工具可以跟踪和报告每个需求的变动历史,特别是当需要恢复早期的需求时非常有意义.
在添加、变动、删除、拒绝一个需求后,附加一些评语描述变更的原因在将来需要讨论时将会很有用.

需求管理的内容:需求跟踪1包括编制每个需求同系统元素之间的联系文档,这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档等,从而建立了需求的跟踪联系链.

需求管理的内容:需求跟踪2需求跟踪能力矩阵:说明了每个功能性需求向后连接一个特定的用例,向前连接一个或多个设计、代码和测试元素.

test2Catalog.
sort()ClasscatalogCatalog.
query.
sortUC1test3Catalog.
update()ClasscatalogCatalog.
updateUC2测试实例代码设计元素功能需求用例把变更控制、版本控制和需求跟踪三者统一起来,真正做到了管理需求变化过程,以及维护需求变化后的一致性和完整性.

需求管理工具以数据库为核心的产品(如Caliber-RM和DOORS):将所有的需求、属性和跟踪能力信息存储在数据库中,有些工具可以把每个需求与外部文件相联系(如微软的Word文件、Excel文件、图形文件等),以补充需求说明.
以文档为核心的工具:使用Word或Adobe公司的FrameMaker等字处理程序制作和存储文档.

以文档为核心ComplianceAutomation,IncVitalLink以数据库为核心IntegratedChipware,IncRTMWorkshop以文档为核心RationalSoftwareCorporationRequisitePro以文档为核心QualitySystemsandSoftware,IncQSSrequireit以数据库为核心QualitySystemsandSoftware,IncDOORS以数据库为核心TechnologyBuilders,IncCaliber-RM类型公司工具习题1一个考务处理系统的要求如下,试画出该系统的数据流图.
(1)对考生送来的报名表进行检查;(2)对合格的报名表编好准考证号码后将准考证送给考生,并将汇总后的考生名单送给阅卷站;(3)对阅卷站送来的成绩表进行检查,并根据考试中心指定的合格标准审定合格者;(4)填写考生通知单(内容包含考试成绩及合格∕不合格标志),送给考生;(5)按地区、年龄、文化程度、职业、考试级别等进行成绩分类统计及试题难度分析,产生统计分析表.

顶层数据流图第1层数据流图第2层数据流图习题21、需求工程包括哪些基本活动每一项活动的主要任务是什么答:需求工程分为需求开发和需求管理两个部分,而需求开发又可进一步分为需求获取、需求分析、规格说明和需求验证四个阶段.
这些基本活动的主要任务包括:(1)需求获取:采集、识别和提取用户的需求,对问题和需求形成文档化的描述,使各种人员达成一致的理解和认可.

(2)需求分析:分析和综合所采集的信息,建立系统的详细逻辑模型.
(3)需求规格说明:编写软件需求规格说明书,明确、完整和准确地描述已确定的需求.

(4)需求验证:评审软件需求规格说明,以保证其正确性、一致性、完备性、准确性和清晰性.

(5)需求管理:定义需求基线,在整个项目过程中跟踪需求状态及其变更情况.

2、原型化方法主要用于解决什么问题试说明这种方法的主要优缺点.
答:原型化方法主要用于解决在产品开发的早期阶段需求不确定的问题,用户、经理和其他非技术项目风险承担者发现在确定和开发产品时,原型可以使他们的想象更具体化.

这种方法的主要优点如下:(1)明确并完善需求原型作为一种需求工具,它初步实现所理解的系统的一部分,用户对原型的评价可以指出需求中的许多问题.

(2)探索设计选择方案原型作为一种设计工具,可以探索不同的用户界面技术,使系统达到最佳的可用性,并且可以评价可能的技术方案.

(3)发展为最终的产品原型作为一种构造工具,是产品最初子集的完整功能实现,通过一系列小规模的开发循环,你可以完成整个产品的开发.

这种方法的主要缺点包括:(1)用户看到一个正在运行的原型便以为产品即将完成,他们会要求不再进行产品重建,而只是对原型进行一些修改就交付.
由于原型没有考虑软件的总体质量和可维护性,交付原型往往造成"欲速则不达"的情况.

(2)开发人员为了快速构造原型,可能会采用不合适的操作系统或程序设计语言,也可能使用一些效率低的算法.
在一段时间的开发之后,他们往往已经习惯了这些选择,于是便在系统中参杂了这些不理想的选择.

3、怎样理解"质量是免费的"这句话答:质量管理的基本思想不是尽量减少错误,而是争取第一次把事情完全做好,从而实现"零缺陷".
我们常常会出现不符合质量标准的问题,也就是有些工作没有做到第一次就做好,为此需要进行一系列的补救,从而产生了额外的支出,包括时间、金钱和精力,由此产生了质量损失.
如果我们能够第一次就将事情做好,那么就避免了质量损失.