Requirements Analysis for Land Force

1
Requirements Analysis for Land Force Command and
Control Information Systems
Canadian Forces Intensive Course in Software
Engineering Capt Tim Bergsma 28 Oct 99
2
Dilbert - Accurate depiction of life in DLR
3
System Requirements Analysis as Percentage of
Life Cycle Cost
4
Requirements Work - Reducing Long Term Risk
5
Aim and Scope
Aim to outline alternative methods for
conducting requirements analysis on Land Force
Command and Control Information System (C2IS)
projects.

• Scope
• Definitions
• The LF Command and Control Environment
• Information System Views
• Alternative Requirements Analysis Methods
• Other Areas to Research
• Characteristics of Good Methods
• Conclusions

6
Defining the problem is the most difficult part
of the system engineering process.
7
Definitions
Requirements How will I know one when I see one?

• Functional Requirement
• a description of what the system must do
• expressed independent of how they will be
  implemented, i.e. independent of technology
• Non-Functional Requirement
• a constraint
• describes a restriction on the system that
  limits our choices for constructing a solution to
  the problem

8
Definitions

• Operational Requirements
• operational distribution / deployment (where
  system will be used)
• mission profile - prime and alternate mission
  scenarios
• performance parameters - operating
  characteristics (accuracy, throughput, speed,
  etc.)
• utilization - duty cycles, system capacity
  used, etc.
• effectiveness - availability, reliability, etc.
• Operational life cycle
• environment - temperature, shock, vibration, etc.

9
Definitions

• Maintenance and Support Requirements
• levels of maintenance / responsibilities - who
  performs what maint tasks
• logistic support elements - test and support
  equipment, personnel, training, facilities, etc.
• effectiveness requirements - as pertain to
  support capability
• environment - environment in which maintenance
  and support will be carried out

10
Op Vs Maint and Sp Reqrs - Life Cycle Cost
11
Systems Approach
ENVIRONMENT
Objects (USERS)
Relationships
Activities
Inputs
Outputs
Other Systems
System Boundary
12
LF Command and Control Environment - C2S vs C2IS
COMMANDER

• Information Requirements (IRs)
• Information Exchange Requirements (IERs)

Provision of Information Management
EVER INCREASING AMOUNTS OF INFORMATION (Correct
information?)
13
(No Transcript)
14
Zachmann Information System Architecture - Views
Data View Data used by Users (Data Model)
Process View How users do their
job (Functionality)
Interface View Who users communicate with
(Interfaces)
Network View Data flow between users (Comms Sys)
System Owners (Scope)
Information System Scope (purpose and vision,
goals and objectives, costs and benefits)
System Users (Requirements)
Information System Requirements (WHAT the system
is and must do independent of technology)
System Designers (Specifications)
Information System Design (HOW the system will be
implemented using technology)
System Builders (Components)
Information System Components (the actual
technical implementation of the system)
15
Joint Application Design

• Fact-finding / Information Gathering Techniques
• Review existing documentation and files
• Site visits
• Observations of users in their work environment
• Questionnaires
• Interviews
• Prototyping
• Focus Groups, SME sessions - JAD
• JAD
• users, developers and other disciplines involved
  in the system development participate in 2-5 day
  workshops
• group is walked through a list of items or a
  scenario with the intent of achieving group
  consensus on requirements
• an experienced facilitator is key to achieving
  success

16
Mission Function and Task Analysis
Definition Phase
updating the baseline mission, function and task
analysis to reflect the proposed system - (i.e.
incorporation of the C2IS intothe C2S - as well
as anychanges to doctrine, procedures, etc.)
Analysis Phase
Deficiencies
Missions
Doctrine
Procedures
identifying decision support technologies (both
hardware and software) that may enhance
performance
Organization
Personnel
Training
conducting an analysis to allocate functions to
human, machine or both to achieve optimal
system performance (a function allocation)
Materiel
Communications
modifying the network model to reflect the
different configuration and technologies
Information systems
evaluating the impact of the system modifications
on the measures of performance and effectiveness
identifying and documenting requirements to
achieve optimal system performance (human and
machine combined)
OUTPUT - Reqrs for Proposed System
17
MFT Product - Reusable Requirements Model
Where are we today?
Where do we need to be tomorrow?
AS IS Model
TO BE Model
System Missions - Mission Scenarios - 3 levels
of FFDs
Human / Machine Function Allocation
Composite Mission Scenario - Task Inventory
(Access DB) and OSDs (SOLE IPME)
Update AS IS Model based on different
configurations / Technologies
SOLE IMPE Simulation (8 MOPE)
Evaluate impact based on C2S based on MOPE
(SOLE IPME)
C2S Deficiencies (Doctrine, Procedures,
Training, Personnel, Organization, Materiel)
C2IS Requirements to achieve optimal (improved)
C2S performance.
Update to reflect impact of new technology,
doctrine, etc. (This can be done very quickly)
Update to reflect new user needs, changed user
needs and improperly implemented user needs.
18
Mission Function and Task Analysis

• Problem areas
• has traditionally used structured modelling
• very structured process in which steps can
  seldom be skipped, thus getting to the As Is and
  To Be models can take a long time (Analysis
  Paralysis?)

19
Quality Function Deployment
Step 1 User requirements are solicited and
recorded Step 2 Requirements are converted to
technical product specifications that will
implement them. Step 3 Users identify the
strength of the relationship between the
requirements and the technical product
specifications. Step 4 Users prioritize or
weight the requirements. Step 5 Technical
product specifications are prioritzed by
multiplying results of steps 3 and 4. Some form
of Rapid Prototyping generally follows until user
acceptance is achieved.
20
House of Quality
2 Technical product specifications that
implement requirements (Hows)
3 Correlation Matrix Relationship between user
requirements and technical product
specifications
1 User Requirements (Whats)
4 Requirement priorities (Weighting)
5 Technical product specification priorities.
21
Quality Function Deployment

• Problem areas
• lack of analysis of the existing system to
  identify deficiencies
• does not identify improvement offered over
  existing system
• translation of House of Quality into
  requirements specification not a trivial step
• systems often require a hierarchy of matrices,
  which can become confusing

22
Rapid Application Development
Requirements Planning
User Design
Construction
Generally 3 - 12 month time limit (18 month max)
Cutover
23
Rapid Application Development
Requirements Planning High level managers and
knowledgeable users determine system requirements
in the context of business problems and business
areas. Specific systems are identified for
development. Developers and users then conduct
JAD sessions to identify system requirements.
User Design User and developers conduct
further JAD sessions using CASE tools to support
rapid prototyping of system design. Prototypes
are used to capture system requirements (no paper
based specifications). Construction Developers
use CASE tools to build the system. Users
validate the system. Cutover System testing,
user training and system delivery.
24
Rapid Application Development

• Problem areas
• lack of analysis of the existing system to
  identify deficiencies (provides little
  understanding of the organization and its
  associated business rules)
• does not identify improvement offered over
  existing system
• short term focus on fielding can harm long term
  plans for evolution and maintenance
• tends to focus on the internal functionality of
  the system being developed and ignore system
  interfaces

25
Other Methods to Research

• Semantic Object Modelling Approach (SOMA)
• combines RAD with Object Oriented Techniques
• commences with brief business process
  reengineering to eliminate inefficiencies in
  target business area
• develops OO models of requirements
• proceeds with a rapid prototyping main build
  phase
• main build phase has set time limit upon which
  decision of field or scrap must be made
• JAD applied throughout

26
Characteristics of a Good Requirements Analysis
Method

• some analysis of existing system (baseline) to
  identify deficiencies (i.e. determine what users
  really need as opposed to what they want)
• scenario based analysis - most demanding and
  most frequent missions
• multidisciplinary involvement throughout,
  especially end users
• fast - 18 month max
• produces model that can be maintained (i.e.
  adapted to meet changes in technology, work
  processes, etc.) - Evolutionary Development
• requirements are measurable in terms of the
  improvements their implementation will provide
  over the existing system (baseline) - if a
  requirements does not improve the exiting system
  why implement it?
• examine all views of the system - Data, Process,
  Interface and Network

27
Evolutionary Development
Requirements V1
Build V1
Field V1
Requirements V2
Build V2
Field V2
Requirements V3
Build V3
Field V3
28
Conclusions thus Far
Speed Cost Quality Pick 2