Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  General  Use Case and FRD - Actors
Previous Previous
 
Next Next
New Post 11/17/2011 1:18 PM
Unresolved
User is offline Preet
2 posts
No Ranking


Use Case and FRD - Actors 

 Hi,

I just started working as a BA and have few questions regarding Use Cases and FRD. It would be really helpfull if somebody can help me asap. Thanks

Use Case:

I am working on a System (ABC) which will send automatic notifications to the selected users (X) with some information gathered from ABC database. Then X users will access ABC system to complete their duties such as scheduling frieght, editing reports, etc. ABC will generate and send these notifications regularly by gathering information from ABC database (which mean the system will scan its own database to create and send notifications to X users).

Now my question is how can i create a use case for this process.  Who will be the actor in this case. Can ABC system act as an actor itself because there is no other external user or system which will be creating and sending notification to X users. It is all done by ABC. What will be the trigger? etc etc

FRD:

I am asked to create a BRD + FRD as 1 document. Basically, ABC system shall have 3 functions which will be used by X users to compelete their tasks.

Question: How should i categorize the functional reuirements for these three different function. Should i write the name of the function and then start writing all the functional req .. For Example:

Edit function: 1- The system shall allow user to change words using edit function....

                      2-  The system shall generate the report using edit function... etc etc.. 

What categories should i inlude in funtional requirements....Functionality, User Classes, Security, etc? 

Do i need to write and categorize my functional requirements based on my business reuirements numbering?

What about Business rules? Should i write business rules for these functions separatly or business rule is one sections where i can write the rules for all three functions together?

Thanks

 

 
New Post 11/19/2011 7:03 PM
User is offline Kimbo
456 posts
5th Level Poster


Re: Use Case and FRD - Actors 

 Hi,

ABC system cannot by definition be an actor that interacts with itself.

Your phrase "ABC System will generate and send these notifications regularly" says to me that the notifications are triggered overnight or over the weekend or something. In this circumstance I use an actor called "Scheduler" or "Clock". Conceptually it is another system that triggers the ABC system to generate a notification at regular intervals or a predetermined time. 

As for your FRD, I suggest you write use cases for your functions. Link your business rules, business domain classes, business processes and requirements to the use case. How you do this in terms of numbering is up to you. Remember that the link between business requirements and use cases is many to many. As is the link between business rules / use cases, business domain class / use cases, UI screens / use cases, business process / use case, etc. You can create traceability matrices between all the different components to your hearts content. As a minimum do the use case / business requirement matrix.

Btw, best practice is to have a separate business rules register and link these to your use cases. In practice, if you are just using MS Word this isn't easy (I just write them into the use case but it means if the rules change you have to remember to change them in every location). If you use a modelling tool this will be easier.

Regarding requirements, I define a set of business requirements and a set of non-functional requirements e.g. security, usability, response times. Your edit function requirements examples are better defined by using use cases.

Hope that helps. If you have any further questions then post away.

Kimbo

 
New Post 11/19/2011 7:04 PM
User is offline Kimbo
456 posts
5th Level Poster


Re: Use Case and FRD - Actors 

 Hi,

ABC system cannot by definition be an actor that interacts with itself.

Your phrase "ABC System will generate and send these notifications regularly" says to me that the notifications are triggered overnight or over the weekend or something. In this circumstance I use an actor called "Scheduler" or "Clock". Conceptually it is another system that triggers the ABC system to generate a notification at regular intervals or a predetermined time. 

As for your FRD, I suggest you write use cases for your functions. Link your business rules, business domain classes, business processes and requirements to the use case. How you do this in terms of numbering is up to you. Remember that the link between business requirements and use cases is many to many. As is the link between business rules / use cases, business domain class / use cases, UI screens / use cases, business process / use case, etc. You can create traceability matrices between all the different components to your hearts content. As a minimum do the use case / business requirement matrix.

Btw, best practice is to have a separate business rules register and link these to your use cases. In practice, if you are just using MS Word this isn't easy (I just write them into the use case but it means if the rules change you have to remember to change them in every location). If you use a modelling tool this will be easier.

Regarding requirements, I define a set of business requirements and a set of non-functional requirements e.g. security, usability, response times. Your edit function requirements examples are better defined by using use cases.

Hope that helps. If you have any further questions then post away.

Kimbo

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  General  Use Case and FRD - Actors

Community Blog - Latest Posts

In today's ever-evolving market, businesses must adapt swiftly to remain competitive and meet the needs of a fast-paced digital economy. Among the various business strategies available, digital transformation, customer-centricity, and sustainability have emerged as top priorities. Let’s explore why these strategies are critical for busine...
The Cisco Certified Network Associate (CCNA) certification is a pivotal credential for networking professionals, validating your skills in networking fundamentals, security, automation, and programmability. Preparing for the CCNA exam can be challenging, but with the right strategy, resources, and mindset, you can successfully achieve this certific...
The CEO/CIO's Guide to Architecting AI: Vision to Value in Minutes Introduction to Architected AI Artificial intelligence (AI) is becoming part of our life at an unprecedented pace. As CEOs and CIOs grapple with how to leverage this powerful technology to drive strategy and enhance operations, the concept of Architected AI becomes importa...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC