specification

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 a business analyst (or any person interested in writing software requirements and quality), there is one thing you should always ask yourself whenever you write a business requirement:

Is this software requirement testable?

I've seen some business analysts write some crazy things and call them requirements, but IMHO, if you can't test it, it's not a requirement.

(And quality software requirements helps lead to quality software applications.)

The checklist provided below isn't ready for prime time, but I wanted to make sure I put a copy of this information somewhere. Basically, I have started to create a checklist of detailed items I need for user interface screens when creating a detailed design specification. So, what I've started to do is list all possible user interface field types, and what features of each interface element that can vary.

Frankly I'm not sure if this is a good idea or not, but if you're into heavyweight processes, this information is certainly needed by someone at some point.