If this is a template Press Submit first

Specification Analysis Tool

ReStart Default Rules No Rules

Prior to uploading your file, set your report options.
Also check the rules and modify them as desired.

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.

New File: eusec2006.txt Previously Uploaded File: eusec2006.txt

Analysis Settings Hide

Services and Rules

Template Comments Default Template

Requirement Text Analysis rta 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

Find Duplicate Objects rptdup
Generic Structure Analysis gsa
Domain Structure Analysis dsa
Generic Capabilities Analysis gca
Domain Capabilities Analysis dca
Key Reqs Analysis kra

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: 0 Removed old html file: 0 You have uploaded a .txt file. There should be one complete sentense per line in the text file. If your sentences have multiple forced line breaks select, the parse text option and upload the file again. Alternatively clean up your text file using an editor by removing spaces and extra line breaks.


Parsed the text in uploaded FILE into complete thoughts using the period punctuation. Stripped extra spaces and line feeds.

1. SAT-3 This system will enable control of all electric appliances in the average home; for example, kitchen appliances (ovens, microwave cookers, and refrigerators), air conditioners, central heating, clocks, entertainment devices (TV, radio and DVD players/recorders), and alarm systems.
. . . Multiple Imperatives Requirement Text Analysis Risk: Med Item: will Instance: 1

. . . Unbounded Requirement Text Analysis Risk: Low Item: all Instance: 1

. . . Compound Req Requirement Text Analysis Risk: Low Item: and Instance: 3

. . . Directive Requirement Text Analysis Risk: Low Item: for example Instance: 1

2. SAT-4 The project includes the development of software intended to run on the home computer, and hardware (using micro-controllers) and software appropriate to the different appliances.
. . . Compound Req Requirement Text Analysis Risk: Low Item: and Instance: 2

3. SAT-5 The system will be supplied in three versions, controlling 25, 50 or 100 physical appliances.
. . . Multiple Imperatives Requirement Text Analysis Risk: Med Item: will Instance: 1

. . . Compound Req Requirement Text Analysis Risk: Low Item: or Instance: 1

4. SAT-7 The basic CCC system will have the following working modes as a minimum: * Fully computerised control – appliance control from the computer only, no manual control permitted.
. . . Multiple Imperatives Requirement Text Analysis Risk: Med Item: will Instance: 1

. . . Incomplete Requirement Text Analysis Risk: High Item: as a minimum Instance: 1

5. SAT-8 * Full dual control – computerised or manual controls independently enabled.
. . . Compound Req Requirement Text Analysis Risk: Low Item: or Instance: 1

6. SAT-9 * Half dual control – computerised control of certain appliances will be terminated if the appliance is used manually.
. . . Multiple Imperatives Requirement Text Analysis Risk: Med Item: will Instance: 1

7. SAT-10 * Full manual control – appliance is controlled manually; the computer will only display the working mode of each appliance.
. . . Multiple Imperatives Requirement Text Analysis Risk: Med Item: will Instance: 1

8. SAT-11 Manual control is performed using the manufacturer-supplied controls or remote controls for a given appliance.
. . . Compound Req Requirement Text Analysis Risk: Low Item: or Instance: 1

9. SAT-13 In all functional modes, the CCC system will monitor the appliances and make available, information on the working mode of each appliance.
. . . Multiple Imperatives Requirement Text Analysis Risk: Med Item: will Instance: 1

. . . Unbounded Requirement Text Analysis Risk: Low Item: all Instance: 1

. . . Compound Req Requirement Text Analysis Risk: Low Item: and Instance: 1

10. SAT-14 In addition, the system will be capable of applying a self-diagnostic test of the computer, micro-controllers, appliance electrical supply and other critical devices.
. . . Multiple Imperatives Requirement Text Analysis Risk: Med Item: will Instance: 1

. . . Compound Req Requirement Text Analysis Risk: Low Item: and Instance: 1

. . . Weak Phrases Requirement Text Analysis Risk: Med Item: be capable of Instance: 1

11. SAT-15 The appliance activity will be able to be pre-programmed at least one year in advance.
. . . Multiple Imperatives Requirement Text Analysis Risk: Med Item: will Instance: 1

. . . Weak Phrases Requirement Text Analysis Risk: Med Item: be able to Instance: 1

12. SAT-16 The system must be simple and include an easy to learn human-machine interface.
. . . Compound Req Requirement Text Analysis Risk: Low Item: and Instance: 1

. . . Weak Phrases Requirement Text Analysis Risk: Med Item: easy to Instance: 1

13. SAT-18 The CCC system should be modular, so its control may be expanded to a larger number of appliances (i.e.
. . . Options Requirement Text Analysis Risk: High Item: should Instance: 2

. . . Directive Requirement Text Analysis Risk: Low Item: i.e. Instance: 1

14. SAT-19 those who purchase a 25 or 50 appliance version, should be able to upgrade).
. . . Options Requirement Text Analysis Risk: High Item: should Instance: 1

. . . Compound Req Requirement Text Analysis Risk: Low Item: or Instance: 1

. . . Weak Phrases Requirement Text Analysis Risk: Med Item: be able to Instance: 1

15. SAT-20 The system will also allow the installation of additional appliances, not initially connected, but limited by the maximum supported by the software.
. . . Multiple Imperatives Requirement Text Analysis Risk: Med Item: will Instance: 1

. . . Weak Words Requirement Text Analysis Risk: Med Item: support Instance: 1

16. SAT-22 The pilot version, developed by Cosy Widgets, controls the operation of air conditioning and an alarm only.
. . . Compound Req Requirement Text Analysis Risk: Low Item: and Instance: 1

Processed Entire File


Accessed Words Hide

Filter Noise Words

Accessed Patterns Found Hide


Metrics Hide

Save Metrics with analysis run eusec2006.txt 02/23/07 10:52:13 Appended Metrics File

Total Lines: 23
Blank Lines:
Non Blank Lines: 23
Imperatives: 1
Shalls:
Wills: 9
IsReq:

Message: This document is 4% imperatives suggesting you do not have a specification. Is this an analysis document? If you are trying to find requirements in this document try the Key Requirements Service. There is an online audio power point segment on this topic. Take a few minutes to view the slides. Specs (PPT)

Item Risk Count Children % lines % imperative % shall % will % isreq % Norm
Buzz Words rta

High

Compound Req rta

Low

10

43.47

Directive rta

Low

2

8.69

22.22

Fragment rta

Low

Incomplete rta

High

1

4.34

100

11.11

Internal Reference rta

High

Multiple Imperatives rta

Med

9

39.13

100

Not Standalone rta

Low

Options rta

High

2

8.69

22.22

Unbounded rta

Low

2

8.69

22.22

Undefined rta

Low

Unsure rta

High

Untestable rta

High

Weak Phrases rta

Med

4

17.39

44.44

Weak Words rta

Med

1

4.34

100

11.11

z Mined Objects

16

69.56

Rules Total 16
Rules Triggered 9
Rules Not Triggered 7
Percent of Rules Triggered 56%

Reading Level Hide

Document Shape Hide

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. 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

. . . 10. 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

. . . 11. 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

. . . 12. 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

. . . 13. 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: NotReq

. . . 14. 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

. . . 15. 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

original processing URL http://localhost:4444/~sat/satpro.cgi v 0.4.5 p

10:52:13 Start Time
10:52:15 End Time
2 Seconds

5.008006 4150613 C:/WINDOWS