二章將屬於較輕鬆的內容，整個過程也會主要以文字描述為主。
　　最常見的功能定義為按使用操作來定義，如下面的例子是最普通的：
　　1）使用者將雨刮開關打至高速檔，雨刮以高速速率刮刷
　　2）在電源檔位為OFF時，使用者將轉向燈開關打到左邊，左側的位置燈亮起
　　3）使用者踩下剎車踏板，制動燈亮起
　　從上述的例子來看，只描述了使用者操作方式，卻未提到系統訊號互動和效能要求，如當用戶將雨刮打到高速檔時，是一個什麼樣的開關訊號輸入到哪裡，哪個件控制電機的哪個電源腳，這些也需以技術語言的方式進行描述。不過對於一些體系相關的要求，如TS的要求、CMMI的要求，它們均是要求需求中有類似的使用者case的描述的，否則就是一個不合符標準的需求。當然，更完整的需求應該不僅只是上面的一句話，它需包含前提、操作、反應三方面。將1）細化如下。
　　a）前提：電源檔位為ACC或ON，當前雨刮處於低速刮刷狀態
　　b）操作：使用者將雨刮開關打至高速檔
　　c）響應：雨刮轉至高速檔刮刷
　　表面上看上述定義貌似清楚了，實則仍不行。因為在前提中“當前雨刮處於低速刮刷狀態”是否“手動開關低速、自動雨刮低速、間歇功能低速、洗滌連帶刮低速”均包含呢？還是隻一種或兩種？這些均未說清，同時，如果當前有某些故障呢？或者該功能是否和電壓有關，如電壓大於16V了還要動作嗎？小於9V了還要動作嗎？這些情況均是實際中會出現的，如果真正需用於開發，肯定需要說明清晰；而如果只是應對一些體系稽核，則稽核的人不會細究其中很多的技術細節，他們僅僅只會看有沒有類似的描述。
　　第二種定義方式為按功能類別，如：本車型的近光燈包含了2種光形模式，即C型近光模式和V級近光模式...這種定義為按類別的定義。
　　第三種定義方式為按輸入訊號的區間分別定義，其更接近技術語言，如以下示例。
　　1）當感測器輸入訊號在0~0.7V之間時，代表感測器尚未被初始化、踏板位置尚未安裝好。
　　2）當感測器電壓在0.7~4.5V時，表明踏板已經安裝好並在正常工作區間；此時若已經完成初始化則按第#節要求操作。
　　3）當感測器電壓在4.5～5V之間，說明踏板安裝過高，此時應記錄##DTC。

　　而對於研發來說，光有以上這些定義是並非足夠，本章節的後續部分將分別做出大體介紹。