In the example cited, it can be seen that by asking WHY , the author can define all of the needs that the system must meet and will then state the real requirements, e. Each of the above listed requirements might result in a data base type of system, but the requirement for the database was not needed.
There are two major dangers in stating implementation. The one most often cited is that of forcing a design when not intended. If all the needs can be met without a database, then why state the need for a database. If they cannot be met, another, or better way, then a database will be the solution -- whether or not there was a requirement for a database. The second danger is more subtle and potentially much more detrimental.
By stating implementation, the author may be lulled into believing that all requirements are covered. In fact, very important requirements may be missing, and the provider can deliver what was asked for and still not deliver what is wanted. Providing a database will not be sufficient for someone needing a requirements management tool. It is the capabilities of the tool that need to be stated as requirements.
At each level of requirements development the problem of needs versus implementation will occur. At the system level the requirements must state WHAT is needed. To ensure that you have not stated implementation, ask yourself WHY you need the requirement.
If this does not take you back to a real need statement, then you are probably stating a need and not implementation. The Implementation Trap. If you have been doing design studies at a low level, you may begin to document these results as high-level requirements -- this is the implementation trap.
You will be defining implementation instead of requirements. An individual submitted a requirement like this:. The ACRV had no requirement for a water landing -- that was a design option. The individual had been working with that design option, and from previous Apollo experience known that crew rescue was possible only in certain sea states.
When asked WHY the requirement was needed, the individual stated that the crew could not be left in the module for a lengthy period of time, thus the landing needed to be where and when sea states could accommodate crew rescue. He had a valid requirement -- but not the one he had written. Whether the ACRV landed on water or land, removing the crew within a limited time period was essential. Thus the real requirement was:. The question WHY will resolve most implementation requirement errors. Always ask WHY a requirement is needed to insure that you have not fallen into this lower level requirement trap.
This problem is somewhat similar to the implementation problem. The statement was written as a description of operations, not a requirement about the environment. The next requirement again describes the operations and is confusing. The statement was rewritten and resulted in a requirement and a design goal.
The design goal is needed because no quantifiable requirement can be written regarding suit mobility. The danger in stating operations, instead of a requirement is 1 the intent may be misunderstood and 2 determining how to verify can be a problem.
In a specification, there are terms to be avoided and terms that must be used in a very specific manner. Authors need to understand the use of shall , will , and should :. These are standard usage of these terms in government agencies and in industry.
You will confuse everyone if you deviate from them. All shall statement requirements must be verifiable, otherwise, compliance cannot be demonstrated.
Terms such as are, is, was, and must do not belong in a requirement. They may be used in a descriptive section or in the lead-in to a requirements section of the specification. There are a number of terms to be avoided in writing requirements, because they confuse the issue and can cost you money, e.
The word support is often used incorrectly in requirements. Support is a proper term if you want a structure to support 50 pounds weight. It is incorrect if you are stating that the system will support certain activities. The system shall provide automated training scenario processes.
The terms but not limited to , and Etc. Using these terms will not accomplish what the author wants and can backfire. The reason the terms are used is to cover the unknown. The contractor will not increase the cost in the proposal because you added these terms.
The only way to get the work added is to place an analysis task in the Statement of Work SOW to determine if more items need to be added to the list. In the SOW you can control what effort the contractor will expend to address these unknowns. If more items are found, you may have to increase the scope of the contract to cover the additions.
Often the terms are used interchangeably, especially shall and must, with no definition of what either means. The fact is that many international standards, including ISO, use the shall, will, should convention.
So, I recommend that you limit your use to these 3 terms in your requirement document. Make sure to define these terms at the beginning of your document so everyone knows exactly what is meant. Another reason you should stick to the shall, will, should convention is that these have attained acceptance in both the international and United States court systems. Requirements are complicated enough — we advise that when writing requirements, stick to the basics.
Shall — Requirement : Shall is used to indicate a requirement that is contractually binding, meaning it must be implemented, and its implementation verified. Remember, we are trying to communicate and it is much easier if we agree on the terms.
Facts or Declaration of Purpose. Will is used to indicate a statement of fact. Will statements are not subject to verification. Should — Goals, non-mandatory provisions. Should is used to indicate a goal which must be addressed by the design team but is not formally verified.
Why include should goal statements in your requirement document? Well anything but a decal will probably impeded crew mobility so how am I going to verify that statement if it is written as a requirement? I have seen some organizations treat goals such that they are expected to be met unless the design team has a good reason for not doing so. Of course any value in between the threshold and goal is acceptable. You always want to keep your goals in front.
Not buried in the requirements, but in the same specification. Also, shall has held up in court, must has not. Granted, must does sounds stronger, right? But, when writing requirements, keep things simple and just use shall.
Here is what the dictionary states, plus my own examples: Shall and its negative shall not—-the imperative form of the verb—-is used for a mandatory requirement. May and its negative may not is used to indicate a non-mandatory suggestion or permission. Must and its negative must not shall never be used, since one of its meanings is synonymous with ought and should.
You are correct in the blog; but a definition of each terms, as well as its negative, is important. Good luck. Ad, thanks for the additional information. She holds a master's degree in microbiology from San Francisco State University. Blumenthal is an ASQ member. Shall vs. Should by Cynthia Blumenthal When writing quality management system QMS documents that state requirements, most of us have used auxiliary verbs such as will, shall, may, might, should , and can.
About the author Cynthia Blumenthal is a regulatory engineer in California. Featured advertisers. ASQ is a global community of people passionate about quality, who use the tools, their ideas and expertise to make our world work better. In the time it takes to have a coffee.
Requirements Terminology Therefore I find using precise terminology to be useful. Network Break Podcast Network Break is round table podcast on news, views and industry events.
0コメント