Requirements are the foundation for whatever you intend to build, whether it be software, hardware, consumer product, service or anything else. Just as you would not attempt to build your house on unfinished or faulty foundations, you should not attempt to build your solution without correctly understanding what it has to do, and the way in which it must do it.
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 SchoolThis 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:
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.
Trawling for Requirements
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.
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 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.
Requirements for Agile Projects
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.
Prototypes and Deviations
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.
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.
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.
The Quality Gateway
Managing Your Requirements
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.
Your Requirements Process
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.
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.
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 . . .
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.
For more information ...