Gathering Requirements 1

[A0C61ZZ]

Hello,
I'm currently managing a group of application across various platforms/technologies (Java, Cobol, Db you name it) in a financial company.
I have to reverse-engineer these apps for extracting the functional requirements & business rules of the same? Is there any correct methodology /format I can follow while doing the same.
Going further I plan to construct testcases based on these extracted rules & requirements. Is it a good idea to build testcases on Business processes ( the logical processes) or just the functional requirements of the application.


- A0C61zz

 

[hilfy]

Is it a good idea to build testcases on Business processes ( the logical processes) or just the functional requirements of the application.

I would do both. You want to make sure that the application meet the functional requirements, but you also want to make sure that they do what the users need them to.

When I'm working on writing specs for something, I like to sit with one or more users who are currently doing the task and see how they work and what they really need as opposed to what I think they need. The functional specs then become a collaborative effort to make sure that the users will get something that actually helps them do their job.

Unfortunately, many programmers don't make this kind of effort. So, you get software that meets the functional specs but doesn't actually help the user be more efficient.

-Dell

A computer only does what you actually told it to do - not what you thought you told it to do.

 

[A0C61ZZ]

Thanks hilfy.
Also what is the exact difference & relationship between business requirements & functional requirements. Is it that business requirements are mostly logical processes whereas the functional requirements are the physical processes. Is there any site which gives a clear info on relationship between business requirements & functional requirements?
- A0C61ZZ

 

[johnherman]

The business requirements are usually stated in business terms while functional requirements are usually at a more technical level and may be unintelligible to the actual business user. Many companies have Business Analysts who work as go-betweens to ensure that the business requirements are accurately translated into system requirements via a Functional Specification or other similar technical document.

-------------------------
The reasonable man adapts himself to the world. The unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw

 

[ArkM]

There is no your (future) system in business requirements.
It's your (future) system works in functional requirements, but (most of) users must understand this doc (on the 1st, upper level, not on subsystems level).

 

[planetant]

There is a very big difference actually.

Business requirements justify why to develop so are like: What is the business problem being solved and how do we solve it: eg 'We need an ecommerce site for our soap product.' 'We need a tool for our inventory.' Why do we need the tool and what do we need it to do? For a developer it is too general a document to use for testing and developing

Functional specifications are things like:
At login page, when the user enters a their user name and presses 'submit' they are taken to their account page; The logged-in header has the following... etc.

Dont confuse the func specs with the tech specs which are like: handlers, field names, changes to the code and table etc

Business requirements are written by marketers, PMs and execs for the IAs and designers; functional specifications written by IA's for the developers and testers. Tech specs are written by developers in order to work out and document the engineering on the site for communicating to current (other layer) developers and future developers.

Tech specs will be unclear to anyone but engineers, func specs should be clear to everyone.

If your issue is testing, I would start by working on func specs.

Good luck!

 

[Goodall]

Business requirements should focus on "What" or "Why" business objective are being addressed. Is it a product/process improvement or a compliance issue. Are you looking to achieve improvements in cost, time, service or quality. They should be linked to relevent objectives in business plans already established. Describe the benefit(s) that can be expected in measurable terms if possible. They should provide a detailed outline of the scope of the project and its boundaries. Use business terms, no technical jargon at all.

The main thing that a business requirement should not include is "How" the requirements will be achieved. That is the purpose of the functional requirements. Possible solutions should not be a part of the business requirement.

 

[grooke]

I find UML is excellent for this task. However, to reverse engineer, you need to understand the forward engineering path.

Business requirements can be captured at three levels:
[ol][li]Global requiremnets go into 'Non-Funtional Requirments Document'. A silly name, but it contains all the Business rules that affect everything that happens on the system. The are mostly used for security and availablility requirements, but also make an excellent repository for things like 'Ergonomic Requirements'.[/li]
[li]Operational Requirements, that correspond to 'Business Processes' and achieve one objective at one time on the computer session, map into Use Cases. There are lots of fancy definitions for these, but the 'one thing, one time at one place' is a good start. Then as people above had commented, these should only say 'What' people want to do and NEVER 'How'. [/li]
[li]Business Rules. All the remaining Business rules should map onto classes or their associations. This assumes you use classes. Often they are written in Business English, just as a list, but this is just a presentational approach. [/li][/ol]

There you are, UML Analysis in a nutshell ;-)

In design, this data is used in different ways.
[ol][li]Use Cases tend to get used to identify one or more screens each. Sometimes, one screen may be used by several use cases.[/li]
[li]The use Cases provide an excellent skeletal set of User Acceptance Tests. They identify all paths, all intents and what to look for when the use case terminates.[/li]
[li]The key business classes should map fairly directly into the any relational database schema.[/li]
[li]Finally there is the code :-( [/li][/ol]

To reverse engineer, you need to make use of these concepts:

[ol][li] Start with the screens and draw the menu structure. Most menu Items are indicative of a use case. Also look at the actions from the mouse keys, as they are NOT always reflected in the top level menus.[/li]
[li] Look at the screens and try to imagine just what a user can do when working on that screen. Also note which other screens they have to use to do that thing. Maybe, you see a very complex set and the user could be working their way through a number of secondary use cases linked by <<includes>> and <<extends>>. Remember the 'One Thing' aspect of a use case. If they do a couple of things, look for a couple of use cases. Beware that 'a thing' in this context is NOT and action, but something that achieves an objective for the user; they could possible go get a cup of coffee after they have done it.[/li]
[li] Look at the database schemas. These probably reflect the classes involved. The relationships then reflect fairly directly, some business rules like 'No more than three items at a time'. Data constraints are sometimes reflected here, like 'Must be over 16'. [/li]
[li] You may be lucky and find an old copy of the 'Non-functional Requirments Document' as these have been used for centuries (Well nearly). [/li]
[li] The code: [ul circle]
[li] If you are lucky it is OO code, and you can find classes[/li]
[li] Components are sometimes Object based just by nature of the desire to encapsulate. Look for these.[/li]
[li] If it is designed with Yourdon, then the functional units tend to deal with only a couple of data structures, each of which reflects a few classes. [/li]
[li] Then you are into the code. Hopefully, you have got most of the structure before you reach this level. [/li][/ul circle][/li][/ol]

Good luck

Gil