sİstem mÜhendİslİĞİ gereksİnİm mÜhendİslİĞİ

Mart 2012, Ders 4, Sürüm1 1

ÖMER ERTEKİN, PSCONSULTECH

SİSTEM MÜHENDİSLİĞİ

GEREKSİNİM MÜHENDİSLİĞİ




GÜNDEM

GEREKSİNİM NEDİR

GEREKSİNİM YÖNETİMİ

SÜREÇ



GEREKSİNİM NEDİR

Definition: “Something that governs what, how well, and under what conditions a product will achieve a given purpose.” EIA 632 V. 1.0 1998

Defines WHAT and not HOW

Must be based on concept of operations

Requirements must state

What is to be done

How well it is to be done

Under what conditions it is to be done



GEREKSİNİM NEDİR

Requirement

A condition or capability that must be met or passed by a

system or a component to satisfy a contract, standard,

specification, or other formally imposed document… IEEE Standard Glossary, 1983

Requirement management

The identification, derivation, allocation, and control in a

consistent, traceable, correlatable, verifiable manner of all the

system functions, attributes, interfaces, and verification

methods that a system must meet including customer, derived

(internal), and specialty engineering needs Northrop Systems Engineering Development Policy Manual



FARKLAR

Requirements Development

Eliciting, identifying, collecting Functional decomposition and analysis Derived requirements Allocation Validation Verification requirements Finding a workable set

Requirements Management

Baselines and changes Traceability Assigning responsibility and authority Requirements quality Risk analysis Consistency with project work



TÜRETİLMİŞ GEREKSİNİM

Derived requirement

• Those characteristics typically identified during synthesis of

preliminary product or process solutions and during related trade

studies and verifications. They generally do not have a parent

function and/or performance requirement but are necessary to

have generated system elements that accomplish their intended

function

MIL-STD-499B (Draft)

• A requirement that (a) is a flowdown or secondary allocation of a

contractual requirement, or (b) a design constraint not directly

traceable to a contract requirement (e.g., tooling, assembly,

support, lessons learned, etc.)

F/A-18 Requirements Management



Linkage Example

A derived requirement results from analysis of a higher level requirement.

Examples:

High level requirement: “Door when closed shall prevent outside air from

entering the room at a rate greater than 10 cc per hour.”

Derived requirement: “Tolerance between door and door frame shall be

no greater than .1 inches.”

Linked to the original requirement and an analysis of the door

leakage.

Derived

requirement

Original

Requirement

Analysis



GEREKSİNİM KAREKTERİSTİKLERİ

Requirement type

Primary (explicit) or derived

Requirement text

Compliance level

Mandatory, goal, information, etc.

Requirement application

Program parameter: design,task/process, compliance

Product parameter: qualitative vs quantitative

Status

Ownership/accountability

Relationship to other elements (i.e., functions, components,

change notices, etc)



GEREKSİNİMLER-ZORLAYICILAR



GEREKSİNİMLER-ZORLAYICILAR

Düzenlemeler Üst Seviye

Spekler Standartlar

What Drives

Requirements

Müşteri ve Kullanıcı

İhtiyaçları ve Beklentileri

Sınırlamalar

Maliyet

Takvim

Teknik Uygulanabilirlik

Mevcut

Sistem

Ve

Süreçler



PROBLEMLER

Stakeholders (sources of requirements) don‟t know what they really

want ;

and may express unrealistic requests

Stakeholders express requirements in their own terms;

assuming knowledge of domain-specific terms and concepts

Different stakeholders may have conflicting requirements

Organisational and political factors may influence the system

requirements;

including a manager‟s personal interest...

The requirements change during the analysis process, and new

stakeholders may emerge;

e.g. because of restructuring in the Client‟s organisation, changes in

management or economic scenario



İYİ BİR GEREKSİNİM

Each individual requirement should be:

Correct – Technically and legally possible

Complete – Express a whole idea or statement

Clear – Unambiguous and not confusing

Consistent – Not in conflict with other requirements

Verifiable – Can be determined to meet the requirement

Traceable – Uniquely identified and can be tracked

Feasible – Accomplished within cost and schedule

Modular – Can be changed without excessive impact

Design independent – Does not pose a specific

implementation solution



Is Each Requirement

Necessary

Examine (and Document?) each Requirement

Assumptions

Why it is necessary

What is the cost impact

Prioritize the requirement

Maintain the lineage



Is Each Requirement

Achievable

Technical, Schedule and Cost Considerations

Get the facts right

Place in a risk pool until fully analyzed

•Remember 49% of requirement errors are due to incorrect facts



Is each Requirement

Verifiable

Subjective requirements are not verifiable

Look for words like: Maximize, minimize, support, adequate, but

not limited to, user friendly, easy, sufficient

Determine how each requirements will be verified as it is

written

test, „shall be .3 seconds‟

demonstrate, „shall be capable of simultaneous viewing‟

analyze, „ MTBF shall be 1 day‟

Inspect, „shall be green‟

•Subjective Requirements from the customer must be converted into achievable

and agreed to Requirements



Is Each Requirement

Clearly Written

Single Thought

Concise

Simple sentences

One subject one verb one

object

•Example: „shall provide a Data base‟

•Ask yourself - Why? Because:

•I need traceability between requirement levels

•I need to add capability to add attributes to

requirements

•I need to be able to sort the requirements

•I need to be able to filter the requirements

•The Data Base becomes a program element which has

requirements associated with it.

• Stand-alone

• Unambiguous

• What not How

• Forcing a design that is not needed

• Forcing a design does not meet the needs

•Example: „ shall be stowed while underway‟

•This is an operational requirement not a system requirements

•Should be: „shall provide a stowage environment‟

•The system shall provide …

•The system shall be capable of …

•The system shall weigh …

•The xyz subsystem shall provide … use acronyms

•Ugly and clear is better than beautiful

and ambiguous



Improving Requirements, Case 1

Capability: “Verb Noun” Example: Transport personnel safely over land. Capability: “Verb Noun” Example: Transport personnel safely over land.

Requirement: “Noun shall verb.”

Example: The car shall stop within 100 feet at 50 mph, weigh less than 3000 lbs, and be green.

Functional (what) Performance (how well) Physical, Design, or Constraint

Capabilities

Functions (SSDD/SS/SDD)

Components

Requirements

Capability: “Verb Noun” Example: Transport personnel safely over land.




Function: “Verb Noun,” “Verb-ing,” or “Verb.” Examples: Stop Car, Stopping, or Stop.

Capability: “Verb Noun” Example: Transport personnel safely over land.




Function: “Verb Noun,” “Verb-ing,” or “Verb.” Examples: Stop Car, Stopping, or Stop.

Component: “Noun.” Example: Brake.




• Requirement: “The pilot and/or co-pilot shall also be able to hear or see a visible

or audible caution/warning signal in case of emergency, hazard, etc.”

• Problems

– Multiple requirements. (Pilot/co-pilot see/hear)

– What emergency, hazard, etc. conditions?

– Defining a solution with visible or audible warning?

– What are pilot/co-pilot able to see/hear?

– What do you verify?

• Better

– 1. The system shall provide a caution/warning signal to the pilot in case of

emergency or hazard conditions defined in Appendix A. 2. Similar for co-pilot.

– If we insist on specifying the type of signal: The system shall provide an X dB

audible (Y micron visible) caution/warning signal to the pilot in case of emergency or

hazard conditions defined in Appendix A. Similar for co-pilot. Signal duration?




• Requirement: “The user shall be notified with a low battery warning lamp

light when the voltage drops below 3.6 volts and the current workspace or input data

shall be saved.”

• Problems

– Multiple requirements. (Notify and save)

– Defining a solution with warning lamp light?


• Better

– 1. The system shall provide a signal when the voltage drops below 3.6 volts.

– 2. The system shall save the current workspace data when the voltage drops below

3.6 volts.




• Requirement: “The crew shall always hear the smoke detector alarm

when smoke is detected unless the alarm is being tested or suppressed.”

• Problems

– Subjective wishful thinking - “always hear”

– Loophole for escape - “unless”


• Better

– 1. The smoke detector shall provide an alarm to the crew when smoke is detected.

– 2. The crew shall be able to suppress the smoke detector alarm when the detector is

in the “Test” mode.



•Improving Requirements, Case 4

• Requirement: “Provided that the designated input signals from the

specified devices are received in the correct order where the system is

able to differentiate the designators, the output signal shall comply with

the required framework of section 4.4.5 to indicate the desired input

state.”

• Problems

– Rambling long sentence


• Better

– 1. The output signal shall comply with section 4.4.5.

– 2. The output signal shall provide the input state.




• Requirement: “The user shall be provided with a user-friendly front

end for operating the system.”

• Problems

– Vague terminology


• Better

– 1. The system shall provide menus and dialog boxes to aid the user in operating the

system. Or,

– 2. The system shall provide step-by-step instructions to guide users in starting

operations.



GEREKSİNİM YÖNETİM SÜRECİ-1

- Requirements Validation

- Functional Verification

- Verification/Validation

- Systems Analysis

- Monitor & Control

Requirements

Analysis

- Systems Analysis

- Requirements Validation

Define

Customer

Expectations

Define

External

Constraints

1 2 3

4

6 7 8 9

10 11

1213 14 15

16

Define

Modes of

Operations

Define

Human

Factors

Define Life-Cycle

Process

Concepts

Define

System

Boundaries

Define

Interfaces

Define

Functional

Requirements

Define

Technical

Performance

Measures

Define

Utilization

Environments

Define

Performance

Requirements

Define

Design

Characteristics

7 8 9

13 14

Physical

View

Operational

View

Establish

Requirements Baseline

Functional

View

15

- Functional Analysis

5

Define

Operational

Scenarios

Define

Measures of

Effectiveness

Define

Project &

Enterprise

Constraints




TASK DESCRIPTION INPUT OUTPUT WORK

PRODUCT

1. Define

Customer

Expectations

Elicits, identifies, prioritizes,

defines and quantifies customer

expectations and constraints for

the system, and provides status

on a regular basis to facilitate

review and coordination

Marketing information

Customer order

Recognized marketing

opportunity

Direct customer comm.

Higher level system req.

Project governing

documents (e.g., SOW,

ORD, TRD, Proposals)

Customer

functional req.

Performance req.

Natural/induced

Environ.

Constraints

Stakeholder

baseline

QFD Needs

Matrix

Needs

issues/conflicts

Needs Statement

Mission Goals &

Objectives

Draft

requirements

Operational

Concepts

2. Define

Project &

Enterprise

Constraints

Identifies and defines project and

enterprise constraints that impact

design solutions

Approved specs from

prior SE applications

Updated tech. & project

Plans

Team structure

Avail. Automated tools

Control mechanisms

Required metrics

Management decisions

Enterprise standards

Policies & procedures

Process capabilities

Physical, financial, & HR

allocations

Program

constraints

Organization

concept

Tool selections

Design

requirements

Market-segment

description

Statement of

Work (SOW)

Assumptions

Guidelines &

Project

Constraints

System cost

objectives





PRODUCT

3. Define

External

Constraints

Identifies and defines external

constraints that impact design

solutions or SE process

Public/international laws

& regulations

Technology base

Industry/international &

general specs/stds

Competitor capabilities

Program

constraints

Design

requirements

Assumptions

Guidelines &

External

Constraints

4. Define

Operational

Scenarios

Identifies and defines operational

scenarios that define range of the

anticipated uses of system

products

QFD

Mission goals &

objectives

Mission needs

Analyses

Trade study

results

Simulations

Reference

Missions

Operational

Concept Report

(OCR)

5. Define

Measures of

Effectiveness

Defines system effectiveness

measures that reflect overall

customer expectations and

satisfaction

Customer functional req.

Performance req.

Criteria for:

performance,

safety, operability,

reliability,

maintainability &

others

Measures of

Effectiveness

(MOE)

QFD

Requirements

Matrix

6. Define

System

Boundaries

Defines which system elements

are under design control and

outside of control, and expected

interactions among system

elements under control, and

external and higher-level and

interacting systems outside the

system boundary

Contract SOW

Customer functional req.

Reference missions

Operational concept

Analyses

Trade studies

Criteria for performance

& operability

System definition System External

Interface Studies





PRODUCT

7. Define

Interfaces

Defines the functional and design

interfaces to external and higher-

level and interacting systems,

platforms, and products in

quantitative terms.

System definition

Analyses

Trade studies

Criteria for operability &

maintainability

Description of

mechanical,

electrical, thermal,

data, procedural,

& other

interactions

Interface

requirements

8. Define

Utilization

Environments

Defines the utilization

environments (natural or induced)

for each of the operational

scenarios.

System Definition

Analyses

Location & condition

factors: Weather,

temperature ranges,

topologies, biological,

time, induced

Definition of

natural and

induced

environment

Environmental

Specification

9. Define Life

cycle Process

Concepts

Analyzes the outputs of tasks 1

through 8 to define life cycle

process requirements necessary

to develop, produce, test,

distribute, operate, support, train,

and dispose of system products

under development

System definition

Analyses

Trade studies

Criteria for operability

reliability &

maintainability

Costs

Schedules

Risks

Operational

concept

Disposal

concepts

System

maintenance and

support concepts

Feasibility

Assessment-Life

Cycle

10. Define

Functional

Requirements

Analyzes and defines, what the

system must accomplish or be

able to do

System definition

Operational scenario

Analyses

Trade study results

Expansion and Growth

provisions in system

requirements

Identification of

what system is to

do

Functional Flow

Analysis -

System Level

Functional

Mission Concept





PRODUCT

11. Define

Performance

Requirements

Defines the performance

requirements for each function of

the system to satisfy the system

measures of effectiveness

System definition

Operational scenario

Mechanical, electrical,

thermal, cost, risk data,

procedural interactions,

models

Quantified

performance

requirements

Performance

parameters

12. Define

Modes of

Operation

Defines the various modes of

operation for the system products

under development

Design requirements

Functional mission

Concept

Definitions of

normal,

contingency, &

error modes

Operational

Requirements

13. Define

Technical

Performance

Measures

Identifies the Technical

Performance Measures (TPMs)

that are key indicators of system

performance

Performance

Requirements

Design requirements

Identification of

key, Quantified

performance

criteria

Technical

Performance

Measures (TPM)

14. Define

Design

Characteristics

Identifies and defines required

design characteristics for the

system products under

development

Design requirements

Design sheets

System physical

description

System

characteristics

Applicable

Standards

15. Define

Human Factors

Identifies and defines human

factor considerations which will

affect operation of system

products under development

System definition

Functional mission

Concept

Identification of

human/system

interactions

Human System

Standards





PRODUCT

16. Establish

Requirements

Baseline

Forms a requirements baseline

that establishes the system

problem to be solved

Functional requirements

Performance

requirements &

constraints

Design requirements

Consolidated

aggregation of all

requirements &

constraints

System

Requirement

Documents

(SRD) or System

Specifications

(SSS)

Results of

Requirements

Reviews

Requirements

traceability matrix

(RTM)

System

requirements

baseline