A Data dictionary defines the structure and relationship of key data elements present in your database or software. In general terms the data dictionary defines the database(s) for your solution. The term metadata is also used here , where metadata is data about your data.
As a business analyst or a team member on an IT project it is necessary for you to access this data dictionary.
For example say for a University Management System for some university Enrollment number can be of this format 2019005013. If you go through the data dictionary you will get to understand that
1)Digits for the enrollment number are 10, first four digits is the year of enrollment, next two digits are the branch, next three digits is the running number.
2)Here it may also be provided that, next 3 digits 001 corresponds to say Computer Science and Engineering branch , 002 corresponds to Electronics and telecommunication and so forth
3)The last 3 digits are the running enrollment number of the individual
So wherever for this database enrollment numbers will utilized in which ever tables in the database the same format will be utilized.
For reasons of interoperability and uniformity the some very key data elements of your database may follow the same definition across industry. So it is not unusual for multiple Insurance companies follow same format or pattern for a policy number in their insurance database systems. Sometimes this is mandated by the regulator at other times industry consortium's come up with a common data dictionary for all the companies. For example ACCORD is one such standard for data interchange and exchange in Insurance industry. Quoting Wikipedia : “ACORD, the Association for Cooperative Operations Research and Development, is a non-profit organization that provides the global insurance industry with data standards and implementation solutions. ACORD is widely known across the industry for the publication and maintenance of an extensive archive of standardized forms. ACORD has also developed a comprehensive library of electronic data standards with more than 1200 standardized transaction types to support exchange of insurance data between trading partners.”
So as a Business Analyst you are suggested to go through and internalize the data dictionary for your solution. If such a data dictionary is not available it is recommended such data dictionary may be prepared. Since finalization of structure and relationship of data elements is primarily the responsibility of data base designer the role of a Business Analyst is at best restricted to documenting the same. The Business Analyst should also be aware of any data dictionary related standards for his industry
Benefits of Preparing and Utilizing a Data dictionary
1)Consistent data definitions leading to uniformity and quick s/w development
2)Quick understanding of data elements and business logic.
How can I earn 25 LPA in software it industry. Currently I am into testing. What can I learn to earn 25 LPA in 1 year? ( Vijay Shekhar Shukla has originally answered this question on Quora.com)
If you are into Manual testing , their is low probability for you to reach this salary level. Even if you are being paid 25 LPA or more, retaining the position can be tricky. You can consider moving to BusinessAnalyst Business consultant positions. These positions have plenty of on-site opportunities. The Business analyst and business consultant roles have plenty of positions which offer this salary. Moreover a BA or a consultant becomes more valuable with experience. You can
MVP stands for Minimum Viable Product
MVP is a very important concept for Software Product Teams
MVP balances cost, risk and value
Differences between User Stories and Use Cases
1)User Stories are part of Agile Frame Work where as Use Cases are part of UML Methodology
2) User stories utilize Natural language or Written method to capture requirements i.e. user story is written in a language like English.
where as Use cases utilize the pictorial method to capture requirements ii.e. this a pictorial method to capture requirements
3) User Stories typically capture a granular requirement or one goal so user stories can even run into hundreds on large projects
where as Use Case Model Captures the overall requirements of the system of the subsystem in question. So even if we prepare use case models for subsystem’s only very few projects have say 20 plus use case models.
4) In a User story the focus is on User Roles, Goals and Benefits E.g.: As a savings bank account holder (Role)I would like to withdraw cash (goal) from ATM with flexibility without visiting a bank branch at any time of day (Benefit) where as In Use Cases the focus is on the on the Goal E.g. Withdraw cash
5) Vocabulary Used in User Stories are Role, Goal, Benefit etc where as Vocabulary Used Use Cases: Actor, Use Case, Relationships etc
6) User Stories are primarily Endorsed By: Agile Practitioners, Scrum Alliance where as Use Cases were primarily endorsed By : OMG , Object Management Group
7) User Stories are primarily used on projects following Agile viz Extreme Programming , SCRUM where as Use Cases are primarily utilized on RUP (Rational Unified Process) projects and traditional software development projects
Visit www.qbi.in for QBI Institute IT Business Analyst Training and Certification
Similarities between User Stories and Use Cases
1) User Stories are utilized to capture requirements, similarly Use Cases are as well utilized to capture requirements
2) User Stories are prepared by Business Analysts similarly Use Cases are prepared by Product Owners or Business Analysts
3) User stories are used by stakeholders like Clients, Requirement teams, Design, Development, Testing and Implementation Teams
similarly Use Cases are used by stakeholders like Clients, Requirement teams, Design, Development, Testing and Implementation Teams
4) User stories are written from the point of view of the end user of the software similarly Use Cases are written or identified from the point of view of end user
Written By: Vijay Shekhar Shukla, Business Analyst Coach and Trainer, 91-9810055734, firstname.lastname@example.org
Vijay Shekhar Shukla has been training IT Business Analysts since 2010. A business analyst and business consultant himself since 1997, he takes pride in his student success stores. Check the Student Feedback here : https://bit.ly/2PuFMRC
Business Analyst Training | Vijay Shekhar Shukla | Business Analysis Techniques
This video on Business Analyst Training captures three prominent Business Analysis Techniques, they are - SWOT, PESTEL or PESTLE and Six Thinking Hats Method by Edward D Bono. All these three techniques can be utilized for IT Business Analysis on Information Technology Projects www.qbi.in, 9810055734
Please find below a simple test on SCRUM Framework or SCRUM Methodology. Any one having 3 plus years of work experience in IT industry should score more than 80 % marks
JIRA is a popular project tracking and issue management software. We know JIRA issue categories are
(Note we can even create our own custom JIRA issues (then can be a standard issue or a Sub-task type) and include it in our project issue tracing scheme)
Here we understand various states of a JIRA issue and transition between the states. This exercise serves us two fold
It allows us to understand
Open : Once the issue is created, the state assigned to it is Open. From here it can transit to other states. An Open issue can remain open if it is not worked upon. The Open issue transits to Resolved state if it is Resolved or an Open issue can transit to In Progress State it takes a certain time to work upon the issue and Resolve it. Open issues can even be Closed by the issue handling team.
Resolved: An issue can be Resolved by the team or the person working on it. An issue in Resolved Issue can be closed automatically after a pre-defined time period . A Resolved issue can be Re-opened as well.
In-Progress: When the team starts working on an Open issue it transits to the In-Progress state. If the work stops on this issue without Resolving or Closing it the state transits to Open again. In Progress issue after being taken up can be Closed or can be categorised as Resolved
ReOpened: A Re-Opened issue in JIRA can be put to Resolved, In-Progress or Closed states.
Closed: Issues in JIRA can be Closed or can transit to the Closed state from being Open or In-Progress or Resolved or Re-Opened States. A Closed Issue can be Re-Opened again in JIRA.
Now to prepare a state machine diagram the challenge is to define a permanent state , because only Permanent states connect to final Pseudo states. So say we define an additional state for the the sake of UML correctness. Let it be Closed – Time-Barred. Say an issue which is in the Closed state for specified time duration transits to Closed-Time-barred state and can not be Re-Opened.
The following will be the State-Machine diagram for this transition between the states.