Including the user's goals is absolutely important in creating a persona document, however I would be wary of including lower level, software requirements style information in documents.
Real users are rarely looking for enumerated lists of features like:
- 32 bit OS support
- Windows or Mac
- 500 ms response time
etc. Instead, personas are made to help you step back and consider the users and what they're doing, not just how the big wigs/requirements document/etc have laid out what the product needs.
Now, Personas, user goals and scenarios aren't a substitute for technical requirements either. Sometimes just because users don't care about (or often more accurately, don't know that they care about) certain things doesn't mean they're not important. An example from Personas: Moving Beyond Role-Based Requirements Engineering:
Scenarios are good at describing and analyzing
functional behavior of the system. However, there are
better ways to describe the nonfunctional or quality of
service (QoS) requirements.
One form of these QoS
requirements center on security. Other QoS
requirements focus as constraints on scenarios such as
performance, load, and stress requirements.
Application security has been a recent focus.
Seventy-five percent of system security breaches have
occurred at the application level...
Some stuff like security you need separate requirements from your personas; the fact that you need AES 256 security doesn't fit with a persona, even if it's important to protecting all personas. I strongly suggest you give Personas: Moving Beyond Role-Based Requirements Engineering a read. It's got lots more good information on using Personas to help build requirements.