ReStart Default Rules No Rules Prior to uploading your file, set your report options. Also check the rules and modify them as desired.       Stop Now

1. select browse - pick spec .txt document 2. select requirement text analysis - press submit - review results 3. go thru each service one at a time 4. select browse - pick non spec .txt document 5. select key requirements analysis service 6. make sure all key reqs in non spec are in spec . . . These template instructions are user defined.

Book Information

Analysis Settings Hide PUI Mask Imperatives Process Only Imperatives

Parse Text Strip HTML Tags Strip Blank Lines Show Processed Upload

Report Areas Hide Analysis Results Accessed Words Accessed Patterns Metrics

Doc Shape Reading Level Comments

Services and Rules

Template Comments Default Template

Requirement Text Analysis Show Search Show Simple Rules Show Complex Rules

. . .

Untestable Multiple Imperatives Options Unsure Unbounded Undefined Compound Req Internal Reference Not Standalone Fragment Directive Incomplete Weak Phrases Weak Words Buzz Words Not a Requirement NO Shall or Must

Find Duplicate Objects
Generic Structure Analysis
Domain Structure Analysis
Generic Capabilities Analysis
Domain Capabilities Analysis
Key Reqs Analysis

Add New Service Name Remove Last Service: Key Reqs Analysis

Analysis Results Hide

Filter case sensitive
Access Object Reject Object Access Risk

Show Comment Details Hide All Comments Hide Checked Items Save Results . File

Removed old doc file: 0 Removed old tmp file: 1 Removed old html file: 1 Processed Entire File

Filter Noise Words

No results to report.

Accessed Patterns Found Hide

No results to report.

Metrics Hide

Save Metrics Appended Metrics File

Total Lines: Blank Lines: Non Blank Lines: Imperatives: Shalls: Wills: IsReq:

Message: These metrics are what allow you to compare different documents and different analysis runs. Consider moving the numbers into a spreadsheet for visualization. Counts of Shalls, Wills, IsReq, and Imperatives are hardcoded into the tool. You have the ability to enter a Norm value, which can be surfaced after multiple analysis sessions.

Item	Risk	Count	Children	% lines	% imperative	% shall	% will	% isreq	% Norm
Buzz Words rta	High
Compound Req rta	Low
Directive rta	Low
Fragment rta	Low
Incomplete rta	High
Internal Reference rta	High
Multiple Imperatives rta	Med
Not Standalone rta	Low
Not a Requirement NO Shall or Must rta	HIGH
Options rta	High
Unbounded rta	Low
Undefined rta	Low
Unsure rta	High
Untestable rta	High
Weak Phrases rta	Med
Weak Words rta	Med

Rules Total 16
Rules Triggered 0
Rules Not Triggered 16
Percent of Rules Triggered 0%

Reading Level Hide

Disabling the noise filter may reduce the reading level. Re-run the report to capture metrics for both instances.

Accessed Unique Words:
Accessed Unique Syllables:
Words with 3+ Syllables:
Polysyllabic Count:
Reading Level: No reading level is available. Select any rule option and check: Count Accessed Words or use a Reading Level Service which has checked: Count Accessed Words.

Document Shape Hide

The number of children at a particular level translate to a document shape. There are diffrent document shapes and each have implications. The document shapes are: random, rectangle, pyramid, inverted pyramid, trapazoid and diamond.

There are no child counts. Try disabling all services except for the service that has checked: Count Accessed Words.

Services and Triggered Rule Comments Hide

Requirement Text Analysis: This looks for word and phrase patterns that typically result in less than optimal reqs. In the past these rules have been encoded in check lists or kept in senior staff heads. Most organizations have different takes on these rules and they tend to change with time. This is a basic service but critical if the project expects to succeed. This should be the starting point of all your analysis.

. . . 1. Buzz Words This is a sign of not knowing the full requirement. This is unexplored context. You must complete your understanding of your reqs and move anything that is open to broad interpretation to your to do list.
. . . . . . Rule Summary Name: Buzz Words Color: NAVY Access Object: fault tolerant|high fidelity|user friendly Reject Object: NotReq

. . . 2. Compound Req Multiple req claims are open to missing or poor tests. Split compound reqs into single stand alone reqs.
. . . . . . Rule Summary Name: Compound Req Color: MAROON Access Object: \band\b|\bor\b Reject Object: NotReq

. . . 3. Directive Reqs that are in a table or figure are not standalone. Some communities believe that tables, figures, examples, notes add understandability to a spec. However, in proof like settings of certification, they lead to missed tests and misinterpretation of contents. They should be moved to design documents.
. . . . . . Rule Summary Name: Directive Color: ORANGE Access Object: \btable\b|\bfigure\b|e\.g\.|i\.e\.|for example|note: Reject Object: NotReq|of contents

. . . 4. Fragment Reqs that are in a list are not standalone. This leads to confusion and untestable results. The only time list reqs are permitted if the list is sequence dependent. This typically occurs when algorithms are described using English rather than formal methods.
. . . . . . Rule Summary Name: Fragment Color: RED Access Object: ^\s*\w+\. Reject Object: NotReq

. . . 5. Incomplete Incomplete specifications vary in severity. This is the worst case of incompleteness. Once the TBDs are gone more sophisticated techniques are needed to address this area. The other SAT services can help in this area along with SRDB parent child reports.
. . . . . . Rule Summary Name: Incomplete Color: RED Access Object: TBD|TBS| TBE|TBC|TBR|\?+| huh |wtf|not defined|not determined|but not limited to|as a minimum Reject Object: NotReq

. . . 6. Internal Reference Round and round we go where we stop no one knows. This leads to confusion and a break down of understanding.
. . . . . . Rule Summary Name: Internal Reference Color: MAROON Access Object: \w \d\.(\d\.)+|paragraph \d|\w section \d Reject Object: NotReq

. . . 7. Multiple Imperatives Sounds like you are trying to maintain 2 sets of req books. This is very destructive. Commit to the req and use the SRDB attributes to track req types.
. . . . . . Rule Summary Name: Multiple Imperatives Color: BLUE Access Object: will |is required to|are applicable|are to|responsible for Reject Object: NotReq

. . . 8. Not Standalone Reqs that start a list are not standalone. This leads to confusion and untestable results. This typically occurs when algorithms are described using English rather than formal methods.
. . . . . . Rule Summary Name: Not Standalone Color: RED Access Object: shall:|below:|as follows:|following:|listed:|in particular:|support:| : Reject Object: NotReq|note:

. . . 9. Not a Requirement NO Shall or Must Missing imperative. Requirements have shall or must.
. . . . . . Rule Summary Name: Not a Requirement NO Shall or Must Color: RED Access Object: \n|\r Reject Object: shall|must

. . . 10. Options This is prone to false alarms. There are different levels of vague. This is one of the worst types of vague, suggesting an option. You must commit to your reqs and move anything that is optional to studies.
. . . . . . Rule Summary Name: Options Color: PURPLE Case Sensitive : CHECKED Access Object: may|might|could|should| can | optionally Reject Object: NotReq

. . . 11. Unbounded This is prone to false alarms. There are different levels of vague. This is one of the worst types of vague, being unbounded. You must commit to your reqs and move anything that is vague to studies.
. . . . . . Rule Summary Name: Unbounded Color: PURPLE Access Object: \ball\b Reject Object: NotReq

. . . 12. Undefined This is prone to false alarms. There are different levels of vague. This is one of the worst types of vague, being undefined. You must commit to your reqs and move anything that is vague to studies.
. . . . . . Rule Summary Name: Undefined Color: PURPLE Access Object: \bany\b Reject Object: NotReq

. . . 13. Unsure This is prone to false alarms. There are different levels of vague. This is one of the worst types of vague, being unsure. You must commit to your reqs and move anything that is vague to studies.
. . . . . . Rule Summary Name: Unsure Color: PURPLE Access Object: possible|possibly|eventually|if possible|if needed Reject Object: NotReq

. . . 14. Untestable This is a neg req and as such is untestable. Re-write as a positive statement.
. . . . . . Rule Summary Name: Untestable Color: RED Access Object: shall not Reject Object: shall|must

. . . 15. Weak Phrases This is prone to false alarms. Weak phrases can be a sign of not knowing the full requirement. This is unexplored context. You must complete your understanding of your reqs and move anything that is weak to your to do list.
. . . . . . Rule Summary Name: Weak Phrases Color: NAVY Access Object: as appropriate|be able to|be capable of|capability of|capability to|as required|provide for|easy to|having in mind|taking into account|as fast as possible Reject Object: NotReq

. . . 16. Weak Words This is prone to false alarms. These words can be a sign of not knowing the full requirement. This is unexplored context. You must complete your understanding of your reqs and move anything that is open to broad interpretation to your to do list.
. . . . . . Rule Summary Name: Weak Words Color: NAVY Access Object: normal|effective|timely|similar|flexible|adaptable|rapid|fast|adequate|support|maximize|minimize|etc|clear | easy | useful | adequate | good | bad Reject Object: NotReq