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 -

INVENTORY.

RESERVATION.

MARKETING.

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:

EightyTwentyRule - An abstraction may handle 80% of the cases, but working around the 20% is a such a bear that the net abstraction savings may not be worth it.
Factors anywhere, anytime - Any factor can potentially impact any spot in the code anywhere at any time. You cannot simply isolate all factors into their own spot because the interaction has to go somewhere. Thus, there might be factor A and factor B, but there is also the intersection of factor A and B. Does the intersection go in A, B, both, or a new factor "AB"? If the latter, then we could have a combinatorial mess as we scale it to more factors. See also LifeIsaBigMessyGraph, EmployeeTypes, and AttributesInNameSmell.
Unpredictable future changes - It is nearly impossible to predict the future. An abstraction that is great today may choke tomorrow, creating a DiscontinuitySpike to remove it or overhaul it.
Abstraction-free code may be repetitious busy work to update, but at least it is a fairly predictable quantity. Managers do not like uncertainty. They often cringe when I say something like, "I am sorry, but I don't know how long it will take until I study the code more." Abstractions often reduce the amount of code changed by itself, but can make it hard or unpredictable time-wise to figure out what to change.
Modeling human personalities, not universal external laws - Many business rules appear arbitrary to us developers, so we just have to implement them more or less as-is. Sometimes we are given the reason for something, sometimes not. If you don't know the reason behind a rule it is harder to find abstractions. Is similarity to other rules part of a pattern or mere coincidence? Business leaders and managers are often known for their "intuitive" abilities and not so much logic or tech abilities. That is fine, but it makes it hard to apply logic and pattern analysis from an implementor's viewpoint. Thus, you get stuff such as, "Let's give discounts to every customer who buys one or more of these items on Sunday or these items on Wednesday, unless they already bought a foo in the past 3 months. Oh, and they cannot use this discount if they have a G coupon, but other coupons are okay". They pull these seemingly out of thin air. Tax laws, for example, similarly have all kinds of goofy rules to satisfy various political constituents. Related: AreBusinessAppsBoring and Page Anchor: "Emanuel_Derman" under BusinessModeling.

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

CategoryBusinessDomain