in Business, Software

Audit your application’s functionality

It is in my nature to ask questions to expand my knowledge of processes and systems. I have to have the full picture. Being cognizant of the next layer of information will almost always impact my way of navigating current circumstances. Over the years I find that fully understanding what a software product does (or is supposed to do), albeit a daunting task in retroactive instances, is very beneficial. Fighting my urge to list the reasons why, I now simply want to dig into how to produce a more complete audit of your software’s functionality.

Sample functionality listing

– Create
– Create from template
– Archive
– Delete

– Link
– Unlink
– Invite

…Shortened for brevity. Simple because why not?

Finding the functionality (in minds, docs, and code)

I move from less technical to more technical for whatever reason…

Public documentation. The product I am working on now does offers documentation to our users. This would be a good place to start if you have it available already. Depending on how old the documentation is you may still have to supplement it some. Be sure to audit what is sourced to in case you have slimmed the functionality down at all.

Meeting of the minds. Getting most of the more senior team members (e.g. product owner, lead analyst, development manager, head of client services, sales manager) together and just verbally listing out functionality should hit at least 80-90%. Of course, if turnover has taken it’s toll this number may be lower. You can timebox this to 30 minutes and still get a good list compiled.

Completed epics or requirements. A scroll through a reasonable amount of completed epics (releasable features) will add a nice chunk to your list. In the event of waterfall simply use the requirements that were used to build the product. And hopefully you know all the deviations that happened after the feedback loop was closed.

Test cases. Automated, integration, manual, and unit tests can all help. Unit tests at a sub-component level you can ignore. But the outermost service level would be good to focus on. The rest, though, should describe functionality worthy of being in your audit.

Routing and request URIs. MVC controller actions and searching for href values (e.g. URIs) in your code should give your ALL of the ways in which the server is able to respond to a request from the application. If you fell victim to CRUD this should be really easy.

Domain events. I give you a standing ovation for this approach. 100% of the product may not be full DDD-CQRS-ES. But whatever portion is would allow you to copy a list of domain events as a 1:1 transfer. FYI, I’m still standing and clapping.

In future posts I will look at what we can do with this information.

Write a Comment