A recurring theme in the literature on IT over the years has been frequent failure of IT projects. Most studies lay the bulk of the blame on requirements (examples here and here). One way to improve accuracy and fit-to-purpose of requirements, and thereby promote project success, is to include data analysis as well as process analysis in the requirements plan.
I’ve cited here the need to start data interface analysis early to avoid budget and schedule blow-ups when, as a result of not thinking early about interface complexity, data integration work turns out to be bigger and nastier than anticipated.
Early data study also helps business analysts elicit more detailed and accurate business requirements. Say a mid-level football (soccer) team in the UK is looking to recruit a couple of strikers who can reliably punch home goals for the club. The obvious data they seek is (1) the number of goals scored per game by each prospect, and (2) over their careers how much time have they spent on the bench due to injury. At the same time, this club is building a strategic recruiting system to support growth into the higher echelons of English football. A process-oriented requirements strategy (like the one described here) asks the team’s recruiters what they need to in order to get good people into the club, and often emerges with a list of statements about what the system will do (”The system shall provide an interface enabling entry of the following player statistics” or “The system shall provide a report ranking players by the following criteria:…”).
It isn’t necessarily wrong to start with process analysis, especially when backed up with formal techniques like use cases, data flow diagramming, or others, but addition of data analysis early provides ability to be far more perceptive into the real business needs. Without interviewing anyone a data analyst can know that there are many goals in a game of soccer (OK, to some not nearly enough, but that’s another story), that the attributes of a game include location, weather conditions, date and time, whether it’s regular season or playoff, and more. Attributes of a goal: time during the game; left foot, right foot, or head; did it come from a set play or in the run of play; from the left or right side of the field, and much more.
The analyst who knows the data and understands its structure can probe with questions like whether a player tends to score at the end of games, or would it be useful to find one striker who tends to score from the left side of the field and another who scores from the right? By understanding the data an analyst can understand the business problem more deeply, build better rapport with business people by asking more informed questions, and cross the business/IT communications gap to define the right requirements so that the right system gets built.
It may be just the organizations I’ve been exposed to, but in my experience data analysis isn’t typically part of the requirements effort. Supporting this point, the author of the wikipedia page on business analysis entirely omits data analysis, apparently favoring a process-only approach. On the other hand, object-based techniques offer a balanced approach, studying both data and process by representing things like goals, games, and players as objects with their own attributes and behaviors. In addition, the International Institute of Business Analysts (IIBA) includes data-oriented along with process-oriented techniques in its Business Analysis Body of Knowledge (BABOK).
As process/data balance early on in the application lifecycle becomes more widespread analysts should generate more insightful requirements and, other things being equal, the success rate of IT application projects should improve.