Hello every one!!!
Recently I attended few interviews .Some interview questions please can any one help me to answer ?
1) At what stag you will use the use case model and how you will decide that how many use cases you might need when you start documenting the project documents.
2) About traciability matrix they asked why I would use that I said that it is used to help in tracing the Incomplete documents but still he wasnt happy can any please give me more points on that..
3) What is the difference between primary actor and secondary actor?
4) Difference between business use case and systems use case?
Please help me in giving answers and your suggestions for above questions and I would say that BABOK has a good stuff to answer many questions in interview.
Regards,
Srikanth.
Hi:
Below is my answer to your first question (actually two questions):
Use Cases come into play after as-is analysis has been completed. This is because use cases do a poor job of facilitating the requirements discovery process - and that is what analysis in large part is: as-is discovery. Why do use cases derail the discovery process? This relates to the second part of your question: How does one decide how many use cases are needed? GREAT QUESTION!! Also an impossible question to answer - which makes it an especailly great question. Use cases lack a lithmus test of completedness. They never tell you when you are done. So use cases are a to-be design tool. So after you have completed your as-is analysis, you may use use cases. Basically, OOA is an oxymoron.
By comparision, with data flow diagrams, the data flows between the functions are a rigorous test of completedness of as-is analysis. A function is defined by its data inputs and outputs. When you evaluate the data inputs and outputs for a functions on a data flow diagram it is usually glaringly obvious when you need to discover more of the as-is. Data flow diagrams actually prod you through the as-is discovery phase (which, as an aside, is a big reason why they are seldom properly used).
Tony
Hi Srikanth,
2) The traceability matrix allows you to see the business goals and objectives that the project at hand will accomplish and how exactly they will be achieved - which functional requirements are the result of each business goal and objective. You can use it to verify if a requirement is in or out of scope, what is the impact of a requirement change - facilitates the requirements change control process, etc.
3) "An actor is someone or something outside the system that either acts on the system – a primary actor – or is acted on by the system – a secondary actor." To elaborate on this furhter, a primary actor of the use case "Print a Word Document" will be the writer who indicates that he would like the document printed, and the secondary actor will be the printer that will produce the output. So the actor may be a person, a device, another system or sub-system, or time.
4) A business use case describes the business process that provides value to the business actor, and it describes what the process does. On the other hand the system use case describes the new system's functionality. It describes what the actor will achieve by interacting with the system.
-Vessela
Use Cases: to discover them, I use the the business process for the scope being analyzed. In it you will find steps where 'somebody does something with some information". like " Salesman creates New Order" or "Warehouse receives Shipment". These are steps where the business wil 'use a system', hence a 'use case', with the 'somebody' being the main Actor. One thing the business can usually do is define their process, i.e. tell you what they do. Once the process definition is stable, all the Use Cases are in there as I have described.
David:
Srikanth asks a very important question: How does one know when they are done creating use cases?
I know that we analyze the business process, and I know that the business process consists of various people doing various things. The fact that we have identified that the "Salesman creates new order" is great. But , with use cases, how do we know if we have captured all the steps leading up to that one? How do we know that there are not steps after that one? The model itself should tell you if you are done. That is a big part of why we create as-is models. How does a use case model itself tell you that you have completed the requriements discovery process?
brought to you by enabling practitioners & organizations to achieve their goals using: