FirstOrderRequirements 
* those which deal with '''what''' the business wants from a solution
* are the primary input into the design process
SecondOrderRequirements
* those which deal with '''how''' the implemented solution should behave
* are input as the solution or prototype is formulated
----
Just as enterprise data has often been held to be more stable (less liable to change) than the applications that operate on it, so can first order requirements be held to more stable than the systems that meet them.  The relative stability of data compared to process suggested to the InformationEngineering methodologists that software applications should be anchored in and grow from a definition of the underlying data.  Likewise, the relative stability of first order requirements compared to their implementation suggests that systems should be anchored in and grow from an understanding of the underlying requirements.  In XP, requirements are embodied, apparently indiscriminately, in UserStories.  I suggest that the more enduring FirstOrderRequirements should be separated out and embodied in overarching EnterpriseScenarios.
----
CategoryRequirements CategoryAnalysis CategoryBusiness