Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Use Case and FRD - HELP
Previous Previous
 
Next Next
New Post 11/17/2011 12:28 PM
Unresolved
User is offline Preet
2 posts
No Ranking


Use Case and FRD - HELP 

 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/28/2011 1:48 PM
User is offline Deepdive
3 posts
No Ranking


Re: Use Case and FRD - HELP 

RE: Use Cases

In my experience, the definition of a User (or Actor) can be a person or a system.  Another question I would ask is if a Use Case is the correct document to use?  If it is, perhaps you keep the 'human' user/actor requirements in the Use Cases and use a supplimental document to define what the system needs to do.  In your Post Conditions section of  your cases, you can state the outcome and refer to the supplimental document that has your backend system requirements.

 
New Post 1/12/2012 5:42 PM
User is offline Engle
30 posts
9th Level Poster


Re: Use Case and FRD - HELP 

 Rob N wrote

RE: Use Cases

In my experience, the definition of a User (or Actor) can be a person or a system.  Another question I would ask is if a Use Case is the correct document to use?  If it is, perhaps you keep the 'human' user/actor requirements in the Use Cases and use a supplimental document to define what the system needs to do.  In your Post Conditions section of  your cases, you can state the outcome and refer to the supplimental document that has your backend system requirements.

An Actor can also be a Date or Time event. If the system is going to be generating reports regularly, then ' regularly ' will have to be defined as the Date/Time trigger

 
New Post 1/12/2012 5:53 PM
User is offline Engle
30 posts
9th Level Poster


Re: Use Case and FRD - HELP 

 Hi Preet, 

I would suggest doing the BRD first, then Bus. Rules, then FRD. Also, suggest a top-down approach - move from high-level to low-level. Keep the non-functionality aside for now. 

Iteratively go back and refine finer details

Cheers !

 

 
New Post 1/13/2012 6:43 PM
User is offline Kimbo
449 posts
5th Level Poster


Re: Use Case and FRD - HELP 
Modified By Kimbo  on 1/13/2012 10:07:42 PM)

 Hi Preet,

First obvious question is what is a BRD and what is an FRD in your company? It varies enormously. Here is what I think needs to be done to define a system:

Business Level

1. Textual requirements (the system shall... type statements)

2. Business process

3. Business use cases

4. Business rules

5. Business domain (main business clases e.g. notification in your example)

6. Non-functional requirements

In an ideal world you get the textual requirements right first and then use the business process to determine the business use cases. Note: there is no definition of screens etc at this point. Business level is the BRD. The business rules are created at the same time as everything else. Put them in a separate document if you wish but cross reference them to the use cases where they apply

Design Level

This is where you define:

1. Screens

2. Reports

3. Data

4. Validation rules

5. Other programs e.g. the one that sends the notifications

6. etc

This should be at sufficient detail for you to give it to a developer. A good developer will probably be able to code from this (also using the companion architecture document developed by your solution architects)

Lots of people seem to use use cases to define screens but I personally think there are more efficient ways. Use cases are not designed for this purpose. I create a prototype layout, define all the fields and where they are loaded from, actions, validation rules, etc. Similarly for reports I do a layout and define the way the report is organised e.g. sections, sub headings, sorting; and where the data comes from.

This is the FRD.

Hope that helps

Kimbo

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Use Case and FRD - HELP

Community Blog - Latest Posts

Gen1us2k
Gen1us2k
Most of the IT projects imply constant cooperation between the team members and customers. Although it might be often overlooked, the role and the importance of the client within the project is very crucial. Thus, it is in your interest to build a strong relationship based on trust. However, gaining trust on a single occasion is not a dealmaker &md...
0 Responses
emorphistechno
emorphistechno
Introduction In today's world, most enterprises work aggressively to achieve a higher level of business growth, which is made possible by leveraging one of the best automation technologies. One such technology is Robotic Process Automation (RPA) that plays a vital role in streamlining the customer experience in the most profitable manner.&nb...
0 Responses
Nick Stowers
Nick Stowers
Introduction   When I was introduced to scrum, the burndown chart was a tool that was highly emphasised however I feel the purpose has changed from it being a tool to predict (to a certain level) timescales for delivery to a tool that measures a team’s productivity…..in other words, the focus is on the number of points clear...
0 Responses






Latest Articles

Top Metrics for measuring Agile Project’s success
Aug 01, 2020
0 Comments
Good news is that the adoption of an agile approach is increasing with more and more projects being successful. As a business analyst / project manage...
Copyright 2006-2020 by Modern Analyst Media LLC