Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Prescriptive Requirements Analysis Jeff Bryson Prescriptive Requirements Analysis Jeff Bryson System Architect Lockheed Martin STS Orlando FL."— Presentation transcript:

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

2 30 September 2008 Jeff Bryson Lockheed Martin STS 2 Prescriptive 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 prescriptive RA processWhat are the values and risks associated to a prescriptive RA process Open ForumOpen 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 30 September 2008 Jeff Bryson Lockheed Martin STS 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 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?If I want to teach you something, or learn something from you, which image do I show?

4 30 September 2008 Jeff Bryson Lockheed Martin STS 4 Statistics Study on over organizations showed:Study on over 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 Kameli – INCOSE presentation 2002 Barker – Rational – System Engineering Effectiveness Barker – Rational – System Engineering Effectiveness Requirements Defects Are Inception Defects

5 30 September 2008 Jeff Bryson Lockheed Martin STS 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. 1.K eep it vague –Y–Y–Y–You can do almost nothing by repeating the customer specification and placing the requirements in DOORS 2.A dmire the problem –Y–Y–Y–You can have analysis paralysis by analyzing the requirements to the nth degree and then describe how complex the problem is 3.Y ou can use a prescriptive analysis process that tell you exactly what you must do and help you identify when you are complete. Admire the problemAdmire the problem I can have analysis paralysis by analyzing the requirements to the n th degree and then describe how complex the problem is

6 30 September 2008 Jeff Bryson Lockheed Martin STS 6 Prescriptive vs. Descriptive Prescription - the enforcement of rules governing how a language is to be usedPrescription - 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.Descriptive – You can select (and/or create) the rules you wish to follow. Need prescriptive process that providesNeed prescriptive process that provides –Clear Metrics –Error Checking

7 30 September 2008 Jeff Bryson Lockheed Martin STS 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 –P–P–P–Produce a description of the problem –I–I–I–Identify who is responsible for solving specific parts of the problem –I–I–I–Identify how you will verify the solution –P–P–P–Provides a means of validating the solution

8 30 September 2008 Jeff Bryson Lockheed Martin STS 8 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 goalsIt 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 30 September 2008 Jeff Bryson Lockheed Martin STS 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 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 30 September 2008 Jeff Bryson Lockheed Martin STS 10 Prescriptive UC Analysis continued 1 to 1 mapping between low level requirement and: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 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 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 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 UC Swim lanes for external actors should have zero functional requirementsSwim lanes for external actors should have zero functional requirements Traceability Map (auto generated)Traceability Map (auto generated)

11 30 September 2008 Jeff Bryson Lockheed Martin STS 11 Prescriptive Requirements Mapping

12 30 September 2008 Jeff Bryson Lockheed Martin STS 12 Bringing it all Together Traceability Matrix

13 30 September 2008 Jeff Bryson Lockheed Martin STS 13 It is acceptable to have errors in the PRA syntax as long as: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.The whole point is to find all errors and correct the ones that can be corrected and track the rest.

14 30 September 2008 Jeff Bryson Lockheed Martin STS 14 How do I know when to stop When every customer functional and performance requirement has been allocated and verifiability has been identifiedWhen 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 requirementsWhen every Activity, Branch, Sync has one and only one low level requirements When every interface has been identified and linked to a functional requirement.When every interface has been identified and linked to a functional requirement. Entity linkage is complete with in the model to allow for error checkingEntity 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 managementAny 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. 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 30 September 2008 Jeff Bryson Lockheed Martin STS 15 Value and Risk Can measure completeness of analysisCan measure completeness of analysis –I 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 after the product is built.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.Lunacy – The act of doing the same thing over and over again, and yet each time expecting different results.


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

Similar presentations


Ads by Google