Prescriptive Requirements Analysis Jeff Bryson System Architect Lockheed Martin STS Orlando FL

1
Prescriptive Requirements AnalysisJeff
BrysonSystem ArchitectLockheed Martin
STSOrlando FL
2
Prescriptive Requirements Analysis

• Why do we need to improve our RA process
• What is meant by a prescriptive process
• One example of a prescriptive RA process
• What are the values and risks associated to a
  prescriptive RA process
• Open Forum
• How do you identify if your RA is complete?
• How do you measure the value of your RA?
• How do you convince management of the value of
  RA?

3
But first a brief commercial

• If I want to sell you my skills as a
  photographer, which image do I show you?
• If I want to teach you something, or learn
  something from you, which image do I show?

4
Statistics

• Study on over 14000 organizations showed
• 80-90 of the systems did not meet their goals
• Around 40 of the developments failed or were
  abandoned
• Less than 25 fully integrated business and
  technology objectives
• Only 10-20 met their success criteria
• Critical System Thinking and
• Information Systems Development, 1997
• Kameli INCOSE presentation 2002

Requirements Defects Are Inception Defects

• Barker Rational System Engineering
  Effectiveness

5
System Engineering and Requirements Analysis

• Requirements analysis (not management) is the
  single best way to identify technical program
  risks and problems in the early stages of a
  project.
• Requirements analysis occurs through the full
  life cycle of the project.
• In 25 years of project development Ive see two
  RA processes used. Im suggesting a third
  approach.
• Keep it vague
• You can do almost nothing by repeating the
  customer specification and placing the
  requirements in DOORS
• Admire the problem
• You can have analysis paralysis by analyzing the
  requirements to the nth degree and then describe
  how complex the problem is
• You can use a prescriptive analysis process that
  tell you exactly what you must do and help you
  identify when you are complete.

6
Prescriptive vs. Descriptive

• Prescription - the enforcement of rules governing
  how a language is to be used
• Descriptive You can select (and/or create) the
  rules you wish to follow.
• Need prescriptive process that provides
• Clear Metrics
• Error Checking

7
Use Case Analysis

• Use Case analysis is requirements analysis.
• Use Case analysis is iterative
• It should have specific (measureable) goals
• Admiring the problem should be avoided
• Describing the problem should be avoided
• Achieving the goals of UC analysis will
• Produce a description of the problem
• Identify who is responsible for solving specific
  parts of the problem
• Identify how you will verify the solution
• Provides a means of validating the solution

8
Requirements Analysis Goals

• Identify all Functional, Performance, Interface
  and Architectural requirements
• Allocate performance, functional, interface, and
  architectural requirements to responsible
  stakeholder.
• Identify testability of each requirement.
• Provide justification for allocation and
  verification (VALIDATION)
• It should NOT be the goal of RA to describe the
  problem or solution. Describing the problem and
  justifying solution should be the outcome of
  achieving the RA goals

9
Prescriptive Use Case Analysis Example

• One activity diagram per UC
• Each Path Identified (1 Happy Path)
• A sequence diagram for each path (scenario) in
  the AD
• A textual description for the Happy Path and each
  scenario (auto generated)
• Each control/transition that crosses a swim lane
  in the AD should correspond to an interface in
  the SD
• Each interface is associated to a functional
  requirements
• Each Interface requirement is tied to the
  requirement of the action that it triggers.
• It is also linked to the requirement of the
  action that initiates the interface
• Interfaces are requirements and the more complex
  the system the more critical detailed interface
  requirements are.
• These are more then just drawings
• Understanding the relationships between all these
  graphical object is key to having a prescriptive
  process. The graphical diagrams become a
  syntactical language
• http//www.math-cs.gordon.edu/courses/cs211/ATMExa
  mple/

1. Customer inserts bank card
2. ATM application monitors for new card
3. ATM application reads customer card
4. ATM application prompts customer for PIN
5. Customer enters PIN
6. ATM application sends card information and PIN to
   bank for verification
7. Bank verifies information
8. ATM received verification
9. ATM display menu of operations to customer
10. Customer selects account balance from menu
11. ATM system request account balance from BANK
12. BANK provide account balance
13. ATM prints balance
14. ATM system returns to step 9

10
Prescriptive UC Analysis continued

• 1 to 1 mapping between low level requirement and
• Activity
• Decision
• Fork
• Synchronization
• If a requirement is mapped to more than one
  activity (or use case) this is an error
• then that requirement should be derived into the
  specific parts that are satisfied (and tested) in
  each swim lane (stakeholder where the activities
  exist)
• If an activity has more than one requirements
  then this is an error
• Either there should be additional activities, the
  current activity should become a new UC, or the
  requirements are redundant.
• A Use Case may contain another Use Case
• It is acceptable (and expected) for one UC to
  invoke another UC
• Swim lanes for external actors should have zero
  functional requirements
• Traceability Map (auto generated)

11
Prescriptive Requirements Mapping
12
Bringing it all Together Traceability Matrix
13
Prescriptive Errors

• It is acceptable to have errors in the PRA syntax
  as long as
• The errors are detectable
• The errors are identified as risks
• Management has deemed the risks acceptable
• The whole point is to find all errors and correct
  the ones that can be corrected and track the rest.

14
How do I know when to stop

• When every customer functional and performance
  requirement has been allocated and verifiability
  has been identified
• When every Activity, Branch, Sync has one and
  only one low level requirements
• When every interface has been identified and
  linked to a functional requirement.
• Entity linkage is complete with in the model to
  allow for error checking
• Any failures to meet the above are identified as
  program risks and have been deemed acceptable by
  customer and program management
• This means you only stop developing UCs and
  start maintaining them.

• When I can create the following documents from
  the UC analysis
• System Requirements Specification (mapped to
  customer requirements and stakeholders)
• System ICD (mapped to System Requirements
  Specification and Stakeholders)
• System Test Procedure (Draft) Mapped to UCs,
  System Requirements Specification, and
  Stakeholders
• Subsystem (IPT, CSCI, HWCI, Arch) Requirements
  Specification for each stakeholder
• Operational Concept detailed behavior description

15
Value and Risk

• Can measure completeness of analysis
• I can identify when I am complete
• Can identify specific areas at risk
• Provides clear direction to each stakeholder
• Provides a more quantitative way of VV
• Cost more at the beginning of a project ????
• Focuses on identifying problem areas
• Control requirements creep
• Should never be used when the RA work is executed
  after the product is built.
• Lunacy The act of doing the same thing over
  and over again, and yet each time expecting
  different results.