You, the Business Analyst, have been there many times:
You walk into a Project Launch meeting. The PM claims the catbird seat at the head of the table. Seated nearby and never looking up, a scribe clacks away on an ultra-thin notebook.
You take a chair near the middle of the long table and reach around for a few handshakes as you drop a yellow tablet to claim your place.
Half of the people you meet represent the business. They seem just delighted to begin this work. The application built by your I.T. colleagues will free them from the awful legacy system now constraining their lives.
You have already met the rest of the people. They represent Project Management (catbird seat), App Architecture (across from you), I.T. Security (lurking at a corner seat), and the Developers (arms folded, already frowning at the time line posted on the white board).
As Business Analyst you literally and figuratively sit between these stakeholders, your constituents.. or maybe you call them your clients.
The Business side thinks you are there to capture requirements; to get it right. They hang a lot on you, and they are always correct. The I.T. side thinks you are there to dig out contractually-sound specifications that never waver, never cause a re-write and never expand scope. They, too, hang a lot on you, less than the PM who only wants you to churn out a hefty, never-to-be-read document for signatures within the three allotted weeks.
So, Business Analyst, where do you begin?
Begin at the Logical beginning. Gather the nouns that you hear and begin to create a Logical Data Model (LDM). In the Launch Meeting, jot down the "who's", the "what's", the "where's" and the "when's" as shared by the Business. Listen to your I.T. colleagues as well. Never miss a noun.
Those verbs are important as well. Tuck away the "how's" and parts of the "what's" for your functional requirements list. Record the why's as potential business rules. You will need those functional requirements and business rules later.
Start with the data requirements. Draw up a model based on your noun list. Be sure to include data elements from every sample report you can gather. Parse the report and column headings: those are your nouns; more data elements for your model.
What do you call it?
You might want to call it a Conceptual Data Model or CDM until you are certain of a few things:
1) The Business agrees that those data elements are accurate and complete. You must hold a few model reviews before you reach this point.
2) You have researched and recorded metadata for all of those data elements. That means you have the definitions, the data types, the default values, the valid values, and the NULLs/NOT NULLs... at a minimum.
3) The relationships... the solid and dotted lines, the crows feet and that turtle-looking thing below "DAILY FLASH" are all understood and verified by the Business.
Now you can call it a Logical Data Model or LDM. Keep it away from the DBA, who now wants to convert it to a Physical Data Model and then forward-engineer it so the Developers can have a "working, prototype" database. If you let that happen too soon, you will pay a toll for every necessary change throughout the development cycle... which will exceed its timeline... and you will own a measure of accountability.
You are not ready for that forward-engineered database. Remember, this is the logical beginning.
