Most requirements artifacts, Vision documents, use cases, and so forth ”and indeed software development artifacts in general, including the code ”require documentation of some kind. Given that these documents divert time and attention from essential coding and testing activities, a reasonable question to ask with respect to each one is "Do we really need to write this document at all?"
You should answer "Yes" only if one or more of these four criteria apply.
Before including a specific artifact in your requirements method, your team should ask and answer the following two questions (and no, you needn't document the answers!).
With this perspective in hand, let's move on to defining a few requirements approaches that can be effective in particular project contexts. We know, of course, that projects are not all the same style and that even individual projects are not homogenous throughout. A single project might have a set of extremely critical requirements or critical subsystems interspersed with a larger number of noncritical requirements or subsystems. Each element would require a different set of methods to manage the incumbent risk. Therefore, a bit of mixing and matching will be required in almost any case, but we can still provide guidelines for choosing among a few key approaches.