Yes, I think your concept of feature is the same as my task concept. Applications that provide functionality without a clear linkage to a context (which in my eyes, in the corporate world would be often the case), are not process aware.
I see many leaders slowly starting to say: between corporate goal and results are many things, but process is one of them, and one of the vital ones.

Now going back to requirements: If you go from corporate goals directly to use cases, in my view, you skip a step. And skipping this, increases the risk of creating feature based solutions.
From corporate goals it is better to start with process: what processes are needed to reach these goals. “Be nr 1 on market XYZ with product ABC” – well, we will need to market, produce, sell, invoice and service our products. And our business model will be XYZ, taking position ABC in the value chain in our industry. From this process architecture, it is much simpler to start deriving use cases.
Process is not equal to use case. A use case is something that defines the requirements for a specific actor goal, using a certain solution (informal definition :-)). A process is more – more steps, more stakeholders, and possibly multiple automated solutions.
So when looking to a process, consisting of steps, collaborations, communications, decisions, etc, etc, for each of these, you might define one or more use cases. Now with much more context than before…

So…
corporate goals -> processes (& products & information) -> use cases…

Feedback most welcome!

Roeland – I might agree, not sure – I need more caffeine, and some clarification. How are you defining tasks?

I ask, because your “task-based is bad” position sounds a lot like my “feature-based is bad” position, but for slightly different reasons.

Feature-based is bad because it lacks context. You are unlikely to create a decent experience (usability), diluting the effectiveness of the feature. Further, without context, you are unlikely to optimize how you invest in development – will you invest in the most valuable features, or the ones that are easiest (or riskiest) to implement?

If you’re defining tasks at a granular level where they are conceptually no different than features, then I agree. However, I always think about defining things in terms of use cases that achieve (or support) corporate goals. This level of chunking / abstraction keeps things tangible, and provides clarity of context. It also gives us the opportunity to clearly associate a capability (the ability to sell a product, the ability to optimize pricing, etc) with the goal(s) it supports.

Would love additional insights if you’re still here and following the thread. Thanks in advance, and thanks in arrears for the previous comment!

Regards,
Roeland

A cow is a steak holder of sorts. Couldn’t resist. Also thought about a vampire picture – would that have been worse?