20 – The Requirements Phase
And… we’re back! For those of you new to Galen University, welcome to your new home. For those of you who have been here before, welcome back. I hope you’ll find many things improved, and a few others at least no worse, than when you left it.
For those of you unfamiliar with our little “chats,” this article represents the latest in a series of monthly publications about technology and its impact on our lives. I find it to be an important avenue of communication between myself and the student body, and as such a valuable project to have undertaken. That being said, I did take a brief break this past summer due to various factors competing for my attention over the last couple of months, but now that the world is safe once again I am likely to stick to my intended schedule for the foreseeable future. In addition, if you are new to Galen, and therefore this series of articles, feel free to look through the previous installments by browsing through the newsletter’s post history. I’ve been told that some of them are pretty ok.
One of my favorite approaches to writing these articles is to look at some aspect of Computer Science that I am likely to address in one of my courses, and to explain both the concept itself, and how it can be applied in a broader sense, perhaps even in ways that can improve the lives and experiences of you, the members of the Galen community.
This month, as the title has already revealed, I want us to look at something called the “Requirements Phase.” In a course called Software Engineering, one of the most important of the entire undergraduate Computer Science curriculum, I detail the process of producing computer programs to meet the requirements of a client, either an individual or a company. We cover such ideas as how to write source code as a member of a team, how to write source code by yourself, and how to write source code by yourself while pretending to be a member of a team.
In most such approaches, since the program is being made to order, the very first step is obtaining the purpose and features of the software from the client, and this procedure is known as the Requirements Phase since it involves obtaining the “requirements” of the finished product.
Some of my students are very surprised to learn that the vast majority of software engineering efforts fail to meet clients’ requirements and expectations – something to the tune of 80% or higher. One of the most common reasons for this, which is also one of the most difficult to detect and either avoid or correct, involves communication errors. Sadly, the earlier a misunderstanding occurs in the development process, the larger the impact it can have on the later stages, and even on the products that are ultimately delivered to the client. As with many things, tiny causes can lead to dramatic effects, and there’s even a name for this phenomenon – the “Butterfly Effect.”
This name comes from the idea that even something as seemingly insignificant as the flapping of a butterfly’s wings can have an effect – however minuscule – on the course of a hurricane. While this is certainly an extreme example, the principle is a useful one; don’t ignore the little details, and pay attention to the subtle influences.
In professional software engineering, specially trained and experienced individuals are hired to act as intermediaries between the development teams and the clients, and when I say “intermediaries,” I mean diplomats, interpreters, and conflict-resolution managers. Their role as interpreters can be critical, even if (maybe even especially if) a common language is used.
Computer programmers are a special kind of people. By-and-large, we have a rather unique reference pool from which we draw our anecdotes, humor (If you’re not part of the solution, you’re part of the… precipitate), and cultural references (WarGames, Tron, Lord of The Rings, Monty Python, The Matrix, etc.). We also have our own sub-language, which sometimes causes us to use words that, while generally known, take on unique connotations within the group. Those of us heavily involved in the theoretical side of things, and who use computers to solve complex problems, will do things like reading the Wikipedia entry on Feynman Diagrams for fun (and to double check the math), and we’ve learned to ignore the weird looks people give us when we discuss it the next day around the water cooler.
By the same token, business experts, company leaders, and financial specialists can often be identified by their jargon and choice of words. I have no idea, for example, what a “Hedge Fund” actually is… well, I do now, because I just looked it up, but you see what I mean.
Because of this, professional communication in the field of software development tends to avoid words that may be perfectly reasonable in a casual conversation, but have the potential to be disastrously ambiguous. Such words include “some,” “sufficient,” “many,” “inexpensive,” “various,” “mostly,” and – perhaps most infamously – “soon.” In software forums that discuss upcoming updates and bug fixes, the latter is sometimes written as SoonTM by impatient end-users, since it is so frequently used by developers who are deliberately trying to avoid being tied down to a particular release date that they may as well have trademarked the term.
In a way, students at all levels, and across all majors, can learn a lot from the software engineering process. Whether joining a new class or taking a test, the first step should always follow the pattern of the requirements phase. The question, “What is being asked of me?” is likely the most important question that a student can ask, and even if it isn’t voiced out loud, the answer to this question should be the driving force behind reading a syllabus, becoming familiar with classroom policies, going over the instructions for an assignment, and responding to a quiz question.
The last one there, “responding to a quiz question” is something I’d really like to emphasize. As an educator, I’m not particularly, or at least not overly, interested in my students’ ability to recall facts and figures. That is certainly necessary for competence in any complex field, but just as important is the ability to reason, apply, and create. Because of this (and this is especially true in my online classes in which students have access to course materials and the entirety of the Internet) I will rarely ask a quiz or test question like, “What does VLSI stand for?”
I do want to know that my students are familiar with this term, but I am not merely testing their ability to use Google, or to vaguely recall the video module in which it appears. As a result, I am much more likely to ask compound questions. Thus, “What does VLSI stand for? What are the most recent developments in using new conductive materials to reduce the minimum safe distance between transistors? Does this contribute to the fact that my expensive NVidia graphics cards keep dying?”
A surprising amount of students… no, an appalling amount of students, will only answer the first part of that question. I don’t really expect them to answer the third part, although it’d be great if they could… but to get full credit they really need to be able to apply what they’ve learned to a thoughtful reply. And it doesn’t seem to be a function of intelligence. Sometimes the brightest and best-performing among my students will leave portions of questions blank that I know they can answer with ease. They aren’t lazy, and they certainly aren’t running out of time. They just didn’t read the questions carefully enough, and didn’t take the time to double-check their answers before submitting their work. They weren’t clear on the requirements, and therefore the rest of their efforts were insufficient at best, and misdirected at worst.
Many As have become B+s, and many Cs have become Ds, because of this very phenomenon. When going over test papers with my students, they will not infrequently say, “Ah, I knew that! Why didn’t I see that during the test?” Far, far less often do they say, “I had no idea what the answer was. I didn’t study that at all.” It doesn’t have to be that way. If we know what we are supposed to be doing, then our choices become meaningful, and our progress consistent. We always have the option to not do something we understand, but we rarely have the option to do something we do not understand. That’s agency, independence, power.
I’d better stop here. I think I am in danger of becoming… quotable.
So anyway, as you participate in your classes, whether for the first semester or the last at our wonderful institution, make sure that you’re always checking the requirements of whatever you are working on. Get a good initial feel for your classes and your instructors’ expectations – and it is certainly our responsibility to make these clear to you – and the rest is much more likely to just fall right into place.
It’ll make you a better student, more successful, more patient, more precise, and more effective; or at least, it will look that way to the people around you.
P.S. VLSI stands for “Very Large Scale Integration,” and it involves the design and manufacture of microchips in such a way that they, among other things, efficiently distribute heat generated by their use across their components so as to avoid damaging their tiny, very delicate structures. Now go impress your friends.
Assistant Professor of Computer Science and Engineering