Kullanıcı Tanıma Anketi (Sistem Analizi)

Geliştirilmesi planlanan yazılım sistemlerinin amacına uygun, yüksek performanslı, etkinliği yüksek ve müşteri beklentilerinin ötesine geçmesini sağlamanın en kolay yolu detaylı bir sistem analizinin yapılmasıdır.

Sistem Altsistem Tanımları dokümanının Fonksiyonel Gereksinimler kısmında sisteminin "ne yapması" gerektiği belirtilirken "Sistem Karakteristikleri" başlıklarında da yapacağı işi "nasıl yapması" gerektiği belirtilir.

Pek çok projede "Sistem Karakteristikleri" başlıkları bütçe yetersizliği, zaman darlığı veya yeterli uzmanlık olmaması sebepleri ile U/D, N/A, DSB gibi kısaltmalar konularak boş bırakılır.

Sistem kullanıma alındıktan sonra da kullanılabilirlik, erişebilirlik, performans, idame edilebilirlik, gibi konularda ardı ardına sorunlar yaşanmaya başlanır.

Standartlara uygun proje geliştiren şirketler çoğunlukla (kısmen de olsa) "Sistem Karakteristikleri"ni belirlemeye çalışmaktadır. Ancak daha düşük bütçeyle iş yapan şirketlerin bu tarz belgeler oluşturma imkanı olmayabilir.

Bu sebeple, bu tarz şirketlerin kullanımı için, son kullanıcıları tanımaya yönelik soruları aşağıda listeledim. Bu sorulara ek sorular da eklenebilir. Sorulara verilecek cevaplara uygun olarak geliştirilecek yazılım sistemlerinin çok daha az hata içeren ve yüksek müşteri memnuniyeti içeren sistemler haline geleceğine emin olabilirsiniz.

Kullanıcı Beklentileri: 

• Kullanıcıların sistemden beklentileri nelerdir?
• Mevcut durumda ne tip işlerde ne tip maliyetler / zararlar oluyor?
• Kullanıcıların bilgisayar okuryazarlığı hangi seviyededir?
• Kullanıcılar içinde bedensel / zihinsel engeli olanlar var mı? Ne tür engelleri var?
• Sistem tek bir yerleşke içinde mi kullanılacak yoksa geniş bir alanda mı?

Kullanıcıları Tanıma:

• Toplam kaç kullanıcı olacak? Önümüzdeki 5 yılda kullanıcı sayısında tahminen kaç kişilik bir artış olur?
• Hangi rollerde kullanıcılar olacak? Yönetici, sistem yöneticisi, veri giriş, raporlama / sunum, …
• Rollere göre kullanıcı sayıları nedir?
• Rollere göre kullanıcılar hangi gün ve saatlerde sistemi kullanacaklar?
• Rollere göre hangi kullanıcı sistemi ne kadar süre kullanacak?
• Rollere göre kullanıcıların en stresli / yoğun / yorucu iş akış(lar)ı nelerdir?
• Rollere göre kullanıcıların çalışma ortamı kısıtları var mı? Sahada kullanım gibi.
• Rollere göre kullanıcı için en kritik / beklemeye tahammül edemeyeceği iş akış(lar)ı nelerdir?
• Kullanıcıların uygulama üzerinden ve/veya dosya sistemi / veritabanı üzerinden girecekleri veri tipleri nelerdir?
• Kullanıcıların girecekleri veri dosyalarının adet ve/veya boyut sınırı var mıdır?
• Kullanıcıların sisteme toplu halde girmeleri gereken veriler ve/veya başka bir sistemden aktarılması gereken veriler var mı?
• İşin zorluklarını ve olası dar boğazlarını anlamak açısından bir müddet çalışma ortamında kullanıcılar ile birlikte vakit geçirmemiz mümkün mü?

Kullanıcı Eğitimi:

• Kullanıcılara hangi konularda eğitim verilecek?
• Eğitim hangi ortamda yapılacak?
• Eğitim sırasında (projenin ilk aşamasında) Kullanabilirlik testi için prototip hazırlanması.
• Toplamda hangi rolde kaç kullanıcı eğitim alacak?
• Eğitim materyali nelerden oluşacak?

Donanım/Yazılım Altyapısını Tanıma:

Yazılım:

• Kullanılan işletim sistem(ler)i nelerdir?
• Kullanılan internet gezginlerinin isimleri ve versiyonları nedir?
• İnternet Gezginleri'nde yüklü addon - pluginler var mı?
• İnternet gezginlerinin / pluginlerin güncellenmesine izin verilmekte midir?
• Kullanıcı doğrulama için LDAP benzeri bir sistem var mıdır?

Donanım:

• Sistemin kullanılacağı tesis(ler)in fiziksel altyapısı nedir? Kablosuz iletişim gerekli ise, ortam uygun mudur?
• Kullanıcıların sistemi kullanacakları donanımın (bilgisayar, tablet, telefon) özellikleri nelerdir? Rollere göre hangi tip donanımlar kullanılacaktır?

Kalite Karakteristikleri:

• Sistemin herhangi bir çevresel şart kısıtı var mıdır? Sıcaklık, nem, toz, gürültü, sarsıntı, ...
• Sistemin kullanılacağı tesis(ler)in donanım altyapısı nedir? Ağ hızı, sunucu sayısı, elektrik altyapısı, jeneratör / UPS varlığı, …
• Sistemin Genişleyebilirlik ihtiyacı var mı? Sınırları nedir?
• Sistemin Yedekleme ihtiyacı var mı? Nasıl bir süreç düşünülüyor?
• Sistemin uyması gereken bir Sertifikasyon kısıtı var mı?
• Sistemin birlikte çalışması gereken (Uyumluluk) başka sistemler var mı? Arayüzler ve veri tipleri nedir?
• Sistemin Kaynak Kullanım kısıtları var mı? CPU, bellek, disk alanı, ağ kapasitesi kullanım sınırları gibi.
• Sistemin Afet Kurtarma özelliği ihtiyacı var mı?
• Sistemin Efficiency (belirli bir yük için kaynak tüketimi) kısıtı var mı?
• Sistemin Effectiveness (harcanan efor sonrasında elde edilen performans) kısıtı var mı? Bir işlemin en fazla 3 adımda yapılması gibi.
• Sistemin uyması gereken bir yasal mevzuat / standart var mı? Nedir?
• Sistemin Performans (tepki süreleri) kısıtı var mı? Hangi yük altında bu süreler nedir?
• Sistemin Platform Uyumluluk kısıtı var mı? Hangi platformlar?
• Sistemin veri / bilgi Gizliliği kısıtı var mı? Ne tür veriler, hangi roldeki kullanıcılar?
• Sistemin Kurtarılabilme (Recovery / recoverability) kısıtı var mı? Ölümcül hata durumunda en geç 5 dakikada sistemin faal hale gelmesi gibi.
• Sistemin Bakımı için izin verilen gün / saatler nelerdir?
• Sistem için Hizmet Seviyesi Anlaşma şartları nelerdir?

Kullanıcı Destek:

• Kullanıcıların eğitim sonrası sorunlarında hangi yöntem ile yardımcı olunacak?
• Bir Destek Merkezi kurulması ihtiyacı var mı?
• Destek hangi ortam üzerinden sağlanacak? E-posta, telefon, video konferans, …
• Soru ve hata bildirimleri nerede kayıt altına alınacak?

Fonksiyonel Olmayan Gereksinimler: Uygunluk

Kullanıcıların, "normal çalışma zamanlarında" sistemin çalışabilir olduğuna güvenme derecesidir. Diğer bir deyişle, kullanıcılar normal çalışma saatlerinde sistemi kullanmak istediklerinde sistemin kullanıcı isteklerine cevap verebiliyor olması gerekmektedir.

Örnekleyecek olursak;

• Çevrimiçi Ödeme Sistemi saat 06 ile 23 arasında kullanıma uygun olmalıdır.
• Çevrimiçi Ödeme Sistemi 100 saatlik MTBF (Mean Time Between Failures - Arızalar Arasındaki Ortalama Süre) değerine sahip olması gerekmektedir.
• Çevrimiçi Ödeme Sistemi, kullanıcıların isteklerinin %95'ine 15 saniye içinde cevap verebilmelidir. Geri kalan zamanlarda 20 saniye içinde cevap verebilmelidir.
• ATM cihazı hafta içi günlerde saat 06 ile 23 arasında %99 oranında uygun olmalıdır. 
• Sistemin yeni bir kurulumu, kurulum işlemi başlatıldıktan sonra 24 saat içinde ilk kullanıma hazır olmalıdır.
• Sistem kullanıma kapatıldıktan sonra sistemin veritabanı yedeği 15 dakika içinde alınabilmelidir.
• Sisteme kapatma komutu gönderildikten sonra 3 dakika içinde sistem kapanmış olmalıdır.
• Acil durum veri silme komutu gönderildiğinde 15 saniye içinde her 3 sabit diskteki tüm veri geri kurtarılamaz şekilde silinmelidir. 

Fonksiyonel Olmayan Gereksinimler: Hayatta Kalabilirlik

Bir sistem arızası ortaya çıktığında yazılım sisteminin kendini toparlaması ve çalışmaya devam etmesinin ölçüsüdür.

Örnekleyecek olursak;

• Denetleme yazılımı arıza sonrası kapanırsa kullanıcının sözleşme dosyasında yaptığı değişiklikler kurtarılmalı ve dosya arıza oluşumundan bir dakika öncesindeki duruma gelmeli.
• Yazılımın güncellenmesi sırasında bir arıza ortaya çıkarsa yapılan tüm veri ve güncellemeler geri alınmalı ve yazılım eski haline dönmelidir.
• Bir arıza durumu sonrasında işletime devam edilirken kullanıcıya yazılımın "güvenli mod"da çalıştığı ve tüm verinin salt okunur durumda gözden geçirmeye hazır olduğunun bilgisi verilmelidir.
• Sistem, arızalı olduğu tespit edilen yeteneklere erişimi engellerken diğer tüm yeteneklere erişime izin vermelidir.
• Montaj hattındaki tüm donanım bileşenleri yedekli olmalıdır, böylece herhangi bir donanım bileşeni arızalandığında montaj hattının durması engellenmelidir.

Taşınabilirlik Gereksinimi Örnekleri

Yazılım sisteminin bulunduğu mevcut donanımdan veya yazılım ortamından bir başka donanıma / ortama kolay taşınabilmesine yönelik gereksinim türüdür.

Örnekler:

1. Hesap Hareketleri İşleme Sistemi tarafından kaydedilen tüm zaman damgaları kalıcı depolama birimine yerleştirildiklerinde Evrensel Koordine Zaman yapısında olmalıdır.
2. Bir zaman değerinin kullanıcıya görüntülendiği her yerde zaman kuşağı belirgin olarak görüntülenmelidir.
3. Ürünün, önümüzdeki sene Avrupa pazarında satışı hedeflenmektedir.
4. Ürün, işyeri ofislerinde çalışacak şekilde tasarlanmıştır ancak, üretim montaj fabrikalarında çalışacak olan bir sürüm de amaçlanmaktadır.
5. Sistem, Microsoft Windows 10 ve Macintosh işletim sistemleri için geliştirilmelidir.
6. "EvMuhasebesi" yazılımı en az aşağıdaki özelliklerdeki kişisel bilgisayarlar veya iş istasyonlarına taşınabilir olmalıdır:
1. En az 16-bit renk destekli 15 inç ve üzeri monitör,
2. Asgari 1GB disk alanı.

Bütünlük Gereksinimi Örnekleri

(Integrity'nin karşılığı olarak Bütünlük - Tamlık kullanılmakta. Bu tanıma Dürüstlük kavramını da eklemek gerekiyor)

Yazılım sistemi tarafından idame ettirilen verinin kesin, tam, gerçek ve doğru olma seviyesine yönelik gereksinim türüdür.

Örnekler:

1. Tüm mali değerler noktadan sonra 2 haneye kadar doğru olmalıdır.
2. Depo sıcaklık değerleri artı / eksi 2 santigrat derece kesinliğe sahip olmalıdır.
3. Proje belgelerinde yapılan değişikliklerin sebebi bir veritabanı veya eşdeğer bir teknoloji ile kayıt altına alınacak ve düzenli olarak yedeklenecektir. Bu işlem, disklerde veri kaybı olması durumunda belgelerde yapılan değişiklikleri belirlemek için gerekmektedir.
4. Kredi Sorgulama Sistemi, tüm yuvarlama hesaplarını önce noktadan sonra 5 haneye kadar yapmalı, ardından da noktadan sonra 2 haneye kadar yapmalıdır.
5. Sistem verisinin bütünlüğü, dahili kontrol sistemi tarafından saniyede 2 defa gözden geçirilmelidir; eğer veride tutatsızlık tespit edilirse, sistemin işlem yapmasına izin verilmemelidir.

Gizlilik Gereksinimi Örnekleri

Yazılım sisteminin hassas veriyi koruma ve sadece yetkili kullanıcıların erişimine izin verme derecesini belirleyen gereksinim türüdür.

Örnekler:

1. T.C. Kimlik Numarası'nın sisteme girişi sırasında veya sonrasında hiçbir kısmı görüntülenmeyecektir. Basılı belgeler üzerinde sadece son 4 rakamı görünür olacaktır.
2. Hasta Verileri Sistemi sadece hastanın ıslak imzalı izni olduğu durumlarda hastanın kayıtlarına erişim izni verecektir.
3. Sistemde kayıtlı her veri türünün gizlilik dereceleri olacaktır. Her veri türü içindeki tekil veriye farklı seviyelerde gizlilik dereceleri atanabilecektir. Bir kullanıcı sadece kendi yetki seviyesi ve bunun altındaki seviyedeki gizlilik derecesine sahip veriye erişim sağlayabilmelidir.
4. "Gizli" gizlilik derecesindeki ve daha üst seviyedeki gizlilik derecesindeki veri hiçbir surette harici bir ortama kaydedilemeyecek ve/veya basılı hale getirilemeyecektir.

Kullanılabilirlik Gereksinimi Örnekleri

Kullanıcının, sistem ile etkileşim kurarak öğrenme, işlem yapma, girdileri hazırlama ve çıktıları yorumlamasının kolay olmasına yönelik gereksinim türüdür.

Aşağıdaki gereksinim örnekleri okuduğunuzda göreceksiniz ki Kullanılabilirlik gereksinimlerini sadece yazılım ürünleri için değil hemen hemen tüm ürün ve hzimetler için geçerlidir. Ve bunları doğrulamak için A/B Testi ve daha genel olarak Odak Grubu (Focus Group) çalışmaları yapmak gerekmektedir.

Örnekler:

1. Ürün, tek el ile erişkin nüfus (18 - 80 yaş) tarafından kolaylıkla kullanılabilmelidir.
2. Gıda otomatı, herhangi bir eğitim gerektirmeden, erişkin nüfus tarafından kullanılabilmelidir. Otomatı ilk defa gören insanların en az %95'i başarılı bir şekilde alışveriş yapabilmelidir.
3. Ürünün yeni sürümünün kullanımının, bunu değerlendirecek kullanıcıların en az %90'ı tarafından "eski sürüme göre daha kolay" olarak değerlendirilmelidir.
4. Deneyimli bir sipariş giriş personeli, tedarikçi kataloğundan seçilen bir ürün için azami 7 dakika ve ortalama olarak 4 dakikada sipariş girebilmelidir.
5. Türkçe bilmeyen kullanıcılar, herhangi bir eğitim ihtiyacı olmadan, ürünü kullanabilmelidir.
6. Daha önce ATM cihazı kullanmış olan banka müşterileri, ortalama 2 dakika içinde ATM'den para çekebilmelidir.
7. Daha önce ATM cihazı kullanmamış olan müşterilerin en az %90'ı ortalama 4 dakika içinde ATM'den para çekebilmelidir.
8. ATM'den ayda en az 6 defa para çekmiş olan müşteriler ortalama olarak 30 saniyede ATM'den para çekebilmelidir.

Emniyet Gereksinimi Örnekleri

Yazılım sisteminin insanlara veya hedef kullanım alanı içindeki ortama zarar vermesini engellemeye yönelik gereksinim türüdür.

Örnekler:

1. Operatör Koruması "Etkin" durumuna gelmeden Radyasyon Sistemi işlem yapmaya izin vermemelidir.
2. İlaç İzleme Sistemi, doktor tarafından belirtilmiş azami miktardan daha fazla oranda doz kullanımına izin vermemelidir.
3. Yiyecek Satış Makinesi, bir soğuk gıda ürününün ısısı 4 derecenin üzerine çıkması durumunda bu ürünün satışına izin vermeyecektir.

Tekrar-Kullanılabilirlik Gereksinimi Örnekleri

Yazılım sisteminin bir parçasının diğer bir sistem tarafından kullanımı için dönüştürülmesine yönelik gereksinim türüdür.

Örnekler:

1. Elektronik Fon Transferi ödeme seçeneğinin geliştirilmesi öyle yapılmalıdır ki organizasyonun diğer bölümleri tarafından tekrar kullanılabilsin.
2. İstemci cihaz üzerinde çalışması için geliştirilen tüm yazılımlar, destekleyici bir ortamın indirilmesini gerektirmeden kişisel bir bilgisayar üzerinde çalışacak şekilde geliştirilmelidir.
3. Devlet arşivlerindeki basılı materyal elektronik hale dönüştürülürken, var olan bilginin farklı maksatlarla kullanılabilmesi için farklı formatlarda sunulabilmesinin sağlanması gerekmektedir. Bilgiye erişim aynı zamanda fikrî mülkiyet yasalarına uygun bilgileri de içermelidir.

Esneklik Gereksinimi Örnekleri

Yazılımın farklı ortamlara, konfigürasyonlara ve kullanıcı beklentilerine kolay uyum sağlamasına yönelik gereksinim türüdür.

Örnekler:

1. Uygulama, gelecekteki çoklu dil kullanımına uygun olmalıdır. Bu uygunluk şunları içermelidir:
• Veritabanının yapısı öyle olmalıdır ki çoklu dil desteğini desteklemek için ek bileşenler veya mevcut bileşenlerin değiştirilmesi gerekmemelidir,
• Kullanıcı, kişisel bilgilerini girerken tercih ettiği dili seçebilmelidir.
2. Kullanıcıya görüntülenen hiçbir metin, programın kaynak kodu içinde olmamalıdır. Kullanıcının gördüğü her metin, kaynak kodun güncellenmesine gerek olmadan değiştirilebilmelidir. 
3. Faturalama sistemi birden fazla para biriminde fatura kesme işlemi yapabilmelidir. 
4. Ders programı yönetim sistemi birden fazla bağımsız dersin birden fazla takvim seçeneğini desteklemelidir. Dersler hakkındaki bilgiler birbirinden bağımsız olmalıdır ve kullanıcılar kayıtlı olmadıkları derslerle ilgili hiçbir bilgiye erişememelidir.
5. Sistem, kaynak kodunda herhangi bir değişiklik gerektirmeden, yeni bir kullanıcı bildirim yönteminin uygulama içinden tanımlanabilmesine imkan sağlamalıdır.

İdame Edilebilirlik Gereksinimi Örnekleri

Yazılım sistemindeki arızaların bulunması ve düzeltilmesine yönelik olan gereksinim türüdür.

Örnekler:

1. Müşteri hizmetleri çağrı merkezi, sorun raporlarının %95'ini 2 saat içerisinde analiz etmelidir. "Acil" olarak sınıflandırılan arızalardan %98'i 3 iş günü içerisinde düzeltilmelidir.
2. Uygulama geliştirme süreci, 2 iş günü içinde tüm sistemi tekrar test eden bir regresyon test prosedürü içermelidir.
3. Bir bakım mühendisi, geliştirme ve test eforu da dahil olmak üzere, yasal mevzuatta yapılan değişiklikleri en geç 24 iş saati içerisinde sisteme yansıtmalıdır.
4. Sistem, bakım amacıyla 24 saatten daha uzun bir süre kapalı kalmamalıdır.

Kurulabilirlik Gereksinimi Örnekleri

Yazılım sisteminin, hedef ortama kurulumu, kurulumun kaldırılması veya tekrar kurulmasının kolay ve zahmetsiz olmasını sağlamaya yönelik gereksinim türüdür.

Örnekler:

1. Sistemin veya 3.parti ürünlerinin detayını bilmeyen ama üzerine kurulum yapılacak işletim sistemi ile ilgili yeterli bilgiye sahip bir sistem yöneticisi tarafından sistemin ana sunucu yazılımının kurulumu mümkün olmalıdır.
2. Yazılım sistemi hedef işletim sistemi olan Windows 10, Ubuntu Linux ve Redhat Linux işletim sistemleri üzerine kurulum arayüzü üzerinden kurulabilmelidir.
1. Kurulum arayüzünde belirtilen tüm alanların yanında detay açıklamaları anlaşılabilir bir dilde yazılmalıdır.
2. Kurulumun yapılacağı hedef işletim sistemi, kurulum dizini, veritabanı bağlantı ayar bilgileri, vekil sunucu ayar bilgileri yine bu arayüz üzerinden girilebilmelidir. Böylece kullanıcı, kurulum sonrasında konfigürasyon dosyalarında değişiklik yapmak zorunda bırakılmamalıdır.
3. Ana sistemin yeni bir sürümü yayınlandığında, sistemin güncellemesi bu yeni sürüm ile yapılabilmelidir. Bu esnada kullanıcı bilgisayarlarındaki ve/veya tüm sunuculardaki kayıt dosyaları, konfigürasyon ayarları, kullanıcı verileri, veritabanı dosya ve tabloları yapılan bu güncellemeden olumsuz etkilenmemelidir / silinmemeli / kaybolmamalıdır.
4. Yazılım sisteminin kurulu olduğu ortamdan kaldırılması, Kurulum Kaldırma yazılımı kullanılarak yapılmalıdır. 
1. Kurulumun kaldırılması esnasında, kaldırılan yazılımın, sistemde yüklü diğer yazılımlar ile ortak kullandığı dosyalar silinmemelidir.
2. Kurulum Kaldırma yazılımı, sadece yazılımın mı yoksa hem yazılım hem de verilerin mi silinmek istediği bilgisini kullanıcıdan almalıdır ve bu doğrultuda silme işlemini yapmalıdır.
3. Kurulum Kaldırma yazılımı, yazılım sisteminin kendi oluşturduğu dosya ve kayıtlar ile kullanıcılar tarafından oluşturulmuş kayıtların yedeklenmesine imkan veren bir yetkinliğe sahip olmalıdır.
4. Yedeklenme işlemi sonrasında, yedeklenen veri ile yedeği oluşturan kaynak veri karşılaştırması yapılarak eksik veri olmadığı doğrulanmalıdır.

Ölçeklenebilirlik Gereksinimi Örnekleri

Müşterinin ticari faaliyetinin büyümesini destekleme amacıyla, sistemin kabiliyetlerinin yukarı ve dışarı doğru genişleme derecesini gösteren gereksinim türüdür.

Örnekler:

1. Sistemde yapılan işlemlerle ilgili olarak üretilecek raporların üretilme süreleri, sistemde depolanmış toplam verinin miktarına değil, raporda içerilen verinin miktarına bağlı olmalıdır.
2. Personel maaş sisteminin yönetimi için harcanacak efor, çalışan sayısının artması durumunda, artış göstermemelidir. 
3. Personel maaş sistemi, çalışan sayısının sürekli olarak artması durumunu desteklemek üzere ölçeklenebilir olmalıdır.
4. İş kuralları veritabanı, sınırsız sayıda ek kuralın yönetimini desteklemek üzere ölçeklenebilir olmalıdır.
5. Tatil rezervasyon sistemi, dünya genelinde sınırsız sayıda tatil ofisinin kullanımını desteklemek üzere ölçeklenebilir olmalıdır.
6. Yapılan alışverişlerin tatil dönemlerinde tepe noktasına ulaşması durumu sebebiyle, ödeme onay sistemi, saatlik potansiyel %1000 artışlara karşı ölçeklenebilir olmalıdır. Bu gibi durumlarda yedek donanım ve sistemler ihtiyaç ortaya çıktığı anda devreye girmelidir.
7. E-ticaret sitesinin kullanıcı sayısının zamanla artması beklendiği için, herhangi bir ek kodlama ihtiyacı olmadan, sistem bu artışı desteklemek üzere ölçeklenebilir olmalıdır.

Erişim Güvenliği Gereksinimi Örnekleri

Sistemin, dahili ve harici kaynaklar tarafından sebep olunan kasıtlı veya istemsiz hatalarına karşı olarak korunmasına yönelik gereksinim türüdür.

Örnekler:

1. Çalışanlar, eğer "şifre geçerlilik süresi" tarafından belirlenmiş zaman aralığı içinde şifrelerini güncellememişse, bir sonraki sisteme girişlerinde şifrelerini değiştirmeye zorlanmalıdır.
2. Kullanıcılar, kendilerine atanan ilk şifreyi, sisteme ilk giriş yaptıkları zaman değiştirmeye zorlanmalıdır. İlk atanan şifre hiçbir zaman yeniden kullanılamamalıdır.
3. Personel sisteminde yer alan çalışan maaş bilgisi, sadece yetkili kullanıcı tarafından görülebilir olmalıdır. 
4. Çalışanlar, kendi maaş bilgilerini değiştirememelidir. Bu bilgiyi değiştirmeye yönelik her girişim, güvenlik yöneticisine raporlanmalıdır.
5. Sadece halihazırda geçerli bir güvenlik kleransına sahip çalışanlar karargah binasına girebilmelidir.
6. Sistem verisine erişim yetkileri sadece sistem veri yöneticisi tarafından değiştirilebilmelidir.
7. Şifreler ne girildikleri anda ne de başka herhangi bir anda okunabilir olmamalıdır.
8. Belirli bir gizlilik derecesi üstünde belgelere erişen kullanıcıların erişim zamanları kayıt altına alınmalıdır.
9. Belirli bir gizlilik derecesi üstünde belgeleri yazıcıya, USB/DVD kaydediciye veya e-posta mesajı ile gönderen tüm kullanıcıların gönderdikleri dosya ismi ve işlem zamanı kayıt altına alınmalıdır.
10. Kullanıcı işlem kayıtlarının tutulduğu dosyada (veritabanı tablosunda) hiçbir şekilde değişiklik yapılamamalı, dosya silinememelidir.

Erişebilirlik Gereksinimi Örnekleri

Mümkün olduğu kadar çok "engelsizlik" kabiliyetleri sunarak sistemin kullanmasını sağlayan gereksinim türüdür.

Örnekler:

1. Sistem, 1990 yılı Amerikan Engelliler Yasası ile uyumlu olarak, engelli bireylerin erişimine izin vermelidir.
2. Sistem, belirli görme zorlukları çeken bireyler tarafından erişebilir olmalıdır, öyle ki:
• Görüntülenen metin veya diğer değerler kırpılmadan tüm kullanıcı arayüzü büyük fontta görüntülebilmelidir,
• Ekranın istenen bölgesi ekran büyüteci ile büyütülebilmelidir,
• Görüntülenen enformasyon bir ekran okuyucu tarafından sesli olarak okunabilmelidir.
3. Sistem, renk körü bireylerin erişimine açık olmalıdır, öyle ki, sistemin görüntülediği enformasyon renk körü olmayan biri tarafından nasıl görülüyorsa, renk körü birey tarafından da aynı şekilde görüntülenebilmelidir. (Tahmini olarak, erkeklerin %9'u, kadınların %0.5'i renk körüdür).