As an example, 'a customer can place an order' is far more informative than 'the user picks products from a list then clicks a button that submits an order'.  In the second example -- the business requirement of having customers place orders is lost within the client's interpretation of how the feature should be implemented.  This detail is important later in the process, but for ensuring engagement readiness, having a high level list of 'who can do what' is enough to build a picture of the number and complexity of the features you want to implement. 3. Define the scope Defining scope provides the boundaries within which the vision and 'who can do what' exist.  Ideally you want to provide numbers on expected levels of use, e.g. the number of users, amount of data stored, number of web pages etc.  It's ok to estimate -- but be realistic as designing for high capacity scenarios gets expensive, quickly. If your solution is intended for use outside Australia specify if localisation and globalisation (e.g. multi language, time zone and non-Australian currency) is a requirement. Include what platforms you are targeting.  Typically this is as simple as web or mobile (iOS, Android and Windows Phone being the most common mobile platforms), but can be more detailed when integrating with third parties, extending existing applications or designing applications for the enterprise. Being able to passionately articulate your vision, 'who can do what' and scope is a fantastic start to engaging with suppliers. I strongly