specification

The three things a Business Analyst should think about during meetings

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.

One thing a business analyst should ask about any requirement

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.

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.

Software requirements - a UI checklist

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.