Online Training and Webinars

Software Requirements Essentials

Based on the popular book Software Requirements Essentials by Karl Wiegers and Candase Hokanson, this three-hour course describes 20 requirements practices that every software team should perform. These core practices help project and product teams understand the business problem, engage the right participants, articulate effective solutions, communicate information among stakeholders, implement the right functionality in the right sequence, and adapt to change. The topics presented include:

What different types of requirements are
The 20 essential requirements practices
How to apply those practices on agile, traditional, and hybrid projects
How to perform business requirements activities that create a solid foundation for a project
How to represent requirements information of various types using various textual, tabular, and graphical techniques
How to define requirements baselines and manage changes to them
Many short exercises that provide a bit of practice with the techniques presented
And much more

More Information and Purchase

Live Webinars Available

These one-hour webinars can be presented to companies, professional organizations, and on-line conferences. Contact us to inquire about scheduling.

Essential Requirements Practices

Many big books on software requirements and business analysis recommend dozens and dozens of practices. It's daunting to try to remember—let alone implement—them all. However, every team should perform 20 core requirements activities. These lay a solid foundation for success and help teams efficiently and effectively elicit, analyze, specify, validate, and manage their requirements. These practices are valuable for both traditional and agile projects, regardless of the kind of product you're building.

This presentation identifies those 20 core practices and drills down into several of them. They can help project and product teams understand the business problem, engage the right participants, articulate effective solutions, communicate information among stakeholders, implement the right functionality in the right sequence, and adapt to change. Do you have to perform all 20 of these on your project? Maybe not, but you'll get better results if you do.

Quality Begins with Requirements

If you don't get the requirements right, it doesn't matter how well you execute the rest of the project: you will fail. A powerful strategy for success is to push quality to the left side of the development schedule, rather than trying to patch it in through rework after the fact. Building a solid foundation of requirements for each development increment contributes strongly to that strategy.

This presentation summarizes twenty core requirements activities that every software project should consider performing. These practices help teams efficiently and effectively plan, elicit, analyze, specify, validate, and manage their requirements. These practices are valuable for both traditional and agile projects, regardless of the kind of product you're building. Does your team have to perform all of these practices? Maybe not, but you'll feel less pain and build higher-quality products if you thoughtfully apply most of them.

Elements of Requirements Style

This presentation describes numerous techniques for writing software functional requirements, focused on the core objective of clear and effective communication. You'll see multiple styles of writing functional requirements and you'll learn many vague "weak words" to avoid. The presentation describes several common types of requirements ambiguity and shows how to rewrite ambiguous requirements to make them clearer. We'll also explore the common issue of having solution ideas or design constraints embedded in requirements. Applying the techniques presentation will help your requirements speak more clearly to their various audiences.

Thorny Issues in Software Requirements

Many software organizations struggle with the same issues when it comes to requirements. Such troublesome topics include: how to define project scope; the connection between use cases and functional requirements; distinguishing requirements from design; and how to use requirements management tools effectively. Some of the questions I'm asked repeatedly don't have simple answers that fit all situations, such as, "How detailed should the requirements be?" and "Is it okay to duplicate requirements?" This presentation addresses ten such tricky topics in requirements engineering. I'll explain why each issue is important and offer some practical advice about how to deal with each of them.

Software Requirements: 7 Critical Success Factors

People who have been writing software for a while understand the value of developing solid requirements to guide development. But eliciting, analyzing, specifying, validating, and managing requirements is hard, and not everyone understands why these activities are so important. This presentation describes seven critical success factors that will help make the requirements activities in your organization pay off for the many project stakeholders. The success factors are:

A shared understanding of what requirements are and why we care
Clearly defined business objectives
Trained, skilled, and motivated business analysts
A collaborative partnership with customers
Rigorous and ongoing requirements prioritization
Taking an incremental and iterative approach to requirements development
Anticipating and accommodating change

The Use Case Technique: An Overview

Use cases are an effective and widely used technique for eliciting software requirements. The usage-centric approach focuses on the goals that users have with a system, rather than emphasizing system functionality. This talk presents an overview of the use-case approach to requirements elicitation in a practical and straightforward fashion. Topics covered include:

Where use cases fit into the business analysis process
Types of projects for which use cases are and are not well suited
Use cases, scenarios, and user stories
User classes and actors
Components of a use case
Deriving functional requirements from use cases

Software Requirements and Organizational Culture: 10 Lessons Learned

When a software organization wants to improve how it works, it's not enough to write procedures, buy tools, and train the team. People who lead a change initiative also must consider the organization's culture. A software engineering culture is a set of beliefs, behaviors, and technical practices that define an environment in which all team members are committed to building quality software products through effective and appropriate software processes. As requirements form the foundation of all the software work that follows, it's especially important to instill a set of effective values, principles, and practices around requirements practices. This presentation describes 10 lessons learned from leading requirements improvement initiatives, including these:

A commitment to effective requirements is a hallmark of a healthy software engineering culture.
Clearly defined business requirements set the direction of a successful project.
Stakeholder engagement is a vital contributor to building high-quality software.
Taking a usage-centric approach instead of a feature-centric approach during elicitation better meets user needs.
The business analyst plays a central role in understanding and communicating a project's requirements.
No single view of the requirements shows you everything you need to know.
A guiding principle of requirements development is "iterative refinement of detail."
Addressing nonfunctional requirements contributes significantly to user satisfaction.

Software Development Pearls of Wisdom

Experience is a powerful teacher, but it's also slow and painful. Software practitioners can't afford to make every mistake others have suffered. You can compress the education and bypass much of the pain by absorbing lessons from others who have already climbed the learning curves.

Based on my more than 50 years of software experience and 25 years of helping software teams succeed in nearly 150 organizations, the book Software Development Pearls presents 60 lessons you can apply to projects regardless of the application domain, technology, development lifecycle, or your role. These pragmatic principles, perspectives, and practices cover six crucial domains of project success: requirements, design, project management, culture and teamwork, quality, and process improvement.

This presentation briefly introduces 24 of the 60 lessons and drills down into six additional lessons. Collecting such pearls of software wisdom can pay off quickly for anyone striving to build high-quality software products, whatever their project role may be.

The Thoughtless Design of Everyday Things

Why do so many software systems and physical products seem to have been designed by someone who has never used a product like that before? This presentation explores that mystery. You'll see numerous examples of thoughtlessly designed products that violate nine fundamental principles of good design, along with some examples of particularly effective designs.

By studying such products we can identify lessons that can help designers, product development managers, and even consumers. I'll share nearly 20 of those lessons with you in this presentation. You'll also hear about multiple techniques that can help designers craft products with a focus on how consumers will use them, not just on their features.

Software Peer Reviews: An Overview

This session presents an overview of the technical, social, and cultural aspects of software peer reviews for managers, customer representatives, and other stakeholders in the software process. It distinguishes peer reviews from other types of project reviews and describes benefits that various project participants can reap from reviews. Some of the many published results of measured benefits from different organizations help build the case for performing reviews. The peer review formality spectrum is described, as are the major characteristics of inspections and other types of less formal reviews. The role that managers play in a review process is emphasized with 10 signs of management commitment to a review program. Finally, several key success factors for a review program are presented, including review traps to avoid and peer review do's and don'ts.

The Soft Side of Peer Reviews

Peer reviews are both a technical practice and an interpersonal interaction. Asking colleagues to point out errors in your work is a learned—not instinctive—behavior. This presentation describes some of the cultural and interpersonal aspects of peer reviews that must be considered when trying to install a review culture in an organization. Suggestions are provided for how a reviewer should present feedback in a nonjudgmental way. Some aspects of management attitudes and behaviors are discussed, including 10 signs of management commitment to reviews.

Reasons why people do not perform reviews and ways to overcome them are explored, including factors related to lack of knowledge, cultural barriers, and simple resistance to change. Some of the benefits that people performing different project roles can enjoy from a successful peer review program are itemized. The presentation also addresses some aspects of holding reviews that involve participants from different cultures.