For years I have been preaching that problems in requirements manifest themselves in design and development and are exposed in testing. While, this is true and completely accurate, it can hardly be said that development problems of this nature are purely the responsibility of the Business Analyst.

So where does quality and the motivation to produce quality come from? Well first let’s look in basic terms, at how a person moves through their career.

Recently, I had the pleasure of meeting with EDev's CIO Asif Sharif. During the meeting, Asif gave me a detailed demonstration of their new requirements tool called InteGREAT. I have to admit, I was impressed.

I was impressed by the fact that it supports application of the CRRSP methodology in a way only one other tool has shown the aptitude for. I'd have to say that I have spent the last couple of weeks mulling over each of the tools and just what I liked about each of them. First, I'll have to share with you what I liked about InteGREAT.

In this post, I will talk about misuse cases and steps to identify security requirements. Ivar Jacobson while working on large telecommunication systems introduced use cases. According to him use cases describe system's desired behavior in the form of a story ('Scenario')from the point view of a user or interfacing system('Actor') and supported by subsidiary scenarios in the form of alternatives and exceptions[Jacabson 1992]. On the other hand misuse cases are the inverse of use cases. The concept was coined in 1990s by Guttorm Sindre of the Norwegian University of Science and Technology, and Andreas L. Opdahl of the University of Bergen, Norway.