img
Mastering the Requirements Process
Getting Requirements Right  —  Traditional • Agile • Outsourcing

Requirements. The most crucial part of development. You can overcome poor planning; you can overcome poor coding. But nobody has ever succeeded with poor requirements. Requirements are the underpinnings for whatever you intend to build, whether it be software, hardware, consumer product, service or anything else. Simply put, only the right requirements will get you the right solution.

Requirements discovery is no longer about producing large, unreadable (and often unread) specifications. Requirements today is about uncovering the real needs of the problem space, understanding the needs of the people who use your solution, the environment for the solution, and then, in a timely manner, delivering requirements that are concise, clear and testable.

"Absolutely fantastic course, will be extremely useful for me."  — Leanne O’Connor, Application Development Officer, Mt. Eliza Business School
This workshop — presented by a real business analyst — gives you a thorough and well-established process for uncovering the real requirements, testing them for correctness, and ensuring that all the requirements have been discovered. The process is used with variations by both agile and traditional projects. It starts with the business, for it is only within the business that you discover the real needs. When you know the real needs, it becomes possible to determine what will best serve those needs, and to write the requirements or stories to build the right solution.

This course is endorsed by the International Institute of Business Analysis (IIBA™). It provides material and skill relevant to the Business Analysis Body of Knowledge (BABOK™) version 3.0.


You Will Learn How to:

  • Determine the real needs of your stakeholders
  • Uncover the essence of the business
  • Learn diverse elicitation techniques to uncover the real requirements 
  • Write agile stories that are more effective and accurate
  • Understand the role of the business analyst in agile projects
  • Write requirements that are complete, traceable, and testable 
  • Use the Volere Knowledge Model to ensure you have all the needed information, and nothing that is not needed 
  • Understand the need for, and how to write, functional and non-functional requirements.  
  • Precisely define the scope of the problem 
  • Discover all the stakeholders and keep them involved 
  • Use prototypes, sketches and storyboards to discover hidden needs
  • Get the requirements quickly, and incrementally 
  • Use state of the art requirements techniques 
  • Write 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 best done in agile projects. 

"The continual use of real examples and experience made it all come to life. The best course I have ever attended. All questions were answered and none dodged".  — Wes Mar, Senior Analyst, Insurance Australia Group.

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. 


What will I learn? What will I be better at?

The Requirements Process

The course begins with an overview of the process. It looks at how agile and traditional projects both need requirements but are done differently, the requirements food chain, and the topics to be covered by the course. Students discuss with the instructor their particular problems and objectives for the course.

Project Blastoff

The blastoff builds a foundation for your requirements project by establishing its  scope, its stakeholders and the goal. The scope is the problem space or the business area to be studied. The stakeholders are the people with an interest in the outcome. The goal is testable, and ensures that the project will deliver stakeholder value. The Blastoff is also there to ensure that the project is viable and worthwhile.

Trawling for Requirements

At the core of any requirements process is the ability to get people to tell you what they really need, rather than their perceived solution, or what they think you might be able to deliver. We show you how to use business events, apprenticing, use case workshops, interviewing, brainstorming, personas and other techniques to discover exactly what your stakeholders do, and what they need to do it.

This section introduces the brown cow model that gives the business analyst different ways of thinking about the problem, and allows the essence, the real problem to emerge. We also look at innovation – fresh thinking about the problem – and how it is a necessary component of any requirements process.

“The course not only treated the technical aspects but also the softer subjects in requirements gathering like psychological aspects”.  — Ron Buskens, Oce Technologies

Functional Requirements

Functional requirements are the things the product must do. You discover them by understanding the real work of the organisation, and determining what part of that work your solution can best do. 

The solution is usually established using scenarios – these are great if you need a sign-off – and then specified by well-formed requirements or stories.

Non-functional Requirements

Non-functional requirements are properties the product must have. These include the desired look & feel, usability, performance, cultural, conformance, and so on. Non-functional requirements often determine the success or failure of solutions, so this section demonstrates their importance, and how to find and then precisely specify the qualitative requirements for your solution.

Requirements for Agile Projects

Requirements are equally important for agile projects 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 if you are to deliver the value proposition. It uses business stories to communicate the Discovery findings. Delivery focuses on iterative development and how a story map provides the best guide to the product under development. We also teach you how to write better, more effective stories.

“It was a great pleasure for all of us to take part in this training. James is very professional, training materials are great, and we all enjoyed the three days. It was also very inspiring for every Wargamer who was there and I know we will improve our work using what we learned.”  — Tatiana Labkovich, Wargaming

Prototypes and Deviations

Prototyping is a way of discovering requirements by sketching wireframe solutions. Here you assess the merits of low and high-fidelity prototypes, and how scenarios can be used to discover previously-hidden requirements. You also look at the wanted alternatives, unwanted exceptions and potential misuses of the product.

Writing Requirements

There is a need to communicate requirements – how to formulate them and how to include an unambiguous fit criterion. The fit criterion makes the requirement measurable and testable, as well as ensuring the implemented solution precisely matches the client’s expectations.

Volere process

The Quality Gateway

Testing is most effective when it is done early in the development cycle. Here we demonstrate how to test requirements so that the developers receive the correct requirements. The Quality Gateway assesses the requirements and rejects any that are out-of-scope, gold-plated, non-viable, incorrect or incomplete.

Managing Your Requirements

Requirements are the lynchpin of any development effort, and so must be managed effectively. You are given strategies for your requirements management, the requirements knowledge model, how to prioritise requirements, and how to resolve conflicting requirements. We take a quick look at tools to help manage requirements.

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 activity. You build a demonstration of how you will use what you have learned when your return to your own workplace.

"The course is grounded in the real world of requirements elicitation. It measures excellently." — John Purssey, ProQual Consulting.


Workshops

We want you to be able to use this right away. Each of the teaching chapters is reinforced with a workshop where you apply the concepts presented in the seminar. You work in a small team to scope the problem space and then discover, specify and evaluate requirements for the solution.


There's More . . .

  • Your instructor is not an “announcer”. He or she is a practicing business analyst who also happens to be an excellent instructor.
  • The course is written to show real-world situations and provide real-world solutions. You will be able to relate your own work situation to the course. 
  • You can discuss your own requirements issues with your instructor. 
  • The course teaches that requirements come from understanding the business and its internal processes, and how the business interacts with its external customers. 
  • The course provides a realistic framework for requirements discovery, not a strict methodology. The framework provides the freedom and encouragement to adapt to your own organisational needs.
  • The techniques are applicable regardless of your development method – agile, traditional, or anything else. 
  • The Brown Cow model to give you different and beneficial ways to look at the problem. 
  • The Volere requirements knowledge model which ensures you collect the right information, and the right amount of it. 
  • You receive the Volere Requirements Specification Template (downloaded over 20,000 times) with advice on how to make this your own template.
  • You receive a free copy of Suzanne and James Robertson’s book Mastering the Requirements Process—Third Edition: Getting Requirements Right.
  • This course This course is endorsed by the International Institute of Business Analysis (IIBA™). It provides material and skill relevant to the Business Analysis Body of Knowledge (BABOK™) version 3.0. 21 CPU/PD Hours 

Learning from Experience

This course was written by James Robertson and Suzanne Robertson, creators of the Volere requirements techniques.

"Excellent! Great delivery from experienced business analysts (not a "trainer") with up to date work practices and examples." — Sandra Pilgrim, CGU Insurance.

Suzanne Robertson is co-author of Mastering the Requirements Process, Third Edition: Getting Requirements Right (Addison-Wesley 2012) a book that provides guidance on finding requirements and writing them so that all the stakeholders can understand them. Her other requirements book, Requirements-Led Project Management (Addison-Wesley 2005) addresses how to use requirements as input to planning and management. She is also co-author of the Volere approach to requirements engineering.

She has more than 30 years experience in systems specification and building. Her courses on requirements, systems analysis, design and problem solving are well known for their innovative workshops and practical applicability. Current work includes research and consulting on finding and involving the right stakeholders, the building of requirements knowledge models and running audits for assessing requirements specifications. She is a principal and founder of The Atlantic Systems Guild and is founding editor of the Requirements column in IEEE Software magazine.

James Robertson is a consultant, teacher, author, project leader whose area of concern is the requirements for products, and the contribution that good requirements make to successful projects. James is a leading proponent of the principle of introducing creativity into the requirements process. His controversial article "Eureka: Why Analysts Should Invent Requirements" in IEEE Software has provoked heated discussion and has been widely quoted. Before becoming a systems engineer, James trained as an architect and his experience in that profession provides inspiration for his work on innovation and creativity. He is co-author of Mastering the Requirements Process, Third Edition (Addison-Wesley 2012), Requirements-Led Project Management (Addison-Wesley 2005), the Volere approach to requirements engineering, and Complete Systems Analysis: the Workbook, the Textbook, the Answers (Dorset House, 1994), a two-volume text and case study that teaches the craft of systems analysis.


Join the Move to Better Requirements

If you want to join the elite band of software developers whose systems are used-and enthusiastically used-then come and participate when one of the industry's most respected names explains how you can get the most value from your requirements gathering activities.

It will take three days out of your schedule, and we will give them back to you with interest (think how much extensive modification and abandoned systems cost you). We know that when you use a better requirements process, you will save months of maintenance effort, be more responsive to user requests, and avoid building systems that end up as shelfware.

Find out how you can gather requirements that deliver your systems earlier, and ensure that they are used, and useful.

Download a pdf copy of this course description. Download a pdf copy of this course description. (320 KB)



For more information ...

For information about in-house or public courses, consulting or other services, contact us or your nearest agent. Scheduled public courses are shown in the Volere events column of the Home page.


img
The content of this site is copyright 1995-2016 Atlantic Systems Guild Ltd. Please contact us if you wish to reproduce any of it.
img