Strongly disagree about the user stories approach. User stories generate a solution from the user's perspective, a perspective that may not state the total business response to an event. What if a better business solution would make that user's role obsolete? Business requirements derived from business rules, not wants, drive solution design from a business perspective. You seem to want to discard a waterfall approach based on good practices in the programming phase. The baby is being thrown out with the bath water.
What are your sources of information about user stories? My friend Ron coined the term. User stories DO NOT have to only come from users. The first part of a story is the role, “As a _____,” That role could be a user, stakeholder, executive, an external system, etc. But it is better to have the focus of a user story be the outcome of applying the business rule rather than the business rule itself. Read Mike Cohn’s book, User Stories Applied if you want to learn what user stories are and how to use them well.
@@ThePassionateProgrammer Thank you for replying. The focus is a study of the events that cause the business area to do work. Data arriving at the business area creates a total business response from the perspective of the business. An alternative and more comprehensive approach to user stories is event analysis driving requirements definition that becomes the foundation for conceptual design. My source for user stories was while working in a large corporation in the US in the 1990's witnessing user stories missed only to be demanded as essential later while other stories were included that were really outside the scope of the business area. I saw this happen on three separate projects.
