需求
需求規格書是對滿足客戶需求時必須要完成的目標的提煉。
有時，在專案正式開始之前便已經開始著手需求規則書，用於選擇正確的方案和技術。這通常稱之為專案可行性研究。更為典型的是將一些需求湊在一起（可能在乙個文件中），然後在專案真正開始之後才真正著手於需求規格書。
功能需求
功能需求即終端使用者和利害攸關者要求產品所擁有的明顯的日常需求。專案以功能需求為中心，且必須為使用者提供這些功能。
典型的功能需求如「系統x必須有功能y」，是一種「斷言」。斷言明確了利害攸關者嚴重系統必須的行為。
沒有清晰的斷言需求，除了給你帶來令你思緒混亂的討論之外，更沒有任何好處。
對比一下下面兩個截然不同的功能需求：
• 該財務系統必須以附錄a的描述來生成詳細的客戶發票
• 為使用者生成發票很重要。發票應包含所有必要的相關資訊，以證明使用者對貨物的支付
第乙個功能需求的描述是一種斷言。表明了財務系統應以附錄a中的描述來生成詳細的客戶發票。同時，其描述可以更具體，為了成功開發財務系統，讀者不會對財務系統必須做的事情感到含糊。
第二個需求可以作為財會書籍的引言。儘管其陳述了發票的重要性，但沒有提及由誰或什麼來生成發票。那麼會開始糾結發票中到底有什麼內容。這樣的描述不應該在需求規格書中。
第二個「需求」看起來與問題相關，但是其實是有歧義的。相關的資訊是什麼意思？以證明使用者對貨物的支付是多餘的，否則發票是做什麼的？這樣的陳述，也許很準確，但是沒有對系統要做什麼有任何的貢獻。
這裡是一些「更好的」需求描述：
• 客戶賬戶記錄必須包含唯一個賬號、主要聯絡人、****，以及該客戶在過去銷售年中的銷售清單
• ****必須包括**號碼、位址、以及可選的電子郵件位址
• 對於每個****，需要支援最多5個**號碼
專案管理之需求管理
需求的變化問題 在軟體開發過程中如果只有一條真理的話，那一定是 需求的變化是永恆的，需求不可能是完備的。軟體開發的過程實際上是同變化做鬥爭的過程，需求的變更不一定是壞事，也有可能是好事，是商業機會，對市場敏感的人可以從需求的變化中發現市場機會。需求變化的原因很多，如 一開始沒有識別全，需要增加需求 ...
專案管理入門
當你預期的那一天，也許是害怕的那一天，終於來到了 從工程師的隊伍裡你被提拔到了軟體專案領導或者團隊領導的位置。這也許就是你選擇的職業道路，或許你不太情願，將就嘗試一下。無論在哪種情況下，你都可能缺少工程學科 人員管理以及領導能力的相關教育。這需要更多的領導能力和管理 它們不是一回事 而不能象dilb...
專案管理入門
專案管理入門 karl e.wiegers 著，mirnshi 譯 非程式設計師雜誌 第3期 當你預期的那一天，也許是害怕的那一天，終於來到了 從工程師的隊伍裡你被提拔到了軟體專案領導或者團隊領導的位置。這也許就是你選擇的職業道路，或許你不太情願，將就嘗試一下。無論在哪種情況下，你都可能缺少工程學科...