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

Prescriptive Requirements Prescriptive Requirements AnalysisAnalysis

Jeff BrysonJeff BrysonSystem Architect

Lockheed Martin STSOrlando FL

30 September 200830 September 2008 Jeff Bryson Lockheed Martin STSJeff Bryson Lockheed Martin STS 22

Prescriptive Requirements AnalysisPrescriptive Requirements Analysis

• Why do we need to improve our RA processWhy do we need to improve our RA process• What is meant by a prescriptive processWhat is meant by a prescriptive process• One example of a prescriptive RA processOne example of a prescriptive RA process• What are the values and risks associated to a What are the values and risks associated to a

prescriptive RA processprescriptive RA process• Open ForumOpen Forum

– How do you identify if your RA is complete?How do you identify if your RA is complete?– How do you measure the value of your RA?How do you measure the value of your RA?– How do you convince management of the value of How do you convince management of the value of

RA?RA?


But first a brief commercialBut first a brief commercial• If I want to sell you my skills as a photographer, which If I want to sell you my skills as a photographer, which

image do I show you?image do I show you?• If I want to teach you something, or learn something from If I want to teach you something, or learn something from

you, which image do I show?you, which image do I show?


StatisticsStatistics

• Study on over 14000 organizations showed:Study on over 14000 organizations showed:– 80-90% of the systems did not meet their goals80-90% of the systems did not meet their goals– Around 40% of the developments failed or were Around 40% of the developments failed or were

abandonedabandoned– Less than 25% fully integrated business and Less than 25% fully integrated business and

technology objectivestechnology objectives– Only 10-20% met their success criteriaOnly 10-20% met their success criteria

Critical System Thinking and Critical System Thinking and Information Systems Development, 1997Information Systems Development, 1997

Kameli – INCOSE presentation 2002Kameli – INCOSE presentation 2002

Barker – Rational – System Engineering EffectivenessBarker – Rational – System Engineering Effectiveness

Requirements Defects Are Inception DefectsRequirements Defects Are Inception Defects


System Engineering and System Engineering and Requirements AnalysisRequirements Analysis

• Requirements analysis (not management) is Requirements analysis (not management) is the single best way to identify technical the single best way to identify technical program risks and problems in the early program risks and problems in the early stages of a project.stages of a project.

• Requirements analysis occurs through the Requirements analysis occurs through the full life cycle of the project.full life cycle of the project.

• In 25 years of project development I’ve see In 25 years of project development I’ve see two RA processes used. I’m suggesting a two RA processes used. I’m suggesting a third approach.third approach.

1.1. Keep it vagueKeep it vague– You can do almost nothing by repeating the You can do almost nothing by repeating the

customer specification and placing the requirements customer specification and placing the requirements in DOORSin DOORS

2.2. Admire the problemAdmire the problem– You can have analysis paralysis by analyzing the You can have analysis paralysis by analyzing the

requirements to the nrequirements to the nthth degree and then describe degree and then describe how complex the problem ishow complex the problem is

3.3. You can use a prescriptive analysis process You can use a prescriptive analysis process that tell you exactly what you must do and that tell you exactly what you must do and help you identify when you are complete.help you identify when you are complete.

•Admire the problemAdmire the problem

I can have analysis paralysis by analyzing the requirements to the nth degree and then describe how complex the problem is


Prescriptive vs. DescriptivePrescriptive vs. Descriptive• PrescriptionPrescription - the enforcement of rules - the enforcement of rules

governing how a language is to be usedgoverning how a language is to be used

• DescriptiveDescriptive – You can select (and/or – You can select (and/or create) the rules you wish to follow.create) the rules you wish to follow.

• Need prescriptive process that providesNeed prescriptive process that provides– Clear MetricsClear Metrics– Error CheckingError Checking


Use Case AnalysisUse Case Analysis• Use Case analysis is requirements analysis.Use Case analysis is requirements analysis.• Use Case analysis is iterativeUse Case analysis is iterative• It should have specific (measureable) goalsIt should have specific (measureable) goals• Admiring the problem should be avoidedAdmiring the problem should be avoided• Describing the problem should be avoidedDescribing the problem should be avoided• Achieving the goals of UC analysis willAchieving the goals of UC analysis will

– Produce a description of the problemProduce a description of the problem– Identify who is responsible for solving specific parts of the Identify who is responsible for solving specific parts of the

problemproblem– Identify how you will verify the solutionIdentify how you will verify the solution– Provides a means of validating the solutionProvides a means of validating the solution


Requirements Analysis GoalsRequirements Analysis Goals1.1. Identify all Functional, Performance, Interface Identify all Functional, Performance, Interface

and Architectural requirementsand Architectural requirements2.2. Allocate performance, functional, interface, Allocate performance, functional, interface,

and architectural requirements to responsible and architectural requirements to responsible stakeholder.stakeholder.

3.3. Identify testability of each requirement.Identify testability of each requirement.4.4. Provide justification for allocation and Provide justification for allocation and

verification (VALIDATION)verification (VALIDATION)• It should It should NOTNOT be the goal of RA to describe the be the goal of RA to describe the

problem or solution. Describing the problem and problem or solution. Describing the problem and justifying solution should be the outcome of achieving justifying solution should be the outcome of achieving the RA goalsthe RA goals


Prescriptive Use Case Analysis ExamplePrescriptive 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/ATMExample/

Customer ATM Bank

Insert Card

Provide PIN

Request PIN

Request Customer Validation

Provide Customer Validation

Display Menu

Request Selection

Request Balance Inquire Request Account Balance

Provide Account BalancePrint Balance

Top Package::Customer

Top Package::Bank

ATM System

Balance Inquire

Withdrawal

Deposit

Transfer

Start

Stop

Service

Top Package::ATM Operator

ATMCustomer Actor Bank

Monitor for new cardInsert Card

Request Pin

Read Card

Enter Pin

Validate Customer Info

Validate Customer Req

Display Menu Error Count

Display Error

Retain CardDisplay Error

Select Account Inquire

Request Account Balance

Provide Account Balance

Pint Account Balance



Request Pin

Read Card

Enter Pin




Display Error






Happy Path



Request Pin

Read Card

Enter Pin




Display Error






Happy Path

PIN Entry Error

PIN Entry 3rd Failure

Loop

Customer Object2 Object3

Insert Card

Provide PIN

Request PIN



Display Error


Monitor for new card

Request Pin

Read Card

Enter Pin




Display Error






Happy Path

PIN Entry Error




Request Pin

Read Card

Enter Pin




Display Error






Happy Path

PIN Entry Error



Monitor for new cardInsert Car

Request Pin

Read Card

Enter Pin




Display Error






Happy Path

PIN Entry Error



Insert Car

Request Pin

Read Card

Enter Pin




Display Error






Happy Path

PIN Entry Error



Monitor for new cardInsert Car

Request Pin

Enter Pin




Display Error






Happy Path

PIN Entry Error


Loop


Insert Card

Provide PIN

Request PIN



Display Error

Loop


Insert Card

Provide PIN

Request PIN



Display Error

1.1. Customer inserts bank cardCustomer inserts bank card2.2. ATM application monitors for new cardATM application monitors for new card3.3. ATM application reads customer cardATM application reads customer card4.4. ATM application prompts customer for PINATM application prompts customer for PIN5.5. Customer enters PINCustomer enters PIN6.6. ATM application sends card information and PIN to ATM application sends card information and PIN to

bank for verificationbank for verification7.7. Bank verifies informationBank verifies information8.8. ATM received verificationATM received verification9.9. ATM display menu of operations to customerATM display menu of operations to customer10.10. Customer selects account balance from menuCustomer selects account balance from menu11.11. ATM system request account balance from BANKATM system request account balance from BANK12.12. BANK provide account balanceBANK provide account balance13.13. ATM prints balanceATM prints balance14.14. ATM system returns to step 9ATM system returns to step 9

http://www.math-cs.gordon.edu/courses/cs211/ATMExample/


Prescriptive UC Analysis continuedPrescriptive UC Analysis continued• 1 to 1 mapping between low level requirement 1 to 1 mapping between low level requirement

and:and:– ActivityActivity– DecisionDecision– ForkFork– SynchronizationSynchronization

• If a requirement is mapped to more than one activity (or use case) this is an errorIf 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 then that requirement should be derived into the specific parts that are satisfied (and

tested) in each swim lane (stakeholder where the activities exist)tested) in each swim lane (stakeholder where the activities exist)• If an activity has more than one requirements then this is an errorIf 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 Either there should be additional activities, the current activity should become a new UC, or the requirements are redundant.UC, or the requirements are redundant.

• A Use Case may contain another Use CaseA Use Case may contain another Use Case– It is acceptable (and expected) for one UC to invoke another UCIt is acceptable (and expected) for one UC to invoke another UC

• Swim lanes for external actors should have zero Swim lanes for external actors should have zero functional requirementsfunctional requirements

• Traceability Map Traceability Map (auto generated)(auto generated)


Prescriptive Requirements MappingPrescriptive Requirements MappingCR 0003A customer shall be able to make a balance inquire of an account linked to the card

CR 0005The ATM system shall communicate each transaction to the bank and obtain verification that the transaction request is allowed

CR 0007If the bank determines that the customer’s PIN is invalid, the customer shall be required to re-enter the PIN for a transaction can proceed.

CR 0008If the customer is unable to successfully enter the PIN after three tries, the card

shall be permanently retained by the machine

SP 0001The ATM system shall monitor the card reader for the insertion of a new card

SP 0002When the ATM system detects the insertion of a new card the ATM shall read the information stored and the card and prompt the user to enter their PIN

SP 0003When the ATM system receives the customer PIN value it shall request verification account access from the BANK

SP 0004When the ATM system receives account verification information from the BANK it shall display a list of account operations available

SP 0005The ATM system shall provide an account operation to provide the customer account balance

SP 0006When the ATM system receives an account balance from the BANK after make a balance request it shall provide a print of the account balance.

SP 0008At the completion of any customer account operation (except exit) the ATM system shall display the display a list of account operations available

SP 0007When the ATM system receives a request to view a customer account balance the ATM system shall request the account balance from the BANK



Request Pin

Read Car

Enter Pin




Display Error






Happy Path

PIN Entry Error


CR 0003A customer shall be able to make a balance inquire of an account linked to the card

























Insert Card

Request Pin

Read Car

Enter Pin




Display Error






Happy Path

PIN Entry Error




Request Pin

Enter Pin




Display Error






Happy Path

PIN Entry Error




Request Pin

Read Car

Enter Pin



Display Error






Happy Path

PIN Entry Error















Bringing it all Together Bringing it all Together Traceability MatrixTraceability Matrix


Prescriptive ErrorsPrescriptive Errors

• It is acceptable to have errors in the It is acceptable to have errors in the PRA syntax as long as:PRA syntax as long as:– The errors are detectableThe errors are detectable– The errors are identified as risksThe errors are identified as risks– Management has deemed the risks acceptableManagement has deemed the risks acceptable

• The whole point is to find all errors and The whole point is to find all errors and correct the ones that can be corrected correct the ones that can be corrected and track the rest.and track the rest.


How do I know when to stopHow do I know when to stop• When every customer functional When every customer functional

and performance requirement has and performance requirement has been allocated and verifiability has been allocated and verifiability has been identifiedbeen identified

• When every Activity, Branch, Sync When every Activity, Branch, Sync has one and only one low level has one and only one low level requirementsrequirements

• When every interface has been When every interface has been identified and linked to a functional identified and linked to a functional requirement.requirement.

• Entity linkage is complete with in the Entity linkage is complete with in the model to allow for error checkingmodel to allow for error checking

• Any failures to meet the above are Any failures to meet the above are identified as program risks and have identified as program risks and have been deemed acceptable by been deemed acceptable by customer and program managementcustomer and program management

This means you only stop This means you only stop developing UC’s and start developing UC’s and start maintaining them.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 UC’s, System Requirements Specification, and Stakeholders

– Subsystem (IPT, CSCI, HWCI, Arch) Requirements Specification for each stakeholder

– Operational Concept detailed behavior description


Value and RiskValue and Risk• Can measure completeness of analysisCan measure completeness of analysis

– I can identify when I am completeI can identify when I am complete

• Can identify specific areas at riskCan identify specific areas at risk• Provides clear direction to each stakeholderProvides clear direction to each stakeholder• Provides a more quantitative way of V&VProvides a more quantitative way of V&V• Cost more at the beginning of a project ????Cost more at the beginning of a project ????• Focuses on identifying problem areasFocuses on identifying problem areas• Control requirements creepControl requirements creep

• Should never be used when the RA work is executed Should never be used when the RA work is executed after the product is built.after the product is built.

• ““Lunacy – The act of doing the same thing over and over again, Lunacy – The act of doing the same thing over and over again, and yet each time expecting different results.” and yet each time expecting different results.”

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

Documents

prescriptive analysis

requirements analysis

prescriptive ra processwhat

analysis paralysis

functional requirements

architectural requirements

prescriptive processwhat

goal of ra