I have used user stories - or at least something similar - to help me identify user requirements, but have never used them as the means of documenting requirements. I am somewhat familiar with the concept, though, and have been interested in learning more.

I found a great deal of help in Mike Cohn’s article, Advantages of User Stories for Requirements. In this article, Cohn explains user stories and the advantages of using them over traditional, natural language requirements and use cases.

Welcome! This site specializes in providing tips and tools for Business Analysts and systems development in general. If you’re new here, you may want to subscribe to my RSS feed. If you’d prefer, you can also receive my posts directly to your e-mail. Thanks for visiting!Recently, I’ve been fortunate enough to participate in some very interesting training sessions relating to business process re-engineering, and UML modeling. Now, I have long understood the value of use cases, but have never fully leveraged them or taken advantage of some of the added …

This quick post is just to share an article I came across that I thought might be beneficial, especially to the relatively new analyst. “Specifying Good Requirements“, by Donald Firesmith, includes some good, basic information about requirement quality assurance.
Basically, the article consists of a list of common requirement quality attributes (you know.. complete, correct, unambiguous, etc.) accompanied by questions that can be used as a checklist to ensure that your requirements meet the criteria of each attribute.
Firestone points out,
[J]ust as we all had to learn the rules for writing grammatically …

As I was scanning some requirements-related blog posts a few days ago, I came across a solid post by Prashant Hegde on the topic of Use Case best practices.
He provides quite a laundry list, and I recommend that you give him a read for the rest, but I’ll include a few points that I particularly liked below:

I’ve been thinking for a while about writing on how best to go about selecting a vendor for an out-of-the-box, or at least partial vendor solution. Sometimes it just makes better sense to go with a tried and true vendor package that performs specialized functionality that your shop doesn’t have the time or expertise to custom code.
As it turns out, Joy over at Requirements Defined has just done a masterful job of just that. The Requirements Defined blog over at Seilevel.com is one of my favorite reads. The topics …

You’ve poured your heart and soul into drafting the perfect requirements specification. You’ve checked, doubled checked, and triple checked every syllable of the document for clarity, spelling, testability. You have full traceability to every business requirement. You’ve been extra, extra careful not to tread in the domain of design. Your spec is rock solid.

So, why, after 5 review sessions with project stakeholders and document consumers, are you still making edits?

If you’re new to use case modelling, or just need a refresher, here is an excellent resource; the UML Use Case Diagrams: Tips and FAQ.