Requirement Patterns in Systems Analysis

Requirement Patterns

• A requirement pattern is a template to write a specific type of requirement, such as performance, backup and recovery, report, or query.
• The goal of requirement patterns is to enable the analyst to write higher quality requirements faster and with less effort.
• Benefits of requirement patterns:
  • Provide guidance
  • Save time
  • Consistency
  • Easier to compare with others of the same type
  • Identify missing information
  • Easier to write
  • Readers can refer to the written pattern for more information
  • Referring to a list of patterns when writing the requirements specification

Templates

• A template is a fill-in-the-blanks definition for a requirement, deemed typical of its type.
• The aim of a template is to allow copying into a requirement description as a starting point.

Examples

• The main role of a requirement's example is to demonstrate the use of patterns in practice.
• Examples need not be consistent with one another, and there are no examples of what not to do.
• Examples are intended to be realistic.

Requirement Domains

• Requirement domains are used to organize requirement patterns.
• Each domain has a theme, which all its patterns share.
• Domains can be broad or narrow, from nearly all systems to just a couple of systems in a single company.
• Each domain needs an introduction for explanation and a description of any infrastructure its patterns depend on.

Domain Examples

• Infrastructure: underlying capabilities needed to support one or more types of requirements
• Fundamental: for things that any kind of system might need
• Information: for several aspects of storage and manipulation of information (data)
• Data entity: on how to treat specific kinds of data
• User function: for a couple of common types of functions, plus accessibility

Requirement Pattern Groups

• A requirement pattern group is created when several requirement patterns have features in common.
• The definition of a group can contain sections such as extra requirements, considerations for development, and considerations for testing.

Requirement Validation

• 1st Definition: checking requirements specification for omissions, conflicts, and ambiguities, and ensuring they follow quality standards.
• 2nd Definition: ensuring the software being developed will satisfy its stakeholders.
• 3rd Definition: checking that the right product is being built.
• Validation involves fully understanding customer intent.
• Verification involves satisfying the customer intent.

Requirement Validation Techniques

• Simple checks: traceability, well-written requirements
• Prototyping
• Functional test design
• User manual development
• Reviews and inspections:
  • Walkthroughs
  • Formal inspections
  • Checklists
• Model-based (formal) validation

IEEE 830-1998 Standard

• Completeness: systematically run through all cases
• Consistency: relate all to one system model
• Unambiguity: check phrasing
• Correctness: validation
• Structuredness: examine structure
• Traceability: are requirements sufficiently linked?
• Agreed upon: check with stakeholders

Requirement Management

• 1st Definition: concerned with all processes involved in changing software system requirements.
• 2nd Definition: a process that supports other RE activities and is carried out in parallel with them.

Requirements Risk Management

• Proactive analysis, identification, monitoring, and mitigation of factors that threaten the integrity of the requirements engineering process.
• Requirements risk factors can be divided into technical and requirements management risk factors.

Importance of Requirements Traceability

• Traceability gives essential assistance in understanding relationships within and across software requirements, design, and implementation.
• Benefits of requirement traceability:
  • Prevents losing knowledge
  • Supports the verification process
  • Impact analysis
  • Change control
  • Process monitoring
  • Improved software quality
  • Reengineering
  • Reuse
  • Risk reduction

Backward and Forward Traceability

• Backward traceability: to previous stages of development, depends upon each element explicitly referencing its source in earlier documents.
• Forward traceability: to all documents spawned by a document, depends upon each element in the document having a unique name or reference number.

Requirement Identification Techniques

• Dynamic renumbering: allows for automatic renumbering of paragraphs and the inclusion of cross references.
• Database record identification: assigning a database record id to each requirement.
• Symbolic identification: giving symbolic names to requirements.