How to write an effective Business Requirements document

Requirements documents are critical because they are used by the IT team, the testers and form the 'contract' that describes the business needs. But no-one, not least the business, has the time or the desire to read a lengthy requirements document. This is even more true in this world influenced by Agile.

Do you want to know how to communicate the business needs quickly and concisely?
Would you like to know how to decide what should appear in a requirements document?
How can you make sure the business understand the document but it also provides all the detail that the IT team require?

The webinar covers what makes a good requirement, how to maintain separate document for Business Requirements and Functional/Non-functional/Technical Requirements. It provides insights into what should be captured in requirements documents for business and IT teams and the steps you can take to help better communicate to the business so they understand, if your team are using Agile/Scrum and User Stories.
  • How to write an effective business requirements document?
  • What makes a good requirement?
  • How do you evaluate your requirements for completeness and accuracy?
  • How do I ensure the User Requirements Document is correct & consistent, where do I need to identify & quantify the quality attributes?
  • How can we avoid missing requirements in Agile world?
  • Do you maintain a separate document for Business Requirements and Functional/Non Functional/Technical Requirements?
  • Which is better, requirements catalogue or use cases?
  • Difference between biz, functional and tec reqts, & how to define what's on us v/s dev @ large enterprise companies?
  • What is a good balance in the level of detail between Business requirements versus System Requirements versus a Solution doc?
  • What factors must be prioritized when tailoring the requirements documentation according to the Project management methodology?
  • How can we document business processes and requirements together? i.e. a hybrid document that gives context?
  • How can you make sure the business understand the document but it also provides all the detail that the IT team require?
  • How to make the requirement document easier to understand by the business users as they need to review and sign-off?
  • Technical teams require a different level of detail to the business - how do we meet the expectations of both stakeholder groups?
  • Do we need different kind of requirement document for different kind of audiance..?
  • Is there an easy technique of encouraging people to define their needs rather than the solution they have already decided on?
  • How do you get the business to quit waffling on what they want so you can nail down the requirements?
  • What should be recorded in a Requirements document when the team is utilising Agile/Srum and User Stories?
  • If an project is trying to mix agile and waterfall, how would you suggest writing the requirements document?
  • How about user story driven requirement document?
  • How to write effective bus. reqs. in an Agile environment
  • Can a business requirements document be used in an agile setting?
  • How can a requirements document help with traceability in user stories?
  • Where is the line between business requirements compared to technical specification with Agile development?
  • Given today's agile development practices, what is the best way to outline requirements without being too generic?
  • When is a business requirement big enough to be its own backlog item?
  • What are the top 5 must have items in a requirements document?


Suzanne Robertson

Requirements is a socio-technical discipline and business analysts/requirements engineers need a diverse mixture of skills. The ability to use modelling languages, requirements definitions and other technical formalisms must be combined with the ability to communicate with diverse people. Instead of expecting stakeholders to “give” the requirements analysts need to be interested in why people behave in different ways and how to make the human connections necessary to “discover” the requirements.

I have worked as a programmer, systems analyst, designer, business analyst, product manager and project manager in many countries. Industries I have worked in include rocket science, insurance, retail and banking. I continue to research and experiment with new ideas and to make them accessible to business analysts. I do this with a mixture of consulting, research and teaching. The skill of systemsthinking is the thread that runs through all of my work

Jody Bullen

Jody Bullen has extensive experience delivering successful complex business and software projects in various industries both in NZ and the UK. As the founder, Jody is a key driving force behind Yonix. He was awarded Computerworld New Zealand Business Analyst of the Year in 2009. Jody is an active member and thought leader within the Business Analyst community, and has presented in New Zealand and internationally.

David Morris

Is a business agility practitioner, coach, and instructor; delivering product management, business analysis, team leading, facilitating, coaching, and training services to customers throughout New Zealand – currently working with Fiserv as a Product Owner on one of their scrum projects.

With nearly 30 years’ experience in project delivery, he has worked in and led teams and run his own business across strategic, business, and technical projects following structured, iterative, and agile methodologies. He is certified as a BA professional, agile practitioner, and as a scrum-master; runs study groups and training courses; organises, chairs, and talks at conferences and events in Europe and Australasia; has contributed to several books (including the ‘Agile Extension to the BA

Get a 60-day free trial of the Professional Functionality
Try every feature, add unlimited users, no credit card required