System Requirements Document for skripsi-manajemen-keuangan

1. Introduction

skripsi-manajemen-keuangan is a research-planning product for an Indonesian undergraduate (Masitah Hartini) who must compose a financial-management thesis (skripsi) on a topic that has never been used before, and who must back that topic with research data taken from the Indonesia Stock Exchange (Bursa Efek Indonesia, BEI).

The product intent is narrow and source-derived:

• Help the student arrive at an original thesis topic for a financial-management course — one that "tidak pernah orang pakek" (nobody has used).
• Anchor that topic in BEI-sourced research data, so the topic is not just novel but defensible with real market evidence.

The audience is a single active human actor: the financial-management thesis student. The product is a first-party web application with its own identity, its own topic workspace, and its own BEI data-collection workspace. It is not a thesis-writing tool, not a plagiarism checker, and not a market-data terminal.

2. System Overview

The current delivery is a first-party web application with application-owned identity and custom UI. It provides:

• An anonymous public entry (Landing) that states the product's promise: find a financial-management thesis title that has never been used, with data from the Indonesia Stock Exchange.
• Self-service enrollment (Sign Up) and returning verification (Login) so that the student's selected topics and collected BEI data persist and can be resumed.
• A protected Topics workspace where the student finds and evaluates candidate financial-management thesis topics for originality and for compatibility with BEI data.
• A protected Data Collection workspace where the student collects and organizes BEI research data for the selected thesis topic.

Actors. The only active human actor is Mahasiswa Peneliti Skripsi Manajemen Keuangan. BEI is an external data source, not a persona and not a first-party surface.

Ownership. All five destinations are application-owned custom pages. Identity is application-owned. BEI data is externally owned by the Indonesia Stock Exchange; the application consumes and organizes it, it does not publish or replace it.

Narrow exclusions. The product does not write the thesis, does not run statistical analysis, does not submit to a university, does not check plagiarism against a global corpus, and does not provide trading, brokerage, or investment-advice functionality. No capability beyond topic originality evaluation and BEI data collection is in scope.

2a. Product Interpretation and Delivery Boundary

The student's work has two halves that the product must keep distinct and connected. The first half is originality: a thesis topic is only acceptable if it has not been used before, so the product must let the student search, inspect, and judge candidate topics against that standard, and must make the originality verdict visible as a first-class fact rather than a footnote. The second half is evidence: the chosen topic must be supported by data taken from BEI, so the product must let the student collect and organize BEI data against the selected topic.

Delivery is a first-party web application. The public entry is anonymous and explains the product. Because the student's topic selections and collected BEI data are durable, actor-specific research state that must be resumed across sessions, the application owns identity: enrollment is self-service and returning verification is required before the protected workspaces. The protected workspaces are Topics and Data Collection; the entry surfaces Landing, Sign Up, and Login are anonymously reachable, and protected state remains unavailable until identity is established.

BEI is an external owner. The application does not own BEI's market data, does not guarantee its completeness, and does not act as an official BEI channel. Everything the product does with BEI data is collection and organization on the student's behalf.

Nothing in this document is deferred to a future horizon; all accepted requirements are current.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source, so no verified factual inventory is reproduced here. BEI is named by the user as the origin of the student's research data; the application does not embed a fixed BEI dataset, and no BEI figures, tickers, or period values are asserted as authoritative content by this document.

2c. Page Content and Component Coverage

Landing

• Information / state. Anonymous public entry. States the product's promise in a full-bleed stacked headline: find a financial-management thesis title that has never been used. States the data origin in a full-width band: data from the Indonesia Stock Exchange. No personalized or protected state is shown.
• Primary action. Begin the search for a topic — the primary call to action that leads into the identity boundary (enrollment or returning verification) before any protected work.
• Supporting actions. Navigate to returning verification for a student who already has an account.
• Domain entities. Thesis topic (as promise, not as data), BEI as data origin, originality as the product's core standard.
• Component responsibilities. Full-bleed stacked display headline; a solid colour block behind the keyword that carries the originality claim; a full-width band carrying the BEI data-origin line; the primary call-to-action control; a rotated originality stamp; a thin top rule carrying a moving row of BEI ticker codes and thesis keywords.
• States. Loading: not applicable — the entry is static content. Empty: not applicable. Success: the student reads the promise and the BEI data-origin line and activates the primary call to action. Error: if the primary call to action cannot proceed, the student is told plainly and can retry or use the returning-verification link. Recovery: the entry remains fully readable and the call to action remains available after any failure.

Sign Up

• Information / state. Anonymous enrollment surface. Explains that an account is what makes selected topics and collected BEI data persist and resumable.
• Primary action. Create the student's account with the required identity details.
• Supporting actions. Move to returning verification if the student already has an account.
• Domain entities. Student identity, credential, the durable research state that enrollment protects.
• Component responsibilities. Enrollment form with labelled fields; inline validation messaging; submit control; link to returning verification.
• States. Loading: submit control shows in-progress state while the account is being created. Empty: the form is presented with empty fields and no error text. Success: the account is created and the student proceeds into the protected workspaces. Error: missing or invalid fields are identified next to the field; a taken or rejected identity is stated plainly. Recovery: entered values are preserved so the student corrects only what failed and resubmits.

Login

• Information / state. Anonymous returning-verification surface. Explains that verification restores the student's selected topics and collected BEI data.
• Primary action. Verify the returning student's identity.
• Supporting actions. Move to enrollment if the student does not yet have an account.
• Domain entities. Student identity, credential, the resumed topic and BEI data state.
• Component responsibilities. Verification form with labelled fields; inline error messaging; submit control; link to enrollment.
• States. Loading: submit control shows in-progress state during verification. Empty: the form is presented with empty fields and no error text. Success: the student is verified and returned to the protected work they were resuming. Error: incorrect credentials are stated plainly without revealing which part was wrong. Recovery: the student can correct and retry, or move to enrollment; no protected state is exposed on failure.

Topics

• Information / state. Protected workspace for finding and evaluating original financial-management thesis topics compatible with BEI data. Presents candidate topics as a dense index, each with its title, an originality indicator, and BEI sector tags. Shows which topic is currently selected.
• Primary action. Select a topic as the thesis topic, which makes it the subject of the BEI data collection work.
• Supporting actions. Search and filter candidate topics; inspect a topic's originality indicator and BEI sector tags; compare candidates before committing; revisit and change the selected topic.
• Domain entities. Thesis topic (title, originality indicator, BEI sector tags, selection state), BEI sector, the student's selection.
• Component responsibilities. Topic index rows (title, originality block, sector chips); search and filter controls; originality indicator with its high-originality stamp; selection control and selected-state marking; empty and no-match messaging.
• States. Loading: the topic index shows a loading state while candidates are retrieved. Empty: when no candidate topics are available, the workspace states that plainly and offers the search/filter controls as the next step. Success: the student selects a topic and the selection is visibly marked and carried into data collection. Error: if candidates cannot be retrieved, the failure is stated and a retry is offered. Recovery: the previously selected topic, if any, remains intact and visible after a failed retrieval.

Data Collection

• Information / state. Protected workspace for collecting and organizing BEI research data for the selected thesis topic. Presents the selected topic as context, a ledger of collected BEI data rows keyed by ticker code, and the active reporting period.
• Primary action. Add a BEI data entry to the collection for the selected topic.
• Supporting actions. Organize entries by ticker code and reporting period; set or change the active reporting period; review and correct previously collected entries; remove an entry that does not belong.
• Domain entities. Selected thesis topic, BEI ticker code, reporting period, collected data values, entry status.
• Component responsibilities. Selected-topic context header; ticker-code column; tabular data sheet with hairline rows and tabular numerals; active-period band; status chips; add/edit/remove controls; empty and error messaging.
• States. Loading: the ledger shows a loading state while collected data is retrieved. Empty: when no data has been collected yet, the workspace states that plainly and points to adding the first BEI entry for the selected topic. Success: an entry is added and appears in the ledger under its ticker code and period, with the active period clearly marked. Error: an entry that cannot be saved is reported with its offending field identified, and the entered values are preserved. Recovery: the student corrects and resaves, or discards the entry; existing collected data is never lost by a failed add. If no topic has been selected, the workspace states that a topic must be selected first and points back to the topic workspace.

3. Functional Requirements

FR-1 — Original thesis topic for financial-management coursework (explicit) As a Mahasiswa Peneliti Skripsi Manajemen Keuangan, I should be able to work toward a financial-management thesis topic that has never been used by anyone else, so that my skripsi satisfies the originality requirement of the course.

• Trigger / input: The student begins topic work in the protected topic workspace.
• Observable result: Candidate topics are presented with an explicit originality indicator, and the student can select one as the thesis topic.
• Access state: Requires established identity; the topic workspace is protected.
• Failure / recovery: If candidates cannot be retrieved, the failure is stated and a retry is offered; any previously selected topic remains intact.
• Continuation: The selected topic becomes the subject of BEI data collection.

FR-2 — Evaluate a candidate topic's originality before committing (explicit) As a Mahasiswa Peneliti Skripsi Manajemen Keuangan, I should be able to see how original each candidate topic is before I commit to it, so that I do not build a thesis on a topic that has already been used.

• Trigger / input: The student inspects a candidate topic in the topic index.
• Observable result: The topic's originality indicator is visible on the topic itself, and topics judged highly original are marked with a distinct originality stamp.
• Access state: Requires established identity.
• Failure / recovery: If the originality indicator is unavailable for a topic, that is stated rather than shown as a false verdict.
• Continuation: The student either selects the topic or continues evaluating other candidates.

FR-3 — Find candidate topics compatible with BEI data (explicit) As a Mahasiswa Peneliti Skripsi Manajemen Keuangan, I should be able to search and filter candidate topics by their BEI sector tags, so that I only consider topics I can actually support with BEI data.

• Trigger / input: The student enters search terms or applies sector filters in the topic workspace.
• Observable result: The topic index narrows to matching candidates, each still showing its originality indicator and BEI sector tags.
• Access state: Requires established identity.
• Failure / recovery: If no candidate matches, the workspace states that plainly and the student can clear or change the filters.
• Continuation: The student selects a topic from the narrowed set.

FR-4 — Select the thesis topic (explicit) As a Mahasiswa Peneliti Skripsi Manajemen Keuangan, I should be able to select one candidate as my thesis topic, so that my subsequent data work is bound to a single, definite subject.

• Trigger / input: The student activates the selection control on a candidate topic.
• Observable result: The topic is marked as selected and is carried into the data-collection workspace as the active subject.
• Access state: Requires established identity.
• Failure / recovery: If the selection cannot be saved, the failure is stated and the previous selection, if any, is preserved.
• Continuation: The student proceeds to collect BEI data for the selected topic, or returns to change the selection.

FR-5 — Collect BEI research data for the selected topic (explicit) As a Mahasiswa Peneliti Skripsi Manajemen Keuangan, I should be able to collect research data sourced from BEI for my selected thesis topic, so that my topic is backed by real Indonesian capital-market evidence.

• Trigger / input: The student adds a BEI data entry in the data-collection workspace, with the selected topic as context.
• Observable result: The entry appears in the ledger under its ticker code and reporting period, and the active period is clearly marked.
• Access state: Requires established identity; the data-collection workspace is protected.
• Failure / recovery: If an entry cannot be saved, the offending field is identified and the entered values are preserved so the student can correct and resave; existing collected data is never lost.
• Continuation: The student continues adding entries, organizes them by ticker and period, or returns to the topic workspace.

FR-6 — Organize collected BEI data by ticker code and reporting period (explicit) As a Mahasiswa Peneliti Skripsi Manajemen Keuangan, I should be able to organize my collected BEI data by ticker code and reporting period, so that the data is ready for analysis rather than a loose pile of figures.

• Trigger / input: The student assigns or changes the ticker code and reporting period of a collected entry, and sets the active reporting period.
• Observable result: Entries are grouped and readable by ticker code and period, with the active period marked by a distinct period band.
• Access state: Requires established identity.
• Failure / recovery: If a period or ticker value is rejected, the entry is reported with the offending field identified and the entered values preserved.
• Continuation: The student reviews the organized ledger or adds further entries.

FR-7 — Review and correct collected BEI data (explicit) As a Mahasiswa Peneliti Skripsi Manajemen Keuangan, I should be able to review and correct the BEI data I have collected, so that what I carry into analysis is accurate.

• Trigger / input: The student opens a collected entry and edits or removes it.
• Observable result: The corrected entry is reflected in the ledger, or the removed entry no longer appears.
• Access state: Requires established identity.
• Failure / recovery: If a correction cannot be saved, the failure is stated and the prior value remains in place.
• Continuation: The student continues collecting or moves on to analysis outside the product.

FR-8 — Self-service enrollment before durable research work (required_inference) As a Mahasiswa Peneliti Skripsi Manajemen Keuangan, I should be able to create my own account before starting durable research work, so that my selected topics and collected BEI data belong to me and persist.

• Trigger / input: The student activates the primary call to action on the public entry and completes the enrollment form.
• Observable result: An account is created and the student enters the protected workspaces.
• Access state: The enrollment surface is anonymously reachable; protected state remains unavailable until enrollment completes.
• Failure / recovery: Invalid or rejected details are identified next to the field, entered values are preserved, and the student can correct and resubmit.
• Continuation: The student proceeds to find a topic.

FR-9 — Returning verification to resume topics and BEI data (required_inference) As a Mahasiswa Peneliti Skripsi Manajemen Keuangan, I should be able to verify my identity when I return, so that I resume the topics I selected and the BEI data I collected instead of starting over.

• Trigger / input: The returning student submits their credentials on the verification surface.
• Observable result: The student is verified and returned to the protected work they were resuming, with their selected topic and collected BEI data intact.
• Access state: The verification surface is anonymously reachable; protected state is not exposed before verification succeeds.
• Failure / recovery: Incorrect credentials are stated plainly without revealing which part was wrong, and the student can retry or move to enrollment.
• Continuation: The student resumes topic work or data collection.

FR-10 — Understand the product and its BEI data origin before committing (explicit) As a Mahasiswa Peneliti Skripsi Manajemen Keuangan, I should be able to understand, before signing up, that this product helps me find an unused financial-management thesis title and that the data comes from the Indonesia Stock Exchange, so that I know the product matches my assignment.

• Trigger / input: The student arrives at the public entry.
• Observable result: The entry states the originality promise and the BEI data origin, and offers the primary call to action.
• Access state: Anonymous; no protected state is shown.
• Failure / recovery: If the call to action cannot proceed, the failure is stated plainly and the entry remains usable.
• Continuation: The student proceeds to enrollment or to returning verification.

4. User Personas

Mahasiswa Peneliti Skripsi Manajemen Keuangan

Product context. An Indonesian undergraduate taking a financial-management course who must produce a skripsi — a thesis — and who has been told, in effect, that the topic must be one nobody has used before. The student's data source is fixed by the assignment: the Indonesia Stock Exchange (BEI). The student is therefore working under two simultaneous constraints that pull against each other — novelty and evidence — and the product exists to hold both at once.

Primary goal. Arrive at an original financial-management thesis topic that has never been used, backed by BEI data that is collected and organized well enough to be analyzed.

Distinct accepted responsibilities.

• Judge candidate topics for originality, not merely for interest — the student is the one who must decide that a topic clears the "belum pernah dipakai" bar.
• Judge candidate topics for BEI-data compatibility, because a novel topic with no BEI data behind it is useless for this assignment.
• Commit to exactly one topic, accepting that the commitment determines what data must be collected.
• Collect BEI data against that committed topic, keyed by ticker code and reporting period.
• Review and correct the collected data so that what is carried into analysis is trustworthy.

Relevant inputs and decisions. Search terms and BEI sector filters; the originality indicator on each candidate; the BEI sector tags attached to each candidate; the decision to select a topic; the ticker code, reporting period, and values of each BEI entry; the decision to correct or remove an entry.

Interactions with other accepted participants. The student is the only active human actor. BEI is an external data source the student draws from; it is not a participant that acts within the product. There is no supervisor, reviewer, or collaborator role in the accepted scope.

Observable success. A single topic is marked as selected and visibly carries a high-originality verdict; the data-collection workspace shows that topic as context with a ledger of BEI entries organized by ticker code and reporting period, with the active period marked.

What makes this role's work different. The student's work is not "using a study app." It is defending a claim. Every candidate topic must survive a negative test — that nobody has used it — before it is allowed to become the subject of any work, and every figure collected afterward exists only to support that one claim. The role's difficulty is that originality and evidence are evaluated in different places and must be reconciled by the student alone.

5. Core User Flows

Flow A — Discover the product and enter (Mahasiswa Peneliti Skripsi Manajemen Keuangan)

1. The student arrives at Landing anonymously, with no account and no prior state.
2. The student reads the full-bleed headline stating the promise — a financial-management thesis title that has never been used — and the band stating that the data comes from the Indonesia Stock Exchange.
3. The student activates the primary call to action, "begin searching for a topic."
4. Because the topic workspace is protected, the student is taken to the identity boundary rather than into protected state.
5. Continuation: the student enrolls (Flow B) or verifies as a returning student (Flow C).

Flow B — Enroll for the first time (Mahasiswa Peneliti Skripsi Manajemen Keuangan)

1. From the identity boundary, the student arrives at Sign Up anonymously.
2. The student reads that an account is what makes selected topics and collected BEI data persist and resumable.
3. The student fills in the enrollment form and submits it.
4. Observable result: the account is created and the student enters the protected workspaces.
5. Failure / recovery: if a field is missing or invalid, or the identity is rejected, the problem is identified next to the field, the entered values are preserved, and the student corrects only what failed and resubmits.
6. Continuation: the student proceeds to Flow D to find a topic.

Flow C — Return and resume (Mahasiswa Peneliti Skripsi Manajemen Keuangan)

1. A student who has already enrolled returns and arrives at Login anonymously.
2. The student reads that verification restores their selected topics and collected BEI data.
3. The student submits their credentials.
4. Observable result: the student is verified and returned to the protected work they were resuming, with their selected topic and collected BEI data intact.
5. Failure / recovery: incorrect credentials are stated plainly without revealing which part was wrong; no protected state is exposed. The student retries, or moves to enrollment if they do not have an account.
6. Continuation: the student resumes at Flow D or Flow E, whichever they were doing.

Flow D — Find, evaluate, and commit to an original topic (Mahasiswa Peneliti Skripsi Manajemen Keuangan)

1. The verified student enters the protected Topics workspace.
2. The topic index loads; if retrieval fails, the failure is stated and a retry is offered, and any previously selected topic remains intact.
3. The student searches and applies BEI sector filters to narrow the candidates to topics that BEI data can actually support.
4. Observable result: the index narrows to matching candidates, each still showing its originality indicator and BEI sector tags. If nothing matches, the workspace says so and the student clears or changes the filters.
5. The student inspects individual candidates, reading each topic's originality indicator; topics judged highly original carry a distinct originality stamp.
6. Decision: the student compares candidates and commits to one by activating the selection control.
7. Observable result: the topic is marked as selected and becomes the active subject carried into data collection.
8. Failure / recovery: if the selection cannot be saved, the failure is stated and the previous selection, if any, is preserved.
9. Continuation: the student proceeds to Flow E, or returns to step 3 to change the selection.

Flow E — Collect and organize BEI data for the selected topic (Mahasiswa Peneliti Skripsi Manajemen Keuangan)

1. The verified student enters the protected Data Collection workspace with a topic already selected.
2. The workspace shows the selected topic as context and loads the ledger of collected BEI data; if retrieval fails, the failure is stated and a retry is offered.
3. If no data has been collected yet, the workspace states that plainly and points to adding the first BEI entry.
4. The student adds a BEI data entry for the selected topic, supplying its ticker code, reporting period, and values.
5. Observable result: the entry appears in the ledger under its ticker code and period, and the active reporting period is clearly marked.
6. Failure / recovery: if the entry cannot be saved, the offending field is identified and the entered values are preserved; the student corrects and resaves, or discards the entry. Existing collected data is never lost by a failed add.
7. The student repeats step 4 to build up the data set, and sets or changes the active reporting period as needed.
8. Observable result: entries are grouped and readable by ticker code and period, with the active period marked.
9. The student reviews a collected entry and corrects or removes it; the correction is reflected in the ledger, or the removed entry no longer appears. If a correction cannot be saved, the failure is stated and the prior value remains in place.
10. Continuation: the student continues collecting, returns to Flow D to change the selected topic, or carries the organized BEI data into analysis outside the product.

Flow F — Recover when no topic has been selected (Mahasiswa Peneliti Skripsi Manajemen Keuangan)

1. The verified student enters Data Collection without having selected a topic.
2. The workspace states that a topic must be selected first and points back to the topic workspace.
3. The student follows that pointer to Topics and completes Flow D.
4. Continuation: the student returns to Data Collection, which now shows the selected topic as context and accepts BEI entries.

6. Visuals Colors and Theme

Muse: Paula Scher. Headline: "Typography as architecture for a thesis that has never been written."

The register is intellectual ambition under deadline pressure: a research poster wall, not a study app. Originality is treated as a public act — a claim set large and defended with evidence — and BEI tickers, ratios, and period ranges become colour-blocked data bands rather than generic cards.

Colour tokens (light mode).

Ratio approximately 60% paper, 25% ink type, 10% red, 5% yellow/teal. No gradients anywhere — every colour is a flat field with a hard edge. Blue and indigo are forbidden as primary or accent in any form.

Typography.

• Headings: Anton. Poster scale, uppercase, line-height: 0.98, tracking -0.01em for stacked display lines and +0.06em for label-size all-caps. Headlines are set as blocks that fill their column edge to edge. Weight contrast is achieved by size and colour, never by bolding Archivo. Anton is never used below 20px and never for body copy.
• Body: Archivo. 16–18px, line-height: 1.6, tabular numerals enabled for all financial figures.
• Scale (1.4 modular, mobile → desktop): display 44 / 64 / 96 / 128px via clamp(); h1 32 / 48 / 64px; h2 24 / 32 / 40px; label 12 / 13px all-caps tracked; body 16 / 17 / 18px; data 20 / 28px tabular.

Shape language. Hard edges only. Zero border radius on cards, buttons, and inputs. 3px solid ink rules as section dividers and 1px hairlines inside tables. Diagonal bands at 8 degrees cut across section transitions. Buttons are ink or red rectangles with uppercase labels sitting flush against a rule. Stamps and badges are rotated 3–6 degrees with a 3px ink outline and no shadow. Nothing floats: every element is anchored to a rule or a colour block.

Layout. A 12-column poster grid with a visible left rule at column 1 on desktop, collapsing to 4 columns at 768px and a single column at 375px. Landing opens with a full-bleed stacked headline spanning the viewport, then a red band, then a three-column evidence row. Topics is a dense poster index: each topic is a row of a grid, not a card, with the title in Anton, a yellow originality block, and BEI sector tags as flat colour chips. Data Collection is a ruled ledger: a fixed left column of ticker codes, a tabular sheet with hairline rows on the right, and a red horizontal band marking the current period. Section transitions are full-width colour-block wipes between paper, red, and ink.

Imagery. Typography is the imagery. No stock photography of students, no laptop mockups. Visual material is oversized stacked type compositions, flat colour blocks, ruled ledger sheets rendered as real UI, halftone-treated IDX sector index charts in ink-on-paper, and rotated rubber-stamp marks ("ORISINIL", "BEI 2020–2024", "BELUM DIPAKAI"). Charts are drawn as thick black strokes on paper, never as gradient-filled area charts. One high-contrast cut-out photograph of an IDX annual report page may be used as a full-bleed band.

Readable text and controls. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control. Moving and scrollable content may cross the viewport or container edge by design and is judged by whether it actually moves or scrolls and whether every item becomes fully readable as it passes.

7. Signature Design Concept

The Unused-Title Poster.

The public entry is a printed poster, not a SaaS hero. A nine-column Anton headline is stacked in four lines — "TEMUKAN JUDUL SKRIPSI MANAJEMEN KEUANGAN YANG BELUM PERNAH DIPAKAI" — set at clamp(44px, 9vw, 128px), flush left against the paper ground #F2EBDD. The word BELUM is knocked out in red #E01B2E as a solid block behind white type, so the originality claim is not a sentence but a physical fact in the composition.

Beneath the headline, a full-width red band carries a single line of all-caps Archivo: "DATA DARI BURSA EFEK INDONESIA" — the BEI data origin stated as a structural band, not a footnote. The primary call to action is a black rectangle labelled "MULAI CARI TOPIK", pinned to the bottom-left of the red band, with a small rotated yellow stamp "ORISINIL" overlapping the band's right edge. A thin ink rule runs the full viewport width above the headline, carrying a slow marquee of BEI ticker codes.

There is no centred stack, no subtext paragraph, no illustration, and no gradient. The composition reads as a poster because it is built the way a poster is built: one claim, set large, anchored to rules and colour blocks.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: flat

Landing Hero Motion Brief.

• Focal subject. The stacked Anton headline itself — specifically the word BELUM inside its solid red block — with the red BEI band and the black call-to-action rectangle as the composed counterweights.
• Input → transformation → outcome thesis. As the entry loads, the headline words snap in from below in a staggered sequence with no easing overshoot, so the claim assembles itself word by word; the red band then wipes across the section boundary as a hard panel rather than fading in; the outcome is a fully composed poster in which the originality claim and the BEI data-origin line are both legible and the call to action is available.
• Motion vocabulary. Staggered word reveals with no overshoot; colour-block wipes that slide a red or ink panel across a section boundary; a slow marquee of BEI ticker codes and thesis keywords running along the top rule; hover states that invert a whole row to ink-on-yellow instantly. No bounces, no floating, no parallax on type.
• Composed first frame. The paper ground #F2EBDD fills the viewport; the thin ink rule with the ticker marquee sits at the top; the headline's first line is already visible; the red band and the black call-to-action rectangle are in place at the bottom. Nothing is mid-animation in a way that hides the claim or the control.
• Reduced-motion state. The marquee becomes a wrapped static row of chips; wipes become instant swaps; word reveals become plain visibility. The poster composition, the BEI band, and the call to action remain fully readable and operable.

9. Non-Functional Requirements

• NFR-1 — Originality is a first-class, visible fact. (explicit) Every candidate topic must present its originality indicator on the topic itself, and highly original topics must carry a distinct stamp. Rationale: the user's core requirement is a topic that has never been used; a verdict the student cannot see does not satisfy it.
• NFR-2 — BEI is the stated and only data origin. (explicit) The product must state, on the public entry and in the data-collection workspace, that research data comes from the Indonesia Stock Exchange. Rationale: the user fixed BEI as the data source.
• NFR-3 — BEI data is externally owned. (explicit) The application consumes and organizes BEI data on the student's behalf; it does not claim to be an official BEI channel, does not guarantee BEI data completeness, and does not publish BEI data as its own. Rationale: BEI is an external owner, not a first-party capability.
• NFR-4 — Durable, actor-bound research state. (required_inference) Selected topics and collected BEI data must persist and remain bound to the correct student across sessions. Rationale: without this, the accepted journeys of resuming topics and BEI data are not executable.
• NFR-5 — Protected state is never exposed before verification. (required_inference) The topic and data-collection workspaces must not render protected state to an unverified visitor, and a failed verification must not leak which credential component was wrong. Rationale: the accepted identity boundary must be truthful.
• NFR-6 — No data loss on failure. (required_inference) A failed save of a topic selection or a BEI entry must preserve the student's entered values and must not damage previously stored research state. Rationale: the student's collected BEI data is the evidence base of the thesis and cannot be silently lost.
• NFR-7 — Readable text and controls at every viewport. (explicit) Headlines, labels, numbers, and controls must remain entirely inside the viewport and their container at 375px, 768px, and 1280px, and no element may cover them. Rationale: stated in the creative direction and required for the product to be usable on the student's devices.
• NFR-8 — Reduced-motion support. (explicit) Under prefers-reduced-motion, the ticker marquee must become a wrapped static row of chips, wipes must become instant swaps, and reveals must become plain visibility, with all content still readable. Rationale: stated in the creative direction.
• NFR-9 — Flat colour discipline. (explicit) No gradients, no border radius above 0, no soft drop shadows, and no blue or indigo as primary or accent. Rationale: stated in the creative direction as a hard visual constraint.

10. Tech Stack

• Frontend: React (web), single-page application with client-side routing across the five destinations.
• Backend: Python with FastAPI, exposing the topic and BEI data-collection endpoints and the identity endpoints.
• Storage: A relational database for student identity, selected topics, and collected BEI data entries (keyed by ticker code and reporting period).
• Containerization: Docker with docker-compose for local and single-host deployment.
• Kubernetes: Not required. The accepted scope is a single-student research-planning application with no stated scaling or multi-tenant deployment requirement.
• Typography delivery: Anton and Archivo web fonts, loaded for the heading and body roles defined in Section 6.

11. Assumptions and Constraints

Constraints (binding).

• C-1 (explicit) Thesis topics must be ones that have never been used by anyone else — originality is a hard requirement, not a preference.
• C-2 (explicit) Research data must be sourced from BEI (Bursa Efek Indonesia).
• C-3 (explicit) The product serves a financial-management course skripsi; it is not a general research tool.
• C-4 (explicit) The visual constraints in Section 6 are binding: flat colour fields only, zero border radius, no gradients, no blue or indigo as primary or accent, Anton never below 20px and never for body copy.

Assumptions (narrow, labeled).

• A-1 (required_inference) The student has access to BEI data through ordinary public means; the product does not provision BEI credentials or a privileged BEI feed.
• A-2 (required_inference) The originality indicator reflects the product's own evaluation of whether a topic has been used; the product does not claim to search a complete global corpus of every thesis ever written, and the indicator is presented as a verdict on the topic rather than as a guarantee of universal novelty.
• A-3 (required_inference) One student owns one body of research state — one selected topic at a time, with its associated BEI data collection.
• A-4 (required_inference) Identity is application-owned and self-service; there is no institutional provisioning, no invitation flow, and no administrator role in the accepted scope.
• A-5 (required_inference) The student carries the organized BEI data out of the product for analysis; the product does not perform the analysis.

Explicit exclusions.

• No thesis-writing, drafting, or formatting capability.
• No statistical or financial analysis capability.
• No plagiarism checking against an external corpus.
• No submission, supervisor, or reviewer workflow.
• No trading, brokerage, or investment-advice functionality.
• No additional personas beyond the single accepted student role.

12. Glossary

• BEI / IDX — Bursa Efek Indonesia, the Indonesia Stock Exchange. The mandated source of the student's research data. An external owner, not a persona.
• Skripsi — The undergraduate thesis required for the student's degree; here, specifically for a financial-management course.
• Topik orisinal — A thesis topic that has never been used by anyone else. The product's core acceptance standard.
• Originality indicator — The visible verdict attached to a candidate topic stating how original it is; highly original topics carry a distinct stamp.
• BEI sector tag — A flat colour chip attached to a candidate topic indicating the BEI sector its data would come from, used to filter topics by data compatibility.
• Ticker code — The BEI-listed instrument identifier under which a collected data entry is organized.
• Reporting period — The financial period a collected BEI entry belongs to; the currently active period is marked by a distinct period band.
• Ledger — The ruled, tabular presentation of collected BEI data in the data-collection workspace, with a fixed ticker-code column and hairline rows.
• Selected topic — The single candidate topic the student has committed to, which becomes the active subject of BEI data collection.
• Protected workspace — A destination that requires established identity: Topics and Data Collection.
• Anonymous entry surface — A destination reachable without identity: Landing, Sign Up, and Login.