Did you know that, at present, two-thirds of the new applications developed never see the light of day? Wow. That's an impressive statistic. There are several reasons for this, of course, including a development cycle that is too long, unrealistic goals, changing hardware or operating system influences, etc. None of the other reasons for failure to launch, however, occurs as frequently as flawed requirements gathering—that is, the communication between those who need a solution and those who provide the solution is inadequate.

Requirements Discovery

One of the most important activities in the application development process is the gathering of system and user requirements. These are your "marching orders" for things the system should do (functional requirements) and the set of constraints under which the system must run (non-functional requirements). The difficulty in acquiring accurate specifications has long been recognized, and multiple software engineering disciplines exist to validate the requirements collected. The approach may be documentation-intense, with specifications written up, reviewed, signed off, prototyped, reviewed, and so on. Or the approach may be lightweight and agile, with little "stories" about small user tasks representing the specifications and the development cycle being tight and frequent. The purpose, in any event, is to mitigate the risk of faulty requirements discovery.

Non-IT Personnel

As IT professionals, we developers rely on input from a variety of concerned persons called "stakeholders." As the name suggests, stakeholders are those with something to be gained from the successful development of a technical solution. Stakeholders include users, managers, trainers, network engineers, auditors, etc. Generally, these individuals are more than just people with something to gain or lose; they're actually participants in the solution development process. In that respect, each stakeholder will have his/her own perspective or viewpoint.

Multiple perspectives are a natural condition of software development because multiple stakeholders are involved. Each has a personal agenda, and if the agenda is understood, the viewpoint may be evaluated accordingly. One stakeholder's priority may be to minimize payroll, another's to maximize production, another's to improve customer service, and yet another's to look good on the annual audit.

The viewpoint-oriented approach to solution development recognizes that multiple perspectives exist, and it requires a mechanism for resolution of conflicting differences. Sometimes, one stakeholder's viewpoint trumps another's. Determining the respective merit of one against another can be a challenge for machine-oriented personnel. Into the mix, add politics. If the boss favors a particular individual or department, you may be handcuffed. (Have you ever noticed that accounting seems to get anything they want? I think that's because they deposit the checks.) In that atmosphere, the likelihood of failure is amplified.

Application Domain

The environment in which a technical solution operates is called the "application domain." Essentially, this is the specific business or scientific area that the system is intended to benefit. Getting accurate and complete information about the application domain can be difficult for a couple of reasons:

• Although "non-technical" folks are not computer-oriented, they nonetheless may be very technical within their domain. Frequently, these people will rely heavily on specific jargon to describe their requirements or operating environment. This use of jargon can be a source of misunderstanding or of incomplete communication.
• Some aspects of the stakeholders' domains may be so familiar to them that they assume that they're familiar to you as well. A stakeholder may gloss over essential details or omit important information altogether.

Interviewing

Most of the system requirements will be discovered through the interviewing process. An interview can be formal, in which a predetermined set of questions is asked, or informal, in which observations are made and questions are asked as needed, or a combination of the two. Some formal questions should be included in even the most casual ad hoc interviews because the direction of the interview may go astray or may get mired in a relatively insignificant topic.

Nevertheless, people like to talk about their jobs, and they usually appreciate being included in the system design process. Your strongest tool, then, is patience. If you expect to garner accurate requirement specifications, you have to put in the time.

Once collected, system and user requirements are organized and grouped into related types. Then, the requirement types are prioritized, conflicting requirements are identified, and resolutions are negotiated. This activity in the process is often assisted by middle management personnel, even though they themselves are non-technical. Finally, when the dust has settled, the requirements are compiled into some sort of document.

Asking Key Questions

Sometimes, users will indicate equal concern about a condition that is the exception, rather than the rule. They will go on about something that, although annoying to them, is minor in comparison with the grand scale of things. To ferret out these sidetracking influences, you should ask questions like these:

• How often does that happen?
• When did it happen last?
• What did you have to do to fix it?
• But most of the time, how does it go?

Further, you have to crack the code. By that, I mean you must identify the hierarchy of conditions that will, in turn, fire processes. For example, process B is only appropriate if condition A is true. If condition A is not true, then skip over process B and proceed to process C. It can be very difficult at times to get a clear understanding of these rules through the interview process because the dependencies of conditions can be very complex and users tend to emphasize the details of the processing over the higher-level perspective. You may do well to frequently ask "Do you perform that process every time or just sometimes?" or "Does that process apply to all the transactions or just some of them?" This will help keep your understanding of the domain on track.

User Interface Design

For reasons too numerous to mention, the user's interface to an application has become crucial to the application's success. It must be recognized that users do not read. They don't read screens, they don't read error messages, and they certainly don't read manuals. You have to expect this and build your application accordingly. Your user interface, although new and improved, must also be old and familiar. Most successful new systems build on the computer know-how that their users already possess. Any unfamiliar new features should adhere to the principles of affordances (designs that invite proper use intuitively) and natural mappings (making your system operate in a manner that the user intuitively recognizes).

Deploying a New Application

Actually getting the target consumer to adopt a new application can be very tricky. For a number of reasons, people are reluctant to let go of an application they're already very familiar with and strike out on an entirely new course.

Learning a new system is unsettling for the users, but the system developer can diminish this concern if the users have been included in the requirements discovery and interviewing processes. If the users feel that the new system is an outgrowth of their own involvement in the process, they will acquire "pride of authorship," even though they can't write a lick of code. The new application will represent the specifications they themselves asked for, and they will adopt—indeed even defend—the new system.

You have to show the users that you're on their side. They should see that your goal is to genuinely understand their viewpoint through intelligent questions and conscientious observation and that you're prepared to incorporate their requests into the system. They should also see that you intend to make an improvement in the quality of the tools they use to do their job.

What non-IT personnel should not see, however, is your technical solution as a threat to their professional well-being. To that end, you should stress the importance of the user's grasp of the business operations—with or without a new computer system. The application to be deployed, then, is just another tool that is going to make the user's day more productive, satisfying, and predictable. If you have the goodwill of your users, the reaction is positive, the adoption time is minimized, and the effort is more likely to be considered a success.

Believe it or not, there are still people in the world who are uncomfortable with computers. They can feel that the computer is sort of watching them and drawing conclusions as to their performance and reporting it somewhere. These folks usually make a point of announcing their discomfort with computers and so are self-identifying. For them, a soft touch is appropriate. You must be extra patient and non-technical in your dealings with them.

Ironically, these users can provide the most beneficial input to the development process. It's their perspectives that you, as a technical professional, can least anticipate. What may seem obvious to you may not be so obvious to them and vice versa. The back-and-forth dialogue with the stakeholders should not be slighted (especially in the late stages of the development cycle, when deadlines are drawing near and patience is wearing thin).

Knowing the Business

When I was doing the hiring for a large IT installation and I interviewed developers, I weighed strong programming skills at about 50%. That is, being a hot-shot programmer got you about halfway there. Equally important in a candidate's value was knowledge of the business. And, sure enough, the best applications we produced came from a strong understanding of the application domain.

Non-technical personnel, as consumers of our application development services, are the customers. Clearly, with a 66% non-acceptance rate for new applications, they aren't buying everything. We then, as application developers, must continually provide a better product. The traits of the target consumer have to be regarded and accommodated just as though we were trying to get them to buy a house or a car. When it comes to opinions, theirs are really the only ones that count.

Chris Peters has 26 years of experience in the IBM midrange and PC platforms. Chris is president of Evergreen Interactive Systems, a software development firm and creators of the iSeries Report Downloader. Chris is the author of The i5/OS and Microsoft Office Integration Handbook, The AS/400 TCP/IP Handbook, AS/400 Client/Server Programming with Visual Basic, and Peer Networking on the AS/400 (MC Press). He is also a nationally recognized seminar instructor and a lecturer at Eastern Washington University. Chris can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

Chris Peters has 32 years of experience with IBM midrange and PC platforms. Chris is president of Evergreen Interactive Systems, a software development firm and creators of the iSeries Report Downloader. Chris is the author of i5/OS and Microsoft Office Integration Handbook, AS/400 TCP/IP Handbook, AS/400 Client/Server Programming with Visual Basic, and Peer Networking on the AS/400. He is also a nationally recognized seminar instructor and a lecturer in the Computer Science department at Eastern Washington University. Chris can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Chris Peters available now on the MC Press Bookstore.

		i5/OS and Microsoft Office Integration Handbook Harness the power of Office while exploiting the i5/iSeries database. List Price $79.95 Now On Sale

Also Read

The Principles of Project Management, Part 1

COVID-19 and Working from Home

Internship Tales