Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Should i use the Use cases OR general requirement description OR flow charts when writing a system a
Previous Previous
 
Next Next
New Post 3/7/2012 2:26 PM
User is offline johnAnd
2 posts
No Ranking


Should i use the Use cases OR general requirement description OR flow charts when writing a system a 

I have read a lot about the best way to document client requirements these methods include:-

1. Uses cases including the following sections (pre-condition, post-condition, detailed description, exceptional flow, alternative flow, etc).
2. Draw the system requirements as flow charts
3, write a document that include two main parts (AS-Is & To-be)
I find that the most professional way is to write all the requirments in detailed uses cases as in the first option ,, but this approach would take a lot of time and efforts especially in the systems that have a lot of functionalities.
So my question is what is the most up-to-date methodology to follow in managing the client requirements for IT solutions.
BR
 
New Post 3/8/2012 6:48 AM
User is offline Anthony Chen
63 posts
8th Level Poster


Re: Should i use the Use cases OR general requirement description OR flow charts when writing a system a 

I prefer to create process flows and then map the requirements to steps in the process flow.

A linear list of requirements is useful because it forms a checklist that test and development can use to make sure they have completed. However a linear list of requirement is very difficult to review. The problem with making use cases your requirements is that it is easy to have an action a user takes actually map to 3-4 requirements.

 

We create our process flows down to an L3 process flow level, then map 3-4 requirements to each step. This has the added benefit that it is extremely easy for the business to review documentation organized this way. 

 

 

 
New Post 3/8/2012 9:48 PM
User is offline Kimbo
450 posts
5th Level Poster


Re: Should i use the Use cases OR general requirement description OR flow charts when writing a system a 

 Hi BR,

Your question is central to how we work as BA's I wrote the following on another post a while back and I've copied it below. There are a number of things you need to do to define a system. What you do will vary with each system. From your question I can see that you've probably learnt a whole lot of techniques and are struggling to know how to put them together to define your system.

This is what I do. Like I said, each system is different and I may only do a subset of this or occasionally add other things.

Kimbo

 

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.

 

 
New Post 3/8/2012 11:47 PM
User is offline KJ
243 posts
6th Level Poster


Re: Should i use the Use cases OR general requirement description OR flow charts when writing a system a 

BR,

There are a lot of papers in Google Land on  "use cases are not requirements" or "requirements are not use cases"!

The Upshot is Usecases are NOT requirements. Usecases define a BEHAVIOUR (how you interact with the domain (ie system or business)).

AND requirements GOVERN the BEHAVIOUR of the systems.

warm regards,

K

 
New Post 3/9/2012 10:48 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Should i use the Use cases OR general requirement description OR flow charts when writing a system a 

Hi:

The real need in documenting system behavioral-related requirements is not so much to document the requirements, but to capture the essential interrelationships between the requirements.

So, let me ask you this, with your approach, how are the interrelationships between the requirements discovered and captured?   (Note:  Flow of control between processes on a flow chart are not interrelationships between the processes.)

Tony

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Should i use the Use cases OR general requirement description OR flow charts when writing a system a

Community Blog - Latest Posts

The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...
Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified. 1. Not understanding underlying business need Organization’s business environment keeps changing with respect to Customer...

 






 

Copyright 2006-2021 by Modern Analyst Media LLC