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.
“There’s the unicorn stuff, delivering at high speed, with little or no compliance, and little technical debt,” he said. “Legacy systems are all about compliance, with a lot of technical debt. This has created the view that innovation and compliance are orthogonal. Basically, organizations are saying, ‘Pick one.’ But that does not have to be the case.
“It turns out that building a high-velocity development pipeline enables compliance. The requirements you get from a compliance program, for workflow, say, or security, are likely vague and ambiguous. It’s in a 300-page Word document that a developer has to interpret and turn into code. But automation tools [like those used in high-velocity development] let you express that compliance rule in an authoritative way.”
iRise’s Lipson agrees that it is “virtually impossible” to define the work that needs to be done in a Word or Google document. Instead, he and others advocate for prototyping requirements. This, though, involves restructuring teams to include designers, developers and business people all at once from the beginning, not in a staggered or “keeping them in the loop” way.
Prototyping allows for a collaborative and iterative experience for all stakeholders, as end users can annotate the screen and business analysts can refine the model. When all are in agreement, the prototype gets turned into functional and non-functional requirements.
“The big velocity gain is from prototyping,” said Kevin Parker, vice president of worldwide marketing at Serena. “The way in which development happens has changed. We’re in a world of incremental development. There’s an ongoing cadence of fine-tuning what already exists.”
In many organizations, visual designers do the prototyping, turning requirements into screens. Following up on the point made earlier by Microsoft’s Guckenheimer, Lipson said there is “some danger in just looking at a backlog written on a user card without validating. At the end of the day, you’re guessing a feature addresses a need.”
Prototypes of requirements help organizations validate that the new functions or capabilities will satisfy a need.
It’s all about the feedback
Requirements are created primarily in two ways. First, when a company is planning a new product, it needs to decide what it wants it to do. But even then, big requirements are rare, only seen in specialized, highly regulated cases, according to Guckenheimer. Today, he said, organizations “do this little bit, take measurements, learn, then do the next little bit. We learn as we go. This continually reduces the code of uncertainty by gathering the learning to see what we can do next. It’s a totally virtuous cycle.”
The second way to get requirements is through customer feedback. Before organizations “go into the tunnel” to build the software, Guckenheimer said organizations should try things with their customers to understand the problems they’re facing. “This way, we know that if we solve the problems, and we have something that they will say, ‘Yes, we’ll pay for that.’ Now you have a minimal product.
“So you solve problems one and two, now here are the third, fourth, fifth,” he continued. “You grow out the layers of the onion based on what’s important to the customer instead of guessing in advance.”
Even with a huge journey, Guckenheimer said, you prove that journey one step at a time, in small batches that build trust. “You create as many feedback loops as possible, from low-visibility telemetry to who’s using what to high-touch engagement about what they like and dislike.” Organizations should do this, he said, “in order to get that understanding to move the needle to higher customer satisfaction and engagement, and more activity.”
Calling Moscow
The Dynamic Systems Development Method Consortium has devised a way to prioritize requirements called MSCW (or Moscow). There are four components for classifying requirements:
Must have—Without it, you’re not even creating a product
Should have—Not critical, but better with it
Could have—For the evolution of the product, to see what comes down the pike
Wish to have—The “Wouldn’t it be awesome?” feature.
