Business Diary with a Slack App (Part 1) - Basic Operations -

The other day, I wrote a post about business diaries here.

• since this is a technical blog, just an article feels incomplete.
• I’m an engineer, so I figured I might as well build something.

With that in mind, I created an app centered around a business diary.
(It’s just a sample app for learning purposes, though.)

Also, I recently learned about requirements definition, design, and technical writing in internal training, so I practiced those as well.

Therefore, in this article I’ll mainly introduce how I organized the requirements definition through design using the business diary app as a case study. I hope to share the process, not the quality of the design, for engineers like me who are building an app. Note that I will omit the actual implemented app here and publish it in a separate article.

• First, our goal this time is to develop only the minimum necessary features for an app that creates business diaries.
• Since I mentioned in my previous blog that I create business diaries using Slack, this time I’ll try building a Slack app (the technical elements will be detailed below).
• Development will proceed in the following steps.
  1. Requirements Definition
  2. Design
  3. Implementation & Testing (details omitted in this blog)

• This is the main focus of the article, and it’s a bit lengthy, but I’d appreciate it if you could follow along 😓
• In requirements definition, we’ll proceed in the order of requests → demands → requirements → specifications.

First, requests are the things we want the system (in this case, the app) to achieve. For now, let’s jot down everything that the business diary app might be able to do.

Next, demands are the subset of requests chosen for implementation. This time, we’ll select only the minimum necessary requests for the business diary app as demands. Therefore, the demands are as follows.

Items 1–4 seem fine. Items 5 and 6 feel a bit redundant, but let’s accept them for now. Registration and persistence usually go together, so we might merge them later.

Here are the requests we won’t include as demands.

Next, let’s define the requirements based on the demands above. Requirements specify what the completed system must achieve.

Finally, let’s define the specifications. Specifications are a comprehensive description of the requirements.

2-2-1. Architectural Design

Here I describe the overall design policy of the app. Since this is the design phase, I will include specific technology elements.

2-2-2. Functional Design

We’ll merge specifications 5 and 6 (persistence of tasks and diaries) into functions 1 and 4 respectively. As a result, we have four main functions to describe.

As part of the design practice, I also created diagrams.

2-3-1. Use Case Diagram

2-3-2. Domain Model

2-3-4. Robustness Diagram

I created the app, so here I’ll only show the results.
Note: I plan to cover the app itself in another article.

First, register a task by sending the /task_add command with the task details as an argument.

If registration succeeds, a message is returned.

Next, display the registered tasks with the /task_list command. This command takes no arguments.

The list is displayed in registration order. The status is shown as a select box for updating, with an update button.

I registered three tasks for testing.

Now let’s change statuses. Change one of the three tasks to In Progress and another to Completed.

When you change the status and click the update button, the status updates and a message is returned.

Finally, generate the diary with the /businessDiary_create command.

After acknowledging the command, the generated diary appears. The list of tasks performed today shows tasks In Progress or Completed. The list of tasks planned for tomorrow shows tasks Not Started or In Progress.

In this article, I went through requirements definition, design, and implementation using a business diary as the theme. This is a personal learning exercise, but I hope it helps others struggling with design while building apps.

My impressions after actually working on this are as follows:

• Since this was extracurricular, I took some shortcuts here and there, but even setting that aside, there are still many shortcomings. I hope exercises like this help improve my skills.
• Also, even for a sample app like this, going through requirements definition and design became quite substantial in volume.
• However, the app development itself felt fairly smooth, so I believe the requirements definition and design process is not a waste.
• Previously, when I used low-code tools, I often skipped design due to the tool’s philosophy that “generated artifacts (code) = design document.” However, working through the process of design → implementation like this, even without low-code, I feel that planning out the design before coding makes development more efficient. I believe this is because documenting the design in advance leads to a better understanding of the specifications than trial-and-error during implementation.

I plan to extend the business diary app with additional features as I learn more technologies. I also hope to publish separate articles on the technical elements I’ve adopted.