作為開發者，拿到乙個需求文件，怎麼看？
乙個字乙個字的看：）
其實開發者都是看了差不多，就開始寫**的。寫不下去的，回頭看文件，再來找問題，提需求的bug。當然這樣反饋週期其實就是太長了。
我這裡有乙個案例，就是之前兩個人對一段**疑問，乙個人說和這個10行就可以搞定，不需要那麼多，現在60行，乙個反對，說我這個60行是因為和需求直接對應的，這樣需求改了，我就直接對應的跟著改就好。我覺得兩個人都有道理，但是依然覺得**邏輯複雜，於是我看了需求，發現需求是錯的，僅僅是邏輯自洽的角度判定就是錯的。把需求從新整理完，再來看，**10行確實夠了。
這就說明，開發者看了需求，不等於真正理解了，如何算是理解?
我認為理解的過程就是分析的過程，分析的過程就是拆解重組的過程。意思就是說，需求哪乙個文件過來表面是文件，後面是需求的思維模型，只要需求有一定的規模和複雜度，你要弄明白，怎麼辦，就是分治。就得把它的乙個個拆解，變成零件，需要用自己的模型把它重新組裝。
組裝的過程就是分析的過程，這個過程，你可能發現兩個零件重灌時發出了咔噠的聲音，這是對你的獎勵，好像告訴你，是的，你理解對了，也可能怎麼也契合不了，然後，你會發出乙個疑問，需求應對你的疑問，可能是我的本意是你得換個方向，或者其實你誤會了，它兩個不是要轉配一起的。當然也有可能需求說，我這個得放考慮的不對，是乙個bug，我重新弄。當幾次反饋下來後，你每乙個零件都可以發出咔噠聲，那麼你就知道，我理解透徹了。否則，就不太明白，就還得反覆。這時候，你怎麼重灌呢，總不至於自己把需求從新抄一遍？我的做法就是換模型，乙個需求都是圖表文字，我就是用類模型。其實類模型有些專業，可以叫做概念模型，每乙個概念都是乙個零件，裝配時就是兩個概念的關係，關係包括使用，泛化，組合等，還有對映關係，就是幾對幾的關係。我看完文件，我會開始繪製概念圖，我把文字才分為概念，在用關係把它重組。這個過程就是乙個發現和建立的過程。引入術語，概念圖就是uml類圖，關係就是use ,inherited 等，對映技術1：n，1：1，n：1，n:n。這個分析過程，就是ooa（物件導向分析）
當我和同事討論此問題，說到此處是，我突然發現原來ooa在這裡啊。我之前一直都是ood，ooa是我一直用，卻沒有想到自己在用的。或者說，我知道在分析，卻不知道它這麼有用。
還有乙個案例。是乙個銷售系統，需求人員做了乙個ui圖，就是我們常常看到的這些圖。我覺得使用者看到的，基本都有了，是乙個合適的需求文件。但是我總覺得其**現的一些概念，叫做跟單、跟進、動態，，可能是一回事，我就把它的概念圖畫出來，然後反覆比對這些概念的場景。每乙個出現的概念，都可能對弈乙個類，所以不能不認真考察，反覆確認這些概念出現的場景後，我們最後確認，它們是乙個東西。分析完後，他認為確實概念圖拿來做分析是有用的。
當然還有乙個問題，就是拿著這個圖，和有開發背景的人談當然沒有問題，但是和沒有開發背景的需求談，怕就難了。這裡就有乙個根本問題，是為了自己弄懂，還是為了別人弄懂，如果是為了自己弄懂，那麼uml是自己的分析工具，而和需求溝通只是輔助，並且也不會涉及太細節的**層面的東西，甚至是方法和屬性的概念，而就是概念，概念關係，概念構成，那麼uml類圖立刻就換身為概念圖，這個並不需要什麼開發背景。
理解和分享這樣的抽象的思維過程，請有趣的。
需求分析的概念
需求分析的概念 前言 軟體開發的成功要素在於能夠充分了解需求，否則無論多麼好的系統設計或是多麼強的程式設計能力，都無法彌補因需求不夠明確對整體系統開發所造成的危害。需求分析是一連串的處理過程，處理的精神在於找出使用者的需求，經過萃煉，將需求 資料的 功能的以及行為的需求 模式化，最後產出乙份需求規格...
需求分析的概念
需求分析的概念 前言 軟體開發的成功要素在於能夠充分了解需求，否則無論多麼好的系統設計或是多麼強的程式設計能力，都無法彌補因需求不夠明確對整體系統開發所造成的危害。需求分析是一連串的處理過程，處理的精神在於找出使用者的需求，經過萃煉，將需求 資料的 功能的以及行為的需求 模式化，最後產出乙份需求規格...
需求分析 需求文件（需求分析結果）的作用
需求分析學習指導目錄 1 在需求方面達成一致 需求是一種反覆進行的過程，涉及到各種各樣具有不同背景和要求的使用者，需求文件必須有助於需求分析師與使用者之間的溝通，以及需求分析師與軟體設計師和測試工程師之間的溝通 2 為軟體設計提供基礎 需求文件必須為軟體設計人員提供精確的輸入，因為設計人員不是應用領...