There are at least three places where functional business requirements can be found, and software engineers should look well beyond traditional sources of functional user requirements when developing new or customizing existing applications. The three perhaps unusual places where requirements hide include: (1) RFIs/RFQs/RFPs, (2) “small” software, and (3) in-the-trenches discovery.
Business requirements collection and validation in the 20th century was straightforward. We perfected methods, tools and techniques for collecting, validating, modeling and implementing requirements in new applications and customized applications. But then requirements became harder to identify, define and model. Many of the challenges to gathering business requirements comes from the sheer velocity of technology, business models and business processes. We wrap business models and processes into the ever-accelerating need for digital transformation.
Software engineers and applications developers should look beyond the systems development life cycle (SDLC) and similar tools – including Agile – for functional business requirements. The first place to look is RFIs, RFQs and RFPs. In a recent social media application development project, we found many requirements in RFI, RFQ and RFP data. We discovered that business requirements for social media analytics applications are embedded in the RFI, RFQ and RFP data that we collected.
The second place to look for requirements is “small” software. Back in the day when “big” software was all the rage, requirements were modeled and reconciled within functional modules of, for example, enterprise resource planning (ERP) and data base management (DBM) applications. Companies yielded functionality to vendors like SAP and Oracle who embedded requirements directly in their applications. But more recently, and especially in the age of micro-service-based architectures, companies define enterprise requirements differently. In fact, the whole idea of enterprise requirements is a relic of the 20th century, since we’ve discovered that one size seldom fits all, and when it might, it’s extraordinarily expensive. Software requirements engineers should look at decentralized and federated organizational structures to find requirements that satisfy specific (and changing) business unit requirements. They should look at “small” software applications with micro-service architectures that define functional requirements from the bottom-up, not the top-down. The real source of functional business requirements is not in the enterprise, but in the business units and even individual product/service suites. This means that software requirements engineers must develop relationships with “users” before developing or customizing applications.
Finally, software engineers and application developers should look for functional requirements in the trenches. We now know that many organizations are adopting emerging technologies without formal requirements analysis of any kind. We found that many companies have abandoned their obsession with business requirements and have begun to implement a “technology-first/requirements-second” approach to technology adoption, especially the adoption of emerging technology, and that companies focused on digital transformation often adopt emerging technologies immediately – with little or no formal, “validated” business requirements. Requirements heresy? Nearly 70% of the companies do not have a defined process for adopting emerging/disruptive technologies, and most companies – also nearly 70% – have adopted emerging technology without specific, validated requirements.
Software engineers and applications developers should live in the prototyping trenches where requirements are quickly discovered rather than modeled over long periods of time. Our data suggests that companies (across multiple vertical industries) are adopting technology at an unprecedented pace to discover the business requirements they might satisfy. They are learning in real-time. Software engineers and applications developers who want to understand functional business requirements should therefore watch-and-learn from these pilot deployments.
These three hiding places shine bright lights on functional business requirements. While often overlooked, they’re becoming a rich source of requirements data for both business and software professionals. So at the very least, requirements engineers should look at (1) RFIs/RFQs/RFPs, (2) “small” software, and (3) in-the-trenches discovery to better understand, define, model functional business requirements. This will help software engineers and application developers design and develop applications that satisfy business requirements.