Dear All,
Currently I am working on business analysis of CRM. For successful implementation in this very fast paced environment I am following below mentioned approach:
1) After first meeting with stakeholder I develop a prototype which highlights application flow. This basically shows what happens on screen when user performs a particular function.
Benefits: Initiates users thought process, you may get detailed picture of application.
2) Once a prototype for a module is finalized then I start working on use cases for that module.
Benefits: covers all the cases of a particular functionality. It is reviewed by coder so that he can understand the document well.
3) And once use case document gets over I start working on prototype document where it clearly defines how system will behave for a particular screen. This document is developed with a technical lead.
Benefits: All integrations level aspect start coming into picture in this document. Plus what values need to be captured.
Please share your feedback on same approach. Negative views are more welcomed J
Hmm, I'm wondering if there is a tester or QA specialist of some sort who ought to be included? To determine if you're covering the details they will need for testing the completed product. Otherwise, if the stakeholders have been identified properly and they are okay with the approach, and the developers are okay with this approach, then it doesn't matter what the rest of us think.
Nitin,
Sounds like you jump straight into screen detail without working out what the actual business requirements are. Therein lies potential disaster. You're quite likely to deliver stuff that your business users don't want.
Pull yourself up out of the detail and work out your requirements first. Once you have that worked out, then get into the solution.
Kimbo
I've got to agree with Kimbo - You need to at least get your high level requirements established first, what are the business trying to achieve, why etc. I would also suggest, that you create the use cases at the same time as the prototype - even it's a wireframe, as the use case scenarios should help with the path through the system (alt paths etc).
Nitin:
On the real plus side, you are focused on getting things done, not on creating needless documentation. But remember, Agile is about creating minimal but quaility (i.e., essential) documentatioin. As Kimbo mentioned, it appears that you are largely skipping requirements analysis and jumping into design. The one analysis artifact you mention is use cases. But use cases by them selves lack an integration mechanism.
If your app is small enough, I guess you can makeif work. But if you have a larger scale app, you need to scope things out (Context Diagram), and concentrate on the fact that it is not so much the stand alone requirements that need to be discovered, but the essential interrelationships between them (ie. the data flows). Do you hav a need for modeling data requirements?
Your approach: Screen shots and Use Cases are all that is really needed. My approach: Some essential data flow diagrams, entity relationship diagrams, and screen shots is all that is really needed.
Tony
brought to you by enabling practitioners & organizations to achieve their goals using: