Continuous Architecture and Requirements

CA Book Cover Small 2

Don’t Think Functional Requirements, Think Faster Time to Feedback

As we discussed in Chapter 1 of the “Continuous Architecture” book and elsewhere in this blog, capturing and managing requirements accurately and timely  – especially Quality Attribute Requirements – is an essential part of the Continuous Architecture approach. Traditionally, the approach to capturing and managing requirements has been based on conducting interviews of subject matter experts (SMEs) in order to document  requirements that the system must satisfy, often documented in voluminous documents which are hard to read and analyze. Ideally, the interviewees should be actual or prospective users of the system being developed, but in practice the interviewers often have to settle for representatives from the business who believe that they are familiar with the way the system is (or will be) used.

Requirements Interviews Dilbert

Collecting requirements from user representatives who attempt to guess the needs of real users as well as the best ways to satisfy those needs often result in systems that fall short of real users’  expectations. In addition there is often a significant time interval between the interviews and the delivery of the system, and this may lead to further disappointment as requirements  may change due to evolving business conditions.

As Forrester Research Principal Analyst Kurt Bittner states, “The problem is the SME paradigm itself. No one person can represent the needs of all users, no matter how hard they try. The problem goes deeper: The conscious mind often cannot express what is really needed, and only knows what it doesn’t like when it sees it. As a result, the surest path to success is to put something out there that minimally satisfies some need, sometimes called a minimum viable product, and then improve upon that in rapid cycles.”

The objective of the Continuous Architecture approach is to enable the rapid delivery of a minimum viable product that may be designed to satisfy some need or validate some hypothesis, and will continuously evolve as feedback from the users is received. As we describe in the book and in this blog, we achieve this objective by creating a “minimum viable architecture” that also continuously evolve as user feedback is received, and enables the delivery of a system that meets or even exceeds its users’ expectations.

Please check our blog at and our “Continuous Architecture” book ( for more information about Continuous Architecture.