例：假設我是乙個學術聯合會的講師。參加我的課程的人在你的課程之後還將參加其它的課程，但他們不知道下一節課的上課地點。我的責任之一，就是確保每個人都知道到**去上下一節課。
分析之前，我們先以結構化的程式設計方法來嘗試解決問題：
1． 獲取課堂上人的名單
2． 對於名單上的每個人：
a)查詢他的下一節課程。
b)查詢下一節課的地點。
c)查詢去的路徑。
d)告訴他怎樣去上下一節課
這是理想的執行步驟，沒有任何問題。但是大家想想，我們真的會按照上面的流程去做嗎？
可能實際中，我們應該會採用這種方法：把從我講課的教室到其他教室的路徑張貼出來，然後告訴上我課的所有人：「我把其它的課程和相應教室的位址張貼在教室後面了。大家按照這份表去你們的下乙個教室。」。這樣就完事了。
那我們來看看這兩種方法有什麼不同呢？
第一種方法——對每個人都需要去明確的指出路徑。你會瘋掉！
第二種方法——你給了乙個告示，並期望每個人都能自己知道如何完成你的告示。
兩者最大的區別就是責任的轉移。在第一種方案中，我對所有事情負責;第二種方案中，學生對他們自己的行為負責。兩者用於實現同樣的目的，但組織方式有巨大的差異。
這樣做有什麼效果？我們來看新需求出現時會發生什麼。
這樣子做有什麼效果呢？我們來看當有新需求出現時會發生什麼？也就是需求發生變化時。
假設我們被告知：需要給畢業後助教的學生特殊的指令。也許他們需要在到下乙個教室之前先收集課程評價並把課程評價交到辦公室。在第一種方案中，我必須修改控制程式來區分畢業和未畢業的學生，然後給畢業的學生特殊的指令。很可能我必須對程式做相當多的修改。
這是控制程式中重大的區別。第一種放啊，每當出現一種新需求時，控制程式都必須修改。
第二種方案：新型別的學生也必須對自己的行為負責。
三處改變早就了這樣的效果：
每個人對自己負責，而不再有控制程式對他們負責。
控制程式可以與不同型別的人對話。
控制程式不需要知道學生在教室之間的任何步驟。
這裡引進一些專門的uml術語：
軟體開發過程中的三個不同的視角：
概念：展現問題領域中的概念
規格：只看軟體的介面，不要看具體的實現
實現：也就是實體的**
從這三個角度，我們再看看上面的那個例子：
我也就是講師是在概念層上跟學生做交流。換句話說，我告訴學生「希望他做什麼」，而不是「怎樣做」。但是，他們各有有各自的課和，走到下個教室的路徑也是不同的，可以自由選擇，這就是實現層的事情了。
在乙個概念層上通訊，而在別乙個實現層上執行。其結果就是我不需要知道具體發生了什麼，只要在「概念上」發生了什麼。
關於需求文件落地 團隊默契 責任問題的討論
最近在專案中連續遇到兩個相同的問題，原來以為口頭已經說明的任務在驗收時卻出現了比較大的偏差。問題一 乙個模組需要新增兩個功能，但是新增功能對原有功能有影響，即交付時除新增功能外還需對原有功能進行修改以符合整個流程，結果交付時只做了新增功能，原來的功能沒有修改，導致整個流程沒法走通。分析 這個需求經過...
關於序列變化問題的總結
類似於把原序列改成目標序列的問題 感覺這種思維題目 有必要總結一下qwq 而且總結一下思考問題的方式是有必要的 發現這些問題是有一定的通解的 下面的問題 感興趣的可以找到出處 這裡我只討論思考問題的方式 首先 是一道思考題 我們知道 目標序列就是 a,a 1,a 2,a 3,a n 2,a n 2 ...
需求分析 關於報表統計類的需求分析
關於需求分析，業界上一直說的比較多的是軟體需求分析，但是工作以來，做bi相關的工作一段時間，發現bi更多的需求會是報表需求分析 當然，其實報表需求可以是乙個很大的專案也可以是一些小專案，大專案與小專案其實需求分析過程都差不多，只是相對來講，小專案可能會更簡單一些 下面就這段時間對報表的需求分析一些總...