Check out these related open workshops:
Check out our related in-house workshops:
Everything you always wanted to know about requirements, but were afraid to ask (+ check out this 3-minute video introduction)
During this workshop, Suzanne and James Robertson will answer these and many other questions:
This intensive three-day workshop is entirely focused on discovering the right requirements
|FREE BOOK with your workshop participation:|
This workshop is entirely focused on discovering the right requirements. Requirements are the most crucial part of systems development, and yet the most misunderstood part of it. Requirements must be correct if the rest of the development effort is to succeed. This workshop presents a complete process for eliciting the real requirements, testing them for correctness, and recording them clearly, comprehensibly and unambiguously.
Software development today is more complex and demanding than ever; and there are fewer resources to meet those demands. Getting the software right - the first time - is the most effective way to succeed under these circumstances. Today's requirements process is incremental with quick cycle times. It uses prototypes and scenarios, and it ensures that your developers know precisely what you - and your customer - mean when you write a fit criterion: a concise test case for the requirement.
This workshop shows you how to precisely define the scope of the business problem, to discover and involve the appropriate stakeholders, to use techniques such as apprenticing and use case workshops to learn what the users really need, to write testable requirements, and to phase the requirements to allow incremental delivery of the product.
This workshop is aimed at everyone who wants to deliver the right systems
Yes, if you want to be involved in delivering the right systems: the ones that get used because they work and solve the user's problem - and who doesn't want this? - then this workshop is for you. 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.
|FREE BOOK with your workshop participation:|
This programme is spread over 3 days, from 9h00 till 17h00. There is a morning coffee/tea break, a lunch break, and an afternoon coffee/tea break. Our workshop leaders will answer your questions and talk about your specific business analysis, requirements and/or innovation challenges and problems that you have, after the workshop, from 17h00 till 17h30 (appropriately called the "afterwords").
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.
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 apprenticing, use case workshops, interviewing, brainstorming, mind maps 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 emerge. We also look at innovation - fresh thinking about the problem - and how it is a necessary component of any requirements process.
Functional requirements are those things the product must do. You discover them by understanding the work the user does, and determining what part of that work the automated product can best do. The resulting interaction between user and product is usually modeled with scenarios, and from these, you can readily derive the functional requirements.
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 discusses the types of non-functional requirements, and shows you how to use the template, and other methods, to find the all-important qualitative requirements for your product.
Managing Your Requirements: prepare and discuss your action plan on how you will use these techniques in your day-to-day business analysis and requirements work
Requirements are the lynchpin of any development effort, and so have to be written correctly and managed effectively. This section demonstrates the use of a template to help you write requirements. It looks at requirements management issues like traceability, prioritization and conflicting requirements. We also look at tools to help manage requirements specifications.