Ever been in a situation where everybody on the design and development team thinks they agree on the requirements-until you try to design that first screen or page? Wonder how exactly the same product requirements documentation can mean completely different things to different people? Ever heard users say of a new feature, “This is not what I expected or need”? To minimize the risks of these things happening again, join Scott Plewes and learn to create concept designs early in the project-during requirements elicitation. As a bonus, concept designs help to involve sales, marketing, technology, and other parts of the product team when you are eliciting requirements. Scott explains the risks as well as benefits of concept designs and describes how to gather and share feedback on them to gain the most value from this approach.

Nonfunctional requirements are an essential part of a holistic understanding of system requirements; yet many teams struggle with them. Some neglect nonfunctional requirements during requirements analysis, considering them as less important or supplemental. Or they specify them incompletely and with un-testable attributes. Analysts, developers, and business customers often struggle with when and how to define and document nonfunctional requirements. However, if these requirements are not defined with precision, you will probably not build the right product. Ellen Gottesdiener guides you through the different types of nonfunctional requirements: quality attributes, external interfaces, and design and implementation constraints. She surveys practical techniques to represent quality attributes and how to define their acceptance criteria.

While agile and traditional software development methodologies differ in many key practices, they share the mutual goal of accurately representing customer needs through requirements-whatever their form. If requirements are poorly understood, lack key details, or are interpreted differently by stakeholders, unnecessary defects will be introduced into the product. Defects lead to rework which ultimately delays product delivery and decreases customer satisfaction. John Terzakis outlines proven practices, templates, and techniques you can use for writing requirements that more accurately capture customer needs. He discusses issues with “natural language,” shares ten attributes of well-written requirements, and explores ambiguity checklists. John presents practical templates and syntaxes for stories (aka scenarios), use cases, and traditional requirements documentation.

Organizations that want to automate their testing generally go through a number of stages before they reach maturity. Whether you are about to begin your journey or are well under way, it is important to know where you are going and where you could go. In automating test execution, many organizations stop short of achieving their maximum benefits. This presentation looks at six levels of maturity in test automation and includes a self-assessment test to see where you are. It is important to have good objectives and realistic plans to achieve them. But in automating testing, these often seem very plausible at first but are not well expressed or are unrealistic. This presentation covers typical problems and examples of unrealistic automation plans and objectives. Leave with advice to help you have a successful journey to test automation.