If the software development team writes a draft run book or draft operation manual, many of the operational problems typically found during pre-live system readiness testing can be caught and corrected much earlier. Because the development team needs to collaborate with the operations team in order to define and complete the various draft run book details, the operations team also gains early insight into the new software.
Using the term 'non-functional requirements' to describe aspects of software systems which are invisible to the end-user but essential for effective service operation is counter-productive; we should instead use 'operational requirements' or 'operational features', and schedule these for delivery alongside end-user features.
The book 97 Things Every Software Architect Should Know is a useful collection of personal recommendations from experienced software practitioners. Four of the contributions deal with the operability of software systems - from Dave Anderson, Mncedisi Kasper, Michael Nygard, and Rebecca Parsons.
The book Patterns for Performance and Operability by Ford et al is one of the few publications which addresses directly the operability of business software (the other book is Team Guide to Software Operability from Conflux Books). This blog post explores a few of the key themes and ideas found in the book Patterns for Performance and Operability.
Using the term 'non-functional requirements' to describe aspects of software systems which are invisible to the end-user but essential for effective service operation is counter-productive; we should instead use 'operational requirements' or 'operational features', and schedule these for delivery alongside end-user features.
