requirements

In many current software development approaches, architecture and design are downplayed. Rather than actually architecting products, good designs are assumed to "emerge." Yet, managers must be confident that their products are well designed. In their efforts to produce products quickly, teams may overlook vital architecture and design issues, such as performance, security, usability, and accessibility. When managers try to help, they can be deterred by jargon and tools that are difficult for non-programmers to understand. Jonathan Kohl illustrates a way for managers to understand and influence product architecture and design. You don't need detailed technical skills to provide valuable insight into a project. Learn how to understand an application and its impact in three contexts: the code (where the application is developed), the system (where the application operates), and the social context (where the application is used).

Requirements risks are among the most insidious risks threatening software projects. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry. As requirements expert and agile coach Ellen Gottesdiener explains, agile practice can go a long way in mitigating the top five requirements risks.

My article, "Requirements Come Second," in a recent issue of Agile Journal caused something of a fuss. The piece was picked up by several more sites and was widely commented on - both on websites and in my inbox. I'm not entirely surprised by this reaction, I've been discussing this research for a year or so now and often find it surprises people. Given this level of interest it is worth looking at how people responded. It is also worth restating the key message: Requirements are an essential part of maximizing business value, but when an organization is struggling with effectiveness it is best to start change by improving delivery.

In these times, many of us are being told to "do more with less." A more useful approach is "invest our organization's scarce resources where the return is the greatest." To do so, we must define the financial benefits sought when developing a system in addition to its requirements.