Perfect Requirements!

The picture above was from a project a few years ago. Literally a couple of hours initial session to understand what a client wanted to achieve with a new event management solution. Yes, its scribbles, its messy, has duplicate areas where we drilled deeper, and has open questions.? That's pretty typical for a first session. But even after this one session, my stakeholders left with confidence that I knew their business.? I left with confidence that we'd pretty much teased out and agreed most of the needs, I knew exactly where the complexity was, and I was confident in proposing future development.

I could fixed price/fixed delivery date bid at this point. Even if I had deeper questions, they would all be very focused on what mattered to my stakeholder. We were as aligned on the project as we could be, on our very first day's work.

Like learning to drive a stick-shift, at first it feels clunky and you occasionally grind a gear.?But as you get more practiced, you just change gear without thinking.? It’s the same for me today. Having done this so many times, I can confidently leap from that scribbled whiteboard to a candidate database and application design, with estimates, in a very short period of time.? And with a little practice, so can you! To make this teachable, I've developed three simple rules to requirements modeling. Now I want to market test the approach and rules and turn this into something you can use!

DM or comment+tag me if you are interested in the book, and I'll make sure you are added to my email list for the book launch around spring of 2024.

If you don’t want to wait for the book, DM me and we can schedule an introductory call.

Now for the longer "what's he babbling about?" content :)

Perfect Requirements in Two Hours?

One of the challenges of sharing traditional requirements is the vagaries of the English language!? Take the working title of my book for example!? Does it mean:-

1. You can read this book in two hours?
2. You can learn how to get perfect requirements in two hours?
3. You can (verb) perfect your requirements in two hours?
4. You can gather requirements from stakeholders in two hours?

If you chose d) you'd be correct, but all the other interpretations could be valid.? This is why I use modeling approaches to solicit business requirements. The potential pitfalls of interpretation of the written word are cleanly avoided with no loss of clarity in the requirements.? Another challenge with contemporary written word requirements is how difficult they can be to comprehend the big picture.

A quick story!

Way back in 1984, I was a young analyst/programmer. My mission was to design and develop a new tech support management system supporting a billion dollar computer manufacturer's Europe-wide support teams. After a few weeks of traditional requirements gathering - interviews and analyzing existing systems and processes - I was deep into logical and physical database design and had hand drawn models all over my desk.? My stakeholder and SME, Colin, with responsibility for all thirteen countries that were going to depend on this system, just happened to be visiting, and peeked over my shoulder.? I kid you not, in less than a minute he pointed at my model and said "oh, this is cool, but that's not right!".? Wait, wait… you understand this?? Of course Colin understood it, it was all in his business terms, and 'made sense'.? Well dang! The penny dropped! Why didn't we start out with a modeling session first?!!? And that's the way I've been getting requirements ever since.

"Aha! All you are doing is ER data modeling!" says you.

Well, kind of, in that it borrows from what used to be called 'logical database design'. But it is not logical db modeling.? A logical model requires more rigor - specification of all entities and their relationships and attributes, and one can normalize the data model before proceeding to physical database design, where we get into detailed definitions with even more rigor to design keys, integrity, de-normalize for performance, select datatypes and more.? That's not what we are doing in requirements modeling. We're simply capturing ideas!? So if you recognize this as ER modeling, great! You already have a foretaste of how this will benefit your team.

When I spend an afternoon with stakeholders, I get their requirements in such a way that I will have a high level of confidence on the development time and costs, we will have defined all the major business rules, the stakeholder will have agreed scope and feature decisions, and understands where the complexity is in their desired application.? And all this can happen in advance of any design deck. If a design or wireframe exists, great! That's one way of getting people to align on the major elements of what we're going to build, so it supports modeling, but the design deck will likely be incomplete and not cover edge cases. It will be missing the devil in the details that complicate software projects.? In my mind, doing user interface design ahead of getting perfect requirements is the wrong way round and risks design rework. Both are important.

Without data, there is no application.

All that a software application does is present, manipulate, and store data. So it follows that if you model the data needed to support your desired functionality, you have 100% defined your scope and needs. You cannot add functionality to the UI if the data is not there to support it.

Furthermore, it does not matter what your user interface design is, or what tech stack you plan to develop with - you can use widely available CRUD type lists and forms, or you can hand design every single page. The only thing that user interface design affects is how you calculate your development estimate based on the model, it does not change the desired functionality of the application. Using low-code tooling will get your application rolling quicker, than say hand-written React/Typescript/Node pages and services. In fact, the modeling approach I use ensures that you can quickly identify what parts of your system could be the basic grids/forms templated look and feel, and which (fewer) areas require some design input for best user experience.? None of these choices will affect your requirements model though, because they do not change the data that is being used.? Hence my earlier statement, that I prefer to do my requirements model before a UI or UX designer is involved.? The UI will not change the business conceptual data model.? Conversely, changes in the business model will impact the user interface design.

All that is old is new again!

My ideas and approach might sound new, especially if you started your software development career in the last 20 years and all you have experienced is the 'agile' approach.?The ideas are not new. Not to me.?I've been consistently bidding fixed price custom business applications with committed delivery date on every technology stack over the last 40 years using this same approach to requirements, and I've never lost money yet.? And my stakeholders have been very satisfied with the results.

Hmm... smells like waterfall?

Could I mix the perfect requirements approach with an agile delivery?? Sure!? Knowing what you want built, and how you manage the development, are two separate things.? If you prefer agile delivery management processes, knock yourself out.? Personally, if I do have perfect requirements up front, I'd rather go waterfall and set deadlines and mid-project delivery dates that align with the known work.? As opposed to slicing up the known work to fit into arbitrary sprint sized chunks. We avoid the 'chunk wont fit into a sprint' issues, and we avoid the typical practice of needing to load up the sprint with smaller work items, to fill the gaps and keep the team velocity numbers steady.? But that's up to you.? You can get perfect requirements and stay in the sprint delivery model of your choice.

If this sounds like I'm making the case for waterfall vs agile, let me state categorically that I am NOT!

Success is all about the initial requirements being as perfect as possible and doing so in a short time, and capturing that information in a way that is easily communicated to, and understandable by all team members!

I'm offering to share how I do high quality, verified, requirements gathering that can be trusted. Because your subject matter expert has tested it, and you have tested it.

You may think this is not possible! What can I tell you? I've been doing it this way for 40 years.? It works. I've never met a non-technical stakeholder who had trouble understanding, quite the reverse! They've appreciated having a 'one pager' understanding of their own business!

You may have many reasons it wont work for you! Its natural to push back and question anything 'new'. Stay curious, your opinion is welcomed, this wont be the last you hear about the topic.

If you are not open to trying a different approach, that's fine. Wait for the book, and you can find out more at your own pace.

If you are open to a new approach, and don't want to wait for the book, then get in touch with me and we'll talk.

Let's connect!

Paul Irvine is an independent consulting CTO, and custom business solutions developer, based in Portland, OR. When Paul is not modeling, leading teams, or building software, his alter-ego, Paul James Irvine is out playing rock music - you can find Paul James Irvine wherever you get your streaming - Tidal, Deezer, Amazon, Pandora, Spotify and more. Rock on!