this website is amazing
I was told to draft a business requirement spec for the data migration part of my project,
I am struggling with this. I am thinking a BRS is not appropriate, please prove me wrong
In my opinion, data migration project is data driven, I can only foresee one functional requirement in the project ie the target system shall update data from the source system.
can there be any other functional requirements?
under what category of non functional requirements can data load frequency be documented?
what should the structure of the BRS should b like?
should data requirements in d BRS be at column or entity level?
Your responses will be highly appreciated
Hi Losky,
The examples you give are not really business requirements. They are your perceived solution to what the business requirements are. I recommend you take the time to ask the business - run a workshop - what they want out of the data migration.
This type of BRS is often quite short but that doesn't mean it isn't worth asking. You may be surprised what you uncover. It could be that the business's idea of what the project will do is quite different to what IT thinks.
Kimbo
Hi Kimbo,
Many thanks for your reply .
had workshops with the business already.
the output of the workshop was only data requirement. (ie we identified data to be migrated).
are you saying regular data load into the target system is not a business requirement?
Hi:
I agree with Kimbo. Sounds like what they want may be something more than your initial interpretation.
Also, per Wikipedia:
After loading into the new system, results are subjected to data verification to determine whether data was accurately translated, is complete, and supports processes in the new system.
Under this broader interpretation of data migration, some (maybe alot?) of data and process analysis may be needed, thus necessitating a spec.
Tony
There are some obvious functional requirements like the one you mentioned plus the non-functionals. Your job as a BA is to look behind what the business is telling you and get to the REAL business requirements and not what the business is telling you. Otherwise you get what looks like is happening here. They are telling you how they think the migration should happen.
What are the business goals? Why is the migration happening? As Tony said, you'll need to capture some verification rules as well although I think I'd leave the details of that to the design phase. Try to think behind what is happening on the surface. When you can do that consistently you'll start to add real value.
Hope I'm not sounding patronising? I don't mean to be.
brought to you by enabling practitioners & organizations to achieve their goals using: