requirements

I tend to forget that I've written a lot of articles and tutorials that are out of the content management system that I now use to run devdaily.com, and last night I stumbled across an article I wrote on software cost estimating that I happen to think is pretty good. So, to make that article easier to find, here's a link to my software cost estimating tutorial.

(As you'll see from the look and feel of those web pages, those pages are formatted very differently, but you'll still be on the devdaily.com website.)

When you're working as a business analyst, the words you write are what you get paid for. Just like the author of a book, when you write software requirements, you shouldn't be loose with the words you write.

While working on a recent project, I started thinking about software requirements again, and was reminded how vague a requirement can be, even when you think it's well written. What made me think about this today was running across this performance requirement I found in an a requirements specification:

Summary: A collection of UML Use Case examples (software requirements examples), based on a "real world" project.

I've been taking a little time lately to document a lot of what I know about UML Use Cases, and today I thought I'd take a few moments to link up to Use Cases I wrote for a client back in 2004. The client graciously allowed me to reprint these on this website, as long as I removed their name from all the documentation.

I took some time yesterday and reformatted my free example software requirements specification, whittling it down to 36 pages, from the original release, which was over 200 pages. As you might guess, the new pages are longer, and I've also reformatted the specification, both of which help to make it much easier to read.

As the Arizona Immigration Law continues to make big news here in the United States, I decided to read the United State Constitution for the first time in thirty years.

As someone who has written dozens of software requirement specifications, the first thing that jumps out at me is that the U.S. Constitution would have never been approved as a requirements specification on my projects. Terms like "people", "person", "tranquility", and "unreasonable" are so vague that from a software decision-making process, they are useless.

All I can imagine at the moment is going up to Mr. Washington and Mr. Jefferson, and saying:

"Excuse me gentlemen, I'm working on the security model for our web app, and I'm wondering if you can clarify a few terms for me?"