談需求和設計

在這裏再談下需求和設計的邊界問題，咱們最終的業務系統實現出現的誤差，到底是需求的問題仍是設計的問題？若是邊界不清楚則很難明確的區分。對於需求自己有原始需求，用戶需求，產品需求和系統需求的各類階段；而對於需求的過程也自己存在原始需求的收集，需求分析，需求挖掘，和需求相關的業務建模。而對於設計一樣存在整體的企業架構設計，到單個應用的整體設計和架構設計，概要設計和詳細設計。 需求的重點是描述清楚現實世界，而設計的重點則是將現實世界的需求轉換爲抽象的模型。這是咱們說的需求和設計的大邊界，可是需求裏面也不是簡單的需求定義和挖掘的問題，還涉及到業務建模，業務建模和架構整體能夠說是銜接需求和設計的重要內容。 在面向對象的需求分析方法中，用例建模涉及到的內容包括了業務流程，業務活動和操做，異常和邊界，業務規則，業務對象模型，模塊和接口等各個方面的內容，也是咱們常採用的系統需求定義和編寫的方法。即需求重點仍是定義清楚問題，而不是管具體的實現方式。在對用例建模的方法基礎上，每每再加入了界面原型和通用的UI/UE規範約束等各方面的內容，以進一步的細化需求。即咱們將需求更進一步，從最初的需求用例增長了界面原型建模，到基於界面原型的界面操做和業務交互操做建模。 對於傳統的需求和設計邊界，每每即只作到系統用例層面，而讓設計和實現有更多的發揮空間。在這種場景下最容易發生的問題就是在出現誤差的時候很難真正去界定到底是需求的問題還設計的問題。在定義需求的時候，咱們強調每個需求條目自己的完整性和可驗證性，可是這自己並不表明需求自己的粒度就合適，若是說一個需求最終去追蹤設計的時候，發現大量的1對多的映射關係，那麼能夠講需求自己的粒度和細化程度出了大問題，對於這種粗粒度的需求最終業務系統實現爲何樣子咱們也很難把控。 需求自己也是漸進明細和迭代的過程，爲了進一步界定需求和設計的關係，能夠講任何不設計到設計層面建模的內容的都歸入到需求範圍，設計建模包括了數據庫設計，核心的類設計和對象模塊，模塊間交互和接口設計，具體一個業務功能的更詳細類交互設計等。這些很明細是抽象層面的內容，那麼除掉這些內容均可以做爲是需求須要去考慮的內容。一個界面上的佈局，控件的選擇和交互，操做的易用性所有歸入到需求範圍，這些的定義不涉及到具體的實現層面的類和代碼邏輯，也是一種合理的方式。需求能夠漸進明細並逐步精化，可是要意識到需求必需要管到這個層面，作需求的人時刻要考慮到按你需求作完的東西真正是客戶想要的東西，需求分析和開發人員必需要對最終的交付負責，而設計開發人員則更多的是爲需求的實現負責而已。 需求和設計能夠有邊界，可是更加劇要的是需求和設計之間的銜接問題，任何只懂業務或只懂技術的人每每都很難真正作好這塊的內容，而這塊內容每每正是傳統的系統分析員的核心價值。