软件需求要写到什么程度,和设计的界限究竟在哪里?

irischenxi 2014-08-14 09:52:14
软件需求要写到什么程度,在实际操作中,一直有这样的疑问。公司要求项目需求在规定时间点定下来,形成文档,那写到什么程度算是合格的需求文档,要留多少空间给设计人员,用户交互算需求还是设计,请高人指点。
...全文
1068 8 打赏 收藏 转发到动态 举报
写回复
用AI写文章
8 条回复
切换为时间正序
请发表友善的回复…
发表回复
  • 打赏
  • 举报
回复
貌似是做“收工测试的”但是他又根本没有把精 --> 貌似是做“手工测试的”但是他又根本没有把精 可以说,是非之人必定整天问别人是非问题。真正搞开发的人,则反而不需要问这些问题。
  • 打赏
  • 举报
回复
有些需求“分析”人员,根本没有开发经验,既没有行业开发经验、没有成熟的行业软件类库架构知识,也不会对交互界面进行设计开发,貌似是做“收工测试的”但是他又根本没有把精力放在产品的回归测试上,她只会不断跟用户和跟程序员纠缠需求方面的“是非”问题。 这种人搞软件需求,是最令人反感的。
  • 打赏
  • 举报
回复
软件需求以足够开始近期的开发计划为限制。 用户对软件的需求随时可能修改,一个产品的每一个迭代周期也不过是2、3个月的事情。因此你对软件文档不能八股地看待。
zhangmike 2014-08-24
  • 打赏
  • 举报
回复
从理论而言,用户交互 算需求。但有些公司的语境下,用户交互设计是常见的说法。 在实践上,早先是界面原型甚至成型有了之后,再开始编码。 随着程序员能力的提升,以及工具的支持,有些组织不再要求先有界面原型,把界面设计交给程序员。 但最近,由于对于界面UX越来越高的要求,有些组织专门安排了UX工程师。 这种情况下,用户交互一般是提前于编码。 比如,有知名公司将用户UX提前一个迭代进行。
  • 打赏
  • 举报
回复
说白一点,你有丰富的开发经验、敏捷地直观把握开发进度,再来看“需求分析需要写到什么程度”就很容易。 其实不是什么技术上的是非,技术上根本没有是非。全是人的作用。
  • 打赏
  • 举报
回复
知识很“八股”的一些软件工程学生,可能死记硬背30年前的“国标”而以为需求分析之后就应该进行“模块分解、详细设计”之类的东西了。 我们进行敏捷开发。因此需求分析进行了一点以后就是落实到“粗放的”工单设计上。每一个工单基本上都是可以比较公平的、程序员他们“自己容易客观公认”为半天或者一天以内保险可完成的内容。这样就是避免说空话。同时也避免把“设计”说的过细。 同时架构式肯定会对“工单的数量多少”有重大的引导作用。通过在每一个里程碑阶段都预先埋伏一些意想不到的任务规划,实际上首先完成了“将来需要反复复用几十遍上百遍”的东西(这些是一般程序所想不到、或者不愿意去想的)。 能够把握这个尺度,那么需求分析就很自由。需求分析就好像是外交事务,总是有着积极意义的引导产品的走向,同时也容许相当大程度地需求改变,而不是什么整天在那里去讨论“是非”问题。
  • 打赏
  • 举报
回复
軟件需求是最膚淺的文檔,所以你不應該太“八股”地要求它。要知道這個文檔應該隨時可能被用戶引導著修改! 軟件需求分析,其實就是羅列從用戶那裏收集來的原始資料,盡量從描述中去掉自己的誤解、添油加醋的部分,盡量將用戶描述整理爲“他們”自成一體的邏輯體系。 有些小作坊式的垃圾團隊,寫了幾十頁的“需求說明書”之後就進行簡單的“模塊分解”(其實是標題黨),然後分解給幾個程序員去“設計”什麽數據庫表增刪改查,接下來就讓程序員各自爲戰地去“開發了”。甚至說“我的程序員都是牛逼人啊,就好像戰爭年代的共産黨幹部給個橡皮圖章就能單獨出去拉隊伍”。實際上,這往往是一葉障目,反而是鼠目寸光。因爲這樣領導的心眼並不“大”,沒有多久就會狠快就反悔並且給手下的程序員們拆台。 真正好的領導應該是知道該把握哪些架構設計、進度控制的訣竅,絕不是進行傻瓜分解任務。所謂“軟件需求分析”給一個小作坊式的團隊使用,與給一個懂得“設計”的團隊使用,其“寫的程度”是不一樣的。前者就好像一個無頭蒼蠅的頭,後者就好像一個大廚的菜。 因此你能够进行一定的“设计”开发,才知道“需求分析该写到什么程度”的问题。不懂设计开发而只知道把任务分解给程序员的垃圾团队,永远都会忧虑“需求分析该写到什么程度”的问题。
青松2 2014-08-15
  • 打赏
  • 举报
回复
从客户、不懂技术的人的角度来写需求吧

1,265

社区成员

发帖
与我相关
我的任务
社区描述
软件工程/管理 管理版
社区管理员
  • 研发管理社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧