Software can solve almost any problem. The problem is that we don't always understand what the problem is. Understanding the problem—the real problem—is the role of the requirements process.
This workshop presents a complete process for uncovering the real requirements, testing them for correctness, and recording them clearly, comprehensibly and unambiguously. This requirements process starts with the business—for it is only within the business that you can discover the real needs. When you know the real needs, it is possible to determine the system that best serves those needs, and to specify, completely and innovatively, the requirements to get the right system built.
"Absolutely fantastic course, will be extremely useful for me." — Leanne O’Connor, Application Development Officer, Mt. Eliza Business SchoolThis workshop shows you how to precisely define the scope of the business problem, to discover and involve the appropriate stakeholders, to use today’s 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.
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 2.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, project leader or manager, requirements engineer, consultant or similar. Or if you are a user or software customer and want to ensure the requirements process delivers what you need.
"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.
What will I learn? What will I be better at?
This builds a foundation for the requirements project by establishing its Scope-Stakeholder-Goals. This gives you the precise scope of the business area to be studied; a testable goal for the project; and using stakeholder maps, you can identify all the sources of requirements. Additionally, the blastoff ensures 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 apprenticing, use case workshops, interviewing, brainstorming, and other techniques to discover exactly what the customers need—and want.
This section introduces the brown cow model that gives the business analyst different ways of thinking about the problem, and allows the real problem to be solved 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 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 requirements. We also show you how to use agile story cards as a way to capture the needed functionality.
Non-functional requirements are properties the product must have, such as the desired look and feel, usability, performance, cultural aspects and so on. This section demonstrates the importance of correct non-functional requirements, and discusses the various types. It shows you how to use the template, and other methods, to find the all-important qualitative requirements for your product.
Being agile does not mean being able to do without requirements - the end solution still has to match the business needs. It is just that requirements are done differently for agile projects. This section shows you how to incorporate sensible requirements practices into your project, and importantly, how to write the best user stories.
Prototyping is a way of discovering requirements by testing mock-up products for the user’s work. Here we look at the merits of both low and high-fidelity prototypes, and how they and scenarios are used to discover previously-hidden requirements. We also look at the wanted alternatives, unwanted exceptions and potential misuses of the product.
This section addresses the need to communicate requirements—how to formulate them and how to include an unambiguous fit criterion. This makes the requirement testable, as well as ensuring the implemented solution precisely matches the client’s expectations.
Testing is most effective when it is done early in the development cycle. Here we demonstrate how to test requirements before they become part of the requirements specification. The Quality Gateway rejects out-of-scope, gold-plated, non-viable, incorrect and incomplete requirements.
Requirements are the lynchpin of any development effort, and so have to be managed effectively. We look at strategies for your requirements project, 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 model 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 use this right away. Each of the 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:
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 ...