This image is from an article titled, Why don’t people use formal methods? I like the parts about writing “precise, unambiguous specifications,” and some other parts.
When it comes to working as a business analyst, I’ve learned that there are just three things you need to keep in your mind when meeting with your customers (the project sponsor (gold owner) and domain experts (“goal donors”)) to gather requirements. These three thoughts will keep your meeting on track, lead you to the next question, and will help you know when your work is done.
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.
I started reading the early release of the book, User Story Mapping, by Jeff Patton, and it looks like it’s going to be really good.
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.
Dear Business Analyst: If you can’t count the Function Points, you’re about to enter a world of hurt
One of the great things about Function Point Analysis (FPA) is that it can be a terrific validator of the work you’re doing as a business analyst. For example, here’s one of the guidelines I came up with after I learned about FPA:
If you can’t count the Function Points when you’re about to start developing a software project, you’re about to enter a world of hurt.
I've written a lot of use case documents lately for software requirements specifications, and as use cases get more complex, I find the need for "sub use cases" or "alternate scenarios". When referring to these from the main use case (or anywhere else), it's nice to be able to use LaTeX's reference capability.
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.