مشخصات فنی صحیح برای توسعه نرم افزار راز یک پروژه موفق است. توسعه مشخصات فنی. چیست، چرا لازم است، از کجا شروع کنیم و چگونه باید باشد؟ وظیفه توسعه مشخصات فنی

مشخصات فنی چیست؟ چگونه این کار را انجام دهیم و برای چیست؟ مثال ها، نمونه ها، نکات و توصیه ها.

به نظر می رسد چقدر عالی است وقتی کسی شما را کاملاً درک می کند. شما چند عبارت را بیان کردید و این دقیقاً همان چیزی است که تصور می کردید. متاسفانه اینطوری کار نمیکنه

مشکل ادراک اطلاعات ابدی است. اثر "تلفن خراب" یک اتفاق رایج است. اما اگر به سادگی ندانید که چگونه یک وظیفه را تعیین کنید چه؟ بله، این نیز اتفاق می افتد و شما باید به نوعی با آن کار کنید، اما چگونه؟ برای اطمینان از اینکه نتایج کارهایی که تعیین می کنید مطابق انتظارات شماست، یک مشخصات فنی بنویسید.

مشخصات فنی چیست

مشخصات فنی (یا TOR) سندی است که شامل الزامات مشتری برای محصولات یا خدمات ارائه شده توسط پیمانکار است. به عبارت ساده: من می خواهم هفت خط عمود بر هم داشته باشم، و همچنین برخی را با رنگ قرمز بکشم، و برخی را با رنگ بی رنگ بکشم (توصیه می کنم در پایان مطلب ویدیویی در مورد این موضوع تماشا کنید).

واحد طراحی

این سند می تواند یک صفحه A4 یا یک جلد کامل را اشغال کند، همه اینها به وظایف و خواسته هایی بستگی دارد که در آن گنجانده شده است. به عنوان مثال، می توانید مشخصات فنی برای یک صفحه فرود کوچک (وب سایت یک صفحه ای) یا برای نرم افزار پیچیده با یادگیری ماشین و سایر ویژگی ها بنویسید.

چرا به مشخصات فنی نیاز دارید؟

• برای تعیین وظایف به مجریان.
• برای توصیف جزئیات آنچه می خواهید در پایان به دست آورید.
• برای توافق بر سر ترتیب کار.
• ارزیابی و پذیرش کار پس از اجرا.
• به ... (گزینه های خود را در نظرات اضافه کنید).

در واقع، اهداف و مزایای مشخصات فنی بسیار بیشتر از لیست بالا است. برای من شخصا، اصلی ترین وظیفه ای که مشخصات فنی حل می کند، اجرای آنچه که نیاز دارم با حداقل انحراف از انتظارات (انتظارات من) است.

به لطف مشخصات فنی، همیشه می توانید در مورد زمان اجرا، هزینه و مطابقت با مشخصات اعلام شده محصول یا خدمات نهایی سوال کنید.

در واقع این یک سند جدی است که توسط مشتری و پیمانکار تنظیم می شود. تا حدی که مجازات ها و تعهدات طرفین مقرر شده باشد. تعدادی GOST وجود دارد، در Habré بیشتر بخوانید.

توسعه مشخصات فنی

اگر ما در مورد یک بازی "بزرگسالان" صحبت می کنیم، به عنوان مثال، یک کار فنی برای توسعه یک برنامه تلفن همراه یا وب سایت، پس این یک کار جداگانه است که برای آن پول زیادی پرداخت می شود. شما فردی را جذب می کنید که معمولاً یک مدیر فنی سابق یا فعلی است و از او می خواهید که به شما کمک کند.

داشتن ریش اختیاری است

بسته به محدوده پروژه/وظایف، این شخص تمام «خواسته‌های» شما را جمع‌آوری می‌کند، آن‌ها را به زبان فنی ترجمه می‌کند، شاید طرح‌هایی را آماده کند (تقریباً چه شکلی باید باشد) و سند تمام شده را به شما می‌دهد. در مرحله بعد، این سند را به مجریان (تیمی در شرکت یا برون سپاری شده) تحویل می دهید، روی پول، ضرب الاجل ها توافق می کنید و دست به کار می شوید.

نکته: CTO باید در تیم شما باشد، در غیر این صورت به احتمال زیاد چیزی را در طول فرآیند اجرا از دست خواهید داد. شما به سادگی برای همه چیز دانش کافی ندارید. هر کس در نوشتن مشخصات فنی شرکت کرده است آن را بررسی می کند.

مشخصات فنی شامل چه مواردی است؟

همه چیز به قالبی که انتخاب می کنید بستگی دارد (کمی بیشتر پیوندهایی به الگوها/نمونه ها می دهم)، اما بلوک های اساسی وجود دارد که در مشخصات فنی گنجانده شده است:

1. شرح پروژه/وظیفه. ما به طور خلاصه می نویسیم که پروژه یا وظیفه ای که باید تکمیل شود چیست.
2. هدف و اهداف. اهداف پروژه چیست؟
3. الزامات. طراحی، عملکردها، فن آوری های مورد نیاز.
4. شرح کار. چه، چه زمانی و چگونه انجام خواهد شد.
5. مراحل کنترل و پذیرش نحوه پذیرش کار، چه چیزی را می توان تکمیل شده در نظر گرفت.
6. برنامه های کاربردی. طرح ها، طرح ها، نمونه های اولیه.

هزینه کار معمولاً در پیوست جداگانه ای به قرارداد درج می شود، اما زمانی اتفاق می افتد که طرفین مبلغ را در مشخصات فنی خود مشخص کنند.

با عرض پوزش برای قطع خواندن. به کانال تلگرام من بپیوندید. اعلامیه های جدید مقالات، توسعه محصولات دیجیتال و هک رشد، همه چیز وجود دارد. در انتظار شما! بیا ادامه بدهیم...

نمونه هایی از مشخصات فنی

با وجود این واقعیت که توسعه مشخصات فنی یک فرآیند پیچیده است، بسیار جالب است. وظیفه شما این است که تصویر نتیجه نهایی را دوباره بسازید و سپس آن را در قسمت هایی توصیف کنید.

نمونه ای از یکی از شرایط مرجع من برای به روز رسانی برنامه تلویزیون هوشمند. وظایف برای محصولات پیچیده تر و پیچیده تر با کمک همکاران بخش فنی جمع آوری شد. از درخواست کمک از هم تیمی های خود دریغ نکنید، تا جایی که امکان دارد آنها را در این فرآیند مشارکت دهید. و بازخورد را فراموش نکنید! هیچ چیز بدتر از صرف تلاش و زمان برای کاری بدون اطلاع از نتایج نیست. به ما بگویید که مشاوره آن شخص چگونه در کار شما مفید بوده است، در غیر این صورت، این یک بازی یک طرفه است.

شرایط مرجع برای توسعه یک فروشگاه آنلاین

شرایط مرجع برای توسعه یک برنامه تلفن همراه

شرایط مرجع برای سایت

شرایط مرجع برای خدمات / به روز رسانی

اگر به نمونه های بیشتری نیاز دارید، فقط آن را در گوگل جستجو کنید.

توصیه اصلی انجام این کار است. مشکل اینجاست که تنبلی مادر بر همه چیره می شود و مقاومت در برابر آن آسان نیست. تمام اراده خود را جمع کنید و شروع به نوشتن مشخصات فنی کنید، فقط بنویسید و متوقف نشوید. نگران نباشید که "کاملا" کار نمی کند، رازی را به شما می گویم، این هرگز اتفاق نمی افتد. فقط بنویس، هر بار بهتر و بهتر می شود.

این طوری باید باشد

اولین اصول اولیه من برای نوشتن مشخصات فنی چندین سال پیش ظاهر شد. من با طراحان کار کردم و وظیفه داشتم برای کمپین های تبلیغاتی خلاقیت ایجاد کنم. من آن را به طور نامنسجم می خواستم و تبدیل به وقت تلف شده و توضیحات زیادی شد. با گذشت زمان، تنظیم وظایف شروع به تبدیل شدن به نوعی بلوک معنایی و سپس به چیزی شبیه به مشخصات فنی کرد.

به عنوان مثال، برای کار "دکمه لایک در سایت":

1. توضیحات: شما باید یک دکمه "پسندیدن" در وب سایت ما ایجاد کنید.
2. هدف و اهداف: مشارکت کاربر، صدور/رده بندی مطالب بر اساس تعداد لایک ها.
3. الزامات: طراحی زیر (به عنوان مثال: پیوند به چیزی مشابه)، عملکرد (هر کاربری می تواند به تصویر امتیاز دهد و آن را دوست داشته باشد، سیستم سایت تعداد لایک ها را در نظر می گیرد و خروجی مواد را تغییر می دهد)، فناوری (موجود در دسکتاپ). و نسخه موبایل سایت).
4. شرح کار: ترسیم 3 گزینه برای طرح بندی دکمه ها (تاریخ آماده: 10/01/17)، توسعه یک سیستم برای توزیع مطالب بر اساس لایک (تاریخ: 10/14/17)، تست عملکرد (تاریخ: 10/16/17) )، انتشار (تاریخ: 17/10/17)
5. پذیرش کار: کاربر دکمه like را فشار می دهد، سیستم کلیک را می شمارد، تحویل مواد تغییر می کند.
6. برنامه‌ها: طرح‌ها، طرح‌ها، نمونه‌هایی از پروژه‌هایی که عملکرد مشابهی در آنها کار می‌کند.

بخش‌ها و بخش‌هایی از ساختار را که برای کارهای شما لازم است، برای خود بگذارید. به عنوان مثال، بلوک ششم "برنامه ها" را می توان در الزامات عملکردی توصیف کرد. توصیه اساسی: به هر طریقی، کار را با توجه به ساختار مشخصات فنی توصیف کنید. به این ترتیب، نکات مهم را از دست نخواهید داد و خود را از سؤالات غیر ضروری نجات نمی دهید و در عین حال زندگی را برای همکارانتان آسان تر می کنید.

بفرمایید

ما بررسی کردیم که یک کار فنی چیست و چگونه آن را انجام دهیم. اکنون شما این توانایی را دارید که وظایف خود را به وضوح و واضح تنظیم کنید، افکار خود را به افراد دیگر منتقل کنید و در وقت خود برای توضیحات اضافی صرفه جویی کنید. امیدوارم اکنون بدانید که با همه اینها چه کار کنید.

واژه نامه

سایر اصطلاحات فنی مطابق با استانداردهای جاری و توصیه های نهادهای بین المللی مسئول مسائل استانداردسازی در اینترنت درک می شوند.

مقررات عمومی

موضوع توسعه

موضوع توسعه سایت اینترنتی شرکت "..."، LLC، با سیستم مدیریت محتوای پویا مبتنی بر رابط وب است.
هدف سایت:
- ارائه اطلاعات در مورد شرکت LLC "..."؛
- ارائه اطلاعات در مورد فعالیت های LLC "..."؛
- و غیره.؛
- و غیره.

هدف از ایجاد سایت: ... .

هدف سند

این سند مجموعه کاملی از الزامات برای اجرای وب سایت LLC "" را ارائه می دهد.
امضای مشتری و پیمانکار بر روی این سند تأیید کننده توافق آنها با حقایق و شرایط زیر است:
1. پیمانکار این سند را به نام مشخصات فنی تهیه و تدوین کرده است که شامل فهرستی از الزامات کار انجام شده است.
2. مشتری با تمام مفاد این مشخصات فنی موافق است.
3. مشتری حق ندارد در چارچوب توافق نامه فعلی، انجام کار یا ارائه خدماتی را که به صراحت در این مشخصات فنی توضیح داده نشده است، از پیمانکار مطالبه کند.
4. پیمانکار متعهد می شود که کار را در محدوده مشخص شده در این مشخصات فنی انجام دهد.
5. در صورتی که در این مشخصات فنی مشخص نشده باشد، مشتری حق ندارد از پیمانکار درخواست کند که با هیچ فرمت و استانداردی مطابقت داشته باشد.
6. کلیه ابهامات شناسایی شده در این شرایط مرجع پس از امضای آن منوط به توافق دوجانبه بین طرفین است. در طول فرآیند تصویب، الزامات اضافی ممکن است ایجاد شود، که در یک توافق نامه اضافی به توافقنامه رسمیت یافته و بر اساس آن ارزیابی می شود.

الزامات طراحی گرافیک سایت

الزامات طراحی وب سایت

هنگام توسعه یک وب سایت، باید از سبک های عمدتا سبک استفاده شود.
بخش های اصلی سایت باید از صفحه اول قابل دسترسی باشد.
صفحه اول نباید حاوی مقدار زیادی اطلاعات متنی باشد.

طراحی سایت نباید شامل موارد زیر باشد:
- بنرهای چشمک زن؛
- تعداد زیادی متن ادغام شده؛
- و غیره.؛
- و غیره.

روش تایید مفهوم طراحی

مفهوم طراحی به عنوان یک گزینه طراحی برای صفحه اصلی و پوسته گرافیکی صفحات داخلی درک می شود که راه حل کلی بصری (ترکیب، رنگ، فونت، پیمایش) صفحات اصلی سایت را نشان می دهد. طرح مفهومی به صورت یک فایل (چند فایل) در قالب شطرنجی یا به صورت چاپی مطابق توافق طرفین ارائه می شود.
در صورتی که مفهوم طرح ارائه شده توسط پیمانکار، مشتری را راضی کند، باید ظرف پنج روز کاری از تاریخ ارائه، آن را تایید کند. در عین حال، او می تواند لیستی از بهبودهای خصوصی را که بر ساختار کلی صفحات و سبک آنها تأثیر نمی گذارد، برای پیمانکار ارسال کند. این پیشرفت ها به موازات توسعه ماژول های نرم افزاری برای سایت انجام می شود. تغییرات در مفهوم طراحی پس از پذیرش آن تنها با توافق اضافی طرفین مجاز است.
اگر مفهوم ارائه شده الزامات مشتری را برآورده نکند، دومی امتناع منطقی از پذیرش مفهوم را ارائه می دهد و جزئیاتی را نشان می دهد که مانعی برای پذیرش مفهوم و فرمول واضح تر الزامات بوده است.
در این مورد، پیمانکار نسخه دوم مفهوم طراحی را توسعه می دهد. پیمانکار تعهدات توسعه نسخه دوم طرح مفهومی را تنها پس از توافق و امضای توافق نامه اضافی برای تمدید مرحله توسعه مفهوم طراحی برای حداقل پنج روز کاری می پذیرد.
گزینه های اضافی (سومین و بعدی) توسط پیمانکار با هزینه ای بر اساس توافقات اضافی ایجاد می شود.

الزامات عملکردی

الزامات ارائه وب سایت

الزامات ارائه صفحه اصلی سایتصفحه اصلی سایت باید شامل قسمت گرافیکی، منوی ناوبری سایت و همچنین قسمت محتوا باشد تا بازدیدکننده سایت از صفحه اول بتواند اطلاعات مقدماتی شرکت را دریافت کند و همچنین با آخرین اخبار شرکت آشنا شود. .
قسمت محتوای صفحه اول باید به بخش های زیر تقسیم شود:
- یک مقاله مقدماتی در مورد شرکت با پیوند "جزئیات بیشتر" که به بخش "درباره شرکت" منتهی می شود.
- اخبار - شامل 3 آخرین اخبار (اطلاعیه ها) در قالب: تاریخ، عنوان، خلاصه.
- اطلاعات تماس مختصر - شماره تلفن و ایمیل شرکت؛
- یک نوار ناوبری سبک وزن در بالای صفحه نمایش داده می شود که انتقال به آیتم های منوی اصلی سایت (درباره شرکت، اخبار و غیره) را فراهم می کند.


- شمارنده ها و پیوند به صفحه تبادل لینک.

برنج. 1. نمونه ای از قرار دادن عناصر در صفحه اصلی.

پوسته گرافیکی صفحات داخلی (متداول برای همه زیربخش ها)
پوسته گرافیکی صفحات داخلی باید به بخش های زیر تقسیم شود:
- هدر گرافیکی
- منوی ناوبری سایت (پانل ناوبری 2 انتقال به موارد منوی اصلی سایت را فراهم می کند).
- فیلد جستجو - طراحی شده برای انجام جستجوی متن کامل در سایت؛
- فیلد انتخاب زبان - روسی\انگلیسی.
- پیوند "خانه"؛
- پانل ناوبری برای بخش های فرعی بخش انتخاب شده از سایت؛
- فیلدی برای نمایش محتوای صفحه سایت انتخاب شده؛
- در پایین صفحه - اطلاعات تماس مختصر - شماره تلفن و ایمیل شرکت؛
- دکمه "برای چاپ" - خروجی منطقه محتوا را به شکل برش داده شده برای چاپ بر روی صفحات A4 ارائه می دهد.
- دکمه "پرسش" - انتقال به فرم "پرسش یک سوال" را فراهم می کند.

برنج. 2. نمونه ای از قرار دادن عناصر صفحات داخلی سایت.

الزامات ساختار سایت
تمامی نام‌های بخش سایت که در زیر آورده شده است مشروط هستند و می‌توانند با توافق با مشتری در طول فرآیند طراحی تنظیم شوند.
ساختار اولیه سایت باید به شکل زیر باشد:
- درباره شرکت

آ. تاریخچه شرکت
ب دیپلم و گواهینامه
ج شرکای ما
د مشتریان ما
ه. مختصات ما
f. ...

2. اخبار
3. و غیره
4. خیابان

الزامات سیستم مدیریت محتوا

الزامات عمومی برای بخش اداری
برای دسترسی به بخش مدیریتی سایت، باید آدرس خاصی را در خط مرورگر مشخص کنید و مجوز را انجام دهید.
صفحه اصلی بخش اداری باید شامل موارد منوی زیر باشد:
- صفحات سایت (مطابق با سطح اول ساختار سایت):

درباره شرکت
- اخبار
- و غیره.؛

برنج. 3. طرح بندی فرم صفحه اصلی قسمت اداری سایت.

الزامات مدیریت بخش های وب سایت
برای مدیریت بخش های سایت، توابع زیر باید ارائه شوند:
- ایجاد یک زیربخش از سطح 1؛
- ایجاد یک زیربخش از سطح 2 (و بیشتر)؛
- ویرایش محتوای صفحه؛
- حذف یک بخش؛
- حرکت بخشی به بالا در لیست؛
- حرکت بخشی به پایین در لیست.
- نشانه نمایش (نمایش) یا عدم نمایش (پنهان کردن) صفحه در قسمت مشتری سایت.
- نمایش لیستی از زیربخش های سطح انتخاب شده.

مدیریت محتوای وب سایت
برای مدیریت محتوای سایت، بلوک های زیر باید ارائه شود:
1. فیلد عنصر محتوا، می تواند یکی از انواع زیر باشد:
- خط؛
- تاریخ؛
- پیوند به فایل؛
- متن چند خطی؛
2. عنصر محتوا - شامل مجموعه ای از فیلدهای عنصر محتوا است.
3. فهرست عناصر محتوا - شامل مجموعه ای از عناصر محتوا است.

برنج. 4. فیلدهای عنصر محتوا.

فیلد عنصر محتوای متن باید در یک صفحه جداگانه در یک ویرایشگر متن چند خطی ویرایش شود (این ویرایشگر اجازه می دهد تا تصاویر در متن گنجانده شوند).

برنج. 5. ویرایشگر متن چند خطی در قسمت اداری.

برای هر عنصر محتوا، مجموعه مورد نیاز از فیلدها باید تعریف شود. به عنوان مثال، برای عنصر "اخبار" مجموعه فیلدهای محتوای زیر تعریف شده است:

برنج. 6. نمونه ای از ارائه عنصر محتوایی “اخبار” در قسمت اداری.

فهرست عناصر محتوا باید اجازه دهد:
. به قسمت های ویرایش آیتم های لیست بروید.
. حذف عنصر لیست؛
. تعیین ترتیب عناصر لیست خروجی در بخش مشتری؛
. ویژگی hide\show را مشخص کنید.

برنج. 7. نمونه ای از ارائه لیستی از عناصر محتوا در قسمت مدیریت و نمایش آنها در قسمت مشتری.

لیست عناصر باید تمام فیلدهای عنصر را نمایش دهد، به جز فیلدهایی از نوع "متن چند خطی".

تنظیمات سایت را مدیریت کنید
تنظیمات سایت باید شامل موارد زیر باشد:
- ایمیل برای ...;
- و غیره.؛
- و غیره.

توابع اضافی بخش اداری
عملکردهای اضافی بخش اداری باید شامل موارد زیر باشد:
- …;

الزامات دسترسی به اشتراک گذاری

تمام بخش های منتشر شده سایت باید برای دسترسی خواندن بدون احراز هویت کاربر باز باشد.
هنگام تلاش برای ورود به یک بخش بسته، باید از یک کاربر احراز هویت نشده، یک لاگین و رمز عبور درخواست شود.
پس از احراز هویت، سیستم باید اقتدار کاربر را برای دسترسی به بخش درخواستی بررسی کند. اگر دسترسی ممنوع باشد، کاربر باید پیامی دریافت کند که نشان می دهد نمی تواند به بخش محدود شده دسترسی پیدا کند.

الزامات انواع وثیقه

الزامات پشتیبانی اطلاعاتی

الزامات ذخیره سازی داده ها
تمام داده های سایت باید به شکل ساختاریافته و تحت کنترل یک DBMS رابطه ای ذخیره شوند. استثناها فایل های داده ای هستند که برای مشاهده و دانلود (تصاویر، فیلم ها، اسناد و غیره) در نظر گرفته شده اند. چنین فایل هایی در سیستم فایل ذخیره می شوند و پیوندهای آنها در پایگاه داده قرار می گیرند.
محتوای سایت‌های مختلف، که عملکرد آن‌ها توسط همان نصب سیستم پشتیبانی می‌شود، باید تحت کنترل یک DBMS ذخیره شود.
الزامات زبان برنامه نویسی
برای پیاده سازی صفحات و قالب های استاتیک باید از زبان های HTML 4.0 و CSS استفاده شود. کد منبع باید مطابق با استانداردهای W3C (HTML 4.0) توسعه یابد.
برای پیاده سازی عناصر تعاملی سمت مشتری، باید از زبان های جاوا اسکریپت و DHTML استفاده شود.
برای پیاده سازی صفحات پویا باید از زبان PHP استفاده شود.
الزامات سازماندهی هایپرلینک ها
تمامی لینک های موجود در سایت باید نسبی باشند (به استثنای لینک های خارجی).

الزامات برای تصویرسازی
تمام نقشه ها و عکس های بزرگتر از 1 کیلوبایت (به جز عناصر طراحی صفحه) باید با متن جایگزین ساخته شوند. تمام نقشه ها باید با فرمت gif یا jpg باشند.
الزامات برای حجم یک صفحه
اندازه متوسط ​​یک صفحه وب سایت بارگذاری شده استاندارد نباید از 170 کیلوبایت تجاوز کند.
اندازه محافظ صفحه نمایش فلش نباید بیش از 300 کیلوبایت باشد.

الزامات نرم افزاری

الزامات نرم افزار سرور
نرم افزار زیر برای عملکرد سایت مورد نیاز است:
- سیستم عامل - Windows XP و Windows Server 2003.
- وب سرور - نسخه آپاچی کمتر از 1.3.26 نیست.
- DBMS - نسخه MySQL کمتر از 3.23 نیست.
الزامات نرم افزار مشتری
سایت باید به طور کامل با استفاده از مرورگرهای زیر قابل مشاهده باشد:
. MS IE 5.0 و بالاتر؛
. Opera 6.0 و بالاتر؛
. موزیلا فایرفاکس 1.0;
. موزیلا 1.7.
وقتی پشتیبانی فلش و جاوا اسکریپت در مرورگر غیرفعال است، سایت باید کاربردی باشد (اطلاعات موجود در آن باید قابل دسترسی باشد).

الزامات فنی

برای عملکرد وب سایت، پشتیبانی فنی زیر با حداقل مشخصات زیر مورد نیاز است:
- پردازنده - Intel Pentium III 1 گیگاهرتز؛
- RAM - 512 Mb RAM؛
- هارد - هارد 20 گیگ.
- و غیره.؛
- و غیره.

الزامات پشتیبانی زبانی

سایت باید به زبان روسی و انگلیسی باشد. جابجایی بین روسی و انگلیسی در هر صفحه از سایت باید امکان پذیر باشد.

الزامات ارگونومی و زیبایی فنی

سایت باید برای مشاهده با وضوح 1024*768، 1280*1024 بدون نوار اسکرول افقی و بدون فیلدهای خالی (سفید) برای انواع وضوح اصلی بهینه شود.
عناصر کنترل باید در همه صفحات به یک شکل - افقی یا عمودی - گروه بندی شوند.
هر صفحه باید لوگوی شرکت و اطلاعات تماس را نمایش دهد.
رابط ماژول های پلاگین باید به همان سبک رابط هسته سیستم ساخته شود و باید این امکان را برای مدیر فراهم کند که به طور شفاف بین ماژول های سیستم حرکت کند و از روش های کنترل و عناصر ناوبری یکسان برای انجام همان نوع عملیات استفاده کند.

الزامات پذیرش و تحویل پروژه

الزامات برای پر کردن اطلاعات

الزامات عمومی برای محتوای اطلاعاتی
به عنوان بخشی از کار در این پروژه، پیمانکار تضمین می کند که بخش هایی از سایت با مواد ارائه شده توسط مشتری به روش مشخص شده در بند 6.1.2 پر شده است.
پیمانکار پردازش تصاویر را تضمین می کند تا آنها را با الزامات فنی و طرح HTML مواد آماده شده مطابقت دهد. اسکن، تایپ و ویرایش- تصحیح متون، روتوش، ویرایش، ترجمه و سایر آثار بر اساس توافق نامه اضافی (پس از بررسی مطالب در دسترس مشتری) توسط پیمانکار قابل انجام است.
پس از راه اندازی سیستم، محتوای اطلاعاتی بخش ها بر اساس توافق نامه پشتیبانی سایت انجام می شود.
حجم متن و تعداد تصاویر در انواع دیگر بخش ها توسط ساختار داده ارائه شده در این TOR تعیین می شود و در مرحله تایید مفهوم طراحی مشخص می شود.
رویه ارائه محتوای اطلاعاتی
مشتری مطالبی را به صورت الکترونیکی در یک آرشیو فشرده حاوی درختی از دایرکتوری های مربوط به ساختار سایت ارائه می دهد.
هر فهرست شامل مجموعه ای از اسناد در قالب MS Word - یک سند برای هر ماژول اطلاعات است که بلوک های اطلاعاتی آن در بخش مربوطه منتشر می شود. قرار دادن متن در قالب گرافیک یا سایر عناصر غیر متنی مجاز نیست.
تصاویر را می توان به صورت متنی در داخل فایل یا به صورت تصویر جداگانه قرار داد. اما در حالت دوم متن باید حاوی لینکی به تصویر در قالب مسیر و نام فایل تصویر باشد.
برای هر ماژول اطلاعاتی، ساختار سند باید با الگوهای ارائه شده توسط پیمانکار قبل از شروع مرحله تهیه مواد مطابقت داشته باشد.
مواد لازم برای پر کردن اولیه بخش ها باید به طور کامل در مدت زمان تعیین شده توسط برنامه کاری به پیمانکار ارائه شود. امکان انتقال مواد به صورت قطعات، در چندین فایل زیپ که شرایط فوق را دارند، مجاز است.
انتقال مطالب در حجم و قالب مربوط به این TOR با امضای گواهی انتقال محتوای اطلاعات ایمن می شود.
هرگونه تغییر در محتوای اطلاعاتی توسط پیمانکار پس از امضای این قانون فقط بر اساس توافقنامه جداگانه با هزینه اضافی مجاز است.
مطالب اطلاعاتی که توسط مشتری در محدوده زمانی تعیین شده توسط برنامه کاری ارائه نشده است، توسط پیمانکار طبق ضمانت نامه پیمانکار ظرف 2 هفته پس از تحویل و پذیرش پروژه ارسال می شود. این بخش از مطالب اطلاعاتی نیز مشمول الزامات قالب ارائه شده در بالا است.

نیازهای پرسنلی

برای راه اندازی رابط وب سیستم مدیریت محتوای پویا، مدیر نباید به مهارت های فنی خاص، دانش فن آوری ها یا محصولات نرم افزاری نیاز داشته باشد، به استثنای مهارت های عمومی در کار با رایانه شخصی و یک مرورگر وب استاندارد (به عنوان مثال، MS IE 6.0 یا بالاتر).

روش تهیه توزیع

پس از تکمیل توسعه، پیمانکار باید یک کیت توزیع سیستم شامل موارد زیر را در اختیار مشتری قرار دهد:
-بایگانی با کد منبع تمامی ماژول ها و بخش های نرم افزاری سایت.
- تخلیه پایگاه داده پروژه با اطلاعات به روز.
توزیع بر روی یک سی دی به عنوان آرشیو فایل ارائه شده است.

روش انتقال سایت به ابزار فنی مشتری

پس از اتمام پذیرش سایت، در چارچوب پشتیبانی گارانتی، پیمانکار یک بار نرم افزار توسعه یافته را به سخت افزار مشتری انتقال می دهد. مطابقت پلت فرم نرم افزاری و سخت افزاری با الزامات این سند توسط مشتری تضمین می شود.
قبل از انتقال، مشتری دسترسی پوسته از راه دور به وب سرور و دسترسی به پایگاه داده سایت را فراهم می کند.

و بنابراین، استانداردهای اصلی، روش‌شناسی و مجموعه‌ای از دانش که TK یا SRS (نرم‌افزار (یا سیستم) مشخصات مورد نیاز را ذکر می‌کنند):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK، BABOK، و غیره.

GOST 34

طبق GOST 34، مشخصات فنی باید شامل بخش های زیر باشد:

1. اطلاعات عمومی
2. هدف و اهداف ایجاد (توسعه) سیستم
3. ویژگی های اشیاء اتوماسیون
4. سیستم مورد نیاز
5. ترکیب و محتوای کار برای ایجاد سیستم
6. رویه کنترل و پذیرش سیستم
7. الزامات ترکیب و محتوای کار برای آماده سازی شی اتوماسیون برای راه اندازی سیستم
8. مدارک مورد نیاز
9. منابع توسعه

هنگام توسعه مشخصات فنی برای پروژه های دولتی، مشتریان، به عنوان یک قاعده، نیاز به رعایت این استاندارد خاص دارند.

GOST 19

1. معرفی؛
2. دلایل توسعه;
3. هدف توسعه;
4. الزامات برای برنامه یا محصول نرم افزاری.
5. الزامات برای مستندات برنامه.
6. شاخص های فنی و اقتصادی;
7. مراحل و مراحل رشد;
8. رویه کنترل و پذیرش;
9. برنامه های کاربردی.

به طور طبیعی ، GOST 34 (و 19) قبلاً منسوخ شده است و من دوست ندارم از آنها استفاده کنم ، اما با تفسیر صحیح استانداردها ، می توانید مشخصات فنی خوبی دریافت کنید ، به نتیجه گیری مراجعه کنید.

IEEE STD 830-1998

ویژگی های محتوا و کیفیت یک مشخصات نیازمندی های نرم افزاری (SRS) را که به خوبی نوشته شده است را توصیف می کند و چندین الگوی SRS را ارائه می دهد. این روش توصیه شده برای ایجاد الزامات نرم افزار در حال توسعه در نظر گرفته شده است، اما همچنین می تواند برای کمک به انتخاب محصولات نرم افزاری اختصاصی و تجاری استفاده شود.

طبق استاندارد، شرایط مرجع باید شامل بخش های زیر باشد:

1. معرفی

• 1. هدف
• 2. دامنه
• 3. تعاریف، کلمات اختصاری و اختصارات
• 4. پیوندها
• 5. مروری کوتاه

• 1. تعاملات محصول (با سایر محصولات و اجزاء)
• 2. ویژگی های محصول (توضیح مختصر)
• 3. ویژگی های کاربر
• 4. محدودیت ها
• 5. مفروضات و وابستگی ها

• 1. الزامات برای رابط های خارجی
  • 1. رابط های کاربری
  • 2. رابط های سخت افزاری
  • 3. رابط های نرم افزاری
  • 4. رابط ها
• 2. الزامات عملکردی
• 3. الزامات عملکرد
• 4. محدودیت های طراحی (و ارجاع به استانداردها)
• 5. الزامات غیر کاربردی (قابلیت اطمینان، در دسترس بودن، امنیت و غیره)
• 6. سایر الزامات

در واقع، برای یک مبتدی درک آنچه باید در این بخش ها مطابق ساختار فوق وجود داشته باشد (مانند مورد GOST) بسیار دشوار است، بنابراین شما باید خود استاندارد را بخوانید. اما به زبان انگلیسی. زبان

خوب، برای کسانی که تا آخر مطالعه می کنند، یک امتیاز وجود دارد: نمونه ای از مشخصات فنی که سال ها پیش نوشتم (الان مدت زیادی است که به عنوان تحلیلگر کار نمی کنم و نمونه های موفق دیگر وجود ندارد. توسط NDA برای مشاهده عمومی باز شد).

• ارائه توسط یوری بولوی طبقه بندی نیازمندی های نرم افزار و نمایش آن در استانداردها و متدولوژی ها.
• تجزیه و تحلیل الزامات سیستم های اطلاعاتی خودکار سخنرانی 11: الزامات مستندسازی.
• قوانین تنظیم مشخصات مورد نیاز نرم افزار (به همراه نظرات بخوانید)
• نمونه هایی از مشخصات فنی و سایر اسناد برای توسعه AS برای وزارت توسعه اقتصادی
• سبک مدیریت GOST مقاله Gaperton در مورد کار صحیح با مشخصات فنی طبق GOST
• الگوهای اسناد تحلیلگر کسب و کار از

اغلب از من می پرسند: "چگونه مشخصات فنی یک سیستم خودکار را به درستی توسعه دهیم؟" موضوع توسعه مشخصات فنی به طور مداوم در انجمن های مختلف مورد بحث قرار می گیرد. این سوال به قدری گسترده است که نمی توان به طور خلاصه به آن پاسخ داد. بنابراین تصمیم گرفتم مقاله ای طولانی در این زمینه بنویسم. در روند کار بر روی مقاله متوجه شدم که نمی توان همه چیز را در یک مقاله قرار داد، زیرا ... حدود 50 صفحه خواهد بود و تصمیم گرفتم آن را به 2 قسمت تقسیم کنم:

• در قسمت اول " توسعه مشخصات فنی. چیست، چرا لازم است، از کجا شروع کنیم و چگونه باید باشد? من سعی خواهم کرد به سؤالات موضوع به طور مفصل پاسخ دهم، ساختار و هدف شرایط مرجع را در نظر بگیرم و توصیه هایی در مورد تدوین الزامات ارائه دهم.
• بخش دوم " توسعه مشخصات فنی. نحوه تدوین الزامات? به طور کامل به شناسایی و تدوین الزامات یک سیستم اطلاعاتی اختصاص داده خواهد شد.

ابتدا باید بفهمید چه سوالی واقعاً مورد توجه کسانی است که می پرسند "چگونه مشخصات فنی ایجاد کنیم؟" واقعیت این است که رویکرد توسعه مشخصات فنی تا حد زیادی به اهدافی که برای آن انجام می شود و همچنین توسط چه کسی استفاده می شود بستگی دارد. در مورد چه گزینه هایی صحبت می کنم:

• یک سازمان تجاری تصمیم به پیاده سازی یک سیستم خودکار گرفت. این سرویس فناوری اطلاعات خود را ندارد و تصمیم به انجام این کار گرفت: طرف علاقه مند باید یک مشخصات فنی تهیه کند و آن را برای توسعه به شخص ثالث ارسال کند.
• یک سازمان تجاری تصمیم به پیاده سازی یک سیستم خودکار گرفت. سرویس آی تی خود را دارد. ما تصمیم گرفتیم این کار را انجام دهیم: یک مشخصات فنی ایجاد کنیم، سپس بر روی آن بین سرویس فناوری اطلاعات و طرف های ذینفع توافق کنیم، و آن را به تنهایی پیاده سازی کنیم.
• سازمان دولتی تصمیم گرفت یک پروژه فناوری اطلاعات را آغاز کند. اینجا همه چیز خیلی تیره و تار است، تشریفات زیاد، رشوه، بریدگی و غیره. من این گزینه را در این مقاله در نظر نخواهم گرفت.
• یک شرکت فناوری اطلاعات خدماتی را برای توسعه و/یا پیاده سازی سیستم های خودکار ارائه می دهد. این سخت ترین مورد است، زیرا شما باید در شرایط مختلفی کار کنید:

  مشتری متخصصان خود را دارد که نظرات خود را دارند و آنها الزامات خاصی را برای مشخصات فنی تعیین می کنند.

  • شرایط مرجع برای توسعه دهندگان داخلی ایجاد شده است (کارفرما اهمیتی نمی دهد).
  • شرایط مرجع برای انتقال به پیمانکار (به عنوان مثال گروهی از برنامه نویسان در کارکنان شرکت یا یک متخصص فردی) ایجاد می شود.
  • یک سوء تفاهم بین شرکت و مشتری در مورد نتیجه به دست آمده ایجاد می شود و شرکت بارها و بارها این سوال را مطرح می کند: "مشخصات فنی چگونه باید توسعه یابد؟" مورد آخر ممکن است پارادوکس به نظر برسد، اما حقیقت دارد.
  • گزینه های دیگر، کمتر رایج نیز ممکن است.

فکر می کنم خواننده اکنون باید سؤالاتی داشته باشد:

• چرا مشخصات فنی را نمی توان همیشه به یک شکل توسعه داد؟
• آیا استانداردها، روش ها، توصیه هایی وجود دارد؟ از کجا می توانم آنها را تهیه کنم؟
• چه کسی باید شرایط مرجع را توسعه دهد؟ آیا این شخص باید دانش خاصی داشته باشد؟
• چگونه بفهمیم که شرایط مرجع به خوبی نوشته شده است یا خیر؟
• با هزینه چه کسی باید توسعه یابد و آیا حتی ضروری است؟

این لیست می تواند بی پایان باشد. این را با اطمینان می گویم زیرا 15 سال است که در زمینه توسعه نرم افزار حرفه ای هستم و در هر تیم توسعه ای که با آنها کار می کنم سؤال مشخصات فنی مطرح می شود. دلایل این امر متفاوت است. با مطرح کردن موضوع توسعه شرایط مرجع، من به خوبی می دانم که نمی توانم آن را 100٪ به همه علاقه مندان به موضوع ارائه دهم. اما، همانطور که می گویند، سعی می کنم "همه چیز را مرتب کنم." کسانی که قبلاً با مقالات من آشنا هستند می دانند که من از "کپی پیست" کارهای دیگران استفاده نمی کنم، کتاب های دیگران را تجدید چاپ نمی کنم، استانداردهای چند صفحه ای و سایر اسنادی را که خودتان می توانید در اینترنت پیدا کنید، نقل قول نمی کنم. آنها را به عنوان افکار نابغه خود به اشتراک بگذارید. فقط در یک موتور جستجو تایپ کنید "چگونه مشخصات فنی ایجاد کنیم" و می توانید چیزهای جالب، اما متأسفانه تکراری زیادی بخوانید. به عنوان یک قاعده، کسانی که دوست دارند در انجمن ها باهوش باشند (فقط سعی کنید جستجو کنید!) هرگز خودشان مشخصات فنی مناسبی تهیه نکرده اند و دائماً توصیه های GOST را در مورد این موضوع نقل قول می کنند. و کسانی که واقعاً در مورد این موضوع جدی هستند معمولاً فرصتی برای نشستن در انجمن ندارند. به هر حال، ما همچنین در مورد استانداردهای GOST صحبت خواهیم کرد. در طول سال‌های کارم، نسخه‌های بسیاری از اسناد فنی را دیده‌ام که هم توسط متخصصان فردی و هم تیم‌های برجسته و شرکت‌های مشاور گردآوری شده‌اند. گاهی اوقات من نیز به این فعالیت می پردازم: زمانی را برای خودم اختصاص می دهم و اطلاعاتی را در مورد موضوع مورد علاقه از منابع غیرمعمول (مانند کمی هوش) جستجو می کنم. در نتیجه، من مجبور شدم مستندات مربوط به هیولاهایی مانند گازپروم، راه آهن روسیه و بسیاری از شرکت های جالب دیگر را ببینم. البته با وجود اینکه این اسناد از منابع عمومی یا عدم مسئولیت مشاوران (پراکندگی اطلاعات در اینترنت) به دست من می رسد، سیاست محرمانگی را رعایت می کنم. بنابراین، بلافاصله می گویم: من اطلاعات محرمانه ای را که متعلق به شرکت های دیگر است، صرف نظر از منابع (اخلاق حرفه ای) به اشتراک نمی گذارم.

مشخصات فنی چیست؟

اولین کاری که اکنون انجام خواهیم داد این است که بفهمیم این "مشخصات فنی" چه نوع جانوری است.

بله، واقعاً GOST ها و استانداردهایی وجود دارد که سعی در تنظیم این بخش از فعالیت (توسعه نرم افزار) دارند. روزی روزگاری، همه این GOST ها مرتبط بودند و به طور فعال مورد استفاده قرار می گرفتند. اکنون نظرات مختلفی در مورد مرتبط بودن این اسناد وجود دارد. برخی استدلال می کنند که GOST ها توسط افراد بسیار دوراندیش ساخته شده اند و هنوز هم مرتبط هستند. برخی دیگر می گویند که به طرز ناامیدکننده ای منسوخ شده اند. شاید کسی اکنون فکر می کرد که حقیقت جایی در وسط است. من به قول گوته پاسخ می‌دهم: «آنها می‌گویند که بین دو عقیده متضاد، حقیقت نهفته است. در هیچ موردی! بین آنها مشکل وجود دارد.» پس هیچ حقیقتی بین این نظرات وجود ندارد. زیرا GOST ها مشکلات عملی توسعه مدرن را آشکار نمی کنند و کسانی که آنها را مورد انتقاد قرار می دهند جایگزین هایی (خاص و سیستمیک) ارائه نمی دهند.

توجه داشته باشید که GOST به وضوح حتی تعریفی ارائه نمی دهد ، فقط می گوید: "TK برای نیروگاه هسته ای سند اصلی است که الزامات و روش ایجاد (توسعه یا نوسازی - سپس ایجاد) یک سیستم خودکار را مطابق با که توسعه یک نیروگاه هسته ای انجام می شود و پس از راه اندازی آن پذیرش می شود.»

اگر کسی به GOST هایی که من در مورد آن صحبت می کنم علاقه مند است، آنها اینجا هستند:

• GOST 2.114-95 سیستم یکپارچه اسناد طراحی. مشخصات فنی؛
• GOST 19.201-78 سیستم یکپارچه اسناد برنامه. وظیفه فنی الزامات محتوا و طراحی؛
• GOST 34.602-89 فناوری اطلاعات. مجموعه ای از استانداردها برای سیستم های خودکار. شرایط مرجع برای ایجاد یک سیستم خودکار.

تعریف بسیار بهتری در ویکی پدیا ارائه شده است (البته در مورد مشخصات فنی به طور کلی، و نه فقط برای نرم افزار): وظیفه فنی- این سند طراحی اصلی است فنیهدف - شی. وظیفه فنیهدف اصلی شیء در حال توسعه، ویژگی های فنی و تاکتیکی-فنی، شاخص های کیفیت و الزامات فنی و اقتصادی، دستورالعمل های تکمیل مراحل لازم برای ایجاد اسناد (طراحی، فناوری، نرم افزار و غیره) و ترکیب آن را تعیین می کند. و همچنین الزامات خاص یک کار به عنوان یک سند اولیه برای ایجاد یک چیز جدید در همه زمینه های فعالیت وجود دارد که از نظر نام، محتوا، ترتیب اجرا و غیره متفاوت است (به عنوان مثال، یک کار طراحی در ساخت و ساز، یک کار رزمی، تکالیف خانه، یک قرارداد برای یک اثر ادبی و غیره). د.)"

و بنابراین، همانطور که از تعریف بر می آید، هدف اصلی مشخصات فنی، فرموله کردن الزامات برای شی در حال توسعه، در مورد ما، برای یک سیستم خودکار است.

این مهمترین چیز است، اما تنها. زمان آن فرا رسیده است که به موضوع اصلی بپردازیم: همانطور که وعده داده شده همه چیز را "در قفسه ها" قرار دهیم.

در مورد الزامات چه چیزی باید بدانید؟ لازم است به وضوح درک کنیم که همه الزامات باید بر اساس نوع و خواص تقسیم شوند. حالا ما یاد خواهیم گرفت که چگونه این کار را انجام دهیم. برای جدا کردن الزامات بر اساس نوع، GOST به ما کمک می کند. فهرستی از انواع الزامات که در آنجا ارائه شده است، نمونه خوبی از این است که چه نوع الزاماتی باید در نظر گرفته شود. مثلا:

• الزامات عملکردی؛
• الزامات امنیت و حقوق دسترسی؛
• الزامات برای صلاحیت پرسنل؛
• …. و غیره. شما می توانید در مورد آنها در GOST ذکر شده بخوانید (و در زیر آنها را با جزئیات بیشتری بررسی خواهم کرد).

من فکر می کنم برای شما واضح است که عامل کلیدی در یک مشخصات فنی موفق، الزامات عملکردی دقیقاً فرمول بندی شده است. بیشتر کارها و روش هایی که در مورد آنها صحبت کردم به این نیازها اختصاص دارد. الزامات عملکردی 90٪ از پیچیدگی کار بر روی توسعه شرایط مرجع است. هر چیز دیگری اغلب یک «استتار» است که این الزامات را پوشش می دهد. اگر الزامات ضعیف فرموله شوند، مهم نیست که چه استتار زیبایی روی آنها قرار دهید، یک پروژه موفق از آب در نخواهد آمد. بله، به طور رسمی تمام الزامات برآورده خواهد شد (طبق GOST J)، مشخصات فنی توسعه یافته، تایید و امضا شده است و پول برای آن دریافت شده است. و چی؟ و سپس جالب ترین قسمت شروع می شود: چه باید کرد؟ اگر این یک پروژه در سفارش دولتی است، پس هیچ مشکلی وجود ندارد - بودجه در آنجا به گونه ای است که در جیب کسی قرار نمی گیرد و در طول فرآیند اجرا (در صورت وجود) همه چیز روشن می شود. این دقیقاً همان روشی است که اکثر بودجه های پروژه صرف سفارشات دولتی می شود (آنها "TZ" را خط زدند، ده ها میلیون ضرر کردند، اما پروژه را انجام ندادند. تمام تشریفات رعایت شد، هیچ طرف مقصری وجود نداشت، یک ماشین جدید نزدیک به خانه. زیبایی!). اما ما در مورد سازمان های تجاری صحبت می کنیم که در آنها پول حساب می شود و نتیجه متفاوتی لازم است. بنابراین، بیایید چیز اصلی را درک کنیم، چگونگی توسعه مشخصات فنی مفید و کاربردی.

در مورد انواع نیازمندی ها گفتم اما املاک چطور؟ اگر انواع الزامات می تواند متفاوت باشد (بسته به اهداف پروژه)، پس با ویژگی ها همه چیز ساده تر است، 3 مورد از آنها وجود دارد:

1. لازمه باید باشد قابل درک;
2. لازمه باید باشد خاص;
3. لازمه باید باشد آزمون گیرندگان;

علاوه بر این، آخرین خاصیت بدون دو مورد قبلی، یعنی. نوعی "آزمایش تورنسل" است. اگر نتیجه یک نیاز قابل آزمایش نباشد، به این معنی است که یا نامشخص است یا مشخص نیست. در مورد آن فکر کنید. در تسلط بر این سه ویژگی از الزامات است که تسلط و حرفه ای گری نهفته است. در واقع بسیار ساده است. وقتی فهمیدی

این داستان را در مورد چیستی مشخصات فنی به پایان می‌رساند و به موضوع اصلی می‌پردازد: نحوه تدوین الزامات. اما آنقدرها هم سریع نیست. یک نکته بسیار مهم دیگر وجود دارد:

• مشخصات فنی به چه زبانی (از نظر سختی درک) نوشته شود؟
• آیا باید مشخصات توابع مختلف، الگوریتم ها، انواع داده ها و سایر موارد فنی را شرح دهد؟
• طراحی فنی که اتفاقاً در GOST ها نیز ذکر شده است چیست و چگونه با مشخصات فنی مرتبط است؟

در پاسخ به این سوالات یک چیز بسیار موذیانه نهفته است. به همین دلیل است که اغلب در مورد کفایت یا عدم وجود جزئیات ضروری الزامات، در مورد قابل درک بودن سند توسط مشتری و پیمانکاران، در مورد افزونگی، قالب ارائه و غیره اختلاف نظر وجود دارد. مرز بین شرایط مرجع و پروژه فنی کجاست؟

وظیفه فنی- این سند مبتنی بر الزامات است که به زبانی قابل درک (معمولی، آشنا) برای مشتری تنظیم شده است. در این مورد، اصطلاحات صنعتی که برای مشتری قابل درک است، می توانند و باید استفاده شوند. نباید هیچ ارتباطی با مشخصات اجرایی فنی وجود داشته باشد. آن ها در مرحله مشخصات فنی، در اصل، مهم نیست که این الزامات در کدام پلتفرم اجرا می شود. اگرچه استثنائاتی وجود دارد. اگر ما در مورد پیاده سازی یک سیستم مبتنی بر یک محصول نرم افزاری موجود صحبت می کنیم، چنین پیوندی می تواند انجام شود، اما فقط در سطح فرم های صفحه نمایش، فرم های گزارش و غیره. شفاف سازی و تدوین الزامات و همچنین توسعه شرایط مرجع باید انجام شود تحلیلگر کسب و کار.و مطمئناً برنامه نویس نیست (مگر اینکه این نقش ها را ترکیب کند، این اتفاق می افتد). آن ها این شخص باید با مشتری به زبان تجارت خود صحبت کند.

پروژه فنی- این سندی است که برای اجرای فنی الزامات فرموله شده در شرایط مرجع در نظر گرفته شده است. این سند ساختارهای داده، راه‌اندازها و رویه‌های ذخیره‌شده، الگوریتم‌ها و سایر موارد مورد نیاز را شرح می‌دهد. متخصصان فنی. مشتری به هیچ وجه مجبور نیست در این مورد تحقیق کند (حتی ممکن است چنین اصطلاحاتی برای او واضح نباشد). پروژه فنی انجام می دهد معمار سیستم(ترکیب این نقش با برنامه نویس کاملا طبیعی است). یا بهتر است بگوییم، گروهی از متخصصان JSC به رهبری یک معمار. هرچه پروژه بزرگتر باشد، افراد بیشتری روی شرایط مرجع کار می کنند.

در عمل چه داریم؟ دیدن زمانی که کارگردان با مشخصات فنی برای تایید ارائه می شود که مملو از اصطلاحات فنی، توصیف انواع داده ها و مقادیر آنها، ساختار پایگاه داده و غیره است، خنده دار است. او البته سعی می کند بفهمد، زیرا نیاز به تایید دارد. ، تلاش برای یافتن کلمات آشنا بین خطوط و از دست دادن الزامات کسب و کار زنجیره ای. آیا این وضعیت آشناست؟ و چگونه به پایان می رسد؟ به عنوان یک قاعده، چنین مشخصات فنی تأیید می شود، سپس اجرا می شود، و در 80٪ موارد، آنها به هیچ وجه با واقعیت کار انجام شده مطابقت ندارند، زیرا آنها تصمیم گرفتند که تغییر کنند، خیلی چیزها را دوباره انجام دهند، اشتباه فهمیدند، اشتباه فکر کردند و غیره. و غیره و سپس سریال ارسال کار آغاز می شود. "اما اینجا چیزی نیست که ما نیاز داریم"، "این برای ما کار نمی کند"، "این خیلی پیچیده است"، "این ناخوشایند است"، و غیره. آشنا بنظر رسیدن؟!! این برای من آشناست، مجبور شدم به موقع به دست اندازها ضربه بزنم.

پس در عمل چه داریم؟ اما در عمل ما بین شرایط مرجع و پروژه فنی مرز مبهم داریم. او در تظاهرات مختلف بین TK و TP شناور است. و این بد است. این به این دلیل است که فرهنگ توسعه ضعیف شده است. این تا حدودی به دلیل صلاحیت متخصصان است، تا حدی به دلیل تمایل به کاهش بودجه و مهلت‌ها (از همه اینها، مستندسازی زمان زیادی می برد - این یک واقعیت است). عامل مهم دیگری نیز وجود دارد که بر استفاده از طراحی فنی به عنوان یک سند جداگانه تأثیر می گذارد: توسعه سریع ابزارهای توسعه سریع و همچنین روش های توسعه. اما این یک داستان جداگانه است؛ من در زیر چند کلمه در مورد آن خواهم گفت.

یک نکته کوچک اما مهم دیگر. گاهی اوقات شرایط مرجع را یک قطعه کوچک از الزامات، ساده و قابل درک می نامند. به عنوان مثال، جستجوی یک شی را با توجه به برخی شرایط بهبود بخشید، یک ستون به گزارش اضافه کنید، و غیره. این رویکرد کاملاً موجه است، چرا زندگی را پیچیده می کند. اما نه در پروژه های بزرگ، بلکه در پیشرفت های جزئی استفاده می شود. من می گویم این به نگهداری محصول نرم افزاری نزدیک تر است. در این مورد، شرایط مرجع ممکن است راه حل فنی خاصی را برای اجرای الزامات توضیح دهد. به عنوان مثال، "یک تغییر فلان و فلان را در فلان الگوریتم انجام دهید" که نشان دهنده یک رویه خاص و یک تغییر خاص برای برنامه نویس است. این در صورتی است که مرز بین شرایط مرجع و پروژه های فنی به طور کامل پاک شود، زیرا هیچ امکان اقتصادی برای افزایش کاغذ در جایی که نیاز نیست وجود ندارد، اما یک سند مفید ایجاد می شود. و درست است.

آیا اصلاً مشخصات فنی لازم است؟ در مورد پروژه فنی چطور؟

آیا من بیش از حد گرم می شوم؟ آیا این بدون هیچ امکانی است؟ مشخصات فنی? تصور کنید ممکن است (یا بهتر است بگوییم ممکن است) و این رویکرد پیروان زیادی دارد و تعداد آنها در حال افزایش است. به عنوان یک قاعده، پس از اینکه متخصصان جوان کتاب هایی در مورد Scrum، Agile و سایر فناوری های توسعه سریع مطالعه کردند. در واقع، اینها فناوری‌های فوق‌العاده‌ای هستند، و کار می‌کنند، اما به معنای واقعی کلمه نمی‌گویند «نیازی به انجام کارهای فنی نیست». آنها می گویند "حداقل کاغذبازی"، به خصوص موارد غیر ضروری، نزدیک تر به مشتری، جزئیات بیشتر و نتایج سریع تر. اما هیچ کس ضبط الزامات را لغو نکرد و این به وضوح در آنجا بیان شده است. در آنجاست که الزامات بر اساس سه ویژگی قابل توجهی که در بالا ذکر کردم ثابت می شود. صرفاً ساختار ذهن برخی افراد به گونه ای است که اگر چیزی را می توان ساده کرد، بیایید آن را تا حد غیبت کامل ساده کنیم. همانطور که انیشتین گفت: آن را تا حد امکان ساده کنید، اما نه ساده تر از آن.» . اینها کلمات طلایی است که با همه چیز همراه است. بنابراین وظیفه فنیلازم است، در غیر این صورت پروژه موفقی نخواهید دید. سوال دیگر این است که چگونه آن را بنویسیم و چه چیزی را در آنجا بگنجانیم. در پرتو روش‌های توسعه سریع، شما باید فقط روی الزامات تمرکز کنید و همه "استتار" را می توان دور انداخت. در اصل من با این موافقم.

در مورد پروژه فنی چطور؟ این سند بسیار مفید است و ارتباط خود را از دست نداده است. علاوه بر این، اغلب شما به سادگی نمی توانید بدون آن انجام دهید. به خصوص وقتی صحبت از برون سپاری کار توسعه باشد، یعنی. بر اساس اصل برون سپاری اگر این کار را انجام ندهید، در خطر یادگیری چیزهای زیادی در مورد اینکه سیستمی که در ذهن دارید چگونه باید باشد، خواهید بود. آیا مشتری باید با آن آشنا شود؟ اگر بخواهد چرا که نه، اما نیازی به اصرار و تایید این سند نیست، فقط جلوی کار را می گیرد و مزاحم کار می شود. طراحی یک سیستم تا کوچکترین جزئیات تقریبا غیرممکن است. در این صورت باید به طور مداوم تغییراتی در طراحی فنی ایجاد کنید که زمان زیادی می برد. و اگر سازمان به شدت بوروکراتیک باشد، تمام اعصاب خود را در آنجا رها خواهید کرد. کاهش این نوع طراحی دقیقاً همان چیزی است که متدولوژی های توسعه سریع مدرن که در بالا به آن اشاره کردم، در مورد آن هستند. به هر حال، همه آنها بر اساس XP کلاسیک (برنامه نویسی شدید) هستند - رویکردی که در حال حاضر حدود 20 سال قدمت دارد. بنابراین یک مشخصات فنی با کیفیت بالا ایجاد کنید که برای مشتری قابل درک باشد و از طراحی فنی به عنوان یک سند داخلی برای ارتباط بین معمار سیستم و برنامه نویسان استفاده کنید.

یک جزئیات جالب در مورد طراحی فنی: برخی از ابزارهای توسعه طراحی شده بر اساس اصل طراحی موضوع محور (مانند 1C و موارد مشابه) فرض می کنند که طراحی (به معنای فرآیند مستندسازی) فقط در مناطق واقعاً پیچیده که در آن تعامل بین کل زیرسیستم ها مورد نیاز است، مورد نیاز است. در ساده ترین حالت، به عنوان مثال، ایجاد یک فهرست یا سند، تنها الزامات تجاری که به درستی فرموله شده اند کافی است. این را استراتژی تجاری این پلتفرم در زمینه آموزش متخصصان نیز نشان می دهد. اگر به کارت امتحان یک متخصص نگاه کنید (این چیزی است که به آن می گویند، نه یک "برنامه نویس")، خواهید دید که فقط الزامات تجاری وجود دارد و نحوه پیاده سازی آنها در یک زبان برنامه وظیفه متخصص است. آن ها بخشی از مشکلی که پروژه فنی برای حل آن در نظر گرفته شده است، متخصص باید "در سر خود" حل کند (ما در مورد وظایف با پیچیدگی متوسط ​​صحبت می کنیم)، در اینجا و اکنون، با پیروی از استانداردهای توسعه و طراحی خاص، که دوباره توسط شرکت 1C برای پلتفرم خود. بنابراین، از دو متخصص که نتایج کارشان یکسان به نظر می‌رسد، یکی می‌تواند در امتحان قبول شود، اما دیگری نمی‌تواند، زیرا استانداردهای توسعه را آشکارا نقض کرده است. بدیهی است که فرض بر این است که متخصصان باید دارای چنین شرایطی باشند که بتوانند وظایف معمولی را به طور مستقل و بدون دخالت معماران سیستم طراحی کنند. و این رویکرد کار می کند.

بیایید به مطالعه این سوال ادامه دهیم: "چه الزاماتی باید در شرایط مرجع گنجانده شود؟"

تدوین الزامات سیستم اطلاعاتی ساختار شرایط مرجع

بیایید بلافاصله موضوع را روشن کنیم: ما به طور خاص در مورد تدوین الزامات یک سیستم اطلاعاتی صحبت خواهیم کرد، به عنوان مثال. با فرض اینکه کار بر روی توسعه الزامات کسب و کار، رسمی کردن فرآیندهای تجاری و کلیه کارهای مشاوره قبلی قبلاً تکمیل شده است. البته در این مرحله می توان توضیحاتی داد، اما فقط شفاف سازی. پروژه اتوماسیون خود مشکلات تجاری را حل نمی کند - این را به خاطر بسپارید. این یک بدیهیات است. بنا به دلایلی، برخی از مدیران سعی در رد آن دارند و معتقدند در صورت خرید برنامه، نظم به یک تجارت آشفته می رسد. اما بدیهیات فقط یک بدیهیات است و نیازی به اثبات ندارد.

مانند هر فعالیت دیگری، تدوین الزامات را می توان (و باید) به مراحل تقسیم کرد. هر چیزی زمان خودش را دارد. این کار فکری سختی است. و اگر با توجه ناکافی با آن رفتار کنید، نتیجه مناسب خواهد بود. بر اساس برآوردهای کارشناسان، هزینه توسعه شرایط مرجع می تواند 30-50٪ باشد. من هم بر همین عقیده هستم. اگرچه 50 شاید خیلی زیاد باشد. از این گذشته، مشخصات فنی آخرین سندی نیست که باید تهیه شود. بالاخره باید طراحی فنی هم وجود داشته باشد. این تنوع به دلیل پلتفرم ها، رویکردها و فناوری های مختلف اتوماسیون است که توسط تیم های پروژه در طول توسعه استفاده می شود. به عنوان مثال، اگر ما در مورد توسعه در یک زبان کلاسیک مانند C ++ صحبت می کنیم، طراحی فنی دقیق ضروری است. اگر ما در مورد پیاده سازی یک سیستم بر روی پلت فرم 1C صحبت می کنیم، پس وضعیت طراحی تا حدودی متفاوت است، همانطور که در بالا دیدیم (اگرچه، هنگام توسعه یک سیستم از ابتدا، طبق طرح کلاسیک طراحی شده است).

اگرچه بیانیه الزامات بخش اصلی است مشخصات فنیو در برخی موارد تنها قسمت مشخصات فنی می شود، باید توجه داشته باشید که این سند مهمی است و باید مطابق آن تنظیم شود. از کجا شروع کنیم؟ اول از همه، باید از محتوا شروع کنید. محتوا را بنویسید و سپس شروع به گسترش آن کنید. من شخصاً این کار را انجام می دهم: ابتدا محتوا را ترسیم می کنم ، اهداف ، تمام اطلاعات مقدماتی را شرح می دهم و سپس به قسمت اصلی می پردازم - فرمول بندی الزامات. چرا برعکس نه؟ نمی دونم برای من راحت تره اولاً، این بخش بسیار کوچک‌تری از زمان است (در مقایسه با الزامات)، و ثانیاً، در حالی که شما در حال توصیف تمام اطلاعات مقدماتی هستید، به موضوع اصلی توجه می‌کنید. خب هر کی دوست داره با گذشت زمان، شما الگوی مشخصات فنی خود را توسعه خواهید داد. برای شروع، من توصیه می کنم دقیقا همان چیزی را که در GOST توضیح داده شده است، به عنوان محتوا انتخاب کنید. برای محتوا مناسب است! سپس هر بخش را می گیریم و شروع به توصیف می کنیم، بدون اینکه از توصیه های سه ویژگی زیر غافل شویم: قابل فهم بودن، اختصاصی بودن و آزمایش پذیری. چرا اینقدر روی این موضوع اصرار دارم؟ بیشتر در این مورد در بخش بعدی. و اکنون من پیشنهاد می کنم آن نقاط مشخصات فنی را که در GOST توصیه می شود مرور کنیم.

1. اطلاعات کلی؛
2. هدف و اهداف ایجاد (توسعه) سیستم؛
3. ویژگی های اشیاء اتوماسیون؛
4. سیستم مورد نیاز؛
5. ترکیب و محتوای کار برای ایجاد سیستم؛
6. روش کنترل و پذیرش سیستم؛
7. الزامات ترکیب و محتوای کار برای آماده سازی شی اتوماسیون برای راه اندازی سیستم.
8. ملزومات مستندسازی؛
9. منابع توسعه

در مجموع 9 بخش که هر کدام به زیربخش نیز تقسیم می شوند. بیایید به ترتیب به آنها نگاه کنیم. برای راحتی، من همه چیز را در قالب یک جدول برای هر مورد ارائه می کنم.

بخش 1. اطلاعات عمومی.

بخش 2. هدف و اهداف ایجاد (توسعه) سیستم.

به طور کلی توانایی شناسایی اهداف، تدوین آنها و ساختن درخت اهداف موضوعی کاملا مجزا است. نکته اصلی را به خاطر بسپارید: اگر می دانید چگونه بنویسید، اگر مطمئن نیستید، اصلا ننویسید. اگر اهدافی را تدوین نکنید چه اتفاقی می‌افتد؟ شما طبق الزامات کار خواهید کرد، این اغلب تمرین می شود.

بخش 3. ویژگی های اشیاء اتوماسیون.

بخش 4. سیستم مورد نیاز

GOST لیست چنین الزاماتی را رمزگشایی می کند:

• الزامات ساختار و عملکرد سیستم؛
• الزامات تعداد و صلاحیت پرسنل سیستم و نحوه عملکرد آنها؛
• شاخص های مقصد؛
• الزامات قابلیت اطمینان؛
• الزامات ایمنی؛
• الزامات ارگونومی و زیبایی فنی؛
• الزامات حمل و نقل برای بلندگوهای موبایل؛
• الزامات برای بهره برداری، نگهداری، تعمیر و ذخیره سازی اجزای سیستم؛
• الزامات حفاظت از اطلاعات در برابر دسترسی غیرمجاز؛
• الزامات ایمنی اطلاعات در صورت بروز حوادث؛
• الزامات محافظت در برابر تأثیرات خارجی؛
• الزامات خلوص حق ثبت اختراع؛
• الزامات استانداردسازی و یکسان سازی؛

علیرغم این واقعیت که بخش اصلی مطمئناً بخش با الزامات خاص (عملکردی) خواهد بود ، این بخش نیز می تواند از اهمیت زیادی برخوردار باشد (و در بیشتر موارد چنین است). آنچه ممکن است مهم و مفید باشد:

• شرایط صلاحیت. این امکان وجود دارد که سیستم در حال توسعه نیاز به آموزش مجدد متخصصان داشته باشد. اینها می توانند هم کاربران سیستم آینده باشند و هم متخصصان فناوری اطلاعات که برای پشتیبانی از آن مورد نیاز خواهند بود. توجه ناکافی به این موضوع اغلب به مشکلات تبدیل می شود. اگر صلاحیت پرسنل موجود به وضوح کافی نیست، بهتر است شرایط لازم برای سازماندهی آموزش، برنامه آموزشی، زمان بندی و غیره را مشخص کنید.
• الزامات برای محافظت از اطلاعات در برابر دسترسی غیرمجاز.اینجا نظری وجود ندارد. اینها دقیقاً الزامات محدود کردن دسترسی به داده ها هستند. اگر چنین الزاماتی برنامه ریزی شده باشد، باید آنها را به طور جداگانه، تا حد امکان با جزئیات، مطابق با قوانین مشابه الزامات عملکردی (قابلیت درک، ویژگی، آزمایش پذیری) نوشته شود. بنابراین، این الزامات را می توان در بخش با الزامات عملکردی گنجاند
• الزامات استانداردسازیاگر استانداردهای طراحی قابل اجرا برای پروژه وجود داشته باشد، می توان آنها را در الزامات گنجاند. به عنوان یک قاعده، چنین الزاماتی توسط خدمات فناوری اطلاعات مشتری آغاز می شود. به عنوان مثال، شرکت 1C دارای الزاماتی برای طراحی کد برنامه، طراحی رابط و غیره است.
• الزامات ساختار و عملکرد سیستم.در اینجا الزامات یکپارچه سازی سیستم ها با یکدیگر را می توان شرح داد و شرحی از معماری کلی ارائه می شود. اغلب، الزامات یکپارچه سازی به طور کلی به یک بخش جداگانه یا حتی یک مشخصات فنی جداگانه جدا می شوند، زیرا این الزامات می تواند بسیار پیچیده باشد.

همه الزامات دیگر اهمیت کمتری دارند و نیازی به توضیح ندارند. به نظر من فقط مستندات را سنگین می کنند و سود عملی کمی دارند. و توصیف الزامات ارگونومیک در قالب الزامات عمومی بسیار دشوار است؛ بهتر است آنها را به موارد کاربردی منتقل کنید. به عنوان مثال، شرط "دریافت اطلاعات در مورد قیمت یک محصول تنها با فشار دادن یک دکمه" ممکن است فرموله شود. به نظر من، این هنوز به الزامات عملکردی خاص نزدیک تر است، اگرچه به ارگونومی مربوط می شود. الزامات برای عملکردها (وظایف) انجام شده توسط سیستم این نکته اصلی و کلیدی است که موفقیت را تعیین می کند. حتی اگر همه چیز به خوبی انجام شود، و این بخش "3" باشد، نتیجه پروژه در بهترین حالت "3" خواهد بود، یا حتی پروژه به طور کلی شکست خواهد خورد. این همان چیزی است که در مقاله دوم که در شماره 5 خبرنامه درج خواهد شد با جزئیات بیشتری به آن خواهیم پرداخت. تا اینجاست که «قاعده سه خصلت الزامات» که در مورد آن صحبت کردم اعمال می شود. الزامات انواع وثیقه

GOST انواع زیر را شناسایی می کند:

• ریاضی
• اطلاعاتی
• وابسته به زبانشناسی
• نرم افزار
• فنی
• مترولوژیک
• سازمانی
• روشمند
• و دیگران…

در نگاه اول، این الزامات ممکن است بی اهمیت به نظر برسند. در اکثر پروژه ها این درست است. اما نه همیشه. چه زمانی این الزامات را شرح دهیم:

• هیچ تصمیمی اتخاذ نشده است که توسعه زبان (یا پلتفرم) انجام شود.
• این سیستم به یک رابط چند زبانه نیاز دارد (به عنوان مثال، روسی/انگلیسی)
• برای عملکرد سیستم، باید یک واحد مجزا ایجاد شود یا کارکنان جدید استخدام شوند.
• برای عملکرد سیستم، مشتری باید در روش های کاری تغییراتی داشته باشد و این تغییرات باید مشخص و برنامه ریزی شود.
• ادغام با هر تجهیزاتی مورد انتظار است و الزاماتی بر آن تحمیل می شود (به عنوان مثال، گواهینامه، سازگاری و غیره)
• موقعیت های دیگر ممکن است، همه اینها به اهداف خاص پروژه بستگی دارد.

بخش 5. ترکیب و محتوای کار برای ایجاد سیستم

بخش 6. رویه کنترل و پذیرش سیستم

الزامات عمومی برای پذیرش کار به تفکیک مراحل (فهرست شرکت ها و سازمان های شرکت کننده، مکان و زمان بندی)، روند هماهنگی و تایید مدارک پذیرش؛ اکیداً توصیه می کنم که مسئولیت مراحل ارسال کار و بررسی سیستم را بر عهده بگیرید. دقیقاً به همین دلیل است که نیازهای قابل آزمایش مورد نیاز است.اما حتی وجود الزامات قابل آزمایش ممکن است در هنگام تحویل سیستم کافی نباشد اگر روش پذیرش و انتقال کار به طور واضح بیان نشده باشد. به عنوان مثال، یک تله رایج: سیستم ساخته شده و کاملاً عملیاتی است، اما مشتری به دلایلی آماده کار در آن نیست. این دلایل می تواند هرکدام باشد: زمان نداشتن، اهداف تغییر کرده اند، کسی ترک می کند و غیره. و می گوید: «از آنجایی که ما هنوز در سیستم جدید کار نمی کنیم، به این معنی است که نمی توانیم مطمئن باشیم که کار می کند. بنابراین یاد بگیرید که مراحل کار را به درستی شناسایی کنید، و چگونه نتایج این مراحل را بررسی کنید. علاوه بر این، چنین روش هایی باید از همان ابتدا برای مشتری واضح باشد. اگر آنها در سطح مشخصات فنی ثابت هستند، در صورت لزوم می توانید همیشه به آنها مراجعه کنید و کار را با انتقال کامل کنید.

بخش 7. الزامات ترکیب و محتوای کار برای آماده سازی شی اتوماسیون برای راه اندازی سیستم

ممکن است قوانین دیگری برای وارد کردن اطلاعات اتخاذ شده توسط شرکت (یا برنامه ریزی شده) وجود داشته باشد. به عنوان مثال، قبلاً اطلاعات مربوط به یک قرارداد به صورت یک رشته متنی به هر شکلی وارد می شد، اما اکنون به شماره جداگانه، تاریخ جداگانه و ... نیاز است. چنین شرایطی می تواند زیاد باشد. برخی از آنها ممکن است با مقاومت کارکنان درک شوند، بنابراین بهتر است همه این موارد در سطح الزامات برای ترتیب ورود داده ها ثبت شوند. تغییراتی که باید در شی اتوماسیون ایجاد شود.

ایجاد شرایطی برای عملکرد شی اتوماسیون که تحت آن انطباق سیستم ایجاد شده با الزامات مندرج در مشخصات فنی تضمین می شود. هرگونه تغییری که ممکن است مورد نیاز باشد. به عنوان مثال، این شرکت یک شبکه محلی، یک ناوگان قدیمی از کامپیوترها که سیستم روی آنها کار نخواهد کرد، ندارد.

شاید برخی اطلاعات لازم روی کاغذ پردازش شده و اکنون باید وارد سیستم شود. اگر این کار را انجام ندهید، برخی از ماژول ها کار نمی کنند و غیره.

شاید چیزی ساده شده بود، اما اکنون باید با جزئیات بیشتری مورد توجه قرار گیرد، بنابراین شخصی باید طبق قوانین خاصی اطلاعات جمع آوری کند.

این لیست می تواند طولانی باشد، به مورد خاص پروژه خود نگاه کنید ایجاد بخش ها و خدمات لازم برای عملکرد سیستم.

زمان بندی و روش کار برای کارکنان و آموزش قبلاً در مورد این موضوع صحبت کرده ایم. شاید این سیستم برای ساختار یا نوع جدیدی از فعالیت که قبلا وجود نداشته است، توسعه یافته است. اگر پرسنل مناسب و حتی آموزش دیده وجود نداشته باشد، سیستم هر چقدر هم که شایسته ساخته شده باشد کار نخواهد کرد.

بخش 8. مدارک مورد نیاز

نحوه ارائه کتابچه راهنمای کاربر را در نظر بگیرید.

شاید مشتری استانداردهای شرکتی را پذیرفته باشد، به این معنی که باید به آنها مراجعه کنیم.

نادیده گرفتن الزامات مستندات اغلب منجر به غیرمنتظره ترین عواقب در پروژه ها می شود. به عنوان مثال، همه چیز انجام می شود و همه چیز کار می کند. کاربران همچنین می دانند که چگونه کار کنند. در مورد مستندات اصلاً توافق یا گفتگویی صورت نگرفت. و ناگهان در هنگام تحویل کار، یکی از مدیران ارشد مشتری که حتی در پروژه شرکت نکرده است، اما درگیر پذیرش کار است، از شما می پرسد: کتابچه راهنمای کاربر کجاست؟ و شروع به متقاعد کردن شما می کند که نیازی به توافق در مورد در دسترس بودن کتابچه راهنمای کاربر وجود ندارد، ظاهراً این "البته" ضمنی است. و بس، او نمی خواهد شغل شما را بگیرد. با هزینه چه کسی دستورالعمل ها را توسعه خواهید داد؟ بسیاری از تیم ها قبلاً به این قلاب افتاده اند.

بخش 9. منابع توسعه

بنابراین بهتر است به سادگی به گزارش نظرسنجی و الزامات افراد کلیدی مراجعه کنید.

و بنابراین، ما تمام بخش هایی را که می تواند در شرایط مرجع گنجانده شود در نظر گرفته ایم. "می توان" و نه "باید" دقیقاً به این دلیل که هر سندی باید برای دستیابی به نتیجه تدوین شود. بنابراین، اگر برای شما واضح است که بخش خاصی شما را به نتیجه نزدیک نمی کند، پس نیازی به آن ندارید و نیازی به اتلاف وقت برای آن ندارید.

اما هیچ مشخصات فنی صالحی نمی تواند بدون چیز اصلی انجام دهد: الزامات عملکردی. من می خواهم توجه داشته باشم که در عمل چنین مشخصات فنی رخ می دهد و چگونه! افرادی هستند که می توانند آب ها را در تمام بخش ها جدا کنند، الزامات کلی را به طور کلی شرح دهند و سند بسیار سنگین است و کلمات زیرکانه زیادی در آن وجود دارد و حتی ممکن است مشتری دوست داشته باشد. آن را (یعنی تایید خواهد کرد). اما ممکن است طبق آن کار نکند، یعنی. کاربرد عملی کمی دارد. در بیشتر موارد، چنین اسنادی زمانی متولد می شوند که شما نیاز به دریافت پول زیادی به طور خاص برای شرایط مرجع دارید، اما باید به سرعت و بدون فرو رفتن در جزئیات انجام شود. و به خصوص اگر معلوم باشد که موضوع جلوتر نخواهد رفت یا افراد کاملاً متفاوتی این کار را انجام خواهند داد. به طور کلی فقط برای مدیریت بودجه به خصوص بودجه دولتی.

در مقاله دوم ما فقط در مورد بخش 4 "الزامات سیستم" صحبت خواهیم کرد و به طور خاص الزامات را به دلایل وضوح، ویژگی و آزمایش پذیری فرمول بندی خواهیم کرد.

چرا الزامات باید واضح، مشخص و قابل آزمایش باشد.

زیرا تمرین نشان می دهد: در ابتدا ، بیشتر مشخصات فنی که توسط متخصصان تهیه می شود یا مورد تقاضا نیستند (با واقعیت مطابقت ندارد) یا برای کسی که باید آنها را اجرا کند مشکل ساز می شود. مشتری شروع به دستکاری شرایط و الزامات مبهم می کند. من چند نمونه از عباراتی که با آن مواجه شد، به چه چیزی منجر شد، و سپس سعی خواهم کرد توصیه هایی در مورد چگونگی جلوگیری از چنین مشکلاتی ارائه دهم.

از نویسنده:چگونه بنویسیم شرایط مرجع (TOR) برای توسعه وب سایت? موضوع کاملاً گسترده است و تجزیه و تحلیل 100٪ آن در چارچوب یک یادداشت (در صورت امکان) دشوار است. اما من سعی خواهم کرد مقررات کلی را در مورد مواردی که باید در نظر گرفته شود و مواردی که هنگام تنظیم شرایط مرجع برای یک وب سایت باید به آنها توجه کنید با جزئیات کافی بیان کنم.

بنابراین، مشخصات فنی برای توسعه وب سایت

مشخصات فنی برای توسعه دهنده آماده شده است. هنگام تنظیم قرارداد بین مشتری و پیمانکار باید به شرایط مرجع اشاره شود. مسئولیت عدم انجام یا عدم انجام صحیح نکات و مهلت ها از طرف دو طرف باید قید شود. اما مهمترین چیزی (به نظر من) که مشخصات فنی برای آن ایجاد می شود سرعت بخشیدن به روند توسعه پروژه.

بیایید این مثال را تحلیل کنیم:

بیایید فرض کنیم که شما به یک تقویم در جایی در کنار وب سایت خود نیاز دارید. به نظر چیز کوچکی بود. اما هرچه عملکرد آن را با جزئیات بیشتری توصیف کنید، سریعتر به نتیجه خواهید رسید.

اجازه بدهید اینجا کمی توضیح بدهم. یک تقویم وجود دارد که به سادگی اعداد را بر اساس روز هفته از ماه جاری نشان می دهد. و قابلیت ورق زدن ماه ها وجود دارد. یک تقویم با قابلیت ورق زدن ماه ها و سال ها وجود دارد.

جاوا اسکریپت. شروع سریع

فرض کنید گزینه دوم را می خواهید (با قابلیت پیمایش ماه ها و سال ها) با برجسته شدن تاریخ فعلی. در شرایط مرجع شما اشاره کردید: "یک تقویم در نوار کناری مورد نیاز است." آنها اولین گزینه را به شما می دهند (به سادگی اعداد را بر اساس روز هفته از ماه جاری نشان می دهد).

آن چه که ما داریم. پیمانکار مشخصات را برآورده کرد، اما شما چیزی کاملاً متفاوت می خواستید. به نظر می رسد همه چیز مطابق است، هیچ کس مقصر نیست، هیچ درگیری وجود ندارد، اما مهم ترین چیز از دست رفته است زمان و پول.

این یک نمونه از یک تقویم پیش پا افتاده است.

اگر مجبور باشید کار جدی‌تری را که پردازش آن به بیش از نیم روز نیاز دارد، مانند تقویم، دوباره انجام دهید، چه؟ پیمانکار زمانی با شما مشغول است که بتواند پروژه شما را تمام کند و پروژه جدیدی را شروع کند.

بنابراین، از جزئیات بیشترشما عملکرد هر ماژول را توضیح دهید، سریعتر به نتیجه خواهید رسید. هر دو طرف باید به این موضوع علاقه داشته باشند.

مشخصات فنی معمولاً شامل چه نکاتی است؟

بیایید تصور کنیم که شما مالک یک شرکت یا شرکت هستید. شرکت شما به تولید هر محصول و فروش آن مشغول است. شما خریدار دارید شما با فروشندگان (فروشگاه ها و فروشگاه های آنلاین)، مراکز خدمات و مصرف کنندگان محصول همکاری می کنید. یا در حال ساختن منبعی برای چنین شرکتی هستید و باید مشخصات فنی بنویسید.

صرف نظر از اینکه چه نقشی ایفا می کنید، اولین کاری که باید قبل از ترسیم مشخصات فنی برای ایجاد یک طراحی وب سایت انجام دهید، مطالعه ساختار سازمان، آنچه انجام می دهد، نام گذاری، ویژگی ها و به طور کلی هر چیزی که با محصول مرتبط است را مطالعه کنید. و شرکت آنچه روی منبع اتفاق می افتد بستگی به این دارد که مشتری تا چه حد عمیقاً ماهیت آنچه را که در شرکت اتفاق می افتد درک کند. بنابراین، وظیفه در اینجا متقابل است: مشتری باید تا آنجا که ممکن است در مورد شرکت با جزئیات بیشتر صحبت کند و پیمانکار باید جوهر آنچه را که اتفاق می افتد کاملاً درک کند.

حتی اگر خودتان در حال نوشتن مشخصات فنی برای شرکتی هستید که پروژه شما را انجام می دهد، ایده خوبی است که همه آن را روی یک تکه کاغذ کشف کنید.

بیایید نقطه به نقطه پیش برویم.

شرح

در اینجا می توانید در چند جمله درباره شرکت و کارهایی که انجام می دهد بنویسید. کاری شبیه مقدمه انجام دهید.

برای چه کسی - مخاطب هدف:

خریداران بالقوه

فروشندگان محصول (فروشگاه ها، فروشگاه های آنلاین)

مراکز خدماتی

شرکا (شرکت ها)

مصرف کنندگان محصولات (کسانی که قبلا خریداری کرده اند)

چرا به وب سایت نیاز دارید:

برای بهبود وجهه شرکت

برای افزایش فروش

برای راحتی مشتری

شرکت های بزرگ، دارای شخصیت حقوقی

وب سایت – کارت ویزیت

فروشگاه آنلاین

نسخه های زبان:

انگلیسی

سایت باید برخی از مشکلات را حل کند. بر این اساس، ما بیشتر به سمت اهداف و مقاصد حرکت می کنیم.

اهداف و مقاصد

در این بخش از مشخصات فنی، کل مخاطبان هدف را مرور می کنیم و محدوده وظایفی را که سایت باید برای آنها حل کند، شرح می دهیم.

خریداران بالقوه محصول

هدف:خریداران بیشتری را جذب کنید و آنها را متقاعد کنید که اولین خرید خود را انجام دهند، به آنها در انتخاب کمک کنید.

مشکلات باید حل شوند:

ارائه اطلاعات با کیفیت بالا و جامع در مورد محصولات، خدمات اضافی، ضمانت ها، خدمات و روش های انتخاب.

اطلاعاتی در مورد نمایشگاه ها ارائه دهید

اطلاعاتی در مورد شبکه خرده فروشی ارائه دهید

با سازماندهی مشاوره آنلاین خریداران بالقوه توسط متخصصان شرکت در مورد مسائل انتخاب و خرید محصولات، فرصتی برای طرح سوال فراهم کنید.

بنابراین، ما از طریق کل مخاطبان هدف می گذریم. ما همچنین اهداف و اهداف فروشندگان محصول (فروشگاه ها، فروشگاه های آنلاین)، مراکز خدمات، شرکا (شرکت ها) و مصرف کنندگان محصول را شرح می دهیم. یعنی سایت به طور خاص برای هر کدام از آنها چه کاری باید انجام دهد.

اکنون ماژول ها را لیست می کنیم.

عملکرد سایت

برای فهرست کردن عملکرد، باید تصمیم بگیرید که چه چیزی نیاز دارد:

آیا ثبت نام لازم است؟

آیا به بخش بسته نیاز دارم (فقط برای کاربران ثبت نام شده)

آیا فرم بازخورد لازم است؟

و غیره. و غیره

جاوا اسکریپت. شروع سریع

اصول اولیه جاوا اسکریپت را با یک مثال عملی از نحوه ایجاد یک برنامه وب بیاموزید.

بعد از اینکه همه اینها را توضیح دادیم، به مهم ترین و جالب ترین چیز می رسیم. البته، تمام کارهای انجام شده در بالا بسیار مهم است، اما در حال حاضر حتی داغ تر می شود.

شرح عملکرد

در حال حاضر، ما می دانیم که سایت برای چه کسی است، چه اهداف و اهدافی را باید برآورده کند، و عملکرد اضافی آن.

زمان آن فرا رسیده است که شما باید تمام اطلاعات جمع آوری شده را در سیستم بیاورید و آن را به زیبایی مرتب کنید. برای آسان‌تر کردن کار و عدم اختراع مجدد چرخ، می‌توانید به منابعی در موضوعات مشابه نگاه کنید. چیزی از آنها بگیرید، به عملکرد آنها نگاه کنید و امتحان کنید و آنچه که ناخوشایند به نظر می رسید، سعی کنید آن را در پروژه خود بهبود بخشید. در اصل، می توانید در همان ابتدای تهیه مشخصات فنی، به سایت هایی با موضوعات مشابه نگاه کنید (و اگر تجربه ندارید، حتی نیاز دارید).

پیشنهاد می کنم با آیتم های منو شروع کنید. باید صفحات اصلی را نمایش دهد و مطمئن شود که هر بازدید کننده به سرعت اطلاعاتی را برای خود پیدا می کند. و بازدیدکنندگان مخاطب هدف ما هستند. منو شامل موارد زیادی است، بنابراین به صورت یک لیست کشویی خواهد بود.

ابتدا باید در مورد شرکت به ما بگویید. ممکن است صفحاتی در مورد شرکت، تاریخچه شرکت، مخاطبین، نظرات وجود داشته باشد.

به طور طبیعی، باید یک آیتم منو "محصولات"، با موارد فرعی "کاتالوگ محصولات"، "انتشارها"، "بررسی محصول" وجود داشته باشد.

به طور کلی، امیدوارم نحوه توصیف آن واضح باشد. اجازه دهید نسخه نهایی منوی ممکن را ارائه کنم:

درباره شرکت

تاریخچه شرکت

مخاطب

محصولات

کاتالوگ محصولات

بررسی محصول

بخش خدمات

خدمات گارانتی

خدمات پس از گارانتی

به مصرف کننده

خرید و تحویل

استفاده کنید

در مورد خدمات

مغازه ها و فروشگاه های آنلاین

عکس های محصول

سوالات متداول

مراکز خدماتی

چگونه به یک مرکز خدمات تبدیل شویم

سوالات متداول

شرکای

دعوت به همکاری

سوالات متداول

به نظر می رسد ما منو را مرتب کرده ایم. اکنون باید توضیح دهید که در هر صفحه چه چیزی وجود دارد و چگونه کار می کند. به علاوه یک طرح تقریبی ارائه دهید. می توان آن را روی یک کاغذ با مداد ترسیم کرد، اسکن کرد و به مشخصات فنی چسباند. تنها چیزی که می گویم این است که تخیل طراح را محدود نکنید، آن را به کلی ترین شکل ترسیم کنید.

این قسمت بسته به اینکه می خواهید صفحه شما چگونه به نظر برسد تغییر می کند. شاید به تعداد زیادی بنر در بالا نیاز نداشته باشید، شاید لازم باشد مخاطبین (آدرس، تلفن، فکس) را در بالا نشان دهید، شاید به شکل نمادهای "نقشه سایت"، "خانه"، "مخاطبین". شاید شما نیازی به اخبار در سمت چپ نداشته باشید، اما "تبلیغات و انتشارات" را در سمت چپ نشان دهید.

نکته اصلی اکنون شرح منطق کار است.

منطق عملیات

من بر اساس تصویر بالا توضیح خواهم داد.

هدر در هر صفحه یکسان می ماند. فید اخبار فقط در صفحه اصلی قابل مشاهده است. در صفحات ثانویه سمت چپ، آیتم‌های فرعی منو موردی را که در حال حاضر در آن هستیم نشان می‌دهیم (به عنوان مثال، اگر در صفحه «خدمات مشتری» هستیم، پیوندهایی به «خدمات گارانتی»، «خدمات پس از گارانتی» را نشان می‌دهیم. ”). بر این اساس با کلیک بر روی این لینک ها به صفحات مربوطه هدایت می شود. در اینجا، در زیر آیتم های سمت چپ، داده هایی را برای تماس با مشاوران آنلاین (اسکایپ، ICQ) نمایش می دهیم. بلوک تبلیغات و انتشارات در هر صفحه باقی می ماند. پاورقی در هر صفحه یکسان نمایش داده می شود.

منطق کلی کار تقریباً به این صورت است.

اکنون، در شرایط مرجع خود برای توسعه وب سایت، هر بلوک تعیین شده از سایت را با جزئیات شرح می دهیم. به عنوان مثال، "فید خبری".

"فید اخبار" از 10 آخرین اخبار. هر خبر باید شامل عنوان خبر، تاریخ انتشار، شروع مختصر خبر (4 تا 5 خط) و لینک «خواندن کامل» باشد. با کلیک بر روی لینک "خواندن کامل" به صفحه خبر منتقل می شوید. خبری که با آن مواجه شدید به جای محتوای اصلی نمایش داده می شود. عنوان خبر و تاریخ انتشار را نیز شامل می شود. فید اخبار نیز در سمت چپ نمایش داده می شود. اخبار ماه ها و سال های گذشته بایگانی می شود. یعنی در زیر اخبار ماه جاری "آرشیو برای (فلان ماه یا سال)" را نمایش می دهیم. وقتی روی پیوند «آرشیو برای (فلان ماه یا سال)» کلیک می‌کنید، فهرستی از اخبار مربوط به ماه/سال مربوطه ظاهر می‌شود.

نحوه عملکرد هر بلوک به این صورت است. حادثه تقویم را فراموش نکنیم. و مهمتر از همه، شما باید کار کاتالوگ محصول را شرح دهید. در اینجا من به شما یک وظیفه می دهم:سعی کنید فکر کنید و نحوه کار کاتالوگ را شرح دهید. گزینه های خود را از طریق ایمیل ارسال کنید. ما بهترین را منتشر خواهیم کرد.

چه چیز دیگری باید وجود داشته باشد؟ خوب است که سازگاری را نشان دهیم.

سازگاری

در این پاراگراف از شرایط مرجع ما برای ایجاد یک وب سایت، نشان می دهیم که وب سایت در کدام سیستم عامل ها و در کدام مرورگرها باید به همان اندازه خوب به نظر برسد. در چه نسخه ای باید به چه زبانی نوشته شود. چه CMS استفاده می شود. اگر واقعاً می دانید در مورد چه چیزی صحبت می کنید، ارزش آن را دارد که به این موضوع اشاره کنید.

اگر این سوالات را نمی دانید، به سادگی مرورگرهایی را که سایت باید در آنها به درستی نمایش داده شود را مشخص کنید. برای بقیه، به وجدان مجری تکیه کنید.

نتیجه

در این مقاله سعی نکردم نشان دهم که مشخصات فنی به این صورت است و هیچ راه دیگری نیست. این کار را انجام دهید و مشکلی پیش نخواهد آمد. یک کیفی بنویسید شرایط مرجع برای توسعه وب سایت- این بیشتر یک سوال است تجربه. همه نمی توانند در چند سال اول مشخصات فنی مناسب ایجاد کنند.

در این مقاله قصد داشتم یک مثال و اصولی را نشان دهم که بر اساس آن یک نمونه مشخصات فنی برای توسعه طراحی و منطق یک وب سایت ساخته شده است و همچنین نکات اصلی قابل توجه است. چقدر موفق شدم امیدوارم از نظرات شما بفهمم.

و در مورد وظیفه فراموش نکنید!