软件需求分析方法

1、需求分析方法一 需求分析概括需求分析应该先了解宏观的问题，再了解细节的问题。一个应用软件系统（记为 S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。S= D1, D2 , D,Dn问题域Di由若干问题（记为 P）组成，每个问题对应于子系统中的一个软构件。Di = P1, P2, P3 ,Pn问题Pi有若干个行为（或功能，记为F）,每个行为对应于软构件中的实现接口。Pj = F1, F2 , F3 ,Fk需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。在写需求说明书时，应该注意两个问题：1. 最好为每个需求注释“为什么” ，这样可

2、以让程序员了解需求的本质， 以便选用最合适 的技术来实现此需求2. 需求说明不能有”二义性”，更不能前后矛盾。如果有二义性或前后矛盾，即要重新分 析此需求。需求分析方法论第一阶段：“访谈式”第一阶段是和具体用户方的领导层、业务层人员的访谈沟通，主要目的是从宏观上把握用户的具体需求方向和趋势， 了解现有的组织架构、业务流程、硬件环境、软件环境、现有 的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。实现手段：访谈、调查表格 输出成果：调查报告、业务流程报告 第二阶段：“诱导式”结合第一阶段的基本信息， 做出简单的用户流程页

3、面， 同时结合以往的项目经验对用户采用 诱导式，启发式的调研方法和手段， 和用户一起探讨业务流程设计的合理性、准确性、 习惯 性。用户可以操作简单演示的DEMO感受整个业务流程的设计合理性、准确性等等问题，以及提出改进意见和方法。实现手段：诱导（拜访） 、原型演示 输出成果：调研分析报告、原型反馈报告、业务流程报告第三阶段：“确认式”此阶段在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段。这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。通过审查，提出反馈意见，并对已经可接受的报告、文档签字确认。实现手段：拜访（回顾、确认）

4、，提交业务流程报告、数据项表；原型演示系统输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归 到需求分析报告中）后续的需求改进中，工作则基本集中在后两个阶段中。三需求工程需求过程諾求营理需求快态跟踪需求幵发需求开发:1. 确定产品所期望的用户分类。2. 获取每类用户的需求。3. 了解实际用户任务和目标 以及这些任务所支持的业务需求。4. 分析源于用户的信息以区别用户 任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。5. 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。6. 了解相关质量属性的重要性。7. 商讨实施优先级的划分。8.

5、将所收集的用户需求编写成规格说明和模型。9. 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前 将问题都弄清楚。需求分析需求分析是指通过对需求获取中获得的问题域的研究，获得对该领域特性及存在其中的问题特性的透 彻理解并用文档说明。? 不需要等到需求完全捕获后开始，在“业务需求”充分理解下，并且收集了本质的“用户需求”之后就可以开始进行需求分析? 交替进行，先把握“用户需求”主要部分，然后在分析的基础上引入系统级的需求（系统的涉 及与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平 台? 分析的基础上，就会发现更多的不明确项，更多待

6、捕获的信息，这时就可以生成第二次的需求 调研计划、问题和素材编写规约? 规格说明书是对需求分析结果的文档化过程? 需求规约必须与实际开发紧密结合，否则很容易造成与开发脱离? 为需求规约定义统一的格式是一个很重要的工作? 规约内容必须严谨、正确、无歧义需求验证? 不重视需求验证工作会在系统交付时，客户发现不是这样的，导致不期望的需求变更? 提高需求质量的重要手段有：需求评审、需求确认和原型验证需求方法之-原型开发需求分析层次需求层次内容业务需求反应组织机构或客户对系统、产品高层次的目标要求。通常问题定义 就是业务需求用户需求描述用户使用产品必须要完成什么任务、怎样完成，通过是在问题定 义的基础上

7、进行访谈、调查、对用户使用的场景进行整理，从而建立 从用户角度的需求系统需求从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求，质量属性以及其他非功能需求，还有设计约束1. 功能需求：系统必须完成的任务，以及怎样完成这些任务。即为了向用户提供有用的功能，必须完成的动作。2. 非功能需求：指产品必须具备的属性或品质，如可靠性、性能、响 应时间、容错性和扩展性。3. 设计约束：即限制条件或补充规约，通常是对解决方案的一些约束说明。例如必须运行在 unix操作系统之下（硬、软件的约束）。，还应该得到市场客户管理将项目大的目标整理提炼，戈U分为项目子目标，将其作为“项目的行动纲领” “项目发

8、起人”的认可，并且在此基础上编写“项目的目标和范围文档”需求分析迭代过程需求分析更正幷 A减少课差僞写机约童骂需求捕获需求捕获明确业务需求：业务需求是整个系统最为宏观层面的东 西”也就是项目的目标“；通常来说，业务需求是构 建在“项目发起人”的脑子里的；“业务需求歸可以分 为*产品丿项目目标和和“子目标描述两个方面的內 容 理解业务流程t若项目较大或者业务较陌生：应进行业务建模;“如果业务较陌生：聘请领域专家*领域培训; -如杲术语较多，易于混淆：业务术语表 无论如何，都应该建立跨部门职能流程图用例模型用例模型一组织需求用例特性“用例描绘的场景（或事件流）展示了参与者如何使用 系统3这都应基于

9、系统要完成的任务及其重要性来决定 如何确定主要场景次要场景，以及需要多少场景I -用例的粒度问题很关键，既不能太丸也不能够太小测试顼说胡WWhat to do用例星苦描述了愷用做什么曲罪如何做？AAtlors puinl of * kW用例的摊述琵否怵現了穆歸的视角丫VVilue for ctie atior?EEnli代 scrollLitio出例插述时间流鼻咅为-个完蹩的场景？建立用例模型一合并特性获得用例特性书倒幵发人员fmks刑廉人易接到任务时.如过刺協鑑HI时袖（ 计超开始ti闻和计制结応时币n项冃粉墀确认后.更釘 H和址排嚨ucuiAte务计它FKATOCi Jt人抽町氏直酣阪工件

10、任务的加处顧揺tfiSff 船悄1茨附戡UC01査询他虫枉务FE/CTg丹发人员可区柚据仟：务綸号*关變界 起止时间谡 鞋分类组令齊询与魁计FEATWJ1K人员琳战豪时记录口己的H阖、慢慎-JTteit IV、 “耕停ii时、11停止计WT .右涉止时.嘎入任 夯骗号 吊務则乐揮八 工佯关艇牛C以型号分爲的多车 ）p自动生成开始时何、暂停时间.停止时间、总时從丫 甫效时風t总肘民-中斷时栓rmitfii诃彌t序食H动违掠翩喩極甘闾曲志t 停丽丁件*术施逼摊肌务僭刪。木飙暫存耐何nUC03.远威詩间日比建立用例模型一绘制用例图建立用例模型一简要描述用例用例编号UCOI用例名称填写任务计划用例彈述

11、齐发人员对项目经理安扌非给自己的工佟任务进行计划.填八计 划开姑吋问和计划完成时间.主參与者开发人屍补充说明在境入计划幵始吋间和计划完成吋间吋，开发人员可以查询与 该任务的关如字和关妁历史任务的數培。建立用例模型一划分用例优先级优先级用例1UCM 登录系纯系统便用的M他.并斗可feHJJft価源UC3管理啪皿息UC04设世工作包UB5分配J件任务UC01 坝写任务计划仔务伶理的完無流创是记录中亦日志的 基础UC03id亲时间H 土系统檢心功陡2【JC07关闭作任务只兒肘杠伤信息进口更祈.而酸忤次ZUCW6.SrHftk UC5A.査耘，按对I IX安井进L优化.便任餌女？ 1台拦化3UB2 査

12、询历史仃分致掛UB8统i卩貝目产能UC10毀汁团队产诡対系扯氾釆的时何记禾迥行片效的利用， 必须而的M4能筋开反UCI2 管好用户询期nJ以迫过直接徨戳据障中写值的方式 进行使用.卓后握01畀面操件即可理立用例複型一评地诵还ffl例ffim号uco用例第体记录破间H土用似|戏述开変人员彳以必时*乙点自己的廿间U 丹耐讣r普停计时、.侔止金対、沁丸 止时-仗人兰命编當q A纵M&M)工什芟优字1以H号分代的$个)U 询2此井竹叭罚 福耳厅间停止M同.殆时米老贰时Me恵时晁冲嘶时兵卜二与善护岌人员条件用户itA “褐廉算间H老”程片Eltfrfr轄次片何。芯海入赣福M垃S!1常妮盅孑讦0 讪屮和“

13、号卍悴仏性仅-S-fe*耳用气HrAJt 卅*T斤城记*片姑M同*4彳*兀可同 -ft 材0 优見，ft 纾AT挨佃不年忙3al命冏户血文條X” i*Q.用命常时问丸矢術待芥怖芮月样刘駅歐稻年町同.井裏如 H “響甘眄河为网*具柴機&垛耘旻比兵住娛矿射規则弓約味叶.通忸冲会0初逵J*氏务乔，无貝叶冋H七丄的亠作，七乂札3 UR% pjrt*札材存时河目怎用户界面设计|圉r ,-啊、彷r快竝JMH呻亠勢城亠7, r.f.航帝酊*.广杠衬F.* kiijNiY-总击叫觉圧-打曲屮于甘m u叭 fiJ-.H 时 a- CA 曲j3.5利用跟踪关系业务需求T用户需求T系统需求如果业务需求和用户需求没有

14、得到片项需求（用户 需求和系统需求）的充分支持，那么软件儒求规格 说明文档就衣在不完备的缺陷=系统需求T用户需求T业务需求如果不能依据跟踪关系找到一条系统蛊求的前顶川 户需求和前项业务需求,那么该需求就属于非必要 的需求验证需求分析将需求分析的结果还原为用户场景，然后向用户描述该场景的目的、任务、实现的方法，以此验证是否正确。推荐的需求文档格式1）业务名称解释2）需求背景及目标介绍3）用户操作场景说明4）功能总览：用列表的方式，逐项叙述对系统所提出的功能要求，说明输入什么量、 经怎么样的处理、得到什么输出5）系统交互图6）界面原型（对该系统的输入、输出数据类型、格式、数值范围、精度的描述）7）

15、业务规则说明8）业务正常流流程：功能模块，主要操作9）业务异常流处理：异常场景，错误提示；异常流转软件需求说明书1引言1. 1编写目的说明编写这份软件需求说明书的目的，指出预期的读者。1 . 2背景说明：a .待开发的软件系统的名称；b 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;C.该软件系统同其他系统或其他机构的基本的相互来往关系。1 . 3定义列出本文件中用到的专门术语的定义和外文首字母组词的原词组。1 . 4参考资料列出用得着的参考资料，如：a 本项目的经核准的计划任务书或合同、上级机关的批文；b .属于本项目的其他已发表的文件；列出这些c.本文件中各处引用的文

16、件、资料、包括所要用到的软件开发标准。文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来 源。2 任务概述2. 1目标叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品 是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更 大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系， 为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。I2. 2用户的特点列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技

17、术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束2. 3假定和约束列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。3 需求规定3. 1对功能的规定用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说 明软件应支持的终端数和应支持的并行操作的用户数。3. 2对性能的规定3. 2. 1精度说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。3. 2 . 2时间特性要求说明对于该软件的时间特性要求，如对：a .响应时间；b.更新处理时间；c .数据的转换和传送时间；

18、d 解题时间；等的要求。3. 2 . 3灵活性说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：a. 操作方式上的变化；b. 运行环境的变化；c .同其他软件的接口的变化；d.精度和有效时限的变化；e .计划的变化或改进。对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。3 . 3输人输出要求解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软 件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结 果输出、状态输出及异常输出）以及图形或显示报告的描述。3 . 4数据管理能力要求说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对 数据及其分量的存储要求作出估算。3. 5故障处理要求列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。3. 6其他专门要求如用户单位对安全保密的要求，对使用方便的要求，