Role
Business analyst
What do you not know about a requirement until you see the first working version? Usually that a case is missing, one nobody thought of because everybody knew it.
Intro call
Four questions we would start with
What do you not know about a requirement until the first version exists?
If the answer is "quite a lot", then the question is not about what the business knows, it is about how the questions are asked.
Whose desk does the settling of two departments' conflicting expectations end up on?
If it is the analyst's, then the analyst is making a business decision without the authority for it - and that usually comes back.
How long does agreeing a requirement take, from the first conversation to approval?
That number usually explains why the project is late before it has even started.
What do you do when two departments describe the same process differently?
Whether the discrepancy is recorded and settled, or whoever spoke to you last wins.
We take over the writing down and the ordering, you keep the discovery
Taking notes from conversations, organising requirements, chasing sign-offs and maintaining the documentation can be taken off the desk. Which questions are worth asking, and spotting what nobody said, stay with the analyst.
- The conversation is recorded in one place. - The note, the agreement and the change to the requirement are linked, rather than scattered across threads.
- A contradiction between requirements is pointed out. - Two descriptions of the same process that rule each other out come up as something to settle, not as two items on a list.
- The documentation follows the change. - A change to a requirement points out which descriptions and models need correcting, instead of leaving it to the analyst's memory.
Scope
What can be taken off business analysis
Nineteen example tasks. Each one has a human approval point. Below is a selection, and the scope we fit to the way you work.
Gathering requirements
- A meeting note with the agreements pulled out (verification: the analyst)
- A list of open questions arising from the conversation
- Linking a requirement to whoever raised it and to the process
- Pointing out requirements phrased as a solution rather than a need (assessment: the analyst)
Description and modelling
- A draft description of the requirement in the agreed format (content: the analyst)
- Pointing out missing elements of the description
- A draft process model based on the description
- Consistent naming across requirements
Agreements with the business
- A register of agreements with the date and the person
- A reminder about a requirement waiting for approval
- Pointing out requirements that contradict each other (settled by: the process owner)
- Requirements awaiting approval in one view
Changes along the way
- A register of changes to a requirement with the reason
- Pointing out the parts of the documentation affected by a change
- A signal when a requirement is changed repeatedly
- The effect of a change on related requirements
Solution documentation
- A comparison of the requirements delivered against those described
- Pointing out descriptions that diverge from the delivered solution
- Documentation in one place, linked to the requirements
A day's work
Today
- You write meeting notes afterwards, from memory and from your own jottings
- The agreements are in notes, in email and in chat
- A contradiction between requirements surfaces during implementation
- You chase approvals by email, without knowing what has been waiting longest
- When something changes you work out yourself what else needs correcting
- The documentation drifts away from the solution after the first release
With AI assistance
- The meeting note has the agreements and open questions pulled out
- The agreements are in one place, linked to the requirement
- A contradiction between requirements is pointed out before implementation
- You can see what is waiting for approval and since when
- A change points out the descriptions and models it affects
- Documentation drifting from the solution is flagged
- Complete requirements
fewer gaps discovered during implementation
open questions are written out after every conversation
- Changes along the way
fewer corrections caused by contradictions
conflicting requirements are pointed out earlier
- Time spent agreeing
approvals do not sit for weeks unnoticed
you can see what is waiting and since when
- Documentation you can rely on
the description matches what actually runs
a change points out the documents to correct
We start with recording the agreements, because that is where most of the context is lost.
- Step 1
Agreements and open questions in one place
Meeting notes with the agreements pulled out, linked to the requirements.
- Step 2
A register of agreements and approvals
What is waiting, with whom and since when.
- Step 3
Detecting contradictions
Requirements that rule each other out, pointed out before implementation.
- Step 4
Documentation against changes
Pointing out the documents a change affects. Last, because it needs the links to be in order.
Common questions
Questions that come up at the first meeting
Who settles conflicting expectations between departments?
The process owner, not the analyst. The tool points out the contradiction and shows who said what - the decision belongs to the person who has the authority for it. That is usually the most noticeable change for the analyst themselves.
Does the business analyst not become redundant?
The best requirements come from a question nobody expected, and that is the whole value of this role. We take over the writing down, the organising and the chasing of approvals, which is what happens after the conversation. The time that goes on it today comes back as further conversations, and their number usually decides the quality of the project.
Does this fall under the AI Act?
Business analysis is not a high-risk use. If meeting notes are produced from recordings, the rules on recording and participants' consent apply - that is a matter of data protection and of agreement within the team, not of the regulations on AI systems.
Still have a question that is not here? Book a call
Next step
How many requirements in your last project changed after implementation had started?
We will show you what analysis looks like when the agreements are in one place and conflicting requirements surface before implementation.