20 The Intersection between Requirements, Business, and the Law
Sheldon’s perspective:
The small print: The framed parchments here say “Computer Science” and “Software Engineering”. They say nothing about being a lawyer, nor anything about having a business degree. Yet, I find myself doing business and writing and evaluating contracts. Just the same, don’t take anything in this book as financial or legal advice.
When I left school, I got a job. I thought that I was going to be a programmer. Three weeks into the job, I was told that I was now a data base consultant. When I arrived at the project to which I was assigned, I was told that the project was in trouble, and that I was to get the data base “handled”. I quickly found that the data base requirements were unknown, and that the nature of the interface between the programs and the data base were also not well defined. That was one of the main reasons that the project was in trouble. That, in turn, caused contractual issues, which in turn was on the verge of causing legal issues, which would have caused financial issues.
Every business is much like a living organism. Organisms want to eat and grow. Businesses want to earn money and grow. Even nonprofits want to earn money and grow, even if the money coming in is used for charitable purposes, or for a cash reserve. The programming (and the requirements gathering which elicits the programming) takes place so that the business can better its bottom line. Depending on the nature of the business, bettering the bottom line usually means one or more of spending less in the long run, earning and/or producing more in the long run, and/or becoming more effective. Your job as a programmer or analyst will seldom directly be producing “cool” stuff; it will be the job of producing the needed stuff. If that stuff is cool, so much the better. If what you’re producing doesn’t affect the bottom line as described above, then it’s useless or worse.
We’ve mentioned above, that various types of business arrangements, uses, and release plans, and how they lead to the use of certain project methodologies, with recommendations to Waterfall, Agile, Spiral, and others. We’ve also mentioned how those methodologies tie in with time-and-expenses contracts, and with fixed-price contracts.
Time-and-expense contracts are very simple, generally. Such contracts are basically a statement that we’re going to charge them so much an hour, plus any direct expenses. There are parameters on how much we can spend, and the time period. For instance, with one customer, the contract was for 80 man-hours per week for 5 months, at a given price per such hour. In such contracts, the customer usually has the right to terminate the work with no notice. Here, it’s not the contract that controls what’s going on. Instead, it’s the customer’s perception of how well you’re doing for them. Show them good stuff early and often, and you’ll keep getting the money. Succeed in the project (whatever that means to the customer), and you’re likely to get repeat business. That’s where the best profits come from.
Fixed-price contracts, on the other hand, almost always force you into the Waterfall model. That’s because in the fixed price model, you’re going to get a specific amount of money for doing a specific thing. Sheldon most strongly suggests that in such a contractual arrangement, that the specifications must be complete before entering into the fixed price contract. Here’s why: Let’s say the customer offers you $30,000 for doing a job for them. If the customer wants you to do $30,000 worth of work for that, everyone will be happy. If it turns out that it’s only $30 worth of work, the customer will not be happy, and the contract might or might not be enforceable, since there’s a “Doctrine of Fairness”. If there’s $30,000,000 worth of work to do, you’re going to go bankrupt and/or get sued or be the one who sues. Don’t get yourself into that. If the customer wants a fixed-price contract, then the customer needs to deliver the specifications as to what is needed, or the requirements gathering process needs to be a separate time-and-expenses contract.
When combining time-and-expense specification writing with fixed-price systems production, keep the two contracts completely separate. Once the specifications are done, you and the customer can negotiate a price, or the customer may go elsewhere for that phase. That’s not always a bad thing. For instance, a company produced a specification. The company then bid a price for the project based on that specification. The customer didn’t like the price and went elsewhere. That was fine, since the company could not have delivered the specified product for the price that the customer and the third-party provider decided on. (As it turned out, that third-party couldn’t produce the product for the price they quoted, either.)
A use-case style specification is usually fine for time-and-expense projects. Both sides know generally what’s going to happen, and things pretty-much go in that direction. If minor or even major mid-course corrections are needed, then they can be made within the wiggle room of the use cases or user stories. The cases and stories can be adjusted as needed, too. Fixed-price contracts are best served by IEEE-830-style specifications. The more everything is nailed down, the better everything will go for both sides. Very often, a fixed price contract will either directly include the specification document, or include it by reference. Thus, the specification is, in effect, a contract in and of itself. Thus, the specifications should be written in contract-like language.
Before we go into the language of contracts, let’s look at the concept of Offer, Acceptance, Performance, and Payment. In this concept, all contractual arrangements involve these four phases, which are not necessarily in this order. Typically, you or the customer makes the other an offer. The other accepts the offer. Then, you perform the contractual function, and finally they pay you. In some arrangements, payment occurs before performance, during performance, or some before and some after, or what have you. The presence of any three of these components is sufficient to prove or require the fourth. For instance, Acceptance, Performance and Payment is sufficient to prove Offer. Offer, Performance and Payment is sufficient to prove or fully imply Acceptance. Offer, Acceptance and Payment is sufficient to force or require Performance (or a refund, and possibly a penalty). Offer, Acceptance and Performance is sufficient to require Payment.
The language of contracts and specifications must be as clear, concise and unambiguous as possible. Define everything, especially abbreviations. Generally, an abbreviation or defined term will generally be of a form in which you use a term in its full form, and then the capitalized abbreviation in parentheses and quotes. For instance:
This agreement is by and between The First Fake Bank of the West (“Lender”) and John Q. Smith (“Borrower”). Lender intends to…
The exact same sort of thing is useful in specifications. but without the quotes. For instance:
The data base management system (DBMS) will communicate with the workstations using the local area network (LAN). The DBMS shall…
Note that the language of the contract is important, and that translations don’t always work well. If a language or a specification is in more than one language, or used in translation, make sure that one of the versions is the reference version or controlling version. Despite all of its ambiguity, English is one of the least ambiguous languages.
One more thing in the area of translations, which seldom applies, except to notices: If two or more countries are involved, a notice in French is a notice, whether or not any of the countries involved speaks French, so if you ever get a document in French, read it or have it translated and then read it.
