It might be dangerous to volunteer your sister to be a use case for a software project, especially when that software project comes from the startup of a good friend. There are just too many opportunities for problems. Your sister can feel that she is being used. Your friend might start to suspect that he gathering information for you. In spite of all of these and other possible problems, I volunteered my sister.
My friend needed to gather information from a potential customer that matched my sister’s background. My sister, a researcher who works in the arts, was interested in getting a little more insight into software development. I thought that the process would teach my sister a little about software development and that it would give my friend’s company some insight into a more sophisticated customer. I’m not sure that I was right on either point.
According to a recent article in IEEE Software magazine, use case analysis has “become the de facto best practice for capturing requirements in software projects.” It is a relatively simple process that is similar to focus groups in marketing. You bring together a group of people who represent most of your potential users. In this case, the software company wanted a young engineer, a business manager who used email and word processing and nothing else, a mother with small children, a person who used computers for creative purposes, someone who used a lot of different computer programs for work, a teacher, and finally, a woman who cared for another person at least half time. (The last person was my sister.)
For each of the people in the use case group—people who are usually called “actors”—the developers explain the basic goals of the software. They then ask each actor how the software should operate: what it should and should not do, what actions will be helpful and what will not, what tasks the software must do and what it should never do. The process is straightforward and is far more common than other ways of gathering information from potential customers. It has a set of concepts and diagrams that are far simpler than any of the alternatives, which use a formal language called Unified Modeling Language.
In spite of its simplicity, or perhaps because of it, use case analysis has been occasionally criticized by a certain segment of the software engineering community. The complaints suggest that use case studies are often inconsistent, too detailed, or not detailed enough. Perhaps the most damning compliant is that many use case analyses confuse the process of gathering information with the work of promoting the software that the developers want to build. The engineers spend their efforts teaching the actors the tasks that the software will perform, rather than listening to the actors tell them what the software should do.
Such complaints, of course, can be leveled at almost any aspect of software engineering. Perhaps more than any other form of engineering, software engineering is a learning process. In each step of the software development process, software engineers have to learn new things. They have to learn what the customer wants. They have to learn how the development environment will support the software. They have to discover their mistakes and find the limitations of their ideas. In such an environment, it is not surprising that much of the recent innovation in software has emphasized the idea that software development teams are engaged in a learning or self-educational process.
The Agile Manifesto, perhaps the most strident addition to the software engineering literature, ends by recognizing the self-educational nature of software development. “At regular intervals,” it concludes, the development team “reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” In modern software development, these “regular intervals” are of very short duration. Software engineers once thought that they would review lessons learned with the release of each new version of the software, something that might happen annually or every six months. In the modern development environment, software engineers reflect on what they have learned weekly or increasingly, daily. In many a morning standup—the meeting that begins the workday for software engineers—each participant is asked to answer four questions: “What have you accomplished?” “What is your goal for today?” “What problems stand in your way?” And finally, “What have you learned?”
Software engineers not only need to learn about the system requirements. They also need to learn about the software stack they are using, the algorithms they are using, even the way that they are debugging and testing the program. Software engineering is a complex field that poses questions that are not always answered by conventional engineering methods. As I have moved through the software industry, I have had many an opportunity to ponder the decisions of software engineers. I have wondered about complex software architectures, opaque data formats, and even excessively convoluted lines of code. More than once, I have concluded that the software developer had simply not learned enough about the craft to do the job well.
Many current writers, including industry leaders such as Ivar Jacobson, are writing of software as a combination of an engineering and a craft discipline. In an engineering discipline, the participants focus on building a body of knowledge and standards. In a craft, the workers focus on learning. Programming, “as a craft discipline,” writes Jacobson, builds “on the experience of software ‘masters’”—people who have learned how to work and are able to teach others. An earlier writer, Princeton professor Mike Mahoney, compared software engineering to the work of an architect, the professionals who design buildings. Architects spend a lot of time in tasks that look a lot like use case studies. They try to understand how people will use the buildings, what features they will need, and what aspects need to be eliminated. “Architecture has a different history from engineering,” Mahoney writes, a history that is less interested in theory and more interested in how people interact with building. He also notes that “we train architects differently from engineers.”
At one point, I was able to ask the engineers at my friend’s company what they had learned from my sister. “She was more sophisticated than we expected her to be,” one of them said. “She knew how to do a lot of things but was impatient with the steps to do them.” When I asked if she had changed the design of the software, they properly responded that all the use case actors determine the requirements for the system, not a single individual.
Later, I had a chance to ask my sister what she thought of the experience. She shrugged her shoulders. “They seemed to know a lot about me,” she said, “but I still said a couple things that surprised them.”
“Do you think they learned something from you?” I asked.
My sister paused. “Maybe,” she said, “but if they did, they learned that they didn’t know everything.”
About David Alan Grier
David Alan Grier is a writer and scholar on computing technologies and was President of the IEEE Computer Society in 2013. He writes for Computer magazine. You can find videos of his writings at video.dagrier.net. He has served as editor in chief of IEEE Annals of the History of Computing, as chair of the Magazine Operations Committee and as an editorial board member of Computer. Grier formerly wrote the monthly column “The Known World.” He is an associate professor of science and technology policy at George Washington University in Washington, DC, with a particular interest in policy regarding digital technology and professional societies. He can be reached at grier@computer.org.