軟體需求是一個很有趣的話題。

我們可以找到很多關於需求的書籍，也容易找到需求文件的模板，但是往往實際工作中，受制於種種因素，很難發揮到需求文件應有的作用。

軟體需求很難，包括以下兩方面原因。

絕大多數軟體在開發過程中，都會或多或少有需求的變更。這種變更有可能是一開始沒有考慮細緻，在慢慢開發中需求細化了的變更；也有可能一開始考慮不周，一段時間後覺得另外的做法才可行而完成的需求變更。

需求如何滿足不夠細化的需求，又如何做到變更的跟蹤呢？

軟體規模當然可以量化，但是對於大多數普通人來說，他可以看到廣州塔那麼高，但他看不多京東商城多麼複雜。

客戶的一句話，我們如何寫這個需求文件呢？

對需求的這些問題，我有三種方式的解決辦法。

這類軟體有一系列的工作流程，也有一系列的輸入輸出文件與之相匹配，需求文件只是其中一小塊，另外還有需求不清晰是用於合同簽訂附件的工作宣告文件、原型、概要設計，這些文件都與需求文件相輔相成。

這類專案不可能有時間和成本去慢慢梳理，往往“我有個想法”到“我要用上”可能就兩個月以內時間。這類開發我們需要淡化需求“文件”這個概念，從客戶根本的需要出發，引導客戶為什麼需求開發軟體，開發軟體用來解決什麼問題。進而給到客戶專業的解決方案，而不能單純地從客戶方獲取需求（畢竟客戶不是專業人員，而我們是）。從解決方案到簡單原型，再到核心業務流程梳理，一路推進到系統上線，都需要我們的專業建議。

這個過程中沒有常規理解中的“需求文件”產生。

這個實行敏捷，必須敏捷。