常见非功能性需求的描述案例
发布于 2024-10-01
2902
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
非功能性需求的重要性与描述案例摘要
非功能性需求是系统需求的关键组成部分,它直接影响系统架构的设计并需要开发人员的重点关注。在工程实践中,客户往往忽略非功能性需求,而需求人员也面临如何准确描述这一挑战。尽管国际标准对此有所定义,但描述往往显得抽象。为了帮助需求人员,以下整理了一些实用的非功能性需求描述案例。
1. 性能需求描述案例:
- 响应时间要求:
- 大部分时段(95%情况)响应时间应在1.5秒以内,高峰时段不超过4秒。
- 定位系统从点击至界面显示不超过300毫秒。
- 拨号连接GPRS网络时间不超过5秒。
- 电子地图刷新不超过10秒。
- 在推荐配置环境下,各种登录、刷新和打开响应时间应在1-2秒内。
- 在非高峰期,特定搜索条件下应在3秒内返回结果。
- 业务量要求:
- 每日最大成交数为3000笔。
- 平均并发交易数为20,最大可达50。
- 预计用户数为1万,日登录用户约3000,网络带宽为100M。
- 系统需支持10,000个用户请求和25,000个并发用户浏览。
- 系统容量要求:
- 支持3万用户,GB级数据。
- 数据库表最多100万行,最大容量1000GB,磁盘空间需40G以上。
- 精度要求:
- 定位精度误差不超过80米。
- 编号和名称搜索的最长查询时间未提及。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 892.7K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
敏捷与规范的杂论
有几家客户在导入敏捷的方法,有些做的很好,很见实效,有些则仍在门外徘徊,形似而神非。究其原因,在于没有理解敏捷思想的精髓,存在对敏捷方法的误解。敏捷方法与规范方法都是为了按时、保质、在规定的时间内实现需求,殊途同归,目的相同,实现的方法不同。规范方法的管理假设是每个人都会犯错误,为了降低犯错的概率,事先定义了严格的过程,通过遵循规范的过程可以降低犯错的概率,如何确保按过程执行了呢?需要QA进行检查
软件项目宏观管理策略点睛
根据国际知名调查机构standish集团的统计,真正成功的项目仅有26%,而其他项目都可以算作失败项目。为什么这么多的项目都失败呢?问题出在哪里呢?依据笔者的经验,很多项目实际上是败在了初期,败在了启动时,败在了项目的宏观管理策略上。即,没有根据项目的特点采用合适的管理策略,即使后续的管理方法再细致也没有用了。我推荐如下八个感触颇深管理策略,供软件项目的管理者借鉴:
惊魂一刻
2008年5月10日星期六,惊魂的一天。 下午5点时我给司机电话,让他5点45分到莫泰168酒店接我,送我去宝安机场,我是7点40分的航班,通常情况从龙华到宝安机场40分钟足够了。他以为是要6点48分到酒店,害得我重复了至少3遍,他才听清楚,我当时就有点火,不知道他怎么听的,我口音没有那么严重啊。我是第一次坐他的车去机场。 5点50分他到了酒店,上了车,他并没有按常规的路线走,而是
原因分析必知必会的十大要点
原因分析是对选定的现象进行全面深入的研究,找到现象背后的真正原因与深层次原因,然后采取合适的措施纠正问题、预防问题。如果没有找到真正的根因就采取措施,往往事倍功半,浪费了投入。那么在原因分析时,有哪些成功要点呢?基于我多年的咨询与引导经验,我总结了如图1所示的十个要点。
拥抱ChatGPT,开启结对咨询模式!
ChatGPT刮起了一阵旋风,ChatGPT到底能做什么?做到什么程度?真的会让咨询顾问失业吗?
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线