精华内容
下载资源
问答
  • 软件需求分析

    千次阅读 2018-12-22 20:58:15
    软件需求分析的任务: 需求分析步骤: 需求分析方法: 分析建模: 分析模型: 建立分析模型的方法: 结构化分析: 软件需求说明: 软件需求说明包括内容: ​ 需求验证: 开发过程模型: 当前系统的...

    目录

     

    开发过程模型:

    软件需求分析的任务:

    需求分析步骤:

    需求分析方法:

     

    分析建模:

    分析模型:

    建立分析模型的方法:

    结构化分析:

    软件需求说明:

    软件需求说明包括内容:

    需求验证:


    开发过程模型:

    当前系统的物理模型:

    通过分析现实世界,理解当前系统的运行过程,用一个具体化的模型模拟、了解当前系统的组织结构、资源利用情况和日常数据处理过程。合理的物理模型应该客观反应现实世界的实际情况,是需求分析中的第一步。

    当前系统的逻辑模型:

    在理解当前系统的具体运行过程后,从各个细节中抽象出本质的过程模型。

    目标系统的逻辑模型:

    分析当前系统与目标系统逻辑上的差别,明确目标系统要“做什么”的实质工作,从当前系统的逻辑模型导出目标系统的逻辑模型。

    目标系统的物理模型:

    要确定待开发系统的系统元素,并将功能和数据结构分配到系统元素中。这是软件开发的目的。

     

     

    软件需求分析的任务:

    1、认清问题、分析资料、建立分析模型:

    分析模型应该包含系统的界面要求、功能要求、性能要求、安全性、保密性、可靠性、运行要求(对硬件、支撑软件、数据通信接口等的要求)、异常处理等对系统的综合需求,以及对于系统信息处理中数据元素的组成、数据的逻辑关系、数据字典和数据模型等系统的数据要求。这些都是形成软件需求规格说明书、进行软件设计与实现的 基础。

    2、编写软件需求规格说明书:

    易于理解和无二义性。在描述过程中最好不使用用户不易于理解的专业术语。为了便于用户理解,该说明书应该直观、易读和易于修改,尽量以图文结合的方式,采用自然语言,标准的图形、表格和简单的符号来表示。

    需求分析步骤:

    需求获取、需求建模、文档编写、需求验证

    需求分析方法:

     

    分析建模:

    分析模型:

    模型:就是为了理解事物所做出的一种抽象,是对事物无歧义的书面描述。模型由一组图形符号和组成这些符号的规则所组成。

    分析模型:由一组模型组成,包括数据模型、功能模型和行为模型。

    建立分析模型的方法:

    结构化分析:

    具体步骤:

    首先,画出分层数据流图。

    1、画出系统的输入/输出——顶层图(仅一张)

    2、画出系统的内部——0层图(仅一张)

    3、对图和加工标号

    4、检查复审:命名、加工、文件、保持父图与子图的平衡、保持数据守恒、分解的速度适当、

    然后,确定数据定义与加工策略。

    再次,复审。

     

     

     

    软件需求说明:

    软件需求说明(SRS):又称软件规格说明书,是系统分析员在需求分析阶段需要完成的文档,是软件需求分析的最终结果。主要作用为,作为软件人员与用户之间事实上的技术合同说明;作为软件人员下一步进行设计和编码的基础;作为测试和验收的依据。

    软件需求说明包括内容:

    主要包括引言、任务概述、需求规定、运行环境规定和附录等内容。

     

    需求验证:

    一致性、现实性、完整性、有效性。

     

     

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • 软件需求分析模板

    千次阅读 2019-05-29 09:13:17
    软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化,分析各种可能的解法,并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步,是确定系统必须完成哪些工作,也就是对目标系统提出完整、准确...

    软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化,分析各种可能的解法,并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步,是确定系统必须完成哪些工作,也就是对目标系统提出完整、准确、清晰、具体的要求。

    软件需求分析的任务是:深入描述软件的功能和性能,确定软件设计的约束和软件同其他系统元素的接口细节,定义软件的其他有效性需求,借助于当前系统的逻辑模型导出目标系统逻辑模型,解决目标系统“做什么”的问题。

    需求分析可分为需求提出、需求描述及需求评审三个阶段。

    需求提出主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。用户、开发人员和用户确定一个问题领域,并定义一个描述该问题的系统。这样的定义称作系统规格说明,并且它在用户和开发人员之间充当合同。

    在问题分析阶段分析人员的主要任务是:对用户的需求进行鉴别、综合和建模,清除用户需求的模糊性、歧义性和不一致性,分析系统的数据要求,为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来,以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求,哪些是用户尚未提出但具有真正价值的潜在需求。

    在需求评审阶段,分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核,以确保软件需求的完整、准确、清晰、具体,并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点,必须尽快更正,再行检查。

    软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解, 使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下:
    1 引言
    1.1编写目的
      说明编写这份软件需求说明书的目的,指出预期的读者。
    1.2背景
      说明:
      a.待开发的软件系统的名称;
      b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;
      C.该软件系统同其他系统或其他机构的基本的相互来往关系。
    1.3定义
      列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
    1.4参考资料
      列出用得着的参考资料,如:
      a.本项目的经核准的计划任务书或合同、上级机关的批文;
      b.属于本项目的其他已发表的文件;
      c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。
    2 任务概述
    2.1目标
      叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
    2.2用户的特点
      列出本软件的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长,以及本软件的预期使甩频度。这些是软件设计工作的重要约束
    2.3假定和约束
      列出进行本软件开发工作的假定和约束,例如经费限制、开发期限等。
    3 需求规定
    3.1对功能的规定
      用列表的方式(例如IPO表即输入、处理、输出表的形式),逐项定量和定性地叙述对软件所提出的功能要求,说明输入什么量、经怎样的处理、得到什么输出,说明软件应支持的终端数和应支持的并行操作的用户数。
    3.2对性能的规定
    3.2.1精度
      说明对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。
    3.2.2时间特性要求
      说明对于该软件的时间特性要求,如对:
      a.响应时间;
      b.更新处理时间;
      c.数据的转换和传送时间;
      d.解题时间; 等的要求。
    3.2.3灵活性
      说明对该软件的灵活性的要求,即当需求发生某些变化时,该软件对这些变化的适应能力,如:
      a.操作方式上的变化;
      b.运行环境的变化;
      c.同其他软件的接口的变化;
      d.精度和有效时限的变化;
      e.计划的变化或改进。
      对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
    3.3输人输出要求
      解释各输入输出数据类型,并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。
    3.4数据管理能力要求
      说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作出估算。
    3.5故障处理要求
      列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
    3.6其他专门要求
      如用户单位对安全保密的要求,对使用方便的要求,对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
    4 运行环境规定
    4.1设备
      列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能,包括:
      a.处理器型号及内存容量;
      b.外存容量、联机或脱机、媒体及其存储格式,设备的型号及数量;
      c.输入及输出设备的型号和数量,联机或脱机;
      d.数据通信设备的型号和数量;
      e.功能键及其他专用硬件
    4.2支持软件
      列出支持软件,包括要用到的操作系统、编译(或汇编)程序、测试支持软件等。
    4.3 接口
      说明该软件同其他软件之间的接口、数据通信协议等。
    4.4控制
      说明控制该软件的运行的方法和控制信号,并说明这些控制信号的来源。

     

    转自:https://blog.csdn.net/sinat_27261621/article/details/52754410

    展开全文
  • 软件工程之软件需求分析

    千次阅读 2018-09-27 10:41:45
    软件需求分析的任务(借助当前系统的逻辑模型推导出目标系统的逻辑模型) 深入描述软件的功能和性能 确定软件设计的约束和接口,同其它系统元素的接口细节 定义软件的其它有效性需求 需求分析的过程 (1)...

    软件需求分析的任务(借助当前系统的逻辑模型推导出目标系统的逻辑模型)

    深入描述软件的功能和性能
    确定软件设计的约束和接口,同其它系统元素的接口细节
    定义软件的其它有效性需求

    在这里插入图片描述

    需求分析的过程

    (1)问题识别
    软件的需求包括
    功能需求 ,资源使用需求,性能需求,成本消耗需求,环境需求,开发进度需求,可靠性需求,预先估计以后系统可能达到的目标,安全保密要求,用户界面需求
    在这里插入图片描述
    (2)分析与综合
    从信息流和信息结构出发,逐步细化所有的软件功能,找出系统各元素之间的联系,接口特性和设计上的约束,分析他们是否满足功能要求,是否合理
    常用的分析方法
    面向数据流的结构化分析方法(SA)
    面向数据结构的Jackson方法(JSD)
    结构化数据系统开发方法(DSSD)
    面向对象的分析方法(OOA)
    (3)编制需求分析阶段的文档
    软件需求说明书
    数据要求说明
    初步的用户手册
    修改,完善与确定软件开发实施计划
    (4)需求分析的评审
    系统定义的目标是否与用户的要求一致
    系统需求分析阶段提供的文档资料是否齐全
    文档中所有描述是否完整,清晰,准却反应用户的要求
    与所有其他系统成分的重要接口是否都已经描述
    (5)需求分析的流程(DFD图)

    在这里插入图片描述

    (6)软件需求分析的原则
    需要能够表达和理解问题的信息域和动能域
    要能以层次化的方式对问题进行分解和不断细化
    在开始建立分析模型前先理解问题
    开发原型,使得用户能够了解将如何发生人机交互
    记录每个需求的起源以及原因
    使用多个需求视图
    给需求赋予优先级
    努力删除含糊性

    分解法 在这里插入图片描述
    (7)软件需求规格说明的原则
    从现实中分离功能,即描述要“做什么”而不是“怎样实现”
    要求使用面向处理的规格说明语言(或称系统定义语言)

    展开全文
  • 如何进行软件需求分析

    万次阅读 多人点赞 2018-09-14 09:43:52
    如何进行软件需求分析 1、需求分析的重要性 软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。 通常,软件生存周期包括可行性分析与开发项计划、需求分析、设计(概要设计和详细设计)...

    如何进行软件需求分析

    1、需求分析的重要性

    软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。

    通常,软件生存周期包括可行性分析与开发项计划、需求分析、设计(概要设计详细设计)、编码、测试、维护等活动。

    常用的三种软件生命周期(瀑布模型、迭代式模型和快速原型模型)中,需求分析中都占据了举足轻重的作用,是系统分析、软件编程、软件测试和系统维护的输入物。

    1.1 瀑布模型

    瀑布模型由于酷似瀑布闻名,(Waterfall Model)首先由Royce提出。在该模型中,首先确定需求,并接受客户和SQA小组的验证。然后拟定规格说明,同样通过验证后,进入计划阶段…可以看出,瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样,瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到,因为整个的模型几乎都是以文档驱动的,这对于非专业的用户来说是难以阅读和理解的。

    瀑布模型图示如下:

     

     

     

     

     

     

     

     

     

    从上图可看出,需求分析的产出物《需求规格说明书》(有的项目组还会产出软件原型,例如静态HTML原型等)是后续设计、编码、测试和系统维护的基础。

    可将瀑布模型的“需求分析”阶段细分为“软件概念”和“用户需求分析”两个阶段,前者用于收集用户的原始需求,包括用户在功能、行为、性能、设计约束等方面的期望,并经过初步分析后形成《用户需求说明书》,而后经过进一步分析,将用户需求精确化、完全化,最终形成《需求规格说明书》。

    可将瀑布模型中的“系统设计”细分为“架构设计”和“详细设计”两个阶段,前者在总体上把握,更关注架构层面,包括系统的总体架构,以及各个子系统或各个模块之间的关系。后者更注重细节,包括系统设计的方方面面都要在详细设计中有所体现。

    作为系统分析师,或系统架构师,主要在“需求分析”和“系统设计”阶段体现自己的作用,后续的各个阶段主要通过与项目组成员的沟通贯彻自己的设计。

    1.2 迭代式模型

    迭代式模型是是RUP(Rational Unified Process,统一软件开发过程统一软件过程)推荐的周期模型。在RUP中,迭代被定义为:迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。

    在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程(编码流程)和测试工作流程。实质上,可将它理解为多个小型的瀑布式项目。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。

    迭代式原型图示如下:

    在每一个迭代中,“需求分析”阶段与瀑布模式一样,是后续系统分析、编码和测试阶段依赖的基础。如果需求分析有较大偏差,势必造成迭代过程中产生的一个产品子集有较大偏差。

    1.3 快速原型模型

    快速原型(Rapid Prototype)模型在功能上等价于产品的一个子集。注意,这里说的是功能上。瀑布模型的缺点就在于不够直观,快速原型法就解决了这个问题。一般来说,根据客户的需要在很短的时间内解决用户最迫切需要,完成一个可以演示的产品。

    在得到用户的需求之后,原型将被抛弃。因为原型开发的速度很快,设计方面是几乎没有考虑的,如果保留原型的话,在随后的开发中会为此付出极大的代价。

    在快速原型模型中,原型最重要的目的是为了确定用户的真正需求。从某种程度上,可以将快速原型理解为需求分析的一种更直观的方式,也是业界比较认可和取得良好效果的一种方式。

    2、需求分析的目标

    通过对应问题及其环境的理解与分析,为问题涉及的信息、功能及系统行为建立模型,将用户需求精确化、完全化,最终形成需求规格说明,这一系列的活动即构成软件开发生命周期的需求分析阶段。

    需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面,需求分析以系统规格说明和项目规划作为分析活动的基本出发点,并从软件角度对它们进行检查与调整;另一方面,需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误,从而提高软件生产率,降低开发成本,改进软件质量。

    3、如何进行需求分析

    3.1 需求分析的困难

    需求分析的目标,说得通俗一点,就是确定“做什么,不做什么”。但需求分析却不像想象的那么简单,主要因为如下原因:

    3.1.1 客户需求自身经常变动

    这世间的一切,只有“变化”是绝对的,从这点来理解,软件系统的需求不断变化也是可以理解的。老听设计人员和开发人员抱怨客户的需求老是变化,其实应该将“需求变化”理解为一种常态。

    引起需求变化的原因诸多,例如:

    (1)因为某些前置条件未满足,之前按照“妥协”方案实现,但若在某个时间点上这些前置条件被满足,于是引起了需求的变化。

    (2)某个后台操作之前不需要走审批流程,但因为客户的某个内部流程改变,需要走审批流程,势必引起需求 -> 设计 -> 编码 -> 测试的一系列变更。

    【对策】:因为需求变动无可避免,系统分析师在进行需求分析时需要明确:

    (1)尽可能地分析清楚哪些是稳定的需求,哪些是易变的需求。以便在进行系统设计时,将软件的核心建筑在稳定的需求上,否则将会吃尽苦头。

    (2)在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊,日后扯皮的事情就多。小的变动影响不大,也不致影响进度,但是对于一些改动会引起设计重大改变的需求,需要在合同中清楚说明。

    3.1.2 客户说不清楚需求,分析人员理解错误

    客户的计算机水平、对需求的理解、表达程度都参差不齐。有些客户对需求只有朦胧的感觉,当然说不清楚具体的需求。有些客户心里非常清楚想要什么,但却说不明白。有的客户本身就懂软件开发,能把需求说得清清楚楚,这样的需求分析将会非常轻松、愉快。

    不同性格、不同水平、与客户交流前准备情况不同的的系统分析师去跟客户讨论需求时,会得到很不不一样的结果。

    作为系统分析师,可以引导客户,先阐述常规的需求,再由客户否定不需要的,最终确定客户真正的需求。一个好的系统分析师,能从客户的一两句话中提出很多自己的观点或可进行拓展,进而进一步挖掘客户需求,或者若与之前的需求矛盾,可进行正确需求导向。

    【对策】:若客户说不清楚需求,为了不造成理解错误,系统分析师可采用多次沟通的方式,例如第一次通过客户初步了解需求,回去分析哪些是合理需求,那些是自相矛盾或不合理的需求,以及哪些是需要进一步明确的需求。经过细化后,第二次交流可提供PPT或简单的Word文档与客户进行第二次深入交流。第三次交流可通过建立快速模型进一步与客户交流得到精确的需求。需求分析也可参考“迭代式模型”来进行不断迭代,一直到挖掘出客户所有的潜在需求为止。

    3.1.3 客户在没看到原型或完整系统时,有一些潜在需求未被挖掘

    甚至有不少这样的客户,去进行需求沟通时提不出太多的需求,但是在你做完整个系统时,潜在需求突然迸发出来。

    【对策】:为了避免此种情况对项目造成破坏性影响,建议相关人员为一些大的功能模块建立快速原型让客户进行确认,并在合同中一定要说清楚“做什么”和“不做什么”

    3.1.4 多个相关方需求相互冲突,需求有二义性

    若些需求若牵涉客户不同部门,若有不一致意见,若私自按某一方的意见进行修改,很可能在后期涉及到按另一个部门的想法进行改造。

    【对策】:对于这种客户内部有冲突的需求,需求组织客户方相关部门一起讨论,由客户更高领导层决定实现哪一方的需求,或者采用折衷方案。需求说明不可有二义性,更不能前后相矛盾。如果有二义性或前后相矛盾,则要重新分析此需求。

    3.2 需求分析的活动

    3.2.1 需求获取

    通过与用户的交流,对现有系统的观察及对任务进行分析,从而开发、捕获和修订用户的需求

    软件需求常见的获取方法(在《软件需求获取方法》一文中写得很详细)如下:

    Ø 面谈

    个人觉得面谈是获取软件需求的最有用的方法,也是需求分析时常用的方法。通过多方面谈,得到的信息最多,进行我们现在所做的系统,与移动集团客户部、业务支撑部、网管中心、系统运营人员等都进行过面谈。

    面谈需准备的内容:面谈对象和面谈问题。

    面谈对象:需要尽量让面谈对象包括可与系统相关的涉众,并具有代表性,保证涵盖到每个角色。一般包括谁为系统付费,购买系统?谁使用系统?谁会受到系统结果的影响?谁来监管该系统?谁来维护系统?

    Ø 问卷调查

    调查问卷无法取代面谈在需求获取阶段的作用,问卷调查的问题和答案具有一定的引导性,在某种程度上会影响结果。

    问卷调查的结果好坏与问卷的设计有直接的关系,在做这个项目时,运营人员在进行前期推广会议上,也给企业客户发过调查问卷,但因为诸多原因,效果不甚理想,基本没为我们项目需求分析出多少力。

    Ø 小组讨论

    小组讨论是指将与项目某个问题相关的人员聚集在一起开会讨论。优势:容易在内部取得对方案的认同,有利于项目的开展;在讨论会上每个相关人员都可发表自己的意见,保证了获取信息的全面性。缺点:不容易把握。

    对于涉及系统边界的需求,或一些相互冲突的需求,采取该种方式是非常可取的。

    Ø 情景串联

    由于软件产品的抽象性,大部分涉众在脑海子未有一个清晰的产品轮廓,影响涉众对产品的理解。基于此可考虑编写清晰、完整的情景描述文档。

    1、采用PPT加图片的方式描述情景:一个好的PPT能更直观的描述各种情景;

    2、采用原型法(比较推荐这种方法)。

    Ø 参与、观察业务流程

    涉众描述的业务流程可能由于某些原因会遗漏掉重要的信息,需求分析人员可申请参与到他们具体的工作,观察、体验业务操作过程。需求分析员在观察业务操作过程时,可根据实际的情况提问并详细记录,记录业务操作员操作过程,操作过程中碰到的难题,可获取真实的材料和理解整个业务。

    Ø 现有产品和竞争对手的描述文档

    阅读现有产品文档有利于了解当前系统情况,从中也可以了解业务流程,对操作员反映的系统问题有着更深层次的理解。

    3.2.2 需求建模

    要有效地收集需求,您要做的第一步是建模,它包括创建体系结构的表示形式以捕获需求、就解决方案方法进行交流、以及分析所提出的系统设计。其目的是使用模型来表现系统中的关键方面。然后,您可以在形式化的分析、模拟和原型设计中使用这些模型,以研究预期的系统行为,并且可以在编写文档或总结时使用这些模型,以便就系统的性能和外观进行交流。

    Ø 域建模

    域建模指的是,您对问题域创建相应的模型并且把它划分为若干个内聚组的过程。然后,您可以在抽象模型中捕获业务流程、规则和数据。

    域模型是一种用于理解问题域的工具。您需要从信息系统之外的角度来理解这个域,这一点是很重要的。

    Ø 用例建模

    用例模型描述了各种参与者(人和其他系统)和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。

    用例模型应该将系统放到上下文环境中,显示系统和外部参与者之间的边界,并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者(例如,用户和维护人员)所看到的系统行为。

    Ø 组件和服务建模

    组件模型为子系统、模块和组件的层次结构分配需求和职责。每个元素作为一个自包含的单元,以用于开发、部署和执行的目的。组件模型的元素由它们所提供和使用的接口来进行规定。在这里,没有考虑其中的内部细节。

    服务模型将应用程序定义为一组位于外部边界(用例)、架构层之间的抽象服务接口,并且提供了通用的应用程序和基础结构(安全、日志记录、配置等等)。支持应用程序需求的这组服务可以与现有的内部和外部提供的接口规范相匹配。所得到的分析结果可以确定预置策略,并将项目活动划分为特定类型的部分,这取决于给定的服务是否已经存在(内部或者外部的,并且其中每个服务都具有适当的活动)、存在但需要进行修改(定义一个新的接口,并规划其实现)、或者必须构建新的服务。

    Ø 性能建模

    可以通过各种各样的方式来度量性能,最显而易见的方式是,应用程序执行其关键操作任务的速度。然而,作为一名架构师,必须考虑性能建模过程中其他的几个方面:

    l 构建和部署应用程序的速度如何?

    l 构建、维护和运行需要多少花费?

    l 该应用程序能在多大程度上满足其需求?

    l 对于必须使用该应用程序的人来说,需要为其付出多大的开销?

    l 该应用程序会对其他应用程序和基础结构产生怎样的影响?

    【说明】需求建模是一门深奥的学问,在做这个项目时,需求建模基本只是用到了“用例建模”,对一些典型流程进行用例建模。域建模、组件和服务建模和性能建模基本是空白状态,希望在下一个项目中有所改进。

    3.2.3 形成《需求规格说明书》

    生成需求模型构件的精确的形式化的描述,作为用户和开发者之间的一个协约

    3.2.4 需求验证

    以需求规格说明为输入,通过符号执行、模拟或快速原型等途径,分析需求规格的正确性和可行性

    3.2.5 需求管理

    支持系统的需求演进,如需求变化和可跟踪性问题。

    要在需求变更时,同步更新《需求规格说明书》以及相关文档,要知道,一个正确的文档是指导软件系统不同阶段的参考,但一个没有同步更新的文档是对软件系统有破坏性作用的,相关人员会受到错误引导。

    4、参考文档

    1、《需求分析的作用及如何进行需求分析》(张友生):

    http://www.educity.cn/se/requirement/200903310923051492.htm

    2、《软件生命周期_百度百科》:http://baike.baidu.com/view/3110371.htm

    3、《软件项目需求分析困难的原因》:

    http://developer.51cto.com/art/200512/15979.htm

    4、《需求建模》:http://blog.csdn.net/weishaofei/article/details/4371584

    5、《软件需求获取方法》:http://blog.sina.com.cn/s/blog_646b84760100s645.html

    6、《系统域建模技术》:

    http://wenku.baidu.com/view/8423fb97dd88d0d233d46ace.html

     

    展开全文
  • 软件需求分析方法

    2017-02-14 16:26:30
    软件需求分析(Software Reguirement Analysis)是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端,也...
  • 软件需求分析报告

    千次阅读 2019-09-24 11:56:42
    一、软件需求分析报告 1.任务概述  1.1.目标  我们小组的目标是设计一款类似于微博的软件,并以网页的形式呈现在用户面前。此款软件是一个基于用户关系信息共享、传播以及获取的平台。应用目标是日常信息的传播...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 36,756
精华内容 14,702
关键字:

软件需求分析