i.I know a thing for sure: it is only you [a user] and your task; a piece of work to perform in order to achieve a state that is meaningful from an organisational point of view. Note that there is no difference whether the task is to be performed by a fully automatic system function or by a manual user with no computer support.Nothing more to say, when it comes to theory. Now about the book.ii.I strongly believe in an approach the authors propagate. Discovering user requirements means you are not thinking about any particular software, hardware or technology. What you are trying to achieve is finding out what a pure state of things is supposed to occur. Unless you forget about IT, this is not a daunting task. Easier said than done.iii.For ordinary people wanting to identify and gather REAL & PURE user requirements, this book might be a perfect companion. You will not find here any technical stuff concerned with the internals of a computer application, so much beloved by (some) hard-codders, especially the young ones not wanting to hear about messy organizational workflows.Even if you are a species coming from a planet IT, you should read the book. There is only one but: DO NOT SEEK TO DISTANCE YOURSELF FROM REALITY, that is the world of non-technical users having nothing in common with classes, events, services or rules. Ask yourself this: why the hell a nice&competent girl from Customer Service Department is supposed to tell the difference between A BUSINESS SERVICE (i.e. a building block of SOA) and CUSTOMER SERVICE (i.e. a business function)?The book is certainly intended for those interested in WHAT a product [not always being a system] is supposed to do, instead of HOW app developers are going to make THE WHAT happen or with what technology THE WHAT might be designed.IF'I wanna know how to precisely define what problems a product must [requirement] and could [affordance] solve in such and such circumstances [constraints]'is trueTHEN'do read the book'.iv.The authors clearly state about the differences between functions, requirements, constraints, and capabilities. All of this without being fluffy. I, for instance, could never agree there exists sth called “a functional requirement”. It is not an appropriate phrase, an oxymoronic one, I’d say. Either FUNCTION or REQUIREMENT. Period.v.This book might be of considerable assistance to analysts or users wanting to learn rules of defining requirements related to grammar. It'll help you recognise:a) which words or phrases are of no or little use (there are many such words);b) how to build sentences when writing requirements (educated native speakers may fail to write clearly);c) how to separate requirements from design (needs versus solutions, business versus technology);d) how to avoid ambiguity and wishful thinking (the latter occurs when you know what a process is supposed to do, but do not have even the slightest idea how it really works).Last but not least the book does not contain even an iota of abstract ideas.