I am completely new in analysis and design.....
please some one tell me :
what is the difference between System use case and Business use case ?
As far as I know, there is only one diagram in UML called use case diagram..
Now, what about them ? Do they have separate diagram?
Thank you
From Wikipedia:
A business use case is described in
technology-free terminology which
treats the business process as a black
box and describes the business process
that is used by its business actors
(people or systems external to the
business) to achieve their goals (...)
A system use case is normally
described at the system functionality
level (for example, create voucher)
and specifies the function or the
service that the system provides for
the user (...)
So, in short, business use cases are more about what the users expect the system to do, and system use cases are more about what the system actually does.
A business use-case describes the steps in a process that achieve a business goal.
A system use-case describes behavior of a system that automates a business use-case.
Use cases are the values provided to the actors by the systems or organizations under study.
For organizations, named business use case;
For systems, named system use case.
See the picture below (drawn by myself):
Use cases can be divided into two types. It is not necessary, but if someone ask you to do that, it is possible.
System use case represents the use cases which are done by the system(not manually).
For example: In a online hotel reservation system a user books a room. So the booking is a system use case and the user is a system user.
Business use case represents the use cases which are done manually. It is not necessarily done by the system.
For Example: Manual hotel reservation via telephone call. A user calls the hotel and books a room. Here telephoning is not a system use case, because it is not done by the system. The user is also not a system user, because they do not interact with the system.
Software architecture comprises among others with the business view (description of business processes) and with the system view (description of the system). A business use case is describing the functionality of the business view, and the system use case is describing the functionality of the system view. The business use case has its graphic stereotype in the UML standard.
Related
I would like to model an application architecture and the time-outs between all the application (e.g. between application A and B there is a time-out of 10 seconds and that between all applications). Which modelling language should I best use for this that it is clear? I don't think UML diagrams will do the trick...
Thanks.
It depends on the purpose of your model.
Business oriented process orchestration
For orchestration between several tasks/activities of several applications of a complex process, you could use Business Process Model and Notation (BPMN), which is a standard of the OMG.
There you can model event-based "gateways" to control flow of control or "messages" between activities. An event could be in your case a timer or a error (e.g. time-out errors) depending on the desired emphasis.
Remark: THere are several third party tools that use BPMN models to generate BPEL in order to to make the modelled process orchestration exectutable.
Technical model
If you want to show interaction between applications, but not necessarily modelled as business processes (user perspective), you could also really consider UML:
activity diagrams can present event actions and also timers
eventually, sequence diagrams could present timing constraints and conditions. But intuitively I doubt it's the best choice for your question here.
Christophe's answer is correct. However, you can show time out with basic activity diagrams by using interruptible regions and an interrupt flow like this:
Of course BPMN can do that much better.
I'm in the process of writing Gherkin Scenarios and am coming across a problem where User Stories apply to multiple Personas in the System we are designing, with subtle differences.
Based on what I've read, the preferred approach is to write Feature files from this perspective:
As a [role/persona]
I want [feature]
So that [benefit]
The problem with this is that I'll end up writing more or less the same scenario for each persona, which is going to end up in a lot of duplication.
To give a specific example, in a Recruitment application, different personas need to be able to view Applicant entities that are registered with the Company. The only difference is that depending on what level of privileges (i.e. what your persona is) you have i.e. Executive level, Regional Manager, Area Manager, Branch Manager, Branch Employee, External Customer, some sort of filtering needs to be applied to the collection of Applicants you can view.
One way of tackling this problem is to orient the Feature / User Story around the Entity (Applicant) rather than the Persona i.e.
Feature
As a user of the application (NB. Rather than mention specific Persona, we refer to a 'Generic' user persona)
I want to be able to view Applicants
So that I can perform my work duties
Scenario
When I request to view Applicants
Then I am to view Applicants that I'm allowed to based on my permissions
This scenario captures the User Story succinctly. However, I would like to test the different use cases i.e. Branch Manager can only view Applicants assigned to his Branch, Area Managers can only view Applicants assigned to his Region, Customer can only view Applicants on work assignment at their Company.
What would be the best way to go about this and do you think the approach of writing User Stories oriented around an Entity rather than a Persona is acceptable?
I would worry less about duplication and focus more on clarity.
If it is important for a stakeholder to see that an Area Manager is allowed to see some stuff and an External Customer is allowed to see some other stuff about the same application then I would express that in Gherkin.
I am sure that these rules will not change often as they are probably at the core of the domain. This means that you will not change them very often. If you need to change them, it must be easy for your stakeholder to understand that.
If you find that there are many variants where the differences are very small, consider a scenario outline to capture all different versions. That could lead to less duplication while still being clear on the differences.
If the changes are of a more of a technical nature and your stakeholder doesn't care, then use unit tests to capture the implementation and not Gherkin.
But in this case, focus less on duplication and more on creating a common understanding that is easy communicate.
Remember that Gherkin is a communication tool rather than a programming tool. As a communication language, other rules apply than on a programming language.
The "As a [role]" is not about who is a user of the feature but who requires the feature. Mostly, it's some stakeholder who requires features so that the company can benefit and do better business.
In your case, it's about viewing applicants. Different access should be described by more scenarios in the same feature file. However, all your access roles are not crucial to explain the feature. Despite the fact that tools behind the Gherkin can test, Gherkin features and scenarios are more about capturing the idea behind them than cover all possible scenarios. Choose 1-2 the most significant access roles and the rest lay down to lower testing levels, mostly unit tests.
Try to keep in mind the test pyramid where acceptance tests have only a small part of all testing.
i've been trying to figure out how to deal with Business Rules in the following format:
a booking has 1 to n (n = 200) articles
problem P shall be handled by the System XYZ
a specifict data-class shall be supported in the System XYZ
the communication to the customer shall be done by the organization Z.
it is possible to change a specific value in an order
the system XYZ shall be able to evaluate if a customer is able to pay monthly rates
in addition, many rules i got explain certain things that need to be fulfilled in order to let a future system work correctly. In my eyes, these rules are technical requirements. So, what would be the best choice? Hard-coding these Business Rules in Business Processes (it just sounds so wrong) or embedding a Business Rule Management System (with a Rules Engine) next to a Business Process Management?
My guess is that a Rule Engine is not the best choice for this. There are sometimes more than one possibilities and scenarios written down in each Business Rule and the common "if-then" statement does not apply in the most cases.
So i found out that in most cases there is this "if-then" statement (literature etc.), but then the SBVR from the OMG comes in (Semantics of Business Vocabulary and Business Rules). It confuses me because there it isn't required to formulate rules with "if-then" et cetera.
I assume that these rules are not specifically meant to be built in a rules engine, but rather kept an eye on during the implementation of the software and after this process. Yet i think that these Business Rules might change. Wouldn't it be naive to hard-code them in Business Processes?
If there's anyone with a hint, i'd be very thankful.
BR
Yeah, you just need to choose the right tool for the job. You should take a look at the Drools and JBPM projects. Where the main goal is to make the rule engine to coexist with the process engine. So for some of those "Rules" you can create a business process to take care of it and for another one you can just write a proper business rule. And the third option is to mix both worlds.
Can anyone gives us tricks, uses case, book and any other ressources for how to Capture and manage requirements from a statement of work(SOW).
A Statement of Work usually identifies your business objectives and spells out the scope. From there I would (very loosely):
Attempt a very high-level model of business functionality (my preferred form is a Use Case Model).
Engage with the business owner(s) to confirm the high-level model.
Attempt - in conjunction with the business owner(s), to model the business requirements (my preferred method is use cases).
It's possible to capture requirements as a list in a document or wiki. It's also possible to capture them purely diagrammatically. I use Visio. I've also used requirements management tools such as RequisitePro. I prefer use cases that start out as diagrams and add step-wise narratives as needed.
I wanna to draw a business use case diagram for a specified problem.
The problem has some rules. Now I wanna to ask that:
Is it correct to put business rules when drawing business use case?
I would say that it is correct to add any information that makes your diagram easier to understand. If you can't find the proper diagram item for the information you want to include, use comments.
I agree with #Konamiman that some flexibility in what we "should" do with our diagrams is reasonable, our objective is to communicate. In this particular situation I would have expected Business Rules to be a largely internal implementation feature of a system and so when we describe the Business Use cases (how the system is used) we probably don't need to mention them. "Approve Insurance Claim" may well be a use case for the system, and probably uses Business Rules internally, but does the reader of the diagram need to know that?
I can imagine that you may have additional "Change Business Rule" use case.