Re: "Allow" vs. "Require"

Subject: Re: "Allow" vs. "Require"
From: Lauren <lauren -at- writeco -dot- net>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Mon, 09 Apr 2012 22:52:08 -0700

On 4/9/2012 6:13 PM, Keith Hood wrote:

These are requirements you're working with. A requirement is just that - something that is required. It's something that the software must do. So the requirement should be written as an imperative - the software will or the software must.

These, however, are not generic requirements, they are design requirements. Such requirements are not just about what the
"software must do," they are about how the user will use the software.

For the purpose statement of the requirement, just put "The RCP will provide the user a mechanism for schlepping the pekele."

I have done some development in my time, but I do not understand what a developer is supposed to develop with that requirement. If I read it, I would wonder, is the tool already developed and I need to develop around it or am I to develop that tool that "will provide" the mechanism and I will wonder what is the nature of the mechanism.

I think that design requirements should be specific and not lead developers to guess what is they are supposed to develop. Developers should focus on functionality and not have to worry about design.

That says what functionality has to be built in but allows a lot of slop in deciding exactly how to implement it, just the way programmers want it.

"Slop" in requirements is bad, precision is necessary. Ineffective programmers may want latitude in design requirements, but that is not because they will produce useful programs.

When you write the specs for that requirement, there's where you can put in nitpicking about whether the pekele schlepping dialog box is modal, whether or not it has a cancel button, etc.

What do you mean "when"? I read this question as being about how to phrase a design requirement. How can the specifications become *more* concise than the design requirements? They can have less detail than design requirements, but they should not add anything to them, like how the user is to interface with the application. Specifications are built around requirements, but they should not change or drive them.

What the frabjapping bleep is a pekele?

A pekele is a four-stringed guitar-type instrument made with potassium instead of uranium.

Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.

Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @


"Allow" vs. "Require": From: Dan Goldstein
Re: "Allow" vs. "Require": From: Keith Hood

Previous by Author: Re: "Allow" vs. "Require"
Next by Author: Re: "Allow" vs. "Require"
Previous by Thread: Re: "Allow" vs. "Require"
Next by Thread: Re: "Allow" vs. "Require"

What this post helpful? Share it with friends and colleagues:

Sponsored Ads