搜尋網上關於軟體需求,都講的長篇大論,是真的有這麼難嗎?如果軟體需求不講清楚,後面設計很多都做白工,所以要怎麼做才能夠一次講清楚呢 ?
就像你發了很多次問題,但其實只為了一個功能((我猜是某種自問自答
你會知道要呈現怎樣的效果、要運用在何處... 但我們不知道
當你發問 其他人給你解... 你會覺得不適用 基於回答再繼續發問... 一直循環直到得到要的效果
不見得是案主不清楚自己的需求
有時候對他們來說那已經是習以為常的動作 並不會太注意細節
((被問過怎麼連xxx都不知道... 靠夭我為什麼應該知道
但案主才是面對問題的人 如果他們自己都沒發現問題... 我們要怎麼幫他設想會出現的問題?
除非各行各業(或你接的案子)的SOP你都瞭若指掌 能夠人家起頭就設想好後路
雖說等你多接觸不同類型的案子之後... 案主一開口就會自動腦補出很~多問題
再厲害的引導也只是減少做白工的次數而已啦~
畢竟對我們來說是學習一個新領域的東西啊~
最近看到相關的敏捷溝通方法。我覺得還不錯可以分享。
就是寫出你的需求情境
每次寫需求都"一定"要寫這樣
我是一位 XXXX,我想要XXX達成什麼事情,所以 我需要XXX系統。
我是一位 XXXX,我想要XXX達成什麼事情,所以 我需要XXX功能。
我是一位 XXXX,我想要XXX達成什麼事情,所以 我需要XXX按鈕。
我是一位 XXXX,我想要XXX達成什麼事情,所以 我需要XXX按鈕是什麼顏色or有什麼反應?
不斷的去向下細分切分,這可以加快溝通效率,讓工程師知道你的目的,並且可以一起找到解法。
就可以慢慢的劃分你需要的範圍,並且將需求定義清楚。