Hi Analysts!
Let's choose a topic for the next publication
Let's choose a topic for the next publication
Anonymous Poll
40%
Data Flow Diagram
38%
Sequence diagram
34%
US vs UC
1%
Offer yours in the comments
Sooo and the winner is "Data flow diagram"!
Thank for your votes⭐️
Data Flow Diagram is a way of visualizing the flow of information within a system or process. It highlights the movement of information as well as the sequence of steps or events required to complete a work task. DFDs allow teams to better comprehend how a system works and make it easier for managers to identify and troubleshoot potential problems to improve effectiveness.
DFD could consist of the following components:
🔸Process is part of a system that transforms inputs to outputs. The symbol of a process is a circle, an oval, a rectangle or a rectangle with rounded corners (depending on the type of notation). The process is named in one word, a short sentence, or a phrase that is clearly to express its essence.
🔸Data flow shows the transfer of information from one part of the system to another. The symbol of the flow is the arrow. The flow should have a name that determines what information is being moved and should only transmit one type of information. The arrow shows the flow direction (it can also be bi-directional if the information to/from the entity is logically dependent - e.g. question and answer). Flows link processes, data storages and external entities.
🔸Data storage (or warehouse) is a piece of information to be used or processed at a later time. The symbol of the storage is two horizontal lines. The name of the data storage is a plural noun (e.g. orders) - it derives from the input and output streams of the warehouse. The flow from the data storage usually represents reading of the data stored in the data storage, and the flow to the data storage usually expresses data entry or updating.
🔸External entities (or terminators) communicate with the system and stand outside of the system. It can be, for example, various organizations (e.g. a bank), groups of people (e.g. customers), authorities (e.g. a tax office) or a department (e.g. a human-resources department) of the same organization, which does not belong to the model system.
👉Here are the main rules for creating DFD:
📎Name the entities in a comprehensive way, so that it does not need further comments.
📎Make sure that your diagram is consistent and complete, e.g. none of the elements stand separately.
📎Enumerate the processes. It would be easier to map and refer to them.
📎Make your DFD concise. The maximum number of processes in one DFD is recommended to be from 6 to 9, minimum is 3 processes in one DFD.
Thank for your votes⭐️
Data Flow Diagram is a way of visualizing the flow of information within a system or process. It highlights the movement of information as well as the sequence of steps or events required to complete a work task. DFDs allow teams to better comprehend how a system works and make it easier for managers to identify and troubleshoot potential problems to improve effectiveness.
DFD could consist of the following components:
🔸Process is part of a system that transforms inputs to outputs. The symbol of a process is a circle, an oval, a rectangle or a rectangle with rounded corners (depending on the type of notation). The process is named in one word, a short sentence, or a phrase that is clearly to express its essence.
🔸Data flow shows the transfer of information from one part of the system to another. The symbol of the flow is the arrow. The flow should have a name that determines what information is being moved and should only transmit one type of information. The arrow shows the flow direction (it can also be bi-directional if the information to/from the entity is logically dependent - e.g. question and answer). Flows link processes, data storages and external entities.
🔸Data storage (or warehouse) is a piece of information to be used or processed at a later time. The symbol of the storage is two horizontal lines. The name of the data storage is a plural noun (e.g. orders) - it derives from the input and output streams of the warehouse. The flow from the data storage usually represents reading of the data stored in the data storage, and the flow to the data storage usually expresses data entry or updating.
🔸External entities (or terminators) communicate with the system and stand outside of the system. It can be, for example, various organizations (e.g. a bank), groups of people (e.g. customers), authorities (e.g. a tax office) or a department (e.g. a human-resources department) of the same organization, which does not belong to the model system.
👉Here are the main rules for creating DFD:
📎Name the entities in a comprehensive way, so that it does not need further comments.
📎Make sure that your diagram is consistent and complete, e.g. none of the elements stand separately.
📎Enumerate the processes. It would be easier to map and refer to them.
📎Make your DFD concise. The maximum number of processes in one DFD is recommended to be from 6 to 9, minimum is 3 processes in one DFD.
👍5❤3
How to Excel in Your Career as a Business Analyst🤓
https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/6107/How-to-Excel-in-Your-Career-as-a-Business-Analyst.aspx
Can you add your own tips?⭐️
https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/6107/How-to-Excel-in-Your-Career-as-a-Business-Analyst.aspx
Can you add your own tips?⭐️
Modernanalyst
How to Excel in Your Career as a Business Analyst
Being successful as a business analyst is not a feat - reserved for a select few. Neither is it rocket science. It is achievable and within your grasp, if you apply a well-rounded approach to how you manage your career. While these tips are centered around…
👍2
The Business Analyst in the SDLC: the global source of product knowledge
The Business Analyst is one of the backbones of the SDLC. This professional is responsible for the result and should be as concerned as the owner of the product. Let's see what the Business Analyst does at each stage of the SDLC.
⭐️Stage 1. Pre-sale — establishing contact with the customer.
Pre-sale is an important stage in getting along with the customer. The Business Analyst explores what their IT company can offer to the customer: makes a list of the functionality of a future application, prepares a team estimation, and takes into account other important aspects. At this stage, the Business Analyst is needed to create the correct vision of the product, cover it in as much detail as possible, and perform functional decomposition, based on which developers will conduct estimation.
⭐️Stage 2. Requirements’ analysis.
The details of this stage are described above. The Business Analyst conducts a discovery phase, where a deep analysis of the requirements of the future functionality and accurate estimation are required.
⭐️Stage 3. Implementation.
At this stage, the Business Analyst provides programmers with elaborated, analyzed, and approved requirements during each sprint. This ensures that there will be no chaos during the project and the least number of bugs will penetrate into the product.
⭐️Stage 4. Testing.
Since QA specialists are guided by the product requirements, the Business Analyst’s participation in the testing stage is mandatory. If a QA engineer has any concerns, the Business Analyst will investigate the bug and determine whether it is a defect that needs to be “cured.” The Business Analyst will take control of the error and think of how to prevent it from emerging again.
⭐️ Stage 5. Release.
The Business Analyst monitors how consumers use the product. This expert gathers information and reviews, communicates with the support service, and analyzes what can be improved in the application. These desires are taken into account in the next sprint. Thus, the team creates a better version of the program that is more useful and valuable to consumers.
⭐️Stage 6. Maintenance.
Developers and other specialists will have many questions. The Business Analyst, participating in all stages of the project, is the global source of product knowledge. That’s why everyone can seek valuable advice from them.
The Business Analyst is one of the backbones of the SDLC. This professional is responsible for the result and should be as concerned as the owner of the product. Let's see what the Business Analyst does at each stage of the SDLC.
⭐️Stage 1. Pre-sale — establishing contact with the customer.
Pre-sale is an important stage in getting along with the customer. The Business Analyst explores what their IT company can offer to the customer: makes a list of the functionality of a future application, prepares a team estimation, and takes into account other important aspects. At this stage, the Business Analyst is needed to create the correct vision of the product, cover it in as much detail as possible, and perform functional decomposition, based on which developers will conduct estimation.
⭐️Stage 2. Requirements’ analysis.
The details of this stage are described above. The Business Analyst conducts a discovery phase, where a deep analysis of the requirements of the future functionality and accurate estimation are required.
⭐️Stage 3. Implementation.
At this stage, the Business Analyst provides programmers with elaborated, analyzed, and approved requirements during each sprint. This ensures that there will be no chaos during the project and the least number of bugs will penetrate into the product.
⭐️Stage 4. Testing.
Since QA specialists are guided by the product requirements, the Business Analyst’s participation in the testing stage is mandatory. If a QA engineer has any concerns, the Business Analyst will investigate the bug and determine whether it is a defect that needs to be “cured.” The Business Analyst will take control of the error and think of how to prevent it from emerging again.
⭐️ Stage 5. Release.
The Business Analyst monitors how consumers use the product. This expert gathers information and reviews, communicates with the support service, and analyzes what can be improved in the application. These desires are taken into account in the next sprint. Thus, the team creates a better version of the program that is more useful and valuable to consumers.
⭐️Stage 6. Maintenance.
Developers and other specialists will have many questions. The Business Analyst, participating in all stages of the project, is the global source of product knowledge. That’s why everyone can seek valuable advice from them.
👍7🔥4❤2
Let's start to discuss new topic "What product discovery techniques do Business Analysts use?"🤓
The first one is Design thinking. Design thinking is an old concept formulated in its current state in the 1990s by David Kelley and Tim Brown. It’s not only a philosophy but also a process that consists of five iterative steps.
🔶 Empathize
In this step, Business Analysts formulate assumptions about the pain points of the potential users:
✔️ What problems are they experiencing?
✔️ How do they currently solve them?
✔️ Are these problems really important?
✔️ Are people ready to pay for solutions?
The specialists shouldn’t convince the customer of anything; their goal is to understand the users.
🔶 Define
Organizing and analyzing data collected in the previous step helps the experts to articulate the main problems that the software will solve, the so-called problem statements, and create personas.
🔶 Ideate
This step refers to brainstorming as many ideas related to software features that will solve the problems as possible. None of the ideas are wrong at this stage, excluding those that are impossible to implement.
🔶 Prototype
The less time it takes to create prototypes of possible solutions, the better. These prototypes can take the form of sketches on a napkin or PowerPoint presentations. They should be minimalistic and just enough to make the potential users understand the idea of how the software is going to work.
🔶 Test
Asking potential users for their opinion about the prototypes can include the following questions:
✔️ Does the software solve the problem?
✔️ Is it convenient to use?
✔️ Is it priced properly?
The process of improving and testing the prototypes should be iterated until the solution can solve potential users' relevant problems in an appropriate and convenient manner.
#Discovery
The first one is Design thinking. Design thinking is an old concept formulated in its current state in the 1990s by David Kelley and Tim Brown. It’s not only a philosophy but also a process that consists of five iterative steps.
🔶 Empathize
In this step, Business Analysts formulate assumptions about the pain points of the potential users:
✔️ What problems are they experiencing?
✔️ How do they currently solve them?
✔️ Are these problems really important?
✔️ Are people ready to pay for solutions?
The specialists shouldn’t convince the customer of anything; their goal is to understand the users.
🔶 Define
Organizing and analyzing data collected in the previous step helps the experts to articulate the main problems that the software will solve, the so-called problem statements, and create personas.
🔶 Ideate
This step refers to brainstorming as many ideas related to software features that will solve the problems as possible. None of the ideas are wrong at this stage, excluding those that are impossible to implement.
🔶 Prototype
The less time it takes to create prototypes of possible solutions, the better. These prototypes can take the form of sketches on a napkin or PowerPoint presentations. They should be minimalistic and just enough to make the potential users understand the idea of how the software is going to work.
🔶 Test
Asking potential users for their opinion about the prototypes can include the following questions:
✔️ Does the software solve the problem?
✔️ Is it convenient to use?
✔️ Is it priced properly?
The process of improving and testing the prototypes should be iterated until the solution can solve potential users' relevant problems in an appropriate and convenient manner.
#Discovery
👍7
Let's continue topic "What product discovery techniques do Business Analysts use?"🤓
🔶Conducting interviews
When providing product development services, interviewing is essential to collect relevant and useful data about a project. An open conversation with potential customers makes them feel confident and provides the project team with more insights.
A good interview shouldn’t take more than twenty minutes and shouldn’t include overly intrusive questions. Interviewers are often tempted to ask about the respondent’s annual revenue and similar topics. However, there is little possibility that they will answer openly as this would involve proprietary information that the respondent might not be willing to disclose. Moreover, they can get irritated by such questions. Instead of inquiring about the prospective customer’s annual revenue, it’s appropriate to ask them about prices for their services and products.
Both using a standard questionnaire and asking clarifying questions are essential. When conducting product discovery, one needs insights and not statistics. Asking open-ended questions provides Business Analysts with the necessary information and helps the respondents to remain engaged during the interview.
🔶Brainstorming
The goal of brainstorming is to find non-standard and effective solutions to problems. During brainstorming, its participants propose the solutions that first come into their minds no matter how strange they might seem. The majority of the proposals are later discarded; however, discussing as many ideas as possible is essential to turn quantity into quality. The main idea behind this process is to articulate the best ideas by employing creativity and full freedom while generating them.
Brainstorming brings the following results:
✔️proposing original solutions to users’ problems;
✔️eliciting as many possible product features as possible so as not to miss anything important;
✔️revealing possible product limitations, for example, dictated by the company policy.
#Discovery
🔶Conducting interviews
When providing product development services, interviewing is essential to collect relevant and useful data about a project. An open conversation with potential customers makes them feel confident and provides the project team with more insights.
A good interview shouldn’t take more than twenty minutes and shouldn’t include overly intrusive questions. Interviewers are often tempted to ask about the respondent’s annual revenue and similar topics. However, there is little possibility that they will answer openly as this would involve proprietary information that the respondent might not be willing to disclose. Moreover, they can get irritated by such questions. Instead of inquiring about the prospective customer’s annual revenue, it’s appropriate to ask them about prices for their services and products.
Both using a standard questionnaire and asking clarifying questions are essential. When conducting product discovery, one needs insights and not statistics. Asking open-ended questions provides Business Analysts with the necessary information and helps the respondents to remain engaged during the interview.
🔶Brainstorming
The goal of brainstorming is to find non-standard and effective solutions to problems. During brainstorming, its participants propose the solutions that first come into their minds no matter how strange they might seem. The majority of the proposals are later discarded; however, discussing as many ideas as possible is essential to turn quantity into quality. The main idea behind this process is to articulate the best ideas by employing creativity and full freedom while generating them.
Brainstorming brings the following results:
✔️proposing original solutions to users’ problems;
✔️eliciting as many possible product features as possible so as not to miss anything important;
✔️revealing possible product limitations, for example, dictated by the company policy.
#Discovery
👍2
Let's continue topic "What product discovery techniques do Business Analysts use?"🤓
🔶Business modeling
Different projects require different business modeling techniques. For example, working on a business model for a startup usually involves using Lean Canvas.
When the product is a large corporate system, it requires establishing business processes.
🔶Functional decomposition
This may seem an easy task, however, many project teams experience difficulties with estimations due to incorrect approaches to creating a work breakdown structure. Specialists who perform decomposition should be skilled in business analysis as they need to understand how the product will work. Otherwise, tasks can be duplicated or unclear from the technical point of view, and therefore, hard to estimate. The lack of qualification in business analysis can lead to missing critical requirements which results in the underestimation of a project, sometimes by several times.
#Discovery
🔶Business modeling
Different projects require different business modeling techniques. For example, working on a business model for a startup usually involves using Lean Canvas.
When the product is a large corporate system, it requires establishing business processes.
🔶Functional decomposition
This may seem an easy task, however, many project teams experience difficulties with estimations due to incorrect approaches to creating a work breakdown structure. Specialists who perform decomposition should be skilled in business analysis as they need to understand how the product will work. Otherwise, tasks can be duplicated or unclear from the technical point of view, and therefore, hard to estimate. The lack of qualification in business analysis can lead to missing critical requirements which results in the underestimation of a project, sometimes by several times.
#Discovery
👍2
Hi Friends! Workshop. NOW
Andersen's workshop on effective personal planning techniques:
❓How to organize your life and daily tasks
❓How to bring order to your projects and workflows
Kiril Zabavski will answer these and many other questions
✔️ Senior Business Analyst at Andersen
✔️ A true expert in time management
📆 December 21, Online
⏰18.00 (GMT+1) DE / PL
⏰19.00 (GMT+2) UA
⏰20.00 (GMT+3) BY
⏰21.00 (GMT+4) GE
Language: English
Link here👇
https://youtu.be/LNTwogjI95E
🔥See you!
Andersen's workshop on effective personal planning techniques:
❓How to organize your life and daily tasks
❓How to bring order to your projects and workflows
Kiril Zabavski will answer these and many other questions
✔️ Senior Business Analyst at Andersen
✔️ A true expert in time management
📆 December 21, Online
⏰18.00 (GMT+1) DE / PL
⏰19.00 (GMT+2) UA
⏰20.00 (GMT+3) BY
⏰21.00 (GMT+4) GE
Language: English
Link here👇
https://youtu.be/LNTwogjI95E
🔥See you!
👍1
Andersen, an international IT company, invites an experienced Product Owner/Business Analyst to work for a large-scale e-commerce project. The customer is a leading international tobacco manufacturer headquartered in Switzerland.
📍You have:
▪️Experience as a Product Owner/Business Analyst for 5+ years;
▪️Proven experience in developing e-commerce platforms (e.g., Magento, Shopify);
▪️Hands on with Agile methodology;
▪️Strong leadership, coordination, negotiation, and presentation skills;
▪️English: B2+.
📌Nice to have:
International certificates (e.g. PSPO/PSM/PSU/PAL/SPS/ICP/IQBBA/IREB)
📍Reasons to join us:
▪️Salaries at Andersen are pegged to the EUR, and our employees are provided with a benefit package and an extensive set of bonuses;
▪️We give our employees an opportunity to attend and participate in the company’s BA meetups, as well as offer a compensation program for international professional certificates;
📎You can find out more about the vacancy here: https://people.andersenlab.com/ru/vacancy/business-analyst-and-product-owner/1679
✏️Feel free to contact:
Linkedin: https://www.linkedin.com/in/ekaterina-vinnikova/
Telegram: @Katerina_Vinnikova
Email: mailto:k.vinnikava@andersenlab.com
📍You have:
▪️Experience as a Product Owner/Business Analyst for 5+ years;
▪️Proven experience in developing e-commerce platforms (e.g., Magento, Shopify);
▪️Hands on with Agile methodology;
▪️Strong leadership, coordination, negotiation, and presentation skills;
▪️English: B2+.
📌Nice to have:
International certificates (e.g. PSPO/PSM/PSU/PAL/SPS/ICP/IQBBA/IREB)
📍Reasons to join us:
▪️Salaries at Andersen are pegged to the EUR, and our employees are provided with a benefit package and an extensive set of bonuses;
▪️We give our employees an opportunity to attend and participate in the company’s BA meetups, as well as offer a compensation program for international professional certificates;
📎You can find out more about the vacancy here: https://people.andersenlab.com/ru/vacancy/business-analyst-and-product-owner/1679
✏️Feel free to contact:
Linkedin: https://www.linkedin.com/in/ekaterina-vinnikova/
Telegram: @Katerina_Vinnikova
Email: mailto:k.vinnikava@andersenlab.com
Andersen, an international IT company, invites an experienced System Analyst to work for a large-scale project of our partners from the Netherlands.
📌You have:
▪️Experience as a Business/Systems Analyst for 3+ years;
▪️Excellent functional and technical skills in software development (Driven Design, UML Diagrams, Design Pattern);
▪️Strong knowledge of DevOps methodology and good knowledge of an Agile Project Management Tool (Azure DevOps, JIRA);
▪️Knowledge in AI/ML or possibility to learn new information in that field right away.
▪️English: B2+.
📌Nice to have:
International certificates (e.g. PSPO/PSM/PSU/PAL/SPS/ICP/IQBBA/IREB)
📌Reasons to join us:
▪️Salaries at Andersen are pegged to the EUR, and our employees are provided with a benefit package and an extensive set of bonuses;
▪️We give our employees an opportunity to attend and participate in the company’s BA meetups, as well as offer a compensation program for international professional certificates;
🖇You can find out more about the vacancy here: https://people.andersenlab.com/ru/vacancy/system-analyst/1676
✏️Feel free to contact:
Linkedin: https://www.linkedin.com/in/ekaterina-vinnikova/
Telegram: @Katerina_Vinnikova
Email: k.vinnikava@andersenlab.com
📌You have:
▪️Experience as a Business/Systems Analyst for 3+ years;
▪️Excellent functional and technical skills in software development (Driven Design, UML Diagrams, Design Pattern);
▪️Strong knowledge of DevOps methodology and good knowledge of an Agile Project Management Tool (Azure DevOps, JIRA);
▪️Knowledge in AI/ML or possibility to learn new information in that field right away.
▪️English: B2+.
📌Nice to have:
International certificates (e.g. PSPO/PSM/PSU/PAL/SPS/ICP/IQBBA/IREB)
📌Reasons to join us:
▪️Salaries at Andersen are pegged to the EUR, and our employees are provided with a benefit package and an extensive set of bonuses;
▪️We give our employees an opportunity to attend and participate in the company’s BA meetups, as well as offer a compensation program for international professional certificates;
🖇You can find out more about the vacancy here: https://people.andersenlab.com/ru/vacancy/system-analyst/1676
✏️Feel free to contact:
Linkedin: https://www.linkedin.com/in/ekaterina-vinnikova/
Telegram: @Katerina_Vinnikova
Email: k.vinnikava@andersenlab.com
👍1💩1
Hi professionals!😎
Long time no see, and great to publish a new post.
Here are a nice article "42 Reasons To Start a Business Analyst Career".
🌟Could you share you own experience in the comments below why do you choose this profession?
🌟Was it an easy decision?
🌟How long did it take you to reach this title?
https://www.bridging-the-gap.com/42-reasons-to-consider-starting-a-business-analyst-career/
Long time no see, and great to publish a new post.
Here are a nice article "42 Reasons To Start a Business Analyst Career".
🌟Could you share you own experience in the comments below why do you choose this profession?
🌟Was it an easy decision?
🌟How long did it take you to reach this title?
https://www.bridging-the-gap.com/42-reasons-to-consider-starting-a-business-analyst-career/
Bridging the Gap | We'll Help You Start Your Business Analyst Career
42 Reasons To Start a Business Analyst Career
Is pursuing a business analysis career worth it to you? Let's explore the reasons it could be the best decision you ever make.
👍3🔥1
Hi professionals!⭐️
How about to read article about ER-model: what it is and how to create it?
☝️Modeling, as a cognitive activity of the highest level, is considered to be the very tool that through simplification of all the relevant project elements makes stakeholders not only aware but also calm about the design of the product, as well as about the processes the project involves and the course of the project realization.
Among many different models that can help all the subjects agree about the product/project, an ER-model is the one that conceptualizes relations between the elements in a system. In simple BA language, an Entity-relationship model describes entities and the relationships between them using graphical notation. In what follows we are going to look up closer at what ER-models comprise and what is the most problematic issue while creating them.
🌟Once the purpose of ER-model is to describe the structure of a database in software engineering and business information systems so as to simplify the database design process, it is clear that one of the major problems with developing an ER-model arises when choosing a notation system. There are several notations and no single standard, which means that every BA is free to use any to their liking, with other stakeholders having a chance to not understand it. With this in mind, I recommend turning to Crow's Foot Notation which is one of the most commonly used notations when creating/designing ER diagrams (ERDs).
The major parts of ERDs are:
🔸Entities - a person, place or thing about which we want to collect and store multiple instances of data - is represented by a rectangle with a noun as the name of the entity (e.g. ‘Patient’, ‘Hospital’, ‘Doctor’).;
🔸Relationship - that connects the two entities involved in some relationship - is represented by a line;
🔸Attributes - the information about an entity which distinguishes the data we intend to store (e.g. doctorid, doctorname) and about the type of the data (e.g. string, integer, etc.) - are written inside an entity (inside a rectangle).
To describe different types of relationships that can take place in an ERD the notion of cardinality is of use. Cardinality is treated as the number of times an instance in one entity can relate to instances of another entity. Cardinality is depicted by the styling of a line that connects instances and its endpoint. The major types of cardinal relationships are:
🔸one to one - relationship means that one entity has only one event shared with another entity (for e.g. An appointment can have one and only one receipt);
🔸one to many - one of the related entities has an event that occurs one time, while the other entity can have more than one repetition of the event (for e.g. A hospital can have one or many doctors, while the doctor can have one and only one hospital);
🔸many to many - both entities have the same event or relationship happening more than once (for e.g. Many patients can have many appointments.).
Here is brief tutorial for ERD creation (in Crow's Foot Notation) with the help of such simple tools as Draw.io and Lucidchart:
👉Identify the key entities with particular names and label rectangles with these names. Don’t forget that they should be represented as nouns.
👉Think about the attributes of each entity and its data type.
👉Place attributes and their data type inside the rectangles with relevant entities.
👉Think about all relationships between the entities.
👉Choose and set an appropriate type of relationships between entities using lines.
Some of your entities may have only one relationship, some may have multiple relationships. That is okay.
How about to read article about ER-model: what it is and how to create it?
☝️Modeling, as a cognitive activity of the highest level, is considered to be the very tool that through simplification of all the relevant project elements makes stakeholders not only aware but also calm about the design of the product, as well as about the processes the project involves and the course of the project realization.
Among many different models that can help all the subjects agree about the product/project, an ER-model is the one that conceptualizes relations between the elements in a system. In simple BA language, an Entity-relationship model describes entities and the relationships between them using graphical notation. In what follows we are going to look up closer at what ER-models comprise and what is the most problematic issue while creating them.
🌟Once the purpose of ER-model is to describe the structure of a database in software engineering and business information systems so as to simplify the database design process, it is clear that one of the major problems with developing an ER-model arises when choosing a notation system. There are several notations and no single standard, which means that every BA is free to use any to their liking, with other stakeholders having a chance to not understand it. With this in mind, I recommend turning to Crow's Foot Notation which is one of the most commonly used notations when creating/designing ER diagrams (ERDs).
The major parts of ERDs are:
🔸Entities - a person, place or thing about which we want to collect and store multiple instances of data - is represented by a rectangle with a noun as the name of the entity (e.g. ‘Patient’, ‘Hospital’, ‘Doctor’).;
🔸Relationship - that connects the two entities involved in some relationship - is represented by a line;
🔸Attributes - the information about an entity which distinguishes the data we intend to store (e.g. doctorid, doctorname) and about the type of the data (e.g. string, integer, etc.) - are written inside an entity (inside a rectangle).
To describe different types of relationships that can take place in an ERD the notion of cardinality is of use. Cardinality is treated as the number of times an instance in one entity can relate to instances of another entity. Cardinality is depicted by the styling of a line that connects instances and its endpoint. The major types of cardinal relationships are:
🔸one to one - relationship means that one entity has only one event shared with another entity (for e.g. An appointment can have one and only one receipt);
🔸one to many - one of the related entities has an event that occurs one time, while the other entity can have more than one repetition of the event (for e.g. A hospital can have one or many doctors, while the doctor can have one and only one hospital);
🔸many to many - both entities have the same event or relationship happening more than once (for e.g. Many patients can have many appointments.).
Here is brief tutorial for ERD creation (in Crow's Foot Notation) with the help of such simple tools as Draw.io and Lucidchart:
👉Identify the key entities with particular names and label rectangles with these names. Don’t forget that they should be represented as nouns.
👉Think about the attributes of each entity and its data type.
👉Place attributes and their data type inside the rectangles with relevant entities.
👉Think about all relationships between the entities.
👉Choose and set an appropriate type of relationships between entities using lines.
Some of your entities may have only one relationship, some may have multiple relationships. That is okay.
👍9
Hi professionals!
How about to discuss topic "User Stories vs Use Cases"?
📝 User Story is a short statement describing some functionality to be implemented from the perspective of a user.
US typically includes:
🔸Story Title written in the format: As a <role> I can <capability>, so that <receive benefit>;
🔸Acceptance Criteria;
🔸Attachments (links to mock-ups, diagrams, check-lists, content, etc).
👍🏻 US’s Pros:
✔️User-centered (e.g.enables developers to determine the way of implementation)
✔️Simple format, which makes it easy for a business owners to understand and (dis)aproove
✔️Quick to change (e.g. changes often affect certain criteria rather than the whole US)
👎🏻 US’s Cons:
➖Unclearly defined criteria make testing difficult
➖Difficult to check the comprehensiveness of the criteria
➖Narrow vision (as US focuses on one single requirement)
📝 Use Case describe how a user should interact with the system in order to achieve a specific goal.
UC typically include:
🔸Titles;
🔸Actors;
🔸Preconditions;
🔸Main scenario;
🔸Alternative scenario;
🔸Exceptional scenario;
🔸Expected result.
👍🏻 UC’s Pros:
✔️Behavior-centred (e.g. describes interaction between a user and a system)
✔️Focus on the functionality (e.g. describes different scenarios and, what is more important, system’s behavior)
✔️Form the basis for writing test cases
👎🏻 UC’s Cons:
➖Changes take much time, as all the scenarios must be refactored
➖Non-functional requirements are not expected to be included
❓What do you prefer US or UC?
How about to discuss topic "User Stories vs Use Cases"?
📝 User Story is a short statement describing some functionality to be implemented from the perspective of a user.
US typically includes:
🔸Story Title written in the format: As a <role> I can <capability>, so that <receive benefit>;
🔸Acceptance Criteria;
🔸Attachments (links to mock-ups, diagrams, check-lists, content, etc).
👍🏻 US’s Pros:
✔️User-centered (e.g.enables developers to determine the way of implementation)
✔️Simple format, which makes it easy for a business owners to understand and (dis)aproove
✔️Quick to change (e.g. changes often affect certain criteria rather than the whole US)
👎🏻 US’s Cons:
➖Unclearly defined criteria make testing difficult
➖Difficult to check the comprehensiveness of the criteria
➖Narrow vision (as US focuses on one single requirement)
📝 Use Case describe how a user should interact with the system in order to achieve a specific goal.
UC typically include:
🔸Titles;
🔸Actors;
🔸Preconditions;
🔸Main scenario;
🔸Alternative scenario;
🔸Exceptional scenario;
🔸Expected result.
👍🏻 UC’s Pros:
✔️Behavior-centred (e.g. describes interaction between a user and a system)
✔️Focus on the functionality (e.g. describes different scenarios and, what is more important, system’s behavior)
✔️Form the basis for writing test cases
👎🏻 UC’s Cons:
➖Changes take much time, as all the scenarios must be refactored
➖Non-functional requirements are not expected to be included
❓What do you prefer US or UC?
🔥10👍4