Repository navigation
Entrega 1
David Guerra Morales edited this page Aug 12, 2026
·
2 revisions
Ristoquia is an independent software product (standalone) for personal financial management. It is not a component of a larger enterprise system; it is the complete system.
The product is built with Django, exposed as a web service (REST API). This architectural decision is intentional: the backend decouples business logic from the presentation layer so that, in a first phase, it can be consumed by a web client, and in later phases by a mobile application without needing to rewrite server logic.
- a) System interfaces: Ristoquia does not depend on any external enterprise system to operate. It is the main system.
- b) User interfaces: Responsive web interface (browser) in the first version; native/hybrid mobile client in future versions, both consuming the same REST API.
- c) Hardware interfaces: Does not require specialized hardware. The client requires a device (computer or smartphone) with a web browser or compatible mobile operating system.
- d) Software interfaces: Django backend (Django REST Framework to expose the API); relational database MySQL as the persistence engine via Django's ORM; external email reading services (IMAP API / Gmail API) for automatic transaction capture (HU-01).
- e) Communications interfaces: Client-server communication via HTTPS/REST (JSON); mailbox access via IMAP protocol or email provider API for reading banking notifications.
- f) Memory: No special restrictions; governed by the standard limits of the server/infrastructure where it is deployed.
- g) Operations: The service must operate continuously (24/7), as automatic transaction capture (HU-01) depends on timely reading of incoming messages.
- h) Site adaptation requirements: None; deployed as SaaS in the cloud, without site-specific installation for the client.
Ristoquia allows a person to centralize and automate control of their personal finances:
- Automatic capture of transactions from SMS/banking emails.
- Manual expense logging.
- Automatic and manual categorization of transactions.
- Management of multiple accounts (debit, credit, cash) and their balances.
- Definition of budgets per category with alerts when limit is exceeded.
- Registration of recurring subscriptions with reminder before charge.
- Graphical visualization of income vs. expenses (dashboard).
- Definition and tracking of savings goals.
- Generation of automated monthly financial feedback.
- User authentication and home screen for expense consultation.
- Natural persons interested in organizing their personal finances, without requiring prior accounting or financial knowledge.
- Users with basic digital literacy: regular use of web/mobile applications and email.
- Spanish speakers (interface and notifications in Spanish).
- No technical experience assumed; users should not interpret raw data (SMS/emails), the system does it for them.
- a) Regulatory policies: The system handles personal financial data, so it must comply with Law 1581 of 2012 (Habeas Data, Colombia) on personal data protection.
- b) Hardware limitations: None beyond a device with a browser or standard mobile operating system.
- c) Interfaces to other applications: Automatic capture depends on permissions and availability of the email/SMS provider's API; these integrations are subject to third-party policies.
- d) Parallel operation: Not applicable; does not replace a legacy system.
- e) Audit functions: The system must log each automatically generated transaction, indicating the source (SMS/email) for traceability.
- f) Control functions: Validation of funds before applying an expense (HU-04); recalculation of budget consumption percentage (HU-03).
- g) Signal handshake protocols: Not applicable.
- h) Quality requirements: Automatic capture by regular expressions must minimize false positives/negatives when interpreting banking messages.
- i) Criticality of the application: Medium — not a mission-critical system, but handles sensitive financial and personal data.
- j) Safety and security considerations: The system must not store banking passwords or PINs; data in transit and at rest must be protected (HTTPS, encryption of email access credentials).
- k) Physical/mental considerations: Not applicable.
- Project backlog user stories: https://github.com/Eder-Ceballos/P1/issues (HU-01 to HU-10)
- ISO/IEC/IEEE 29148:2011 — Requirements specification template.
- Mazo & Jaramillo, Towards a new template for the specification of requirements in semi-structured natural language.
- Problem to solve: people do not have centralized visibility of their financial transactions because they are dispersed across different accounts and channels (SMS, banking emails, cash), making it difficult to control expenses, meet budgets, and achieve savings goals.
Identification: FR (functional), UR (usability), DBR (logical database), CR (constraints).
Origin: HU-01 — Automatic transaction capture
- FR01. The system shall use regular expressions to process incoming SMS content in order to extract banking transaction data.
- FR02. The system shall use regular expressions to process incoming banking emails in order to extract transaction data.
- FR03. The system shall automatically generate and save a transaction record when a match is validated in an SMS or email.
- FR04. The system shall update the balance of the linked account immediately after recording an automatically captured transaction.
Origin: HU-02 — Transaction categorization
- FR05. The system shall allow automatic assignment of a category to a transaction based on predefined rules.
- FR06. The system shall allow the user to manually assign or reassign the category of a transaction.
- FR07. The system shall allow the user to consult total accumulated expenses filtered by category.
- FR08. The system shall allow the user to consult total accumulated expenses filtered by a date range (start and end date).
Origin: HU-03 — Budget configuration and alerts
- FR09. The system shall allow the user to create a budget by defining a limit amount for a specific category.
- FR10. The system shall recalculate the percentage of budget consumed each time a new transaction is recorded in the associated category.
- FR11. The system shall send a notification to the user at the moment budget consumption reaches or exceeds 100% of the established limit.
Origin: HU-04 — Management of bank accounts and balances
- FR12. The system shall allow the user to register multiple accounts by indicating name, type, and current balance.
- FR13. The system shall validate fund availability in an account before applying an expense transaction.
Origin: HU-05 — Advance subscription reminder
- FR14. The system shall allow the user to register a subscription by indicating service name, amount, and monthly charge date.
- FR15. The system shall automatically calculate days remaining until the next subscription charge date.
- FR16. The system shall send a notification N days before the scheduled charge date of a subscription.
Origin: HU-06 — Graphical statistics visualization
- FR17. The system shall display a dashboard with charts grouping expenses by category.
- FR18. The system shall dynamically update dashboard charts according to the time period selected by the user.
- FR19. The system shall display comparative indicators of income versus expenses for the selected period.
Origin: HU-07 — Tracking of financial goals
- FR20. The system shall allow the user to define a savings goal with a target amount.
- FR21. The system shall calculate and graphically display progress percentage toward the savings goal based on current savings.
Origin: HU-08 — Monthly financial feedback
- FR22. The system shall consolidate all transactions and budgets of the period at the end of each month.
- FR23. The system shall generate an automatic monthly report indicating whether budgets were met and suggesting recommendations based on consumption.
Origin: HU-09 — Manual expense logging
- FR24. The system shall allow the user to manually create an expense record.
- FR25. The system shall allow the user to assign the account associated with a manually created expense.
Origin: HU-10 — Minimal graphical interface
- FR26. The system shall allow a registered user to authenticate using credentials (login).
- FR27. The system shall display a home screen with the user's expenses.
- FR28. The system shall allow the user to create a transaction from the home screen.
(Total: 28 functional requirements — exceeds the minimum of 20 requested.)
- UR01. A new user shall be able to complete manual logging of an expense in a maximum of 3 steps.
- UR02. The user shall be able to consult the current balance of all their accounts in a single screen, without additional navigation.
- UR03. At least 90% of users evaluated in usability tests shall be able to create a budget without external assistance.
- UR04. The system shall present error messages in Spanish, with understandable language requiring no technical knowledge.
- UR05. The dashboard shall render category charts in a maximum of 2 seconds under normal network conditions.
- UR06. A new user shall be able to complete the account registration process in an average maximum of 2 minutes.
(Total: 6 — exceeds the minimum of 5 requested.)
- DBR01. The system shall store each transaction with, at minimum: amount, date, category, associated account, and origin (manual or automatic).
- DBR02. The system shall maintain a one-to-many relationship between User and Accounts.
- DBR03. The system shall maintain a one-to-many relationship between Account and Transactions.
- DBR04. The system shall guarantee referential integrity such that no Transaction can exist without an associated Account and Category.
- DBR05. The system shall preserve transaction history for at least 12 months to allow generation of monthly and historical reports.
- DBR06. The system shall store each subscription with service name, amount, charge date, and associated account.
(Total: 6 — exceeds the minimum of 5 requested.)
- CR01. The system shall be implemented using Django as backend, exposing its functionality through a REST API consumable by a web client and, in later phases, by a mobile application.
- CR02. The system shall comply with Law 1581 of 2012 (Habeas Data, Colombia) for the treatment of personal financial data.
- CR03. The system shall not store user banking passwords or PINs.
- CR04. Business logic shall be kept decoupled from the presentation layer (API-first architecture) to support multiple clients (web and mobile) without duplicating business rules.
- CR05. The system shall use MySQL as the relational database engine.
-
CR06.
[TEAM: confirm deployment/hosting provider]