What are your software requirements headaches?

Understanding what your stakeholders want in an application can be challenging, to say the least. You need to know what questions to ask and get your stakeholders to explain their needs and wants. It requires not just eliciting requirements but also validating that what you’re ready to send to the developers is in fact what your stakeholders want. Communication with the stakeholders and with the developers is essential.

That’s just one headache business analysts often have. Others that I’ve heard people talk about:

• Transitioning from legacy requirements or documents (Word, Excel files) to use cases
• Transitioning from per-project requirements to per-system requirements
• Being asked to specify many of the user interface details as requirements (Too much UI detail in the requirements constrains the designers and takes away from the functional requirements)
• Managing requirements across the enterprise
• Managing requirements for reusable components (How to achieve effective reuse across the enterprise)

Additionally, more people are asking about how to manage and define software requirements in agile environments. How do you handle changing software requirements?

Do any of those issues cause headaches for you? Are there other things related to software requirements that create problems for you or you need more information about? Tell me about your pains — be as specific as you want.

Think of me as your doctor: Tell me where it hurts, and I’ll try to help you get rid of the pain. Only I won’t charge you for an office visit.