HNU_SRE_软件需求的本质

Project stakeholders:

  项目干系人/项目涉众:参与软件项目或受软件影响的人

  主要包括:

    客户,用户,需求分析员,开发人员,测试人员,文档编制人员,法律人员,生产人员(制造包含软件的产品),其他人员(市场策划,营销,技术支持等)

需求工程:

  包含着与发现、记录和维护计算机系统的需求相关的所有活动。“工程”意味着应该采用系统的和可重复的技术来确保系统需求是完整的,一致的和相关的。

  RE是从系统工程角度定义。从业务系统角度,可以看作系统分析。

ENGLISH:Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system.

软件需求的三个层次:

  业务需求Business~:反应组织或客户对系统、产品高层次的目的要求;(项目远景与范围文档)

  用户需求User~:描述用户使用产品必须完成的任务;(使用实例文档Use-case)

  功能需求Functional~和非功能需求:描述系统展现给用户的行为和执行的操作等;(软件需求规范和模型)

需求规格说明书:要得到客户的认可;为开发人员提供指导;

需求定义的要点:

  定义“做什么”,不描述“怎么做”

  软件需求规格说明(SRS)重点描述产品应达到和满足的功能与非功能需求特性

  软件开发与运行环境,开发进度,产品成本,培训需求等内容应该在项目需求中进行定义

需求开发和管理:

  软件需求工程领域划分为需求开发和需求管理。

  需求开发:产生经过验证的SRS

    Elicitation 获取;Analysis 分析;Specification 规范说明;Validation 验证  

  需求管理:以SRS为基线,对需求变更进行控制和管理

  (基线:已通过正式评审和批准的规约或产品,他将作为进一步开发的基础,只能通过正式的变更控制过程来改变。)

    Version Control 版本控制;Change Control 变更控制;Requirements Tracing 需求跟踪;Status Tracking 状态跟踪

每个项目都有需求:

  核心问题不在于写需求,而是判断需求;

  如果项目团队写的需求得不到干系人的认可,则开发人员无法确定自己的工作是否令干系人满意;

  不知道需求,则何时完工,是否满足目标等情况就无法确定

劣质需求产生的原因:

  认识不到位;易变性;不确定性;

  没有抓住主要矛盾;没有强调质量(SRS不符合要求);

  分析不全面;设计没有反映实际情况。

高质量需求过程的好处:

  需求缺陷和产品缺陷更少;后期和维护返工减少等

优秀需求的特点:

  完整性Completeness

  正确性Correctness

  可行性Feasibility

  必要性Necessity

  优先性Priority

  无二义性Unambiguity

  可验证性Verifiablity

  完全性Integrity

  一致性Consistency

  可修改性Modifiable

  可跟踪性Traceability

原文地址:https://www.cnblogs.com/Comet-Fei/p/12331721.html

时间: 2024-10-11 09:05:31

HNU_SRE_软件需求的本质的相关文章

软件需求模式阅读笔记之五

这周我学习的是软件需求模式的第二章------需求规格的内容. 目前为止还没有唯一正确的方法阻止需求规格,但是反复出现在大部分系统中的主题,是我们应该注意和掌握的内容.从大的方面来说,需求规格可以分为四个部分,分别是介绍部分,上下文部分,功能域部分,主要非功能要求部分四个方面,其中功能域部分定义了系统实际上要做的内容. 介绍部分包括系统目的,文档目的,需求格式,词汇表,参考书目以及文档历史.这个板块主要是介绍系统规格.这其中要注意,系统目的是系统本身的目的,而不是项目的目的,是落脚于功能的:文档

软件需求与分析之必要内容——课后作业01

软件的项目,有成功的案例,但是除此之外,也难免会有失败的经历,而且这也不在少数.造成项目失败的原因多种多样,客户关系.设计.技术.时间管理.问题培养,但是归根到底,更多的问题还是归咎于需求分析没有做完善:被不懂技术的客户牵着走,没有分析到位:没有弄清需求是否能给予我们现有的技术:是否触及到了有需求的所有层面的人员,没有合理安排和客户进行需求的多方面交流,来保证项目的成功,这些都源于没有做好需求分析.为了不重蹈覆辙,了解软件需求与分析十分有必要. 做需求分析大多是从需求调研开始的,尽管如此,但是重

《软件需求最佳实践》阅读笔记一

这本书主要从软件需求实践中出现的主要问题和困难入手,指出了改造的主要方法,然后逐一说明了需求定义.需求捕获.需求分析与建模.编写规约.需求验证等需求开发活动的任务.要点和具体手段.还对包括需求基线.变更管理.需求跟踪在内的需求管理活动的操作要点进行了阐述. 软件项目实施过程中,会遇到很多的问题,有的甚至许多项目根本无法达到预期的目标,这些问题的根源就是软件需求实践.“在中国做软件太难了!客户连自己的需求都说不清楚!”,这种抱怨的话经常被做软件需求的人说到.需求失败也是因为不完整的需求.缺乏用户参

《软件需求十步走》读书笔记二

这次都<软件需求十步走>的后三篇,分别为“方法篇”.“规划篇”.“开发篇”. 方法篇: 1.需求工程的方法观 方法的使命就是要将问题的结构和规律展现出来 2.分析计算方法 分析计算是需求规划方法与传统需求分析方法有本质区别的地方之一.分析计算包括系统支撑能力计算和业务发展能力计算 3.结构化分析方法 结构化的分析(又称SA)方法是本书在需求规划中的业务建模.系统建模和体系建模所采用的方法 4.面向对象分析方法 在需求分析中本书采用面向对象的分析方法作为用例分析和功能需求分析的方法 5.需求统一

软件需求十步走读书笔记2

今天读完了软件需求十步走的第二部分.读了知识篇和方法篇.在知识篇中知识体系的构建方法 事物的知识是由知的知识和识的知识构成.识的知识是以知的知识为核心的需求工程的知识构成 需求工程的知识体系是由基础知识体系.专用知识体系.特有知识体系三个部分构成需求工程的基础知识 形式逻辑中演绎.推理.假设.论证等方法对于解决软件需求中“不完整.不准确.总在变.不一致”问题具有帮助需求工程的专有知识.需求工程的专有知识包括软件工程.软件体系架构和信息资源规划需求工程的特有知识 需求规划是新一代软件需求工程有别于

软件需求阅读笔记3

IEEE对需求定义为:①用户为了解决问题或达到某些目标所需要的条件或能力.②系统或系统部件为了满足合同.标准.规范或其他正式文档所规定的要求而需要具备的条件或能力.③对①或②中的一个条件或一种能力的一种文档化表述.通过这个定义了解了需求并不是用户想要的,想实现的,了解了需求本质的内涵. 功能需求是软件系统需求中最常见.最主要和最重要的需求,同时也是最为复杂的需求.功能需求通常体现为三个层次:业务需求.用户需求.系统需求. 业务需求描述了组织为什么要开发系统,满足用户的业务需求.业务需求是用户需要

软件需求与分析 - 认识

经验人 1 :没有技术背景很难真正成为一个优秀的软件需求分析师,最多也就是一个业务需求分析师. 经验人2 :软件需求在整个软件生命周期中的定位来看,其上接业务,下接设计和技术.从这个概念上来讲软件需求人员必须具备业务和技术两个方面的能力. 菜鸟的软件需求分析知识体系架构 个人认识: 我以为对于软件需求来说,我感觉并不需要什么具体的知识体系,会局限我们的想法(我的意思是不要让思想拘束起来,解决了本质问题的就是好方法),私以为:需求的目的是做出"符合"的软件,用户想要的 和软件功能的符合.

软件需求与分析课堂讨论一

课堂讨论 分组:每4人一组 内容: 某大学为进一步推进无纸化考试,欲开发一考试系统.系统管理员能够创建专业方向.课程编号.任课教师等相关考试基础信息.教师和考生进行考试相关工作.系统与考试有关的主要功能如下: (1)考试设置:教师制定试题(题目和答案),制定考试说明.考试时间和提醒时间等考试信息,录入参加考试的学生信息,并分别进行存储. (2)显示并接收解答.根据教师设定的考试信息,在考试有效时间内向学生显示考试说明和题目,根据设定的提醒时间进行提醒,并接收学生的解答. (3)处理解答.根据答案

需求工程-软件需求模式读书笔记1

今天读完这本书<软件需求模式>的第一部分,也就是准备阶段. 需求分析是困难的.需求分析师又往往缺少经验和训练.本书的目的是帮助和决定新的软件应该走什么,建议添加那些额外的特性,使系统更好或更卓越.需求模式是经验的结晶,本书主要建好了37个模式,解决了所有系统中反腐出现的特定问题.适合业务分析师.软件架构师和工程师.软件开发人员.软件测试人员.项目经理等人员阅读.. 软件系统的需求定义他要定义的问题:它的的意图和目的.为了更好地构造系统需要一系列的改进.该书主要可分为两部分:第一部分:解释开始,