[Product] 👀: REBuild Ireland: 1️⃣ Product Definition | 2️⃣ Specifications

[ai-avengers-team]

Rebuild Ireland: Product Definition & Specifications

Status & Keys

^{Document: Draft✏️ | Prepared | Reviewable | Accepted}

^{Changes: 🔉: To Discuss ➕ Add context | ✏️ Edit, Update | ➖ Remove | ✅ Approved | ❌ Rejected}

- `Content reuse is the name`
- This is a deliverable
- Collective for all Product

^{N.B: Nav Links in GitHub Issue main bodies are not functional.}

Table of Contents

• [Product Definition]()
  1. [Concept]()
  2. [Objectives and Goals]()
  3. [Problem Statement]()
  4. [Value Proposition]()
• [Specification]()
  1. [Product Requirements (Functional)]()
  2. [Product Requirements (Non-Functional)]()
  3. [Epics: Hackathon Demo]()
  4. [Features]()
  5. [UX Flow and Design Notes]()
  6. [System and Environment Requirements]()
  7. [Assumptions, Constraints and Dependencies]()

^{Next | Bottom}

Product Definition

TABLE OF CONTENT

1. [Concept]()
   1. [Pitch One Liner]()
   2. [Full Description]()
2. [Objectives and Goals]()
3. [Problem Statement]()
4. [Value Proposition]()

🔎 Help

Concept

🔎 Help

If you can write a short and sharp summary, then use a LLM to assist and get team to review.

Pitch One Liner (30 Seconds | Elevator)

🔉➕

Full Description

🔉➕

Objectives and Goals

🔉➕

Value Proposition

🔉➕

---

---

Specifications

🔉➕

^{Prev | Next Bottom}

TABLE OF CONTENTS

1. [Product Requirements (Functional)]()
2. [Product Requirements (Non-Functional)]()
3. [Epics: Hackathon Demo]()
4. [Features]()
5. [UX Flow and Design Notes]()
6. [System and Environment Requirements]()
7. [Assumptions, Constraints and Dependencies]()

Product Requirements (Functional)

🔎 Help

Itemise the use cases and desired functionality. Describing each feature and or capability as a separate item, with a use case per item. Keeping to highest level, and or using checklists approach, this is a summary collective issue of many references from team and individual workflow tickets.

---

To be ⤵️ Reviewed By:  

Key:  🔉: To Discuss  ➕ Add context | ✏️ Edit, Update | ➖ Remove

Release Capabilities

As a team, we want to release the following, for a demonstrable solution/idea: 🔉➕

• .
• .
• .
• .

Release Overview

🔎 Help

For our specific release, which is a fully functional demo of a proof of concept for our chosen solution, we aim to specify what we aim to achieve with this demo. i.e what does our release look like?

• .
• .
• .

Product Requirements (Non-Functional)

🔎 Help

What are the top level actual non-functional and/or quality attributes of the demo application? Itemise the use case and quality attribute. Describe each quality as a separate item, inc a brief use case. Keeping to highest level, and or using a checklist approach, this is a summary collection of my references from the team and individual workflow tickets.

🔉➕

• [ ] .
• [ ] .
• [ ] .
• [ ] .
• [ ] .
• [ ] .
• [ ] .
• [ ] .
• [ ] .

Epics: Hackathon Demo

🔎 Help

A well-written epic is a key to have a good understanding and material to refer in case of any doubts during the development work. It helps in avoiding a lot of conflicts and misunderstanding.

🔉 It is very useful to collaborate when developing your Epic.

Epic Template:

Main elements include the user, the product and design requirement, expressed as a story that encapsulates the future state. ``` For: {whom} Who: {what to achieve} Our: {title of project | demo} Is a: {what utility} That: {list benefits, or short form acceptance criteria} ```

EPIC: ReBuild Ireland's Derlicit Housing Engine (Search & Answers) 🔉➕

For:    REBuild Ireland and general public
Who:    ..
Our:    {title of project | demo}
Is a:   {what utility}
That:   {list benefits, or short form acceptance criteria}

Features

🔎 Help

For each feature, you should include a description, goal and use case at a minimum. Additional details may be helpful or necessary depending on the complexity of the feature, such as out-of-scope items

^{Prev | Next TopBottom}

Table of Major Features as Functionality

We have two functional features.

1. Labelled Data for Derlicit or Vacant Housing
2. ChatBot

Feature Template

A feature should contain a short descriptor of the item of value, a description of the benefit of the feature, and the acceptance criteria ((the points of quality or completion the feature must achieve)

Feature:
Benefit:
User Acceptance Criteria: 

Hackathon Features should

• provide business | demo | judge-able value, i.e. meet the criteria listed below.
  • ai-avenger-teams/rebuild-ireland-frontend#46
• Should 
  • be estimable | minimally viable 
  • be testable 
  • be deployable
  • be acceptable
  • be functional

---

To be ⤵️ Reviewed By: @stephendawsondev @jhoanTrujillo @iPoetDev 

Key:  🔉: To Discuss  ➕ Add context | ✏️ Edit, Update | ➖ Remove

---

Feature: Labelled Data for Derelict or Vacant Housing

DESCRIPTION: {provide a brief overview of the dataset, including its purpose and relevance to the LLM training process.} 🔉➕

GOAL: To be able to use labeled data that is off sufficient quality, consistency and reliability to be transformable by a LLM and to be discoverable, queryable and retrieveable by a user and usable by them.

Feature Story

FEATURE: {__} 🔉➕  BENEFIT: {__} 🔉➕  ACCEPTANCE CRITERIA: {__} 🔉➕ 

Sources 🔉➕ 

The sources of this data are: ^{List each record source of data, bullets}

• Source Author|Org Name (Date of Publishing) "Title". Last Access (Date of Access): {Data Source URL}
• Source Author|Org Name (Date of Publishing) "Title". Last Access (Date of Access): {Data Source URL}

^{Ensure each data source is credible and properly documented, including authorship, publication date, and access details.}

Users, Buyers, Partners, Stakeholders, Trainers, Data Subjects 🔉➕ 

The following actors are key principles for this data set. Refer to the team AI Innovation Business Canvas.

• Users: Individuals or entities who will interact with the dataset.
  • {Individuals, entities, organisations}🔉➕
• Buyers: Those who may purchase or invest in the dataset.
  • {purchasers, investors} 🔉➕
• Partners: Suppliers and data controllers involved in the dataset lifecycle.
  • {suppliers, data controller} 🔉➕
• Stakeholders: Interested parties, such as RACIS (Responsible, Accountable, Consulted, Informed, Supporting) roles.
  • {RACIS interested parties}, overlaps ⬆️⬇️
• Trainers/Operators: Individuals responsible for operating and training the model.
  • {Model operators, developers} 🔉➕
• Data Subjects: Individuals whose data is included in the dataset t or who will generate new insights from their input.
  • {data subjects, personal identifiers} 🔉➕

Use Case 🔉➕ 

:

System and Environment Requirements \ ^{Edit | Update\} @stephendawsondev, @jhoanTrujillo 

Outline bullets or per line, tooling like Vertex and its components, like AutoML. 

Hardware, software, platform, manage services, secrets, service accounts, API used, etc

1st party🔉➕ 

For purpose of hackathon: GCP will be first party for clarity and disambiguation.

3rd party: 🔉➕ 

• Libraries, e.g. streamlit, that directly touch/transform the data, o
  • Steamlit
  • DataHorse (https://github.com/DeDolphins/DataHorse)
  • SDK/Libraries

Quality & Other Requirements 🔉➕ 

• Methods:
  • {data collection} : How did we collect? 🔉➕
  • {data augmentation}: to enhance the dataset with additional relevant information to improve model training. 🔉➕
  • {formating}, How formats and transformations did we do? 🔉➕
  • {data preprocessing} : What data cleansing, missing values, duplicates, normalisations, alias for same values, 🔉➕
  • {exploratory data analysis}: Can we explain, and interpret the data without using an intermediate LLM. Human in the loop. 🔉➕
  • {training}: How | workflow of training, minimum requirements 🔉➕
  • {prompting}: How we defined our prompts 🔉➕
  • {model specialisation}: Foundational model to a specialised train model steps? 🔉➕
  • {fine-tuning}: iterations and other hyperparameters to set/vary. 🔉➕
  • {performance and evaluations} 🔉➕
• Consistency & Labelling
  • Ensure data is consistently labelled and categorized.
  • Use of data schemas as structured output and input: {json, yaml, csv}
  • Itemise schema {schema} 🔉➕
• Legality:
  • Compliance 🔉➕
    • GDPR: Data Sources, data controllers obligations, and data processors obligations, automated processing, etc 🔉➕
  • Public Sources 🔉➕
  • Licencing of data 🔉➕
• Ethics (Five Pillars). 
  See [wiki for definitions](https://github.com/ai-avenger-teams/rebuild-ireland-backend/wiki/AI-Ethics).
  • Fairness: Ensure unbiased data representation.
  • Robustness: Maintain data integrity and reliability.
  • Explainability: Facilitate understanding of data transformations.
  • Transparency: Provide clear documentation and access protocols.
  • Privacy: Protect sensitive information and adhere to privacy laws.

---

To be ⤵️ Reviewed By: @jhoanTrujillo @iPoetDev @stephendawsondev @DarrachBarneveld @violaberg  

Key:  🔉: To Discuss  ➕ Add context | ✏️ Edit, Update | ➖ Remove

---

---

Feature: LLM Chatbot

DESCRIPTION: 🔉➕  GOAL: 🔉 ➕ 

Feature Story

FEATURE: {__} 🔉➕  BENEFIT: {__} 🔉➕  ACCEPTANCE CRITERIA: {__} 🔉➕ 

Users, Partners Stakeholders, Trainers, Data Subjects: 🔉

• Users: Individuals or entities who will interact with the chatbot / LLM provider .
  • {Individuals, entities, organisations} 🔉➕
• Partners: Suppliers and data controllers involved in the chatbot / LLM provider .
  • {suppliers, data controller} 🔉➕
• Stakeholders: Interested parties, such as RACIS (Responsible, Accountable, Consulted, Informed, Supporting) roles.
  • {RACIS interested parties}, overlaps ⬆️⬇️ 🔉➕
• Trainers/Operators: Individuals responsible for operating and training the chatbot / LLM provider .
  • {Model operators, developers} 🔉➕
• Data Subjects: Individuals whose data is included in the chatbot inputs | processes | outputs or who will generate new insights from their input.
  • {data subjects, personal identifiers} 🔉➕

Use Case 🔉➕ 

:

System & Environment Requirements 🔉➕ 

🔎 Help

- Outline bullets or per line, language, framework like Python, React, Django, and there critical components. - Frameworks, platform, manage services, automations, secrets, service accounts, API used, etc

1st party 🔉➕ 

3rd party 🔉➕ 

Quality Requirements 🔉➕

These are auto generated AND can be dropped or remove from discussion.

🔎 Help

For a demo app of an embedded GenAI chatbot using Django and React, especially in the context of a hackathon, it's crucial to focus on a few key non-functional requirements that ensure quality and performance. Here are the top quality aspects to consider

1. Performance:
   1. Response Time: The chatbot should have a quick response time, ideally under 2 seconds, to maintain user engagement. 🔉➕➖
   2. Scalability: The system should be able to handle a reasonable number of concurrent users typical for a demo, without significant degradation in performance. 🔉➕➖
2. Usability:
   1. User Interface: The chatbot interface should be intuitive and easy to use, ensuring that users can interact with it without confusion. 🔉➕➖
   2. Accessibility: Ensure that the chatbot is accessible to users with disabilities, adhering to basic web accessibility standards. 🔉➕➖
3. Reliability:
   1. Availability: The chatbot should be available and functional during the entire duration of the hackathon. 🔉➕➖
   2. Error Handling: Implement basic error handling to manage unexpected inputs or system failures gracefully. 🔉➕➖
4. Security:
   1. Data Protection: Ensure that any user data processed by the chatbot is handled securely, even if minimal, to protect user privacy.🔉➕➖
   2. Authentication: If applicable, implement a simple authentication mechanism to restrict access to authorized users only. 🔉➕➖
5. Maintainability:
   1. Code Quality: Write clean, well-documented code to facilitate any quick changes or debugging during the hackathon. 🔉➕➖
   2. Modularity: Design the system in a modular fashion to allow easy updates or feature addition. 🔉➕➖

Any Other Comments 🔉➕ 

Add below or open for discussion

UX Flow and Design Notes 🔉➕➖

🔎 Help

1. The UX design of features after the PRD has been reviewed and accepted.
2. To have general guidance required/set at this stage to ensure the release objectives are met. 3. To describe the overall user workflow and design work of the team.

User Experience and User Flow 🔉➕

• User journey
• User Stories
• User Acceptance Testing

Design: User Interface 🔉➕

Wireframes 🔉➕

Fonts 🔉➕

Colours 🔉➕

Accessibility 🔉➕

Interactivity 🔉➕

Visual Features 🔉➕

Screenshots if applicable 🔉➕

System and Environment Requirements 🔉➕

🔎 Help

Which end-user environments will be supported (such as browsers, operating systems, memory, and processing power, API, platforms, Low Code solutions, etc.).
Above, the system and environment requirements are attached per feature. Below, we aggregated these and include any system level diagrams. (Auto/LLM generated). Options: C4 and or Mermaid Charts for flow charts.

---

Architectural 🔉➕

Using the C4 Model (@iPoetDev ✅) we can produce a system design diagram.

Overall 🔉➕

Frontend 🔉➕

Backend 🔉➕

Data 🔉➕

Deployment 🔉➕

---

Technical Specifications (Minimum to Get Started) 🔉➕

Itemise the technical spec used for the demo AND for development processes

DEMO 🔉➕

Development 🔉➕

---

:

Assumptions, Constraints and Dependencies

🔎 Help

List out what is expected of users, any limits for the implementation to be aware of and any outside elements required for the final solution to be functional.

Assumptions 🔉➕

List the guess and what we don't know or can't know at this stage

---

Guesses 🔉➕

Don't Know 🔉➕

---

Constraints

List the self imposed decisions or technical or data or scope constraints here. Constraints in designing systems are critical to shaping the system.

---

Choices | ADRs 🔉➕

Summary of key team and solution choices that define our solution and its implementation.

• .

---

Technical 🔉➕

• We were given, by the organisers, access to OpenAI API keys for 7 days and had to abide by National AI Challenge's terms of service

---

Data 🔉➕

• . 

---

Scope 🔉➕

• E.g. We decided for only focusing on Cork Local Government authorities and derelict homes in Co Cork, Ireland.
• We decided if we needed to increase out scope of data collection, we would move from County level to Provence level, if there was insufficient data and county level data has to be augmented e.g. Cork => Munster region. 
• .
• .
• .

---

Rights & Licences🔉➕

• By participating we opt to retain ownership of their projects.
• However, by participating, we grant TechIreland, Enterprise Ireland and Data2Sustain EDIH a non-exclusive, royalty-free licence to use, distribute, and display your project for promotional purposes.

---

:

Acknowledgement

^{Next | Top}

Credits

Sources

• 1 productplan.com  "Product Requirements Document". Last Accessed: Aug 2024. https://www.productplan.com/glossary/product-requirements-document/
• 2 .
• 3 .
• 4 . 

Changelog

Edits and additions to the issue

Date1	Version	Changed By	Change	Action
2024-08-26	0.1	Charles J Fowler	Initial version created	Create
2024-08-26	0.2	@ai-avengers-team	Added 🔎 Help & moved supporting text to foldable sections	Update
Cell	Cell	Cell	Cell	Cell

¹: YYYY-MM-DD

[ai-avengers-team]

Cleaned up the document from v0.1 and move quote support text to right aligned 🔎 Help that is a folded text block.

Improves readability.