Hi Guys,
It's awesome to see your enthusiasm!
First of all, let's make sure we are all working off the same requirements (the last attachment in the previous thread). I'll re-attach it here for easy reference.
Let me try to answer some of your questions and provide some feedback:
- I'm not an expert on Context Diagrams and DFDs but I think we should clarify what is a Context Diagram.
- There are many folks who will use a context diagram to show all kinds of different things.
- From my perspective, a Context Diagram is the Level 0 of a set of Data Flow Diagrams. Therefore, the Context Diagram itself is a data flow diagram. What this means is that the relationships among processes and entities in a Context Diagram show Data Flow and not actions. Therefore the relationships should not be named as "Verb Noun" but just "Noun".
- In both context diagram versions, the relationships seem to show actions and not data. If you are going to create the next level of data flow diagrams (decomposing what is supported by the "Use CyberBank ATM" ") then you will see that the verb labels, such as "Withdraw Cash", "Deposit Cash", etc. are actually sub-processes in lower level DFDs.
- Any other Senior BAs care to comment on this one?
- At the Level 0 of the Context Diagram, the main thing you need to identify correctly are all the external entities that will interact with our main process "Use Cyberbank ATM" process. So you should take a look at the requirements document for such requirements.
- The Customer is an external entity and you got that
- If you take a look at Requirement # 2 you will see that the ATM must interact with the Cyberbank's main on-line banking system (OBS). This should be in your context diagram as an external entity.
- Are there others? Take a look at the requirements doc?
- Also - make sure that you don't have external entities which are not supported by the existing requirements or else we get "Scope Creep". In one of the context diagrams I noticed an external entity called "Admin/Maintenance System". Based on the requirements, I'm not sure what this is.
Lessons Learned - for ANY Business Analyst:
- Make sure you understand your tools and their purpose. In this case the Context Diagram: what is it, what are the rules, etc. No understanding your tool leads to misuse which leads to the perception that that tool does not work or is not effective.
- Beware of Scope Creep! The business analyst must ensure he/she has a solid understanding of the requirements and when new ones come up the requirements document/repository should be update. There are many instances where once a requirement has been identified, documented, and agreed upon, another stakeholder comes along who had a different experience at a different company/job and "assumes" on how the system should work without checking the requirements.
Best regards,
- Adrian