Presentation: Non-functional not Dysfunctional
“As an end-user in order to navigate the online product catalog, I will need a banner here with menu option there and the page should function THIS way and then the mobile app should function THAT way.”
Today’s software engineers are typically overwhelmed with descriptions specifying WHAT the software should be while working with little or no information about HOW it should be working. Testers are under even more pressure to prioritize the high-risk test cases as well as rapidly invent new ways to break the functionality of the app. It’s only after those bugs are found and fixed, after the code is packaged and deployed to staging, that a lonely ops engineer asks: “I wonder if this code will scale?” and the database administrator replies: “You know they didn’t test THAT!”
Unfortunately, it is incredibly common for those non-functional characteristics to be left out of our user stories and specs because they represent much harder and more complex questions for product owners and engineers to answer. But without giving thought to the characteristics of our system before we write code or deploy the infrastructure, we perpetuate failures and re-work that could be avoided.
We CAN do better and I’ll share some insights on how to make your non-functional thinking more robust.