Title: Prescriptive Requirements Analysis Jeff Bryson System Architect Lockheed Martin STS Orlando FL
1Prescriptive Requirements AnalysisJeff
BrysonSystem ArchitectLockheed Martin
STSOrlando FL
2Prescriptive 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?
3But 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?
4Statistics
- 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
technology objectives - Only 10-20 met their success criteria
- Critical System Thinking and
- Information Systems Development, 1997
- Kameli INCOSE presentation 2002
Requirements Defects Are Inception Defects
- Barker Rational System Engineering
Effectiveness
5System 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. - Keep it vague
- You can do almost nothing by repeating the
customer specification and placing the
requirements in DOORS - Admire the problem
- You can have analysis paralysis by analyzing the
requirements to the nth degree and then describe
how complex the problem is - You can use a prescriptive analysis process that
tell you exactly what you must do and help you
identify when you are complete.
6Prescriptive 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
7Use 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
8Requirements Analysis Goals
- Identify all Functional, Performance, Interface
and Architectural requirements - Allocate performance, functional, interface, and
architectural requirements to responsible
stakeholder. - Identify testability of each requirement.
- 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
9Prescriptive 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/ATMExa
mple/
- Customer inserts bank card
- ATM application monitors for new card
- ATM application reads customer card
- ATM application prompts customer for PIN
- Customer enters PIN
- ATM application sends card information and PIN to
bank for verification - Bank verifies information
- ATM received verification
- ATM display menu of operations to customer
- Customer selects account balance from menu
- ATM system request account balance from BANK
- BANK provide account balance
- ATM prints balance
- ATM system returns to step 9
10Prescriptive 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)
11Prescriptive Requirements Mapping
12Bringing it all Together Traceability Matrix
13Prescriptive 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.
14How 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.
- 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
15Value 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 VV
- 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.