Prescriptive Requirements Analysis VIEW ME

8/4/2019 Prescriptive Requirements Analysis VIEW ME

http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 1/15

Prescriptive RequirementsAnalysisJeff Bryson System Architect

Lockheed Martin STS Orlando FL



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




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?




Statistics

• Study on over 14000 organizations showed: – 80-90% of the systems did not meet their goals

– Around 40% of the developments failed or wereabandoned

– Less than 25% fully integrated business andtechnology objectives

– Only 10-20% met their success criteriaCritical System Thinking and

Information Systems Development, 1997 Kameli – INCOSE presentation 2002

Barker – Rational – System Engineering Effectiveness

Requirements Defects Are Inception Defects




System Engineering andRequirements Analysis

•

Requirements analysis (not management) isthe single best way to identify technicalprogram risks and problems in the earlystages of a project.

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

• In 25 years of project development I’ve see

two RA processes used. I’m suggesting athird approach.

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

customer specification and placing the requirementsin DOORS

2. Admire the problem

– You can have analysis paralysis by analyzing therequirements to the nth degree and then describehow complex the problem is

3. You can use a prescriptive analysis processthat tell you exactly what you must do andhelp you identify when you are complete.

•Admire the problem

I can have analysis paralysis by analyzingthe requirements to the nth degree and thendescribe how complex the problem is




Prescriptive vs. Descriptive

• Prescription - the enforcement of rulesgoverning 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




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




Requirements Analysis Goals

1. Identify all Functional, Performance, Interfaceand Architectural requirements

2. Allocate performance, functional, interface,and architectural requirements to responsible

stakeholder.3. Identify testability of each requirement.

4. Provide justification for allocation andverification (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



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






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 (andtested) 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 zerofunctional requirements

• Traceability Map (auto generated)




Bringing it all Together Traceability Matrix




Prescriptive Errors

• It is acceptable to have errors in thePRA 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 andcorrect the ones that can be corrected

and track the rest.




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

performance requirement has beenallocated and verifiability has beenidentified

• When every Activity, Branch, Synchas one and only one low levelrequirements

• When every interface has beenidentified and linked to a functionalrequirement.

• Entity linkage is complete with in themodel to allow for error checking

• Any failures to meet the above are

identified as program risks and havebeen deemed acceptable bycustomer and program management

This means you only stop developing UC’s and start maintaining them.

• When I can create the following

documents from the UC analysis – System Requirements Specification

(mapped to customer requirements andstakeholders)

– System ICD (mapped to SystemRequirements 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 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 executedafter the product is built.

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

Prescriptive Requirements Analysis VIEW ME

Documents

Transcript of Prescriptive Requirements Analysis VIEW ME