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