人人都是架构师:非功能性需求

需求是最重要的事情,失去了功能,失去了客户的价值,软件将一无是处。

然而,功能的实现只是架构的开端。

架构首先来自需求,需求驱动架构,然后非功能性需求反映服务等级,面对客观环境的约束,自行引入的架构实现原则,是在高层次以上对需求、约束、和原则的理解和把握。

非功能性需求也可以称为质量属性,我所了解的非功能性需求主要有:

  1. 性能:响应时间或延迟
  2. 可伸缩性:更多用户,请求和数据的处理能力
  3. 可用性:99.9%意味着每天一分钟故障
  4. 安全性: 可以参考OWASP,open web application security project
  5. 灾难恢复:业务连续性过程
  6. 可访问性:www.w3.org/standards/webdesign/accessibility
  7. 监测:只读视图
  8. 管理:操作视图
  9. 审计:日志及虚拟货币的对账
  10. 灵活性:非技术人员修改业务规则的能力
  11. 可扩展性:可以做现在还不能做的事情
  12. 可维护性:可读性,可持续发展
  13. 法律规则:如隐私
  14. 国际化i18n
  15. 本地化i10n

一时想不起更多了,欢迎补充。

时间: 2024-11-01 17:54:04

人人都是架构师:非功能性需求的相关文章

人人都是架构师

http://www.devdiv.com/blog-1895-57919.html 架构是什么?业界并没有权威的说法. 架构作为名词与结构相关,将产品分解为一系列组件.模块和交互.作为动词,是关于交流愿景和引入技术领导力的,简而言之,架构就是结构和愿景. 关于架构 应用程序的架构着重于软件和代码的组织,每个工程师的代码都是有架构的,只是自发和自觉的区别:系统架构描述从组件和服务到子系统等更高层次的抽象含软硬件,从代码结构到生产环境,与软件系统重要元素相关的所有东西就是软件架构.企业架构是一个截

人人都是架构师: 约束和原则

约束 时间和预算是约束的基本条件. 技术约束 技术清单,现有系统的互操作性(兼容性),目标部署平台,技术成熟度(保守),开源技术,供应商关系(阿里云,还是AWS),过去的失败,内部知识产权 人员约束 团队规模,技能,团队扩展的速度,咨询和培训,运维团队的技能 组织约束 企业战略的影响,办公室政治的影响 约束条件也是有优先级的. 原则 开发原则 编码标准和规范,自动化单元测试,静态分析工具 架构原则 1)分层策略,如UI组件里没有数据访问的逻辑 2)业务逻辑的位置: 3)高内聚.低耦合:解耦合可以

人人都是架构师:面对风险

架构包含技术的选择,更多分层等于更高的复杂度,但是轻量级协同设计可以提高质量.最佳实践也是有使用条件限制的,面对架构要用于质疑. 系统的最大风险 外部接口是系统风险最高的部分之一. - 关键的外部接口有哪些?接口的技术定义是什么? - 哪些队列是通信组件?消息的格式是什么? - 同步还是异步?异步连接是否有保障?能否乱序传输? - 接口是否幂等?接口的可用性.性能.可伸缩性.安全性? - 接口的所有权属?版本的升级处理?服务级别? 系统的常见风险 除了外部接口之外,其他的常见风险如下: - 组件

影响架构决策的非功能性需求

本文由<IEEE Software>杂志首发,现在由InfoQ和IEEE Computer Society联合向您呈现. 在软件工程中,非功能性需求(nonfunctional requirements,简称NFRs)与软件架构(software architectures,简称SAs)之间存在着紧密联系.早在1994年,Rick Kazman和Len Bass就肯定地说过,软件架构与实现非功能性需求之间存在密切联系.1这一想法在软件开发领域已经流行很多年,它也解释了为什么开发项目要在实现非功

软件测试-----功能性需求(Functional requirement)+非功能性需求(Non-functional requirement)

显式功能性需求(Functional requirement)的含义从字面上就可以很好地理解,指的是软件本身需要实现的具体功能, 比如“正常用户使用正确的用户名和密码可以成功登录”.“非注册用户无法登录”等,这都是属于典型的显式功能性需求描述. 非功能性需求主要涉及安全性.性能以及兼 容性三大方面. 在上面所有的测试用例设计中,我们完全没有考虑对非功能性需求的测试,但这些往往是决定软件质量的关键因 素. 安全测试用例: 性能测试用例: 兼容性测试用例: 原文地址:https://www.cnbl

[转]《一线架构师实践指南》—— 读后总结

原文:<一线架构师实践指南>—— 读后总结 之前总觉得架构是一件很高大上的工作,跟普通的编码设计不太一样.前一段实践,自己也尝试做过架构的工作,可惜经验不足导致架构非常混乱.这里读完这本书,大体上对架构的工作有所了解,也稍微摸清了些门道. 我理解的架构 我理解的架构就是基于某些需求,设计代码的基础框架.既然是基于需求,那么肯定要面临不少需求的扩展以及变更,这时就需要架构能够灵活方便的适应变化.因此,架构的工作我的理解更多的是提前预料到未来的变化,提前做好改变的准备. 架构设计的大体思路为: 时

App架构师成长路线

点击关注 异步图书,置顶公众号 每天与你分享 IT好书 技术干货 职场知识 参与文末话题讨论,每日赠送异步图书 --异步小编 架构师,软件技术领域一个高大上的名词,业界有言"人人都是产品经理",却很少听到"人人都是架构师".其本身涉及的复杂庞大的跨领域知识体系除外,对于架构一词,其实很难去完整地定义,我们也没必要过于纠结,就如我们为什么要登山,因为山在那里,执着前行,或许还未曾知晓路在何方,抑或你都不曾思考要去何方,但至少你已经在路上,while(!(succeed

每周荐书:我的世界、架构师、OpenStack(评论送书)

上周的荐书活动大家如此踊跃热情,看得出来在座各位都是爱书之人. 既然大家这么捧场,小编决定赠书数量翻倍,从这周开始每本书选出2位中奖用户. 先来公布一下上期中奖用户! Doem <Spring MVC实战> 工匠若水 <Python大战机器学习:数据科学家的第一个小目标> bit_kaki <Android移动性能实战> 中奖通知由CSDN官方发布站内消息,请关注消息通知~ 活动规则: 在文末评论里回复你对本周推荐图书的看法,或想要获得某本书的书名及理由 下期荐书更新时

转:每个架构师都应该研究下康威定律

今天的分享主要来自我之前的工作经验以及平时的学习总结和思考.我之前的背景主要是做框架.系统和平台架构,之前工作过的公司 eBay.携程.唯品会都是平台型互联网公司,所以今天主要带着平台架构视角和大家分享心得体会.架构的视角每个人都不一样,可以说一万种眼光,有业务架构.安全架构.平台架构.数据架构,各不相同,这里仅是我的一家之言,欢迎大家加入『聊聊架构』社群参与讨论.今天聊的话题主要包括以下几点: 我对架构定义的理解 架构的迭代和演化性 构建闭环反馈架构(Architecting for clos