We continue to look forward to sending to and hearing from our SBDi Tips Members. We use these tips as a means to share our knowledge and experience with you. Our ears (eyes for emails) are always open waiting to hear what is of concern to you in the area of Requirements Engineering, Project or Program Management, and Process Improvement. Please continue to send in your inquiries and we hope you continue to find these tips helpful and useful.

Now, let's complete our Anti-Pattern discussion.

Risk refers to anything that could compromise a requirement not being satisfied. Risks can occur throughout the product's and project's life.

Here is a small sample of Project, Product and Business Related Risk.

Project Related:

• Change in staffing.
• Change in budget.
• Change in schedules.

Product Related:

• Security breach.
• Late delivery of hardware, software, network.
• Poor performance (i.e.: network outage).

Business Related:

• Unforeseen competitor advantage.
• Legal infringement.
• Partnership agreement failures.

Risks need to be identified, documented, and WATCHED. A tolerance must be set, like validation criteria, of how to identify when the risk occurs. A countermeasure is then documented as a proposal or procedure on what to do if the risk occurs.

Risks should be written to include the following.

• Identifier
• Name
• Description
• Tolerance Measures
• Impact if Risk Occurs
• Countermeasure to prevent risk from occurring

For requirements specifications, a tool is available to assess the risk (quality) of the requirements set. The objective of this tool is to provide a way for project managers to assess the quality of the requirement specification. Although most of the quality attributes are subjective, this tool looks for key aspects that can be measured and are indicators of the quality of the requirement specification.

The Goddard Space Flight Center's (GSFC) Software Assurance Technology Center (SATC) has developed an automated tool that reviews documents for specific natural language that may indicate a potential defect in a requirement. This product has great promise in coming closer to determining the quality value of a requirement set.

The automated requirements measurement (ARM) software scans the requirement specification for the number of occurrences (defects) in nine categories. Five categories for individual statements are:

1. Imperatives - shall, must/must not, is required to, applicable, responsible for, etc.
2. Continuances - as follows, listed, below, support, etc.
3. Directives - figure, table, for example, etc.
4. Options - can, may, optionality, etc.
5. Weak phrases - timely, effective, if practical, easy, etc.

And in four specification levels:

1. Size - by the previous five categories and lines of text/paragraphs.
2. Specification depth - number of imperatives at each hierarchical level.
3. Readability - reading level - requirements should be written for a 7th or 8th grade reading level.
4. Text structure - number of identifiers at each hierarchical level.

The ARM Quality Indicator/Quality Attribute Correlation illustrates the relationship that underlines the tool. This is important because the next step is to interpret the potential risk the requirement quality has on the Internet product. (http://SATC.GSFC.NASA.GOV/support/PNSQC_OCT96/pnq.html)

The purpose of using a tool like ARM is to minimize risk to your product. Remember, poor-quality requirements increase the risk of failure and decrease your return on investment. The ARM Quality Attribute/Risk Type Correlation breaks risk into the following:

Product Risks: A defect can be implemented into the design product. This includes six sub-categories:
Acceptable risk - The product will not meet user's expectations.
Performance risk - The final product will not perform as requested.
Reliability risk - The product will fail in the operation environment.
Reproducibility risk - The product cannot be duplicated for distribution.
Supportability risk - The product cannot be adequately maintained.
Utility risk - The product will be less useful than requested by the requirement suppliers.

Resource Risk: The product will exceed allocated resources. This includes two sub-categories:
Cost - The product will exceed allocated funding. This includes development and support.
Schedule - The product will not be delivered as scheduled.

The ARM tool is valuable to "unit test" the requirement subset or set. It should be used prior to any walkthroughs. This tool is most valuable in convincing management of the need to spend the time on the requirement effort, which will provide comprehensive risk analysis.

SBDi is available to help educate teams in identifying changes in the requirement set and how to identify its impact and manage them.

Our services include:

• Education of the management and development team on the value of the development, implementation and use of anti-patterns.
• Teaching how to identify, develop, validate, and implement anti-patterns.
• Developing project specific anti-patterns.
• Developing a divisional or corporate process for the development and implementation of anti-patterns.
• Review of existing anti-patterns for quality.

Pat Ferdinandi