document or standard process when automating manual stuff or creating scripts

Question

I am part of a new team that has the main task of automating manual processes. Mostly using excel VBA or PowerShell. The requests that come in are somewhat in general. For example, it will only say "We want to automate moving data from one excel workbook to another".

I am trying to look for or formulate a document that we can use to indicate all the specifications of the script/project. Something we can ask the requestor to fill out so we can get a clearer view of the process to be automated.

While researching I came across Software Requirements Specification (SRS) Document. I am not sure if we can use this or this is something we need.

Answer 1

Documenting requirements as user stories on a backlog is a common approach to start off with. Example: "As a financial analyst I want my daily financial summary to be automated so that the figures can be available quickly and accurately". You could consider using a lean workflow approach like Kanban, or an iterative approach like Scrum but what's important is to encourage the development team to work closely with the customer, to demo possible solutions to them, gather their feedback and act on it. Try to avoid over analysing and being too detailed in specifications without actually testing them out. Too much time spent on analysis without actually testing and validating any real outcomes will eventually become counter-productive.

When it comes to written specifications a lighter touch is generally better. Use a wiki or a collaboration system like Jira rather than producing word-processed documents. A good rule of thumb is that documentation for a single unit of work becomes "too much" at the point where you aren't happy to throw it away and start again.

Answer 2

You first need to start by understanding the existing manual processes. Identify what the inputs and outputs are, how the process starts, what activities it includes to transform the inputs into the outputs, in what sequence do those activities occur, what are the actors involved in those activities, what are their roles, etc.

Then, think about where you will add the automation. Will you be automating the entire process or just parts of it? For example, you mentioned that "We want to automate moving data from one excel workbook to another". This seems like part of a process to me. Is that it or is there more? Find out!

You first need to understand the "what" so that you can then figure out the "how" and the "where".

This activity is basically requirements gathering (that you can do in various ways). You can end up with a Software Requirements Specification Document, but the point of it is to understand what you need to build. Once you do, you can then plan out your work, which I would suggest you do incrementally and not all at once.

The problem with manual processes is that, unless there is a strict documented standard to follow (in which case you already have your Requirements Specification), a lot of things can live in people's heads and managed through their experience, things that are so ingrained in people's work that it doesn't even occur to them that it's important to mention explicitly. So figure out what you need to build and automate some of it. Then get feedback. Automate some more. Get feedback. That way you make sure you build the complete solution (that maybe you might not have captured fully when doing the requirements gathering).

Another thing to be aware of is that people may ask for "extras". That thing that's not in the manual process that they always wanted to do but was labor intensive, maybe you could build it also, right? So be sure to first automate the existing manual process and then enhance it, otherwise the goal of the automation might become fuzzy or too generic with time.

Answer 3

1. Can be done ''offline', but need some preparation:

you prepare small UML use case schemas to drive the respondents, what you're asking about - they add more use cases and describe each one in details step by step. OR you prepare a User Story form and the respondents fill the gaps. Then you aggregate it into the map.

**PROS**: it hightlights more cases than you can catch on your own, ...
**CONS**: but may not provide the direct requirements of what they want to get as a result of the 'optimization project'. Need to analyze and decompose the received stories.

2. Need people to participate in the dialogue, i.e. 'online' meeting:

Gather the respondents altogether, ask them to describe their activities and draw a business process in BPMN - drawing the process during the interview in front of the respondents makes it easy to get the feedback (or just to use a block schema, i.e. algorithm), and then you can provide them with the access to the BPMN, so they can comment and correct you (helps in 1-to-1 meeting or when there is no much people on the meeting and they are from the same area - only business, or only IT, or only technical guys). Butin this way you'll create user stories on your own.

**PROS**: people see to-be more clearly.
**CONS**: takes more time, more persons involved into action need peoples' attention.

Or, being consistent, you can go all the way through: from the business process first (as-is, highlighting the issues and bottlenecks) -> then High-level business requirements what they want to see (to-be business process) -> to then functional/technical requirements [here is the Requirements Specification].

Capturing the business processes first will take time, but will give the understanding, how this flat list of requirements came up.