|
|
Evaluating the Quality of Requirements: A Primer for Independent Verification Would you tell your publisher to stop editing in the middle of your manuscript and publish your novel now? Of course not! Then, why would you tell your QA/test team to stop identifying problems with requirements documentation? All deliverables—and especially requirements—should undergo a rigorous assessment based on their quality attributes and measurable evaluation criteria. Mark Haynes describes quality models and attributes he has used to evaluate requirements documents. He shows how you can detect imprecision-that will haunt you later-and remove it with a set of formal criteria and informal heuristics. Discover how you can use quality attributes, even subjective ones, to conduct a quality dialogue within the development team. Mark shares examples of poorly written requirements for you to evaluate and try your hand at improving.
|
Donald Haynes, Modis
|
|
|
Refactoring: What You Need to Do It Right As certain as evolving requirements lead to code changes, code changes lead to code degradation. Therefore, code refactoring is critical to the long-term viability of all software products. Kevin Sawicki shares tips and tricks for refactoring to help developers identify code that needs refactoring, preserve the correct code history during refactoring sessions, and ensure that appropriate unit tests cover the refactored code. Kevin demonstrates the Eclipse open-source frameworks and Java-based tools, including EMMA for code coverage analysis and JUnit for unit testing. These tools not only make code refactoring less painful, they also empower developers to constantly improve their code through relentless refactoring. Kevin outlines a step-by-step process to find refactoring candidates, perform the refactorings in an isolated code branch, and collaborate with other developers to review the refactored code.
|
Kevin Sawicki, Perforce Software
|
|
|
The Power of Concept Designs in Requirements Elicitation 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.
|
Scott Plewes, Macadamian Technologies
|
|
|
Involve Your Customers for Better Requirements Have you ever heard something like “This feature (system) doesn't look anything like what I expected and doesn't do what I want”-even though you were confident that you knew what your customers wanted? Jennifer Bonine presents a strategy for involving customers up front and throughout the requirements definition process. She discusses how you can engage customers and set their expectations for involvement in the project before it begins. Jennifer outlines how to identify customer groups to engage in a joint IT–Business software requirements process in which the customers and the technology team work as peers. She describes the skill sets required for developers participating in this process and explores the reality that not every developer will be able to or want to transition to this model.
|
Jennifer Bonine, Oracle
|
|
|
Nonfunctional Requirements: The Forgotten Needs 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.
|
Ellen Gottesdiener, EBG Consulting, Inc.
|
|
|
Business Rules and Data Requirements: In Tandem for Success Business rules and data needs are essential ingredients for a balanced set of requirements and are vital for successful product delivery. When analyzing requirements, some teams focus on business rules at the expense of data. Others dive deeply into modeling data, skimming over or skipping business rules. When it comes to delivery, if either data or rules are inadequately elaborated, you risk not delivering the right requirements and wasting precious time and money. Mary Gorman demonstrates how to leverage behavioral analysis models to discover and detail business rules and data in tandem. After identifying four types of business rules, she describes when to start modeling rules and data together, whom to involve, the skills you need, and the level of detail to explore.
|
Mary Gorman, EBG Consulting
|
|
|
Writing Higher Quality Software Requirements 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.
|
John Terzakis, Intel
|
|
|
Facilitation Patterns for Interaction Satisfaction Good facilitation skills are essential for everyone in development. In fact, everyone facilitates whether they know it or not. If you work on a team, manage an organization, or simply work with others, the opportunity to facilitate arises often. Steven "Doc" List leads delegates in exploring the common patterns and anti-patterns-for both the facilitator and the participants-he's seen and experienced during facilitation interactions. Join Doc for this highly interactive class and have some fun taking on roles like Gladiator, Guide, and Conclusion Jumper. Explore the facilitation behaviors that work-and ones that don't-and participate in activities that provide an opportunity for you to practice new facilitation techniques. You'll laugh and learn, and you'll take away new skills and tools to help you and your team become more effective facilitators.
|
Steven List, ThoughtWorks
|
|
|
Uncovering User Needs with Critical Incident Task Analysis What do users really need? Do they really know what they need? Although developers and testers are expected to implement stories and requirements that add real value, users often describe wants rather than needs and ask for features rather than solutions. Rob Sabourin shares his experiences applying task analysis using the “critical incident method” to better understand user processes and determine needs and desired solutions. Rob does not ask “what the system should do for the user” but rather learns “what the user does with the system.” The critical incident task analysis method is a fast and systematic way to study user experiences and analyze business needs. From brilliant successes and dismal failures we learn to identify and understand the user process.
|
Rob Sabourin, AmiBug.com, Inc.
|
|
|
Avoid Failure with Acceptance Test-Driven Development One of the major challenges confronting traditional testers in agile environments is that requirements are incrementally defined rather than specified at the start. Testers must adapt to this new reality to survive and excel in agile development. C.V. Narayanan explains the Acceptance Test-Driven Development (ATDD) process that helps testers tackle this challenge. He describes how to create acceptance test checkpoints, develop regression tests for these checkpoints, and identify ways to mitigate risks with ATDD. Learn to map acceptance test cases against requirements in an incremental fashion and validate releases against acceptance checkpoints. See how to handle risks such as requirements churn and requirements that overflow into the next iteration. Using ATDD as the basis, learn new collaboration techniques that help unite testing and development toward the common goal of delivering high-quality systems.
|
C.V. Narayanan, Sonata Software Ltd.
|
