Most often getting business architecture requirements right is a challenge and it means there are two types of people who need to converge at a common point to where they could make sense it each other. The business people are concerned with the business side of things and look at the picture from an angle which could be quite different from the IT folks. For example the IT team is worried about building requirements that are more better versions of working software or rather refinements in releases but the business is concerned about what business value will this piece add to the overall product strategy or solution point of view. Many a times it so happens that there is no clear articulation of business value and organizations spend time and effort in producing waste or MUDA ( Toyota / Six Sigma ) prefers to call it. This can happen because in the name of taking up an initiative a wrong requirement was envisaged as having to be completed. Many a times the requirements although is an art and science by itself and needs to be done with the right focus as all the downstream actions based on this can create mis alignment in the vision and mission of an enterprise. So is there is definitive prescription to doing this , how is this similar to user stories or epics that agile teams talk about . User stories are not enough to detail all possible requirements more so when they depict the end to end system goals where aligning business and IT is paramount. This being the case there needs to be a structure to capture all the actors and details that goes into getting a business scenario right.
Recently been to an IT company where the issue was product owners hand over requirements over email or chat sessions or simply over a phone call. It was said that requirements not getting correctly scoped was the single most productivity loss and created enormous amount of wasteful downstream activities. What has been your experience here ?
