requirements

Conference Presentations

Ready, Really Ready, and Really Really Ready Stories

Product owners create stories they believe are ready for development. Developers accept and then estimate stories that are not really ready to be started. This disconnect between being “ready” and “really ready” results in miscommunication and frustration. For example, story development can take much longer than original estimates because of the details and “sad paths” that were not expressed in the story. Ken Pugh describes how to turn vague acceptance criteria into specific acceptance tests. He explains how levels of detail in acceptance tests can help to more closely estimate the effort required by stories and shows how acceptance tests determine when stories are complete. With Ken, you’ll go through creating a “really really ready” story and examine when it should be created and who should participate.

Ken Pugh, Net Objectives
Specification by Example: Building Executable Requirements

Specification by Example is a collaborative approach for constructing executable requirements. Examples demonstrate how the system should operate through the eyes of its users and shows understanding of the application’s functions. Michael Connolly demonstrates the practical and easy-to-implement Specification by Example method which he uses to write user stories and acceptance criteria. This direct approach, in which requirements are elaborated via executable code, creates a solid communication bridge between non-technical and technical staff and managers within the organization. Eventually, these executable requirements become the basis for the system’s acceptance test suite. As a take away, Michael provides participants with a lightweight requirements document format and an acceptance criteria framework to help you translate written specifications into automation.

Michael Connolly, OPOWER
Adding Good User Experience Practices into Agile Development

Whose job is it to ensure that the user has a good experience with a new application? As agile processes are taught today, the user experience (UX) design practice is usually left out or at best described as an optional team role. However, the companies that build useful, usable, and desirable software know that UX is baked into the whole development process. Jeff Patton describes what user experience design is and isn’t, and how every person on the team has something to contribute. Hear concrete examples of how companies have adapted their UX practice to work well in an agile context and, along the way, discovered innovative UX practices that work better in agile contexts. Jeff explores pragmatic personas, guerrilla user research, design sketching, lightweight prototyping, and concept testing. Leave with valuable tips for adding UX practices and thinking to your agile process to help you get good user experience.

Jeff Patton, Jeff Patton & Associates
Optimal Project Performance: Factors that Influence Project Duration

Speedy delivery is almost always a primary project goal or a significant project constraint. To shorten project duration without sacrificing quality or budget, you need to know where to focus the team’s efforts. Mining the QSM database containing many quantitative metrics and numerous qualitative attributes, Paul Below shares the factors that have the greatest influence on project duration. While he’s at it, Paul debunks a couple of myths. For example, many managers consider team skill to be important in determining duration of software projects-not so. The most important factors are certain types of tooling, architecture, testing efficiency, and management/leadership skills, which Paul explores in depth. Learn a technique for normalizing your projects for size by computing the standardized residual of duration.

Paul Below, QSM, Inc.
The Mis-education of Software Testers: Rethinking and Relearning Software Quality

The role of the software tester is continuing to evolve, becoming more complex and more technical. As new methodologies, technologies, and platforms emerge, testers are bombarded with new, so-called "best practices" on how to do their jobs. The problem is that testers have heard the same songs with different lyrics for more than twenty years now. Clint Sprauve takes a contrarian’s view of testing and the quality assurance industry. He examines some of today’s typical testing "best practices"-keyword-driven testing, requirements traceability, the tester’s role in agile development, quality reporting, tool expertise, and quality certification programs-while providing alternative approaches for how to view each practice.

Clinton Sprauve, Micro Focus
How to Rework Poorly Defined Requirements

Poorly defined requirements are even more dangerous than no requirements because they offer the illusion that all is well during development. However, when user acceptance testing begins, requirements problems surface and the users rightly say, “I don’t care that the system test has passed, this isn’t what we need, and we won’t be signing off.” Steve Caseley reviews the actions he took to rework the requirements on two failed projects and the changes he made to get new projects off to the right start. Steve explores how statements such as “new reports must be balanced with the old reports” were re-written to identify quantifiable variances. He shows how other loosely defined requirements were reworked to provide clear mapping of measurable requirements to expected test results.

Steve Caseley, CBTNuggets
Agile Development Conference & Better Software Conference West 2012: EARS: The Easy Approach to Requirements Syntax

One key to specifying effective functional requirements is minimizing misinterpretation and ambiguity. By employing a consistent syntax in your requirements, you can improve readability and help ensure that everyone on the team understands exactly what to develop. John Terzakis provides examples of typical requirements and explains how to improve them using the Easy Approach to Requirements Syntax (EARS). EARS provides a simple yet powerful method of capturing the nuances of functional requirements. John explains that you need to identify two distinct types of requirements. Ubiquitous requirements state a fundamental property of the software that always occurs; non-ubiquitous requirements depend on the occurrence of an event, error condition, state, or option. Learn and practice identifying the correct requirements type and restating those requirements with the corresponding syntax.

John Terzakis, Intel Corporation
Agile Requirements Readiness ... and the Role of Testers

Mature agile teams work together to ensure sufficient requirement information is ready when an iteration starts. However, on many teams, developers lack this support and may receive overly detailed-and often ambiguous-requirements that are “thrown over the wall.” Drawing on recent industry research and successes of companies with which he’s worked, Chris Duro shares stories from three companies that evolved an agile adoption requirements readiness assessment framework. They used this framework to quantify the requirements problems, obtain management visibility, and win improvements in their requirements process. Chris answers key questions about the framework: How is readiness defined and measured? What is the tester’s role in agile requirements development? How can agile teams check thousands of requirement document pages automatically?

Christopher Duro, Cognizant
Agile Development Conference East 2011: A Software Quality Engineering Maturity Model

You are probably familiar with maturity models for software development such as CMMI. In this thought-provoking session, Default.aspx Pope and Ellen Hill describe a corresponding five-stage maturity model for software quality engineering-not just testing-which addresses the challenges organizations face when attempting to improve the their software’s quality. Default.aspx and Ellen introduce their model for software quality maturity and discuss how you can use this model to baseline your organizations' current level and map out a path for improvement. You'll learn how to assess where you are now on the ladder: (1) do nothing, (2) write documents and create forms, (3) measure the process, (4) improve based on metrics, or (5) automate tools and process.

Gregory Pope, Lawrence Livermore National Laboratory
Testing in the Cloud: Is it Right For You?

Finally, software testing in the cloud is not just for dreamers anymore! Join Andrew Pollner to explore why and how cloud-based testing is emerging as a viable alternative to replace or complement traditional testing platforms. Implemented properly, cloud testing offers many advantages: shifts the burden of installing, configuring, maintaining, and updating testing tools to a vendor; reduces or eliminates the need to build and maintain servers to support testing functions; expands the reach of testing across geographical locations; offers potentially limitless capacity; and more. However, with all these benefits come new challenges: determining the appropriate cloud test environment, test data security, connectivity to the environment, and others.

Andrew Pollner, ALP International Corp

Pages

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.