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.