Some people cannot understand why data requirements are important. There are a lot of Business Analysts who say they have never collected data requirements and do not understand why they should. Here is one small example from my experience. I was doing some business analysis consulting at a state agency that was just beginning to use the RUP methodology and the Business Analysts were busy using use cases to document most of their requirements.
One story I heard when I first arrived on my assignment was that they had written all their uses cases in great detail and had an approved prototype. The developers had done their testing, and they were really trying to rush to get everything ready to go to production when someone discovered a big problem that delayed the project for several months. During User Acceptance Testing, it was discovered that new data was now being collected from the users of this application but this new information had no where to go. The database did not know about the new data requirements. No one had collected the data requirements for the application – only the use cases. The data could not be stored. No one had modeled anything for the DBA.
To keep the project from being delayed, the IT group suggested that the business keep track of the data manually. Another option they suggested was that they could just create notes in the application with the new information until such time that the data requirements could be collected and the data models designed. The business folks were livid that such a silly mistake could be made. The project was delayed and no one was satisfied. Do you have any stories about why capturing and modeling data requirements is important for requirements elicitation?
If I understand your story correctly, the UI was designed to accept the data, but nobody took the time to analyze the data being collected by the UI? This seems like an obvious miss. I absolutely agree that somebody should be analyzing every single piece of data required for the new system. Who does that and when may vary based on the analysis process being used for the particular project. I’ve seen some projects where Business Systems Analysts define the data (not the structure of the database), and others where a dedicated Data Analyst or Data Team defines the data only asking the Business Systems Analyst to do additional analysis when necessary. – Chris Modern Analyst, Core Member http://www.modernanalyst.com
As someone on the DBA side of the house who is more interested in the housing and care of data than the newest features of the DBMS, there are several questions that you can ask to get to data requirements. (Mind you, I’m just trying to get to understanding how to formalize data requirements myself).
1. If your story has the user doing any kind of data entry, ask if the user or anyone else will ever expect to see that data again.
2. Assuming yes to 1, how soon do others after the user clicks OK to persist data do others need to see this data? (Often if it is some kind of master data, it needs to be pushed to another system).
3. Will the users have any ability to set preferences in the system? Some examples could be an email address to get alerts, frequency of certain events, whether they use IE or Firefox for their browser.
4. If this is a subscription service or an internal application, who will manage the users of the system?
5. For any of 1, 2 and 3, who will manage the data? Typically, application support (especially off-shore) consists of programmer types who don’t really understand the business and the data rules. If a user says they entered a change on Friday but they don’t see it, who will know the data enough to analyze it? Often figuring out who will own the data is a tough decision for an organization.
Those are some starter thoughts. I have found that even in a very large organization with very experienced Software folks, the majority of the folks in IT don’t care about data. Ergo, of course, data requirements are frequently given minimal attention.
I don't know if it happens because I work close to the system analysts but our process involves the modeling of the entity classes by the business analyst, this model includes the relationships, multiplicities, generalizations and of course, properties. But it doesn't end here. Every use case objective is to change the properties of one or more entities. That means that there's always a direct relation between the use case description and the entity classes diagram. For each use case we describe, we attach the affected classes and their affected properties and it reduces the chance to forget about some data to zero. That's also a good reason to treat reports as use cases because if you want to report something, it's got to be somewhere, and you have to show where it is. Kerber ITBA – Digitro Technology http://www.digitro.com http://www.kerber.com.br
Thank you for your responses. Yes – Chris- they really did design the UI without any thought to what was going to happen to the data once it was collected. Edmundo, great user questions, especially in an agile environment – – thank you. I have also noticed that many people in IT do not seem to comprehend the importance of data requirements. Sounds like Kerber is the one working in an enlightened place that truly understands the benefits of documenting and analyzing data requirements. With our core training we love to get our BAs excited about how much they can learn about the business through elicitation of the data requirements. There is hope for the rest…
There are plenty of tools to make sure your requiremenst capture data as well as everything else. Personally I like the Method H model provided at Project Perfect
From the story above I presume the real problem was too many people involved in requirements management. Managing complexity is often proxy for managing lots of people.
Craig @ Better Projects
Modern Analyst – Core Member
Well Angie, over here we work very close to the system analysts and we can fell the heat when things are not well modeled from the beginning. Maybe the path to reach a good environment is the knowledge of the whole process and each part