需求调查与分析注意点

很多人认为企业信息化的前提是业务流程要相对固化,因为计算机能处理的都是规则化的东西。这种看法无疑是对的,但如何正确地看待和处理相对二字却是让很多IT人非常头痛的(IT
就是挨踢说法也是由此产生)。当今世界各行各业唯一不变的就是时刻都在变化,企业信息化应该要能让自己的企业更能适应各种各样的变化。于是矛盾产生了。很多人都懂得事后修改不如事前规划并实现来得好,因为这样省时、省力、省钱。因此这就对需求调查分析工作提出了更高的要求。

在需求分析报告中一定要有对所分析对象的将来发展变化的前瞻性和预见情的陈述。只有如此架构和实现人员才可能在实现过程中充分考虑并留下可扩展接口。因此对前瞻和预见性陈述得越多、越精、越准则后其因业务变化而产生的修改或修改程度就会越少,将来产品的可扩充情和可扩展情也越强。这也要求需求分析人员对业务非常熟悉(我猜这也是我们这行业务专家比技术专家值钱的原因,因为业务专家必须通过较长时间的浸泡才可,而技术专家则不然)。

在需求分析报告中还要有对分析对象本次要解决问题的范围的确定描述。人要解决一个问题要考虑其周边的一些问题,但周边的一些问题是否要列入本次要解决问题的范围则要认真考良。一句话就是要分清主次,把本次要解决的问题圈定在一个范围之内而避免将问题无限扩大或减少。

对软件产品的功能需求与性能需求描述也很重要。功能需求是指产品要能够及时无误做那些事情。性能需求是指除功能需求之外的其他需求,也叫非功能需求,如产品的实现某项功能时的响应时间、可靠情、可移值情、所需要的资源等。功能需求大家比较不容易忽略,也会描述得很清楚。与性能需求相对比,性能需求往往很容易被忽略,但评定一个软件的好坏,其各方面的性能也会起决定性的作用。

对由软件使用者引起的异常状况的处理也应在需求分析时有所考虑。人非圣贤,谁能无过,而在企业中前段流程中所犯的错误肯定会甚至是最终结果。当后段人员发现前段或前几段人员的错误时某些错误的结果已产生,这时提供什么方式让用户或维护人员来纠正这些错误就成了必须要考虑的事情。需求分析人员必须要明白每一业务的最终目的是什么,为了实现这些目的那些因素是企业内部可协调的,那些是不可协调的。

本文只是列举了笔者认为需求分析中比较容易忽略的几个点,其实我还觉得有很多东西因我水平和文笔的原因没有表达出来,只好草草收编。也望诸君指正及扩充!

需求调查与分析注意点

时间: 2024-10-10 07:40:02

需求调查与分析注意点的相关文章

《JUST DO IT!》团队作业4-基于原型的团队项目需求调研与分析

一.实验目的与要求 (1)体验以原型设计为基础的团队软件项目需求获取技巧与方法. (2)学习利用UML模型描述用户需求. (3)编写软件需求规格说明书. 二.实验环境要求 (1)实验七开发的团队项目原型: (2)UML绘制工具. 三.实验内容与步骤 实施团队项目软件用户调研活动. 1.需求调研方法 (1)原型法 将我们APP端和WEB端的原型发给调研用户,用户通过使用反馈给我们一些意见和建议. (2)远程交流 我们选取典型用户通过qq在线交流的方式获得用户的需求,在了解完用户的需求过后将我们已经

A_Pancers团队作业4—基于原型的团队项目需求调研与分析

任务1:实施团队项目软件用户调研活动. (1)用户调研对象:我们的项目软件是基于安卓系统的音乐播放器,以设计出操作简单的音乐播放器为目的,所以本次用户调研的对象主要以身边的老人为主,对他们听音乐,听戏曲的情况进行了解,看他们对于音乐播放器有何需求,有何期待:并将我们设计出的项目模型对他们进行介绍,听取他们的意见和建议.另外考虑到为了获取更加全面的需求其他年龄阶段的人为辅助调研对象(例如:身边的同学.家长.朋友等). (2)调研方式:对于老人这个用户对象我们采取了面对面采访的方式进行调研,而对于其

需求用例分析之异常流

问题的引出 备选流,又称备选事件流,英文是Alternative Flow.在RUP和UML中,备选流的解释如下:备选事件流包括与正常行为相关的可选或异常特征的行为,同时也包括正常行为的各种变形.您可以将备选事件流看作是基本事件流的"绕行道",有些备选事件流将返回到基本事件流,而有些将结束此用例的执行. 分析RUP对于备选流的定义,可以看到备选流可以分成两类: 1,不同做法但仍然达成用例目标: 2,异常情况,无法达成用例目标. 在实际用例分析中,由于备选流可能存在两种情况,导致备选流存

需求用例分析之二:级别设置

在<编写有效用例>(阿莱斯特-科伯恩著,下面用科伯恩用例来指代)一书中,赋予了用例不同的级别,科伯恩形象的设定了例如以下级别:海平面.云朵.风筝.蛤等等. 科伯恩建议用例级别分为多个个目标层次:概要.用户目标.子功能,书写需求用例时,仅仅能选择其一,以下对其详细说明: 概要:包含多个用户目标,它有"显示相关目标的生命周期顺序"和"为低层用例提供一个文件夹表"的功能,概要用例通常须要运行几个小时.几天.几个星期.几个月.甚至几年. 用户目标:它是主运行者努

苍狼敏捷需求用例分析方法简介并讲义下载

作者:张克强    作者微博:张克强-敏捷307 用例分析方法已经有不短的历史,发展出了多种用例分析方法.笔者花费了大量时间,对用例分析的各个方面进行实践和分析,得到如下系列文章: 需求用例分析之一:异常流 需求用例分析之二:级别设置需求用例分析之三:补充规约 需求用例分析之四:业务规则 需求用例分析之五:业务用例之Rational系 需求用例分析之六:业务用例之科伯恩系 需求用例分析之七:业务用例之小结 需求用例分析之八:用例颗粒度 在这些分析的基础上与及笔者的实践,总结整理得到"苍狼敏捷需求

需求用例分析之业务规则

作者:张克强 作者微博:张克强-敏捷307 在雅各布森用例分析方法和科伯恩用例分析方法中其实都没有"业务规则"的属性,在科伯恩方法中有个相近的属性是约束条件.但是业界使用中常常会给用例加上这个属性,这是为什么呢?为什么两位大师没有加上,是大师们疏忽了?而为什么不少人加上了呢? 从时间和传播上很容易推断,业务规则的来源是传统的需求规格说明书.在传统的需求规格说明书中,整理提炼业务规则或称业务逻辑是其中核心的分析产物.受到传统需求规格说明书的深远影响,不少人觉得这样的业务规则是值得写的用例

需求用例分析之补充规约

补充规约在RUP中是记录那些在用例模型的用例中不容易体现出来的系统需求.这些需求包括: § 法律法规方面的需求和应用标准. § 要建立的系统质量属性,包括可用性需求.可靠性需求.性能需求和可支持性需求. § 其他需求,诸如操作系统和操作环境.兼容性需求以及设计约束. 补充规约是对用例模型的重要补充.补充规约和用例模型应该一起获取对系统的一整套需求. 通过以上文字可以知道,补充规约是全局性的要求,与上述c文中的"全局规则"极为接近.而中文中"补充规约"的说法让不少人以

需求用例分析之九:序列图

作者:张克强    作者微博:张克强-敏捷307 序列图,也称时序图.顺序图,英文名Sequence Diagram.在雅各布森用例分析方法中鼓励使用各类图形来表达,但恰恰没有明确提到序列图.而科伯恩用例分析方法以结构化/半结构化文本用例为中心,强调基于目标的文本格式,对UML各类图所提甚少. 在RUP和OOAD中,UML序列图的最基本定位是用于识别类与类之间的信息传递,是识别类的方法的最佳场合.它是在得到用例之后初步识别了类之后发挥巨大作用的.序列图是交互图(interaction diagr

需求用例分析之级别设置

在<编写有效用例>(阿莱斯特-科伯恩著,以下用科伯恩用例来指代)一书中,赋予了用例不同的级别,科伯恩形象的设定了如下级别:海平面.云朵.风筝.蛤等等. 科伯恩建议用例级别分为多个个目标层次:概要.用户目标.子功能,书写需求用例时,只能选择其一,下面对其具体说明: 概要:包括多个用户目标,它有"显示相关目标的生命周期顺序"和"为低层用例提供一个目录表"的功能,概要用例通常需要执行几个小时.几天.几个星期.几个月.甚至几年. 用户目标:它是主执行者努力使工作