Now that we have established the basic concept of the database, let’s get started with ‘modeling’. Database modeling means clearly and specifically representing (documenting) the entire process from data creation to operation to management. In this article, we would like to discuss the first step in database modeling: analyzing requirements.
■ Why Database modeling?
Regular databases are bound to have limited resources, such as capacity and administrative personnel. If you think like “I don’t know about it, I will save them all.”, and put them all in, they’re going to be distorted or inefficient quickly. Also, scalibility can be another issue you might face.
Therefore, it is necessary to design well in advance what kind of data will be stored in the database. The database should also be studied from the planner’s point of view, because if you have a good understanding of the database, you are less likely to make unreasonable demands.
■ Database modeling steps
The database modeling phase can be divided into four steps. It is requirement analysis > conceptual data modeling > logical data modeling > physical data modeling, and each step results in output called requirement analysis, ERD, relational data model, and SQL. It then moves on to developing applications, security, and management.
A detailed description of each step will be discussed in a later article, and today we’ll first discuss the requirements analysis process.
■ Step 1: Create a request for proposal (RFP)
A RFP is typically a document sent to a developer or subcontractor asking, “I need a service with this capability, can you do it for me?” Usually, public institutions disclose the form of proposals, so it would be good to check the samples. Components include:
1. Overview –> what this project is about…
This item tells you what kind of work you are requesting. The outline of the project describes the project name, duration, budget, terms and conditions. Also, we need the necessity and purpose of this project, the composition of the current status, and the implementation schedule.
2. Requirements –> I want this, and this…
It is important to distinguish between what needs to be implemented and what needs to be implemented to produce project results in advance. This helps to establish future milestones by discussing the project schedule and scope. In addition to functionality/performance/interface/DB, it must be written comprehensively, including security and maintenance.
3. Proposal Guide –> Will you write a proposal in this format?
This is not applicable to internal projects. If you are placing an order with an outsourcing company, it is also recommended to provide a guide for writing the proposal. Basically, a entire process, selection criteria, and estimated schedule are required. It also contains instructions on the request form (ppt, word, pdf) or the table of contents to be included in the proposal and where to submit it.
■ Step 2: Create a requirements statement (SRS, Software Requirements Specification)
Once the requirements have been derived from the RFP, it is now time to prepare a statement of requirements. There is an International Standard (IEEE-Std-830). For more information about standards, you need to purchase to see. However, there are already broad requirements. See the blog for details.
As you look at the content, the data scattered in the proposal request is organized into one document. It is a step to verify how each role will perform their tasks and understand the requirements properly, along with explanations of the details (descriptive sentences or materials to help them understand).
■ Step 3: Create a requirements definition
A requirement definition is a document that identifies whether the requirement is clear or complete. The administrator must review the integration or disconnection requirements through SRS and return to the requirement derivation stage if defective.
In most cases, list the requirements. This document clearly summarises whether there are requirements and constraints to be performed. Of course, it’s a document that needs to be constantly modified, updated, and managed.
■ Identifying requirements is not a one-time task!
So far, we’ve taken a quick look at the process of analyzing requirements. Of course, I hope it goes smoothly like this, but the reality is… It will be difficult to proceed perfectly in a short period of time, non-cooperative members… etc. First of all, it is difficult for people who want to create services to define what they want and what customers want in one succint word.
What this article deals with is not something that ends once or twice. If development starts with a misplanned project, only greater difficulties will arise. If possible, it is important to gather all stakeholders to communicate, exchange opinions, and refine each other. At this stage, let’s not say:
“You’re the planner. Why don’t you know?”
“You’re the developer. Why can’t you do that?”
In the end, it is very important to work together.