Requirements, I pondered, weak and weary...

I went. I saw. I learned. I am here to recount my experience.

Firstly, if you follow use case best practices, then you are way ahead of the game in understanding how RAVEN works. We do so at Decade Software, but instructor Steve Yeo told us that this rare among the software shops he visits.

The user-interface is modeled after Microsoft Outlook, so there was only a small learning curve. We covered the basics of the application in under two hours.

The other six were discussing those best practices.

The rules for writing Use Cases are simple:

• Write concisely—no extraneous words.
• Write in Active Voice—not passive voice.
• No assumptions—assume your reader knows nothing that you are explaining.
• Be consistent—if the system shows once, it shouldn't display later.
• Flows describe Functional Requirements Only—Preconditions, Post-conditions, and Business Rules are documented outside of the flows.
• Document all alternate flows—If this then that, otherwise that.
• Use Requirements English—Actor Function Object Target ("User enters Login Credentials in the Password Dialog.")

RavenFlow's sales folk get a little cryptic discussing pricing structure, but once you cut through that—and verify that you can live with the best practices defined above—I assure you that RAVEN can help your organization deliver requirements faster with little rework and greatly improve transparency.

But...

As Steve said...

"We can only give you the tools to get the job done. Solid processes start at the top and only work with complete buy-in from the team."

Now, where have I heard that before?