Requirements Engineering

Benzer belgeler
Requirements Engineering

Requirements Engineering

Yazılım Gereksinimlerinin Görsel Çözümlemeleri: UML (UnifiedModeling Language) Birleştirilmiş Modelleme Dili

Öğretim planındaki AKTS Ulusal Kredi

Chapter 5 Sistem Modelleme. Lecture 1. Chapter 5 System modeling

YZM 2108 Yazılım Mimarisi ve Tasarımı

TÜMLEŞİK MODELLEME DİLİ. UML (Unified Modeling Language)

İTÜ DERS KATALOG FORMU (COURSE CATALOGUE FORM)

EBE-368 Veri Tabanı Yönetim Sistemleri Veri Tabanı Tasarımı

Gereksinim Mühendisliği (SE 560) Ders Detayları

Veritabanı Yönetim Sistemleri (Veritabanı Kavramı) İş Kuralları ve Veri Modelleri

BÖLÜM 1 YAZILIM TASARIMINA GİRİŞ YZM211 YAZILIM TASARIMI. Yrd. Doç. Dr. Volkan TUNALI Mühendislik ve Doğa Bilimleri Fakültesi / Maltepe Üniversitesi

Veritabanı Yönetim Sistemleri (Veritabanı Kavramı) Veri Modelleri

NESNEYE YÖNELİK PROGRAMLAMA Unified Modelling Language (UML) Bütünleşik Modelleme Dili

Bölüm 2 Varlık-İlişki Veri Modeli: Araçlar ve Teknikler. Fundamentals, Design, and Implementation, 9/e

SOFTWARE ENGINEERING Ders İzlence Formu. Kodu:CSE400 Dersin Adı: SOFTWARE ENGINEERING Toplam Saat

Software Requirements Specification

Kavramsal Tasarım. Veritabanlarına Giriş Dersi

Görünümler ve Ötesi Yaklaşımıyla Radar Yazılım Mimarisi Dokümantasyonu Tecrübeleri. Ali Özzeybek M. Devrim Tokcan Murat Tuncer

Eylül 2007 de v1.0 ı yayınlanan SysML sayesinde endüstri mühendislerinin de ihtiyacı karşılanmış oldu.

Business Intelligence and Analytics Principles and Practices: Charting the Course to BI and Analytic Success

YZM211 YAZILIM TASARIMI

NESNEYE YÖNELİK PROGRAMLAMA. Yrd.Doç.Dr. Zeynep ORMAN

Inventory of LCPs in Turkey LCP Database explained and explored

Teknoloji Servisleri; (Technology Services)

Kullanım Durumu Diyagramları (Use-case Diyagramları)

YAZILIM MODELLEME VE TASARIM

YAZILIM MİMARİLERİ DERSİ BİLGİSAYAR PROGRAMCILIĞI

MVP, Observer ve Mediator Örüntüleri ile Yeniden Kullanılabilir Uygulama Bileşenleri Geliştirme

Maltepe Üniversitesi Bilgisayar Mühendisliği Bölümü BİL 203 Veri Yapıları ve Algoritmalar I

Yaz.Müh.Ders Notları #6 1

Yazılım Gereksinimleri Mühendisliği (SE 221) Ders Detayları

CENG 302 Yazılım Mühendisliği Yazılım Mimarisi - Devam. Alper UĞUR

design)1980li ve 1990lıyıllar Birleştirilmiş Modelleme Dili (Unified Modeling Language-(UML) yazılım geliştirme araçlarının temelidir.

İçindekiler. Okuma lisansı info acar, için verilmiştir. Çoğaltılması ve dağıtılması yasaktır.

BM208- Nesneye Dayalı Analiz ve Tasarım. Sunum 7

Software Design Document

SOFTWARE ENGINEERS EDUCATION SOFTWARE REQUIREMENTS/ INSPECTION RESEARCH FINANCIAL INFORMATION SYSTEMS DISASTER MANAGEMENT INFORMATION SYSTEMS

Unified Modeling Language

YAZILIM MODELLEME VE TASARIM

GEREKSİNİM ANALİZİ SÜRECİ VE ÖNEMİ

Yazılım Gereksinimleri & Sistem Gereksinimleri (tekrar)

SİSTEM MÜHENDİSLİĞİ OPERASYONEL KONSEPT

Ferhat ERATA. Geylani KARDAŞ

İSTANBUL ÜNİVERSİTESİ MÜHENDİSLİK FAKÜLTESİ BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜMÜ BİTİRME PROJESİ 1. GetFit (Spor Merkezi) Uygulaması

Düzenlenmesi, Program Yazmak ve Çalıştırmak. Alt Programlar, Modüller ve Arşiv. Fonksiyonları

Nesne ve Sınıf Kavramları

Unified Modeling Language

DERS BİLGİ FORMU DERS BİLGİLERİ. Türü Zorunlu/ Seçmeli DERS PLANI

Model Güdümlü Geliştirme ile Gömülü Kaynakların Yönetimi

Sınıf Diyagramları Amaç: Sınıf Diyagramları Nasıl Çizilir?

Nesneye Dayalı Programlama

Ferhat Cem CİHAN-Bilgisayar Mühendisliği Emre BALCI-Bilgisayar Mühendisliği

C++ Dersi: Nesne Tabanlı Programlama

Beşevler Mah. Aktaş Sok.Pars İş Merkezi. No:5 Kat:4 Büro:8 Nilüfer/Bursa Tel: Faks: e-posta:

YMT 312-Yazılım Tasarım Ve Mimarisi MimariTasarım

ARDIŞIL DİYAGRAM YAPI DİYAGRAMI. Sistem Analizi ve Tasarımı Dersi

Yazılım Süreçleri Software Processes

Computer Engineering Department LAB 1 WORKSHEET

Oluşturmak istediğimiz OU ye bir isim veriyoruz. Name kısmına ISTANBUL yazıyoruz,

Bilgi Sistemleri Tasarımı (SE 503) Ders Detayları

Yazılım Mühendisliği Bölüm - 4 Sistem Analizi. Cengiz GÖK

Veritabanı Yönetim Sistemleri (Veritabanı Tasarımı) Varlık İlişki Modeli

<Ekip Adı> <Proje Adı> Yazılım Gereksinimlerine İlişkin Belirtimler. Sürüm <1.0>

Senaryoların Gerçeklenmesi (Use-Case Realization)

Veri tabanı tasarım prosesi genel şeması Temel Kavramlar

İÇİNDEKİLER CONTENTS

Inheritance. Inheritance (turetim)

Ders Adı Kodu Yarıyılı T+U Saati Ulusal Kredisi AKTS

e-tartı LTR3 Firmware Upgrade Yazılım Güncelleme Moduler Connection LTR3 Firmware Upgrade / LTR3 Yazılım Güncelleme v1.0.

MÜHENDİSLİK FAKÜLTESİ / ENSTİTÜSÜ / YÜKSEKOKULU BİLİŞİM SİSTEMLERİ MÜHENDİSLİĞİ BÖLÜMÜ /ABD LİSANS PROGRAMI - 2 ( yılı öncesinde birinci

Yazılım Geliştirme Genel Tanımlar

Eclipse, Nesneler ve Java 2 Java Nereden Çıktı? 2

UNICASE.... kapsamlı bir CASE* aracı. *

IDENTITY MANAGEMENT FOR EXTERNAL USERS

MÜHENDİSLİK FAKÜLTESİ / ENSTİTÜSÜ / YÜKSEKOKULU BİLİŞİM SİSTEMLERİ MÜHENDİSLİĞİ BÖLÜMÜ /ABD LİSANS PROGRAMI - 1 ( yılı ve sonrasında birinci

Geleneksel Yazılım Mühendisliğinden Alana Özel Yazılım Mühendisliğine Doğru

Veritabanı Yönetim Sistemleri (Veritabanı Tasarımı) Varlık Bağıntı Modeli

Yazılım Mimari Tasarımından Yazılım Geliştirme Çatısının Üretilmesinde Model Güdümlü Bir Yaklaşım

YAZILIM MÜHENDİSLİĞİ - 2

Yazılım Mühendisliğine Giriş 2018 GÜZ

Senaryoların Gerçeklenmesi (Use-Case Realization)

Kullanım Eşlemesiyle Mimari Görünümlerin Đrdelenmesi Üzerine Bir Örnek Çalışma

«BM364» Veritabanı Uygulamaları

LOGO. Kamuda e-devlet Uygulamaları ve Endüstri Mühendisliği. Ömer KILIÇ. Bilgi Teknolojileri Direktörlüğü

NESNEYE YÖNELİK TASARIM SÜRECİ

T.C. ERCİYES ÜNİVERSİTESİ MÜHENDİSLİK FAKÜLTESİ BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜMÜ EĞİTİM ÖĞRETİM YILI DERS KATALOĞU

Doç. Dr. Cüneyt BAYILMIŞ

Veritabanı Yönetim Sistemleri (Veritabanı Tasarımı) SQL (Structured Query Language)

VERİ TABANI YÖNETİM SİSTEMLERİ Melih BÖLÜKBAŞI

Özgeçmiş Burak ÖZ. Telefon: (90)

Dr. Aysın Yeltekin. EST Enerji

Nesneye Dayalı Yazılım Geliştirme. Her iterasyon sonunda sistem istenene yaklaşır. Nesneye Dayalı Yazılım Geliştirme

Klasik Dosya Sistemi. (Yomralıoğlu, 2002)

Veritabanı Tasarımı Ve Yönetimi

COĞRAFİ BİLGİ SİSTEMLERİ İLERİ SEVİYE EĞİTİMLERİ BUILDING GEODATABASE EĞİTİMİ

Ön program (elin yazma hizi ile): 0 - Genel hata: C kastedip C++ demek 1 - C++ kutuphanesi kullanmak!= C++ programlamak 2 - Class kutuphanesi

Varlık davranış modeli: Bu aşama her entity ye etki eden durumların tanımlandığı, modellendiği ve dokümante edildiği süreçtir.

Tasarım Örnekleri. Senaryoların Gerçeklenmesi (Use-Case Realization)

Transkript:

Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde 1

Fundamentals of RE Chapter 4 Requirements Specification & Documentation 2

Chap.1: RE products and processes alternative options Chap. 2: Elicitation techniques Chap. 3: Evaluation techniques consolidated requirements start documented requirements agreed requirements Chap. 4: Specification & documentation techniques 3

Doğal Dildeki Yapısal Disiplinli Dokümantasyon: Gereksinimlerin Dokümantasyonu için Global Kurallar Gruplama Kuralları Çözülecek problemle ilgili ortak özelliklerin (kriterlerin) belirlenerek, ilgili tüm bildirimlerin aynı bölümde dokümantasyonunun yazılmasıdır. Bunlar: Sistemin amacı (system objective) Sistem bileşeni (system component) Görev yapılacak iş (task) Kavramsal nesne (conceptual object) Yazılım özelliği (software feature). şeklinde düzenlenebilir. Gereksinimler Dokümantasyonunu stadartlaşt olarak oluşturan global şablonlar farklı düzenlenir. Örneğin: Alana-özgü(domain-specific), organizasyona özgü (organization-specific), şirkete özgü (company-specific) 4

1.Giriş ( Introduction) 1.1 gereksinimler Dok. Amacı (RD purpose 1.2 Ürün Kapsamı (Product scope) 1.3 Tanımlamalar, Kısaltmalar (Definitions, acronyms, abbreviations) 1.4 Kaynaklar (References) 1.5 Genel Bakış (Overview) 2. Genel Betimleme(General Description) 2.1 Ürün Perspektifi(Product perspective 2.2 Ürün Fonksiyonları (Product functions 2.3 Kullanıcı Karakteristikleri (User characteristics 2.4 Genel Kısıtlamalar( General constraints 2.5 (Tahminler&Bağlılıklar(Assumptions & Dependencies) 2.6 Gereksinimlerin Bölüştürülmesi (Apportioning of requirements) 3. Spesifik Gereksinimler (Specific Requirements Gereksinimlerin Belirlenmesinde IEEE Std-830 Şablonu domain, scope, purpose of system-to-be glossary of terms elicitation sources sw-environment boundary: interfaces with users, devices, other sw functionalities of software-to-be assumptions about users development constraints (hw limitations, implem platform,...) environment assumptions (subject to change) optional, deferable reqs. 5

3. Spesifik Gereksinimler (Specific Requirements) 3.1 Fonksiyonel Gereksinimler (Functional requirements) 3.2 Dışsal Arayüz Gereksinimleri (External interface reqs) 3.3 Performance reqs 3.4 Tasarım Kısıtları (Design constraints) 3.5 Yazılım Kalite Öznitelikleri (Software quality attributes) 3.6 Diğer Gereksinimler (Other requirements Ekler (Appendices) indeks (Index) Gereksinimlerin Belirlenmesinde IEEE Std-830 Şablonu alternative templates for specific types of system NFRs: interoperability NFRs: time/space performance NFRs: development reqs. NFRs: quality reqs. NFRs: security, reliability, maintainability NFRS: Fonksiyonel olmayan gereksinimler 6

Gereksinimlerin Dokümantasyonunda Diyagram Şeklinde Görsel Notasyonların Kullanımı Doğal dilde dokümantasyonu yapılmış gereksinimlerin görsel olarak ta ifade edilmesidir. Geliştirilecek sistemin hedefleri ifade edilir. (to-be) Grafiksel Gösterim geliştirme aşamasında iletişimi kolaylaştırır, problemin çözümüne genel bir bakış sağlar Semi-formal (Yarı biçimsel) betimleme de oluşturur. 7

Geliştirilecek Sistem Kapsamı 1: «Context» Diyagramları Sistemin bileşenleri (system components) ve onların arayüzlerini betimler Sistemin yapısı tanımlanır. Sistem nedir? Ne değildir? cevaplanır. Her bileşenin çevresi (environment of each component): komşular (neighbors), arayüzler (interfaces) Handbrake Controller button Pressed handbrake.sw pedal Pushed motor.regime Car system component Driver connection through shared phenomenon (data, event) 8

«Context» Diyagramları «Context» Diyagramlarında bir bileşen (component) diğer tüm bileşenlerle etkileşime girmeyebilir. «Context» diyagramı her bileşenin doğrudan ilişkili olduğu çevresinin (environment) basit bir görselleştirmesini ifade eder. «Context Diyagramı» kısaca bir bileşenin, bileşenin arayüzleri ile etkileşimde olduğu komşu bileşenleri kümesidir. 9

Sistem Kapsamı 2: Problem Diyagramları Context diyagramının daha ayrıntılı ifade edilmesidir. Machine Bileşen paylaşılan bir olguyu (shared phenomenon) kontrol eder. Bileşen, oluşturulacak makineyi temsil eder. Bileşenler gereksinimler tarafından etkilenir. Handbrake Controller HC! handbrake.sw C! motor.regime Car DR! {pedalpushed, buttonpressed} {pedalpushed, Driver buttonpressed} constrains {BrakeActivation, BrakeRelease} controlling component refers to Handbrake shall be... activated if the brake button is pressed, released if the acceleration pedal is pushed requirement 10

Kavramsal Yapılar (Conceptual structures): Varlık-İlişki Diyagramlar (Entity-Relationship Diagrams) Kavramsal imgelerin bildirimi ve onların yapılandırılması Varlık (Entity) : kavram örnekleri sınıfı (class of concept instances )... Farklı kimlikler (having distinct identities) Ortak özelliklerin paylaşımı (sharing common features (attributes, relationships)) e.g. Meeting, Participant N-li ilişkiler (N-ary relationship Çokluk (Multiplicity), varlık örneklerinin min&max sayısı e.g. Invitation linking Participant and Meeting Öznitelik (Attribute) : bir ilişki ya da bir varlığın özelliğinin bir değer aralığı vardır. e.g. Date of Meeting 11

specialization Important Participant Preferences Email Participant Name Address Email Varlık-ilişki Diyagramı Örneği Entity-relationship diagram invitedto Normal Participant role Invitation 1..* 0..* constraintsfor binary relationship Constraints excludeddates preferreddates Invites constraintsfrom attributes of relationship Meeting Date Location 1..* 1..1 Initiator entity attribute Requesting daterange withwhom A meeting invites at least 1 up to an arbitrary number of participants Çokluklar (multiplicities) gereksinimleri ya da alan özelliklerini ifade edebilir. prescriptive & descriptive tanımlamalar arasında fark yoktur 12

Varlık İlişki Diyagramları Entity-Relationship Diagrams Varlıkların (entities) özelleştirilmesi: Kavram örneklerinin alt sınıfı spesifik özellikleri ile (öznitelikler (attributes) ve ilişkiler (relationships) ile karakterize edililir. İlişkiler ve öznitelikler varsayımsal olarak (default) alt sınıflardan miras alınır. Üst sınıflarda (super classes) yapısal olan ortak özellikleri saptamada güçlü bir yapısal mekanizma oluşturulur. e.g. ImportantParticipant, with specific attribute Preferences Invitation, Constraints miras ilişkileridir (inheritance relationship) Address ise özniteliktir (attribute) (Email of ImportantParticipant varsayımsal miras özelliğini miras alır inhibits default inheritance) 13

Varlık İlişki Diyagramları Entity-Relationship Diagrams Diyagram açıklamaları(diagram annotations): elemanların kesin olarak tanımlanması Böylece yapılabilecek bazı temel hataların önüne geçilmiş olacaktır. e.g. annotation for Participant: (katılımcıya açıklama) «Kişinin toplantıya belli bir rolü gerçekleştirmek üzere katılacağı beklenir. Toplantı başladığında kişi sistemde görünür ve bittiğinde artık sistemde kaydı bulunmayacaktır». 14

Use Case Diyagramı Örneği environment component operation interaction Initiator variant operation Check Request <<extend>> Unauthorized Deny Request Ask Constraints Collect Constraints Participant Participant every thing good in UML is not new, every thing new in UML is not good Determine Schedule <<include>> Resolve Conflicts Scheduler Merge Constraints operation performer software component Conflict Resolver suboperation 15

Olay izleme Şeması (Event trace diagram) Sequence Diyagram in UML interaction event attribute component instance Initiator meetingrequest (daterange, withwhom) OK-request Scheduler Participant? constraints! constraints OK-constr scheduledetermination notification (date, location) notification (date, location) timeline controls interaction monitors interaction self-interaction 16

Gereksinimleri Mühendisliğinde UML Birleştirilmiş Modelleme Dilinin - Unified Modeling Language-UML Gereksinimler Mühendisliğinde kullanıldığı diyagramlarının standart gösterimleri Class diagrams: Yapısal ilişkilerin görüntülendiği diyagramlar Use case diagrams: Operasyonel işlemlerinin özeti Sequence diagrams: Seneryoları simgeleyen diyagramlar State diagrams: Farklı davranışların içerildiği diyagramlar 17