Requirements Engineering

Transkript

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

2 GM nin Temelleri Bölüm 2 Alan Analizi (Domain Understanding) & Gereksinimlerin Edinimi (Requirements Elicitation) 2

3 Bilgi Edinimi Knowledge Acquisition system-as-is: Mevcut sistem ve içeriği ile ilgili bilgi edinilir. i)yeni bir sistemin oluşturulması için problemin tanımlanması ve olanakların (fırsatların ) araştırılması, iii) Yeni sistem için gerekli olan gerçek iştirakçilerin (stakeholders) tanımlanması system-to-be: Geliştirilecek yeni sistem ile ilgili bilgi edinilir. Bunlar: i)system-to-be için tanımlanacak organizasyona ait ve teknik kısıtlardır ii) amaçların belirlenmesi ve alınacak sorumluluklar üzere alternatif seçeneklerdir iii) yazılımın-çevresi ile etkileşimini sağlayacak senaryolardır iv) yazılımın gereksinimleridir v) çevresel varsayımlardır 3

4 İştirakçiler (Stakeholders) İştirakçiler başarılı bir GM nin temelini oluştururlar. Elicitation (edinim) = birlikte öğrenme (cooperative learning) İştirakçilerin analizinde aşağıdakiler göz önüne alınmalıdır: Dağıtık kaynaklar ve çatışan (örtüşmeyen) bakış açıları, İnsanlara ve bilgiye erişimdeki güçlük, Farklı altyapılar, terminoloji ve farklı kültürler, Örtük bilgi (tacit knowledge), gizli gereksinimler (hidden needs), Problemle uyumlu olmayan ayrıntılar, İç politikalar, rekabet, değişimlere direnç göstermek, Kişisel dengesizlik, organizasyondaki değişiklikler, veya bazı öncelikler. Ayrıca : İletişim becerileri: karşılıklı görüşmelerde farklı insanları dinlemede güvenli ilişkiler kurulması gerekir. Bilginin (yeniden)düzenlenmesi & görüşmeler yapılması gerekir. 4

5 GM de bilgi edinme (knowledge acquisiton) 2 temel kategoride gerçekleşir: Artefact-driven bilgi edinme teknikleri system-as-is ile ilgili mevcut dokümanların incelenmesi, veri örnekleri, sorular sorma, kavramsal ızgaralar (conceptual grids) Stakeholder -driven bilgi edinme teknikleri 5

6 Artefact-driven bilgi edinme teknikleri -1 Başlangıçtaki içerik çalışmasıdır Dokümanların toplanması, incelenmesi ve sentezi gerçekleştirilecektir. Bu amaçla: organization ile ilgili bilgi edinilmelidir: organizasyon şemaları, iş planları, mali raporlar, toplantı tutanakları, toplantı süreleri vs. örnek olarak verilebilir. Alan (domain) ile ilgili bilgi edinilmelidir: kitapların incelenmesi, anketler, makaleler, yönetmelikler, benzer alanlardaki benzer sistemlerle ilgili raporlar örnek olarak verilebilir. system-as-is ile ilgili bilgi edinilmelidir: belgelendirilmiş iş akışları, prosedürler, iş kuralları; değiştirilen belgeler; kusur / şikayet raporları, değişim talepleri örnek olarak verilebilir. 6

7 Artefact-driven bilgi edinme teknikleri -2 Veri Toplama (data collection) ve sorular sorma (questionnaires) Verilerin toplanması. Bunlar piyasa verileri, kullanıcı istatistikleri, performans türleri, ortalama maliyetler vs..) Veri toplanması kullanılabilirlik, performans, maliyetlerle ilgili fonksiyonel olmayan gereksinimler için önemlidir. Sorular sorulması (questionnaires) katılımcılara çoktan seçmeli ya da ağırlıklı sorular sorulabilir 7

8 Artefact-driven bilgi edinme teknikleri -3 Amaç: Önceden ortaya konulmuş kavramlar hakkında daha fazla bilgi edinilmesidir. Kavram odaklı edinim amacı ile katılımcılara kartlar dağıtılır Her kart metin ya da grafik olarak özel bir alan kavramına aittir. Kartlar iştirakçilerin kriterlerine göre alt kümelere ayrılır. Ortak özelliklere sahip her bir alt gruba tanımlayıcı ya da öngörmeli özellikler eklemeleri istenir. Tanımlayıcı (descriptive) özelliklerin alan özelliği kabul edilir oluşturacağı Öngörmeli (predictive) özelliklerin gereksinimleri oluşturacağı kabul edilir. 8

9 Aynı kartlar yeni gruplar/özellikler için değiştirilerek iterasyona sokulur. Örneğin toplantı planlanması (meeting scheduling) sistemi için: 1. iterasyon: Katılımcı, Toplantı ve Katılan kartlarını birlikte gruplar ve toplantıya katılacaklar davet edilir (kurallı özelliktir). 2.iterasyon: Toplantı ve Katılan kartları birlikte gruplanır; toplantının düzenleyicisi toplantıya katılanın kısıtlarını öğrenmelidir (kurallı özelliktir). 9

10 Artefact-driven bilgi edinme teknikleri -4 Repertory grids: (çizelgeler) Toplantı kavramı ile ilgili bir çizelge Tarih, Yer, Katılımcılar gibi özellikler içerirken, Tarih için günler farklı bir aralık olarak belirlenir. Kavram- özellik ızgarası (concept-attribute grid (Date, Mon-Fri), (Location, Europe) şeklinde tasarlandığında Meeting sistemine ait bir grid karakterizasyonudur. Kavramsal merdiven(conceptual laddering) : iştirakçilerin hedef kavramlarını sınıf-altsınıf bağlantıları ile sınıflandırmasıdır Altsınıflar: RegularMeeting, OccasionalMeeting Üst sınıf: Meeting olarak tanımlanabilir. 10

11 11

12 12

13 13

14 Artefact-driven bilgi edinme teknikleri -5 Problem dünyasının keşfi için senaryolar ve taslaklar (Scenarios and Storyboards system as-is ya da system to be ile ilgili bir dizi hikaye anlatılır (snapshot). Bu hikayeler taslaklar (storyboards) olarak pasif ya da aktif cümleler olarak tanımlanır. Kim, ne, nasıl, niçin sorularına cevap verilir.. Pozitif senaryo: Sistemin bir davranışı gerçekleştirmesi ile NE olacağıdır. Örneğin: Toplantıya katılan kısıtlarını belirlediğinde, zaman düzenleyici bu tarihleri onaylar. Katılana kısıtlarının güvenli şekilde alındığını bildirir.. 14

15 Artefact-driven bilgi edinme teknikleri -5 Negatif senaryo: Sistem bir davranışı gerçekleştirmediği zaman NE olacağıdır. Örneğin: 1.Katılımcı belirlenen tarih aralığındaki tüm kısıtlarını bildirir. 2.Toplantıyı düzenleyen kişi bu mesajı diğer tüm katılımcılara gönderir; tarih aralığını genişletir ve onlardan alternatif kısıtlarını sorar. Normal Senaryo: Her işlemin normal olarak gerçekleştiği etkileşimdir. Pozitifdir. Abnormal (standartlara uymayan, gayritabii) senaryo: Normal etkileşimlerin dışında olan, gerçekleşmesi mümkün olmayan koşullarda talep edilen etkileşimlerdir. Pozitifdir. Örneğin: 1.Toplantıyı başlatan yetkili biri değildir. 2. Katılımcının kısıtları geçerli değildir. 3.Katılımcı kısıtlarını zamanında göndermemiştir. 15

16 Stakeholder-driven bilgi edinme teknikleri İştirakçilerle karşılıklı görüşmeler önemlidir. System-as-is ile ilgili yoğun bilgi edinmek bu sistemi oluşturanlar ile doğrudan etkileşim ile sağlanır. Görüşmeler belli bir protokole göre gerçekleşir. Mülakatlar (interview) Bir iştirakçi belirlenir. Bilginin tipine bağlı olarak seçilen kişi alanda uzman, yönetici, satış elemanı, danışman, operatör, son kullanıcı vs. olabilir. Yapısal görüşme: Önceden hazırlanmış sorular sorulur. Bazıları açık uçlu olabilir; bazıları için pek çok seçim yapılabilir. Yapısal olmayan görüşme: önceden hazırlanmış sorular yoktur. Görüşmeciye system-as- is ile ilgili sorular sorulabilir: nasıl çalıştığı, mevcut sistemde ne tür problemler belirlediği, nasıl çözümlenebileceği vs. sorulur. 16

17 Stakeholder-driven bilgi edinme teknikleri İştirakçiler ile karşılıklı görüşmelerin olumlu olduğu kadar zayıf yanları da vardır. Gerçekten deneyimlenmiş olan ve sorunları açıklayan bildirimler önemlidir. Fakat aynı problem için farklı görüşmecilerden gelen bildirimlerin ortak olarak yorumlanmasında sorunlar yaşanabilir. Gözlemler ve etnografik incelemeler Pasif gözleme: analizi gerçekleştiren mühendis, incelenen görevi gerçekleştirecek kişi ile iletişim kurmaz. Sadece dışarıdan gözlem yapar. (not alarak yada kamera ile) Toplanan verinin doğru sıralanarak doğru yorumlanması gerekir. Etnografik incelemeler örnektir.örneğin gelenek ve görenekler. 17

18 Senaryo örneği: Toplantı zamanlaması meeting scheduling 1. The initiator asks the scheduler for planning a meeting within some date range. The request includes a list of desired participants. Toplantının organizatörü toplantıyı planlayacak kişiye bir tarih aralığında toplantı düzenlemeyi planladığını bildirir. İsteminde toplantıya katılmak isteyenlerin listesi vardır). 2. The scheduler checks that the initiator is entitled to do so and that the request is valid. It confirms to the initiator that the requested meeting is initiated. (Toplantıyı planlayacak kişi toplantı organizatörünün isteklerini kontrol eder. Toplantıyı başlatacak olan kişiye, yani organizatöre onay vermesi ile istek geçerli olur. 3. The scheduler asks all participants in the submitted list to send their date and location constraints back within the prescribed date range. (Toplantıyı planlayacak kişi tüm katılımcılara tarih ve yer ile ilgili kısıtlarını göndermesini ister) 18

19 Senaryo Örneği : Toplantı Planlaması meeting scheduling 4. When a participant returns her constraints, the scheduler validates them (e.g., with respect to the prescribed date range). It confirms to the participant that the constraints have been safely received. (Bir katılımcı kısıtlarını bildirdiğinde, toplantıyı planlayacak kişi bunları önceden belirlenmiş tarihlere göre değerlendirip, onaylar. Daha sonra katılımcıya kısıtlarının güvenli şekilde alındığını bildiren onay gönderir.) 5. Once all valid constraints are received, the scheduler determines a meeting date and location that fit them. (Geçerli bir kısıt alındığında, toplantıyı planlayan kişi uygun bir toplantı tarihi ve yeri belirler). 6. The scheduler notifies the scheduled meeting date and location to the initiator and to all invited participants (Toplantıyı planlayan kişi belirlenmiş olan bu tarih ve yeri, hem davetli katılımcılara, hem de toplantının organizatörüne bildirir. 19

20 UML Unified Modeling Language (UML) gereksinimler mühendisliğinde standart olan bazı notasyonları kullanarak diyagramlar çizer ve görsel çözümleme gerçekleştirir.. Class diagrams Sınıf diyagramları ya da yapısal tasarımda Entity Relationship (varlık-ilişki) diagrams Use case diagrams: Operasyonel işlemlerin özetini görseller Sequence diagrams: Senaryolar için gerçekleştirilen işlemlerin sırası özetlenir lamsweerde Chap.4: Requirements Specification & Documentation 20

21 Toplantı Planlaması Örneğine ait use case Diyagramı 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 lamsweerde Chap.4: Requirements Specification & Documentation 21

22 Toplantı Planlaması Örneğine ait veri akış (Dataflow ) Diyagramı meeting Request Initiator Check Request constraintrequest input data flow invalid Request validrequest copyof constraints Request Ask Constraints Collect Constraints output data flow operation Merge Constraints meeting Constraints Participant meeting Notification Determine Schedule Participant individual Constraints participantconstraints system component data repository lamsweerde Chap.4: Requirements Specification & Documentation 22

23 Toplantı Planlaması Örneğine ait olayların (events) sırasının izlenmesi: Sequence Diyagramı 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 lamsweerde Chap.4: Requirements Specification & Documentation monitors interaction self-interaction 23