Glossary

Quick reference for terms used across BA Toolkit documentation and generated artifacts. If you are new to business analysis or requirements engineering, start here.

Core concepts

Artifact A Markdown document generated by a BA Toolkit skill and saved to your project folder. Each artifact covers one aspect of the specification — for example, the Brief captures goals and stakeholders, while the SRS lists detailed requirements. Artifacts are cross-referenced so changes in one can be traced through the rest.

Skill An AI-powered task you invoke with a slash command (e.g., /brief, /srs, /stories). Each skill loads previous artifacts, asks you a series of focused questions, and generates or updates an artifact. There are 15 pipeline skills (run in sequence) and 9 utility skills (run at any stage).

Pipeline The recommended sequence of skills that takes a project from concept to implementation plan: /discovery (optional) through /brief, /srs, /stories, and onward to /implement-plan. Each step builds on the previous one.

Slug A short, URL-safe identifier for your project, derived from the project name. If you name your project “Neobank App”, the slug is neobank-app. It appears in every artifact filename (e.g., 01_brief_neobank-app.md).

Domain The industry vertical your project belongs to — for example, SaaS, Fintech, E-commerce, or Healthcare. BA Toolkit ships 12 domain references that add industry-specific interview questions, mandatory entities, and glossary terms to every skill. Pick “Custom” if none of the 12 fits.

Traceability The practice of linking every requirement to its downstream artifacts (user stories, acceptance criteria, API endpoints, wireframes) so you can verify that nothing was lost or duplicated. The /trace skill builds the full traceability matrix automatically.

Refinement skills After a skill generates an artifact, you can refine it using standalone utility skills:

/validate — check completeness and consistency of the current artifact
/revise [section] — rewrite a specific section with new feedback
/expand [section] — add more detail to an under-developed section
/split [element] — break a large element (FR, User Story, Use Case) into smaller pieces
/done — finalize the artifact and move to the next pipeline step

Requirement types

FR (Functional Requirement) What the system must do. Example: “The system shall allow users to reset their password via email.” Each FR has an ID (e.g., FR-001) and is traced forward to user stories, use cases, and acceptance criteria.

US (User Story) A short description of a feature from the user’s perspective. Format: “As a [role], I want [action], so that [benefit].” Example: “As a shopper, I want to filter products by price, so that I find items within my budget.”

UC (Use Case) A step-by-step narrative describing how a user achieves a goal through the system. Includes main flow, alternative flows, and exception flows. More detailed than a user story — shows the full interaction sequence.

AC (Acceptance Criteria) Testable conditions that define when a user story is complete. Written in Given/When/Then format. Example: “Given a logged-in user, when they click ‘Reset password’, then they receive an email within 60 seconds.”

NFR (Non-Functional Requirement) A quality attribute the system must meet — performance, security, availability, scalability, compliance. Example: “The API shall respond within 200 ms at the 95th percentile under 1,000 concurrent users.”

SRS (Software Requirements Specification) The comprehensive requirements document generated by /srs. Lists all functional requirements, roles, business rules, assumptions, and constraints. Follows the IEEE 830 standard structure.

ADR (Architecture Decision Record) A record of a significant technical decision (e.g., “Use PostgreSQL for the primary datastore”). Documents the context, options considered, decision rationale, and consequences. Generated by /research.

DAG (Directed Acyclic Graph) A way to order tasks by their dependencies so that each task starts only after its prerequisites are complete. The /implement-plan skill produces a task DAG that an AI coding agent can execute step by step.

Standards and frameworks

These are industry standards referenced in BA Toolkit artifacts. You do not need to read them — the skills apply them automatically. This section explains what each one is so the references make sense.

IEEE 830 A standard for writing software requirements specifications. Defines the structure: scope, definitions, functional requirements, non-functional requirements, assumptions, constraints. The /srs skill follows this structure.

MoSCoW A prioritization framework that classifies requirements as Must have, Should have, Could have, or Won’t have (this time). Used in /stories and /srs to set priority levels.

BABOK (Business Analysis Body of Knowledge) The professional reference guide for business analysts, published by IIBA. BA Toolkit follows BABOK practices for requirements elicitation, analysis, and traceability.

INVEST A checklist for well-written user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable. The /stories skill runs an INVEST self-check on every story.

Cockburn use cases A structured format for writing use cases, created by Alistair Cockburn. Defines goal level, actors, main success scenario, and extensions. Used by /usecases.

ISO 25010 The international standard for software product quality. Defines 8 quality characteristics: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability. Used by /nfr to categorize non-functional requirements.

ISO 31000 The international standard for risk management. Defines the risk assessment process: identify, analyze (probability x impact), evaluate, treat. Used by /risk.

PMBOK 7 (Project Management Body of Knowledge) The project management standard published by PMI. BA Toolkit references PMBOK for risk treatment strategies (avoid, mitigate, transfer, accept) and sprint planning practices.

Michael Nygard ADR format A lightweight template for architecture decision records: Title, Status, Context, Decision, Consequences. Extended by /research with Drivers, Alternatives Considered, and Decision Date.