How to proceed with requirement definition and method design

When using this tool, there are no rules about where to start. However, I think the natural way to proceed is as follows.

• Only requirement setting is required first.

1. Clarify the purpose of realizing the idea:

As a motivation to create an application, it should always be clear.

Requirement name Setting

• Set the requirement name and application name, and clarify your motivation to impolement and the purpose of the requirement
  • Example: Requirement name EC site service (EC_site_Shopping)

2. Create a target list:

This is the process of clarifying the necessary resources as targets for the application.

Recognize and regiter targets (create model)

• Identify nessesary appearers (actors and props) on the stage to realize the requirements(Here, we limit to those that are directly conceivable)
  • Example: product, customer, person in charge
• In some cases, common accessories attached to appearing items are made independent as one target (for example, image target that collectively handle images attached to multiple targets)
• The target is equivalent to creating the M model of the MVC method.
• ER diagram is automatically generated based on the target's settings.

3. Create a feature list:

It's a process of figuring out whatever functionality your application needs.

Register expected functions (identify functions)

• Register without considering the order of features or the level of a feature.

4. Associate each feature with a relevant target:

This is the process of selecting and linking the corresponding target by editing each feature in the feature list.

Associate targets in editing created feature

• Assign a main target to a feature. (The main target means the target that the feature deals primarily with.)
• How to choose the main target of a feature? (When being somebody deals with something, if somebody and something are different, then something is the main target.)
• When there are multiple items to deal with, which one should be selected as the main target? (Things that occur incidentally to a certain target are called sub-targets, so a certain target is main target)
• Targets related to the main target are secondary targets. Sub1 occurs directly related to the main target. A sub2 shall occur related to a sub1 target.
• If there is a mistake in the linked target or there is a shortage, add or delete it by editing again.
• Some original targets change content depending on the process of feature. In that case, it is important to newly register and link appropriate targets.
  • Example: If it is an order for a product, the ordered product will be the product linked to the customer. Therefore, such ordered products should be treated separately from the original product targets.
  • Example: An ordered product becomes a shipping product linked to the person in charge and shipping date by being handled by the person in charge. Therefore, it should be differentiate the shipments as well.
  • Example: As the same, a person becomes a user by logging in, and becomes a customer by placing an order on an EC site. If a user has the role that handles the shipment becomes the person in charge .
• When the target is not particularly clear, such as home connection feature, it is a good idea to specify the application (System) target generated by default.

5. Group each feature around its target:

The process of grouping based on the main target associated with each feature.

Grouping the list of features ( grouping features equivalents to Creating a controller. This task is very important.)

• It is important to properly link the main target for the feature. Grouped around this main target. Features that do not specify a main target are not grouped.
• Grouping results in creating a 'group of features' that performs operations on a main target. Grouping has a very important meaning, and each group corresponds to a controller unit in the MVC method.
• Grouping can be changed at any time, partially according to your needs.

6. Break down each feature by CRUDI:

It is the process of validating each grouped feature against CRUDI (Create, Read, Update, Delete, Index(list)) criteria and subdivide it if necessary.

Specify CRUDI in feature details (Verify feature by specifying CRUDI)

• Organize missing features based on CRUDI. However, if you specify multiple CRUDIs for a feature, it will be automatically divided into each by the action generation operation.
• Create: C, Update: U, Delete: D, Read: R, Index(list): I
• Based on CRUDI, when missing features are added, if an appropriate target is linked, the additional features are also grouped together.

7. Generate action:

Auto-generate standard action steps required when performing a feature.

Assign actions (automatically generate a standard action)

• For each feature, it is possible to assign actions based on CRUDI criteria for those with CRUDI designations. You can do it all together or individually.
• If multiple CRUDIs are assigned to one feature, they will be divided into each feature, so organize them appropriately according to each CRUDI.
• Actions are automatically generated according to rules. Duplicate action names in the same group must be adjusted, including changing the action name, so that they do not overlap later.

8. Create relationships between targets:

It is the process of making mutual connections between individual targets, and of parent-child relationships being explicit. This work forms an important relationship diagram for creating the database.

Set the relationships between targets and create an ER diagram (It is extremely important to organize the relationships of the targets. The ER diagram is automatically generated.)

• Organize the parent-child relationships of already created targets. Arrangement of this relation greatly influences the construction of the database.
  • Example: When a customer places an order, there is a relationship with the ordered product, and that relationship can be multiple ordered products for one customer (one-to-many relationship).
  • Example: One product can be ordered by multiple customers, so there is a relationship between one product and multiple order products (one-to-many relationship)
• Setting the target parent-child relationship automatically sets the parent's ID as the child's foreign key.
• Consider STI inheritance, polymorphic relationships where appropriate
  • Example: To inherit the user and make the customer and the person in charge an STI relationship, specify the inheritance source of the customer and the person in charge as the user.
  • Example: A polymorphic relationship associates an image target with a product, user, etc. that needs the image through a virtual parent. At this time, the parent target (product, user, etc.) associates the virtual parent as a child. The virtual parent is deleted when the set child side association is deleted, and the relationship with the related parent is also deleted.
• Don't create force a target relationship if it's not necessary.
  • Example: Merchandise inventory is registered by the person in charge, but it is not necessary for one person in charge to be associated with a specific product inventory, so there is no need to have a relationship.
• ER diagram is automatically generated

9. Organize target attributes:

Register the required attributes of each target and reflect them in the ER diagram.

Set target attributes and refine ER diagram

• By creating a target and establishing relationships between targets, the ID attribute that is the primary key of the target, the creation date, the update date that are required as standard, and the foreign key attribute of the parent reference are automatically set.
• Add required target attributes for non-auto generated attributes.However, for 'target' in a parent-child relationship, the same attribute as that of the parent should be not set for the child. It is sufficient if there is a relationship in which the parent's attribute can be obtained by referencing the parent with the foreign key attribute. Eliminate duplication of parent-child attributes (one of 'target' attributes normalization).
• Set target attributes with proper names so that they are not duplicated for each target.
  • Example: If each target requires a name attribute, it is better to use the same name for each.
• Attributes required for Polymorphic relationships and STI inheritance are automatically set (Polymorphic and STI can be ignored if not necessary.)
• ER diagrams are automatically generated considering the set attributes.

Think about the process and normalize (this is very important)

• Considering the process, if there is overlap in the attributes of the data represented by the target, the common attributes of the target should be isolated. This work corresponds to target attributes normalization. This is a very important task for effective database management.

  • Example: Ordered products generated by the process of purchasing products, if a customer order different products at the same time, the data will be duplicated for items other than products, such as the same order date. In this case, the common attribute related to the same order is separated as a target called order, and the order product and the order are linked in a parent-child relationship (one-to-many relationship).
  • old: customer → Product → Ordered product
  • New: customer → Product → Order - Ordered product (one to many)

  

10. Rearrange actions:

As a result of target normalization, group readjustment, etc., these actions finally must be adjusted.

readjust actions

• Action name must be unique within one group. Therefore, change one of the duplicate action names to a proper action name
• Duplicate actions in each group are clearly marked as duplicates by color

• If there is a lot of duplication within a group, consider splitting the group

  • Example: In user management, login, logout, etc. are considered targets of authentication for use. In that case, you can create a group called 'authentication' and separate it without creating a target.

Organize the descriptions of actions in the group

• Organize the descriptions of actions generated by individual defaults into more specific and appropriate content

11. Organize user interface (UI) frames should be associated with each feature:

This is the process of organizing the screen (rough framework) calling each feature and displayed as a result of the feature.

Create a UI in the user interface list and associate it with a feature action (organize UIs)

• Set common layout (think header, footer, right side display, left side display configuration)
• Register the user interface (screen for user) used (called) for each feature.
• You can associate an image with the UI, but it is better to set only the name first.
• Think of UI as a screen called from a specific action. Therefore, the linked action specifies the action that calls the UI screen
• UI screen creation corresponds to the view unit of the MVC method.
• Organize the descriptions of actions generated by individual defaults into more specific and appropriate content

12. Organize the necessary conditions for each feature action and each target:

This is the process of sorting out the conditions for whether or not to execute each feature action and the conditions for processing the target.

Set group conditions: Set action conditions from group details

• Set condition for executing actions within the group if necessary
  • Set the necessary conditions for feature actions within the group
  • Pre-processing conditions (preconditions for action execution)
  • Post-processing conditions (Incidental conditions after action execution)
  • Link by assigning the corresponding action to the condition

Set model conditions: Set model conditions in the target details

• Set conditions that need to be enforced during CRUDI processing for models (targets)
  • Validation (validity check conditions for entering data)
  • Filtering conditions (data search conditions)
  • Preprocessing for registration/update/deletion
  • Post-processing of registration/update/deletion
  • Other necessary processing