tag:blogger.com,1999:blog-6106782.post4746124231196905686..comments2024-03-27T10:47:33.255+00:00Comments on Architecture, Data and Intelligence: Use Cases for Business RequirementsRichard Veryardhttp://www.blogger.com/profile/04499123397533975655noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6106782.post-5773833887430399862008-08-11T02:53:00.000+01:002008-08-11T02:53:00.000+01:00In my opinion, use cases are too weak for describi...In my opinion, use cases are too weak for describing a solution (even if abstract), but for that very reason they're great to capture what the stakeholders would want to do with a system, standing from their own viewpoint. We are (dramatically) short of tools for capturing the very essence of WHAT we are being asked to do. We don't need another technique for describing solutions, I think.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6106782.post-61722955092588504112008-04-04T15:16:00.000+01:002008-04-04T15:16:00.000+01:00Thanks for starting this discussion! Are you chall...Thanks for starting this discussion! <BR/><BR/>Are you challenging the business process / use case approach as a whole, or just the creation of user-goal business use cases? I assume the latter, as otherwise I wonder how you would get a grip on the big picture and address issues like end-to-end coverage of business processes in terms of completeness and testing (just to mention two problems I see with that).<BR/><BR/>Let's assume that you "only" propose not to detail the user-goal level nodes of a business process with a use case description. I find it interesting to know what you use to capture user requirements in a way that an end-user can recognize them without getting confused by a lack of context. How would you prevent the risk that the requirements of a specific actor in a specific context gets blurred by generalization?<BR/><BR/>I also wonder if we have the same notion of "requirements". This wondering is triggered by your statement that you think use cases are more useful for describing a solution. Although I recognize that they can be used for that, I only see added value in specific situations where there is a need to describe a solution in words.<BR/><BR/>Granted, specific situations like that typically are in the SOA-space. I create service descriptions of reusable (business) services to capture the goal, input and output and any transformation or other business logic in there of a specific service to build. <BR/><BR/>I classify such service descriptions as a user-goal/sub-function system (instead of a business) use case. /User-goal/ if the service covers exactly one specific goal of some actor, sub-function if it is generic and supports more that one goal, or more specific and together with some other functionality supports part of such a goal. And /system/ because it describes how a system supports that goal, rather than abstracting from that and just stick to the requirements.<BR/><BR/>Finally I wonder how you prevent over-designing, but also under-designing the service if you do not have captured the specific usages in different contexts.Jan Kettenishttps://www.blogger.com/profile/14146264706360751350noreply@blogger.com