It long has been understood that requirements are the very first step in the application life cycle. After all, you can’t build what you don’t know, so requirements are what inform software development from the beginning.

Requirements take time to create, though. Business meetings result in ideas for new products or features, and then business analysts need to put that into a form developers can work with to create the software. Often, those requirements are in a large document, delivered to programmers who then have to mentally transpose the language of requirement to a programming language. In the end, the expectation (sometimes more like a hope) is that the developer will have understood the requirement correctly and built the right thing.

Today, though, the name of the game in software development is velocity. Development shops are going agile, reducing projects that took a year or more to finish into smaller deliverables that come out in a matter of weeks or even days. So, the lengthy requirements process doesn’t seem to mesh with high-velocity software development.

“Large companies are moving to agile but still struggle,” said Bryan Lipson, director of product definition at requirements-management solution provider iRise. “They do a requirements document on the business side and hand it to IT. There it gets siloed up into user stories, so [the process] starts traditional but becomes agile. Other [organizations] are real aggressive with agile. They start projects without writing much down, but find they’re using iterations to fix prior iterations. Iterating in code can be expensive… Even in agile shops, there needs to be a process to flesh out and iron out requirements before coding begins.”

As agile has come of age, turbo-charging the life cycle, it’s important for requirements to keep pace. But according Mik Kersten, CEO of Tasktop, “It’s meshing terribly. The bottom line is it has to mesh, but the gears are turning at different speeds. There’s a directive from the CIO to become more agile. Agile’s great. The result is that development is faster, but nothing’s changing in requirements.”

Organizations need to figure out how to get requirements and traceability throughout the life cycle, or “You’re not getting the ROI on your agile investment,” said Kersten. Writing requirements in Word and updating them every six months, he said, “is no longer competitive.”

Chained to legacy systems

Organizations need speed to be competitive, yet most of their outward-facing Web applications are tied to back-end systems that are not designed for quick change. That leaves organizations facing the dilemma of having two-speed (or bimodal) IT. “You need a fundamentally different process for both” delivering new products to new customers and new channels using new technology, and for maintaining and updating the legacy back-end systems, according to Justin Arbuckle, chief enterprise architect and vice president of EMEA at DevOps company Chef.

About David Rubinstein

David Rubinstein is editor-in-chief of SD Times.