由於Customer needs是由使用者/獲取者所提出，為了避免不必要的麻煩，或者讓一般的使用者(絕大多數都沒有技術背景)再去學習新的表示方法，statement of needs/operational concept documents要讓不論是使用者代表或者使用者群中的一員，都可以看得懂，故應該要避免使用USE CASE diagrams/Activity diagrams/ sequence diagrams等，而是用使用者所可以看得懂的圖(例如，概念圖、方塊圖、流程圖、時線圖等)，再加上文字描述。statement of needs /operational concept documents不見得一定是要有技術背景的人才能提。因為，這份文件純粹就是問題的提出及問題的解決方案，而解決方案中，也不必然要涉及技術，儘可能把技術相關都當成黑箱。因為這些與技術相關的東西，未來可能是硬體的，也有可能是軟體的，也有可能會化為人工作業流程，如果一下子就寫死，就有可能會造成技術過時、成本過高、或過於繁瑣等狀況。所以，技術的部分，就留給架構設計、軟體需求分析、初步設計階段再去探討吧。

OCD要像是一本描述系統的故事書(系統是如何打敗企業惡魔的)--從為什麼要有一個系統，系統會經過什麼歷程，在什麼環境或條件下，用什麼方法或能力打敗這些惡魔。就是說故事，不要太技術。要讓一般的使用者都可以看得懂，這樣子才能夠集思廣益地審查這份文件。

另外，不是個人挑剔，大家可以再想想，translate 與 Design又有何不同。在概念階段裡，為何用translate，而不用design？在概念階段後，接著是系統的架構設計(architecture design)階段。

在系統建置案RFP當中，應當提供的資訊應該還要包括：計畫的WBS(PWBS幾乎都漏掉)、工作條款(SOW)(常常寫不清楚)、營運構想文件(OCD)。系統工程作法裡，合理的工作流程是statement of need -> OCD -> PWBS -> SOW -> RFP。當然每個一文件(資訊)產出活動可以是迭代的。常聽到有獲取者叫廠商提SOW來參考，最主要的就是不知道如何提需要、營運構想與情境，所以WBS出不來，當然不就不知道怎麼提SOW了。

----------------
引文: