名詞解釋篇
不知道有沒有人和我一樣，就是在遇到一些專業的名詞的時候，都如臨大敵。如“業務”、“願景”、“目標”、“需求”、“需要”、“業務需求”、“軟件需求”、“核心域”，每次看到軟件工程相關的書，就會開始很頭疼，軟件工程的書，很多都是程序員出身的專業人員寫的。我想着，是否程序員都很有創造力的，所以他們也會在軟件這個領域創造自己的詞彙。另外一個方面，可能也是因爲很多原始的講軟件工程的書，都是外國人寫的，所以外文翻譯過來，可能就會讓人需要花更多時間去思考。
《軟件方法》這本書真的很好，把軟件需求的理論都寫的大道至簡，但是我看書的時候，最頭疼的依然是專業名詞。所以在看書的過程，也琢磨了一點時間裏面的名詞，然後整理了。現在翻看早前寫的讀書筆記，覺得現在已經都不需要去看對照理解，也基本知道是個什麼東西了，不過也不想浪費了這個整理。
所以想着也分享出來，如果你也在看這本書，關於名詞的解釋，可以看看有沒有需要用到。
名詞1“業務”：
例如，我是一個軟件產品的產品經理，那麼我涉及的業務就是軟件業務。我是一箇中餐的廚師，那麼我涉及到的業務就是廚房業務。有個公司是賣塑料的，那這個公司經營的就是塑料業務。
軟件產品的存在，最終都是爲了人類的某項專業，某項事務而服務的。所以在軟件運行的大環境中，軟件服務到的專業的事務，我們稱之爲業務。
例如醫院使用的醫療系統，就是爲醫療業務而服務的。學校使用的教務系統，就是爲教學業務服務的，電商公司使用的電商系統，就是爲電子商務（網上的商業交易，網上的買賣）而服務的。這裏的業務，如醫療業務，教學業務，電商業務，都只涉及軟件系統要服務的對象。它們大部分，在沒有軟件時代就已經存在了，如醫療業務，教學業務等。也有少部分，是隨着軟件的誕生而新興的。
所以，我們講業務不一定需要軟件，提供特定服務的軟件則一定是因爲某業務的需求，纔出現，用於提供服務的。
名詞2“核心域”：
有一些書，會把業務，叫做“核心域”，我們就看到“核心域”，把它當成業務範圍就可以了。更精確地說，就是“軟件要核心服務的領域”，稱之爲“核心域”。
名詞3“願景”：
願景的字面意思，就是願望場景的描繪。例如有一本書的名字，就叫做《沙灘上的鋼琴》，作者希望有一天能實現的夢想，就是在沙灘上彈奏鋼琴，將遠期追求的夢想或理想，圖像化，作爲最高的目標去追求。它具有結果性，是一切奮鬥，一切努力的本質原因。
名詞4“目標”：
願景也是目標，但是目標不一定是願景。願景有兩個特性，一個是圖像化，具體化。目標不一定圖像化，不一定具體，它也有可能是階段性的，可大可小。例如，小f說，我希望3年之內能結婚，這是一個目標，但是它不描述願望場景。而如果小f說，我希望在3年之後第一天的清晨，能穿着婚紗，在海灘上，吹着海風，舉行結婚儀式。那它就是一個目標，也是一個願景。
當我們很難區分哪個是哪個，其實，就把它們都當成目標，再判斷一下是否有畫面感。
當然，在軟件的願景，以及軟件的目標的提出，除了是個目的，還要求可量化，這是區別於其他目標定製的一個更細節的地方。
名詞5“需求”vs“需要”：
看到需求和需要，你會不會和我一樣一直傻傻分不清楚，然後看到其他人都懂的時候，就會想，他們是怎麼知道的，那種好奇的想法。
痛苦的點還在於，你在不同的地方還要加以區分，避免人家說你不專業，真是頭疼，爲了一兩個詞，也需要琢磨琢磨。
這兩個詞，可以用一個場景的描繪來加以區分。想象你有一天心血來潮去一座非常高的高山爬山，在下山的路上，你的肚子純天然的咕咕咕地叫，飢餓圍繞着你，你是走一步，你的肚子就在告訴你，我餓了，我餓了，我需要被餵飽。
你就看着沿途，是不是有小驛站之類的，好不容易看到了一個賣豆腐花的，那個心裏嘩啦啦的被它的存在，感動的“痛哭涕零”，終於不用餓肚子了喲。你買了一碗豆腐花，匆匆下肚，你的肚子終於纔沒那麼飢餓。
這個場景裏，肚子餓了是人的本能，填飽肚子就是人的需要。而需求，是在你可選擇的範圍內，“求”得滿足你需要的服務，還可以講“爲了滿足需要，而希望求得的東西”。在這個案例中，需求就是喫一碗豆腐花。
那在這裏又有另外一個問題了，需要、需求和目標的關係是什麼呢？我們講目標是有層次的，那麼需要是一個高層次的目標，更加抽象化，而需求則是較之比較低的層次，更加具體化。
這樣，就不用擔心什麼時候用目標，什麼時候用需要，什麼時候用需求，什麼時候用願景了。
例如，我餓了，我希望填報肚子（需要），我希望最後能吃不了兜着走，樂呵呵地回家去（願景），那爲了能達成需要，實現這樣的願景，我打算喫好幾碗豆腐花（需求）。
而這些，都是我的目標，只是目標是在什麼層次而已。
需要（Needs）：人類沒有得到某些滿足的狀態
需求（Demand）：人們有能力並且願意購買某種產品的願望
簡單地講，凡是能買賣的都是需求，不能買賣的都是需要
名詞6“業務需求”：
坊間流傳的“想要一匹更快的馬”，還是“想要能快速地從A點到B點”，可以歸屬到“交通業務”。
想要解決“快速地從A點到B點”是需要，需求則是想要“一匹更快的馬”，或想要“一輛車”。
結合起來描述就是：需求1：希望求得“一匹更快的馬”，以期“更快速地從A點到B點”
需求2：希望求得“一輛車”，以期“更快速地從A點到B點”。
那我們回到醫院的醫療業務。他們希望縮短“患者看病時間”，這是需要。
這個需要，可以通過服務流程效率改進達到，如增加配備門診，收費等相關係統的工作人員，這樣患者就可以分流服務。
也可以通過硬件設備輔助的手段達到，例如，原先的測血壓需要人工壓縮來測量，現在的機器設備，只要手伸進去，就可以自動壓縮，並很快出結果，這就也是縮短了患者停留的時間。
還可以通過信息化系統，讓信息的流程更爲高效等。下面的增配人員，增加輔助硬件設備，增加信息化系統，就都是業務上的需求。
由於業務大部分都比較複雜，所以業務需求的分解，很多都通過“流程”圖來體現，方便從時間線上來看各項事務，優化各項事務，以及優化各項事務的協作方式，這個“流程圖”，我們就稱爲業務流程圖。從而拆分出真正的業務需求，以期滿足業務需要。
當然由於業務需求是從業務需要引申出來的，所以一般地爲了能滿足前因後果的邏輯嚴謹性，所有人們講業務需求，或講業務需求梳理的時候，也會帶入“業務需要”，把需要和需求都一併講明白。
名詞7“軟件需求”和“系統用例”：
原始的業務流程圖的每個環節，都採用何人做何事的方式來描述。
但是當我們想在這個“何人做何事”的過程中，提煉出哪個人做事，是利用了軟件系統進行輔助的。換個角度講，業務上需要軟件提供什麼服務，才能實現業務的需求，對業務直接產生價值。
我們可以把上面講的業務流程圖，轉化成業務序列圖，就可以很好得觀察到“軟件需求”了。
簡單地舉例，我在寫報告的時候，使用word文檔編輯文字。那麼寫報告就是我“業務”上的事情，可以表達到業務流程圖中，而使用word文檔編輯文字，就是利用了“word”這個軟件系統輔助完成業務事務，可以在業務序列圖中體現出來。具體業務流程圖和業務序列圖要怎麼畫後面的章節會講。
軟件需求，就是一系列的講“...請求軟件提供...服務”的集合，就構成了軟件需求的集合。
而“系統用例”，就是這些“...請求軟件提供...服務”中的任意一個，通俗地理解，就是系統的用戶操作事務（事例）。
軟件需求在業務領域，是一個解決方案。
但是在軟件設計領域，就會內化成設計之前提出的問題，即“我要如何讓軟件擁有做...的能力”，這個時候系統用例規約，就悄悄出場了。
名詞8“系統用例規約”
系統用例描述“用戶使用系統操作什麼事務”，用例規約，描述“用戶如何使用系統操作事務”的規定和約束。
想要知道用戶如何操作，除了知道用戶會有哪些感知能力和操作行爲，如“視聽嗅味”，如“說”，如“寫”等之外。還需要知道系統是如何接收請求，以及提供反饋的。這樣，才能知道他們要怎麼互動，這個過程有點像人和人合作的過程，想要合作共贏，就要知彼解己，人和人的對話如此，人和“系統機器”的對話過程也跳不過這一步。
當知道人和系統怎麼互動了之後，就可以把“系統必須接收什麼輸入”，“系統必須處理什麼”，以及“系統必須反饋什麼結果”，這幾個重要的部分梳理出來。
當然，實際的交互還有很多繁瑣的神奇功能，例如系統接收輸入的時候，人在系統的操作，可能不只一次，可能會錄入多個表單，但是在用例規約，規定用戶使用系統，只要能把用戶不得不做的核心交互，也就是沒有這些核心交互，就完不成“用戶使用系統操作事務”這件事情就可以了。剩下的靈活多變的細節交互，可以留到用戶體驗設計。
上面講的人和系統的交互過程，我們也可以稱爲“系統使用場景”，剛好匹配新興互聯網產品設計的應用場景。除了交互過程，我們還需要在這裏把一些用戶操作事務的要求體現出來，例如，做一個輔助人口採集的軟件，那麼在採集人口的事務中，就必須規定人口要採集哪些信息，如果是涉及到一個城市的人口採集，要求完成的時間又很緊迫，那麼採集的效率就有要求了，就要根據當時的時間，和能採集的羣裏，進行折算，算到每人每天要採集多少，再進一步折算系統的採集表單就要設計的夠簡單好用，系統的數據提交就要足夠快，這些，就又成爲了對系統的質量上的要求。另外，軟件系統自己本身也有限制，如只能在Android手機上使用。
總的來講，用例規約，描述“用戶如何使用系統操作事務”。它除了描述使用的過程交互之外，還對於使用過程的內容，操作等做了各種各樣的要求和限制。目的都是能支撐其完成“提供...服務”的使命。
名詞9“業務工人”
業務流程裏，“何人做何事”的何人，就是業務工人
名詞10“業務實體”：
業務序列圖，“提供...服務”的系統，就是業務實體，可以把它理解成業務“機器人”，是另一類業務工人（業務實體的理解）
名詞11“系統執行者”
系統用例中，“用戶使用系統操作什麼事務”，這裏的用戶，就是系統執行者，當然，用戶不一定是真人，也可能是另一個“系統”機器，它具有主動發送請求的能力。
名詞非官方解釋參照表
提供一個詞彙理解非官方對照表，如果後面遇到了這些名詞，但是忘記了，可以回來翻閱
參考書籍：《軟件方法（上）》潘加宇