Getting Business Requirements Right
By: Keith Ellis
This paper describes a methodology that brings the early stages of the SDLC up to a high level of maturity consistent, proven, and optimized for success. This drastically reduces the downstream problems that plague many IT projects, and substantially enhances the predictability of cost and timelines. The larger the project the higher the risk, therefore a sound business and software elicitation and definition methodology is an essential element in the selection of an ERP system, or in contemplating an enterprise-class application.
Whitepaper Sponsored By
Use case and process/data modeling
Good reading! My observations are somewhat opposite.
I am not so clear about the few terms used in page6: "We use Use Cases and process/data modeling to describe each business activity."
1) what is the difference between use case and process?
2) How process/data modeling is the same activity? I am not sure if the "/" is used in the right place. If yes, then, please inform on the name of an example diagram (ex: UML domain model, UML activity diagram, etc) that is a process/data model.
3) What "type" of use case you are referring here? business or system? If it is business use case, then it should not refer to technology terms/products. If it is system use case, of course the flows and actors will mention about "the system" and "external systems" that are all tech products. From your sample problem descriptions in the side bar, it seems you are referring to business use case. However, from your article, it seems you are referring to system use case. Overall, it feels you are confusing business use case and system use case as one shot.
4) How do you determine what is a "business activity (business use case)" vs. what is a business step? I have seen that most requirement analysts struggle with this. They either come up with too many use cases or too few (confusing step as activity or activity as step/alternate flow).