We know that the business stakeholders whose needs we elicit and capture as requirements are our customers. We know that the sponsor who foots the bill for our work is our customer. Often, product end-users are considered customers. We don’t typically think of designers, developers and QA analysts – our delivery team counterparts – as customers, but maybe we should.
Read More
Adam Feldman, blogging from Bright Green Projects’ “Bright Ideas” blog poses a fun and interesting question. Twitter limits entries to 140 characters. Should we do the same for requirements?
Read MoreAs I was scanning through some of my old documents, I found that I wasn’t that thrilled with a lot of my older work. Ever had that happen to you?
Read MoreI recently posted about the need for accuracy and precision in requirements. In that post, I mentioned that natural language requirements are probably the least precise format for expressing requirements. Many BA’s, myself included, write specs composed of natural language requirements and a few flow diagrams for clarification and context. So, given that natural language is not inherently precise, how do we at least make them as precise as possible?
Read More
What can business analysts learn about quality from McDonald’s?
Read More