Software Quality Insights

Oct 23 2008   11:38PM GMT

What are your software requirements headaches?

Colin Smith Colin Smith Profile: Colin Smith


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. 🙂

1  Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • BeantownQualityGuy
    My software requirements headache are getting BA's to realize that quality start with good requirements. I've started a grass roots effort to get people in my organization to adopt the Volere Requirements Process. All of our BA's use different methods to gather their requirements and they don't always gather all the correct requirements. Many times I've brought up questions in meetings which relate to quality. Many times it's getting the BA to explain to me what a phrase like [B] "a reasonable amount of time" [/B] means.
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: