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
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 2/15
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?
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 3/15
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 teach you something, or learn something from
you, which image do I show?
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 4/15
30 September 2008 Jeff Bryson Lockheed Martin STS 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 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
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 5/15
30 September 2008 Jeff Bryson Lockheed Martin STS 5
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
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 6/15
30 September 2008 Jeff Bryson Lockheed Martin STS 6
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
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 7/15
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
– 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/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 8/15
30 September 2008 Jeff Bryson Lockheed Martin STS 8
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
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 9/15
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 10/15
30 September 2008 Jeff Bryson Lockheed Martin STS 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 (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)
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 11/15
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 12/15
30 September 2008 Jeff Bryson Lockheed Martin STS 12
Bringing it all Together Traceability Matrix
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 13/15
30 September 2008 Jeff Bryson Lockheed Martin STS 13
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.
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 14/15
30 September 2008 Jeff Bryson Lockheed Martin STS 14
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
8/4/2019 Prescriptive Requirements Analysis VIEW ME
http://slidepdf.com/reader/full/prescriptive-requirements-analysis-view-me 15/15
30 September 2008 Jeff Bryson Lockheed Martin STS 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 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.”