建築往往是根據設計圖來完成的，軟體也不例外，乙個專案的質量和設計規劃圖有著密不可分的關係。這之間的聯絡，簡單來說，便是使用者和工程師的溝通，使用者說出自己的需求來讓工程師去實現。而需求包括三個不同的層次——業務需求、使用者需求和功能需求，需求使問題變得明確，它是一一指明實現說明的規格說明，描述了系統的行為、特性或屬性，是在開發過程中的約束。
需求的質量高低對於程式設計師來說很重要，實行有效的需求工程管理的組織能火得多方面的好處，其中最大的好處是在開發後期和整個維護階段的重做的工作大大減少了。正確的需求過程強調產品開發中的通力合作，包括在整個專案過程中多方面風險承擔者的積極努力。
實施需求工程需要一定的方法，絕大多數的軟體開發人員都需要去進行需求分析，包括提煉、分析和審查以收集到的需求，以確保所有的風險承擔者都明白其含義並找出其中的錯誤、遺落和不足之處。然後將其編寫入軟體需求文件，並以正確的格式進行儲存。
個人感受：拿到乙個專案，直接去做是不會有好結果的（例如重寫），要好好分析軟體需求，過去的我只是追求功能的完善而忽視了需求的重要性，但我意識到軟體需求同樣重要。
軟體需求閱讀筆記01
軟體需求實際就是 業務知識 問題列表 其他元素 軟體需求的三層次 業務需求 使用者需求 軟體需求。需求也有著三種型別 功能需求 非功能需求 設計約束。不完整的需求 缺乏使用者參與 不切實際的使用者期望 需求變更頻繁 提供了不再需要的 敗因解決方案 1 不完整的需求 採用業務導向讓使用者參與到完整性評...
軟體需求閱讀筆記01
在資訊化高速發展的今天，構建與時俱進的資訊化系統已成為所有 企事業單位的重點課題之一。然而在軟體專案實施過程中，進度超期 經費超預算 變更頻繁的現象層出不窮，甚至有許多專案根本無法達到預期的目標，更談不上為業主創造真正的效益。歸根結底，軟體需求實踐這一共同的軟肋是問題的根源。隨著資訊化應用的逐漸深入...
《軟體需求》閱讀筆記01
開篇首先先介紹了乙個關於phil和 maria 的關於客戶姓名更改這個功能沒有實現而造成的問題，這個問題包括很多內容 資訊收集不正規 功能隱晦 對假設功能有理解上的分歧 需求制定不明確以及需求變更不正規等。關於使用者需求，文中肯定了 ian sommerville and peter sawyer ...