TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> Not having seen any of the material you're discussing I'm having
> a hard time seeing the distinction between your "business
> requirements" and "functional requirements." I don't think I've
> ever worked on a product development in which what we called
> "business requirements" were so large that there could have been
> something that was only 1/12 of the total. Ours were basically
> what market the product was going to sell to, what its basic
> function was, what projected price range we thought we could
> sell it in and what its cost to deliver would have to be in order
> for it to make an acceptable profit to justify its development.
> What am I missing?
>
> Gene Kim-Eng
Gene,
I can see a difference between business requirements and functional
requirements. I haven't worked for a company that markets software in quite
awhile. As I recall, business requirements are a small part of marketed
software, but there are considerations for a market need that does not exist
in in-house software and systems.
For the companies and state agencies where I have worked, there are business
requirements before a software or system is developed or purchased because
there must be a business need that justifies the expense for the software or
system. The business requirements do exist even when there is not a
document to support them. "Somebody" gets the idea there is a business need
and everyone agrees. What "everyone" agrees to should be documented and
this is not always the case. For state agencies, I have seen that
documented business requirements are necessary before the development of the
Feasibility Study Report that requests funding. Functional requirements
occur after funding and a development project is approved.
The way I see it, functional requirements are not necessary for boxed
software in the same way as they are for developed software. I might be a
little fuzzy on some of the connections between documents, but in a boxed
software, functional specifications, that is what the software does, must
match up with business requirements. For developed software, functional
requirements, that is what the software will do, must match up with business
requirements.
Perhaps my experience and understanding is different from that of other
people.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
