Requirements, Business Needs, Value: all together

Traditional 

The so called "traditional" approach to materialize WHAT should be done (by a software system) it  is described by "requirements". It is specified also that requirements must be prioritized, but too often that failed because of lack of focus.

Unified Process 

A simplified extension it is provided by Unified Process that define a hierarchical pyramid-like model where Business Needs are in top of Requirements, and there is a trace between each business need and corresponding requirements.

Extended

An extended approach it is described by various sources related to software engineering (Unified Process included): the relationship between target business ans software system requirements are more detailed modeled: with flows (use cases) and data. The software systems use cases/flows are integrated in the overall business use cases/flows (and also the data/information).  

Agile

The most common additional concept associated with the requirements from the Agile viewpoint it is the value (provided to the business) encapsulated by a set of the requirements.

Comments

• Traditional: seems to be incomplete, because all others are adding valid extensions
• Extended - flows and data: it is a valid conceptual model about how the business and software system are integrated in details, but seems also to be incomplete on dimension that quantify priorities of the requirements (for other reason that detailed dependencies that are clearly defined here)
• Business Needs - could be very useful because specify "requirements of the requirements". Anyway, could not describe detailed relationship between business and requirements (as flows and data) but rather most important aspects and it is useful for strategic decisions related to the requirements.
• Value - it is somehow similar with the Business Needs, but add something more: we can address the business needs better of worse, that mean we could deliver more or less value for same business needs (example: by quality and supplementary non-functional requirements). It quantify that they customer will finally receive. 

An integrated approach 

All the above approaches are correct, but all are incomplete. Unfortunately, for the sake of promoting only one method or only one approach, there are advertised - "sold" -  only some of them. It is very common these days, when Agile it is very trendy, to talk about only about value and diminish the others. A coherent and professional software engineering approach should consider all of them and use them when and where it is appropriate.

Story

We have to define WHAT the software system must do for the target business. This "what" need a name and this name it is Requirements. Anyway, these requirements cannot be defined directly, we need to be aligned to some goals and use specific practices and concepts:

• Should be a traceability between target business objectives and the requirements: we can use here the Business Needs concept 
• We need to be more precise about what we shall deliver for business (related to this business needs), and how well are addressed. Here we can use the Value concept 
• The Value help us to fulfill another goal: prioritizing requirements according to what the target business evolution needs 
• Both Business Needs and Value provide instruments to strategically manage the requirements 
• For detailed relationship between business and requirements and their integration, we can use the flows & data model. We can ignore this aspect, but in reality business and system are interacting in a such manner and we need an explicit understanding about what it is really happening. If fact that it is what we will implement and we need to be aware of that.  How much detailed representation "on paper" it is necessary, that it is a another discussion  

Conclusion: there are more aspects and dimensions on the process of managing the requirements and could be very useful to use more concepts and practices (each having its role): Business Needs, Value, Requirements, Flows and Data.

Notes

• User stories are just particular form (less structured and minimalist) of flows & data approach
• "Features" concept it is less useful because it is too generic  ( such as "functionality")