http://tc.eserver.org/authors/Ferlazzo,_Ellen_Lawson A bibliography of works by Ferlazzo, Ellen Lawson in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Ferlazzo,_Ellen_Lawson http://tc.eserver.org/27572.html http://tc.eserver.org/27572.html What quicker way can there be to find out if something is teachable than to write up task-oriented documentation? And as things are built or changed, the documentation is updated. I often update the documentation before the code! http://tc.eserver.org/27575.html http://tc.eserver.org/27575.html Your requirements document needs to focus on the user’s goals. They should not be marketing’s list of features 'we’ve got to have' because the competition has these features. They should not be a list of things the programmers think ought to be included 'because we can add those things for very little cost.' Feature bloat does not benefit the user. http://tc.eserver.org/27576.html http://tc.eserver.org/27576.html Handheld devices and small appliances pose a unique challenge to the interface designer. The blur between user interface and functionality (interface vs. interaction) is even more pronounced in these environments. The interface of any small device is extremely important; yet, more than ever, the necessity to build in exactly (and only) what is required by the user is extremely important! http://tc.eserver.org/27573.html http://tc.eserver.org/27573.html Software is sometimes poorly designed to begin with and the interface should be scrapped and rebuilt from scratch. But more often than not, I see software that started with a decent design and has since had features added onto it with each release, squeezed into the existing design rather than being designed in. People aren't in a design mindset but an 'enhancement' mindset somehow. http://tc.eserver.org/27577.html http://tc.eserver.org/27577.html Your requirements will assist you in delivering a software solution that meets your users' needs. You can find all sorts of templates and formal processes for requirements of various kinds, and while they are useful, the biggest problem I've found is that most people confuse defining the need with proposing a solution. As soon as a requirements document contains any part of 'how we're solving this', you've crossed the line into presupposing that you already know what the problem is and can stop listening. http://tc.eserver.org/27578.html http://tc.eserver.org/27578.html In any software development methodology, there's a secret ingredient that doesn't get enough press. It doesn't matter whether you follow Cooper, Beck, McConnell, or anyone else on the long list of notables. http://tc.eserver.org/27579.html http://tc.eserver.org/27579.html Smart and energetic people believe 'Never put off till tomorrow what you can do today.' Smart and lazy people say 'Never do today what you can put off till tomorrow!' This is, to me, one of the most useful tenets from the eXtreme Programming movement. http://tc.eserver.org/27580.html http://tc.eserver.org/27580.html As I write the 'how to' documentation based upon the in-process design, the weaknesses of my original design become apparent and I go back and forth from writing text to designing the software until it all flows. http://tc.eserver.org/27581.html http://tc.eserver.org/27581.html Let's say you've got a clear set of requirements; the users have been defined, the features are associated with user tasks, marketing has done a competitive analysis and everything is good to go. Now what? http://tc.eserver.org/27585.html http://tc.eserver.org/27585.html A broader awareness of how changes can impact other things, including schedule commitments and work outside of the immediate area of change, is beneficial in terms of assessing trade-offs and benefits.