{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihukg4y34noeuizlerswbc3rhs7pj6cid43jio2mwyvnjloko4h6q",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mnccgs3phjp2"
  },
  "path": "/t/creating-a-new-app-for-making-brd/176419#post_2",
  "publishedAt": "2026-06-02T08:05:57.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "Docling",
    "Docling docs",
    "RAGFlow",
    "RAGFlow docs",
    "Dify",
    "n8n",
    "SpecifAI",
    "Jama Connect Advisor",
    "Ragas",
    "RAGAS paper",
    "GitHub Spec Kit",
    "Spec-driven development post",
    "Ragas faithfulness",
    "OWASP Top 10 for LLM Applications",
    "OWASP GenAI prompt injection note",
    "MCP security best practices",
    "spec-driven development"
  ],
  "textContent": "For now, it looks like many relevant building blocks already exist, but there still seems to be plenty of room:\n\n* * *\n\nI think this is a strong idea, especially because you are focusing on **existing-process transformation** rather than generic document generation.\n\nA BRD is usually not hard because of the writing itself. It is hard because the source material is messy, incomplete, inconsistent, and full of implicit operational knowledge:\n\n  * meeting notes\n  * process maps\n  * SOPs\n  * current-state walkthroughs\n  * AHT / touch-time / volume metrics\n  * stakeholder comments\n  * old BRDs\n  * exception cases\n  * undocumented workarounds\n  * half-confirmed assumptions\n  * operational constraints that everyone “knows” but nobody wrote down\n\n\n\nSo I would avoid framing the product only as a **BRD generator**.\n\nI would frame it as a **requirements discovery workbench**.\n\nThe BRD can still be the final exported document, but the core product should be the structured requirements package behind it.\n\n## 1. Why I think the idea is promising\n\nThe strongest part of your idea is not “LLM writes a BRD”.\n\nThe strongest part is:\n\n> messy process-discovery artifacts → reviewable requirements, gaps, edge cases, and BRD sections\n\nThat is a much more valuable workflow.\n\nA plain LLM prompt can produce a polished document, but a real BRD needs more than polished prose. It needs:\n\nNeed | Why it matters\n---|---\nConfirmed business facts | Avoids turning guesses into requirements\nSource-backed requirements | Lets reviewers check where each requirement came from\nGap detection | Shows what is missing before stakeholders find it later\nEdge-case discovery | Prevents happy-path-only BRDs\nOperational metrics | Converts AHT, volume, SLA, rework, etc. into measurable requirements\nHuman review | Keeps SMEs / BAs / PMs accountable for final decisions\nTraceability | Connects source artifacts → requirements → tests / Jira / implementation\n\nSo the product boundary I would choose is:\n\n> A source-backed requirements discovery workbench for existing-process transformation.\n\nNot:\n\n> A better BRD writer.\n\n## 2. Many building blocks already exist\n\nThere are already useful pieces in the ecosystem. That is good news. It means this is technically feasible.\n\nBut those pieces mostly live at different layers.\n\nArea | Examples | What they solve | What they do not fully solve\n---|---|---|---\nDocument ingestion | Docling, Docling docs, Unstructured | Parse PDFs, Office files, OCR, layouts, tables, images, transcripts | Convert artifacts into requirement-level business facts\nRAG / knowledge layer | RAGFlow, RAGFlow docs, Dify, LlamaIndex | Retrieve relevant context from documents | Decide whether a chunk truly supports a requirement\nWorkflow automation | n8n, Flowise | Connect forms, files, LLM calls, docs, Jira, email, storage | Maintain requirement review state and evidence validity\nRequirements generation | SpecifAI, BRD/PRD generators | Generate BRD/PRD/NFR drafts | Handle process metrics, gaps, edge cases, and source-backed review as first-class objects\nRequirements quality / ALM | Jama Connect Advisor, Trace.Space, Visure | Analyze requirements, traceability, quality, compliance | Lightweight upstream discovery from messy process artifacts\nRAG evaluation | Ragas, RAGAS paper | Evaluate retrieval and generation quality | Evaluate BRD-specific coverage, gaps, NFRs, edge cases, and reviewer effort\nSpec-driven downstream | GitHub Spec Kit, Spec-driven development post | Move from specifications into AI-assisted implementation workflows | Discover and validate business requirements from messy upstream artifacts\n\nSo I do not think the gap is “there are no tools”.\n\nThe gap is more specific:\n\n> The missing layer is a requirements layer between document AI and ALM.\n\nIn other words, many systems can parse documents, retrieve chunks, run agents, or generate documents. Fewer systems turn messy discovery artifacts into **requirement objects** with evidence, gaps, assumptions, edge cases, metrics, and review state.\n\n## 3. The missing layer\n\nA useful product here should not be centered around `document -> LLM -> BRD`.\n\nIt should be centered around:\n\n\n    artifacts\n      -> business facts\n      -> process observations\n      -> requirement candidates\n      -> source evidence\n      -> gaps\n      -> edge cases\n      -> metric-derived requirements\n      -> human review\n      -> BRD / Jira / Confluence / tests / traceability matrix\n\n\nThe missing layer looks like this:\n\nMissing layer | Why it matters\n---|---\nRequirement-level evidence binding | A BRD reviewer needs to know which source artifact supports each requirement.\nGap ledger | The most useful output is often what is missing: SLA, owner, approval rule, exception path, volume assumption, data retention, etc.\nProcess-to-requirement conversion | A process map is not yet a requirement model. The system should convert process observations into FRs, NFRs, data requirements, integration requirements, and business rules.\nMetric-derived requirements | AHT, touch time, volume, SLA breach, rework rate, and exception rate should become requirements and business-case assumptions.\nReview-first workflow | Human BA/SME review should be a first-class product flow, not an afterthought.\nBRD-specific evaluation | General RAG metrics help, but BRD quality also needs coverage, grounding, gap quality, NFR coverage, edge-case coverage, and reviewer edit distance.\n\n## 4. Product framing\n\nI would describe the product this way:\n\n> A business analysis workbench that turns fragmented process discovery artifacts into source-backed requirements, gaps, edge cases, metrics, and BRD sections.\n\nThat framing is stronger than:\n\n> Upload docs and generate a BRD.\n\nBecause “generate a BRD” can sound like a generic LLM wrapper.\n\nThe more defensible product is the structured layer underneath the BRD.\n\nWeak framing | Stronger framing\n---|---\nAI BRD Generator | Requirements Discovery Workbench\nUpload documents, get BRD | Upload artifacts, get a reviewable requirements package\nPrompt engineering | Guided elicitation\nContext engineering | Evidence-bound requirement generation\nMemory engineering | Provenance-aware project and organization memory\nHarness engineering | BRD-specific evaluation and review loop\nBRD document | BRD as one export view of structured requirement objects\n\n## 5. Core internal objects\n\nI would make the internal model explicit.\n\nThe core objects should not only be documents and chunks. They should be requirement-oriented objects.\n\nObject | Purpose\n---|---\n`Artifact` | Uploaded source: meeting notes, SOP, process map, KPI table, transcript, old BRD\n`BusinessFact` | Atomic fact extracted from an artifact\n`ProcessStep` | Current-state or future-state process observation\n`RequirementCandidate` | Proposed functional / non-functional / data / reporting / integration requirement\n`Evidence` | Source excerpt or process-map reference supporting a requirement\n`Gap` | Missing information that blocks confident requirement writing\n`EdgeCase` | Exception path, failure path, unusual variant, fallback, escalation, override\n`Metric` | AHT, touch time, volume, SLA, error rate, rework rate, exception rate\n`Assumption` | A statement that may be useful but is not yet fully supported\n`ReviewDecision` | Accept, reject, edit, needs SME review, needs more evidence\n`TraceLink` | Source artifact → requirement → test case / Jira item / BRD section\n\nA useful requirement object might look like this:\n\n\n    {\n      \"id\": \"FR-014\",\n      \"type\": \"functional_requirement\",\n      \"text\": \"The system shall route exception cases to supervisor review.\",\n      \"source_evidence\": [\n        {\n          \"artifact_id\": \"meeting_notes_2026_05_20\",\n          \"excerpt\": \"Exceptions are currently reviewed manually by supervisors.\",\n          \"support_level\": \"partial\"\n        },\n        {\n          \"artifact_id\": \"current_process_map_v3\",\n          \"step\": \"Manual supervisor review\",\n          \"support_level\": \"strong\"\n        }\n      ],\n      \"confidence\": 0.74,\n      \"assumptions\": [\n        \"Exception cases are a distinct case category.\"\n      ],\n      \"open_questions\": [\n        \"What exactly qualifies as an exception?\",\n        \"Does the threshold differ by region or product?\"\n      ],\n      \"review_status\": \"needs_sme_review\"\n    }\n\n\nThis is the important shift.\n\nThe BRD is not just generated text. It is a view over structured requirement objects.\n\n## 6. How I would reinterpret your four engineering levers\n\nYour four levers make sense. I would operationalize them this way.\n\nOriginal lever | Practical version | What it should do\n---|---|---\nPrompt Engineering | Guided elicitation | Ask the right missing questions instead of relying only on free-form prompts\nAutomated Context Engineering | Evidence binding | Link each requirement to the artifacts that support it\nMemory Engineering | Provenance-aware memory | Reuse organizational patterns while preserving where each pattern came from\nHarness Engineering | BRD evaluation harness | Measure coverage, grounding, gaps, edge cases, and reviewer effort\n\n### Prompt Engineering → Guided elicitation\n\nInstead of only asking the user to provide a problem statement, I would build a structured elicitation flow.\n\nExample questions:\n\nQuestion | Reason\n---|---\nWhat is the current process? | Establish current state\nWhich roles are involved? | Find stakeholders and permissions\nWhich systems are touched? | Identify integration requirements\nWhat are the known exceptions? | Avoid happy-path-only BRDs\nWhat metrics exist? | Convert AHT, volume, SLA, rework into measurable requirements\nWhat is still unknown? | Create the gap ledger\nWhat is the desired future state? | Separate problem statement from solution assumption\n\n### Context Engineering → Evidence binding\n\nRAG is useful, but the important question is not only:\n\n> Did we retrieve relevant context?\n\nIt is:\n\n> Does this context actually support this requirement?\n\nRagas faithfulness is a useful conceptual reference: it checks whether generated claims are supported by retrieved context. For BRDs, I would apply that idea at the requirement level.\n\nRequirement | Evidence | Confidence | Open question\n---|---|---|---\nSystem shall route exception cases to supervisor review. | SOP step + workshop note | Medium | What qualifies as an exception?\nSystem shall reduce AHT from 12 min to 7 min. | KPI table + project objective | Low-Medium | Is 7 min a target or a hard SLA?\nSystem shall validate mandatory fields before submission. | Rework notes + SOP checklist | High | Which fields are mandatory by case type?\n\n### Memory Engineering → Provenance-aware memory\n\nMemory is useful, but I would avoid “the system remembers it, therefore it is true”.\n\nI would split memory into types:\n\nMemory type | Example | How to use it\n---|---|---\nProject memory | Decisions, unresolved questions, accepted assumptions | Use as current project state\nOrganization memory | Standard BRD template, terminology, approval conventions | Use as default structure\nPattern memory | Past requirement patterns from similar BRDs | Use as candidates, not facts\nRisk memory | Common missing NFRs and edge cases | Use as checklist\nReviewer memory | What reviewers often edit or reject | Use to improve drafts and evals\n\nEvery memory item should carry provenance:\n\n\n    memory_item\n      -> source BRD / template / meeting / reviewer decision\n      -> confidence\n      -> last reviewed date\n      -> applicable domain\n\n\n### Harness Engineering → BRD-specific evaluation\n\nThis is especially important.\n\nA polished BRD is not necessarily a good BRD. It can be clear, fluent, and still wrong.\n\nI would evaluate the system on BRD-specific metrics:\n\nMetric | What it measures\n---|---\nEvidence coverage | Percentage of requirements with usable source evidence\nUnsupported claim rate | Requirements or claims with weak/no source support\nRequirement coverage | Whether expected categories are covered\nNFR coverage | SLA, security, audit, availability, performance, data retention, observability\nEdge-case coverage | Exception flows, rework, cancellation, fallback, manual override, escalation\nGap quality | Whether open questions are specific and actionable\nMetric conversion quality | Whether AHT, volume, SLA breach, etc. become useful requirements\nReviewer edit distance | How much BA/SME editing is needed\nTime-to-review | How quickly a reviewer can validate the draft\nTraceability completeness | Source → requirement → test/ticket linkage\n\nGeneral RAG metrics from Ragas or the RAGAS paper are useful, but BRD quality needs extra domain-specific checks.\n\n## 7. Historical BRDs: use them, but not only for fine-tuning\n\nThe 100–200 historical BRDs are valuable.\n\nBut I would not use them only as fine-tuning data at the beginning.\n\nI would first use them for:\n\nUse historical BRDs for… | Why\n---|---\nRetrieval examples | Find similar past requirements and BRD sections\nTemplate mining | Extract organization-specific BRD structure\nRequirement pattern memory | Reuse common requirement patterns\nGap checklist | Detect common omissions from prior projects\nEvaluation set | Test whether the system produces useful BRD packages\nReviewer rubric | Learn what “good” looks like in your organization\nTerminology normalization | Align language with internal BA / PM / compliance conventions\n\nFine-tuning may become useful later, especially for style, extraction consistency, or organization-specific language.\n\nBut early on, I would prioritize:\n\n  1. structured schema\n  2. retrieval\n  3. evidence binding\n  4. review workflow\n  5. evaluation\n  6. then fine-tuning if the data supports it\n\n\n\n## 8. Suggested architecture\n\nI would avoid building everything from scratch.\n\nReuse commodity layers where possible, but build the requirements layer yourself.\n\nLayer | Responsibility | Build vs. reuse\n---|---|---\nArtifact ingestion | Parse PDFs, DOCX, PPTX, XLSX, transcripts, SOPs, process docs | Reuse tools like Docling or Unstructured where possible\nRetrieval layer | Retrieve relevant historical BRDs, SOPs, meeting notes, templates | Reuse RAGFlow, Dify, LlamaIndex, or a custom RAG stack\nRequirements core | Requirement objects, evidence, gaps, metrics, review state | Build this as the differentiated layer\nGap / edge-case engine | Detect missing information and likely exception paths | Build domain-specific logic + LLM checks\nReview UI | Accept, reject, edit, assign owner, check evidence | Build as first-class UX\nExport layer | BRD, traceability matrix, Jira, Azure DevOps, Confluence, Word, Markdown | Adapter-based\nEval harness | Measure grounding, coverage, unsupported claims, reviewer edits | Build BRD-specific metrics on top of general RAG eval ideas\n\nThe product should not depend on one parser, one model, one vector database, or one workflow tool.\n\nI would make it adapter-first:\n\n\n    core/\n      requirement_schema\n      evidence_model\n      gap_ledger\n      metric_mapping\n      review_state\n      traceability_model\n      eval_interface\n\n    adapters/\n      docling\n      unstructured\n      ragflow\n      dify\n      llamaindex\n      jira\n      azure_devops\n      confluence\n      sharepoint\n      google_drive\n      word_export\n      markdown_export\n\n\nThis matters because many organizations already have their own stack:\n\n  * SharePoint\n  * Confluence\n  * Jira\n  * Azure DevOps\n  * Box\n  * Google Drive\n  * internal document stores\n  * Azure OpenAI\n  * local LLM endpoints\n  * internal approval workflows\n\n\n\nA useful product should fit into that reality instead of forcing one universal stack.\n\n## 9. MVP scope\n\nI would keep the MVP narrow.\n\nDo not start with everything: video, BPMN, ALM replacement, Jira round-trip sync, fine-tuning, test generation, and full approval workflow.\n\nStart with a small but valuable workflow.\n\nInclude in MVP | Defer\n---|---\nMeeting notes | Full video understanding\nOne SOP or process description | Automatic BPMN generation\nOne process map if available | Full process mining\nOne metrics table: AHT, touch time, volume, SLA breach, rework rate | Full ALM replacement\nOne BRD template | Complex Jira round-trip sync\nOptional historical BRDs for retrieval | Fine-tuning as the first step\nRequirement candidates + evidence + gaps + edge cases | Fully automated final BRD approval\nMarkdown / Word / CSV export | Large-scale enterprise workflow orchestration\n\nA good MVP output would be:\n\nOutput | Purpose\n---|---\nBRD skeleton | Gives the expected document shape\nRequirement candidates | Gives reviewers something structured to inspect\nEvidence table | Shows where each requirement came from\nGap ledger | Shows what still needs SME / stakeholder input\nEdge-case register | Makes exception handling visible\nMetric-derived requirements | Converts operational data into measurable requirements\nOpen questions | Drives follow-up workshops\nTraceability matrix | Prepares downstream test / Jira / implementation work\n\n## 10. Metric-derived requirements may be a strong differentiator\n\nThis is where the idea can become more than another document generator.\n\nOperational metrics should not only appear in the background section of the BRD. They should drive requirements.\n\nInput metric | Possible requirement impact\n---|---\nAHT | Processing-time target, automation target, efficiency business case\nTouch time | Manual work reduction, automation candidate selection\nMonthly volume | Throughput, capacity, scaling, queue design\nSLA breach rate | Alerts, escalation, reporting, workload balancing\nRework rate | Validation rules, data quality requirements\nException rate | Exception queue, routing, supervisor review\nHandoff count | Role redesign, workflow simplification\nPeak volume | Capacity planning, batch/real-time processing choices\n\nExample:\n\nObservation | Requirement candidate\n---|---\nAHT is 12 min; target is 7 min | NFR: redesigned workflow should support average handling time <= 7 min for standard cases\n18% of cases are exceptions | FR: system shall support exception classification and supervisor queue routing\n11% rework due to missing fields | FR: system shall validate required fields before submission\n40k cases/month | NFR: system shall support expected monthly volume plus agreed peak margin\nSLA breach is tracked manually | Reporting requirement: system shall report SLA breaches by queue, region, and case type\n\nThis is much more concrete than simply asking an LLM to write a better BRD.\n\n## 11. Review-first UX\n\nI would not make the first interface a document editor.\n\nI would make the first interface a review queue.\n\nType | Item | Evidence | Risk | Action\n---|---|---|---|---\nRequirement | Supervisor review for exception cases | SOP + meeting note | Exception definition unclear | Accept / Edit / Reject\nGap | SLA target missing | No source | NFR cannot be validated | Assign owner\nEdge case | Approver absent | Implied in process notes | Workflow may block | Ask SME\nAssumption | 40k cases/month | KPI table | Seasonal peak unknown | Confirm\nMetric-derived req | Reduce AHT to 7 min | KPI target | Hard SLA vs goal unclear | Clarify\n\nThis makes the tool useful before the BRD is “done”.\n\nIn real BA work, the intermediate review artifacts are often more valuable than the first draft.\n\n## 12. Security and governance should be designed early\n\nBRDs often contain sensitive operational information:\n\n  * internal process details\n  * volumes and SLAs\n  * customer or employee data in meeting notes\n  * system names\n  * manual workarounds\n  * approval paths\n  * compliance assumptions\n  * audit requirements\n  * integration constraints\n\n\n\nSo I would design for governance early:\n\nArea | Practical requirement\n---|---\nData residency | Know where artifacts, embeddings, and generated requirements are stored\nTenant isolation | Separate projects, clients, and departments\nSource permissions | Preserve source document permissions when surfacing evidence\nAudit logs | Track who accepted, edited, or rejected each requirement\nPII handling | Detect and redact sensitive information in notes and transcripts\nPrompt injection defense | Treat uploaded documents as untrusted input\nBYO model / private deployment | Support Azure OpenAI, private endpoints, or local models where needed\nExport control | Prevent unsupported assumptions from being exported as confirmed requirements\n\nThe OWASP Top 10 for LLM Applications and the OWASP GenAI prompt injection note are useful references here. If you expose the system through tools or MCP-style integrations, the MCP security best practices are also worth reading.\n\nSecurity should not be treated as a final enterprise checkbox. It affects the architecture.\n\n## 13. API and integration shape\n\nIf this becomes a platform, I would make the requirements core accessible through APIs.\n\nExample API surface:\n\n\n    POST /projects\n    POST /projects/<project_id>/artifacts\n    POST /projects/<project_id>/extract-facts\n    POST /projects/<project_id>/generate-requirements\n    GET  /projects/<project_id>/requirements\n    GET  /projects/<project_id>/gaps\n    GET  /projects/<project_id>/edge-cases\n    PATCH /requirements/<requirement_id>/review\n    GET  /projects/<project_id>/traceability\n    POST /projects/<project_id>/export/brd\n    POST /projects/<project_id>/export/jira\n    POST /projects/<project_id>/export/azure-devops\n\n\nImportant point:\n\n> Exporting a BRD should be one view. Exporting structured requirements should be the real product API.\n\nThat makes downstream integration easier:\n\nOutput view | Consumer\n---|---\nBRD document | Business stakeholders\nRequirements table | BA / PM / product owner\nGap ledger | SME / process owner\nTraceability matrix | QA / compliance\nJira / Azure DevOps items | Engineering\nTest case seeds | QA\nSpec package | Spec-driven development / AI coding workflows\n\nThe GitHub Spec Kit and the broader spec-driven development discussion are useful downstream references. They show why structured specifications matter beyond a static document.\n\n## 14. What I would not overbuild at first\n\nI would be careful not to make the first version too broad.\n\nTempting feature | Why I would defer it\n---|---\nFull video understanding | Expensive, noisy, privacy-sensitive, and hard to evaluate\nAutomatic BPMN generation | Useful later, but it can distract from requirement discovery\nFull ALM replacement | Jama / Trace.Space / Visure-like territory is heavy\nFine-tuning-first strategy | Hard to evaluate early; retrieval + rubrics give faster feedback\nFull Jira round-trip sync | Useful, but export/import can start simpler\nFully automated final BRD approval | Risky; human review should remain explicit\nTest-case generation as primary feature | Valuable later, but only after requirements are grounded\n\n## 15. A practical build sequence\n\nIf I were building this, I would use a phased approach.\n\nPhase | Goal | Key output\n---|---|---\nPhase 1 | Artifact normalization | Business facts extracted from notes, SOPs, process docs, metrics\nPhase 2 | Requirement candidates | FR/NFR/data/integration/reporting requirements with evidence\nPhase 3 | Gap ledger | Missing information and targeted SME questions\nPhase 4 | Review workflow | Accept/edit/reject/assign owner/check evidence\nPhase 5 | BRD export | BRD skeleton generated from accepted / pending objects\nPhase 6 | Eval harness | Coverage, grounding, unsupported claims, reviewer edit distance\nPhase 7 | Downstream integrations | Jira, Azure DevOps, Confluence, tests, spec packages\n\nThis sequence keeps the first product useful without pretending to solve the entire SDLC on day one.\n\n## 16. My suggested positioning\n\nI would position it like this:\n\n> A requirements discovery workbench for process transformation projects.\n\nOr:\n\n> A source-backed BA workbench that turns messy process artifacts into requirements, gaps, edge cases, and BRD sections.\n\nOr more sharply:\n\n> Find what your BRD is missing before stakeholders do.\n\nThe second and third versions are probably stronger than “AI BRD generator”.\n\n## 17. Short version\n\nI would keep the core idea, but sharpen the boundary.\n\nDo not make the product only a better BRD writer.\n\nMake it the missing requirements layer between document AI and ALM:\n\n  * parse messy artifacts\n  * extract business facts\n  * generate source-backed requirement candidates\n  * maintain a gap ledger\n  * mine edge cases\n  * convert operational metrics into requirements\n  * keep humans in the review loop\n  * export the BRD as one view of a structured requirements package\n\n\n\nThat would preserve the strongest part of the idea while making it much harder to dismiss as “just another LLM document generator”.",
  "title": "Creating a New App for Making BRD"
}