I’m in the middle of teaching my Software Requirements Engineering course at UCSC Extension. On the first day of class, I always ask my students what problems they’re hoping to solve by coming to this class. Once again I was struck by the commonality of answers from students in all kinds and sizes of companies in the Valley:
“My management won’t support the introduction of process/project management into the company because they think:
a. it won’t be worth the time and money
b. we don’t have the time
c. we can’t spare the resources because we need them to work on Urgent Project X that is behind schedule
d. it’s just a boondoggle for highly-paid consultants and managers
e. yada yada yada”.
It’s the same story over and over again. The students have a gut feeling that there must be something out there that can make their projects more successful (or at least less chaotic), but they are not supported by their management in their quest for answers in the project management world.
My students are all engineers of one sort or another (software, testing, hardware), and I promised them (as I did students in my Software Project Planning, Monitoring, and Management course) that I would give them persuasive arguments to help them convince Management.
Written Requirements
So, once again, my students are telling me the same requirement stories:
· “no one will write down project requirements for us”
· “it even seems like they’re avoiding writing them down”.
And the excuses they get from their management are a variation on those above:
· “we don’t have time to write down requirements for you (it will delay the start of the project)”
· “you know what we need, why do we have to write it down?”
· “we can’t spare the resources (they’re busy starting the project)”
· (and, my personal favorite) “they’ll just change anyway”.
The importance of software requirements for Engineering organizations is the typical list, obvious to many, but not so to all:
· Makes sure the expectations of what the product will do is shared by all stakeholders
· Makes sure the product is technically feasible
· Forms the basis for work estimates and the schedule
· Forms the basis for later testing
· Forms the basis for change
These address why requirements are important for Engineering, but doesn’t address why they should be written. And the reasons for needing written requirements strikes at the heart of some of the struggles getting them written down.
Getting requirements written down (and ultimately signed off) is the way Engineering gets the writers (whoever that may be) to commit. And fear of commitment is, I believe, the primary thing that keeps potential writers from doing the writing. By committing the requirements to writing, and putting their signature on the document, the writers are saying “This is it. This is all. This is now perfect. Go forth and build.”
And for a multitude of reasons, they just can’t make themselves do that.
But written they must be. Perhaps Management could see the benefits to them of written requirements…
Helps with Marketing decisions. The more detailed product information that goes into written requirements helps Executive management and Marketing decide which projects to fund.
Provides Marketing material. Those screen shots and user scenarios can form the basis of excellent product data sheets. The writing that goes into good requirement descriptions leads to good customer-benefit text which helps with advertising text.
Will help meet critical delivery timelines because accurate work estimates lead to reliable scheduling. This should be a no-brainer, but, sadly, isn’t.
High quality, written requirements will lower the costs of developing and maintaining software and speed time to market because they will reduce rework. Explaining the costs of software rework isn’t always as easy as explaining the cost of tearing down and rebuilding part of a construction project, but with patience, it can be explained that way. Relating maintenance costs to technical support staff, interference with future new projects, and company reputation can be very helpful.
And a final one that should be used very carefully:
You can’t change what isn’t written down. Recognizing that some change is inevitable, when the time comes to make a change, it really can’t be accomplished unless there’s something to change. Following this up with a dialog about change management is usually a good idea here.
Build a good dialog around these points, and at least you can say you tried:
And, if all else fails, then you need to write the requirements down yourself. But that’s another topic.
Anita Wotiz
www.duckpondsoftware.com
Instructor, UCSC Extension, SEQ Program
Software Requirements Engineering (next class Aug 2008)
Software Project Planning, Monitoring, and Management (next class Nov 2008)
