Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Defining and Managing Requirements with Interactive Prototypes

Defining and Managing Requirements with Interactive Prototypes

This item in japanese

Lire ce contenu en français

InfoQ did an interview with Mike Hughes, senior director of innovation solutions at iRise, about the iRise Enterprise Visualization Platform, a rapid prototyping and requirements platform.

Hughes talks about recent developments in requirement definition and management and how agile teams handle requirements and which problems they face in their daily work, and explains how they can use interactive diagrams and prototypes for conveying requirements. He also discusses how interactive prototyping can be used with a lean startup approach, and what the future will bring us in requirements definition and management.

InfoQ: Can you give an update on developments in requirement definition and management? How is the software industry doing?

Hughes: For years, interest in requirement definition and management tools tapered as teams adopted Agile approaches and focused on the significant cultural shift. I think we’re now seeing a renewed interest in requirement tools that compliment Agile methodologies and help organizations scale their Agile footprint. The reality for many large organizations is that their teams are spread over the world, and these teams are increasingly looking to requirements definition tools to help bridge the communication gap across geographies and time zones.

Also, organizations are starting to recognize that the primary measure of progress is not just "working software," but valuable software. Agile and now DevOps methods have helped teams develop and deploy software faster, but are still finding that the result doesn’t meet the customer need. That’s why we’ve been focused on helping teams zero in as quickly as possible on the right set of requirements that will deliver true business value.

InfoQ: How do Agile teams typically handle requirements, and which problems do they face in their daily work?

Hughes: Most Agile teams leverage user stories to express the needs of the customer - i.e. the requirements. Generally a user story is only one sentence of text, which can leave quite a bit of room for interpretation - particularly where teams are distributed. Simple user stories are often too vague and incomplete to use as the basis of implementation, especially when everyone isn’t sitting in the same room. The result is feedback at the end of your sprint that rejects or significantly rewrites your user stories.

While Agile is far superior to waterfall, we think there’s still plenty of opportunity to improve on this fundamental communication problem. As a product owner, how do you efficiently express the intention of a user story? How do you vet your proposed solution with the business when they’re located on the other side of the world? How do you explain what’s needed to the developer who’ll write the code? How do you ensure that feedback isn’t lost in emails?

InfoQ: Can you explain how interactive diagrams and prototypes can be used between customers and developers to convey requirements?

Hughes: The best feedback comes from customers experiencing software first-hand. Interaction is the key. Showing a picture of a screen is nowhere near as effective as letting somebody click on dropdowns, enter data, navigate between pages, do all of this on their smartphone. This is what makes Agile methodologies powerful - customers experience the software sooner and provide feedback.

That’s critical because customers can rarely articulate their own needs. Only when people actually interact with a product - or, more efficiently, an immersive, functional prototype - do you discover design flaws, requirements errors and usability issues.

So being able to quickly create and share realistic prototypes, then easily incorporate feedback, validates your user stories. Pair this with interactive diagrams to provide context, and you end up with a much more thorough understanding of the requirements and business value. Doing all this before you start writing code is a faster and less wasteful way to get to the right solution.

InfoQ: With DevOps professionals from development and from operations will be working intensively together with their customers. Can you give some examples showing how the iRise tool suite can be used to collaborate?

Hughes: While much of the DevOps focus has been around continuous integration - automated build, verification and deployment of code - it’s important to highlight that the scope of DevOps is the entire software value chain. DevOps includes everyone who is involved in taking an idea through IT to business value.

iRise allows prototypes, interactive diagrams and user stories to be captured and easily shared with the team and customers before coding begins. Integrations with ALM platforms then ensure that information captured in the iRise platform flows automatically to dependent systems. Whether planning tasks, writing code or creating test scripts, all team members should not only be able to easily understand the user stories by seeing them brought to life in prototypes, but also be able to understand the intended business value.

InfoQ: Can you use interactive prototyping with a lean startup approach? Do you have some examples of how organizations are doing this?

Hughes: At the heart of lean startup is a build-measure-learn feedback loop. A realistic prototype can serve the same purpose as running code when it comes to exposing customers to ideas for a minimum viable product and learning from their feedback. Since prototypes can be assembled and easily shared in a matter of hours, new ideas can be tested in a much shorter timeframe.

Case in point, at iRise we do exactly this when we are exploring new product features. By exposing customers to new ideas using prototypes, we’re able to quickly learn and adapt our approach and ensure the development team is focused on building things that we know our customers value.

InfoQ: What do you expect that the future bring us in requirements definition and management?

Hughes: A proliferation of SaaS-based products has provided those responsible for defining software with many options for defining a business problem, describing and vetting solutions and subsequently planning and tracking work. Compared with the very feature-heavy and difficult to install requirement platforms of old, the newer solutions focus on ease-of use and are cloud-based to avoid the challenges of installing software.

However, most products have focused on a subset of the responsibilities of product development, which means that as a product manager you still need to use a number of different products to do your job effectively. This fragmented tool-scape makes it difficult to get a 360 degree view of the product that you are building. Requirements definition and management tools need to evolve, not only for better ease of use and deployment flexibility, but also to provide all of the features that product managers need, and to easily and quickly exchange this information with the other platforms that support the software value stream.

Rate this Article