Hello Members
I want to clarify if USE CASE approach is effective for a Backend application?Also apart from having a detailed BRD , is a USE CASE required for each requirement?
I have a project wherein BRD captures the requirements ,but I am tasked with preparing use cases for these ?
Since its a backend application which will be from a anew vendor, how should i approach the USE case technique ?since i do not know how the new applicationwill look like ?
Any Suggestions/comments is helpful
Thanks
Hi Sindh, I understand your situation. You probably have found a way round this already (as your message is a few weeks old) but I wanted to comment if that is okay.
Personally, I would not be able to define a use case specification for a system I do not directly support (as the whole essence of a use case is to be able to specify the system behaviour and based on your message I don't think you can do that). Personally, I only define use cases for systems I directly support.
As you are asking for suggestions, this is what I would do:
Provided you have made it clear on your use case diagram that the system you support interacts with another system (downstream/backend application) using the boundary symbols AND in your use case specification, you have have spec'ed up to the point where the post-condition of the last interacting use case (in the system you support) clearly states the entry criteria (pre-conditions) of the downstream/backend application, I would think that is sufficient for your developers. Might I add here that this post-condition must be verified with the developers of the vendor company and testing of course would prove if the handshake happens as expected.
If a UC is absolutely required (for the vendor application), it cannot be provided by you for reason underlined above. I strongly believe it is the responsibility of the vendor to provide the system spec for their application.
I hope I have not muddied the water for you even more.
BA-MAN stated: "as the whole essence of a use case is to be able to specify the system behaviour"
This is completely wrong. A use case specifies the interaction (behaviour) between an actor and the solution. Essentially it is actor does something, solution does something, actor does something, solution does something.... etc
Use cases are solution independent. The 'solution' may not even involve a computer system or it may be a combination of manual and system.
A use case is initiated by an actor (a person or system that is external to your system) and is a series of steps to achieve a goal that is of benefit to the actor.
Lots of people talk about system use cases nowadays but there are much better ways to specify system behaviour than shoe horning it into a use case.
Kimbo
brought to you by enabling practitioners & organizations to achieve their goals using: