软件需求分析的内容
需求分析——分析软件用户的需求,细致的进行调查,把用户＂做什么＂的要求最终转换为一个完全的,精细的软件逻辑模型,并些出软件的需求规格说明,准确地表达用户的要求. 需求分析的任务 解决＂做什么＂的问题,全面地理解用户的各项要求,准确表达所接受的用户需求.
软件需求分析说明书怎么写
1.基本依据,可以依据可行性分析 2系统概述,系统目标 3.分析方法 4.信息采集 5.系统功能,包括用户界面等
软件的需求分析怎么写啊？
1. 引言
1.1 编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体.
1.2 项目背景
1.2.1项目委托单位:****公司
1.2.2开发单位:***公司
1.3 定义
1.4 参考资料
2. 任务概述
2.1 目标:
<1> 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示
<2>提高效率:利用软件进行管理,避免人工管理的失误以及 延迟性,从而实现高效率的管理.
2.2 运行环境:
<1> 硬件方面:Pentium级处理芯片
1兆显存的兼容显卡
256色,800*600的兼容显示器
标准兼容打印机
<2>软件方面: WIN95操作系统
2.3 条件与限制:
编程用计算机一台
完成期限2000/7/1
无资金供给
3. 数据概述
数据流程图如下:
3.1 静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据
3.2 动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间
3.3 数据库描述:
人事管理数据库:公司内人员的个人详细信息,包括档案信息
销售管理数据库:当日销售记录及以前的销售统计,用于销售分析
财务管理数据库:公司内部账目及收支情况详表
技术管理数据库:公司所需各技术档案的详细记录(包括文档)
3.4 数据字典:
<1>数据流词条描述:
1.数据流名:登录信息
来源:用户的输入
去向:系统内部检验部分
组成:用户名,密码
流通量:每次登录输入一次
2.数据流名:登录结果
来源:系统
去向:用户
组成:返回信息
流通量:每次登录返回一次
3.数据流名:输入修改信息
来源:用户
去向:系统判断部分
组成:根据各数据库内容而不同
流通量:依用户输入而定
4.数据流名:反馈信息
来源:系统判断部分
去向:用户
组成:系统经判断后发回的字符数据
流通量: 依系统当前信息而定
5.数据流名:识别信息
来源:系统内部检验部分
去向:系统判断部分
组成:系统各数据库的标识信息
流通量:用户每次输入流通一次
6.数据流名:处理信息
来源:系统判断部分
去向:各数据库处理部分
组成:读取/修改标识,读取/修改的变量名称
流通量:用户每次输入流通一次
7.数据流名:读取修改
来源:系统判断部分
去向:系统各数据库
组成:读取/修改标识,读取/修改内容
流通量: 用户每次输入流通一次
<2>数据文件词条描述:
1.数据文件名:人事数据
简述:存储人员信息
数据文件组成:人员的各项信息(以CString类型为主)
2.数据文件名:销售数据
简述:存储当日及从前的销售记录
数据文件组成:销售的各项信息
3.数据文件名:财务数据
简述:存储财务管理信息
数据文件组成:财务管理的各项记录
4.数据文件名:技术数据
简述:存储公司内部使用的技术档案信息
数据文件组成:技术档案名称,内容
<3>加工逻辑词条描述:
1.加工名:检验
简要描述:判断用户的许可性
输入数据流:登录信息
输出数据流:登录结果
加工逻辑:判断是否与系统内部用户信息相符合
2.加工名:判断
简要描述:判断用户的操作并进行相应的读取/存储工作
输入数据流:输入修改信息
输出数据流:反馈信息
加工逻辑:判断用户的操作->调用数据库->读取/修改->反馈
3.加工名:人事档案管理
简要描述:对人事数据库进行相应要求的操作,并与判断部分交互
输入数据流:处理信息,读取修改
输出数据流: 读取修改, 处理信息
加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息
4.加工名:销售统计
简要描述:对销售数据库进行相应要求的操作,并与判断部分交互
输入数据流:处理信息,读取修改
输出数据流: 读取修改, 处理信息
加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息
5.加工名:财务统计
简要描述:对财务数据库进行相应要求的操作,并与判断部分交互
输入数据流:处理信息,读取修改
输出数据流: 读取修改, 处理信息
加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息
6.加工名:技术管理
简要描述:对技术统计数据库进行相应要求的操作,并与判断部分交互信息
输入数据流:处理信息,读取修改
输出数据流: 读取修改, 处理信息
加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息
<4>源点及汇点词条描述:
名称:用户
简要描述:既是源点又是汇点,发出动作信息给”检验”和”判断”加工,通过交互界面接受反馈信息有关数据流:登录结果,登录信息,输入修改信息,反馈信息
数目:一个
4. 功能需求
4.1 功能划分
可细分为四部分:人事管理,销售管理,财务管理,技术档案管理
4.2 功能描述
<1>人事功能:
(1)能对公司内部的所有人员有关档案详细资料记录并保存。
(2)能对数据库内人事档案的数据进行查阅和修改。
(3)能按部门或姓名检索人员。
(4)当某员工的雇用期限达到整年时，按时提醒。
<2>销售统计功能
(1)按日对公司的销售情况进行统计,包括销售额\销售数量\各地区销售比例\不同销售方式的销售量比例以及销售毛利润情况
(2)制定销售情况的月报表\季报表以及年报表对销售情况进行分析,对不同销售人员的业绩进行评定
<3>财务管理功能
(1)协助财务人员进行计算机管理,对库存情况\进货情况\销货进行登录和输出
(2) 根据预设的库存情况提醒进货
(3) 对收款情况进行统计,在应收帐款达到预设值时进行提示
<4>技术管理功能
(1)对技术资料进行登录
(2)对维修记录进行登录和统计,按不同型号的机器进行故障整体分析,并作出分析报告
(3)对维修配件的需求进行管理并及时提示备货
5. 性能需求
5.1 数据精确度:因为此数据为公司内部数据,所以要求不能有误差
5.2 时间特性:当日销售统计要求有即时性,马上能反应出存货的问题;同时财务管理数据计算当前存货情况,并对进货情况进行估算
5.3 适应性:此软件只在公司内部管理人员的机器上使用,因此不考虑适应性
6. 运行需求
6.1 用户界面:
屏幕格式:
(1)要求有菜单及工具栏以方便操作
(2)各数据库信息可在屏幕上直接修改
(3)各数据统计结果可在屏幕上显示
(4)进行系统分析后的结果在另一窗口中显示
报表格式:
(1)人事管理报表只要求有个人的普通数据
(2)销售统计报表要求可分别打印当日统计或之前的统计
(3)财务统计报表要求打印出存货及公司帐务详表
(4)技术管理报表要求可以分别打印技术档案总表和任一技术档案文档内容菜单格式:要求菜单项大致与WIN95标准相同,另外附加的功能做到新的单项中输入输出时间:年份以4位数字表示
6.2 硬件接口:需要标准打印机接口进行报表打印
6.3 软件接口:Windows标准接口
7. 其他需求
可使用性:要求容易使用,界面友好
安全保密性:因本数据属于公司内部管理用关键数据,因此除公司管理人员外,其他人员不得访问.要求设有登录密码检验功能,并且此密码可以在以后进行修改
可维护性:要求本软件的维护文档齐全,便于维护
怎样做软件的需求分析？
软件需求的定义：
（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。
需求工程的定义：
需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
需求开发与管理的一些方法：
（1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
（2）可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
（4）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。。
（5）图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
（6）数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。
需求管理的方法主要包括以下一些方面：
1）确定需求变更控制过程。制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。
2）进行需求变更影响分析。评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。
3）建立需求基准版本和需求控制版本文档。确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
4）维护需求变更的历史记录。将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。
5）跟踪每项需求的状态。可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。
6）衡量需求稳定性。可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。过多的需求变更”是一个报警信号”，意味着问题并未真正弄清楚。
4.需求分析评价标准
（1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。 除了语言的二义性之外，注意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。
（2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。但实际情况是，需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。
（3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。在需求过程中，开发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。
（4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。这就要求需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。
求一款孕婴店管理软件要求的功能如下:
那就要网络版的,普通单机版的实现不了异地联网查看.网络版现在孕婴店用得较多的是x8销售管理系统
如何进行软件需求分析
功能：
软件功能又分关键功能，次要功能等。在第二阶段，我们要做的就是分辨并整理关键功能，和次要功能。根据项目的规划，找出当前需要实现的关键功能，与此同时，对于高风险，技术风险大的功能，或者关键功能中相互冲突的功能进行前期取舍。（当然啦，在取舍和确定具体的功能范围，还是要和客户之间相互沟通的）
最后要补充一点的，就是确定关键功能这个过程是不停递归的一个过程。
质量：
一般质量分类包含 性能，安全性，可靠性，易用性，可扩展，可维护，可移植等。
在需求分析中，和关键功能一样，要根据项目的愿景，进行关键质量的筛选。
在某种情况下软件的质量之间还是有冲突，鱼和熊掌不可兼得的情况，如 可维护性和性能是一对对立的两兄弟。我们还需要对这样的关键质量进行必要的取舍。在作出这样的取舍，依据的标准就来源于我们需求的第一阶段的工作。
约束：
软件的约束分好多的角度，
业务级约束：举例：项目的组织结构和人员信息来源于企业人事系统
用户级约束：举例：使用客户用一部分是残障人事等，其包含了藏语用户等
开发级约束：举例：开发人员的技术水平等。
在调研并完成这样的二维需求表后，及时的和客户沟通，确定关键功能，关键质量和约束等。对二维需求表中的内容进行取舍和确定。
在第二阶段出的配置项二维需求表
在第二阶段的基础上，我们就可以对项目核心功能进行数据流需求调研分析，业务逻辑分析。并在这基础上编写用户用例 ，数据流转图，业务逻辑图等
在完成了以上业务核心功能的详细调研分析后，将全部用例和其他内容组合在一起，制定《项目需求规格说明书》。
请问一下软件需求分析的任务有哪些呢?
结构化程序设计和确定逻辑模型都不是软件需求分析的任务
如何才能把软件需求分析做好？
我的第一个故事来自大名鼎鼎的东软。我在2005年接一个项目的时候，听说这个项目之前是东软做的。当时东软在做这个项目的时候，整个过程经历了10多次结构性的大变更，局部性的调整更是不计其数。据说某天早上，客户对某个功能不满意，他们不得不对几百处程序进行修改。之后客户对修改的内容还是不满意，又不得不将几百处修改重新改回来。最后这个项目导致的结果是，整个这个项目组的所有成员都离开了东软，并似乎从此不愿涉足软件开发领域。多么惨痛的教训啊!我常常听到网友抱怨客户总是对需求改来改去，但客户对需求改来改去的真正原因是什么呢?当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢?他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
软件需求分析的过程
软件需求分析所要做的工作是深入描述软件的功能和性能,确定软件设计的限制和软件同其它系统元素的接口细节,定义软件的其它有效性需求.进行需求分析时,应注意一切信息与需求都是站在用户的角度上.尽量避免分析员的主观想象,并尽量将分析进度提交给用户.在不进行直接指导的前提下,让用户进行检查与评价.从而达到需求分析的准确性.分析员通过需求分析,逐步细化对软件的要求,描述软件要处理的数据域,并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示.在软件完成后,制定的软件规格说明还要为评价软件质量提供依据.
如何做好软件项目需求分析
需求分析是介于系统分析和软件设计阶段之间的重要桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。
需求分析阶段的基本任务是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件其它有效的需求。
最主要的原因是对于开发小组的使用成员（包括用户）来说，需求确定是极具认知性和创造性的活动。需求确定也许是仍在苦苦等待人工智能支持的最后领域之一。具体表现如下：
系统分析员对问题域的了解程度也是一大困难。
系统分析员感到需求确定很困难的另一个原因是问题域的动态性。
生活是动态的，公司也是。
项目团队成员之间的沟通也一直是需求确定的另一大困难。
每个问题域都有术语。
最后，需求确定过程还会受到其它因素的影响。例如劳累、不舒服、开会时室内和窗外的干扰、团队成员的压力等等。
