ArgonDigital - enterprise automation experts

Share This Post

An Actual Case of Software Requirements Re-use

We have been using Caliber for a few years and we recently decided to research whether there was a requirements management tool that more cleanly supported working offline. I actually wrote a bit about our vendor selection process and our search for a requirements tool awhile back, so if you read it, you’ll know we did this project working from software requirements written at the level necessary to do a vendor selection. Well, here we are again a few years later, with a pretty important feature request that we didn’t recognize the priority of when we did the first analysis. The issue is that we often work on cellular cards, which with Caliber has doesn’t work well – the connection is too slow. So we really need to be able to just work offline and sync. We have a few anecdotes about other vendor tools in the market and how they handle offline support. We even have thoughts of building some offline tool ourselves to sync with Caliber or another backend. In the end, we are trying to follow our vendor selection process. We have done a bit of research on the other tools we know might work – including reading feedback and doing a mini demo ourselves. And at the same time, we have our existing software requirements from the first time we selected a tool that we are reviewing.

Our intent is to review any tools we consider against those original requirements. Ideally we really need reprioritize those as our needs may have changed, but for the most part we can select a new tool with MUCH less work than the first time. My estimate is it’ll take a tenth of the time this round through.

The only downsides to this, our old requirements aren’t in a tool (since we didn’t have a tool when we did the first analysis) and I don’t know how easily we can get them in one. But the bigger issue is there is no organization to them at all – they are about 150 features, not organized by any other useful models (and that’s because we didn’t use models as consistently then!). So, while we do have our software requirements to reuse, we probably could do a pass on improving them too. But even at that, it’s still so much less time committed.

An Actual Case of Software Requirements Re-use

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage