Главная страница Случайная страница
КАТЕГОРИИ:
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
What Should I Know about Writing an SRS?
|
|
Unlike formal language that allows developers and designers some latitude, the natural language of SRSs must be exact, without ambiguity, and precise because the design specification, statement of work, and other project documents are what drive the development of the final product. That final product must be tested and validated against the design and original requirements. Specification language that allows for interpretation of key requirements will not yield a satisfactory final product and will likely lead to cost overruns, extended schedules, and missed deliverable deadlines.
Table 4 shows the fundamental characteristics of a quality SRS, which were originally presented at the April 1998 Software Technology Conference presentation " Doing Requirements Right the First Time." Reprinted with permission from the Software Assurance Technology Center at NASA (https://www.gsfc.nasa.gov/). These quality characteristics are closely tied to what are referred to as " indicators of strength and weakness, " which will be defined next.
Table 4 The 10 language quality characteristics of an SRS
| SRS Quality Characteristic | What It Means |
| Complete | SRS defines precisely all the go-live situations that will be encountered and the system's capability to successfully address them. |
| Consistent | SRS capability functions and performance levels are compatible, and the required quality features (security, reliability, etc.) do not negate those capability functions. For example, the only electric hedge trimmer that is safe is one that is stored in a box and not connected to any electrical cords or outlets. |
| Accurate | SRS precisely defines the system's capability in a real-world environment, as well as how it interfaces and interacts with it. This aspect of requirements is a significant problem area for many SRSs. |
| Modifiable | The logical, hierarchical structure of the SRS should facilitate any necessary modifications (grouping related issues together and separating them from unrelated issues makes the SRS easier to modify). |
| Ranked | Individual requirements of an SRS are hierarchically arranged according to stability, security, perceived ease/difficulty of implementation, or other parameter that helps in the design of that and subsequent documents. |
| Testable | An SRS must be stated in such a manner that unambiguous assessment criteria (pass/fail or some quantitative measure) can be derived from the SRS itself. |
| Traceable | Each requirement in an SRS must be uniquely identified to a source (use case, government requirement, industry standard, etc.) |
| Unambiguous | SRS must contain requirements statements that can be interpreted in one way only. This is another area that creates significant problems for SRS development because of the use of natural language. |
| Valid | A valid SRS is one in which all parties and project participants can understand, analyze, accept, or approve it. This is one of the main reasons SRSs are written using natural language. |
| Verifiable | A verifiable SRS is consistent from one level of abstraction to another. Most attributes of a specification are subjective and a conclusive assessment of quality requires a technical review by domain experts. Using indicators of strength and weakness provide some evidence that preferred attributes are or are not present. |
What makes an SRS " good? " How do we know when we've written a " quality" specification? The most obvious answer is that a quality specification is one that fully addresses all the customer requirements for a particular product or system. That's part of the answer. While many quality attributes of an SRS are subjective, we do need indicators or measures that provide a sense of how strong or weak the language is in an SRS. A " strong" SRS is one in which the requirements are tightly, unambiguously, and precisely defined in such a way that leaves no other interpretation or meaning to any individual requirement.
The Goddard Space Flight Center (GSFC) studied dozens of NASA requirements specifications that revealed nine categories of SRS quality indicators. The individual components in each category are words, phrases, and sentence structures that are related to quality attributes. The nine categories fall into two classes: those related to individual specification statements, and those related to the total SRS document. Table 5 summarizes the classes, categories, and components of these quality indicators. This table was also originally presented at the April 1998 Software Technology Conference presentation " Doing Requirements Right the First Time." Reprinted with permission from the Software Assurance Technology Center at NASA (https://www.gsfc.nasa.gov/).
Table 5 Quality measures related to individual SRS statements
| Imperatives: Words and phrases that command the presence of some feature, function, or deliverable. They are listed below in decreasing order of strength. | |||
| Shall | Used to dictate the provision of a functional capability. | ||
| Must or must not | Most often used to establish performance requirement or constraints. | ||
| Is required to | Used as an imperative in SRS statements when written in passive voice. | ||
| Are applicable | Used to include, by reference, standards, or other documentation as an addition to the requirement being specified. | ||
| Responsible for | Used as an imperative in SRSs that are written for systems with pre-defined architectures. | ||
| Will | Used to cite things that the operational or development environment is to provide to the capability being specified. For example, The vehicle's exhaust system will power the ABC widget. | ||
| Should | Not used often as an imperative in SRS statements; however, when used, the SRS statement always reads weak. Avoid using Should in your SRSs. | ||
| Continuances: Phrases that follow an imperative and introduce the specification of requirements at a lower level. There is a correlation with the frequency of use of continuances and SRS organization and structure, up to a point. Excessive use of continuances often indicates a very complex, detailed SRS. The continuances below are listed in decreasing order of use within NASA SRSs. Use continuances in your SRSs, but balance the frequency with the appropriate level of detail called for in the SRS. 1. Below: 2. As follows: 3. Following: 4. Listed: 5. In particular: 6. Support: | |||
| Directives: Categories of words and phrases that indicate illustrative information within the SRS. A high ratio of total number of directives to total text line count appears to correlate with how precisely requirements are specified within the SRS. The directives below are listed in decreasing order of occurrence within NASA SRSs. Incorporate the use of directives in your SRSs. 1. Figure 2. Table 3. For example 4. Note | |||
| Options: A category of words that provide latitude in satisfying the SRS statements that contain them. This category of words loosens the SRS, reduces the client's control over the final product, and allows for possible cost and schedule risks. You should avoid using them in your SRS. The options below are listed in the order they are found most often in NASA SRSs. 1. Can 2. May 3. Optionally | |||
| Weak phrases: A category of clauses that can create uncertainty and multiple/subjective interpretation. The total number of weak phrases found in an SRS indicates the relative ambiguity and incompleteness of an SRS. The weak phrases below are listed alphabetically. | |||
| adequate | be able to | easy | provide for |
| as a minimum | be capable of | effective | timely |
| as applicable | but not limited to | if possible | tbd |
| as appropriate | capability of | if practical | |
| at a minimum | capability to | normal | |
| Size: Used to indicate the size of the SRS document, and is the total number of the following: 1. Lines of text 2. Number of imperatives 3. Subjects of SRS statements 4. Paragraphs | |||
| Text Structure: Related to the number of statement identifiers found at each hierarchical level of the SRS and indicate the document's organization, consistency, and level of detail. The most detailed NASA SRSs were nine levels deep. High-level SRSs were rarely more than four levels deep. SRSs deemed well organized and a consistent level of detail had text structures resembling pyramids (few level 1 headings but each lower level having more numbered statements than the level above it). Hour-glass-shaped text structures (many level 1 headings, few a mid-levels, and many at lower levels) usually contain a greater amount of introductory and administrative information. Diamond-shaped text structures (pyramid shape followed by decreasing statement counts at levels below the pyramid) indicated that subjects introduced at higher levels were addressed at various levels of detail. | |||
| Specification Depth: The number of imperatives found at each of the SRS levels of text structure. These numbers include the count of lower level list items that are introduced at a higher level by an imperative and followed by a continuance. The numbers provide some insight into how much of the Requirements document was included in the SRS, and can indicate how concise the SRS is in specifying the requirements. | |||
| Readability Statistics: Measurements of how easily an adult can read and understand the requirements document. Four readability statistics are used (calculated by Microsoft Word). While readability statistics provide a relative quantitative measure, don't sacrifice sufficient technical depth in your SRS for a number. 1. Flesch Reading Ease index 2. Flesch-Kincaid Grade Level index 3. Coleman-Liau Grade Level index 4. Bormuth Grade Level index |