We often hear about “bridging the gap between business and IT”, but the reality is often less glamorous than it sounds. Here are a few truths about why software requirements exist – and why they might always have to. Which ones resonate with you? Be honest.
1. Prescription
Not everyone does well with the โplaceholders for a conversationโ approach; thereโs a good reason why IT folk are often characterised as socially challenged, keepers of their own company. Furthermore, blame culture and toxic work environments have caused many developers to retreat to becoming order takers, not order makers. In these cases, a prescriptive approach isnโt just acceptable, itโs welcomed.
2. Navigation
Many developers would struggle to navigate the complexity of modern workplaces, even if they were keen to do so. Domain knowledge, business knowledge, and system knowledge are rarely located with one person or in the same place. Office politics and informal power structures makes things harder. Conversations and information gathering on behalf of the developer can be the right approach, particularly if they are sitting behind an IDE in a foreign country.
3. Scaling
A few developers โfacing offโ to the business is fine, but adding another 10 or 20 developers changes the dynamic. Subject matter experts quickly become overloaded by Zoom requests from individual developers, imparted knowledge is opaque to other team members, and coordination within the development team becomes a mission. A single planning process that distributes work as requirements allows development to scale.
4. Compliance
Rules, regulations, policies, standards, legislation : the bureaucracy is vast, even for the simplest of applications. No company wants the risk of public social media shaming for non-compliance, but no single developer could possibly know the breadth of compliance required. Clear and effective requirements ensures compliance, keeps regulators happy, and users safe.