Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Business Proces...  Implementing Use Cases in our organization
Previous Previous
 
Next Next
New Post 6/27/2008 7:01 AM
User is offline Requirements Czar
6 posts
10th Level Poster


Implementing Use Cases in our organization 

We are trying to implement use cases in our organization as a tool for better capturing functional requirements.  However, since most of our applications are 3rd party and not built from the ground up, how does this affect how we write our use cases?  Or does it?  A majority of our work is customization of these vendor applications.

 
New Post 6/30/2008 5:22 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Implementing Use Cases in our organization 

Hi:

Graphical use cases are for to-be design of relatively finite systems.   Text based use cases are for to-be design of even smaller scale systems.  Your situation seems to require as-is modeling for (maybe?) larger scale integration. 

Also, maybe consider the need for business process reengineering, as the major benefit of larger scale automation efforts often revolve around simplification of existing business processes.  Use cases are not a business process reengineering tool. 

Tony

 
New Post 6/30/2008 5:22 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Implementing Use Cases in our organization 

Hi:

Graphical use cases are for to-be design of relatively finite systems.   Text based use cases are for to-be design of even smaller scale systems.  Your situation seems to require as-is modeling for (maybe?) larger scale integration. 

Also, maybe consider the need for business process reengineering, as the major benefit of larger scale automation efforts often revolve around simplification of existing business processes.  Use cases are not a business process reengineering tool. 

Tony

 
New Post 7/1/2008 12:37 AM
User is offline Rob Winter
4 posts
No Ranking


Re: Implementing Use Cases in our organization 

Our organisation is following a similar path, with the added variation that some projects could be aimed toward procurement of new 3rd party software.

The business analyst role here keeps use cases fairly simple (or 'black box'), concentrating on what the system does, not how it does it.  In that respect then, our use cases would be just the same regardless of whether the project was aimed at procurement, reuse of existing assets, or new development.

The next stage is where the different project types diverge.  For a procurement, we would send black box use cases to potential suppliers.  This level of use case gives suppliers a bit of freedom to gear their products toward a viable solution.  For reuse of existing assets or new development, our systems analysts and developers would analyse the black box use cases and begin to move into the solution domain, looking at how the system will provide the required functionality.

 

 

 
New Post 7/1/2008 8:58 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Implementing Use Cases in our organization 

Robert:

Question:   Don't  you have a need to formally address data flows?

The application integration projects that I have worked on (including integrating of a 3rd party package into an existing organization) have always required a significant amount of data flow analysis.   After all, the required data flows are the essential interfaces between a (3rd party) system and the outside world, including to other systems.   Unfortunately, use cases do not capture data flows.

Tony

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Business Proces...  Implementing Use Cases in our organization

Community Blog - Latest Posts

Ashish Adike
Ashish Adike
As a Business Analyst, very often we get into a situation where the Project requires multiple IT Products to be evaluated before implementation and might seek Business Analyst’s recommendation for the same. With the ever-growing range of Products in the market and the marketing promotions associated with some of the products, it’s very ...
0 Responses
m_anst
m_anst
What Does Success Look Like? I challenge Business Analysts to view requestors’ requirements as an opportunity to define success. Too often, teams fall into a trap focused on requestors’ prescriptive requirements that are meant to serve as roadmaps for developers and testers. When you limit your view of requirements to this prescripti...
0 Responses
Mariya Kotsupalova
Mariya Kotsupalova
They say the best criteria of Business Analyst’s success are a happy customer (business) and a happy engineering team. But what does it mean? How can we break down happiness and measure it? These are precisely the questions my 8 BAs team and I tried to answer this year. The result was a surprisingly efficient pair of surveys we developed and ...
0 Responses






Copyright 2006-2020 by Modern Analyst Media LLC