Systems Engineering Fundamentals - PowerPoint PPT Presentation

Loading...

PPT – Systems Engineering Fundamentals PowerPoint presentation | free to view - id: 4681ba-ZjQwZ



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Systems Engineering Fundamentals

Description:

Systems Engineering Fundamentals Requirements Analysis – PowerPoint PPT presentation

Number of Views:558
Avg rating:3.0/5.0
Slides: 111
Provided by: Saade
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Systems Engineering Fundamentals


1
Systems Engineering Fundamentals
Requirements Analysis
2
Requirements Analysis Techniques
  • Context Analysis
  • States and Modes Analysis
  • Requirements Parsing
  • Requirements Template
  • Functional Analysis
  • Operational Concept Analysis
  • Requirements Decomposition
  • Use Case Analysis
  • ViewPoints Oriented Requirements Development

3
Requirements Analysis Techniques
  • Context Analysis
  • States and Modes Analysis
  • Requirements Parsing
  • Requirements Template
  • Functional Analysis
  • Operational Concept Analysis
  • Requirements Decomposition
  • Use Case Analysis
  • ViewPoints Oriented Requirements Development

4
Context Analysis
  • Capturing all specified interfacing systems and
    (life cycle) system inputs and outputs to provide
    a progressively developed point of reference for
    identification of missing external interface
    requirements and inputs/outputs.

5
Purpose of The Context Analysis
  • It provides a much better understanding of the
    requirements, and of the nature and extent of
    requirements issues.
  • Work through source documents, identifying each
    reference to an external system or particular
    element of the environment which is required to
    interface or interoperate with the system, or to
    an item which is specified to be input to or
    output from the system.

6
Conduct Context Analysis
  • Represent the interfacing entities on the
    periphery of a context diagram by considering
    each stage of lifecycle.

Operation Stage (Used block of CFD)
Automatic Meteorological Station
Abovewater Target
EO System
Power
BDOC Software
BDOC Operator
DVR
Passive Acoustic Array
7
Conduct Context Analysis
  • Name the interfacing entities and related
    external interfaces.

Automatic Meteorological Station
Abovewater Target
Visuality, Wind, Rain, Humudity
Visual View
EO System
Power
Power IF
Automatic Control
BDOC Software
Manual Control
Record Realtime Video
TRN of the target
BDOC Operator
DVR
Passive Acoustic Array
8
Requirements Analysis Techniques
  • Context Analysis
  • States and Modes Analysis
  • Requirements Parsing
  • Requirements Template
  • Functional Analysis
  • Operational Concept Analysis
  • Requirements Decomposition
  • Use Case Analysis
  • ViewPoints Oriented Requirements Development

9
States and Modes Analysis
  • States and Modes Analysis is performed to gain
    and effectively communicate an understanding of
    groupings, at the highest level of abstraction,
    of time-variant alternative characteristics
    required of the system.

10
Conduct States and Modes Analysis(2)
  • For each state/mode prepare dictionary
    description of that state/mode.
  • State/Mode Dictionary Entries Example
  • The Limited Capability State of the Abovewater
    Surveillaince and Detection System in which one
    of the EO sensor is off due to malfunction or
    maintenance. In this state other EO sensors will
    try to cover the surveillance region of the
    failed sensor.
  • Automatic Scanning Mode of the Abovewater
    Surveillance and Detection System is that mode EO
    sensors scan their predefined sectors for target
    detection.

11
Conduct States and Modes Analysis(3)
  • Enter the identified states and modes into a
    state/ mode table. Show mutual exclusivity in
    the table

State/Mode Table Example
State/Mode Limited Capability State Full Capability State Automatic Scanning Mode Manual Scanning Mode Tracking Mode
Limited Capability State   M M M
Full Capability State M  
Automatic Scanning Mode   M M
Manual Scanning Mode M M   M
Tracking Mode M M M  
12
Conduct States and Modes Analysis (4b)
Automatic Scanning Mode
Confirmed/Out of Range Audio/Visual Alert
Target Detected Audio/Visual Alert
Manual Control on Confirm Manual Mode
Manual Control off Automatic scanning
Tracking Mode
Manual Scanning Mode
Manual Control on Confirm Manual Mode
Track selected Visual Display
13
Requirements Analysis Techniques
  • Context Analysis
  • States and Modes Analysis
  • Requirements Parsing
  • Requirements Template
  • Functional Analysis
  • Operational Concept Analysis
  • Requirements Decomposition
  • Use Case Analysis
  • ViewPoints Oriented Requirements Development

14
Requirements Parsing
  • Requirements Parsing is a text analysis technique
    for identification of error, incompleteness,
    inconsistency, lack of clarity, ambiguity,
    unverifiability and infeasibility in textually
    stated requirements.

15
Elements of Parsing Template
  • Actor/Iniator of Action. This is the subject of
    the sentence - the thing being specified.
    Examples are the system, the interface, the
    function.
  • Action. This is a verb the action to be taken by
    the actor (subject). Examples are shall
    calculate, shall display, shall fly.
  • Object of Action. This is a noun, and is the
    thing acted upon by the actor. Examples are the
    message, the input signal.
  • Conditions of Action. This defines the conditions
    under which the action takes place, for example
    upon receipt of a message, in high resolution
    mode, within 10 minutes of power-on.
  • Constraints of Action. This qualifies the action,
    for example at a resolution of 400 x 1000
    pixels, within limits imposed by vehicle
    speed.
  • Refinement/Source of Object. These qualify the
    object, for example (refinement) of flash
    priority, for example (source) from DISCON.
  • Refinement/Destination of Action. These further
    qualify the action, and may be additional to
    Constraints of Action. Examples are within
    10ms, to DISCON.
  • Other. This element collects non-requirements
    material.

16
Requirement Parsing
The system, shall switch the message within 10
milliseconds of receipt, upon receipt of a
message for messages in ACP128 format having a
valid routing indicator, from the message input
port, to a message output port, corresponding to
the routing indicator in the message.
Actor The system,
Condition of Action upon receipt of a message
Action shall switch
Object of Action the message
Constraints of Action within 10 milliseconds of receipt,
Refinement of Object for messages in ACP128 format having a valid routing indicator,
Source of Object from the message input port,
Destination of Action to a message output port,
(Further) Refinement of Action corresponding to the routing indicator in the message.
17
Conduct Requirements Parsing
Original Requirement For the given Zone, a main
Switch, which is identical to a trunk node
switch, shall be given two (2) independent links
to at least two (2) other nodes in the network.
Actor A main Switch,
Condition of Action For the given zone,
Action shall be given
Object of Action Two (2) independent links
Constraints of Action
Refinement of Object to at least two (2) other nodes in the network
Source of Object
Destination of Action
(Further) Refinement of Action which is identical to a trunk node switch,
18
Conduct Requirements Parsing
Example Requirement The operator shall be able
to read a 10 cm high name and other
distinguishing markings at a range of at least
0.25 nm and a 40 cm high name at a range of 1 nm
during the day under high visibility conditions
and with a black-white contrast.
Element Text
Actor The operator
Action shall be able to read
Object of Action a 10 cm high name and other distinguishing markings / a 40 cm high name
Conditions for Action at a range of at least 0.25 nm /at a range of 1 nm
Constraints of Action during the day under high visibility conditions
Refinement / Source of Object  
Refinement / Destination of Action  and with a black-white contrast.
19
Conduct Requirements Parsing
Element Text Remark
Actor The operator
Action shall be able to read
Object of Action a 10 cm high name and other distinguishing markings / a 40 cm high name Two objects
Conditions for Action at a range of at least 0.25 nm /at a range of 1 nm
Constraints of Action during the day under high visibility conditions High visibility?
Refinement/ Source of Object  
Refinement/ Destination of Action and with a black-white contrast.   Contrast scale?
20
Conduct Requirements Parsing
  • Calculate Individual Requirement Quality
  • Determine which of the possible seven elements of
    the structure are applicable and assign a value
    of 1 to each applicable element (most
    requirements have 5-7 applicable elements)
  • Assess each element of the parsed requirement
    against the quality factor criteria, and score
    each applicable element as 1 (satisfactory) or 0
    (unsatisfactory).
  • Calculate the metric by dividing the sum of the
    element scores into the sum of the applicable
    element values.

21
Conduct Requirements Parsing
  • Example IRQ

Element Applicability Score
Actor 1 1
Action 1 1
Object of Action 1 0
Conditions for Action 1 1
Constraints of Action 1 0
Refinement/ Source of Object 0 0
Refinement/ Destination of Action 1 0
TOTAL 6 3
  • OmmissionRatio TotalApplicability-TotalScore 3
  • IRQ TotalScore / TotalApplicability 3 / 6 0.5

22
Conduct Requirements Parsing
  • Score Indivudual Quality Factors (IQF)

Quality Metrics Metric Name  Metric Value
Correctness IQF1 1
Completeness IQF2 1
Consistency IQF3 1
Clarity IQF4 0
Non-ambiguity IQF5 1
Singularity IQF6 0
Verifiability IQF7 0
Feasibility IQF8 1
Functional Orientation IQF9 1
23
Conduct Requirements Parsing
  • Calculate Aggregate Requirements Quality and
    Quality Factors from individual requirements for
    requirements groups
  • RQ ?IRQ/n RQ means Requirements quality
  • QF1 ?IQF1/n QF means Requirements Quality
    Factor
  • IQF2 ?IQF2/n - ?OmmisionRatio/n
  • IQFx ?IQFx/n x takes a value between 3 and 9

24
Conduct Requirements Parsing
Metrics QL1 QL2 QL3 QL4
RQ 0.01-0.3 0.3-0.7 0.95-0.99 0.99
QF1-Correctness 0.9 0.98 0.99 0.99
QF2-Completeness 0.5 0 0.95 0.99
QF3-Consistency 0.9 0.97 0.99 0.99
QF4-Clarity 0.9 0.97 0.99 0.99
QF5-Non-Ambiguity 0.3 0.7 0.9 0.98
QF6-Singularity 0.1 0.3 0.99 1
QF7-Verifiability 0.1 0.7 0.99 0.99
QF8-Feasibility 0.95 0.99 0.99 0.99
QF9-Functional Ori. 0.9 0.98 0.99 0.99
  • Quality Level (QL) of Requirements Set
  • QL1 Very poor set of requirements, requiring
    substantial development
  • QL2 Fair set of requirements, may just be
    suitable for purposes of solicitation, depending
    on the SOW and type of contract envisaged
  • QL3 Requirements at SRR suitable for carrying
    forward into development
  • QL4 Requirements suitable for establishment of
    the Functional Baseline

25
Conduct Requirements Parsing
  • Try to solve deficiencies (to increase quality)
    with below alternatives
  • Refine the requirement
  • Derive new requirements
  • Split into child requirements
  • putting a note on decision table as To Be
    Resolved to resolve with customer.(Future
    resolution)

26
Requirements Parsing
  • Example Solution
  • Split into two requirements and put traceability
    to parent requirements.
  • Put a quantative verifiable condition for
    visibility
  • The operator shall be able to read a 10 cm high
    name and other distinguishing markings at a range
    of at least 0.25 nm with 8 bit black-white
    contrast during the day where the visibility
    factor ?0.2 km-1.

27
Requirements Analysis Techniques
  • Context Analysis
  • States and Modes Analysis
  • Requirements Parsing
  • Requirements Template
  • Functional Analysis
  • Operational Concept Analysis
  • Requirements Decomposition
  • Use Case Analysis
  • ViewPoints Oriented Requirements Development

28
Requirements Template
  • Requirements Templates standardizes format,
    simplifies writing procedure, conforms to
    properties of good requirements, consolidates
    functionality, interfaces, performance and some
    specialty requirements such as security.
  • Capture requirements according to template and
    try to resolve missing parts by interviewing with
    stakeholders.

29
Conducting Requirements Template (1)
  • Define requirements template structure to capture
    need.
  • The ltsystem_namegt shall produce ltoutputgt
  • for use by ltdestinationgt
  • if lttriggergt
  • using ltinputsgt
  • where ltamplifying informationgt

30
Conducting Requirements Template (2)
  • Define templates variables
  • system _name - the system/subsystem which
    produces the output
  • output the product that is generated by the
    system/subsystem
  • destination(s) the human user, or an external
    system that uses the output identified above
  • trigger the condition that causes the system to
    produce the output
  • input(s) the information entering the system or
    subsystem needed to create the output
  • amplifying information additional data that
    clarifies the clauses of the requirement

31
Example Captured Requirement
The OIS shall produce a missile mission planning
display for use by the OIS user if
requested by the user using user entered
necessary information (????) where the
display includes available surface
launched missile missions, ground
targets, maritime targets,
missile count and type for user selected missile
mission
32
Requirements Analysis Techniques
  • Context Analysis
  • States and Modes Analysis
  • Requirements Parsing
  • Requirements Template
  • Functional Analysis
  • Operational Concept Analysis
  • Requirements Decomposition
  • Use Case Analysis
  • ViewPoints Oriented Requirements Development

33
Requirements Analysis Techniques
  • Context Analysis
  • States and Modes Analysis
  • Requirements Parsing
  • Requirements Template
  • Functional Analysis
  • Operational Concept Analysis
  • Requirements Decomposition
  • Use Case Analysis
  • ViewPoints Oriented Requirements Development

34
Concept of Operations
  • Operational Concept Document (OCD) is produced
    early in requirements development process
  • to describe what the system will do (not how it
    will do) and why (system rationale)
  • to define critical, top-level performance
    requirements or objectives.
  • OCD should contain preliminary functional block
    diagram of the system with only the top-level
    functional threads.
  • No attempt is made at this stage to define a
    complete operational concept.
  • OCD is essentially a functional concept
    definition and rationale from the user and
    customer perspective.

35
Objective of OCD Analysis
  • To provide traceability between operational needs
    and the written source requirements captured.
  • To establish a basis for requirements to support
    the system over its life, such as personnel
    requirements, support requirements, etc.
  • To establish a basis for test planning,
    system-level test requirements, and any
    requirements for environmental simulators.
  • To generate operational analysis models to test
    the validity of external interfaces between the
    system and its environment, including
    interactions with external systems.
  • To provide the basis for computation of system
    capacity, behavior under/overload, and mission
    effectiveness calculations.
  • To validate requirements at all levels and to
    discover implicit requirements overlooked in the
    source documents.

36
How to produce OCD
  • Deduce a set of statements describing the
    higher-level, mission-oriented system objectives
    (using users statement of need and other
    sources).
  • Review the system objectives with end users and
    operational personnel.
  • Define the boundaries of the operational models.
  • For each model, generate a context diagram to
    represent the model boundary.
  • Add concurrent functions to the context diagram,
    which are performed by the sections of external
    systems that send input stimuli to the system or
    receive outputs from the system.
  • Identify all of the possible types of observable
    input and output events that can occur between
    the system and its in interacting external
    systems.
  • Define a system interface between the system and
    the environment or external system.

37
How to produce OCD, cont
  • For each class of interaction between a part of
    the system and an external system, create a
    functional flow diagram to model the sequence of
    interactions as triggered by the stimuli events
    generated by the external systems.
  • Review the functional flow diagrams with end
    users and operational personnel.
  • Develop timelines, approved by end users, to
    supplement the source requirements.

38
OCD Topics
1. Scope 1.1 Identification 1.2 System
Overview 1.3 Document Overview 2. Reference
Documents 3. Current System or Situation 3.1
Background, Objectives, and Scope 3.2 Operational
Policies and Constraints 3.3 Description of
Current System or Situation 3.4 User or Involved
Personnel 3.5 Support Concept 4. Justification
for and Nature of Changes 4.1 Justification for
Change 4.2 Description of Needed Changes 4.3
Priorities Among the Changes 4.4 Changes
Considered but Not Included 4.4 Assumptions and
Constraints
5. Concept for a New or Modified System 5.1
Background, Objectives, and Scope 5.2 Operational
Policies and Constraints 5.3 Description of the
New or Modified System 5.4 Users/Affected
Personnel 5.5 Support Concept 6. Operational
Scenarios 7. Summary of Impacts 7.1 Operational
Impacts 7.2 Organizational Impacts 7.3 Impacts
During Development 8. Analysis of the Proposed
System 8.1 Summary of Advantages 8.2 Summary of
Disadvantages/Limitations 8.3 Alternatives and
Trade-offs Considered 9. Notes
39
Exercise MPS Operational Concept
  • Develop an operational concept description for
    the MPS based on the Operational Need defined
    before.
  • Concept for the Message Processing System
  • Operational Scenarios

40
Answer MPS Operational Concept
  • 5. Concept for the Message Processing System
  • 5.1 Background, objectives, and scope
  • There is no means currently available to
    distribute incoming and outgoing messages between
    the Global Military Communication System (GMCS)
    and the Inter-Island Communication System (IICS).
    MPS will provide a collection and distribution
    point for messages between the two systems.
  • 5.2 Operational policies and constraints
  • All outgoing messages to be transmitted to the
    GMCS must be encrypted regardless of
    classification. Incoming messages received from
    the GMCS for distribution to military units on
    the IICS are forwarded without any changes by the
    MPS.
  • 5.3 Description of the new or modified system
  • MPS will operate 24 hours per day in an
    automated mode to process either incoming or
    outgoing messages on both the GMCS and the IICS.
    To allow for continuous operation of the MPS the
    system will have redundent hardware and software
    capabilities with automatic switchover between
    the primary and back-up units upon failure of the
    current primary unit. The MPS operator will have
    the capability to shut down either the IICS or
    GMCS interfaces or the MPS system as needed. The
    latest 60 days of IICS generated messages will be
    stored and available for analyst on-line review.
    IICS messages over 60 days old will be archived
    to magnetic tape storage and retained for a
    minimum of two years. Access to the archived
    storage is not included in the initial MPS
    capability but may be added in the future.

41
Answer MPS Operational Concept
5.4 Users/affected personnel MPS Analysts -
use MPS to review IICS messages on on-line
storage to determine the correct classification
and to select which messages are to be forwarded
via the GMCS. The analysts may also generate new
messages to be stored and forwarded via the GMCS.
MPS Operator - exercises control over the
MPS with the capability to start-up or shut-down
the interface between the IICS and GMCS and/or
start or stop the MPS. The MPS Operator monitors
the system operation via error and other operator
messages on the operator display. 5.5 Support
Concept MPS will have sufficient redundancy
to allow continuous operation. Failed components
will be taken off-line for repair or replacement.
Software failures will be the responsibility of
an on-going maintenance contract with the
developer. Plans will be made for periodic
releases of new versions of the software.
Provision will also be made to allow for
individual software updates to the operational
system to resolve critical problems which cannot
wait for the next software release. All
individual updates will be included in the next
software release.
42
Answer MPS Operational Concept
6. Operational Scenarios 6.1 Each message
received from the GMCS will be processed by the
MPS to determine which IICS military units are to
receive the message. The appropriate unit
addresses are added to the message and it is
forwarded via the IICS. 6.2 Each message
received from the IICS is stored in the IICS
Message Data Base. A review flag is set in the
message to indicate that it has not been
processed by an analyst for transmission via the
GMCS. 6.3 Analysts review messages stored in
the IICS Message Data Base, assign them a
classification and select the messages to be
transmitted to the USA and UK via the GMCS.
Analysts can choose to print or display the
messages being reviewed. The review flag is
updated on all messages reviewed by an
analyst. 6.4 Once a day the messages in the
IICS Message Data Base that are over 60 days old
are copied to a magnetic tape for archiving and
they are deleted from the on-line data base.
43
Answer MPS Operational Concept
6.5 Analysts generate messages which are stored
on disk for subsequent review and transmission
to the USA and UK. 6.6 Twice daily messages are
received on diskettes. These messages are read
and stored on disk for subsequent review and
transmission to the USA and UK. 6.7 Analysts
conduct on-line training as needed, without
impacting message processing. 6.8 Start-up and
Shut-down scenarios. 6.9 Maintenance
scenario. 6.10 MPS failure scenarios. 6.11
Hostile action scenario.
44
Requirements Analysis Techniques
  • Context Analysis
  • States and Modes Analysis
  • Requirements Parsing
  • Requirements Template
  • Functional Analysis
  • Operational Concept Analysis
  • Requirements Decomposition
  • Use Case Analysis

45
Requirements Decomposition
  • Breaking down complex requirements into single,
    simple requirement statements
  • Decomposed requirement statement may interpret or
    quantify the spec language
  • Decomposition does not change the contractual
    requirement or specification document

46
Conducting Requirements Decomposition (1)
  • Perform Functional Analysis (Identify the desired
    behaviour)

22 The Aircraft(A/C) shall have a precision
landing capability for both Carrier Vessel(CV)
and land based operations. Example Functional
Flow
Identify Landing Area
Engage Flight Control Surfaces
Engage Landing Gear
Engage Tail Hook
Land
Stowage
47
Conducting Requirements Decomposition (2)
  • Identify ALL impacting requirements (customer
    and/or derived)
  • 22 The Aircraft(A/C) shall have a precision
    landing capability for both Carrier Vessel(CV)
    and land based operations.
  • Example Impacting Requirements
  • Carrier identification (i.e., class, location,
    etc.)
  • Potential environmental conditions
  • Supportability concerns (land and sea based)

48
Conducting Requirements Decomposition (3)
  • Identify issues
  • 22 The Aircraft(A/C) shall have a precision
    landing capability for both Carrier Vessel(CV)
    and land based operations.
  • Example Identified Issues
  • Will CV landing capability impact the overall
    Logistic footprint?
  • Will CV landing capability impact mission radius?

49
Conducting Requirements Decomposition (4)
  • Resolve issues to define/identify alternate
    solutions
  • 22 The Aircraft(A/C) shall have a precision
    landing capability for both Carrier Vessel(CV)
    and land based operations.
  • Example Alternate Solutions for Issue
  • Yes - CV landing capability will impact the
    overall logistic footprint because of deck
    spotting factor and stowage constraints
  • Make aircraft spot factor smaller
  • Change carrier sizing constraints

50
Conducting Requirements Decomposition (5)
  • Identify the decision, derived requirements and
    allocations
  • 22 The Aircraft(A/C) shall have a precision
    landing capability for both Carrier Vessel(CV)
    and land based operations.
  • Example Decision, Derived Requirement and
    Allocation
  • Decision Limit the A/C spot factor
  • Documented By Design decision memo xx dated
    mm/dd/yy
  • Derived Requirement 22.1 A/C dimensions shall
    be no larger than x-y-z.
  • Allocated to WBS 1xxx, Air Vehicle IPD Teams
    XXX (the single point of accountability and all
    of the supporting teams)

51
Conducting Requirements Decomposition (6)
  • Record the issues, decision, derived
    requirements, and allocations in the requirements
    database

52
Example Level 1 DecompositionWeapon System
Responsibility
22 The Aircraft(A/C) shall have a precision
landing capability for both Carrier Vessel and
land based operations. Perform functional
analysis (identify the desired behavior)
Identify landing area Engage flight control
surfaces Engage landing gear Engage tail
hook Land Stowage
Identify ALL impacting requirements (customer
and/or derived) A. Carrier identification (i.e.,
class, location, etc.) B. Potential environmental
conditions C. Supportability concerns (land and
sea based) Identify issues A. Will CV landing
capability impact the overall Logistic
footprint? B. Will CV landing capability impact
mission radius?
53
Example Level 1 Decomposition Weapon System
Responsibility
  • Resolve issues to define/identify alternate
    solutions
  • A. Yes - CV landing capability will impact the
    overall logistic footprint because of deck
    spotting factor and stowage constraints
  • 1. Make aircraft spot factor smaller
  • 2. Change carrier sizing constraints
  • Identify the decision, derived requirements and
    allocations
  • Decision Limit the A/C spot factor
  • Documented By Design decision memo xx dated
    mm/dd/yy
  • Derived Requirement 22.1 A/C dimensions shall
    be no larger than x-y-z.
  • Allocated to WBS 1xxx, Air Vehicle IPD Teams
    XXX (the single point of accountability and all
    of the supporting teams)
  • Record the issues, decision (and appropriate
    documentation), derived requirements, and
    allocations in the requirements database

54
Example Level 2 Decomposition System
Responsibility / Action
22.1 - A/C dimensions shall be no larger than
x-y-z. Perform functional analysis (identify the
desired behavior) Land Turn aircraft Stow
on deck or Load on elevator Stow below
deck Identify ALL impacting requirements
(customer and/or derived) A. Signature
constraints (needs 7) B. Operational and
supportability cost (needs 1) C. Deployability
(needs 31) Identify Issues A.
Reliability/maintainability impact? B. Design
vs. producibility constraints?
55
Example Level 2 Decomposition System
Responsibility / Action
  • Resolve issues to define/identify alternate
    solutions
  • A. Design must account for manufacturing
    technology and producibility costs
  • 1. Removable wings
  • 2. Inflatable wings
  • 3. Foldable wings
  • Identify the decision, derived requirements and
    allocations
  • Decision Foldable wings
  • Documented By Trade Study 1234 dated mm/dd/yy
  • Derived Requirement 22.1.1 Wings shall be
    foldable to enable stowage and maintenance.
  • Allocated to WBS 11xx, AirFrame IPD Teams XXX
    (the single point of accountability and all of
    the supporting teams)
  • Record the issues, decision (and appropriate
    documentation), derived requirements,
  • and allocations in the requirements database

56
Example Level 3 DecompositionSegment
Responsibility / Action
22.1.1 - Wings shall be foldable to enable
stowage and maintenance. Perform functional
analysis (identify the desired behavior) Pilot/ma
intainer input Fold wing Lock wing Identify
ALL impacting requirements (customer and/or
derived) A. Maximum crosswind B. LO
concerns C. Maximum allowable hydraulic
pressure D. Maximum allocated power
usage Identify Issues A. Type of power for the
wingfold mechanism system? B. What is the
minimum/maximum? C. What type of hinge line will
result in the desired angle
57
Example Level 3 DecompositionSegment
Responsibility / Action
  • Resolve issues to define/identify alternate
    solutions
  • A. Identification and trade study based on
    various mechanical or electrical mechanisms and
    hinge solutions
  • 1. Articulating hinge line
  • 2. Single axis hinge line with
    hydraulic/mechanical mechanism
  • Identify the decision, derived requirements and
    allocations
  • Decision Hydraulic power with single axis hinge
    line
  • Documented By Trade Study 1786 dated mm/dd/yy
  • Derived Requirement 22.1.1.1 The wing-fold
    mechanism shall be hydraulically driven with a
    single axis hinge line
  • Allocated to WBS 11D0, Hydraulic/Pneumatic
    Subsystem IPD Teams XXX (the single point of
    accountability and all of the supporting teams)
  • Record the issues, decision (and appropriate
    documentation), derived requirements, and
    allocations in the requirements database

58
Example Level 4 Decomposition Sub-Segment
Responsibility / Action
22.1.1.1 - The wing-fold mechanism shall be
hydraulically driven with a single axis hinge
line Perform functional analysis (identify the
desired behavior) Pilot/maintainer
input Processor action Signal to
actuator Fluid flow Hinge
movement Identify ALL impacting requirements
(customer and/or derived) A. Structural loads B.
Hydraulic power available/needed C. RM
concerns Identify Issues A. O, I and D level
maintenance? B. Impact of safety and/or
redundancy requirements
59
Example Level 4 Decomposition Sub-Segment
Responsibility / Action
  • Resolve issues to define/identify alternate
    solutions
  • A. Reliability requirements identify need for
    system redundancy
  • 1. Single hydraulic drive - need customer change
    to delete redundancy
  • 2. Dual hydraulic drive to ensure backup
    capability
  • Identify the decision, derived requirements and
    allocations
  • Decision Dual hydraulic drive to ensure backup
    capability
  • Documented by Trade study 1786 dated mm/dd/yy
    (contains program office letter 17285, dated
    mm/dd/yy denying limination of redundancy
    requirement)
  • Derived requirement 22.1.1.1.1 Dual hydraulic
    drive systems shall be utilized for all hydraulic
    driven mechanisms
  • Allocated to WBS 11D1, hydraulic hardware
    elements IPD teams XXX (the single point of
    accountability AND all of the supporting teams)
  • Record the issues, decision (and appropriate
    documentation), derived requirements, and
    allocations in the requirements database

60
Example Level 5 Decomposition Hardware Elements
Responsibility / Action
22.1.1.1.1 - Dual hydraulic drive systems shall
be utilized for all hydraulic driven
mechanisms. Perform functional analysis
(identify the desired behavior) Pilot/maintainer
input Processor action System 1 fluid to
control surfaces Notice of hydraulic
failure System 2 fluid to control
surfaces Identify ALL impacting requirements
(customer and/or derived) A. Weight B.
Size/Location constraints Identify Issues A.
System 1 vs system 2 definition? B. Rates of
fluid flow to each system? C. Display
failures/status to pilot/maintainer?
61
Example Level 5 Decomposition Hardware Elements
Responsibility / Action
  • Resolve issues to define/identify alternate
    solutions
  • A. Trade study indicates design of and
    operability of both systems
  • 1. System 1 is power control / system 2 is power
    and weapons combined
  • 2. System 1 is weapons only / system 2 is
    combined
  • Identify the decision, derived requirements and
    allocations
  • Decision System 1 is power control / system 2 is
    power and weapons combined
  • Documented by Trade study 11185 dated mm/dd/yy
  • Derived requirement 22.1.1.1.1.1 The dual
    hydraulic drive systems shall be a redundant
    system with 1 system having power control and the
    second one satisfying a combined tasking
  • Allocated to WBS 11D1x, hydraulic hardware
    elements next level down IPD teams XXX (the
    single point of accountability AND all of the
    supporting teams)
  • Record the issues, decision (and appropriate
    documentation), derived requirements, and
    allocations in the requirements database

62
Requirements Analysis Techniques
  • Context Analysis
  • States and Modes Analysis
  • Requirements Parsing
  • Requirements Template
  • Functional Analysis
  • Operational Concept Analysis
  • Requirements Decomposition
  • Use Case Analysis
  • ViewPoints Oriented Requirements Development

63
Use Case
  • A use case is a sequence of transactions in a
    system whose task is to yield a measurable value
    to an individual actor of the system
  • Describes WHAT the system (as a Black Box) does
    from a users (actor) perspective
  • The Use Case Model is NOT an inherently object
    oriented modeling technique

64
Purpose of The Use Case
  • Captures operational requirements from users
    perspective
  • Gives a clear and consistent description of what
    the system should do
  • A basis for performing system tests
  • Provides the ability to trace functional
    requirements into actual classes and operations
    in the system

65
UML Use Case Diagrams
  • A Use Case model is described in UML (Unified
    Modeling Language) as one or more Use Case
    Diagrams (UCDs)
  • A UCD has 4 major elements
  • The system described
  • The actors that the system interacts with
  • The use-cases, or services, that the system knows
    how to perform
  • The relationships between the above elements

66
System Boundary in Use Case (1)
  • As part of use-case modeling, the boundaries of
    the system developed must be defined
  • Defining the boundaries of the system is not
    trivial
  • Which tasks are automated and which are manual?
  • Which tasks are performed by other systems?
  • The entire solution that we supply should be
    included in the system boundaries
  • Incremental releases

67
System Boundary in Use Case (1)
  • A system in a UCD is represented as a box
  • The name of the system appears above or inside
    the box

Traffic Violations Report System
68
Actor (1)
  • Someone or something that interacts with the
    system (exchanges information with the system)
  • An actor represents a role played with respect to
    the system, not an individual user of the system
  • Example
  • Policeman Enters data
  • Supervisor Allowed to modify/erase data
  • Manager Allowed to view statistics.
  • A single user may play more than one role

69
Actor (2)
  • Actors have goals
  • Add a Traffic Violation
  • Lookup a Traffic Violation
  • Actors dont need to be human
  • May be an external system that interfaces with
    the developed system
  • An actor has a name that reflects its role

70
Relationships between Actors
  • When several actors as part of their roles, also
    play a more generalized role, it is described as
    generalization
  • The behavior of the general role is described in
    an actor super-class
  • The specialized actors inherit the behavior of
    the super-class and extend it in some way
  • Relationships between actors are not always
    necessary

71
Use Case
  • Represent a complete behavior as perceived by an
    actor
  • A use case satisfies an actors goal
  • Always initiated by an actor
  • A use case is complete
  • Dont divide a use case into smaller use cases
    that implement each other (functional
    decomposition)

72
Use Case Description
  • The scenarios of a use case are normally
    described textually
  • A simple and consistent specification about how
    the actors and the system interact
  • Use case description template
  • Describe at the level of user intentions and
    system responses
  • Free of technology and mechanism details,
    especially those related to user interface

73
Conduct Use Case (1)
  • Draw use case diagram that shows actors and
    interactions of the actors with the system
  • Example (Microwave Oven System)

Microwave Oven System
initiator
Cook Food
Cook
74
Conduct Use Case (2)
  • Define a use case for each use case of the use
    case diagram
  • Example
  • Name Cook Food
  • Brief description This use case describes the
    user interaction and operation of a microwave
    oven. Cook invokes this use case in order to cook
    food in the microwave.
  • Added value Food is cooked.
  • Scope A microwave oven
  • Primary actor Cook
  • Supporting actors Timer
  • Preconditions The microwave is waiting to be
    used.

75
Conduct Use Case (3)
  • Define main success scenario
  • Example
  • Cook opens the microwave oven door, puts food
    into the oven, and then closes the door.
  • Cook specifies a cooking time.
  • System displays entered cooking time to Cook.
  • Cook starts the system.
  • System cooks the food, and continuously displays
    the remaining cooking time.
  • Timer indicates that the specified cooking time
    has been reached, and notifies the system.
  • System stops cooking and displays a visual and
    audio signal to indicate that cooking is
    completed.
  • Cook opens the door, removes food, then closes
    the door.
  • System resets the display.

76
Conduct Use Case (4)
  • Define alternate flows
  • Example
  • 1a. If Cook does not close the door before
    starting the system (step 4), the system will not
    start.
  • 4a. If Cook starts the system without placing
    food inside the system, the system will not
    start.
  • 4b. If Cook enters a cooking time equal to zero,
    the system will not start.
  • 5a. If Cook opens the door during cooking, the
    system will stop cooking. Cook can either close
    the door and restart the system (continue at step
    5), or Cook can cancel cooking.
  • 5b. Cook cancels cooking. The system stops
    cooking. Cook may start the system and resume at
    step 5. Alternatively, Cook may reset the
    microwave to its initial state (cancel timer and
    clear displays).

77
Conduct Use Case (5a)
  • Capture functional requirements from the steps of
    the main and the alternative flows
  • Example
  • Req. F1 The system shall provide a mechanism for
    Cook to enter a cooking time. From step 2
  • Req F2 The system shall be capable of displaying
    the cooking time entered by Cook. From step 3
  • Req F3 The system shall cook food using
    microwave radiation. From step 5
  • Req F4 The system shall be capable of
    calculating and displaying the remaining cooking
    time From step 5
  • Req F5 The system shall interface with a timer
    mechanism such that the system is stopped when
    the timer elapses. From step 6

78
Conduct Use Case (5b)
  • Capture functional requirements from the steps of
    the main and the alternative flows
  • Example (Continued)
  • Req F7 The system shall emit an audible signal
    when the timer has elapsed. From step 7
  • Req F8 The system shall visually indicate when
    the timer has elapsed. From step 7
  • Req F9 The system shall be capable of
    determining whether the oven door has been
    closed. From step 1a
  • Req F10 The system shall not start, if the
    system detects that the door is open. From step
    1a
  • Req F11 The system shall be capable of
    determining if food has been placed in the oven.
    From step 4a

79
Conduct Use Case (5c)
  • Capture functional requirements from the steps of
    the main and the alternative flows
  • Example (Continued)
  • Req F12 The system shall not start, if the
    system detects that no food has been placed in
    the oven. From step 4a
  • Req F13 The system shall stop running if the
    oven door is opened while the system is running.
    From step 5a
  • Req F14 The system shall provide a mechanism to
    cancel a cook time entered by Cook. From steps
    5a and 5b
  • Req F15 The system shall stop running if the
    cook time is canceled while the system is
    running. From steps 5a and 5b

80
Conduct Use Case (6a)
  • Think about performance and other constraints to
    capture nonfunctional requirements and decide
    with stakeholders.
  • Example (Continued)
  • Req N1 The system shall allow Cook to enter the
    cooking time in less than five keystrokes.
    Constraint on Req F1, from stakeholder
    interviews
  • Req N2 The cooking time displayed by the system
    shall be visible to a Cook with 20/20 vision
    standing five feet from the oven in a room with
    an luminance level between 0 and 100
    foot-candles. Constraint on requirement F2, and
    from stakeholder interviews
  • Req N3 The system shall raise the temperature of
    food in the oven such that temperatures at two
    distinct locations in the food are different by
    less than 10. Constraint on Req F3, and from
    stakeholder interviews where stakeholders desire
    even cooking of food

81
Conduct Use Case (6b)
  • Think about performance and other constraints to
    capture nonfunctional requirements and decide
    with stakeholders.
  • Example (Continued)
  • Req N4 The system shall update the remaining
    cook time display every second. Constraint on
    Req F4
  • Req N5 The audible signal emitted by the oven
    shall have an intensity level of 80 decibels, /-
    2 decibels. Constraint on Req F7, from
    stakeholder interviews
  • Req N6 The system shall detect food items
    weighing at least 0.05 ounces and with a volume
    of at least 1 cubic inch. Constraint on Req F11,
    obtained from stakeholder interviews

82
Conduct Use Case (6c)
  • Think about performance and other constraints to
    capture nonfunctional requirements and decide
    with stakeholders.
  • Example (Continued)
  • Req N7 The system shall comply with section 1030
    of Title 21- Food and Drugs, Chapter I Food
    and Drug Administration, Department of Health and
    Human Services, Subchapter J Radiological Health
    Constraint on Req F3, specifies required
    compliance with health standards
  • Req N8 The system shall provide 14 3/4" Width x
    8 3/4" Height x 15 3/4" Depth inside cooking area
    volume. From step 1, obtained by stakeholder
    interviews
  • Req N9 The cooking time shall be adjustable
    between one second and ninety minutes
    Constraint on Req F1, obtained from stakeholder
    interviews

83
Conduct Use Case (7)
  • Record the captured requirements with the
    captured source (Use case Name and stakeholder
    interview if exist) to the requirements database

84
Requirements Engineering Process
85
Objectives of Requirements Engineering (RE)
Process
  • Requirements cannot be established without
    checking their impact (achievability) on lower
    level elements.
  • Requirements definition is an iteration and
    balancing process that works both top-down and
    bottom-up.
  • Once the top level requirements has been
    established, it is necessary to allocate and flow
    down to successively lower levels.
  • As the allocation and flowdown is repeated,
    traceability to top level requirements are
    assured.

86
RE Process Variability
  • RE processes vary radically from one
    organisation to another
  • Factors contributing to this variability include
  • Technical maturity
  • Disciplinary involvement
  • Organisational culture
  • Application domain
  • There is therefore no ideal requirements
    engineering process

87
Example RE Process Model
88
Example RE Process Model
  • Requirements elicitation
  • Requirements discovered through consultation with
    stakeholders
  • Requirements analysis and negotiation
  • Requirements are analysed and conflicts resolved
    through negotiation
  • Requirements documentation
  • A requirements document is produced
  • Requirements validation
  • The requirements document is checked for
    consistency and completeness

89
Example RE Process Model
90
CASE Tool Support
  • Management tools help manage a database of
    requirements and support the management of
    changes to these requirements.
  • Requirements storage
  • Requirements should be managed in a secure,
    managed data store.
  • Change management
  • The process of change management is a workflow
    process whose stages can be defined and
    information flow between these stages partially
    automated.
  • Traceability management
  • Automated retrieval of the links between
    requirements.

91
Requirements Management Tools
  • Requirements browser
  • Requirements query system
  • Requirement Traceability
  • Report generator
  • Requirements converter and word processor linker
  • Change control system

92
A Requirements Management Tool
93
Requirements change management
  • Should apply to all proposed changes to the
    requirements.
  • Principal stages
  • Problem analysis. Discuss requirements problem
    and propose change
  • Change analysis and costing. Assess effects of
    change on other requirements
  • Change implementation. Modify requirements
    document and other documents to reflect change.

94
RE Process Problems
  • Lack of stakeholder involvement
  • Business needs not considered
  • Lack of requirements management
  • Lack of defined responsibilities
  • Stakeholder communication problems
  • Over-long schedules and poor quality requirements
    documents

95
Requirements Reviews
  • To deal with RE Process Problems regular reviews
    should be held while the requirements definition
    is being formulated
  • Both client and contractor staff should be
    involved in reviews
  • Reviews may be formal (with completed documents)
    or informal. Good communications between
    developers, customers and users can resolve
    problems at an early stage

96
Review Checks
  • Verifiability. Is the requirement realistically
    testable?
  • Comprehensibility. Is the requirement properly
    understood?
  • Traceability. Is the origin of the requirement
    clearly stated?
  • Adaptability. Can the requirement be changed
    without a large impact on other requirements?

97
RE Process Key Points
  • The requirements engineering process is a
    structured set of activities which lead to the
    production of a requirements document.
  • Inputs to the requirements engineering process
    are information about existing systems,
    stakeholder needs, organisational standards,
    regulations and domain information.
  • Requirements engineering processes vary radically
    from one organisation to another. Most processes
    include requirements elicitation, requirements
    analysis and negotiation and requirements
    validation.
  • Human, social and organisational factors are
    important influences on requirements engineering
    processes.
  • Requirements engineering process improvement is
    difficult and is best tackled in an incremental
    way.
  • Requirements engineering processes can be
    classified according to their degree of maturity.

98
Activities of The Requirements Engineering
99
Perspectives of View for the Requirements Analysis
WHAT the system must do to produce the required
operational behavior.
HOW the system is constructed.
Functional
Physical
VIEWS OF THE REQUIREMENTS ANALYSIS
Operational
How the system will serve its users.
100
Operational View for the Requirements Analysis
  • Operational need definition,
  • System mission analysis,
  • Operational sequences,
  • Operational environments,
  • Conditions/events to which a system must respond,
  • Operational constraints on system,
  • Mission performance requirements,
  • User and maintainer roles (defined by job tasks
    and skill requirements or constraints),
  • Structure of the organizations that will operate,
    support and maintain the system,
  • Operational interfaces with other systems.

Functional
Operational
Physical
101
Functional View for the Requirements Analysis
  • System functions,
  • System performance,
  • Qualitative how well
  • Quantitative how much, capacity
  • Timeliness how often
  • Tasks or actions to be performed,
  • Inter-function relationships,
  • Hardware and software functional relationships,
  • Performance constraints,
  • Interface requirements including identification
    of potential open-system opportunities
  • Unique hardware or software
  • Verification requirements

Functional
Physical
Operational
102
Physical View for the Requirements Analysis
  • Configuration of System
  • Interface descriptions,
  • Characteristics of displays and operator
    controls,
  • Relationships of operators to system/ physical
    equipment,
  • Operator skills and levels to perform functions.
  • Characterization of Users
  • Handicaps (special operating environments),
  • Constraints (movement or visual limitations).

Operational
Physical
  • System Physical Limitations
  • Physical limitations (capacity, size, weight),
  • Technology limitations (range, precision, data
    rates, frequency, language),
  • Government Furinished Equipment (GFE),
  • Commercial-Off-the-Shelf (COTS),
  • Nondevelopmental Item, reusability reqs
  • Necessary or directed standards.

Functional
103
Example RE Process (INCOSE defined)
104
Example RE Process
Capturing Source Requirements
Concept of Operations Definition
Define/Derive/Refine Functional/Performance Requir
ements
Requirements Allocation And Traceability
Development of Spec Tree And Specifications
105
Capturing Source Requirements
Capturing Source Requirements
Concept of Operations Definition
Define/Derive/Refine Functional/Performance Requir
ements
Requirements Allocation And Traceability
Development of Spec Tree And Specifications
106
Preperation for Capturing Source Requirements
  • Empower a systems analysis team
  • Assign experienced Systems Engineer(s) to lead
    the team.
  • Assign experienced team members
  • Establish the form of the design decision
    database mechanisms and any supporting tools.
  • Obtain necessary SE tools.
  • Complete trainings.
  • Define the formats of the output deliverables
    from this function to permit the definition of
    any database schema tailoring which may be needed.

107
Capturing Source Requirements
Inputs
Methods
  • Customer Conversations
  • Surveys
  • Existing Concepts
  • Requirements Derivation
  • Requirements
  • New or updated customer needs,
  • Mission Objectives
  • Measures Of Effectives
  • Technical Performance
  • Utilization Environment
  • Constraints
  • Technology base
  • Contractually cited documents
  • Records of meetings
  • Conversations with the customer.

Outputs
  • Derived Requirements
  • Traceability matrix
  • Issues
  • Issue Resolutions
  • Requirements Decision Database
  • System Requirements Document (SRD)

Capturing Source Requirements
  • Decision Database Tools

Tools
108
Activities for Capturing Source Requirements
Organizing the Effort
Initializing the Database
Identifying Issues
Generation of the System Requirements Document
109
Organizing The Effort
Organizing the Effort
  • Establish Team,
  • Identify procedures and standarts for management
    and communication
  • State the objectives of the program
  • Assemble and prioritize source documents
  • Prepare work environment, access rights and
    access boundaries for team
  • Determine work breakdown and responsibilities

Initializing the Database
Identifying Issues
Generation of the System Requirements Document
110
Initializing the D
About PowerShow.com