Sie sind auf Seite 1von 15

Prescriptive Requirements Analysis

Jeff Bryson
System Architect Lockheed Martin STS Orlando FL

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?

30 September 2008

Jeff Bryson Lockheed Martin STS

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?

30 September 2008

Jeff Bryson Lockheed Martin STS

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 Requirements Defects Are Inception Defects technology objectives Only 10-20% met their success criteria
Critical System Thinking and Information Systems Development, 1997

Kameli INCOSE presentation 2002

Barker Rational System Engineering Effectiveness


30 September 2008 Jeff Bryson Lockheed Martin STS

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. 1. Keep it vague
You can do almost nothing by repeating the customer specification and placing the requirements in DOORS

2. Admire the problem

3.

You can have analysis paralysis by analyzing the the problem Admire requirements to the nth degree and then describe how complex the problem is I can have analysis paralysis by analyzing You can use a prescriptive analysis process the requirements to the nth degree and then that tell you exactly what you mustdescribe how complex the problem is do and

help you identify when you are complete.


30 September 2008

Jeff Bryson Lockheed Martin STS

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

30 September 2008

Jeff Bryson Lockheed Martin STS

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

30 September 2008

Jeff Bryson Lockheed Martin STS

Requirements Analysis Goals


1. Identify all Functional, Performance, Interface and Architectural requirements 2. Allocate performance, functional, interface, and architectural requirements to responsible stakeholder. 3. Identify testability of each requirement. 4. 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
Jeff Bryson Lockheed Martin STS

30 September 2008

Prescriptive Use Case Analysis Example



1. 2. 3. 4. 5. 6.

Customer

ATM applicationrequirement is tied to the requirement of Each Interface sends card information and PIN to Withdrawal the for verification bank action that it triggers. Bank also linked to the requirement of the action that It is verifies information 7. Deposit Customer initiates the interface Object2 Object3 8. ATM received verification Top Package::Customer ATM display menu of operationsthe customer Interfaces are requirements and to more complex the Insert Card 9. system the more critical detailed interface requirements 10. Customer selects account balance from menu Transfer are. 11. ATM system request account balance from BANK Loop Request PIN These are more then just drawings 12. BANK provide account balance Validation Request Customer Provide PIN Understanding the relationships between all these 13. ATM prints object is key to havingValidation balance Provide Customer a prescriptive process. graphical 14. ATM system returns to step 9 a syntactical language The graphical diagrams become
Display Error

One activity diagram per UC Each Path Identified (1 Happy Path) ATM System 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 laneinserts bank card Customer in the AD should correspond to an ATM application monitors for new card interface in the SD ATM application reads customer card Each interface prompts customer for PIN ATM application is associated to a functional enters PIN Customer requirements
Stop

Customer Actor

ATM

Bank

Insert Card Insert Car

Monitor for new card

ATM

Bank

Read Card

Insert Card

Service

Request PIN Top Package::ATM Operator Request Customer Validation Provide PIN Provide Customer Validation

Request Pin

Start

Enter Pin

Display Error

Display Menu

Validate Customer Info Validate Customer Req

Request Selection

Balance Inquire

Request Balance Inquire Print Balance

Request Account Balance Provide Account Balance

Happy Path Happy Path

Top Package::Bank

PIN Entry Error

PIN Entry 3rd Failure Display Menu Error Count

Select Account Inquire

Retain Card Display Error

Request Account Balance Provide Account Balance

Pint Account Balance

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

30 September 2008

Jeff Bryson Lockheed Martin STS

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)
30 September 2008 Jeff Bryson Lockheed Martin STS

10

Prescriptive Requirements Mapping


CR 0003 A customer shall be able to make a balance inquire of an account linked to the card CR 0005 The ATM system shall communicate each transaction to the bank and obtain verification that the transaction request is allowed CR 0007 If the bank determines that the customers PIN is invalid, the customer shall be required to re-enter the PIN for a transaction can proceed. CR 0008 If the customer is unable to successfully enter the PIN after three tries, the card shall be permanently retained by the machine

Customer Actor

ATM

Bank

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

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

Insert Card

Monitor for new card

Read Car

SP 0002 When 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 0004 When the ATM system receives account verification information from the BANK it shall display a list of account operations available SP 0005 The ATM system shall provide an account operation to provide the customer account balance

Request Pin

Enter Pin

Display Error

Validate Customer Info Validate Customer Req Happy Path

SP 0006 When 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 0007 When the ATM system receives a request to view a customer account balance the ATM system shall request the account balance from the BANK SP 0008 At the completion of any customer account operation (except exit) the ATM system shall display the display a list of account operations available

PIN Entry Error

PIN Entry 3rd Failure Display Menu Error Count

Select Account Inquire

Retain Card Display Error

Request Account Balance Provide Account Balance

Pint Account Balance

30 September 2008

Jeff Bryson Lockheed Martin STS

11

Bringing it all Together Traceability Matrix

30 September 2008

Jeff Bryson Lockheed Martin STS

12

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.
30 September 2008 Jeff Bryson Lockheed Martin STS

13

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.
30 September 2008

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

Jeff Bryson Lockheed Martin STS

14

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 V&V 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.

30 September 2008

Jeff Bryson Lockheed Martin STS

15

Das könnte Ihnen auch gefallen