business analyst

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.

UML Use Case quality: Questions to ask yourself when writing a Use Case alvin March 1, 2019 - 6:47am
Table of Contents1 - Major points of my "User Logs In" Use Case2 - The "User Logs In" user story3 - Are my statements testable?4 - What I left out5 - User Stories, Use Cases, and Requirements6 - Back to the questions

I was just updating my Example UML Use Case diagram article and it occurred to me that if you're a Business Analyst, there are a couple of questions you can ask yourself as you write a Use Case (or User Story) that will help improve the quality of your writing. Two questions specifically come to mind:

  • What are the main points of this use case? (Which might also be phrased, "What points about this business process do I need to make sure everyone really agrees about?")
  • Are the statements I've written testable?

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.

How to know when a software requirements specification process is done

Summary: This short article describes a way to know when a software requirements specification is complete by using Function Point Analysis techniques.

I've written dozens — maybe hundreds — of software requirement specifications over the years, and at one point in my career I learned an important little secret about knowing when the process of gathering requirements for a software requirements specification was really complete. Here's my secret.

Business Analyst and Computer Programmer in Alaska (Anchorage, Wasilla, Palmer area)

This web page is the resumé for Alvin Alexander, the creator of this website. Mr. Alexander occasionally provides software consulting services to select clients, including business analyst and computer programming services. He currently resides in Wasilla, Alaska (and is preparing to move to Palmer, as of August, 2010). Both cities are just north of Anchorage, Alaska.