第一章 01
作為《軟體需求分析教程》的開端,也就是第一章內容為我們介紹了軟體需求分析的一些例項，以及需求的定義。從閱讀的過程中我了解到，任何乙個軟體專案都存在他的需求，與此同時，往往決定專案成功與否的關鍵，也是專案最初階段需求分析的成功與否。
在軟體工程中，所有的風險承擔者（stakeholder）都感興趣的就是需求分析階段。這些風險承擔者包括客戶、使用者、業務或需求分析員（負責收集客戶需求並編寫文件，以及負責客戶與開發機構之間聯絡溝通的人）、開發人員、測試人員、使用者文件編寫者、專案管理者和客戶管理者。這部分工作若處理好了，能開發出很出色的產品，同時會使客戶感到滿意，開發者也倍感滿足、充實。若處理不好，則會導致誤解、挫折、障礙以及潛在質量和業務價值上的威脅。
在第一張的閱讀中，留給我最深的印象便是軟體需求的重要性，與此同時我還了解到了需求的不同層次，對需求的理解更加具體。需求的層次包括
三個不同的層次——業務需求、使用者需求和功能需求——也包括非功能需求。業務需求反映了組織機構或客戶對系統、產品高層次的目標要求，它們在專案檢視與範圍文件中予以說明。使用者需求文件描述了使用者使用產品必須要完成的任務，這在使用例項文件或方案指令碼說明中予以說明。功能需求定義了開發人員必須實現的軟體功能，使得使用者能完成他們的任務，從而滿足了業務需求。所謂特性是指邏輯上相關的功能需求的集合，給使用者提供處理能力並滿足業務需求。
也是從這次的閱讀中了解到，軟體需求的方面多樣，但總的來說，以我個人的理解來看軟體需求可以總結為，從不同的利益相關者的角度去考慮，方便自己實現目標，再將這些需求點做整合，也就有了整個專案的軟體需求。從需求層次那一張來看，就能看出來，軟體需求不單單是簡單的軟體要有什麼功能，我們作為開發者更多的需要站在使用者的角度出發，依照使用者的職業，生活特點做總結，最後做出真正讓使用者滿足的軟體。
閱讀筆記01
許多軟體問題都源於收集 記錄 協商和修改產品需求過程中的方式不當，包括資訊收集方式不正規，沒有明確提出想要的功能，假設是未經過溝通的錯誤假設，需求的定義不夠充分，以及未經仔細考慮進行需求變更等。在軟體開發中遇到的問題時，人們常常輕率地將其忽略。軟體專案中40 60 的缺陷都是由需求分析階段的過失所致...
閱讀筆記01
架構是有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計。為了對架構有更加深刻的理解和掌握如何進行架構，我閱讀了 架構之美 這本書。這本書是來介紹系統的設計方法的。首先對架構的基本概念進行了了解。在建築，寫作等各種行業都可以看到這個詞的出現.架構是系統設計的一部分，它突出了某些細節...
假期閱讀筆記01
在大三這個寒假我閱讀了 架構之美 這本書，對於架構我之前是有聽說的，但是並沒有很深刻的了解，通過這次對於 架構之美 的閱讀，我了解到架構對架構師，構建者和其他利益相關者有著重要的幫助。乙個合格的系統首先要具備架構的概念，架構是有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計。當今...