What is Function Design?
Function design is the process of defining the functions, features, and workflows/operations of software. This process requires BAs to analyze client requirements, identify problems and solutions before proposing necessary functions/features. Function design typically occurs in the early stages of a project or when there are new requests from clients.
Within the scope of this article, I won't be revisiting the requirement gathering process. You can refer to it here [link to your relevant post]. To begin, you should identify the objects in the system before defining and designing the corresponding functions.
What is an Object?
Objects in BA analysis can be divided into two types: Business Objects and System Objects:
Business objects are identified during the process of understanding the client's business. These objects reflect real-world business entities such as products, sales orders, invoices, request forms, etc.
System objects are generated during the software development process to support information management and processing, such as master data and login accounts.
How to Identify Objects
The simplest way to identify objects is to answer the question "What." Of course, how you ask the question is also crucial; simply asking "what" won't always get you an answer.
First, whenever you start a new business flow or even analyze existing software, besides gathering and analyzing requirements (which I mentioned I won't be covering here), you need to identify the main object of that business flow:
Ask the question: "What is being mentioned or interacted with the most by users in this flow?"
The workflow of a business process usually revolves around a main object. For example, the purchasing flow revolves around the "Sales Order."
In some cases, you might be influenced or misled by the solution, leading to getting "lost" when identifying objects. In this situation, when you start to struggle with finding/identifying objects for the feature/module/solution you've proposed, go back to the "problem."
Example:
In my April class, one group identified the main topic of their assignment as "Time Management" after applying the Double Diamond model to find and solve a problem. However, they got stuck at the object identification stage. I asked them what problem led them to choose time management. Their answer stemmed from experiencing schedule delays or forgetting tasks. At this point, they answered the "What" question themselves. Their "What" was "work" or "tasks."
Therefore, the main object in this case was "Task" in general. Other objects would emerge as they analyzed the functions related to "Task."
Designing System Functions
This is the stage where you need to apply your BA analytical skills to analyze various aspects of the object. In my course, I introduce two techniques – CRUD and I/O Flow – both of which are used/needed in this step.
With CRUD:
You analyze based on the four basic use cases of an object: Create, Read, Update, and Delete.
Using CRUD, you'll at least identify four basic functions as mentioned above. Additionally, there will be derived functions from these basic functions that you can analyze, such as import (create multiple), view list (read multiple), search/filter (derived from view list), etc.
With the Time Management case study mentioned above, the "Task" object could include functions like:
C: Create a new task, upload an attachment.
R: View task details, view task list, search/filter tasks.
U: Update task.
D: Delete a task, delete multiple tasks.
With I/O Flow:
This technique is based on analyzing the input and output of an object.
When using I/O Flow, besides identifying object functions, you can also clarify information about the attributes of an object. For example, what are the inputs for a task? Title, content, assignee, deadline, etc.
For output questions, I often use phrases like: "After... what happens?" or "Where is the information/data processed after... and who processes it next?"
I usually use this technique in conjunction with CRUD for better results.
Example:
C: What are the inputs for creating a new task? What needs to be done after a task is created? (Send a notification to the user so they can accept the task assigned by someone else, run a reminder when the deadline approaches...) --> notification function, notification object, reminder function, accept/reject task function.
R: What are the inputs for viewing task information? (The task must exist.) What can people do with the task after viewing it? (For assigned users, they might transfer the task, confirm completion, cancel...) --> Task assignment function, task completion function, task cancellation function...
By applying these two techniques together and continuously asking and answering questions, you can build features more comprehensively.
Points to Note When Designing System Functions:
Applying analytical methods like the ones above can easily lead to functional duplication. Therefore, when you analyze a function, establish naming conventions to easily check for duplicates when you have the list.
Additionally, during the analysis process, you'll likely encounter other objects that emerge alongside the main object. For example, in the example above, the "notification" object appeared. At this point, don't rush to analyze the new object immediately. Instead, mark it down, make a note of it somewhere, and return to it after completing the current object (task). This helps prevent the analysis process from becoming scattered.
After you have the list of analyzed functions, you need to re-evaluate them to ensure they address the client's problems or serve the proposed solution.
Finally, neatly present the list of functions by object and confirm with stakeholders before proceeding with detailed implementation.
Comments