BotTalk: Gathering requirements for our LLM-powered Telegram Chat Bot

Part II of the series where I chronicle the journey of building BotTalk.

Building on the motivation and vision articulated in our first entry, we now turn to a more granular level of planning. In the world of software development, the foundation of a successful project is a clear and comprehensive understanding of its requirements. These requirements can broadly be categorised into Functional and Non-functional. But what do these terms mean, and why are they pivotal?

Functional vs. Non-Functional Requirements: A Brief Primer

Functional requirements pertain to the essential functions a system must execute. Think of them as the definitive list of features or services a system needs to provide. They answer the "what" of a system — what tasks it should perform, what its input/output behaviour should be, and the interactions it must support.

On the other hand, Non-functional requirements, detail how these functions are realised, focusing on system behaviour and quality. They're often the attributes that users expect by default, such as reliability, security, and performance. In essence, they address the "how" — how fast, how secure, how scalable, and so on.

Together, these requirements give us a 360-degree view of what we aim to achieve and set the stage for future phases of our software development journey.

Now, let's cover the Functional Requirements of BotTalk

---

Functional Requirements of BotTalk

In the context of BotTalk, there are a couple key components that would drive the motivation for creating such a service. Of course, that would mean comparing it to the most prevalent chat assistant service right now: ChatGPT.

Dissecting the UI gives us an idea of how BotTalk could enhance its use-case.

In the context of ChatGPT, conversations with the model are organised in threads, sorted by date on the left side. As for opening new chats, ChatGPT gives an option to select the preferred model above, while maintaining contexts per conversation within each tab and even providing suggestions for prompts.

Taking inspiration from ChatGPT then gives us some understanding of the user requirements for a chat bot like BotTalk. These include:

1. Initialisation & Individual Usage:

   • The bot should initialise in a one-on-one chat setting, primarily recording user details.
   • Users should be able to select the LLM model they prefer from a provided list. We're initially focusing on OpenAI's models, but a future iteration might allow user-driven customisation. This choice ensures users have control over the conversational quality and style, fostering a sense of familiarity and empowerment.
   • Users should dictate the level of context retrieval, graded on a scale from 1-10. This permits dynamic adaptability, tailoring conversations to the desired depth and relevance.
   • To ensure quality, only one prompt will be answered at a time. Over-zealous prompters will be kindly asked to pace their inquiries.

2. Group Integration:

   • Bot should effortlessly integrate into group chats, answering based on the collective context offered by the group's members.
   • Unregistered users must engage with the bot privately before group chat participation.

3. Monetisation & Subscription:

   • Users will operate on a token-based system, reflective of their usage.
   • Users will be able to track their usage thus far.

4. Input Sanitation And Moderation:

   • Inputs by users will be monitored and checked for hateful language, mirroring ChatGPT's input sanitation mechanism

These user requirements give a reasonable road map for the project, and allows for extendibility such as the use and deployment of models that is fine tuned on the collection of prompts stored by BotTalk.

Next, let's take a look at some of the non-functional requirements of BotTalk

---

Non-functional Requirements of BotTalk

Examining some of the network connections and requests also gives us an idea of some of the system choices and non-functional requirements taken in mind while building ChatGPT, which we could use towards the development of BotTalk.

This is the network request of a prompt that requests an implementation of a distributed queue system.

First, we see that the return content-type of the sent GET request is in fact an event stream. The model's response is streamed to the client to provide a better user experience, allowing the user to feel like the user is having a conversation with the model in real time. On top of that, while the entire content of the response in fact took 45 seconds to complete downloading, the server response only takes 2 seconds, even with millions of users around the world. This gives us an idea of the non-functional requirements that BotTalk should adopt:

1. Scalability: BotTalk should be built to cater to thousands of users globally. As the user base grows, the bot's architecture should gracefully handle the increased load.

2. Low Latency: In the world of chatbots, speed is paramount. Our bot aims for real-time communication, offering quick, concise, and pertinent responses.

3. Security: Conversations are personal. Our bot should ensure data integrity and prevent users from accessing other people's interaction histories. While ChatGPT achieves this with individual conversation threads with the user, we should be limiting the context to only the chat the user participates in with the bot. For example, if the user participates in 2 groups with the bot enabled Chat A and Chat B, user should not be able to get responses with the context for Chat A while participating in Chat B.

With the functional and non-functional requirements in mind, let's generate user-stories, partitioned by phases. This allows for strategic, incremental development and testing. Breaking it down phase-by-phase ensures that each part of the project is validated before moving on to the next, minimising potential issues, as well as a road map for product release.

---

User Stories

User stories are informal, general explanations of a software feature written from the perspective of the end user, which often follow a format of "As a [type of user], I want [an action] so that [a benefit/a value]". I have divided the user stories up into 4 phases,

1. Initial Setup and Single-User Interaction,
2. Group Integration,
3. Monetisation and Credit System, and
4. Sanitation and Moderation

At the end of each phase or iteration, I expect to have completed the user stories and have a working version of the bot that has completed the phase's user stories and maintained the status of previous phases's completed work.

Phase 1: Initial Setup and Single-User Interaction

1. As an alpha user, I want to initiate the bot in a private chat so that I can have personalized interactions.
2. As a new user, I want the bot to record and recognize my details so that my interactions are personalized.
3. As a user, I want to choose from available GPT models so that I can tailor the chat experience.
4. As an advanced user, I want the option to fine-tune or select advanced models in the future so that I can continuously improve the chat experience.
5. As a user, I want to set a context sensitivity level so that my chat reflects the depth of conversation history I desire.
6. As a user, I want to be sure my chats are isolated so that my interactions are not influenced by other users' interactions.
7. As a user, I want to receive a response for each of my prompts so that I feel the bot is attentive and interactive.
8. As a user, I want the bot to inform me if I'm sending prompts too quickly so that I can adjust my interaction speed.
9. As a user, I want to view my usage statistics so that I can understand my interaction patterns with the bot.

Phase 2: Group Integration

1. As a group admin, I want to add the bot to my group chat so that multiple users can interact with it.
2. As a group member, I want the bot to consider all user inputs so that it provides relevant group context in its responses.
3. As a new group member, I want the bot to prompt me for registration so that I can also participate in group interactions.
4. As a group admin, I want to ensure only fellow admins can control the bot so that its functionalities aren't misused.

Phase 3: Monetization and Credit System

1. As a user, I want to know about my available credits so that I can manage my usage.
2. As a user, I want to purchase additional credits so that I can continue using the bot extensively.
3. As a super admin, I want to grant certain users unlimited access so that they can have uninterrupted interactions for promotional or testing purposes.
4. As a user, I want my credits to be used uniformly across different chats so that I don't have to manage multiple balances.

Phase 4: Input Moderation

1. As a responsible developer, I want to ensure that users are not misusing the chat bot by sending inappropriate prompts, which could possibly influence the set of prompts collected by the users.

---

With our requirements in place, our next step is to take this blueprint and begin crafting our chatbot. The journey of BotTalk is only getting started, and there's much more ground to cover. I hope you'll continue to join me as we embark on this meticulous journey, watching an idea mature through each SDLC phase.

Thank you and see you in the next article!