發現功能需求的的目的，是要形成構建的產品的一份合約，因此，功能性需求必須十分詳細的描述預期的產品將執行哪些活動。為了滿足這個指標，功能性需求必須包含足夠的細節，讓開發能夠構造出正確的產品，使需求分析師與利益相關方的誤解減少到最低程度。

為了使需求更規範、清晰、有條理，就需要考慮發現和組織需求的方法。我們可以這樣來考慮：

• 首先：把每個用例看成一個大的需求集，描述清楚這些需求集之間的互動關係，這就自然的使需求與用例之間有了對映關係。
• 其次：把視野集中在每個用例。一個用例表現了為實現一個大的目標所必需的行為，而每一個大目標需要若干小目標來實現，這個小目標就是事務。在用例點規模估計中，我們已經定義了事物就是從使用者到系統，再回到使用者的一個“環形路線”，我們可以把每個用例所包含的若干事務分離出來並進行命名。這就有了一個清晰的需求框架。
• 最後：再把視野集中到每個事務，仔細分析為了完成這個小目標（事務），系統需要哪些功能？這些功能有哪些模糊不確定的地方？能不能據此定義開發？

這種從功能集到事務再到功能的層層分解方式，不但減少了需求定義的難度，而且是最後形成需求文件和用例文件之間有很好的追蹤關係，下圖展示了這種漸進式得到功能性需求的方法。



我們用已經討論過的“預訂房間”作為案例，討論如何在場景中發現事務並細化功能的。



據此可以發現功能需求如下：



在完成了每個場景的功能提取之後，需要整體審視一下已經形成的功能表，看看哪些功能是重複的可以共享的，並把它們提取出來。雖然在編寫用例場景的時候，已經利用用例的包含關係做了一些這方面的工作，但是基於下面一些原因可能是不充分或者不正確的：

• 最初掌握的資訊不足，不足以發現更多的共享功能；
• 場景可能是由不同的人編寫的，限於範圍，不足以發現更大範圍內的共享。

在掌握更多資訊的情況下，我們會發現原來用例場景的不足，從而修正用例的場景，使他們趨於完善。我們用上一章討論過的賓館管理作為例子，最初編寫場景的時候針對顧客和櫃檯服務員的應用場景，是由不同的人編寫的，所做出的用例可能是下面的樣子。



在針對每個場景提取功能需求之後，在統一審視的情況下，人們發現在每個用例中都存在“查詢房間詳情”的功能集。於是把它們提取出來，反過來修正原來的用例，如下圖所示。



我們不可能一下子掌握所有情況，對情況的掌握是在過程中逐步完成的，這種後一步驟對前一步驟的修正稱之為反饋。在軟體工程中，有效的利用反饋過程的原理，可以大幅度提升每個過程的質量。

例如，前面我們在明確了客戶需求之後，根據新掌握的資訊，可能會修正原來確定的範圍（總比到了最後範圍蠕變強）；在功能提取之後，可能會修正原來確定的場景；在進入設計階段，根據掌握的更多設計資訊，可能會修正最初確定的需求；在每個階段整合測試並評審之後，我們可能會根據已經獲得的新情況，修正已有設計，甚至提出需求變更要求。

遇到這些情況不要奇怪，這正是符合人們認識事物的螺旋上升法則，與其避開這種螺旋性，還不如承認它，並利用它幫助我們提升質量。不要怕修改，精雕細刻與粗製濫造根本性的區別，就是一個是反覆修改的，一個是做出來就算了。那麼這會不會影響效率呢？從一個節點看是會的。但是從整體上看，前期付出的努力會在後期獲得豐厚的回報，並且會大大提升整體的效率。這種精益求精的文化，無論對於企業還是個人，都是良好的正向推動力。