Put Your Best Foot Forward A Project Managers Guide to QualityRelated Requirements

1
Put Your Best Foot ForwardA Project Managers
Guide to Quality-Related Requirements

• Robert Watkins

2
Two Aspects ofQuality-Related Requirements

• Types of Requirements to Capture
• Operations
• Security
• Performance
• Usability
• Reuse
• Interoperability

• Ensure Each Requirement is
• Clear
• Prioritized
• Correct
• Traceable
• Consistent
• Verifiable

Put Your Best Foot Forward, a Project Managers
Guide to Quality-Related Requirements
3
Types of Requirements to Capture
4
Types of Requirements to Capture

• Operations
• Backup requirements
• Disaster recovery requirements
• System monitoring
• System tasks
• Log file requirements
• Why Important Improve reliability by including
  other IS Staff in testing and defining tests.

5
Types of Requirements to Capture

• Security
• Intrusion detection/handling
• Password standards
• Cookie standards
• Cryptography standards
• User action logging
• Why Important Improve adherence to Security
  standards by including IS-Security staff in
  testing process

6
Types of Requirements to Capture

• Performance
• System response time for certain activities
• Concurrent users supported
• Availability
• Why ImportantImproved confidence that user
  expectations of performance are met.

7
Types of Requirements to Capture

• Usability
• Time needed for users to complete tasks
• Error message standards
• Error-reducing standards
• Ability to track user error rate
• Why Important
• More happy users

8
Types of Requirements to Capture

• Reuse
• Coding standards compliance
• Scalability
• Maintainability
• Why ImportantEnsure Standards are developed

9
Types of Requirements to Capture

• Interoperability
• Standards compliance
• Industry standards
• Reporting formats
• Data naming
• Audit tracing
• Design standards
• Coding standards

• Interface specification adherence
• Flagstar system interfaces
• Vendor system interfaces
• Browser compatibility
• Operating system compatibility

Why ImportantEnsure Standards are Identified
10
Ensure Each Requirement is
11
Ensure Each Requirement is

• Clear
• There should be only one interpretation.

12
Ensure Each Requirement is

• Prioritized
• Each requirement is ranked by importance,
  necessity or acceptability and that each
  requirement is given a unique ranking.
• Good Example1 High - Mission critical to the
  business - financial ramifications with its
  implementation or in the event of failure.
• 2 Medium - Disruption of operation/service.
  Adequate and/or alternate process available or
  limited-capacity back up available.
• 3 Low - Little or no business impact with its
  implementation or in the event of failure
• Bad Example Everything is required. Zero Defects
  are acceptable.
• Why Important You can eliminate some tests if
  needed due to time constraints

13
Ensure Each Requirement is

• Correct
• Complete, based on business or technical need,
  verified by SME.
• Good ExampleProvide a link on the homepage to
  the Flagstar Privacy Policy approved by the SVP
  of Legal Affairs to comply with corporate privacy
  standards.
• Bad ExampleNeed privacy policy.
• Why ImportantThe right people define the
  requirements that are within their domain.

14
Ensure Each Requirement is

• Traceable
• Each requirement has a unique identifier used for
  reference.
• Good ExampleUse a hierarchical numbering system
  for requirements. (e.g. use Caliber or
  TestDirector)
• Why Important You can quickly determine what
  requirements have been tested and how often when
  using TestDirector to match tests to requirements.

15
Ensure Each Requirement is

• Consistent
• There are no conflicts with other requirements or
  constraints.
• Bad ExampleOne requirement may state that A
  must always follow B, while another may require
  that A and B occur simultaneously.
• Why Important Also makes sure new requirements
  are not in conflict with existing system
  requirements.

16
Ensure Each Requirement is

• Verifiable
• There exists a time and cost effective way to
  verify the requirement has been met.
• Good ExampleOutput of the program shall be
  produced within 20 s of event 60 of the time
  and shall be produced within 30 s of event 100
  of the time.
• Bad Exampleworks well, good human interface,
  and shall usually happen.
• Why ImportantThis simplifies establishing
  testing goals and verifying that these goals
  accurately reflect the business needs.

17
Resource

• IEEE 820-1998 - IEEE Recommended Practice for
  Software Requirements Specifications

18
Takeaways

• Establish standards for requirements
• Enforce those standards through peer reviews or
  other means
• Evaluate the effectiveness of your standards by
  tracking defects found during testing as well as
  from the helpdesk.

19
The End

• Questions?