Requirements definition-articles that can be human resources who can design systems

Introduction

Have you ever felt this while studying programming?

** "I can't make a product even if I study" ** ** "How do you do development in the first place?" ** ** "What is the requirement definition?" **

In order to solve that problem, let's first understand ** the overall feeling of development **. Please see the figure below "Software Development Process"

The programming I'm always studying corresponds to the ** "implementation" ** part. In other words, there are ** 4 walls ** before you can demonstrate your programming skills.

image.png

Therefore, in this article, it is necessary before starting implementation (programming). I will explain ** "Planning-Design" ** step by step. In particular, we will focus on ** "requirements definition" and "design" ** that engineers should understand.

It is said that the time used for ** implementation (programming) ** in the entire development is ** 20 to 30% of the total **. On the other hand, ** 50% of the total ** is used for ** upstream processes ** such as requirement definition and design.

In other words, ** human resources who can define and design requirements will inevitably increase their contribution to development projects **. Let's take this opportunity to acquire it and expand the field of activity.

The chapters of this article are as follows.

--Necessity of requirement definition --The process of determining requirements --Matters to be decided by requirement definition --How to make a basic design --One step ahead of basic design --Summary

Need for requirement definition

Purpose of requirement definition

There are two types of parties involved in system development projects.

-** People who "make" the system (developers) ** -** People who "use" the system (orderer) **

If you want to make the system you want, there is no problem because you have the completed image in your head. In many cases, we ask the "orderer ⇒ developer" to develop.

At that time, the developer does not know what to make unless ** the image in the orderer's head is clarified **. Requirement definitions exist for the purpose of communication for that purpose.

Let's compare it to everyday life. Would you like to ask "Buy a drink!" When you're thirsty?

Properly "buy coffee" or more specifically "** Buy hot fine sugar coffee. It's a PET bottle, not a can! **" You can't buy the coffee you thought you wouldn't say.

System development is the same. ** "What should I make? The purpose of the requirement definition is to clearly agree on **.

That is, ** Requirements definition = Advance promise that you can specifically confirm "This is OK!" At the time of delivery ** It is good to have an understanding such as.

Process of determining requirements definition

Now that you know the purpose of the requirements definition, let's understand the three steps to complete the requirements definition.

-** Request : ** Ideas such as "I wish there was such a system" ** - Request : I want you to implement it in your system ** Rough list of functions ** - Requirements **: Both sides agreed ** Specific function list ** and ** Implementation method **

image.png

Communication through ** "examination" and "proposal" ** is required for these three-step process. It will be as follows when arranged in order.

-** ① Request: Problem to be solved (orderer task) **

image.png

Matters decided by requirement definition

Now that you know the flow, let's roughly organize the matters to be decided in the requirement definition. If you organize it with 3W (Why, What, How), it will be neatly organized.

-** Why: Purpose of system development (request) **

How to make basic design (screen design, functional design, data design)

You can imagine that there are so many things to decide in the requirements definition, but don't worry.

What (business flow, functional requirements, non-functional requirements) is not an engineer, Even on the development side, there is a tendency for "** salesman " and " sales engineer **" to handle the work.

So, I will dig deeper into ** How (design) ** where engineers can demonstrate their abilities. Among them, ** basic design is the key **, so this article will focus on that.

As mentioned above, in the basic design, ** "screen / function / data" ** is designed. Only when these are in place can programmers start software development.

-** Screen design (UI design) ** ――What can you do on each screen? --Information to be displayed (characters, images, etc.) and layout --Summary the above in a screen transition diagram -** Functional design ** --Backside processing (function name and processing content) --Data required for processing, data acquisition source (input from screen, acquisition from DB, etc.) --Delivery destination of processed data (screen display, save to DB, etc.) -** Data design ** --Specific contents of the data --Database design --Data flow (data flow)

Screen design (UI design)

First and foremost, the element that should be decided is ** screen design (UI design) **.

Because users use the software through the screen (UI) First of all, getting consent to ** "Ease of use of the screen" ** is the shortcut to the success of the project.

As mentioned above, the following items are decided in the screen design.

――What can you do on each screen? --Information to display (text, images, etc.) and layout --Summary the above in a screen transition diagram

image.png

If you organize it so far, you can get a concrete image of the completed system. This is the reason for making the screen design first.

Functional design

After the screen design (UI design) is completed, design the functions to be implemented in the system. Please understand that functional design is the phase that defines ** "processing to be executed behind the scenes, necessary data" **.

The decisions you need to make are as described above.

--Backside processing (function name and processing content) --Data required for processing, data acquisition source (input from screen, acquisition from DB, etc.) --Delivery destination of processed data (screen display, save to DB, etc.)

Let's roughly design the functions of each page that appears in the screen transition diagram.

image.png

image.png

image.png

image.png

image.png

image.png

By doing this, anyone can imagine ** what kind of program should be written **. Since the parts composition that makes up the system is also clarified, ** division of roles within the team ** is also easy.

As a finishing touch to the functional design, let's connect the screen design and the functional design. Visualize what kind of ** user operation / backside processing ** is being performed between screens.

image.png

The figure below shows the overall arrangement.

image.png

Data design

The last is data design. After preparing so far, you can finally start data design.

As mentioned above, there are three things to decide.

--Specific contents of the data --Database design --Data flow (data flow)

What you should be aware of here is that ** data is roughly divided into four types **. Design how these four types of data flow in the system.

-** Data to "input" to the program (argument) ** --Data entered by the user from the web screen --Data read from database -** Data "returned" from the program (return value) ** --Data to be displayed on the web screen --Data to be stored in the database

Specific contents of data

At this stage, we will embody the data definition that has been abstracted, such as ** "member information" **. At the practical level, knowledge of ** "normalization" ** is required.

-** Member information **

Database design

After the data is clear, design the database.

The first thing to remember is that up to this point, data was called by "member information," "product information," "purchase history," etc. From a database perspective, we use the expression ** table **. *** "Member table", "Product table", "Purchase history table" **, etc.

There are three tasks required in database design.

--Dividing table roles into ** "master" ** and ** "history" ** --Organize ** reference relationships ** between tables --Transcribing the reference relationship to ** ER diagram **

First, let's divide the role of each table according to the following criteria.

-** Master: Basic information (data referenced from other tables) ** --Member table (hereinafter referred to as ** "Member Master" ) --Product table (hereinafter referred to as ** "product master" ** - History: Data accumulated while the system is used ** --Purchase history table

Next, "Reference relationship between tables" organizes the relationship between ** reference destination and reference source ** with arrows. If you also specify ** "Data generated from user behavior" **, it is easy to understand without omission of data flow.

image.png

Finally, create an ER diagram that will be the design diagram of the database and complete it.

image.png

Data flow (data flow)

Finally, if you organize ** "Relationship between database and screen transition diagram" **, You can see the whole system ** "Screen design x Functional design x Data design" **.

Since we will write programs one by one based on this blueprint, Practice it many times so that you can draw the whole picture firmly.

image.png

One step ahead of basic design

If you understand so far, you can make a basic design, so it is enough for the purpose of developing your own product. Let's proceed with programming while investigating various parts that we do not understand.

After development, many people have posted Qiita articles about server settings for publishing services, so Please refer to [this article] if it is easy to understand.

In the actual development site, you cannot make a clear request to the programmer unless you make ** detailed design **. After understanding the contents of this article, please study the following first.

--Make class diagrams and sequence diagrams --Determine the system architecture --Determine the mounting technology for each part of the architecture

That said, technological innovation is particularly rapid these days, so there are cases where new technologies appear in the middle of detailed design . Following agile development, you can proceed by saying " Detailed design is decided while making **".

at the end

In the field of team development, ** division of roles is a prerequisite **. Let's draw the whole picture firmly and clarify ** "who makes what" ** and proceed with development smoothly.

Also, various information is posted on SNS, so if you feel that you can read the article, I would be grateful if you could follow Twitter account "Saku731".

(Addition) I wrote an article summarizing the skills required for system development with Python. Please refer to those who program by themselves.

--Overview of skills required for system development: Learning roadmap that allows you to develop and publish services from scratch with Python --A series of steps for system development using Django: Articles that enable system development with Django (Python) _Introduction

Recommended Posts

Requirements definition-articles that can be human resources who can design systems
Confirmation that rkhunter can be installed
Article that can be a human resource who understands and masters the mechanism of API (with Python code)