SİSTEM MÜHENDİSLİĞİ GEREKSİNİM MÜHENDİSLİĞİ · 2012. 4. 2. · Mart 2012, Ders 5,...

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

ÖMER ERTEKİN, PSCONSULTECH

SİSTEM MÜHENDİSLİĞİ

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

II




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



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



DOĞRULAMA ve GEÇERLİ KILMA

Requirements

Product

Verification

Are the requirements right? Do

they meet the basic quality

criteria (e.g., correct, complete)

Is there objective evidence that the

product satisfies the requirements?

Validation

Are the requirements the right

requirements, i.e., do they

properly represent the customer

need?

Does the product, when operated by

representative operators, in the

representative operational

environment, satisfy the customer

needs?



Improving Requirements, Case 1

• 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.



USE CASE DIAGRAMS USE CASE, ACTOR

A ‘Use case’ yields an observable

result to an ‘Actor’.

Use Cases describe the functionality

of a system in terms of how its users

use that system to achieve their

goals.

An actor is used to represent the role

of a human, an organization, or any

external system that participates in

the use of subject system.



USE CASE DIAGRAMS RELATIONSHIP

•Inclusion: The inclusion relationship allows one use case referred to as “base use

case”, to include the functionality of another use case, called the included use case

as a part of its functionality when performed.

•Extension: A “use case” can extend a “base use case” using the extend

relationship. The extending use case is a fragment of functionality that is not

considered part of the normal base use case functionality.



USE CASE DIAGRAMS

•13

//upload.wikimedia.org/wikipedia/commons/1/1d/Use_case_restaurant_model.svg



USE CASE DIAGRAMS

•14

•“Actors” can be classified using

standard generalization

relationship. A specialized actor

participates in all the use cases

that the more general actor

participates in.



USE CASE DIAGRAMS

uc [Package] UseCaseDiagramsPkg [Use Cases for SpaPoolTempControl System]

OperatorOperator

Set up system

Operate

system

Adjust set point

and set or

unset low-temp

alarm

Tune control

algorithm

Calibrate

sensor

Activate or

deactivate

system

Enter or exit

standby modeControl

temperature

and alarm

«inc lude»«inc lude»

«extend» Handle alarm«extend»

•Scenarios for the general

use case are also scenarios

of the specialised use case



USE CASE DIAGRAMS

•Actors associated with a general use case do not participate in

any scenarios solely described by a specialized use case.



USE CASE DIAGRAMS •GPS Start-up (extension or classification ?)

•The hot start is when the GPS device remembers its last calculated position and the

satellites in view, the almanac used (information about all the satellites in the

constellation), the UTC Time and makes an attempt to lock onto the same satellites and

calculate a new position based upon the previous information. This is the quickest GPS

lock but it only works if you are generally in the same location as you were when the

GPS was last turned off.

•The warm start is when the GPS device remembers its last calculated position, almanac

used, and UTC Time, but not which satellites were in view. It then performs a reset and

attempts to obtain the satellite signals and calculates a new position.

•The receiver has a general idea of which satellites to look for because it knows its last

position and the almanac data helps identify which satellites are visible in the sky. This

takes longer than a hot start but not as long as a cold start.

•And finally – the cold start is when the GPS device dumps all the information, attempts

to locate satellites and then calculates a GPS lock. This takes the longest because there

is no known information



USE CASE DIAGRAMS

•Driver Information System Use Cases



USE CASE DIAGRAMS

•Top Level Use Cases for the Hybrid SUV



USE CASE DIAGRAMS

•Operational Use Cases for “Drive the Vehicle”

SİSTEM MÜHENDİSLİĞİ GEREKSİNİM MÜHENDİSLİĞİ · 2012. 4. 2. · Mart 2012, Ders 5,...

Documents

Transcript of SİSTEM MÜHENDİSLİĞİ GEREKSİNİM MÜHENDİSLİĞİ · 2012. 4. 2. · Mart 2012, Ders 5,...