Below I attempt to answer your questions about needed requirements types and essential requirements by means of data flow diagrams.
Note: In the below, I am only referring to behavioral requirements, also called function or process requirements. I am not referring to performance requirements, data requirements, or timing requirements.
Data flow diagrams are used to capture manual and/or automated system required behavior. Lets say that we are performing an enterprise analysis (the whole enterprise is considered as one big system) by creating a larger set of data flow diagrams. The topmost diagram will be a context diagram in which the diagram’s single process/function will be labeled with the highest level behavioral requirement – the highest level goal or object – of the enterprise. There is no higher level required behavior of the enterprise than this.
Now let’s say that we decompose the set of DFD’s many layers down. Within these layers, every requirement, whether that requirement is a higher level abstraction of lower level requirements or is a bottom-most level detailed requirement, and whether that requirement is implemented manually or is implemented by software will be captured by us in modeling the whole enterprise.
Guess what! We have created an all encompassing requirements document without having to break the requirements out into categories of business requirements, stakeholder requirements, and solution requirements. What do you call this single category of behavioral requirements. Answer: Anything you want, just don’t muck things up by falsely partitioning the requirements into unnecessary additional categories
If additional categories are not needed, i.e, if the all the requirements can be captured using a single type of requirements, then any additional categories only unnecessarily complicate things. And unnecessary complexity is real quick way to kill a business analysis project.
To necessarily complicate matters a little, while we only need one category of behavioral requirement (whatever we choose to call it), that category can consist of essential requirements and non-essential requirements.
What is an essential requirement? Example: Lets say we have a business whose sole required behavior (sole goal) is to calculate the sales tax on beer sold in Texas (trying to keep it real simple here). Now let’s say that to make such calculation, a compute has requirements to r roles out the circular polarization, adjusts a servo modulator, and hemulates azel indicators.
In this example, the only essential behavior (i.e., unchanging business requirement) is to calculate the sales tax on the beer. The behavioral requirements of the computer will change as time passes and computer technology enhancements develop. That is the computer’s current behavioral requirements are non essential for the long term success of the business. The essential business behavioral requirements can be re-implemented by newer technology.
The finalized set of DFD’s will be heavily slanted towards essential requirements.