Introduction: In step by step (4) of database design, we discuss components and semantics of advanced entity-link models, such as generalization, aggregation, and ternary relations. Starting from this lecture, I will guide you on the database design journey. We will start from requirement analysis, in the process of conceptual data modeling, multi-view integration, ER model conversion to SQL, paradigm, and so on, a complete and available SQL table is obtained.
Requirement Analysis is vital in the database lifecycle and usually involves the most people. At this stage, database designers must visit end users and interview them to determine what data they want to store in the system and how they want to use it. We divide requirement analysis into two steps: 1. understanding user requirements; 2. Extracting business rules. This time, we will first discuss "understanding user needs ".
Designing customized products-whether it is a database, a print advertisement or a toy, is a "Translation" process. We need to mine the vague ideas and aspirations that come into our customers' minds and translate them into real products that meet their needs.
The first step in this "Translation" process is to understand the user's needs. Designing the best order processing system is meaningless for customers who need a circuit design tool. An incomplete understanding of customer needs may lead to incorrect or useless design and development, which wastes time and money for you, your team, and your customers. (Remember that databases are the foundation of the entire application development)
Develop a plan
We first developed a plan, which contains a series of steps to explore customer needs. Follow these steps to better understand customer needs, but in some projects we do not need to follow all the steps. For example, if the customer is a single person and has a clear demand, we do not need to "find out who is who" or "Brainstorm. When the customer's data needs to be kept confidential, we cannot "Try the customer's work. In other projects, it is more appropriate to adjust the order of these steps. For example, we may brainstorm before visiting customers and observing their work ".
The steps are listed in the most general order below. You can make flexible adjustments based on different projects. The only goal is to better understand user requirements.
Next we will explain each step one by one.
List Problems
We need to think about what problems we can ask customers to help us understand the scope of the project ). The following problems can be used as the starting point.
Function:
The following problems mainly involve the functions and objectives of the system.
- What should the system do?
- Why do you want to build this system?
- What should the system look like?
- What reports are required?
- Do you need to define a new report?
- Who will the system operator be?
Data requirements:
These problems are to clarify the data requirements of the project. Understand what data is needed to help us define database tables.
- What data needs to be displayed on the system interface?
- Who should provide the data?
- How is the data associated?
- How are these tasks handled now? Where is the data from?
Data Integrity:
These issues help us define integrity constraints when building databases.
- What data is required? (Eg: Must a customer record have phone information ?)
- What is an effective field of data? (Eg: Is there a format for phone numbers? How long should the address data be ?)
- Does the system need to verify the effectiveness of the City Based on the zip code?
- Must the customer be defined in the system before placing an order?
- How high is the availability level required by the system? (Does the system require 7 × 24 availability? How often is data backed up ?)
Security:
These questions help us understand the customer's requirements for permission control and audit.
- Does each user need a different password?
- Do you need to control the data that different users can access? (Eg: The sales representative has the permission to view the customer's credit card account, but the order entry specialist cannot)
- Is data stored in the database encrypted?
- Who needs to record what operations to facilitate auditing? (Eg: record the operations performed by the Sales Representative to increase the customer level and trace the reasons for the operations as needed)
- How many levels of customers are there in the system? How many customers are there at each level?
- Does the document record your work and rights and responsibilities?
Environment:
These questions help us understand which systems or processes the current project will replace and which systems the project will interact.
- Is the current project replacing or upgrading an existing system?
• Is there a document describing the existing system?
• What functions are required by the existing system? What is not required?
• What data does the existing system process? How is the data stored? How is data associated?
• Is there a document on existing system data?
- Which systems must the current project interact?
• How do projects interact with other systems?
• Do new projects need to provide data to existing systems? How to provide?
• Do new projects need to receive data from existing systems? How to receive?
• Is there any document about other systems?
- What is the customer's entire business process? (Understand the role of the current project in the entire business process)
Visiting customers
The best way to understand the system we want to design and build is to ask the customer. Schedule a meeting with the customer with the problem list we prepared in the previous step. This is not as easy as chatting. It is a lengthy and painful process to understand the customer's needs.
Sometimes our hard-hitting questions can make customers feel uncomfortable. At these times, we must be more patient. We can have several meetings to understand the requirements, and each time we have to address several questions or procedures. Our goal is to have a complete and thorough understanding of the problems we want to solve.
Even if our project only solves a small part of the problem in the entire business, we should try to understand the customer's overall business process, which may bring us unexpected gains.
Find out who is who
Realize that different customers may have different visions for the project. We need to identify who is the leader, who is the active supporter, who is the spectator, and who is the player.
Some common customer roles are listed below:
Mining customer brain
Once we figure out who the customer is, we have to discuss with the Project Executive Director what the customer needs. What is the customer's desired solution, what data needs to be included, how the data is presented, and how different data is associated.
To communicate with as many stakeholders as possible, we need to consider the opinions of everyone, but remember that the project owner understands the customer's needs most and has the final decision.
Depending on the scale of the project, this process takes a few hours, and a few weeks to complete.
Try the customer's work
Observing the daily work of the customer can help us better understand the business. It would be better if we could do the customer's work for a while to understand the content.
Even if we cannot actually try the customer's work, we can usually sit close to them. Tell customers that we will slightly reduce their work efficiency and ask silly and annoying questions. Then we can start to ask. Record and learn as many things as possible in this process. In some cases, the opinions of foreign practitioners may be converted into good ideas that customers cannot think.
Learn existing operations
After trying the customer's work, we can also see if there are other ways to understand the existing process. Generally, companies have operation manuals or documents describing customer roles and responsibilities.
Find the data storage methods currently used by customers, such as relational database systems, workbooks, and paper documents. Learn how the data is used and how it is associated. Generally, physical databases are correlated by redundant information, such as the customer ID.
Brainstorm
At this moment, we have a better understanding of the customer's business and needs. To confirm that there are no omissions, we need to arrange brainstorming. Call the project execution owner and as many customer representatives and stakeholders as possible to describe the requirements they have known in the early stage, and then let them speak freely about the problems or problems.
In this process, we are not eager to accept or exclude any customer's requirements. First, we will record what the customer said and confirm that we have taken these aspects into consideration. Before the formal development, we will work with the Project Executive Director to determine the priority of the requirement based on the project scale and delivery deadline.
Future Prospects
Think about future needs during brainstorming. Ask the customer if their business will change in the future or what functions they want the system to include in the future.
We can put some of their ideas into the current project, even if we can't, it can let us know what extensions may be in the future, we can leave room in advance when designing the database.
Understanding customers' questions
Some enthusiastic and technical users will come to advise us how to design the system and how to create structured data tables. We may find these suggestions meaningless or even ridiculous. However, before ignoring these suggestions, we should think carefully about the underlying reasons why users put forward these suggestions or question them. Customers are more familiar with the business than we do. Their suggestions or questions may contain business changes that we have not yet understood or some special business situations.
Clarify the real needs of customers
Sometimes customers do not understand their real needs. They can see the appearance of the problem, but they may not be clear about its root cause. We need to help customers find the root cause of the problem and propose solutions to the source of the problem.
Sometimes customers think that databases or new systems can magically increase sales and reduce costs. In fact, a well-designed database can reduce input errors, improve operation efficiency, provide data reports, and help customers manage data. In the process of communicating with customers, we need to tell them what the new system can do and what it cannot do, so that customers can establish correct expectations.
Priority
After the previous steps, we have listed a long list of expected functions. Some of these functions may be impractical or beyond the scope of the current project. To make the project scale controllable, we need to work with the customer to define the priority of the function.
Generally, we can divide functions into three levels. The first priority is the features that must be included in the current development. Failing to complete these features means that the project fails. The second priority is the function that can be put into the next phase of development. When the first priority function is completed, we can refer to the second priority function for the current development. The third priority is those functions that are relatively unimportant or beyond the scope of the project. We can ignore these functions.
In some cases, priority may be converted. When a feature with the first priority is very difficult to implement, we can communicate with the customer to determine whether the feature is so important and whether it can be moved to the second priority to avoid affecting the project progress. When some features in the second priority are easy to implement, we can adjust this feature to the first priority list. However, before making these adjustments, you must communicate with the customer and get the customer's approval.
Verify your understanding
Sort out our understanding of the business and needs, and confirm with the customer one by one. When the customer says "but", "except", "and" sometimes ", we should be very careful to confirm that the customer only emphasizes what we already know, there is no new situation. At this stage, the customer may think of exceptions they have not considered before.
The exception is the major impact of database design. Only by mining exceptions in the demand analysis phase can we prepare for database design. For example, we confirmed the return process to the customer and said, "Here, the receiver will enter the RMA number and click the" finish "button ?" The customer may say, "Well... This is the case in most cases, but sometimes there is no RMA, and the recipient will fill in none ." This is an important exception that a customer did not tell us before. We must record it immediately. In another example, we assume that the customer uses two columns: Delivery Address and Bill address. "The order must have a delivery address and a bill address," We confirmed to the customer ." The customer interrupted: "Sometimes we need two delivery addresses because different parts of the order may be delivered to different places .", And find an order, and the second delivery address is marked at the edge of the order. This is a major exception. It can be easily labeled on paper, but it is impossible to add an address in a form element of the database. Only by knowing this exception can we use the design method to solve this requirement.
Write requirement document
The requirement document describes the system we want to build. This document is also known as the Requirement Specification Description. The requirement document should clarify what kind of system we will build, what the system will do, what features it will contain, and how customers will use the system to solve their problems. The requirement document clarifies the functions that will be completed by the project, which also avoids disputes during system delivery.
Deliverables, namely milestones, should be defined in the requirement document. Milestones are intermediate results that can be intuitively presented and verified. The customer uses milestones to measure the progress of the project. The final deliverables need to be defined in the requirement document, which is also the criteria for determining whether the project is completed.
The use case diagram is a good requirement analysis tool and can be used as part of the requirement document. The main function of the use case diagram is to express the functional requirements or behaviors of the system. The use case diagram shows who uses the system from a business perspective, what services the user wants the system to provide, and what services the user needs to provide for the system. It also facilitates software developers to ultimately implement these functions. In the official document, the use case diagram contains six elements: Actors, use cases, associations, and include), extended relationship (extend), and generalized relationship (generalization ). However, some UML plotting tools provide a direct Association (directed Association ).
E. g.: The user management example is shown in the following figure. The humanoid icon in the figure represents the participant, and the ellipse represents the use case. (for the source of the example, see "summary and reference ")
Overview
1. Find out which customer plays which role
2. Mining information from the customer's mind
3. Search for documents on user roles, responsibilities, existing processes, and existing data
4. Observe the customer's work and learn their business operations
5. Brainstorm and divide the collected functional requirements into Level 1, level 2, and level 3 by priority.
6. Confirm understanding of customer requirements
7. Write Requirement documents, including verifiable milestones and Use Cases
Reference
1. Beginner UML ------- use case diagram (http://blog.csdn.net/dl88250/archive/2007/10/16/1826713.aspx)
2. UML use case diagram (http://www.alisdn.com/wordpress? P = 1161)
From: dbfocus
Introduction: In step by step (4) of database design, we discuss components and semantics of advanced entity-link models, such as generalization, aggregation, and ternary relations. Starting from this lecture, I will guide you on the database design journey. We will start from requirement analysis, in the process of conceptual data modeling, multi-view integration, ER model conversion to SQL, paradigm, and so on, a complete and available SQL table is obtained.
Requirement Analysis is vital in the database lifecycle and usually involves the most people. At this stage, database designers must visit end users and interview them to determine what data they want to store in the system and how they want to use it. We divide requirement analysis into two steps: 1. understanding user requirements; 2. Extracting business rules. This time, we will first discuss "understanding user needs ".
Designing customized products-whether it is a database, a print advertisement or a toy, is a "Translation" process. We need to mine the vague ideas and aspirations that come into our customers' minds and translate them into real products that meet their needs.
The first step in this "Translation" process is to understand the user's needs. Designing the best order processing system is meaningless for customers who need a circuit design tool. An incomplete understanding of customer needs may lead to incorrect or useless design and development, which wastes time and money for you, your team, and your customers. (Remember that databases are the foundation of the entire application development)
Develop a plan
We first developed a plan, which contains a series of steps to explore customer needs. Follow these steps to better understand customer needs, but in some projects we do not need to follow all the steps. For example, if the customer is a single person and has a clear demand, we do not need to "find out who is who" or "Brainstorm. When the customer's data needs to be kept confidential, we cannot "Try the customer's work. In other projects, it is more appropriate to adjust the order of these steps. For example, we may brainstorm before visiting customers and observing their work ".
The steps are listed in the most general order below. You can make flexible adjustments based on different projects. The only goal is to better understand user requirements.
Next we will explain each step one by one.
List Problems
We need to think about what problems we can ask customers to help us understand the scope of the project ). The following problems can be used as the starting point.
Function:
The following problems mainly involve the functions and objectives of the system.
- What should the system do?
- Why do you want to build this system?
- What should the system look like?
- What reports are required?
- Do you need to define a new report?
- Who will the system operator be?
Data requirements:
These problems are to clarify the data requirements of the project. Understand what data is needed to help us define database tables.
- What data needs to be displayed on the system interface?
- Who should provide the data?
- How is the data associated?
- How are these tasks handled now? Where is the data from?
Data Integrity:
These issues help us define integrity constraints when building databases.
- What data is required? (Eg: Must a customer record have phone information ?)
- What is an effective field of data? (Eg: Is there a format for phone numbers? How long should the address data be ?)
- Does the system need to verify the effectiveness of the City Based on the zip code?
- Must the customer be defined in the system before placing an order?
- How high is the availability level required by the system? (Does the system require 7 × 24 availability? How often is data backed up ?)
Security:
These questions help us understand the customer's requirements for permission control and audit.
- Does each user need a different password?
- Do you need to control the data that different users can access? (Eg: The sales representative has the permission to view the customer's credit card account, but the order entry specialist cannot)
- Is data stored in the database encrypted?
- Who needs to record what operations to facilitate auditing? (Eg: record the operations performed by the Sales Representative to increase the customer level and trace the reasons for the operations as needed)
- How many levels of customers are there in the system? How many customers are there at each level?
- Does the document record your work and rights and responsibilities?
Environment:
These questions help us understand which systems or processes the current project will replace and which systems the project will interact.
- Is the current project replacing or upgrading an existing system?
• Is there a document describing the existing system?
• What functions are required by the existing system? What is not required?
• What data does the existing system process? How is the data stored? How is data associated?
• Is there a document on existing system data?
- Which systems must the current project interact?
• How do projects interact with other systems?
• Do new projects need to provide data to existing systems? How to provide?
• Do new projects need to receive data from existing systems? How to receive?
• Is there any document about other systems?
- What is the customer's entire business process? (Understand the role of the current project in the entire business process)
Visiting customers
The best way to understand the system we want to design and build is to ask the customer. Schedule a meeting with the customer with the problem list we prepared in the previous step. This is not as easy as chatting. It is a lengthy and painful process to understand the customer's needs.
Sometimes our hard-hitting questions can make customers feel uncomfortable. At these times, we must be more patient. We can have several meetings to understand the requirements, and each time we have to address several questions or procedures. Our goal is to have a complete and thorough understanding of the problems we want to solve.
Even if our project only solves a small part of the problem in the entire business, we should try to understand the customer's overall business process, which may bring us unexpected gains.
Find out who is who
Realize that different customers may have different visions for the project. We need to identify who is the leader, who is the active supporter, who is the spectator, and who is the player.
Some common customer roles are listed below:
Mining customer brain
Once we figure out who the customer is, we have to discuss with the Project Executive Director what the customer needs. What is the customer's desired solution, what data needs to be included, how the data is presented, and how different data is associated.
To communicate with as many stakeholders as possible, we need to consider the opinions of everyone, but remember that the project owner understands the customer's needs most and has the final decision.
Depending on the scale of the project, this process takes a few hours, and a few weeks to complete.
Try the customer's work
Observing the daily work of the customer can help us better understand the business. It would be better if we could do the customer's work for a while to understand the content.
Even if we cannot actually try the customer's work, we can usually sit close to them. Tell customers that we will slightly reduce their work efficiency and ask silly and annoying questions. Then we can start to ask. Record and learn as many things as possible in this process. In some cases, the opinions of foreign practitioners may be converted into good ideas that customers cannot think.
Learn existing operations
After trying the customer's work, we can also see if there are other ways to understand the existing process. Generally, companies have operation manuals or documents describing customer roles and responsibilities.
Find the data storage methods currently used by customers, such as relational database systems, workbooks, and paper documents. Learn how the data is used and how it is associated. Generally, physical databases are correlated by redundant information, such as the customer ID.
Brainstorm
At this moment, we have a better understanding of the customer's business and needs. To confirm that there are no omissions, we need to arrange brainstorming. Call the project execution owner and as many customer representatives and stakeholders as possible to describe the requirements they have known in the early stage, and then let them speak freely about the problems or problems.
In this process, we are not eager to accept or exclude any customer's requirements. First, we will record what the customer said and confirm that we have taken these aspects into consideration. Before the formal development, we will work with the Project Executive Director to determine the priority of the requirement based on the project scale and delivery deadline.
Future Prospects
Think about future needs during brainstorming. Ask the customer if their business will change in the future or what functions they want the system to include in the future.
We can put some of their ideas into the current project, even if we can't, it can let us know what extensions may be in the future, we can leave room in advance when designing the database.
Understanding customers' questions
Some enthusiastic and technical users will come to advise us how to design the system and how to create structured data tables. We may find these suggestions meaningless or even ridiculous. However, before ignoring these suggestions, we should think carefully about the underlying reasons why users put forward these suggestions or question them. Customers are more familiar with the business than we do. Their suggestions or questions may contain business changes that we have not yet understood or some special business situations.
Clarify the real needs of customers
Sometimes customers do not understand their real needs. They can see the appearance of the problem, but they may not be clear about its root cause. We need to help customers find the root cause of the problem and propose solutions to the source of the problem.
Sometimes customers think that databases or new systems can magically increase sales and reduce costs. In fact, a well-designed database can reduce input errors, improve operation efficiency, provide data reports, and help customers manage data. In the process of communicating with customers, we need to tell them what the new system can do and what it cannot do, so that customers can establish correct expectations.
Priority
After the previous steps, we have listed a long list of expected functions. Some of these functions may be impractical or beyond the scope of the current project. To make the project scale controllable, we need to work with the customer to define the priority of the function.
Generally, we can divide functions into three levels. The first priority is the features that must be included in the current development. Failing to complete these features means that the project fails. The second priority is the function that can be put into the next phase of development. When the first priority function is completed, we can refer to the second priority function for the current development. The third priority is those functions that are relatively unimportant or beyond the scope of the project. We can ignore these functions.
In some cases, priority may be converted. When a feature with the first priority is very difficult to implement, we can communicate with the customer to determine whether the feature is so important and whether it can be moved to the second priority to avoid affecting the project progress. When some features in the second priority are easy to implement, we can adjust this feature to the first priority list. However, before making these adjustments, you must communicate with the customer and get the customer's approval.
Verify your understanding
Sort out our understanding of the business and needs, and confirm with the customer one by one. When the customer says "but", "except", "and" sometimes ", we should be very careful to confirm that the customer only emphasizes what we already know, there is no new situation. At this stage, the customer may think of exceptions they have not considered before.
The exception is the major impact of database design. Only by mining exceptions in the demand analysis phase can we prepare for database design. For example, we confirmed the return process to the customer and said, "Here, the receiver will enter the RMA number and click the" finish "button ?" The customer may say, "Well... This is the case in most cases, but sometimes there is no RMA, and the recipient will fill in none ." This is an important exception that a customer did not tell us before. We must record it immediately. In another example, we assume that the customer uses two columns: Delivery Address and Bill address. "The order must have a delivery address and a bill address," We confirmed to the customer ." The customer interrupted: "Sometimes we need two delivery addresses because different parts of the order may be delivered to different places .", And find an order, and the second delivery address is marked at the edge of the order. This is a major exception. It can be easily labeled on paper, but it is impossible to add an address in a form element of the database. Only by knowing this exception can we use the design method to solve this requirement.
Write requirement document
The requirement document describes the system we want to build. This document is also known as the Requirement Specification Description. The requirement document should clarify what kind of system we will build, what the system will do, what features it will contain, and how customers will use the system to solve their problems. The requirement document clarifies the functions that will be completed by the project, which also avoids disputes during system delivery.
Deliverables, namely milestones, should be defined in the requirement document. Milestones are intermediate results that can be intuitively presented and verified. The customer uses milestones to measure the progress of the project. The final deliverables need to be defined in the requirement document, which is also the criteria for determining whether the project is completed.
The use case diagram is a good requirement analysis tool and can be used as part of the requirement document. The main function of the use case diagram is to express the functional requirements or behaviors of the system. The use case diagram shows who uses the system from a business perspective, what services the user wants the system to provide, and what services the user needs to provide for the system. It also facilitates software developers to ultimately implement these functions. In the official document, the use case diagram contains six elements: Actors, use cases, associations, and include), extended relationship (extend), and generalized relationship (generalization ). However, some UML plotting tools provide a direct Association (directed Association ).
E. g.: The user management example is shown in the following figure. The humanoid icon in the figure represents the participant, and the ellipse represents the use case. (for the source of the example, see "summary and reference ")
Overview
1. Find out which customer plays which role
2. Mining information from the customer's mind
3. Search for documents on user roles, responsibilities, existing processes, and existing data
4. Observe the customer's work and learn their business operations
5. Brainstorm and divide the collected functional requirements into Level 1, level 2, and level 3 by priority.
6. Confirm understanding of customer requirements
7. Write Requirement documents, including verifiable milestones and Use Cases
Reference
1. Beginner UML ------- use case diagram (http://blog.csdn.net/dl88250/archive/2007/10/16/1826713.aspx)
2. UML use case diagram (http://www.alisdn.com/wordpress? P = 1161)
From: dbfocus
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
