Business Systems Analysis

Functional Categories - Proposal by Paresh

Most of the business requirements that I can think of would fit into one of these FUNCTIONAL categories discussed in class -




I was also contemplating Reporting as another functionality, but I think it would be good to consider having reporting as a sub-unit to each of these functionality.

So I stay with the above 3 functionality.

In the NONFUNCTIONAL category I recommend the following:

SECURITY. Access rights, Backup, off-site storage

SERVICES. Help desk, Deployment(distribution and SW packaging), documentation and training.

PERFORMANCE. Response time monitoring, Tuning

DATA MIGRATION. If we need to transfer data from the existing old systems(COBOL and CICS) we need to consider this before we start the data model design.

UTILITIES. e.g. Changing user Password, Changing User Preferences/Settings etc.

Functional Categories - Proposal by Irene

I have attached my proposed list of functional categories for the team project. I have listed categories that I could identify and put a description and sample detail next to each to attempt to clarify how I view the category.

I look forward to seeing your suggestions.

Inventory - Will provide details on vehicle, vehicle type, warranties, vehicle age, graphic of vehicle, etc.

Maintenance - Will provide Maintenance details, upcoming and past scheduled maintenance dates, uncalculated maintenance (accidents, malfunctioning parts etc).

Reservations/Scheduling - Car assignments, length of time, purpose/event, etc.

Ticket/Driving History - Track all car tickets and incidents.

Car Rotation/Sales - To maintain the rules to determine when a car is to be retired, details on retirement that fall outside the rules, vehicle sales at auctions and sales to employees, etc.

Billing - To maintain the prices and fees related to rentals.

Marketing - To maintain information on promotions.

Function Categories - Proposal by Clem

Spoon usage - Show spoons used per day, how many spoons deformed in the process.

Wardrobe - Track failures, limnal and catastrophic.

Resources - Track ear wax usage, navel lint production, per capita, per parish and per fortnight.

last edited June 3, 2004, no links to anything, no links to this page. It looks like a WalledGarden or somebody's meeting notes. WikiIsNotYourNotebook

(moved from ObjectiveEvidenceAgainstTopDiscussion)

I think it's because Top has little-to-no real formal training in CS. He is probably mostly self-taught. Because of that, he's very short-sighted when it comes to most improvements.

I have a CS degree from a state university, and graduated with honors. No, that does not make me an Alpha Geek, but I am sufficiently educated. And, I even took a graduate course on "patterns". -- top

Check out how he complains about business logic and how irregular it is. Any business solution guru worth his salt would have built an abstraction over those rules, shoved them in the database, and made a fitting algorithm to determine which apply. But Top lacks the fundamentals necessary to make that work. So instead he relies on complex if-then-elses, nested logic, and leverages the ability to cull possibilities in SQL before his underpowered languages-of-choice have to get ahold of them.

Well, I don't dispute that I might be missing some Grand Abstraction to simplify everything, but I've been around a lot of developers and they also seem to be unable to find them. However, unlike them it is something I ponder fairly often instead of just happily live with it. I have experimented fairly often with business logic abstractions and then have been chewed out when they fail to handle new requirements. (And there are political reasons for the rejection sometimes, see WarStories.) Thus, it is not for a lack of trying.

You seem to be implying that if companies hired more top-notch Phd's in CS that they would be able to find these alleged big abstractions and convert all the custom apps to math-like compactness. If you can give us some semi-relatistic [?] examples of Phd techniques greatly simplifying business logic, I would be very happy to see it, even if it ends up making me look bad. I will happily lose face over slam-dunk evidence. At the very best, ignoring some caveats, you FP'ers have only shown incremental and minor improvements. No need to bicker over smallies here yet more, we have enough of that already. I am more interested in things that have big, clear impact.

Really, what Top seems to advocate is DataDrivenDesign?. He doesn't really follow an everything-in-the-db-policy because it seems he simply lacks the skills that a real professional would use. So in a sense, he's right. DataDrivenDesign? is a very good thing, up unto the boundary of YAGNI.

I am not sure what you are implying here. Are you implying that even though I like data-driven driven design that I lack the ability to use it effectively because I cannot abstract high enough? Or, are you saying that DDD has too many limits because of YagNi or something else?

I think the best thing we can do is let Top lie, at this point. He doesn't want to understand, and that's fine. Obviously his current employers are easy to please (if CopyAndPaste is any indication), so it's not like his future is on the line. Eventually, circumstances will compel him to come out into the modern world of computer programming, one way or another. Right now he's hunkered down and is planning to stand his ground. I know how he feels. When I first came to C2 and met all these smart people, I was just a little bit defensive about my bad practices too. He'll get over it on his own. -- AnonymousDonor

I do want to understand, but I learn by seeing actual relevant code examples that demonstrate some objective-ly observable principle. Your evidence seems to be feelings and emotions, not science. You might be a genius, but if you cannot turn that into something objectively observable, then I and millions of other biz developers will ignore it.

Here is a summary of the things which have gummed up my past attempts at higher biz rule abstractions:

What I have trended toward is light-duty, small abstractions that can be easily tossed (no DiscontinuitySpike) when needed rather than target monolithic Ultimate Abstractions or Ultimate Frameworks. See HelpersInsteadOfWrappers. In other words, the best abstractions seem to be those that one can date or flirt with, but does not have to marry.

And, managers don't believe your Phd superproductivity claim also. They don't like "weird" code that complicates hiring. Unless productivity can be clearly demonstrated, they will ignore claims such as yours. Even if by chance I agreed with you, I don't know how to present it to management because your sales pitch is wishy washy, fuzzy, and seemingly beyond the scientific method. They make the final choice, not me. If you tell the manager that he/she won't "get" your productivity claims unless they first get a Phd, they will show you the door faster than a Cray can add 1 + 1.

-- top

See also: GenericBusinessFrameworkUnobtainable

EditText of this page (last edited August 22, 2005) or FindPage with title or text search