VOGO · Agent Analysis
The agent for business analysis and consulting
Requirements, processes, use cases, data flows and traceability — prepared and checked by the agent, following the recognised standards of analysis.
For the organisation's implementation projects and for the analysis chapter of bids. The analyst validates with the client and is accountable.
- Requirements traceable to acceptance
- Diagrams to standard
- The analyst decides
The rigour of analysis, kept by the agent from the first workshop to acceptance; validation, the analyst's
The agent holds together what easily drifts apart in an analysis: requirements, processes, diagrams and tests. The same requirement codes appear in the register, in the analysis report, in the use cases and in the agreed test scenarios, so every requirement can be followed through to acceptance.
It works on a ready-structured project folder: the analysis report with the interfaces, open issues and test scenarios, the requirements register, the traceability matrix and the diagrams — use cases, context, data flows, BPMN processes, DMN rules, data model —, each with its instructions and the questions to ask the client.
What it states about a standard rests on that standard's sources, kept locally; what it cannot find there, it says openly.
Less drafting work. Fewer requirements lost along the way. The same accountability, the analyst's.
AS-IS and TO-BE
Today's processes and the target ones, modelled in BPMN by role, with the problems found and what changes.
The requirements register
Each requirement with its source, MoSCoW priority and acceptance criterion, listed in the report and tracked until acceptance.
Use cases
The actors and what they get from the system, in UML, each case with its specification and "Given / When / Then" scenarios.
Data flows
The context diagram and levelled DFDs: where data comes from, where it is kept, to whom it goes.
Decision rules
Repeatable decisions taken out of the flow into DMN tables, each rule linked to its legal source.
Interfaces
Screens as mock-ups reviewed online by the client, the interfaces between modules and the integrations with other systems.
Traceability
Requirement — process — design — test — deliverable, in a single matrix that shows what is covered and what is not.
The compliance matrix
The requirements of the specification, point by point, with the answer and the place in the bid or the solution where they are covered.
Structure and behaviour
UML class, sequence, activity, state, component and deployment diagrams, from the same model.
The data model
The conceptual, logical and physical models: entities, relationships and the data life cycle.
The validated prototype
An evolutionary prototype, reviewed in iterations by the key users and validated through a signed report, the basis of the final system.
The analyst decides
The agent prepares, models and checks; validation with the client and approval remain the analyst's.
From the system inventory to the accepted analysis
System inventory
The existing systems, interfaces, volumes and the people who know them; profiling the real data against the documented data.
Workshops and AS-IS
Workshops with the process owners: the actors, the decisions, the exceptions; the AS-IS BPMN models, validated by them.
TO-BE and scenarios
The target processes, with their control points and approvals, and the usage scenarios with actors, steps and expected result.
The requirements
Atomic, verifiable requirements, each assigned to a component; the non-functional ones with a target value and a measurement method.
Traceability
The requirement — process — system — component — deliverable matrix, covering every requirement, with no unassigned items.
The analysis report
Written to the agreed table of contents and put through technical, functional and security review by people other than the authors.
Validation and acceptance
Validation with the client's specialists and acceptance through a signed report, with no open remarks.
The outputs of the analysis are the formal inputs of design: every requirement moves on with the same identifier, and whatever is unclear is recorded with an owner, not covered by assumptions.
What the client receives at the end of the analysis
The system sheets
One sheet per existing system and the profiling report of its data.
The process models
The AS-IS and TO-BE BPMN models, the catalogue of flows and dependencies.
The usage scenarios
The use cases with actors, steps and expected result, the basis of the acceptance tests.
The single requirements register
Each requirement with its own identifier, source, priority and acceptance criterion.
The traceability matrix
The link from each requirement to the process, component, deliverable and the test that proves it.
The rule sheets
The validation and calculation rules, documented with the client's specialists and approved by them.
The analysis report
The current and target situation, the requirements, the interfaces, the open issues and the agreed test scenarios.
Validation
The minutes of the validation workshops and the signed acceptance report of the analysis.
No deliverable goes to the client without an internal review by someone other than the author, and progress is measured by validated requirements and accepted deliverables, not by estimated percentages.
The decisions the client takes, prepared with the analyst
What to do with the existing systems
For each system, the decision taken together with the client: keep and integrate, modernise, redesign, replace or controlled coexistence.
Continuity
The period of parallel running, the reconciliation rules between the old and the new system, the switch-over criteria and the rollback procedure.
The business rules
Each rule documented with the client's specialists and approved by them, linked to requirement, implementation and test; changing it goes through impact analysis.
What the client checks when accepting the analysis
Validated processes
Every process in the project scope has its AS-IS model validated by its owner.
Scenarios for every TO-BE
Every target process has at least one usage scenario, with actors, steps and expected result.
Measurable requirements
Every requirement is atomic, verifiable and assigned to a component; the non-functional ones have a target value and a measurement method.
Full coverage
The traceability matrix covers every requirement of the specification, with no unassigned items.
Three reviews
The report passes technical, functional and security review, carried out by people other than the authors.
Clean acceptance
The analysis is accepted through a signed report, with no open remarks.
The criteria are checked before submission, against the minimum content list of the deliverable, not discovered at acceptance.
One requirement, from the workshop to acceptance
The workshop
The process owner says that an incomplete application goes back to the applicant with the reason in writing.
The register
It becomes requirement CF-014, with its source (the workshop minutes), Must priority and the acceptance criterion.
The use case
It goes into UC-03 "Check the application", with the alternative flow "incomplete application".
The TO-BE process
It appears in the BPMN model as a decision, and the rule "what complete means" moves into a DMN table.
The test
The agreed scenario TS-07 checks that the application is returned with the reason in writing.
Acceptance
The acceptance report closes CF-014 on the basis of the passed test; the matrix shows the complete chain.
The same identifier, from the first workshop to the acceptance report: if a link is missing, the matrix shows it.
What the analysis works with
BPMN editor
AS-IS and TO-BE processes in BPMN 2.0, compatible with the workflow engine that runs them.
Diagram editor
Use cases, data flows, data model and architecture, as editable files.
The requirements register
Versioned, with templates, identifiers and links to source, deliverable and test.
Preview in ECM
BPMN, DMN and draw.io diagrams shown directly in VOGO ECM, as they look in their own tools.
The source models remain editable and are handed over to the client; the documents are not sent to external services.
What can delay an analysis and how we keep the risk under control
A client too little involved
The client's people named for each process from the start, workshops planned with duration and participants; their absence is recorded as a dependency, with its effect on the schedule.
Late validations
An approval calendar with firm deadlines, interim versions of the deliverables before the final one, the decision register with the deadline of each decision and escalation.
Insufficient information
Structured information requests, with deadline and owner; data profiling and reconstruction of missing documentation, with effort planned from the start.
New requests along the way
Prototypes and demonstrations instead of abstract specifications; a request that changes the scope goes through a change request, not an informal extension.
The same term, understood differently
The project's common glossary, validated at the kick-off meeting, used in requirements, models and tests.
The project starts from a ready-structured folder
Structure by phase
Management, analysis, design, implementation, testing, training and archive, each with its place.
The analysis documents
The complete analysis report, the process sheet, the use case specification, the requirements register, the traceability matrix.
Diagrams, with instructions
Use cases, context, data flows, the value chain, the stakeholder map, the conceptual data model, the data life cycle, application interaction, BPMN processes and DMN rules — each with the standard, the questions for the client and the prompt for the agent.
Context for the agents
The files that explain the project structure to the agents, what they read first and where they record decisions.
The folder is created in one click, from the software implementation project template in VOGO ECM.
The frameworks it works by
IIBA BABOK
The knowledge areas of business analysis and the content of the ECBA, CCBA and CBAP certifications.
IREB CPRE
Requirements engineering: the foundation level and the advanced levels of elicitation and requirements modelling.
UML, BPMN and DMN
The OMG notations for use cases, processes and decisions, used in our analyses.
ISO/IEC/IEEE 29148 and SWEBOK
How to write a good requirement and the software requirements domain; TOGAF for the architecture diagrams.
Workshops, a prototype validated by the client, BPMN models that become executable workflows and two-way traceability — the same methodology we use in our projects and our bids.
Frequently asked questions
Does it replace the business analyst?
No. The agent does the preparation, modelling and checking — the requirements register, the diagrams, the analysis report, traceability — and the analyst validates them with the client and is accountable for them.
What does it rely on when it cites a standard?
On the sources kept locally for each framework. What is not in its sources, it says so; it does not fill gaps from memory.
How does it fill in a diagram?
From the project documents: the workshop minutes, the process sheets, the specification. What does not follow from them, it does not invent: it moves it to the open issues, with the questions to ask the client.
Does it help with bids?
Yes. It prepares the analysis chapter and the methodology of a bid, the compliance matrix and the mapping of the requirements in the specification.
Do I need to know anything technical?
No. Type or dictate what you need, in conversation, and download the resulting documents and diagrams.
Where is project data kept?
In the organisation's folder. Processing is based on the agreement between the organisation, VOGO and the provider of the artificial intelligence service.
See how VOGO Agent Analysis works
A 15-minute demo, on an example or on one of your organisation's projects.