The course is COMP8100 Requirements Elicitation and Analysis Techniques.
Note there's a lot more stakeholders than just the users and those who pay for it: those who are supposed to build it have to be involved in the requirements analysis too. Not much point stating requirements for something that can't be defined properly, or built within time and budget, or which can't be tested. Or which is so brittle that entirely foreseeable future requirements can't be met.
All you can do is state the aims, then enough detail about how those aims are to be met in a testable fashion that everyone can agree on is feasible and useful. Compromises usually have to be made, so there's a matter of prioritising the requirements too.
Rocket Science... yes, it is, sometimes.
2 comments:
I've seen this picture before and always get a chuckle. It's one of those "funny cuz it's true" things.
That last frame is pretty crucial, and not always well understood. I was once on a huge multi-year project that delivered a gorgeous web application vastly improving functionality and usability from an old green-screen application. It was hugely celebrated upon its launch only to be completely rejected upon rollout to the user base. What the user base needed was an upgrade to their old green screen application. They couldn't afford the migration and training costs to switch platforms. In terms of this cartoon we had every base covered except that final frame. And the result = expensive failure.
Every salescreature I train gets told: The first thing you ask is not "what do you want" nor "how much do you want to spend", but "what are you doing with it?" It is absolutely amazing how often customers have a complete disconnect between that question and the first two; they frequently ask for something they couldn't possibly use.
Post a Comment