软件需求-架构师之路(五)

这篇具有很好参考价值的文章主要介绍了软件需求-架构师之路(五)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

  • 软件需求

软件需求:

指用户 对系统在功能、行为、性能、设计约束等方面的期望。

分为 需求开发 需求管理 两大过程。

需求开发:

  1. 需求获取
  2. 需求分析
  3. 需求定义(需求规格说明书)
  4. 需求验证:拉客户一起评审,没问题签字。

这里评审确定后就形成需求基线。下面就是需求管理,如果变更需求就超过了基线。

需求管理(支持需求开发):

  1. 变更控制:加需求必需严格控制。
  2. 版本控制
  3. 需求跟踪:跟踪需求变更。
  4. 需求状态跟踪:需求是否完成跟踪。

重点:软件需求分为 业务需求用户需求系统需求,三大类。(重点:业务需求用户需求系统需求

业务需求:反映 企业和客户对系统高层次目标要求,通常来自项目投资人、市场营销部或产品策划部。

用户需求:描述 用户具体目标,用户要求系统必需完成的任务,通常采用用户访谈和文件调查。

系统需求:系统角度的需求,分为 功能需求,非功能需求和设计约束等。

功能需求:开发人员需要实现的功能。

非功能需求:系统必需的属性,如可维护,高效率,可靠性等性能。

设计约束:对系统的一些约束说明,例如必需采用自主知识产权的数据库系统,必需运行在linux系统下等。

真题:

某软件公司正在承担开发一个字处理器的任务,在需求分析阶段,公司的相关人员整理出一些相关系统需求,其中,“找出文档中的拼写错误并提出一个替换项列表来供选择替换拼写错误的词”属于();“显示提供替换词的对话框以及实现整个文档范围的替换”属于();“用户能有效纠正文档中的拼写错误”属于()。

  1. 业务需求
  2. 用户需求
  3. 功能需求
  4. 性能需求

答案:B、C、A

解析:

第三个 抽象程度很高“用户能有效纠正文档中的拼写错误”在前,之后第一个在后“找到错误并替换错误”。

第一个找到错误并替换,用户去找。

第二个显示词语,功能需求。

第三个能有效找到的要求,业务需求。

第三个则是提出的也无需求,提出来后,则用户去找到错误改正,第一个。所以第三个是业务需求,第一个是用户需求。  第二句话则是实现,用代码。

二、需求获取

需求 获取不同用户和干系人的需求和约束。

常见获取方法:

用户访谈、问卷调查、采样、情节串连班、联合需求计划、需求记录技术。

联合需求计划(JRP):就是联合各方,如需求分析师,开发等一起开会。

问券调查:大量数据无法一一 访谈。

用户访谈:良好灵活性,应用范围广,但存在获取信息大、记录困难和需要足够知识领域等问题。

采样:基于 数理统计原理,不仅用于收集数据,还可以用采访用户或采集用户,减少数据偏差。

三、需求分析

需求分析:把杂乱无章的用户要求转化为用户需求。

结构化的需求分析

自顶向下,逐步分解,面向数据。

三大模型:功能模型(数据流图)、行为模型(状态转换模型)、数据模型(E-R图)以及数据字典。

软件需求-架构师之路(五),架构师,软考高级,需求分析

 

长方形:外部实体。

圆形或者椭圆形:加工。

箭头线条代表:数据流。

两条线代表:数据存储。

数据流:必需经过加工。

加工:

有输入但没输出,则是黑洞。

有输出但没输入,是奇迹。

输入不足以产生输出,是灰洞。

外部实体:

软件系统之外的人员或者组织,指系统所需发源地和归宿地。

  • 数据字典

数据字典DD

数据字典为数据流图每个数据流、文件、加工以及组成数据流或文件数据项作出说明。

4个类目:数据流、数据项、数据存储和基本加工。

加工逻辑结构化语言、判定表和判定树

= 表示被定义

= 与 x=a+b,表示x由a和b组成

[...|...] 或,x=[a|b],x表示a或者b

{......},x=[a],0个或者多个a组成

  • 需求定义

需求定义是整个需求开发的基础。SRS是软件开发过程最重要文档之一,对任何规模和性质都不应该缺少。

需求定义方法:

  1. 严格定义称为预先定义,所有需求都能够预先定义。开发与用户之间能够准确清晰交流,
  2. 原型方法:迭代的循环开发方式,原型客服了困难的一种手段,项目干系人都存在交流困难。

需求验证:

称为需求确认,目的与用户一起确认需求无误,对需求规格说明书SAS进行评审。

需求评审:正式评审和非正式评审。

需求测试:设计概念测试用例。

需求验证通过后需要签字,不可以随意更改。

需求跟踪分为双向跟踪,正向跟踪和反向跟踪。

正向跟踪 去看看产品实现的有没有少实现。

反向跟踪 去看看之前的文档有没有多实现。

重点)需求变更的管理过程:

变更请求、团队分析影响评估、评估结果通知干系人、CCB审批(绝对性领导)、

同意的话

执行变更、记录变更实施情况、分发新文档

CCB是控制委员会。文章来源地址https://www.toymoban.com/news/detail-655149.html

到了这里,关于软件需求-架构师之路(五)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包