The Better Business Analysis Institute presence, the Better
Business Analysis Podcast with Benjamin Walsh.
Hi, everybody, and welcome back to the Better Business Analysis
podcast with Benjamin Walsh. And this week we have ABA Bytes
talking about it's OK to ride a long requirement spec, but it's
only temporary. That's right.
I'm going to talk to you about when it's appropriate to write a
long requirement specification when you do that, and when it's
time to then take the chunks of that specification and put it
into other systems and other types of, I guess, processes and
documents so it can be consumed by those people who need to use
that information. So I've been working on a
project, a large piece of work. It's a program within a
portfolio and there are lots of projects, if you like, streams
of work in that portfolio and the process, the business
process in which we are improving the value chain, if
you like, is spread across those projects.
What does that mean from ABA point of view?
What that means is you might start with a requirement
specification document, a business requirements document
where you're capturing assumptions, constraints, pain
points, res in one document, even in decisions in like a Word
document form or a Google Doc. And at the same time you might
be transferring that or we're working in a requirements
matrix, requirements traceability matrix, which you
might have that information in and you might be copying it back
and forth within Word and Excel. You've got it in Word because
you might want to send some of those out to get clarification
during the analysis phase. Not as a published document, but
just simply as a question and answer on getting people to to
work on it. Sometimes Word of course is
better at showing visual depictions of things and having
tables through, but it's pretty useless when you're trying to
track that stuff, which is why Excel and a requirements matrix
makes sense as your kind of master.
If you're in this Phase, I would highly recommend that your
requirements traceability matrix in Excel is your master and that
you're just copying information into Word for the purposes of
showing people and talking about it.
Now I'm going to make another assumption here, which is you've
already kind of got a bit of a scope.
You already have your scope, which ideally is defined by
epics, and you may have done that through, say, PowerPoint
presentations and talking about it or mural something.
So now we have a bit of an outline.
You're working in these two medium.
Now what this is OK to be in and that requirement specification,
even though I go on about BA should be running along spec
this spec, and I'm going to be clear it's a working spec, can
be quite null. So for this particular example I
was talking about, I maybe had 100 and 52150 pages of document
reference material, process diagrams, process steps, pain
points, requirements, all put together in, in a, in a list of
tables within this Word document for my own benefit, a business
requirement spec that's about 200 pages.
But I should know that my audience doesn't want to consume
all that. So what I need to do then is now
work on who my stakeholders are and how I want to share that
information. If I'm working with my product
owner just before I go into the delivery side, into the like
agile delivery or whatever mechanism you're using, then I
should really be going through the Excel spreadsheet working
with them. What's in scope, what's out of
scope, What's code must should your Moscow ratings in any note?
So they, they understand that that's the master and you've
working with them in that medium.
They may also want a copy of that, which you could then flick
out in terms of Word format. So that's your requirement side.
Now what do you do with everything else?
Because when you move to the delivery cycle, it should be
easy or known from a lot of your BAS that once you get to
delivery, you should be working in a delivery tool like DevOps
or Jira. And at that point you copy your
stories or you import your stories into Jira.
You should ideally have epics which link to user stories.
I don't like the feature join that Azure DevOps has and I
ignore that and I use my own custom process.
And then user stories may develop into child user stories
and tasks within Azure DevOps within your development system
could be a juror. That's fine.
The master then becomes that system and your requirements
matrix is kind of signed off as your kind of starter
requirement. That's how you work with
requirements. So I could do a whole session on
that, but that's how you work with it.
But what I'm trying to answer it or articulate to you today is
what do you do with everything else?
What do you do with the process step?
What do you do with the issues and the risks that you used to
have in your starter document? Well, within these systems, JIRA
and as your dev OPS, I think it's best that you create work
types or issue types depending on which system you're using,
which allow you to capture in the same way you capture user
stories, pain points, maybe the process steps, issues, risks and
decisions and have them in there.
And if you've created those custom types, then you can
actually transfer all that information from your working
document into Azure DevOps or into Jira.
And then the project manager can see those.
The team can then raise those. The development team and the
project manager can summarize those in the issue reports.
And the risk reports and issues can be tracked through that
workflow system, right? So it's enough of me.
So it's OK to have a requirement specification document that's
really long, but it should be temporary because you're then
moving that along into other systems as you move into
development.