Portfolio project · design decisions
Why this tool is small on purpose
Business Analysts spend hours turning raw meeting notes into structured documentation. It is slow, inconsistent between people, and easy to get wrong. AmadursInsight does one step of that job: notes in, a linked first-draft requirements document out.
What it produces
Eight artifact types, because together they cover the “what, why, and how do we prove it” of early analysis: business goals stated in the notes, requirements (classified as functional, non-functional, business rule, or constraint), conflicts — contradictions the notes (or an optional pasted backlog/ticket list) surface, each with a recommended resolution rather than a silent pick, user stories for each functional requirement, acceptance criteria in Given/When/Then form, and risks, assumptions, and open questions so the gaps in the notes are named rather than filled in.
What the app does, and what the model does
A language model does the extraction — pattern-matching cannot pull requirements out of messy prose. The app’s contribution is the structure it imposes: the artifact types, the required formats, and the instruction to surface gaps and contradictions instead of inventing detail or picking a side. The change-impact step is the opposite — fully deterministic. Links between requirement, story, and criterion are captured at generation; editing a requirement walks that graph and flags every affected item for review. No model call is involved. Nothing here ships to a backlog on its own — every item is a draft the human reviews, edits, and exports by hand.
What it deliberately leaves out
- Accounts, login, and any server-side storage.
- Multi-user collaboration, comments, approvals.
- PDF and Word export — Markdown only, copied or downloaded.
- Diagram generation, a multi-project dashboard, version history.
The one concession: your current draft is kept in this browser (never on a server) so a refresh doesn’t lose it. “Start over” clears it. That is a convenience, not the version history above.
Each of the excluded items is a project in its own right. Naming the boundary is part of the point: the skill on show is scoping a real problem down to something shippable.
What would come next
A stakeholder-analysis / RACI step from the same notes; requirement versioning with a diff view; and traceability extended down to test cases — the part existing tools handle worst.