Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].
ON THE WEB
My thanks to Requirements.com for hosting this web page - allowing me to consolidate links to articles and other resources I’ve produced during the final 10 years of my 50-year career in information technology. The objective is to inform business analysts who have found items I’ve...
Having to tackle product requirements is not always easy especially when faced with a complex business domain. This task can be less daunting if the practitioner comes prepared with a framework of the types of scenario that (s)he might encounter. In this article, experienced...
Part 5 of Dan Tasker’s Requirements in Context series moves on from high-level requirements to detailed requirements, discussing the importance of capturing detailed data-specific business needs in a data dictionary (DD).
The primary objective of the Requirements In Context series is to help business analysts improve their elicitation and documentation of requirements. It does this by providing a clear distinction between high-level and detailed requirements and, for detailed requirements, offering...
Part 6 of Dan Tasker’s Requirements in Context series discusses detailed business needs for a user interface (UI) or report, and capturing those needs as detailed requirements in a spreadsheet-based template for user interface.
Part 4 of Dan Tasker’s Requirements in Context series provides guidelines for what a business analyst should and shouldn’t include in a high-level requirement (HLR). It begins by comparing a formal HLR ‘shall’ statement to a user story. What is similar about them is that...
Part 3 of Dan Tasker’s Requirements in Context series continues to look at high-level requirements, narrowing the context to that of a project charted to deliver an IT-bases solution. It discusses how scope statements that identify functional capabilities are a good source of HLRs.
Having established “Business Information Systems” as the context for his series of articles on requirements, Dan Tasker introduces a three-level generic functional model applicable to any organization. The highest level, considered to be “… a view from 10,000...
"Context is everything"... at least when it comes to requirements. Regardless of the software development methodology used, the need to deal with requirements is real. Whether they are called user stories, features, capabilities, use cases, or any other name - understanding,...
The objective of this article is to provide business analysts with guidelines for distinguishing between high-level requirements (HLRs) and detail requirements (in IIBA® BABOK® V3 terms – Stakeholder requirements and Solution requirements respectively).
Requirements.com is trusted by leaders and experienced professionals across the world. Start your subscription today, for free.
it's all about requirements
for business analysts, data analysts and more...
one byte at a time!