3 The Relationship Between Needs and Projects
We had mentioned before that a perceived need is the reason for a project. Below, many of those reasons, with their business relationships, are explained.
3.1. When the Project is the Business
In the simplest circumstance, the project is the business. Take, for instance, Facebook. The Facebook program (project) is not a program that facilitates the business — it is the business in and of itself. To be sure, there is more to the program than any one user sees. For instance, as a regular user, ads are being served up to you. Somewhere in the program, those ads are being sold and billed.
This brings to mind an important point: When writing a specification, or requirements document, consider all the people involved in the transaction. Here, “transaction” does not just mean monetary things, but any sort of system-to-system interaction, system-to- person, person-to-system, or person-to-person. Note that a project may be composed of more than one program, and may involve hardware too, and may involve interaction. For instance, if I send a message to you, we can’t stop at my sending the message. We have to at least get as far as you receiving the message. Maybe we even go to the point of me receiving a delivery receipt. Seeing a transaction through is called “transaction completeness”. (There is a second, related, type of transaction in data base systems which often takes place at the same time, but the two are not exactly the same.)
Here, the need is simple: We can’t do anything until we have the program done.
Note that a project may be composed of more than one program, and may involve hardware too, and may involve only hardware. While this book is mainly concerned with software requirements documents, the same techniques used here will usually apply to other projects as well, whether or not related to information technology.
3.2. When the Project is the Product
When someone who is not in the information technology (IT) industry thinks of a program, likely the thing they’re thinking of is a packaged product or downloadable application (app). When someone buys an application or pays for an application or service on a regular basis, then the application/project is the product that the company is selling. The success of the company, or at least of the product, is dependent on sales of that product. If the product is good, and at a fair price (you can take “fair” to have both meanings, equitable and likable), then it will be profitable (if the costs to produce it were not too high).
Here too the need is simple: We’re going to build it so we can sell (or rent) it.
3.3. When the Project Drives Profits
Very often, the purpose of a project is to drive profits for the company. Driving the profits may happen directly or indirectly. When profits are driven directly by the project, the company will usually call those producing the project a “profit center”. When the project indirectly drives profits, the company will call those producing the project a “loss center”. A non-programming example: A supermarket chain might call the store a profit center, and might call the warehouse and transportation departments loss centers.
An example of a project that drives profits indirectly is a company web-site. The web-site’s job may be to bring customers in so that they spend money with the company, and it may be the web-site’s job to actually sell products. An example of a project that drives profits directly could be in a company that sells development services. The company gets a customer who wants a project done, and the successful delivery of the project is the product being sold (hopefully at a profit) to that customer.
3.4. When the Project Decreases Costs
It used to be that if you wanted to buy an airline ticket, there were three ways to do it. One was to go to the airline ticket counter and buy the ticket there. Another was to go to a travel agent and do the same thing. Later, there was a third way to do it: Call them on the phone, and buy that way. Once the World Wide Web (or “WWW”, or just “the web”) was in place, tickets began to be sold that way. The reason for selling tickets on the web, rather than on the phone was simple: It costs less to have tickets sold that way, because the overall costs of writing the program and maintaining the software and hardware are lower than the overall costs of payroll and benefits for the phone attendants. So, adding web access to the airlines’ systems decreased their costs.
Many times, in-office cost-decreasing reasons for a project are present. If we stay with the same example, airline tickets used to be sold on handwritten tickets, or from pre-printed tickets. Pre-printed tickets had to exist in only one place, and the right tickets had to be found to be sold. When the PARS airline reservation system came into use, any ticket could be sold from anywhere, so long as the seller had a PARS terminal.
Note that the World Wide Web and the Internet are not exactly the same thing. The Internet is the transport mechanism for data and the services they carry. The World Wide Web is a collection of services carried on the Internet.
3.5. When the Project Increases Speed or Efficiency
It is often the case that a project is done purely to increase the speed of something, even if that speed increase does not directly increase the bottom line (meaning the company’s profitability). For instance, a factory control system might allow a product to be delivered faster, even if at the same cost. Of course, if customers get their products faster, they’ll be happier, which will indirectly increase the bottom line.
A product can increase efficiency without affecting other aspects of a product too. For instance, cars used to have carburetors. Now, cars that still burn gasoline have fuel injectors. Those fuel injectors are often computer-controlled, using sensors in the engines and air intakes to determine the optimal amount of fuel to inject on a real-time basis.
Note that in these examples, there is nobody directly inputting any values or parameters, and nobody directly receiving any sort of display output. Don’t get into the trap of thinking that every transaction involves a visible input and a visible output. Sometimes a sensor delivers the input, and sometimes an actuator or some sort delivers the output. Some transactions are initiated by sensors, and some transactions are initiated by a clock.
3.6. When the Project Enables Something
Sometimes a project enables something that could not otherwise happen at all. One such example is the SpaceX Falcon system. The rocket’s first stage launches the second stage, then returns to earth and lands. In order to do so, calculations must be made faster than any person could (or an immense amount of fuel would have to be carried).
3.7. When the Project Protects Against Something
Protection can be in the form of physical protection, such as a door lock with keypad entry, or in the form of some sort of computational protection, such as fraud detection and prevention.
3.8. Collecting and Selling Data
Collecting and selling data is a big business. It happens as an adjunct to a lot of systems. A lot of big tech companies collect all sorts of data on their users — typically as much as they’re legally allowed to — and there are not many laws limiting them. Those companies may sell the data to companies that want the data, either in an individual manner, or in an aggregated manner. For a good example of specific data being collected, sold, and used, check out any real-estate site, such as Zillow. They have fairly detailed property history data on just about everyone’s home. Data in the aggregate is much more innocuous. For instance, CalTrans collects data from freeway sensors and sells that data to whoever would like it.
The European Union (EU), a number of countries, and a number of states have instituted laws controlling the amount and type of data that can be collected, and how it can be used. Whenever working on a project that is used to collect data, it would be appropriate to decide, often with the help of corporate counsel (a) whether the system will follow the laws of everywhere that the system will be used, or just follow the laws of where the system is located, and (b) after that decision is made, just what those laws are, and how it will affect the system.
Similarly, note that in any money-involved system, you will likely run into money-handling laws that vary from country to country. Again, those same two sets of decisions will have to be made.
There are basically three ways of handling local laws, whether it be pertaining to disclaimers, fair use, data collection, or money:
- The system can be built to operate under the laws of each country in which it’s operating, doing one thing for users in one country, and something else for users in another country. For instance, PayPal operates by the rules of each currency.
- The system can be built to operate under the laws of just one country, and operate from there only, telling other countries “we don’t care”. For instance, Wikipedia operates from the US, where you can say what you want, and doesn’t hold to the rules of countries that tell them what they can and can’t say.
- The system can be built in such a way as to operate within all the laws of every country simultaneously by not doing anything illegal in any country. This is often the cheapest way to go.
- The system can be build by ignoring laws, and falsely claiming to be operate legally. This is typical of scammer systems.
3.9. Controlling the Flow of Information
Controlling the flow of information can be done for both good and evil purposes, so be careful. (Or at least know what side you’re on.)
The good version of information flow control is most often used for data cleansing, or in protecting a learning system from incorporating incorrect and questionable material. For example, you wouldn’t want artificial intelligence (AI) that learns by perusing the seedier side of the web.
The evil version of information flow control gives only one-sided information to people in order to keep the truth from them or to influence them in a particular manner, or to quash information that the paying entity doesn’t want widely known.
3.10. Embedded Software
Embedded software is software that is a part of some device. Typically that device doesn’t appear to the casual observer to have software, but does. A quick example is the typical microwave oven. The oven could have a circuit board that handles the buttons with debouncers and a shift register and a timer and a power controller and who knows what else, or it could just be a computer connected to the keyboard and the microwave controls, with a program in read-only memory (ROM). That ROM-based program is embedded software. Most cars now have a number of computerized functions, including, as mentioned above, the fuel injection system, plus the dashboard and entertainment system. Although most cell-phones now run applications, flip-phones run embedded software.
The specifications for these embedded systems often omit the fact that there is software, and talks only about how the system or device will behave. Sometimes, in specifications, hardware and software requirements are handled separately.
3.11. Systemic Control (ATC, Factories, and the Like)
The idea of embedded systems has a larger, broader counterpart: Cooperative systems. Consider the case of an automated factory. The factory will have construction robots. Parts will be brought to the factory robots using “smart” conveyor belts, and taken from the robots in the same way. The robots’ supply needs, such as welding materials, will be supplied by other more mobile robots. Those robots all have to coordinate with each other, either as peers, or as slaves to some sort of master control system.
Specifications for these types of systems will generally involve how the system as a whole acts. But, such a specification will typically have to state how each system within the factory will communicate with each other, or how they will interact with the system that runs the factory as a whole.
Sometimes remote systems need to interact with each other. For instance, a military plane will usually carry an IFF (Identify as Friend or Foe) unit that will communicate with ground-based systems, carrier-based systems, and systems in other planes or missiles. A specification will typically describe the protocols that these things are going to use to interact with each other.
3.12. Modernization
During the first year of the Covid pandemic, one of your authors noted that there were a lot of want-ads for people to work on conversion projects. Very often, these projects involved conversion from on-site systems to cloud systems, from Microsoft Dot Net to Microsoft Dot Net Core, from SQL-based databases to so-called NoSQL databases, from monolithic systems to distributed microservice systems, from mainframes to distributed systems, and many more projects like this.
There are a number of underlying causes for this type of conversion, categorized below.
Note that in many conversion or modernization projects, there is no need to produce any additional software specification or requirements document at all, since the functionality of the system will remain unchanged.
3.12.1. Useful
Of course, optimally, any conversion effort will have a good cause behind it. In the early days of computing, each manufacturer, and even each model of computer was so significantly different that some conversion effort was required to move the program from the old computer to the new computer. The programs were moved because the old computers were too costly to maintain, and because the new computers were so much faster. This happens in modern projects, too, when some special hardware feature becomes available, and specific use of it is to be added.
In modern times, the typical reason for a useful conversion effort is to gain functionality, gain speed, or to decrease the code complexity of the system to lower future development costs. For instance, a company was using an enterprise management system written in Borland C++. The system had a desktop version, and needed a web-based system sharing the same database. Every user screen, because of the way Borland worked, had been written independently. A large number of new screens were to be added, and a large number were to be modified. Doing the additional work in Borland C++ would have taken a certain amount of effort. Converting the entire system to C# (chosen because the programmers at this company already knew and used C# for another project), plus the effort of the adds and changes required, took less effort than the job would have taken if the software had stayed on the Borland system.
3.12.2. Lemmings
Too often, a project will undergo conversion for no other purpose than “everyone else is doing it”.
The business advice: Don’t undergo a conversion project unless at least one of these goals will be met: (a) The project will be more functional in some manner (note that this will mean producing a functional requirements specification for the new functionality); (b) The resulting new software will execute more quickly; (c) The resulting system will be easier to maintain, such that the cost of the conversion effort plus the cost of future maintenance would be less than the cost of maintaining old system. If you can’t say that one to three of these goals will be met, then you should not be doing the conversion. Be careful too when incorporating new language requirements into the system. For instance, the old system was written in DB/2, C, and CL, and the new system is written in in Mongo and Hadoop and Java and JSP and a custom tag library and MQ and HTML and CSS and Javascript and Typescript and Bootstrap and Angular — your job of hiring the next programmer just got way harder.
The career advice: When management tells you to do something, decide whether you agree with it or not. If you agree, good. If you disagree on a technical basis, let management know, once, politely. If you disagree on a moral basis, refuse. One of your authors knows from first-hand experience that the latter will get you fired.
3.13. Mergers & Acquisitions
When a large company buys out a smaller company, or when two companies of approximately the same size merge, they will generally combine their two systems. This will happen in one of two ways.
In the acquisition model, one system is seen as being better than the other. Typically, it’s the larger company’s system that prevails, sometimes because it’s really better, and sometimes just because the larger company is already using it. Sometimes the smaller company’s system is used purely because it’s better. There have even been cases where the larger company buys the smaller system purely because its system is better. In such cases, the data from one system will be moved onto the other system. This process is called Extract, Transform, and Load (ETL) or Extract, Load, and Transform (ELT). Sometimes this can happen purely by asking for the data to be transferred, but often a specification of how the data is to be transferred and/or translated is required. In this sort of case, it’s not a software requirements specification that gets written, but a data requirements specification.
In the merger model, there is almost always the merging of data as described above, but also the merger of functionalities. Both companies will have functionalities they need to maintain. At first, their respective systems will operate side-by-side, but generally the functions of one will be added to the functionality of the other, and the data will often become a merger of the two original data sets. In this model, a specification is usually written handling both software and data requirements.
3.14. Return on Investment — ROI
The key point in all of these is Is It Worth It? Any project, any sub-project, even any feature, should only be taken on (and thus specified) if the project is worth it. There is a term, “return on investment” (ROI), which is the benefit divided by the cost. If that number is higher than 1, then do it. It the number is 1 or less, don’t do it. Note that cost and benefit are not always monetary. Sometimes one or both will be in terms of capabilities, speed, some sort of “goodness” factor, customer good will, or other factors.
There will always be some amount of uncertainty in the ROI. The higher the ROI and the more certainty, the greater the priority for that project, sub-project, or feature set.
3.15. How Things Can Go Wrong
The two main ways to miss the goal here are to leave things out, and to put things in that don’t belong there. This sort of problem can happen all at once, or through slow scope creep. Leaving things out is not that big of a deal in the Agile methodology, because things can be added as needed. How to avoid the problem: Ask these questions: Are there any features we need that we don’t have? Is there anything in the requirements list that we don’t need? Is the entire project, and every feature in it, worth what it will cost?
3.16. Discussion Questions
- When is it better to upgrade to something more modern?
- When is it better to stick with what works?
- Is it better to work for a big, stable company, a friendly medium-sized, or a small start-up? Hint: You’ll have a different answer from others, and if you’re true to yourself, your answer will be right.
- Is it better to work for the start-up, or to be the start-up?
- What do you think is the most likely project reason at a non-internet large company?
- Same question for large internet company?
- Same question for medium company?
