Getting Clueful: Five Things CIOs Should Know About Software Requirements
- 03 April, 2007 12:37
- Comments
Some days, you wish you had telepathy. You just know that your development staff is holding back in some way, but you don't know how to get them to communicate. Is the project in trouble, but they're afraid to tell you?
Since your software development staff won't tell you what they're really thinking, I asked them to confide in us instead. I posed a single question to professional programmers and testers: If you could get your CIO to understand just one thing about software requirements, what would it be?
From the answers, I collated the five things at the top of their minds. If you grok these concepts, you will win the respect and support of your programming department (prizes you'll also earn for understanding the term grok), and you'll optimize the chance of success for your next software project.
I must warn you that this will shock some developers. Most of them don't expect you to have a clue.
1.THE INCONVENIENT CHECKBOX: Understand the Role of Requirements
Many development projects are handicapped from the start. The requirements are vague and subject to interpretation, require intimate knowledge of the business to interpret correctly, and aren't prioritized. "It's a classic garbage-in, garbage-out situation," says James Pulley, director of professional services at PowerTest. "Poor requirements are provided to a development organization that either does not question them or receives hostile glares from the business community when clarification is sought. Items requiring insight or interpretation are interpreted one way by the requirement writer, a second way by development, possibly a third way by QA."
It's critical to establish some sort of process for documenting software requirements — what one developer plaintively described as avoiding an ongoing guessing game. Yet, say many developers, managers often forget why they gathered the software requirements in the first place. QA tester Darrel Damon complains that some organizations act as though requirements are "an inconvenient checkbox that has to be gone through for legal purposes". In one project on which he worked, for example, management paid little attention to maintaining and updating the requirements. "It was as if the requirements checkbox had been checked, so we could move past requirements," he says. "When requirements did change, there was no formal notification to the rest of the team."
This was more than a political issue. During testing, Damon entered a defect report when he found a specific discrepancy between the application and the requirement. The business analyst said it wasn't a defect; the application was right and the requirement document was wrong. "I argued that it was a defect regardless, because defects are not just in the app. I stood my ground and refused to close the defect. I finally got a meeting with the business owner; the requirement was right and the app was wrong. [The analyst's] comment about it not being a defect because it was 'only a documentation issue in requirements' spoke volumes about the value placed on requirements."
But that's the easy item. Most developers say their CIO understands the importance of requirements. It's what happens after that where things get . . . interesting.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.
- Bookmark this page
- Share this article
- Got more on this story? Email CIO
- Follow CIO on twitter
-
Monash Uni reduces IT teams after consolidation project
-
FTC warns makers of background checking apps
-
Time to get Agile
-
QLD govt demands answers after pay glitch
-
Monash Uni reduces IT teams after consolidation project
-
Eight threats your antivirus won’t stop - Why you need endpoint security
News headlines are a constant reminder that malware attacks and data loss are on the rise. High-profile incidents that make big news might seem out of the ordinary. Yet businesses of every size face similar risks in the everyday acts of using digital technology and the Internet for legitimate purposes. This paper outlines eight common threats that traditional antivirus alone won’t stop, and explains how to protect your organisation using endpoint security. -
Cost Effective Security and Compliance with Oracle Database 11g Release 2
Information ranging from trade secrets to privacy related information has become the target of sophisticated attacks from both sides of the firewall. Protecting data now requires a strategy that enables both preventive and detective controls. Read on. -
Unified & Collaborative Communications
The demands on day-to-day business activities are changing all the time with the wide variety of communications media now available being a major contributing factor. They also serve to cut response times, thereby speeding up processes. With employees often working across many different sites being able to control their availability, enables new opportunities for working more efficiently.
-
Hdtv for Dummies, 2nd Edition
-
Mastering Windows Server 2008 R2
-
C++ for Dummies, 5th Edition
-
The Data Model Resource Cd-rom, Revised Edition, Volume 1
-
Ipv6 Mandates
-
ActionScript 3.0 Bible, Second Edition
-
Mastering AutoCAD Civil 3D 2008 (Includes CD-ROM)
-
BEA Weblogic Workshop
-
Professional ASP.NET 3.5 Ajax











Comments
Post new comment