Agile or traditional, unless the product solves the right business problem, it has no use. Your requirements process must discover the customer’s real needs in all their subtlety and concealment.

This workshop presents a thorough and well-established process for uncovering the real requirements, testing them for correctness, and recording them clearly, completely and unambiguously. The process is used by both agile and traditional projects. This workshop shows you how to precisely define the scope of the business problem, to discover and involve the appropriate stakeholders, to use prototyping and other modern techniques to learn what the business really needs, to innovate and find better ways to do the work, to communicate effectively and to write testable, unambiguous requirements and stories.

All public courses are available as in-house training. Contact us for more information.

What Will I learn? What Will I be Better at?

The Requirements Process
A quick look at the activities of finding the right requirements, and a short workshop to illustrate the problem.

Project Blastoff
The Blastoff builds a foundation for the requirements project by establishing its Scope-Stakeholder-Goals. It gives you the precise scope of the business area to be studied; a testable goal for the project; and using stakeholder maps, you identify all the sources of requirements. Additionally, the Blastoff ensures the project is viable and worthwhile.

Trawling for Requirements
We show you the most effective techniques to discover exactly what
the customers need, and want. This section introduces the essence of the problem, how to see the real need and not some assumed solution. It also introduces the brown cow model that gives the business analyst different ways of thinking about the problem, and allows the real problem to emerge.

Prototyping for Requirements
Here we use simulations of candidate solutions to explore the problem space, determine that we are solving the right problem, and find imaginative solutions. Multiple candidates are quickly produced which eliminate the assumed solution and provide the right direction for the product.

Functional Requirements
Functional requirements are those things the product must do. You discover them by understanding the real work of the organisation, and determining what part of that work the automated product can best do. The
automated product is specified using well-formed functional requirements.

Non-functional Requirements
Non-functional requirements are properties the product must have, such as the desired look and feel, usability, performance, cultural, conformance, and so on. This section demonstrates the importance of discovering the
non-functional requirements, and shows you how to use the template, and other methods, to find these qualitative requirements for your product.

Requirements for Agile Projects
Requirements are equally important for agile projects, but you go about them differently if your solution is to match the real business needs. Effective agile projects understand that there are two parts: Discovery and Delivery. Discovery involves understanding the real work and the real problem to be solved to deliver the value proposition. It uses business stories to communicate the Discovery findings. Delivery focuses on development of the product and here we see how a story map provides the best guide to the product under development. We also demonstrate how to write better, more effective stories.

Your Requirements Process
You discuss and determine how to make your own requirements process as effective and efficient as possible. This involves incorporating your own organisational processes into the requirements activities. You build a demonstration of how you will use what you have learned when your return to your own workplace.

Workshops
We want you to use this right away. Each of the key teaching chapters is reinforced with a workshop where you apply the concepts presented in the seminar. Participants work in teams to discover, specify and evaluate
requirements for a significant system by:

• Defining the project’s scope, its goals and the relevant
  stakeholders
• Identifying business events, business use cases and
  product use cases
• Evaluating candidate prototypes to find hidden
  requirements
• Defining functional and non-functional requirements
• Writing better stories
• Deriving the fit criterion, or measurement, for the
  requirements

• Determine the real needs of your client
• Uncover the essence of the business and its real requirements
• Use prototypes and sketches to discover hidden needs
• Write requirements that are complete, unambiguous, and testable
• Write agile stories that are more effective and accurate
• Understand the role of the business analyst in agile projects
• Use a story map for more controlled development
• Understand the need for (and how to write) both functional and non-functional requirements
• Precisely define the scope of the project
• Get the requirements quickly, and incrementally
• Discover the right requirements and stories

Is This For Me? Yes, if you want to be involved in delivering the right systems—the ones that get used.

Your title is probably business analyst, systems analyst, product owner, project leader or manager, requirements engineer, consultant, product or program manager or similar. Team members on agile projects benefit from understanding how requirements are done in agile projects. 

Users, software customers and business stakeholders have found that this course equips them to participate more effectively in the requirements process, and so ensure that the end solution matches what they really need.