On Requirements Elicitation

1. Be not an order-taker - either as Business Analyst or as Product Owner; taking that Wish-list of features to the Dev Team; your role is to Elicit Requirements and not writing them down.
2. Engage the end-users in a polite – and at times firm -conversation about where they are going, where they expect to be, and if those goals and desires are reachable or desirable.  Custom software-development is very very expensive and not for the faint of heart.
3. We develop software to Automate human tasks or to help human beings make decisions.  Start by asking the following questions:
1. “What data elements are needed to accomplish the goal of this system?”
2. “What other data elements could be added to delight and please the end-users?”
3. “What data is needed to reduce the cognitive load on the end-users when using this system”?
4. “Where can I find the data for this system?”
4. As Product Owner, you own the product (even if you are working for IT) – meditate on a thousand and one ways that you could expand and develop the system – all the time.
5. BAs, Product Owners, End-users are on a joint voyage of discovery – to create something new that had not existed before – give it the respect that such an undertaking deserves.
6. In every meeting with the end-users, present a very specific and narrow agenda.  This should be in the body of the Meeting Request.  Supply a subject matter as well for the meeting.
7. Often, the customers (end-users) are looking to us in IT to suggest technological solutions – they do not know what is available.  We should have the ability to give them options and let them chose.  For example, sometimes, a COTS package – that is already licensed and deployed – may satisfy the needs of the end-users in contradistinction to a ton of custom-code with the latest IT buzzwords, languages, and frameworks..
8. Like the space program – always have at least two members of the Dev team present in the requirements sessions, lest something be lost.
9. After each and every requirements session, meet with the Dev Team to go over what has been discussed and revise the Product Road Map, the Software Specifications, and the Software Architecture and BoM - if needed.

I think when meeting with the end-users, we are defining and fleshing out Business Use Cases (Business User Stories).  I think it would be a good idea to meet separately with the Dev Team and flesh out the Technical User Stories.

The Product Owner, as end-users community’s proxy, owns the business requirements. 

Since we do not have the role of a Requirements Engineer within development teams, it follows that the entire team owns the technical requirements. 

Which means, in practice, that Dev Team members ought to actively participate – when warranted – in the discussions with the end-users as well as with the product owner. 

The Dev Team owns three things: Software Architecture and changes thereto, Software Specifications (Technical User Stories), and the BoM – in my opinion.