Yazılım geliştirmede doğru teknik özellikler başarılı bir projenin sırrıdır. Teknik spesifikasyonların geliştirilmesi. Nedir, neden gereklidir, nereden başlamalı ve neye benzemelidir? Teknik spesifikasyonların geliştirilmesi görevi

Teknik şartname nedir? Nasıl yapılır ve ne için? Örnekler, örnekler, ipuçları ve öneriler.

Birinin sizi mükemmel bir şekilde anlaması ne kadar harika görünüyor. Birkaç cümle verdiniz ve işte tam da hayal ettiğiniz gibi. Maalesef bu şekilde çalışmıyor.

Bilgi algısı sorunu sonsuzdur. “Kırık telefon” etkisi yaygın bir durumdur. Peki ya bir görevi nasıl belirleyeceğinizi bilmiyorsanız? Evet, bu da oluyor ve bununla bir şekilde çalışmanız gerekiyor, ama nasıl? Belirlediğiniz görevlerin sonuçlarının beklentilerinizi karşıladığından emin olmak için bir teknik şartname yazın.

Teknik şartname nedir

Teknik şartname (veya TOR), yüklenici tarafından sağlanan ürün veya hizmetlere ilişkin müşterinin gereksinimlerini içeren bir belgedir. Basit bir deyişle: Birbirine dik yedi çizgiye sahip olmak ve bazılarını kırmızı, bazılarını renksiz çizmek istiyorum (materyalin sonunda bu konuyla ilgili bir video izlemenizi öneririm).

Tasarım Bölümü

Bu belge bir A4 sayfasını veya tüm cildi kaplayabilir, hepsi içerdiği görevlere ve isteklere bağlıdır. Örneğin, küçük bir açılış sayfası (tek sayfalık web sitesi) veya makine öğrenimi ve diğer özelliklere sahip karmaşık bir yazılım için teknik spesifikasyon yazabilirsiniz.

Neden teknik spesifikasyonlara ihtiyacınız var?

• Sanatçılara görev atamak.
• Sonunda ne elde etmek istediğinizi ayrıntılı olarak açıklamak.
• İş sırası üzerinde anlaşmaya varmak.
• Uygulama sonrasında çalışmayı değerlendirmek ve kabul etmek.
• Bunun için...(seçeneklerinizi yorumlara ekleyin).

Aslında teknik şartnamenin yukarıdaki listeden çok daha fazla amacı ve avantajı vardır. Şahsen benim için teknik şartnamelerin çözdüğü asıl görev, ihtiyaç duyduğum şeyin beklentilerden (beklentilerimden) minimum sapma ile uygulanmasıdır.

Teknik spesifikasyonlar sayesinde uygulama süresi, para ve nihai ürün veya hizmetin beyan edilen özelliklerine uygunluk hakkında her zaman soru sorabilirsiniz.

Aslında bu müşteri ve yüklenici tarafından hazırlanan ciddi bir belgedir. Tarafların cezaları ve yükümlülükleri belirlendiği ölçüde. Çok sayıda GOST var, daha fazlasını Habré'de okuyun.

Teknik spesifikasyonların geliştirilmesi

Örneğin bir mobil uygulamanın veya web sitesinin geliştirilmesine yönelik teknik bir görev gibi "yetişkinlere yönelik" bir oyundan bahsediyorsak, o zaman bu, çok para ödenen ayrı bir iştir. Genellikle eski veya mevcut Baş Teknik Sorumlu olan bir kişiyi çekersiniz ve ondan size yardım etmesini istersiniz.

Sakallı olmak isteğe bağlıdır

Projenin/görevlerin kapsamına bağlı olarak bu kişi tüm “isteklerinizi” toplar, bunları teknik dile çevirir, belki de eskizler hazırlar (yaklaşık olarak nasıl görünmesi gerektiği) ve bitmiş belgeyi size verir. Daha sonra, bu belgeyi sanatçılara (şirketiniz içindeki veya dışarıdan sağlanan bir ekip) teslim edersiniz, para ve son teslim tarihleri ​​üzerinde anlaşmaya varırsınız ve işe koyulursunuz.

İpucu: CTO ekibinizde olmalıdır, aksi takdirde uygulama sürecinde büyük olasılıkla bir şeyleri kaçıracaksınız. Her şey için yeterli bilgiye sahip değilsiniz. Teknik şartnamelerin yazımına katılan kişi bunu kontrol eder.

Teknik şartname nelerden oluşur?

Her şey seçtiğiniz şablona bağlı olacaktır (biraz ileride şablonlara/örneklere bazı bağlantılar vereceğim), ancak teknik özelliklerde yer alan temel bloklar vardır:

1. Projenin/görevin açıklaması. Tamamlanması gereken projenin veya görevin ne olduğunu kısaca yazıyoruz.
2. Amaç ve hedefler. Projenin hedefleri nelerdir?
3. Gereksinimler. İhtiyaç duyulan tasarım, işlevler, teknolojiler.
4. İş tanımı. Ne, ne zaman ve nasıl yapılacak.
5. Kontrol ve kabul prosedürü. İşin nasıl kabul edileceği, neyin tamamlanmış sayılabileceği.
6. Uygulamalar. Eskizler, eskizler, prototipler.

İşin maliyeti genellikle sözleşmenin ayrı bir ekinde yer alır ancak bu, tarafların teknik şartnamede tutarları kendilerinin belirtmesi durumunda gerçekleşir.

Okumayı böldüğüm için özür dilerim. Telegram kanalıma katılın. Yeni makale duyuruları, dijital ürünlerin geliştirilmesi ve büyüme hileleri, hepsi orada. Seni bekliyor! Devam edelim...

Teknik spesifikasyon örnekleri

Teknik şartnamelerin geliştirilmesi karmaşık bir süreç olmasına rağmen oldukça ilgi çekicidir. Göreviniz nihai sonucun resmini yeniden oluşturmak ve ardından bunu parçalar halinde açıklamaktır.

Smart TV uygulamasını güncellemeye ilişkin görev şartlarımdan birine bir örnek. Daha karmaşık ve karmaşık ürünlere yönelik görevler, teknik departmandaki meslektaşların yardımıyla derlendi. Ekip arkadaşlarınızdan yardım istemekten çekinmeyin, mümkün olduğunca onları sürece dahil edin. Ve geri bildirimde bulunmayı unutmayın! Sonuçlarını bilmeden bir şeye çaba ve zaman harcamaktan daha kötü bir şey yoktur. Bize bu kişinin tavsiyesinin işinizde ne kadar yararlı olduğunu anlatın, aksi takdirde bu tek taraflı bir oyundur.

Bir çevrimiçi mağazanın geliştirilmesi için referans şartları

Bir mobil uygulamanın geliştirilmesi için görev tanımı

Site için referans şartları

Hizmetler/güncellemeler için görev tanımı

Daha fazla örneğe ihtiyacınız varsa Google'da aramanız yeterli.

Ana öneri bunu yapmaktır. Sorun şu ki, anne tembelliği herkesi etkiliyor ve buna direnmek kolay değil. Tüm iradenizi toplayın ve teknik şartnameleri yazmaya başlayın, sadece yazın ve durmayın. “Mükemmel” olmaz diye endişelenmeyin, size bir sır vereyim, bu asla olmaz. Sadece yazın, her seferinde daha iyi ve daha iyi olacak.

İşte böyle olmalı

Teknik şartname yazmaya yönelik ilk ilkelerim birkaç yıl önce ortaya çıkmaya başladı. Tasarımcılarla çalıştım ve reklam kampanyaları için yaratıcı öğeler oluşturmakla görevlendirildim. Tutarsızca istedim ve bir sürü zaman ve açıklama israfına dönüştü. Zamanla, görevlerin belirlenmesi bir tür anlamsal bloklara ve ardından teknik spesifikasyon gibi bir şeye dönüşmeye başladı.

Örneğin, “Sitedeki beğen düğmesi” görevi için:

1. Açıklama: Sitemizde bir "Beğen" butonu oluşturmanız gerekmektedir.
2. Amaç ve hedefler: Kullanıcı katılımı, beğeni sayısına göre materyallerin yayınlanması/derecelendirilmesi.
3. Gereksinimler: aşağıdaki tasarım (örnek: benzer bir şeye bağlantı), işlevsellik (herhangi bir kullanıcı resmi derecelendirebilir ve beğenebilir, site sistemi beğenilerin sayısını dikkate alır ve materyallerin çıktısını değiştirir), teknoloji (masaüstünde mevcuttur) ve sitenin mobil versiyonları).
4. İşin tanımı: düğme düzenleri için 3 seçenek çizin (hazırlık tarihi: 10/01/17), beğenilere göre malzeme dağıtımı için bir sistem geliştirmek (tarih: 10/14/17), fonksiyon testi (tarih: 10/16/17) ), yayın (tarih: 10/17/17)
5. İşin kabulü: Kullanıcı beğen butonuna basar, sistem tıklamaları sayar, malzemelerin teslimi değişir.
6. Uygulamalar: eskizler, eskizler, benzer işlevin çalıştığı proje örnekleri.

Görevleriniz için gerekli olan yapı bölümlerini ve kısımlarını kendinize bırakın. Örneğin altıncı blok “Uygulamalar” işlevsel gereksinimlerde açıklanabilir. Temel tavsiye: Öyle ya da böyle, görevi teknik şartnamenin yapısına göre tanımlayın. Böylece önemli noktaları kaçırmaz ve gereksiz sorulardan kendinizi kurtarırsınız, aynı zamanda iş arkadaşlarınızın hayatını da kolaylaştırırsınız.

Hadi bakalım

Teknik bir görevin ne olduğuna ve nasıl yapılacağına baktık. Artık görevleri açık ve net bir şekilde belirleme, düşüncelerinizi diğer insanlara aktarma ve ek açıklamalarla zaman kazanma olanağına sahipsiniz. Umarım artık tüm bunlarla ne yapacağını biliyorsundur.

Sözlük

Diğer teknik terminoloji, mevcut standartlara ve İnternet'teki standardizasyon sorunlarından sorumlu uluslararası kuruluşların tavsiyelerine uygun olarak anlaşılmaktadır.

Genel Hükümler

Geliştirme konusu

Geliştirme konusu, web arayüzüne dayalı dinamik bir içerik yönetim sistemine sahip "...", LLC şirketinin internet sitesidir.
Sitenin amacı:
- LLC “...” şirketi hakkında bilgi sağlamak;
- “...” LLC'nin faaliyetleri hakkında bilgi sağlamak;
- vesaire.;
- vesaire.

Siteyi oluşturma amacınız: ... .

Belgenin amacı

Bu belge, LLC "" web sitesinin uygulanmasına yönelik eksiksiz bir gereksinimler seti sağlar.
Müşterinin ve Yüklenicinin bu belgedeki imzası, aşağıdaki gerçekleri ve koşulları kabul ettiklerini teyit eder:
1. Yüklenici, yapılan işe ilişkin gereksinimlerin listesini içeren, Teknik Şartname adı verilen bu belgeyi hazırlamış ve geliştirmiştir.
2. Müşteri, bu Teknik Şartnamenin tüm hükümlerini kabul eder.
3. Müşterinin, mevcut Sözleşme çerçevesinde Yükleniciden işbu Teknik Şartnamede açıkça belirtilmeyen işin yapılmasını veya hizmetlerin sağlanmasını talep etme hakkı yoktur.
4. Yüklenici bu Teknik Şartnamede belirtilen kapsamda iş yapmayı taahhüt eder.
5. Müşterinin, bu Teknik Şartnamede belirtilmediği sürece Yükleniciden herhangi bir format ve standarda uymasını talep etme hakkı yoktur.
6. Bu Görev Tanımında imzalandıktan sonra tespit edilen tüm belirsizlikler, Taraflar arasındaki ikili anlaşmaya tabidir. Onay süreci sırasında, Anlaşmaya ek bir anlaşmayla resmileştirilen ve buna göre değerlendirilen ek gereksinimler geliştirilebilir.

Web sitesi grafik tasarımı için gereksinimler

Web sitesi tasarımı gereksinimleri

Web sitesi geliştirirken ağırlıklı olarak hafif stiller kullanılmalıdır.
Sitenin ana bölümlerine ilk sayfadan erişilebilir olmalıdır.
İlk sayfa çok miktarda metin bilgisi içermemelidir.

Site tasarımı şunları içermemelidir:
- yanıp sönen pankartlar;
- çok sayıda birleştirme metni;
- vesaire.;
- vesaire.

Tasarım konseptini onaylama prosedürü

Tasarım konsepti, sitenin ana sayfalarının genel görsel (kompozisyon, renk, yazı tipi, gezinme) çözümünü gösteren, ana sayfa ve iç sayfaların grafik kabuğu için bir tasarım seçeneği olarak anlaşılmaktadır. Tasarım konsepti, tarafların mutabakatına göre tarama formatında bir dosya (birkaç dosya) veya çıktı olarak sunulur.
Yüklenicinin sunduğu tasarım konsepti Müşteriyi tatmin ederse, sunum tarihinden itibaren beş iş günü içinde onaylaması gerekir. Aynı zamanda sayfaların genel yapısını ve stilini etkilemeyen özel iyileştirmelerin bir listesini Yükleniciye gönderebilir. Bu iyileştirmeler siteye yönelik yazılım modüllerinin geliştirilmesine paralel olarak gerçekleştirilmektedir. Kabul edildikten sonra tasarım konseptinde değişiklik yapılmasına yalnızca tarafların ek mutabakatı ile izin verilir.
Sunulan konsept Müşterinin gereksinimlerini karşılamıyorsa, ikincisi, konseptin kabulüne engel teşkil eden ayrıntıları ve gereksinimlerin daha net bir şekilde formüle edilmesini belirterek, konseptin kabul edilmesinin gerekçeli bir reddini sağlar.
Bu durumda Yüklenici tasarım konseptinin ikinci bir versiyonunu geliştirir. Yüklenici, tasarım konseptinin ikinci versiyonunu geliştirme yükümlülüğünü, ancak tasarım konsepti geliştirme aşamasını en az beş iş günü süreyle uzatmaya yönelik ek bir anlaşmayı kabul edip imzaladıktan sonra kabul eder.
Ek (üçüncü ve sonraki) seçenekler Yüklenici tarafından ek anlaşmalara dayalı olarak bir ücret karşılığında geliştirilir.

İşlevsel gereksinimler

Web sitesi sunumu için gereksinimler

Sitenin ana sayfasının sunumu için gereksinimler Sitenin ana sayfası, ilk sayfadan site ziyaretçisinin şirket hakkında tanıtıcı bilgiler alabilmesi ve en son şirket haberlerinden haberdar olabilmesi için bir grafik bölümü, site gezinme menüsü ve bir içerik alanı içermelidir. .
İlk sayfanın içerik alanı aşağıdaki bölümlere ayrılmalıdır:
- "Şirket hakkında" bölümüne yönlendiren "daha fazla ayrıntı" bağlantısını içeren şirket hakkında tanıtım makalesi;
- haberler - şu formatta en son 3 haberi (duyuruları) içerir: tarih, başlık, özet;
- kısa iletişim bilgileri - şirketin telefon numarası ve e-postası;
- sayfanın üst kısmında, sitenin ana menü öğelerine (Şirket hakkında, Haberler vb.) geçiş sağlayan hafif bir gezinme çubuğu görüntülenir;


- sayaçlar ve bağlantı değişim sayfasına bir bağlantı.

Pirinç. 1. Ana sayfaya öğe yerleştirme örneği.

Dahili sayfaların grafik kabuğu (tüm alt bölümler için ortak)
Dahili sayfaların grafik kabuğu aşağıdaki bölümlere ayrılmalıdır:
- grafik başlığı
- site gezinme menüsü (gezinme paneli 2, ana site menü öğelerine geçişi sağlar);
- arama alanı - sitede tam metin araması yapmak için tasarlanmıştır;
- dil seçim alanı - Rusça\İngilizce;
- “Ana Sayfa” bağlantısı;
- sitenin seçilen bölümünün alt bölümleri için gezinme paneli;
- seçilen site sayfasının içeriğini görüntülemek için bir alan;
- sayfanın alt kısmında - kısa iletişim bilgileri - şirketin telefon numarası ve e-posta adresi;
- “Yazdırma İçin” düğmesi - içerik alanının A4 sayfalara yazdırmak için kesilmiş bir biçimde çıktısını sağlar;
- “Soru sor” butonu – “Soru sor” formuna geçiş sağlar.

Pirinç. 2. Sitenin iç sayfalarının öğelerinin yerleştirilmesine bir örnek.

Site yapısı için gereksinimler
Aşağıda verilen tüm saha bölümü adları koşulludur ve tasarım sürecinde Müşteri ile anlaşarak ayarlanabilir.
Sitenin ilk yapısı şöyle görünmelidir:
- Şirket hakkında

A. şirketin geçmişi
B. Diplomalar ve sertifikalar
C. Bizim ortaklarımız
D. müşterilerimiz
e. Koordinatlarımız
F. ...

2. Haberler
3. vb.
4. cadde.

İçerik yönetim sistemi için gereksinimler

İdari kısım için genel şartlar
Sitenin yönetim kısmına erişim sağlamak için tarayıcı satırında belirli bir adres belirtmeli ve yetkilendirmeden geçmelisiniz.
Yönetim bölümünün ana sayfası aşağıdaki menü öğelerini içermelidir:
- Site sayfaları (site yapısının birinci seviyesine uygun olarak):

Şirket hakkında
- Haberler
- vesaire.;

Pirinç. 3. Sitenin idari bölümünün ana sayfasının düzeni.

Web sitesi bölümlerini yönetme gereksinimleri
Sitenin bölümlerini yönetmek için aşağıdaki işlevler sağlanmalıdır:
- 1. seviyenin bir alt bölümünün oluşturulması;
- 2. seviyenin (ve daha ilerisinin) bir alt bölümünün oluşturulması;
- sayfa içeriğini düzenlemek;
- bir bölümün silinmesi;
- listede bir bölümün yukarıya taşınması;
- listede bir bölümün aşağıya taşınması;
- sitenin müşteri kısmında sayfayı gösterme (gösterme) veya göstermeme (gizleme) işareti;
- seçilen seviyenin alt bölümlerinin bir listesinin görüntülenmesi.

Web sitesi içerik yönetimi
Site içeriğini yönetmek için aşağıdaki bloklar sağlanmalıdır:
1. içerik öğesi alanı aşağıdaki türlerden biri olabilir:
- astar;
- Tarihi;
- dosyaya bağlantı;
- çok satırlı metin;
2. içerik öğesi - bir dizi içerik öğesi alanından oluşur;
3. içerik öğeleri listesi - bir dizi içerik öğesinden oluşur.

Pirinç. 4. İçerik öğesi alanları.

Metin içerik öğesi alanı, çok satırlı bir metin düzenleyicide ayrı bir sayfada düzenlenmelidir (bu düzenleyici, görsellerin metne dahil edilmesine olanak tanır).

Pirinç. 5. Yönetim kısmında çok satırlı metin editörü.

Her içerik öğesi için gerekli alan kümesi tanımlanmalıdır. Örneğin, "Haberler" öğesi için aşağıdaki içerik alanları kümesi tanımlanmıştır:

Pirinç. 6. “Haberler” içerik öğesinin yönetim kısmında sunulmasına bir örnek.

İçerik öğeleri listesi aşağıdakilere izin vermelidir:
. liste öğesi alanlarını düzenlemeye gidin;
. liste öğesini sil;
. istemci kısmındaki çıktı listesi öğelerinin sırasını belirlemek;
. gizle\göster özelliğini belirtin.

Pirinç. 7. İçerik öğelerinin bir listesinin yönetim kısmında sunulmasına ve bunların müşteri kısmında görüntülenmesine bir örnek.

Öğe listesi, "Çok satırlı metin" türündeki alanlar hariç, öğenin tüm alanlarını göstermelidir.

Site ayarlarını yönet
Site ayarları şunları içermelidir:
-... için e-posta;
- vesaire.;
- vesaire.

İdari bölümün ek işlevleri
İdari kısmın ek işlevleri şunları içermelidir:
- …;

Paylaşım erişimi için gereksinimler

Sitenin yayınlanan tüm bölümleri, kullanıcı kimlik doğrulaması olmadan okuma erişimine açık olmalıdır.
Kapalı bir bölüme girmeye çalışırken, kimliği doğrulanmamış bir kullanıcıdan kullanıcı adı ve şifre istenmelidir.
Kimlik doğrulamanın ardından sistem, kullanıcının istenen bölüme erişim yetkisini kontrol etmelidir. Erişim reddedilirse kullanıcıya kısıtlı bölüme erişemediğini belirten bir mesaj gönderilmelidir.

Teminat türleri için gereklilikler

Bilgi desteği gereksinimleri

Veri depolama gereksinimleri
Tüm site verileri, ilişkisel bir DBMS'nin kontrolü altında yapılandırılmış bir biçimde saklanmalıdır. İstisnalar, görüntüleme ve indirme amaçlı veri dosyalarıdır (resimler, videolar, belgeler vb.). Bu tür dosyalar dosya sisteminde saklanır ve bunlara bağlantılar veritabanına yerleştirilir.
Çalışması aynı sistem kurulumuyla desteklenen çeşitli sitelerin içeriklerinin tek bir DBMS'nin kontrolünde saklanması gerekir.
Programlama dili gereksinimleri
Statik sayfaları ve şablonları uygulamak için HTML 4.0 ve CSS dilleri kullanılmalıdır. Kaynak kodu W3C standartlarına (HTML 4.0) uygun olarak geliştirilmelidir.
İstemci tarafının etkileşimli öğelerini uygulamak için JavaScript ve DHTML dilleri kullanılmalıdır.
Dinamik sayfaları uygulamak için PHP dili kullanılmalıdır.
Köprüleri düzenlemek için gereksinimler
Sitedeki tüm bağlantılar göreceli olmalıdır (dış bağlantılar hariç).

Resimler için gereksinimler
1 kb'den büyük tüm çizim ve fotoğraflar (sayfa tasarım öğeleri hariç) alternatif metinle yapılmalıdır. Tüm çizimler gif veya jpg formatında olmalıdır.
Bir sayfanın hacmi için gereksinimler
Standart olarak yüklenen bir web sitesi sayfasının ortalama boyutu 170 kb'yi geçmemelidir.
Flash ekran koruyucunun boyutu 300 Kb'yi geçmemelidir.

Yazılım gereksinimleri

Sunucu yazılımı gereksinimleri
Sitenin çalışması için aşağıdaki yazılım gereklidir:
- İşletim sistemi - Windows XP ve Windows Server 2003;
- Web sunucusu - Apache sürümü 1.3.26'dan düşük olmamalıdır;
- DBMS - MySQL sürümü 3.23'ten düşük değil;
İstemci yazılımı gereksinimleri
Site aşağıdaki tarayıcılar kullanılarak tamamen işlevsel olarak görüntülenebilmelidir:
. MS IE 5.0 ve üzeri;
. Opera 6.0 ve üzeri;
. MozillaFirefox 1.0;
. Mozilla'nın 1.7.
Tarayıcıda Flash ve JavaScript desteği devre dışı bırakıldığında sitenin çalışır durumda olması (üzerinde yer alan bilgilerin erişilebilir olması) gerekir.

Teknik gereksinimler

Web sitesinin çalışması için aşağıdaki minimum özelliklere sahip teknik destek gereklidir:
- işlemci - Intel Pentium III 1 Ghz;
- RAM - 512 Mb RAM;
- sabit sürücü - 20 Gb HDD.
- vesaire.;
- vesaire.

Dil desteği için gereklilikler

Site Rusça ve İngilizce olmalıdır. Sitenin herhangi bir sayfasında Rusça ve İngilizce arasında geçiş mümkün olmalıdır.

Ergonomi ve teknik estetik gereksinimleri

Site, ana çözünürlük türleri için yatay kaydırma çubuğu ve boş (beyaz) alanlar olmadan 1024*768, 1280*1024 çözünürlükte görüntülenecek şekilde optimize edilmelidir.
Kontrol öğeleri tüm sayfalarda aynı şekilde (yatay veya dikey) gruplandırılmalıdır.
Her sayfada şirket logosu ve iletişim bilgileri bulunmalıdır.
Eklenti modüllerinin arayüzü, sistem çekirdeği arayüzüyle aynı tarzda yapılmalı ve yöneticiye sistem modülleri arasında şeffaf bir şekilde hareket etme ve aynı tür işlemleri gerçekleştirmek için aynı kontrol prosedürlerini ve gezinme öğelerini kullanma yeteneğini sağlamalıdır.

Proje kabulü ve teslimatı için gereklilikler

Bilgi doldurma gereksinimleri

Bilgi içeriği için genel gereksinimler
Bu projedeki çalışmanın bir parçası olarak Yüklenici, şantiyedeki bölümlerin Madde 6.1.2'de belirtilen şekilde Müşteri tarafından sağlanan malzemelerle doldurulmasını sağlar.
Yüklenici, resimlerin teknik gerekliliklere ve hazırlanan malzemelerin HTML düzenine uygun hale getirilecek şekilde işlenmesini sağlar. Metinlerin taranması, yazılması ve düzenlenmesi-düzeltilmesi, rötuşlanması, düzenlenmesi, tercümesi ve diğer işler Yüklenici tarafından ek bir anlaşmaya dayalı olarak (müşterinin elinde bulunan malzemeler incelendikten sonra) yapılabilir.
Sistem devreye alındıktan sonra bölümlerin bilgi içerikleri site destek sözleşmesi esas alınarak gerçekleştirilir.
Diğer bölüm türlerindeki metnin hacmi ve çizim sayısı, bu Şartnamede sağlanan veri yapısına göre belirlenir ve tasarım konseptinin onaylanması aşamasında netleştirilir.
Bilgi içeriği sağlama prosedürü
Müşteri, sitenin yapısına karşılık gelen bir dizin ağacı içeren bir zip arşivinde elektronik biçimde materyaller sağlar.
Her dizin, MS Word formatında bir dizi belge içerir - bilgi blokları ilgili bölümde yayınlanan her bilgi modülü için bir belge. Metinlerin grafik veya diğer metin dışı öğeler biçiminde yerleştirilmesine izin verilmez.
Resimler dosyanın içindeki metnin içine veya ayrı bir resim olarak yerleştirilebilir. Ancak ikinci durumda metin, görüntü dosyasının yolu ve adı biçiminde görüntüye bir bağlantı içermelidir.
Her bilgi modülü için belgenin yapısı, malzeme temini aşamasına başlamadan önce Yüklenici tarafından sağlanan şablonlara uygun olmalıdır.
Bölümlerin ilk doldurulmasına ilişkin malzemeler, iş programında belirlenen süreler içerisinde Yükleniciye eksiksiz olarak teslim edilmelidir. Malzemelerin, yukarıdaki gereksinimleri karşılayan birkaç zip dosyası halinde parçalar halinde aktarılmasına izin verilir.
Bu Şartname'ye karşılık gelen hacim ve formattaki materyallerin aktarımı, Bilgi İçeriği Aktarım Sertifikası'nın imzalanmasıyla güvence altına alınır.
Bu Kanunun imzalanmasının ardından Yüklenici tarafından bilgi içeriğinde yapılacak herhangi bir değişikliğe, yalnızca ek bir ücret karşılığında ayrı bir sözleşme temelinde izin verilir.
Müşteri tarafından iş programının belirlediği süreler içerisinde sağlanmayan bilgilendirme materyalleri, projenin teslimi ve kabul edilmesinden sonra 2 hafta içerisinde Yüklenicinin teminat mektubuna göre Yüklenici tarafından ilan edilir. Bilgilendirme materyallerinin bu kısmı aynı zamanda yukarıda belirtilen sunum formatına ilişkin şartlara da tabidir.

Personel gereksinimleri

Dinamik içerik yönetim sisteminin web arayüzünü çalıştırmak için yönetici, kişisel bir bilgisayar ve standart bir web tarayıcısıyla (örneğin, MS) çalışma konusundaki genel beceriler haricinde özel teknik becerilere, teknolojiler veya yazılım ürünleri bilgisine ihtiyaç duymamalıdır. IE 6.0 veya üstü).

Dağıtım provizyonu prosedürü

Geliştirmenin tamamlanmasının ardından Yüklenici, Müşteriye aşağıdakilerden oluşan bir sistem dağıtım kiti sağlamalıdır:
-tüm yazılım modüllerinin ve sitenin bölümlerinin kaynak kodlarını içeren arşiv;
- güncel bilgiler içeren proje veritabanının dökümü.
Dağıtım, dosya arşivi olarak bir CD'de sağlanır.

Siteyi müşterinin teknik araçlarına aktarma prosedürü

Yüklenici, saha kabulünün tamamlanmasının ardından garanti desteği çerçevesinde geliştirilen yazılımın Müşteri donanımına bir defaya mahsus aktarımını gerçekleştirir. Yazılım ve donanım platformunun bu belgenin gerekliliklerine uygunluğu Müşteri tarafından sağlanır.
Aktarımdan önce Müşteri, web sunucusuna uzaktan kabuk erişimi ve site veritabanına erişim sağlar.

Ve böylece, TK veya SRS'den (Yazılım (veya Sistem) Gereksinimleri Belirtimi) bahseden ana standartlar, metodolojiler ve bilgi kümeleri:

GOST34
GOST 19
IEEE STD830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK vb.

GOST34

GOST 34'e göre teknik şartname aşağıdaki bölümleri içermelidir:

1. Genel bilgiler
2. Sistemin yaratılmasının (geliştirilmesinin) amacı ve hedefleri
3. Otomasyon nesnelerinin özellikleri
4. Sistem gereksinimleri
5. Sistemi oluşturmaya yönelik çalışmanın bileşimi ve içeriği
6. Sistemin kontrol ve kabulüne ilişkin prosedür
7. Sistemin devreye alınması için otomasyon nesnesinin hazırlanmasına yönelik işin bileşimi ve içeriğine ilişkin gereklilikler
8. Dokümantasyon gereklilikleri
9. Geliştirme kaynakları

Müşteriler, hükümet projeleri için teknik spesifikasyonlar geliştirirken kural olarak bu özel standarda uyumu talep eder.

GOST 19

1. Giriş;
2. Gelişme nedenleri;
3. Geliştirmenin amacı;
4. Program veya yazılım ürününe ilişkin gereksinimler;
5. Program dokümantasyonu için gereklilikler;
6. Teknik ve ekonomik göstergeler;
7. Gelişimin aşamaları ve aşamaları;
8. Kontrol ve kabul prosedürü;
9. Uygulamalar.

Doğal olarak, GOST 34 (ve 19) zaten güncel değil ve bunları kullanmayı sevmiyorum, ancak standartların doğru yorumlanmasıyla iyi teknik özellikler elde edebilirsiniz, bkz. Sonuç.

IEEE STD830-1998

İyi yazılmış bir yazılım gereksinimleri spesifikasyonunun (SRS) içeriğini ve kalite özelliklerini açıklar ve çeşitli SRS şablonları sağlar. Bu önerilen uygulama, geliştirilmekte olan yazılım için gereklilikleri belirlemeyi amaçlamaktadır ancak aynı zamanda özel ve ticari yazılım ürünlerinin seçiminde yardımcı olmak için de kullanılabilir.

Standarda göre görev tanımının aşağıdaki bölümleri içermesi gerekmektedir:

1. Giriş

• 1. Amaç
• 2. Kapsam
• 3. Tanımlar, kısaltmalar ve kısaltmalar
• 4. Bağlantılar
• 5. Kısa genel bakış

• 1. Ürün etkileşimleri (diğer ürünler ve bileşenlerle)
• 2. Ürün özellikleri (kısa açıklama)
• 3. Kullanıcı özellikleri
• 4. Sınırlamalar
• 5. Varsayımlar ve bağımlılıklar

• 1. Harici arayüzlere ilişkin gereksinimler
  • 1. Kullanıcı Arayüzleri
  • 2. Donanım arayüzleri
  • 3. Yazılım arayüzleri
  • 4. Arayüzler
• 2. İşlevsel gereksinimler
• 3. Performans gereksinimleri
• 4. Tasarım Kısıtlamaları (ve Standartlara Referanslar)
• 5. İşlevsel olmayan gereksinimler (güvenilirlik, kullanılabilirlik, güvenlik vb.)
• 6. Diğer gereksinimler

Aslında, yeni başlayan birinin yukarıdaki yapıya göre (GOST örneğinde olduğu gibi) bu bölümlerde nelerin bulunması gerektiğini anlaması oldukça zordur, bu nedenle standardın kendisini okumanız gerekir. ancak İngilizce. dil.

Tamam, sonuna kadar okuyanlar için bir bonus var: yıllar önce yazdığım bir teknik spesifikasyon örneği (şimdi uzun süredir analist olarak çalışmıyorum ve diğer daha başarılı örneklerin yayınlanması yasaktır) NDA tarafından halka açık görüntülemeye açılmıştır).

• Sunum: Yuri Buluy Yazılım gereksinimlerinin sınıflandırılması ve standartlarda ve metodolojilerde gösterimi.
• Otomatik bilgi sistemleri gereksinimlerinin analizi. Ders 11: Belgeleme gereksinimleri.
• Yazılım gereksinimleri spesifikasyonunun hazırlanmasına ilişkin kurallar (yorumlarla birlikte okuyun)
• Ekonomik Kalkınma Bakanlığı için AS'nin geliştirilmesine yönelik teknik spesifikasyonlara ve diğer belgelere örnekler
• GOST yönetim tarzı. GOST'a göre teknik özelliklerle doğru çalışmaya ilişkin Gaperton makalesi
• İş Analisti Belge Şablonları

Bana sık sık şu soru soruluyor: "Otomatik bir sistem için teknik özellikler nasıl doğru şekilde geliştirilir?" Teknik spesifikasyonların geliştirilmesi konusu çeşitli forumlarda sürekli olarak tartışılmaktadır. Bu soru o kadar geniştir ki kısaca cevaplamak imkansızdır. Bu nedenle bu konu hakkında uzun bir makale yazmaya karar verdim. Makale üzerinde çalışma sürecinde her şeyi tek bir makaleye sığdırmanın mümkün olmayacağını fark ettim çünkü... Yaklaşık 50 sayfa olacak ve onu 2 parçaya ayırmaya karar verdim:

• İlk bölümde" Teknik spesifikasyonların geliştirilmesi. Nedir, neden gereklidir, nereden başlamalı ve neye benzemelidir?? Konunun sorularını detaylı bir şekilde cevaplamaya çalışacağım, Görev Tanımının yapısını ve amacını ele alacağım ve gereksinimlerin formülasyonu konusunda bazı önerilerde bulunacağım.
• İkinci kısım " Teknik spesifikasyonların geliştirilmesi. Gereksinimler nasıl formüle edilir? Tamamen bir bilgi sistemi için gereksinimlerin belirlenmesine ve formüle edilmesine ayrılacaktır.

Öncelikle “Teknik şartname nasıl geliştirilir?” diye soranların ilgisini çeken sorunun ne olduğunu bulmanız gerekiyor. Gerçek şu ki, teknik şartnamelerin geliştirilmesine yönelik yaklaşım, büyük ölçüde, bunun hangi amaçla yapıldığına ve kim tarafından kullanılacağına bağlı olacaktır. Hangi seçeneklerden bahsediyorum:

• Ticari bir kuruluş, otomatik bir sistem uygulamaya karar verdi. Kendi BT hizmeti yoktur ve şunu yapmaya karar vermiştir: İlgili taraf bir Teknik Şartname geliştirmeli ve bunu geliştirilmek üzere üçüncü bir tarafa sunmalıdır;
• Ticari bir kuruluş, otomatik bir sistem uygulamaya karar verdi. Kendi BT hizmeti vardır. Bunu yapmaya karar verdik: bir Teknik Şartname geliştirin, ardından BT hizmeti ile ilgili taraflar arasında üzerinde anlaşmaya varın ve bunu kendi başımıza uygulayın;
• Devlet kurumu bir BT projesi başlatmaya karar verdi. Buradaki her şey o kadar karanlık ki, pek çok formalite, komisyon, kesinti vb. Bu makalede bu seçeneği dikkate almayacağım.
• Bir BT şirketi, otomatik sistemlerin geliştirilmesi ve/veya uygulanmasına yönelik hizmetler sağlar. Bu en zor durumdur çünkü çeşitli koşullarda çalışmanız gerekir:

  Müşterinin kendi görüşleri olan kendi uzmanları vardır ve bunlar Teknik Şartname için özel gereklilikler hazırlar;

  • Görev tanımı şirket içi geliştiriciler için geliştirildi (müşterinin umurunda değil);
  • Görev tanımı yükleniciye (yani şirket kadrosundaki bir grup programcıya veya bireysel bir uzmana) transfer edilmek üzere geliştirilir;
  • Elde edilen sonuç konusunda firma ile müşteri arasında bir yanlış anlama ortaya çıkıyor ve firma tekrar tekrar şu soruyu soruyor: “Teknik Şartname nasıl geliştirilmeli?” Son durum bir paradoks gibi görünebilir ama doğrudur.
  • Daha az yaygın olan diğer seçenekler de mümkündür;

Okuyucunun artık şu soruları sorması gerektiğini düşünüyorum:

• Teknik Şartname neden her zaman aynı şekilde geliştirilemiyor?;
• Herhangi bir standart, yöntem, öneri var mı? Onları nereden alabilirim?
• Görev Tanımını kim geliştirmelidir? Bu kişinin herhangi bir özel bilgisi olması gerekir mi?
• Görev Tanımının iyi yazılıp yazılmadığı nasıl anlaşılır?
• Kimin pahasına geliştirilmeli ve hatta gerekli mi?

Bu liste sonsuz olabilir. Bunu güvenle söylüyorum çünkü 15 yıldır profesyonel yazılım geliştirme içerisindeyim ve birlikte çalıştığım her geliştirme ekibinde Teknik Özellikler sorusu karşımıza çıkıyor. Bunun nedenleri farklıdır. Görev Tanımının geliştirilmesi konusunu gündeme getirirken, bunu konuyla ilgilenen herkese %100 sunamayacağımın çok iyi farkındayım. Ama dedikleri gibi "her şeyi halletmeye" çalışacağım. Makalelerime zaten aşina olanlar, başkalarının eserlerini “kopyala-yapıştır” kullanmadığımı, başkalarının kitaplarını yeniden basmadığımı, çok sayfalı standartlardan ve internette bulabileceğiniz diğer belgelerden alıntı yapmadığımı biliyorlar. bunları kendi dahiyane düşünceleriniz olarak aktarıyorsunuz. Sadece bir arama motoruna "Teknik Şartname nasıl geliştirilir" yazın; birçok ilginç ama ne yazık ki tekrarlayan şeyleri okuyabilirsiniz. Kural olarak, forumlarda zekice davranmayı sevenler (sadece aramayı deneyin!) hiçbir zaman kendileri uygun bir Teknik Şartname hazırlamamışlar ve bu konuyla ilgili sürekli olarak GOST tavsiyelerinden alıntı yapmışlardır. Ve konu hakkında gerçekten ciddi olanların genellikle forumlarda oturacak vakti yoktur. Bu arada GOST standartlarından da bahsedeceğiz. Yıllar süren çalışmalarım boyunca, hem bireysel uzmanlar hem de seçkin ekipler ve danışmanlık şirketleri tarafından derlenen teknik belgelerin birçok versiyonunu gördüm. Bazen ben de bu aktiviteye giriyorum: Kendime zaman ayırıyorum ve ilgilendiğim bir konu hakkında alışılmadık kaynaklardan (biraz zeka gibi) bilgi araştırıyorum. Sonuç olarak GazProm, Rus Demiryolları ve diğer birçok ilginç şirket gibi canavarlarla ilgili belgeleri görmek zorunda kaldım. Bu belgelerin bana kamuya açık kaynaklardan gelmesine veya danışmanların sorumsuzluğuna (bilgilerin internette yayılmasına) rağmen elbette gizlilik politikasına uyuyorum. Bu nedenle hemen şunu söylüyorum: Başka şirketlere ait gizli bilgileri, kaynağı ne olursa olsun (mesleki etik) paylaşmıyorum.

Teknik şartname nedir?

Şimdi yapacağımız ilk şey bu “Teknik Şartnamenin” nasıl bir canavar olduğunu bulmak olacak.

Evet, faaliyetin bu kısmını (yazılım geliştirme) düzenlemeye çalışan gerçekten GOST'ler ve standartlar var. Bir zamanlar tüm bu GOST'lar alakalıydı ve aktif olarak kullanılıyordu. Şimdi bu belgelerin geçerliliği konusunda farklı görüşler var. Bazıları GOST'ların ileri görüşlü insanlar tarafından geliştirildiğini ve hala geçerli olduğunu iddia ediyor. Diğerleri umutsuzca modası geçmiş olduklarını söylüyor. Belki birileri artık gerçeğin ortada bir yerde olduğunu düşünüyordu. Buna Goethe'nin şu sözleriyle cevap verirdim: “İki karşıt görüş arasında gerçeğin yattığını söylüyorlar. Hiçbir durumda! Aralarında bir sorun var." Dolayısıyla bu görüşler arasında doğruluk payı yoktur. Çünkü GOST'ler modern gelişimin pratik sorunlarını ortaya koymuyor ve onları eleştirenler alternatifler (özel ve sistemik) sunmuyor.

GOST'un açıkça bir tanım bile vermediğini unutmayın, sadece şunu söylüyor: “Bir nükleer santral için TK, otomatik bir sistemin oluşturulmasına (geliştirilmesi veya modernizasyonu - daha sonra oluşturulmasına) uygun olarak gereklilikleri ve prosedürü tanımlayan ana belgedir. Nükleer santralin geliştirilmesinin gerçekleştirildiği ve işletmeye alındıktan sonra kabulünün yapıldığı."

Hangi GOST'lardan bahsettiğimi merak eden varsa işte buradalar:

• GOST 2.114-95 Birleşik tasarım dokümantasyon sistemi. Teknik özellikler;
• GOST 19.201-78 Birleşik program dokümantasyon sistemi. Teknik görev. İçerik ve tasarım gereksinimleri;
• GOST 34.602-89 Bilgi teknolojisi. Otomatik sistemler için standartlar seti. Otomatik bir sistemin oluşturulması için referans şartları.

Wikipedia'da çok daha başarılı bir tanım sunuluyor (sadece yazılım için değil, genel olarak teknik özellikler hakkında da olsa): " Teknik görev- bu orijinal tasarım belgesidir teknik nesne. Teknik görev geliştirilmekte olan nesnenin ana amacını, teknik ve taktik-teknik özelliklerini, kalite göstergelerini ve teknik ve ekonomik gerekliliklerini, dokümantasyon oluşturmanın gerekli aşamalarını (tasarım, teknolojik, yazılım vb.) ve kompozisyonunu tamamlama talimatlarını belirler. yanı sıra özel gereksinimler. Yeni bir şeyin yaratılmasına yönelik ilk belge olarak görev, adı, içeriği, uygulama sırası vb. bakımından farklılık gösteren tüm faaliyet alanlarında mevcuttur (örneğin, inşaatta bir tasarım görevi, bir savaş görevi, ev ödevi, bir sözleşme) bir edebi eser vb.). d.)"

Ve böylece, tanımdan da anlaşılacağı gibi, Teknik Şartnamenin ana amacı, bizim durumumuzda otomatik bir sistem için geliştirilmekte olan nesnenin gerekliliklerini formüle etmektir.

Ana şey bu, ama tek şey. Asıl meseleye inme zamanı geldi: söz verildiği gibi her şeyi "raflara" koymak.

Gereksinimler hakkında bilmeniz gerekenler nelerdir? Tüm gereksinimlerin türe ve özelliklere göre bölünmesi gerektiğini açıkça anlamak gerekir. Şimdi bunu nasıl yapacağımızı öğreneceğiz. Gereksinimleri türe göre ayırmak için GOST bize yardımcı olacaktır. Burada sunulan gereksinim türlerinin listesi, ne tür gereksinimlerin dikkate alınması gerektiğine dair iyi bir örnektir. Örneğin:

• İşlevsellik gereksinimleri;
• Güvenlik ve erişim hakları gereksinimleri;
• Personel niteliklerine ilişkin gereklilikler;
• …. Vesaire. Bahsedilen GOST'ta bunlar hakkında bilgi edinebilirsiniz (ve aşağıda bunlara biraz daha ayrıntılı olarak bakacağım).

Başarılı bir Teknik Şartnamedeki temel faktörün tam olarak iyi formüle edilmiş işlevsellik gereklilikleri olduğunu sizin için açık olduğunu düşünüyorum. Bahsettiğim çalışmaların ve yöntemlerin çoğu bu gereksinimlere adanmıştır. İşlevsellik gereksinimleri, Görev Tanımını geliştirme çalışmasının karmaşıklığının %90'ını oluşturur. Geriye kalan her şey genellikle bu gereklilikleri kapsayan bir “kamuflajdır”. Gereksinimler kötü formüle edilirse, onlara ne kadar güzel kamuflaj koyarsanız koyun başarılı bir proje ortaya çıkmayacaktır. Evet, resmi olarak tüm gereksinimler karşılanacak (GOST J'ye göre), teknik şartname geliştirildi, onaylandı ve imzalandı ve bunun için para alındı. Ve ne? Ve sonra en ilginç kısım başlıyor: ne yapmalı? Bu Devlet Düzeni ile ilgili bir proje ise, o zaman sorun yoktur - oradaki bütçe kimsenin cebine sığmayacak şekildedir ve uygulama sürecinde (varsa) her şey netleşecektir. Proje bütçelerinin çoğunluğu tam da bu şekilde Devlet Emirlerine harcanıyor (“TZ” yazdılar, on milyonlar kaybettiler ama projeyi yapmadılar. Tüm formaliteler yerine getirildi, suçlu taraf yoktu, yeni bir araba yakınlarda) ev. Güzellik!). Ama paranın sayıldığı, farklı bir sonuca ihtiyaç duyulan ticari organizasyonlardan bahsediyoruz. Bu nedenle, asıl meseleyi, nasıl geliştirileceğini anlayalım kullanışlı ve çalışır durumda Teknik özellikler.

Gereksinim türlerinden bahsettim, peki ya özellikler? Gereksinim türleri farklı olabiliyorsa (projenin hedeflerine bağlı olarak), o zaman özelliklerde her şey daha basittir, bunlardan 3 tane vardır:

1. Gereklilik şu şekilde olmalıdır: anlaşılır;
2. Gereklilik şu şekilde olmalıdır: özel;
3. Gereklilik şu şekilde olmalıdır: sınava girenler;

Üstelik son özellik, önceki iki özellik olmadan mümkün değildir, yani. bir tür “turnusol testi”dir. Bir gereksinimin sonucu test edilemiyorsa bu, onun belirsiz olduğu veya spesifik olmadığı anlamına gelir. Bunu düşün. Ustalık ve profesyonellik, gereksinimlerin bu üç özelliğine hakim olmada yatmaktadır. Aslında çok basit. Bunu anladığında.

Bu, Teknik Şartnamenin ne olduğuna dair hikayeyi sonlandırıyor ve asıl konuya geçiyor: gereksinimlerin nasıl formüle edileceği. Ama o kadar hızlı değil. Son derece önemli bir nokta daha var:

• Teknik şartname hangi dilde (anlaşılma zorluğu açısından) yazılmalıdır?
• Çeşitli fonksiyonların, algoritmaların, veri türlerinin ve diğer teknik şeylerin özelliklerini açıklamalı mı?
• Bu arada GOST'larda da bahsedilen teknik tasarım nedir ve Teknik Şartname ile nasıl ilişkilidir?

Bu soruların cevaplarında çok sinsi bir şey gizlidir. Bu nedenle gereksinimlerin yeterliliği veya gerekli ayrıntıların eksikliği, belgenin Müşteri ve Yükleniciler tarafından anlaşılabilirliği, fazlalık, sunum formatı vb. konularda sıklıkla anlaşmazlıklar ortaya çıkar. Görev Tanımı ile Teknik Proje arasındaki çizgi nerede?

Teknik görev- Müşterinin anlayabileceği (sıradan, tanıdık) bir dilde formüle edilmiş gereksinimlere dayanan bir belgedir. Bu durumda Müşterinin anlayabileceği sektör terminolojisi kullanılabilir ve kullanılmalıdır. Teknik uygulamanın ayrıntılarıyla hiçbir bağlantı olmamalıdır. Onlar. Teknik şartname aşamasında prensip olarak bu gereksinimlerin hangi platformda uygulanacağı önemli değildir. İstisnalar olmasına rağmen. Halihazırda var olan bir yazılım ürününe dayalı bir sistemin uygulanmasından bahsediyorsak, o zaman böyle bir bağlantı yalnızca ekran formları, rapor formları vb. düzeyinde gerçekleşebilir. Gereksinimlerin açıklığa kavuşturulması ve formüle edilmesinin yanı sıra geliştirme Görev Tanımı yerine getirilmeli iş analisti. Ve kesinlikle bir programcı değil (bu rolleri birleştirmediği sürece bu olur). Onlar. bu kişi Müşteriyle işinin dilinde konuşmalıdır.

Teknik proje- Bu, Görev Tanımında formüle edilen gerekliliklerin teknik olarak uygulanmasına yönelik bir belgedir. Bu belge veri yapılarını, tetikleyicileri ve saklı prosedürleri, algoritmaları ve gerekli olacak diğer şeyleri açıklamaktadır. teknik uzmanlar. Müşterinin bunu hiçbir şekilde araştırmasına gerek yoktur (bu tür şartlar bile onun için net olmayabilir). Teknik proje yapılır sistem mimarı(Bu rolü bir programcıyla birleştirmek oldukça normaldir). Daha doğrusu, bir mimar tarafından yönetilen bir grup JSC uzmanı. Proje ne kadar büyük olursa, Görev Tanımı üzerinde o kadar çok kişi çalışır.

Pratikte elimizde ne var? Yönetmene, teknik terminoloji, veri türlerinin açıklamaları ve değerleri, veritabanı yapısı vb. ile dolu bir teknik şartnamenin onay için sunulmasını izlemek komik. Onaylaması gerektiği için elbette anlamaya çalışıyor. , satır aralarında tanıdık sözcükler bulmaya çalışmak ve zincirleme iş gereklerini kaybetmemek. Bu tanıdık bir durum mu? Peki nasıl bitiyor? Kural olarak, bu tür teknik özellikler onaylanır, daha sonra uygulanır ve vakaların% 80'inde, yapılan işin gerçeğine hiç uymuyorlar çünkü değiştirmeye karar verdiler, birçok şeyi yeniden yaptılar, yanlış anladılar, yanlış düşündüler vb. ve benzeri. Ve ardından iş teslimiyle ilgili seri başlıyor. "Ama burada ihtiyacımız olan şey bu değil" ama "bu bizim işimize yaramayacak", "bu çok karmaşık", "bu sakıncalı" vb. Tanıdık geliyor mu?!! Bu bana tanıdık geliyor, tümseklere zamanında çarpmam gerekiyordu.

Peki pratikte elimizde ne var? Ancak pratikte, Görev Tanımı ile Teknik Proje arasında bulanık bir sınırla karşı karşıyayız. Çeşitli tezahürlerle TK ve TP arasında süzülüyor. Ve bu kötü. Bunun nedeni kalkınma kültürünün zayıflamasıdır. Bu kısmen uzmanların yeterliliklerinden, kısmen de bütçeleri ve son teslim tarihlerini azaltma arzusundan kaynaklanmaktadır (sonuçta belgeleme çok zaman alır - bu bir gerçektir). Teknik Tasarımın ayrı bir belge olarak kullanımını etkileyen bir başka önemli faktör daha vardır: hızlı geliştirme araçlarının ve geliştirme metodolojilerinin hızlı gelişimi. Ama bu ayrı bir hikaye, aşağıda birkaç kelime söyleyeceğim.

Küçük ama önemli bir nokta daha. Bazen Görev Tanımına, basit ve anlaşılır, küçük bir gereklilik parçası denir. Örneğin, bir nesnenin aramasını bazı koşullara göre iyileştirin, rapora bir sütun ekleyin vb. Bu yaklaşım oldukça haklı, neden hayatı zorlaştırıyor. Ancak büyük projelerde değil, küçük iyileştirmelerde kullanılıyor. Bunun yazılım ürünü bakımına daha yakın olduğunu söyleyebilirim. Bu durumda, Görev Tanımı, gereksinimin uygulanmasına yönelik spesifik bir teknik çözümü de tanımlayabilir. Örneğin, programcı için belirli bir prosedürü ve belirli bir değişikliği belirten "Şöyle bir algoritmada şöyle bir değişiklik yapın". Bu, Görev Tanımı ile Teknik Projeler arasındaki sınırın tamamen silindiği durumdur, çünkü İhtiyaç duyulmayan evrakları şişirmenin ekonomik bir fizibilitesi yoktur, ancak faydalı bir belge yaratılır. Ve bu doğru.

Teknik spesifikasyon gerçekten gerekli mi? Teknik Proje ne olacak?

Aşırı ısınıyor muyum? Bu herhangi bir şey olmadan mümkün mü? Teknik özellikler? Bunun mümkün olduğunu (daha doğrusu mümkün olduğunu) ve bu yaklaşımın pek çok takipçisinin olduğunu ve sayılarının arttığını hayal edin. Kural olarak, genç uzmanlar Scrum, Agile ve diğer hızlı gelişim teknolojileri hakkında kitaplar okuduktan sonra. Aslında bunlar harika teknolojiler ve işe yarıyorlar ama kelimenin tam anlamıyla “teknik görevler yapmaya gerek yok” demiyorlar. "Minimum düzeyde evrak işi", özellikle de gereksiz olanlar, Müşteriye daha yakın olanlar, daha fazla ayrıntı ve daha hızlı sonuçlar diyorlar. Ancak hiç kimse gereksinimlerin kaydedilmesini iptal etmedi ve bu orada açıkça belirtiliyor. Yukarıda bahsettiğim üç dikkat çekici özelliğe göre gereklilikler orada belirleniyor. Sadece bazı insanların zihinleri öyle yapılandırılmıştır ki, eğer bir şey basitleştirilebiliyorsa, o zaman onu tamamen yok olacak kadar basitleştirelim. Einstein'ın dediği gibi " Bunu mümkün olduğu kadar basit hale getirin, ancak bundan daha basit değil. . Bunlar her şeye uyan altın kelimelerdir. Bu yüzden Teknik görev aksi takdirde başarılı bir proje göremezsiniz. Başka bir soru da bunun nasıl oluşturulacağı ve oraya nelerin dahil edileceğidir. Hızlı geliştirme metodolojileri ışığında, yalnızca gereksinimlere odaklanmanız gerekir ve tüm “kamuflaj” bir kenara bırakılabilir. Prensip olarak buna katılıyorum.

Teknik Proje ne olacak? Bu belge çok faydalıdır ve geçerliliğini kaybetmemiştir. Üstelik çoğu zaman onsuz yapamazsınız. Özellikle geliştirme çalışmalarının dış kaynak kullanımı söz konusu olduğunda, ör. dış kaynak kullanımı ilkesine dayanmaktadır. Bunu yapmazsanız aklınızdaki sistemin nasıl görünmesi gerektiği hakkında çok şey öğrenme riskiyle karşı karşıya kalırsınız. Müşteri buna aşina olmalı mı? İstese neden olmasın ama ısrar etmeye, bu belgeyi onaylamaya gerek yok, sadece engel olur ve işe engel olur. Bir sistemi en ince detayına kadar tasarlamak neredeyse imkansızdır. Bu durumda Teknik Tasarımda sürekli değişiklik yapmanız gerekecek ve bu da çok zaman alacaktır. Ve eğer organizasyon ağır bir bürokratikse, o zaman tüm sinirlerinizi orada bırakırsınız. Bu tür tasarımın azaltılması, yukarıda bahsettiğim modern hızlı geliştirme metodolojilerinin tam olarak amacıdır. Bu arada, hepsi zaten yaklaşık 20 yıllık bir yaklaşım olan klasik XP'ye (ekstrem programlama) dayanıyor. Bu nedenle, Müşterinin anlayabileceği, yüksek kaliteli bir Teknik Şartname hazırlayın ve Teknik Tasarımı, sistem mimarı ile programcılar arasındaki ilişki için dahili bir belge olarak kullanın.

Teknik tasarımla ilgili ilginç bir ayrıntı: Konu odaklı tasarım ilkesine göre tasarlanan bazı geliştirme araçları (1C ve benzeri), tasarımın (belgeleme süreci anlamına gelir) yalnızca tüm alt sistemler arasında etkileşimin gerekli olduğu gerçekten karmaşık alanlarda gerekli olduğunu varsayar. En basit durumda, örneğin bir dizin veya belge oluştururken, yalnızca doğru şekilde formüle edilmiş iş gereksinimleri yeterlidir. Bu aynı zamanda bu platformun uzmanların eğitimi açısından iş stratejisiyle de kanıtlanmaktadır. Bir uzmanın (“programcı” değil, buna denir) sınav kartına bakarsanız, yalnızca iş gereksinimlerinin olduğunu ve bunların bir program dilinde nasıl uygulanacağının uzmanın görevi olduğunu göreceksiniz. Onlar. Sorunun Teknik Projenin çözmeyi amaçladığı kısmını, uzmanın yine "kafasında" (orta karmaşıklıktaki görevlerden bahsediyoruz) burada ve şimdi, belirli geliştirme ve tasarım standartlarını izleyerek çözmesi gerekir. platformu için 1C şirketi. Böylece, çalışma sonuçları aynı görünen iki uzmandan biri sınavı geçebilir, diğeri geçemez çünkü geliştirme standartlarını açıkça ihlal etti. Yani uzmanların, sistem mimarlarının katılımı olmadan tipik görevleri bağımsız olarak tasarlayabilecek niteliklere sahip olmaları gerektiği açıkça varsayılmaktadır. Ve bu yaklaşım işe yarıyor.

Şimdi şu soruyu incelemeye devam edelim: "Görev Tanımında hangi gereksinimler yer almalıdır?"

Bilgi sistemi gereksinimlerinin formülasyonu. Görev Tanımının Yapısı

Hemen açık konuşalım: Özellikle bir bilgi sistemi için gereksinimlerin formüle edilmesinden bahsedeceğiz; iş gereksinimlerinin geliştirilmesi, iş süreçlerinin resmileştirilmesi ve önceki tüm danışmanlık çalışmalarının halihazırda tamamlanmış olduğu varsayılmaktadır. Elbette bu aşamada bazı açıklamalar yapılabilir ama sadece açıklamalar. Otomasyon projesinin kendisi iş sorunlarını çözmez - bunu unutmayın. Bu bir aksiyomdur. Bazı yöneticiler, programı satın almaları halinde işin kaotik bir hal alacağına inanarak bunu çürütmeye çalışıyorlar. Ancak bir aksiyom yalnızca bir aksiyomdur; kanıt gerektirmez.

Herhangi bir aktivite gibi, gereksinimlerin formüle edilmesi de aşamalara ayrılabilir (ve bölünmelidir). Her şeyin bir zamanı var. Bu zorlu bir entelektüel çalışmadır. Ve eğer ona yeterince dikkat etmezseniz, sonuç uygun olacaktır. Uzman tahminlerine göre, Görev Tanımını geliştirmenin maliyeti %30-50 olabilir. Ben de aynı fikirdeyim. Her ne kadar 50 belki çok fazla olsa da. Sonuçta Teknik Şartname geliştirilmesi gereken son belge değildir. Sonuçta teknik tasarımın da olması gerekiyor. Bu farklılık, proje ekiplerinin geliştirme sırasında kullandığı farklı otomasyon platformları, yaklaşımları ve teknolojilerinden kaynaklanmaktadır. Örneğin C++ gibi klasik bir dilde geliştirmeden bahsediyorsak o zaman detaylı teknik tasarım olmazsa olmazdır. 1C platformunda bir sistem uygulamaktan bahsediyorsak, yukarıda gördüğümüz gibi tasarımla ilgili durum biraz farklıdır (her ne kadar sıfırdan bir sistem geliştirirken klasik şemaya göre tasarlanmış olsa da).

Gereksinimler beyanı ana kısım olmasına rağmen Teknik özellikler ve bazı durumlarda teknik şartnamenin tek bölümü haline geliyor, bunun önemli bir belge olmasına dikkat etmeli ve buna göre hazırlanmalıdır. Nereden başlamalı? Öncelikle içerikten başlamanız gerekiyor. İçeriği yazın ve ardından genişletmeye başlayın. Şahsen bunu yapıyorum: önce içeriğin taslağını çiziyorum, hedefleri, tüm giriş bilgilerini tanımlıyorum ve sonra ana kısma - gereksinimlerin formülasyonuna iniyorum. Neden tam tersi olmasın? Bilmiyorum, benim için daha uygun. Birincisi, bu çok daha küçük bir zaman dilimidir (gereksinimlerle karşılaştırıldığında) ve ikincisi, tüm giriş bilgilerini anlatırken asıl konuya odaklanırsınız. Peki kim beğenirse. Zamanla kendi Teknik Şartname şablonunuzu geliştireceksiniz. Başlangıç ​​​​olarak, tam olarak GOST'ta açıklananı içerik olarak almanızı öneririm. İçerik için mükemmel! Daha sonra, aşağıdaki üç özelliğin önerilerini unutmadan, her bir bölümü alıp açıklamaya başlıyoruz: anlaşılabilirlik, özgüllük ve test edilebilirlik. Neden bu konuda bu kadar ısrar ediyorum? Bir sonraki bölümde bununla ilgili daha fazla bilgi vereceğiz. Ve şimdi GOST'ta önerilen teknik spesifikasyonların bu noktalarını gözden geçirmeyi öneriyorum.

1. Genel bilgi;
2. sistemin yaratılmasının (geliştirilmesinin) amacı ve hedefleri;
3. otomasyon nesnelerinin özellikleri;
4. sistem gereksinimleri;
5. sistemi oluşturmak için işin bileşimi ve içeriği;
6. sistemin kontrol ve kabul prosedürü;
7. sistemi işletmeye almak için otomasyon nesnesini hazırlamak için işin bileşimi ve içeriğine ilişkin gereksinimler;
8. dokümantasyon gereksinimleri;
9. geliştirme kaynakları.

Toplamda 9 bölüm olup, her biri kendi içinde alt bölümlere ayrılmıştır. Sırasıyla bunlara bakalım. Kolaylık sağlamak için, her öğe için her şeyi bir tablo şeklinde sunacağım.

Bölüm 1. genel bilgiler.

Bölüm 2. Sistemin oluşturulmasının (geliştirilmesinin) amacı ve hedefleri.

Genel olarak hedefleri belirleme, bunları formüle etme ve bir hedef ağacı oluşturma yeteneği tamamen ayrı bir konudur. Önemli olanı unutmayın: Nasıl yapılacağını biliyorsanız yazın, emin değilseniz hiç yazmayın. Hedefleri formüle etmezseniz ne olur? Gereksinimlere göre çalışacaksınız, bu sıklıkla uygulanmaktadır.

Bölüm 3. Otomasyon nesnelerinin özellikleri.

Bölüm 4. Sistem Gereksinimleri

GOST, bu tür gereksinimlerin listesini çözer:

• sistemin yapısı ve işleyişine ilişkin gereksinimler;
• sistem personelinin sayısı ve nitelikleri ile bunların çalışma şekline ilişkin gereklilikler;
• hedef göstergeleri;
• güvenilirlik gereksinimleri;
• güvenlik gereksinimleri;
• ergonomi ve teknik estetik gereksinimleri;
• mobil hoparlörler için taşınabilirlik gereksinimleri;
• sistem bileşenlerinin çalıştırılması, bakımı, onarımı ve depolanmasına ilişkin gereksinimler;
• bilgileri yetkisiz erişime karşı korumaya yönelik gereksinimler;
• kaza durumunda bilgi güvenliği gereklilikleri;
• dış etkenlerden korunma gereklilikleri;
• patent saflığı gereksinimleri;
• standardizasyon ve birleştirme gereklilikleri;

Ana bölümün kesinlikle özel gereksinimleri olan (işlevsel) bölüm olacağı gerçeğine rağmen, bu bölüm de büyük önem taşıyabilir (ve çoğu durumda öyledir). Neler önemli ve yararlı olabilir:

• Kalite gereksinimleri. Geliştirilmekte olan sistemin uzmanların yeniden eğitilmesini gerektirmesi mümkündür. Bunlar hem gelecekteki sistemin kullanıcıları hem de onu desteklemek için ihtiyaç duyulacak BT uzmanları olabilir. Bu konuya yeterince dikkat edilmemesi sıklıkla sorunlara yol açar. Mevcut personelin nitelikleri açıkça yetersizse, eğitimin organizasyonu, eğitim programı, zamanlaması vb. için gereksinimlerin belirlenmesi daha iyidir.
• Bilgilerin yetkisiz erişime karşı korunmasına yönelik gereksinimler. Burada yorum yok. Bunlar tam olarak verilere erişimi sınırlamak için gereken gereksinimlerdir. Bu tür gereksinimler planlanmışsa, bunların ayrı ayrı, mümkün olduğunca ayrıntılı olarak, işlevsel gereksinimlerle aynı kurallara göre (anlaşılabilirlik, özgüllük, test edilebilirlik) yazılması gerekir. Bu nedenle bu gereksinimler işlevsel gereksinimler bölümüne dahil edilebilir.
• Standardizasyon gereksinimleri. Projeye uygulanabilir tasarım standartları varsa bunlar gereksinimlere dahil edilebilir. Kural olarak bu tür gereksinimler Müşterinin BT hizmeti tarafından başlatılır. Örneğin, 1C şirketinin program kodunun tasarımı, arayüz tasarımı vb. için gereksinimleri vardır;
• Sistemin yapısı ve işleyişi için gereklilikler. Burada sistemlerin birbirleriyle entegrasyonuna yönelik gereksinimler açıklanabilir ve genel mimarinin bir açıklaması sunulur. Entegrasyon gereksinimleri genellikle ayrı bir bölüme, hatta ayrı bir Teknik Şartnameye ayrılır, çünkü bu gereksinimler oldukça karmaşık olabilir.

Diğer tüm gereksinimler daha az önemlidir ve açıklanması gerekmez. Benim düşünceme göre, bunlar yalnızca belgeleri daha ağır hale getiriyor ve pratik faydaları çok az. Ergonomik gereksinimleri genel gereksinimler biçiminde tanımlamak çok zordur, bunları işlevsel olanlara aktarmak daha iyidir. Örneğin “Tek tuşa basarak bir ürünün fiyatı hakkında bilgi alın” şartı formüle edilebilir. Benim düşünceme göre bu, ergonomi ile ilgili olsa da, yine de spesifik fonksiyonel gereksinimlere daha yakındır.Sistemin gerçekleştirdiği işlevlere (görevlere) ilişkin gereksinimler Başarıyı belirleyecek ana ve kilit nokta budur. Her şey mükemmel yapılsa ve bu bölüm “3” olsa bile, projenin sonucu en iyi ihtimalle “3” olacaktır, hatta proje tamamen başarısız olacaktır. Bültenimizin 5. sayısında yer alacak olan ikinci yazımızda bunu daha detaylı ele alacağız. Bahsettiğim “gerekliliğin üç özelliği kuralı” bu noktada geçerlidir.

GOST aşağıdaki türleri tanımlar:

• Matematiksel
• Bilgilendirici
• Dilbilimsel
• Yazılım
• Teknik
• Metrolojik
• Organizasyonel
• metodik
• ve diğerleri…

İlk bakışta bu gereksinimler önemsiz görünebilir. Çoğu projede bu doğrudur. Ama her zaman değil. Bu gereksinimler ne zaman açıklanmalıdır:

• Hangi dil (veya platform) gelişiminin gerçekleştirileceğine ilişkin herhangi bir karar alınmadı;
• Sistem çok dilli bir arayüz gerektirir (örneğin Rusça/İngilizce)
• Sistemin işleyebilmesi için ayrı bir birimin oluşturulması ya da yeni çalışanların işe alınması gerekiyor;
• Sistemin çalışabilmesi için Müşterinin çalışma yöntemlerinde değişiklik yapılması ve bu değişikliklerin belirtilmesi ve planlanması gerekir;
• Herhangi bir ekipmanla entegrasyon bekleniyor ve ona gereksinimler (örneğin sertifikasyon, uyumluluk vb.)
• Diğer durumlar da mümkündür; bunların hepsi projenin belirli hedeflerine bağlıdır.

Bölüm 5. Sistemi oluşturmaya yönelik çalışmanın bileşimi ve içeriği

Bölüm 6. Sistemin kontrol ve kabulüne ilişkin prosedür

İşin aşamalar halinde kabulüne ilişkin genel gereklilikler (katılımcı kuruluş ve kuruluşların listesi, yer ve zamanlama), kabul belgelerinin koordinasyonu ve onaylanması prosedürü; İşin sunulması ve sistemin kontrol edilmesi prosedürünün sorumluluğunu almanızı şiddetle tavsiye ederim. Test edilebilir gereksinimlere tam olarak bu yüzden ihtiyaç duyulmaktadır, ancak işin kabulü ve devrine ilişkin prosedür açıkça belirtilmemişse, sistem teslim edildiğinde test edilebilir gereksinimlerin varlığı bile yeterli olmayabilir. Örneğin, yaygın bir tuzak: sistem inşa edilmiş ve tamamen çalışır durumdadır, ancak Müşteri bazı nedenlerden dolayı bu sistemde çalışmaya hazır değildir. Bu nedenler herhangi biri olabilir: zaman yok, hedefler değişmedi, birisi istifa etti vb. Kendisi de şöyle diyor: “Yeni sistemde henüz çalışmadığımız için çalıştığından emin olamıyoruz.” Öyleyse işin aşamalarını doğru bir şekilde tanımlamayı ve bu aşamaların sonuçlarını nasıl kontrol edeceğinizi öğrenin. Üstelik bu yöntemlerin Müşteri için en başından itibaren açık olması gerekir. Teknik Şartname düzeyinde sabitlenmişlerse, gerektiğinde her zaman onlara başvurabilir ve aktarımla işi tamamlayabilirsiniz.

Bölüm 7. Sistemin devreye alınması için otomasyon nesnesinin hazırlanmasına yönelik işin bileşimi ve içeriğine ilişkin gereklilikler

Şirket tarafından benimsenen (veya planlanan) bilgilerin girilmesine ilişkin başka kurallar da olabilir. Örneğin, bir sözleşmeye ilişkin bilgiler önceden herhangi bir biçimde metin dizisi olarak girilirken artık ayrı bir sayı, ayrı bir tarih vb. istenmektedir. Bunun gibi birçok durum olabilir. Bazıları personel tarafından dirençle algılanabilir, bu nedenle tüm bu tür durumların veri giriş sırasına göre gereksinimler düzeyinde kaydedilmesi daha iyidir.

Oluşturulan sistemin teknik şartnamede yer alan gerekliliklere uygunluğunun garanti edildiği otomasyon nesnesinin işleyişi için koşulların oluşturulması.Gerekebilecek her türlü değişiklik. Örneğin şirketin yerel bir ağı yok, sistemin çalışmayacağı eski bir bilgisayar filosu yok.

Belki de gerekli bazı bilgiler kağıt üzerinde işlendi ve şimdi sisteme girilmesi gerekiyor. Bunu yapmazsanız, bazı modüller vb. çalışmayacaktır.

Belki bir şey basitleştirildi, ancak şimdi daha ayrıntılı olarak dikkate alınması gerekiyor, bu nedenle birisinin belirli kurallara göre bilgi toplaması gerekiyor.

Bu liste uzun olabilir, projenizin özel durumuna bakın: Sistemin işleyişi için gerekli departmanların ve hizmetlerin oluşturulması;

Personel alımı ve eğitim için zamanlama ve prosedür Bu konuyu daha önce konuşmuştuk. Belki de sistem daha önce var olmayan yeni bir yapı veya faaliyet türü için geliştirilmektedir. Uygun personel ve hatta eğitimli personel yoksa sistem ne kadar ustalıkla kurulursa kurulsun çalışmayacaktır.

Bölüm 8. Dokümantasyon Gereksinimleri

Kullanım kılavuzlarının nasıl sunulacağını düşünün.

Belki de Müşteri kurumsal standartları kabul etmiştir, bu da onlara başvurmamız gerektiği anlamına gelir.

Dokümantasyon gereksinimlerinin göz ardı edilmesi çoğu zaman projelerde en beklenmedik sonuçlara yol açar. Mesela her şey yapıldı ve her şey çalışıyor. Kullanıcılar ayrıca nasıl çalışacaklarını da biliyorlar. Dokümantasyon konusunda herhangi bir anlaşma veya görüşme yapılmadı. Ve birden işi teslim ederken, Müşterinin projeye bile katılmayan ancak işin kabulünde yer alan üst düzey yöneticilerinden biri size şunu sorar: "Kullanım kılavuzları nerede?" Ve sizi kullanım kılavuzlarının mevcudiyeti konusunda anlaşmaya varmaya gerek olmadığına ikna etmeye başlıyor, bu "elbette" sözde ima ediliyor. İşte bu, işini elinden almak istemiyor. Yönergeleri kimin pahasına geliştireceksiniz? Pek çok takım bu kancaya çoktan düştü.

Bölüm 9. Geliştirme Kaynakları

Bu nedenle, anket raporuna ve kilit kişilerin gereksinimlerine başvurmak daha iyidir.

Bu yüzden İş Tanımına dahil edilebilecek tüm bölümleri değerlendirdik. Kesinlikle "Yapılabilir" ve "Zorunludur" çünkü herhangi bir belgenin bir sonuca ulaşmak için geliştirilmesi gerekir. Dolayısıyla belirli bir bölümün sizi sonuca yaklaştırmayacağı aşikarsa, o zaman buna ihtiyacınız yoktur ve üzerinde zaman harcamanıza gerek yoktur.

Ancak hiçbir yetkili teknik spesifikasyon asıl şey olmadan yapamaz: işlevsel gereksinimler. Pratikte bu tür Teknik Şartnamelerin ortaya çıktığını ve nasıl olduğunu belirtmek isterim! Tüm bölümlerde suları ayırabilecek, genel gereksinimleri genel hatlarıyla anlatabilecek kişiler var ve belge çok ağır çıkıyor ve içinde çok fazla akıllıca kelime var, hatta Müşterinin hoşuna gidebilir. (yani onaylayacaktır). Ama buna göre çalışmayabilir, yani. Pratik kullanımı çok azdır. Çoğu durumda, bu tür belgeler, özellikle Görev Tanımı için çok para almanız gerektiğinde doğar, ancak bunun hızlı bir şekilde ve ayrıntılara dalmadan yapılması gerekir. Ve özellikle işin daha ileri gitmeyeceğini veya bunu tamamen farklı kişilerin yapacağı biliniyorsa. Genel olarak sadece bütçeyi, özellikle de devlet bütçesini yönetmek için.

İkinci makalede yalnızca 4. bölüm "Sistem gereksinimleri" hakkında konuşacağız ve özellikle açıklık, spesifiklik ve test edilebilirlik nedenleriyle gereksinimleri formüle edeceğiz.

Neden gereksinimler açık, spesifik ve test edilebilir olmalıdır?

Çünkü uygulama şunu gösteriyor: İlk başta, uzmanlar tarafından geliştirilen teknik özelliklerin çoğu ya talep edilmiyor (gerçeğe uymuyor) ya da bunları uygulaması gereken kişi için sorun haline geliyor, çünkü Müşteri belirsiz şart ve gereksinimleri manipüle etmeye başlar. Hangi ifadelerle karşılaşıldığına, bunun nelere yol açtığına dair birkaç örnek vereceğim, ardından bu tür sorunların nasıl önlenebileceğine dair öneriler vermeye çalışacağım.

Yazardan: Nasıl yazılır web sitesi geliştirme için görev tanımı (TOR)? Konu oldukça kapsamlı ve tek bir not çerçevesinde (mümkünse) %100 analiz etmek zor. Ancak bir web sitesinin kullanım koşullarını hazırlarken nelere dikkat edilmesi ve nelere dikkat edilmesi gerektiğine ilişkin genel hükümleri yeterince detaylı bir şekilde özetlemeye çalışacağım.

Yani, web sitesi geliştirme için teknik özellikler

Teknik şartname geliştirici için hazırlanır. Müşteri ile yüklenici arasında bir anlaşma hazırlanırken görev tanımına atıfta bulunulmalıdır. Her iki tarafın da puanları ve son teslim tarihlerini yerine getirmemesi veya yanlış yerine getirmesi sorumluluğu belirlenmelidir. Ancak teknik şartnamelerin oluşturulduğu en önemli şey (bence) proje geliştirme sürecini hızlandırmak.

Bu örneği analiz edelim:

Web sitenizin yan tarafında bir yerde bir takvime ihtiyacınız olduğunu varsayalım. Küçük bir şeymiş gibi görünüyordu. Ancak işlevselliğini ne kadar ayrıntılı açıklarsanız, sonucu o kadar hızlı alırsınız.

Burada biraz açıklayayım. İçinde bulunulan ayın haftasının gününe göre sayıları gösteren bir takvim var. Ve aylar arasında geçiş yapma yeteneği var. Aylar ve yıllar arasında geçiş yapma yeteneğine sahip bir takvim var.

JavaScript. Hızlı başlangıç

Diyelim ki, geçerli tarihin vurgulandığı ikinci seçeneği (aylar ve yıllar arasında gezinme olanağı sunan) istediğinizi varsayalım. Belirttiğiniz referans şartlarında: "kenar çubuğunda bir takvime ihtiyaç var." Size ilk seçeneği veriyorlar (sadece geçerli ayın haftasının gününe göre sayıları gösteriyor).

Neyimiz var. Yüklenici şartnameyi yerine getirdi, ancak siz tamamen farklı bir şey istediniz. Her şey yolunda görünüyor, suçlanacak kimse yok, çatışma yok ama en önemli şey kayboluyor zaman ve para.

Bu sadece sıradan bir takvim örneğidir.

Peki ya takvimde olduğu gibi işlenmesi yarım günden fazla süren daha ciddi bir şeyi yeniden yapmak zorunda kalırsanız? Yüklenici projenizi bitirip yeni bir projeye başlayabilecekken sizinle meşgul.

Bu nedenle, daha daha fazla detay Her modülün işlevselliğini anlatırsanız sonuca o kadar hızlı ulaşırsınız. Her iki tarafın da bununla ilgilenmesi gerekiyor.

Teknik şartname genellikle hangi noktalardan oluşur?

Bir şirketin veya firmanın sahibi olduğunuzu düşünelim. Firmanız her türlü ürünün üretimi ve satışı ile uğraşmaktadır. Alıcılarınız var. Satıcılarla (mağazalar ve çevrimiçi mağazalar), hizmet merkezleriyle ve ürün tüketicileriyle işbirliği yaparsınız. Veya böyle bir firmaya kaynak yapıyorsunuz ve teknik şartname yazmanız gerekiyor.

Hangi rolü oynarsanız oynayın, bir web sitesi tasarımı oluşturmak için teknik şartnameler hazırlamadan önce yapmanız gereken ilk şey, organizasyonun yapısını, ne yaptığını, isimlendirmesini, özelliklerini ve genel olarak ürünle bağlantılı her şeyi incelemektir. ve şirket. Kaynağa ne olacağı, müşterinin işletmede olup bitenlerin özünü ne kadar derinlemesine anladığına bağlıdır. Bu nedenle buradaki görev karşılıklıdır: Müşteri işletmeyi mümkün olduğunca ayrıntılı olarak anlatmalı ve yüklenici olup bitenlerin özünü iyice anlamalıdır.

Projenizi yapacak şirket için teknik şartnameyi kendiniz yazıyor olsanız bile, hepsini bir kağıt parçası üzerinde çözmek iyi bir fikirdir.

Nokta nokta gidelim.

Tanım

Buraya şirket ve ne yaptığı hakkında birkaç cümle yazabilirsiniz. Giriş gibi bir şey yapın.

kimin için - hedef kitle:

Potansiyel Alıcılar

ürün satıcıları (mağazalar, çevrimiçi mağazalar)

servis merkezleri

ortaklar (firmalar)

Ürünlerin tüketicileri (zaten satın almış olanlar)

Neden bir web sitesine ihtiyacınız var:

Şirketin imajını iyileştirmek için

Satışları artırmak için

Müşteri rahatlığı için

Kurumsal

Web sitesi – kartvizit

Online mağaza

Dil versiyonları:

İngilizce

Sitenin bazı sorunları çözmesi gerekiyor. Buna göre amaç ve hedeflere doğru ilerliyoruz.

Amaçlar ve hedefler

Teknik şartnamenin bu bölümünde hedef kitlenin tamamını inceliyor ve sitenin onlar için çözmesi gereken görev yelpazesini açıklıyoruz.

Potansiyel ürün alıcıları.

Hedef: daha fazla alıcı çekin ve onları ilk satın almalarını yapmaya ikna edin, seçim yapmalarına yardımcı olun.

Sorunların çözülmesi gerekiyor:

Ürünler, ek hizmetler, garantiler, hizmet ve seçim yöntemleri hakkında yüksek kaliteli, kapsamlı bilgiler sağlayın.

Showroomlar hakkında bilgi verin

Perakende ağı hakkında bilgi sağlayın

Ürün seçme ve satın alma konularında şirket uzmanları tarafından potansiyel alıcılara çevrimiçi danışmanlık düzenleyerek soru sorma fırsatı sağlayın.

Böylece hedef kitlenin tamamının üzerinden geçiyoruz. Ayrıca ürün satıcıları (mağazalar, çevrimiçi mağazalar), hizmet merkezleri, ortaklar (firmalar) ve ürün tüketicileri için amaç ve hedefleri de açıklıyoruz. Yani sitenin her biri için özel olarak yapması gereken şey.

Şimdi modülleri listeliyoruz.

Site işlevselliği

İşlevselliği listelemek için neye ihtiyacı olduğuna karar vermeniz gerekir:

Kayıt gerekli mi?

Kapalı bir bölüme ihtiyacım var mı (sadece kayıtlı kullanıcılar için)

Geri bildirim formu gerekli mi?

Vesaire. ve benzeri.

JavaScript. Hızlı başlangıç

Bir web uygulamasının nasıl oluşturulacağına ilişkin uygulamalı bir örnekle JavaScript'in temellerini öğrenin.

Bütün bunları anlattıktan sonra en önemli ve ilginç şeye geliyoruz. Elbette yukarıda yapılan tüm çalışmalar çok önemli ama artık durum daha da kızışıyor.

İşlevselliğin açıklaması

Şu anda sitenin kime yönelik olduğunu, hangi amaç ve hedefleri yerine getirmesi gerektiğini ve ek işlevlerini biliyoruz.

Toplanan tüm bilgileri sisteme getirip güzelce düzenlemeniz gereken zaman geldi. Görevi kolaylaştırmak ve tekerleği yeniden icat etmemek için benzer konulardaki kaynaklara bakabilirsiniz. Onlardan bir şeyler alın, işlevlerine bakın ve deneyin ve uygunsuz görünen şeyleri projenizde geliştirmeye çalışın. Prensip olarak, teknik şartnamelerin hazırlanmasının en başında benzer konulardaki sitelere bakabilirsiniz (ve deneyiminiz yoksa, o zaman buna ihtiyacınız bile vardır).

Menü öğeleriyle başlamanızı öneririm. Ana sayfaları görüntülemesi ve her ziyaretçinin kendisi için hızlı bir şekilde bilgi bulmasını sağlaması gerekiyor. Ziyaretçiler de hedef kitlemizdir. Menü birçok öğeyi içerecek, dolayısıyla açılır liste biçiminde olacaktır.

Öncelikle bize firmadan bahsetmeniz gerekiyor. Şirketle ilgili sayfalar, şirket geçmişi, kişiler, incelemeler olabilir.

Doğal olarak, "ürün kataloğu", "sürümler", "ürün incelemeleri" alt öğeleriyle birlikte bir "ürünler" menü öğesi bulunmalıdır.

Genel olarak, umarım nasıl tanımlanacağı açıktır. Olası menünün son halini sunayım:

Şirket hakkında

şirketin geçmişi

kişiler

ürünler

Ürün kataloğu

ürün incelemeleri

servis bölümü

Garanti hizmeti

garanti sonrası servis

tüketiciye

satın alma ve teslimat

kullanmak

hizmet hakkında

mağazalar ve çevrimiçi mağazalar

ürün fotoğrafları

SSS

servis merkezleri

Nasıl servis merkezi olunur?

SSS

ortaklar

işbirliğine davet

SSS

Menüyü halletmiş gibiyiz. Şimdi her sayfada ne olacağını ve her şeyin nasıl çalıştığını açıklamanız gerekiyor. Ayrıca yaklaşık bir düzen sağlayın. Bir kağıda kurşun kalemle çizilebilir, taranabilir ve teknik şartnameye eklenebilir. Söyleyeceğim tek şey, tasarımcının hayal gücünü sınırlamayın, onu en genel haliyle çizin.

Bu kısım sayfanızın nasıl görünmesini istediğinize bağlı olarak değişir. Belki üstte bu kadar banner'a ihtiyacınız yok, belki de kişileri (adres, telefon, faks) üstte belirtmeniz gerekiyor, belki "site haritası", "ev", "kişiler" simgeleri şeklinde. Belki sol tarafta haberlere ihtiyacınız yok ama sol tarafta “promosyonlar ve yeni çıkanlar”ı göstermelisiniz.

Şimdi asıl mesele işin mantığını anlatmak.

Çalışma mantığı

Yukarıdaki resme dayanarak anlatacağım.

Başlık her sayfada aynı kalır. Haber akışı yalnızca ana sayfada görünür. Soldaki ikincil sayfalarda o anda içinde bulunduğumuz ürünün menü alt öğelerini gösteriyoruz (örneğin, “müşteri hizmetleri” sayfasındaysak “garanti servisi”, “garanti sonrası servis” bağlantılarını gösteriyoruz) ”). Buna göre, bu bağlantılara tıklamak ilgili sayfalara yönlendirir. Burada soldaki alt öğeler altında çevrimiçi danışmanlarla (Skype, ICQ) iletişim kurmaya yönelik verileri görüntülüyoruz. Promosyonlar ve sürümler bloğu her sayfada kalır. Altbilgi her sayfada aynı şekilde görüntülenir.

İşin genel mantığı kabaca bu şekilde anlatılıyor.

Şimdi, web sitesi geliştirme referans şartlarımızda, sitenin belirlenen her bloğunu ayrıntılı olarak açıklıyoruz. Örneğin, “Haber Kaynağı”.

En son 10 haberin “Haber akışı”. Her haber; haber başlığı, yayın tarihi, haberin kısa bir başlangıcı (4-5 satır) ve “tamamını oku” bağlantısından oluşmalıdır. “Tamamını oku” linkine tıkladığınızda haber sayfasına yönlendirileceksiniz. Karşılaştığınız haberler ana içeriğin yerine görüntülenir. Ayrıca haberin başlığı ve yayınlanma tarihi de yer alır. Haber akışı da solda görüntülenir. Geçmiş aylara ve yıllara ait haberler arşivlenir. Yani içinde bulunduğumuz aya ait haberlerin altında “(şu ay veya yıl) arşivi”ni gösteriyoruz. “(Şu ay veya yıla ait) arşivle” linkine tıkladığınızda ilgili aya/yılın haber listesi açılır.

Her bloğun işleyişini bu şekilde açıklıyoruz. Takvim olayını unutmayalım. Ve en önemlisi ürün kataloğunun çalışmasını anlatmanız gerekiyor. Burada size bir görev veriyorum: Kataloğun nasıl çalışacağını iyice düşünmeye ve açıklamaya çalışın. Seçeneklerinizi e-postayla gönderin. En iyisini yayınlayacağız.

Başka ne olmalı? Uyumluluğu belirtmek güzel olurdu.

Uyumluluk

Bir web sitesi oluşturmaya ilişkin görev koşullarımızın bu paragrafında, web sitesinin hangi işletim sistemlerinde ve hangi tarayıcılarda eşit derecede iyi görünmesi gerektiğini belirtiyoruz. Hangi versiyonda, hangi dilde yazılmalıdır. Hangi CMS'nin kullanıldığı. Eğer gerçekten neden bahsettiğinizi biliyorsanız, bunu belirtmekte fayda var.

Bu soruları bilmiyorsanız sitenin doğru görüntülenmesi gereken tarayıcıları belirtmeniz yeterlidir. Geri kalanı için sanatçının vicdanına güvenin.

Çözüm

Bu yazımda teknik şartnamelerin bu şekilde derlendiğini ve başka bir şekilde olmadığını göstermeye çalışmadım. Bunu yapın ve hiçbir sorun olmayacak. Niteliksel bir kompozisyon oluşturun web sitesi geliştirme için referans şartları- bu daha çok bir soru deneyim. İlk birkaç yılda herkes yetkin bir teknik şartname oluşturamayacaktır.

Bu yazıda bir web sitesinin tasarımını ve mantığını geliştirmeye yönelik örnek bir teknik şartnamenin oluşturulduğu örnek ve ilkelerin yanı sıra dikkat edilmesi gereken ana noktaları göstermek istedim. Ne kadar başarılı olduğumu umarım yorumlarınızdan öğrenebilirim.

Ve görevi unutma!