Requirements - need for new approach

Been doing some consultancy for a client, around the processes dealing with requirements. Yep, that's process management as well - making sure your innovation processes are able to capture requirements and initiate and guide change effectively and efficiently.

My client is struggling with two things:
- A large application, which misses a lot of baseline documentation (what else is new...), and no clear approach how to capture requirements for changes
- An unclear link between strategy/business drivers, business processes and the IT functionality to support the processes

Let's start with the first one - requirements methods for maintenance situations
It's amazing to see how little one can find on requirements management and engineering for existing applications. Sure, tons of stuff for "green-field, let's create a new application, with a great set of requirements". But honestly, how many times does that happen?
Right.
(One article I found was a good start, and I recommend it - www.processimpact.com/articles/reqs_not_green.pdf )

What is needed is a better, common way, of dealing with the requirements around an existing system. And how to define changes - so that business knows that it asked the correct things, designers/developers know what to build, testers know what to test (next to regression testing), and change management knows what to prepare the business with.
Something a bit light and agile (you know how many requirements an average system contains....many!) And.. With a clear process and clear artifacts.

For now, we came up with:
- Identify required change source, stakeholders and business drivers/strategy
- Understand requirements of change, in terms of changed/added/deleted
=> business requirements (e.g. what does the business want to reach)
=> process requirements
=> functional requirements (global and in the form of use cases or a functional decomposition)
=> non-functional requirements
=> information model
=> business rules
- Determine impact and possible solutions. Perform trade-off analysis
- Decide on scope and plan the change.
- Perform usual IT activities (refine, design, implement, test, etc)

Insights welcome!

And now the second one - the missing link between business intent, process, requirements and IT.
Most requirements methods are still focused on what I call "features". A business analyst will talk to users, understand processes and data, and will come up with a solution, expressed in a list of "the system should .... feature X". So, in the end we understand what functions it needs to do, maybe even understand the tasks they relate to, but we lost the link with process and with business drivers/intent.

What I hope, is that requirements methods will evolve, and will start linking to new developments in thinking around business architecture and process architecture.
In the end, we mainly build IT systems to support actors within businesses to perform tasks, that are executed in the context of processes!

So, what I would like is to see the convergence of:
- Business architecture concepts:
- What business intent/strategy do we want to implement?
=> Principles
=> Execution Objects (could be people, IT)
=> Data Objects
- Process architecture
=> What processes are needed to execute and deliver the strategic results?
- Requirements
=> Linked to process steps: this step, we want to automate, and it will require XYZ....
Hm, you might even call it: BPM driven requirements methods!

Again, comments welcome. I am puzzled by the naivitity of current requirements methods.