SE#4.1 საინფორმაციო სისტემების მოთხოვნები (Requirements Engineering)

Reference: Sommerville, Software Engineering, 10 ed., Chapter 4

საინფორმაციო სისტემების მოთხოვნების ინჟინერია – Requirements engineering (RE)

Requirements engineering (RE) –  საინფორმაციო სისტემების მოთხოვნების ინჟინერია – იმ პროცესების ერთობლიობაა, რომელთა საშუალებითაც განისაზღვრება, საინფორმაციო სიტემისათვის, მომხმარებლის მოთხოვნები და შეზღუდვები,  საინფორმაციო სისტემის და მისი კომპონენტებისადმი მოთხოვნების ერთობლიობა Requirements  (R).

Requirements
მოთხოვნების ცვლილების გამო პროექტის ფასის ცვლილება, სისტემის  შექმნის სხვადასხვა ეტაპზე

არაზუსტ მოთხოვნების მიხედვით შექმნილი სისტემის ფუნქციონირება, შეიძლება საერთოდ მიზანშეუწონელი გახდეს, მის გამოსასწორებლად საჭირო დანახარჯების გამო. ამიტომ მნიშვნელოვანია მოთხოვნები, სისტემის საბოლოო მფლობელთან ზუსტად ჩამოყალიბდეს და შეთანხმდეს  მისი შექმნის ადრეულ ეტაპზე.

The Institute of Electrical and Electronics Engineers (IEEE) defines a requirement as:

  1. A condition or capability needed by a user to solve a problem or achieve an objective.
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
  3. A documented representation of a condition or capability as in (1) or (2). (IEEE, 1990). Well-defined requirements help make sure client needs are understood and addressed and also help help detect potential problems before they become large and expensive to fix

R – ის დეტალიზაცია შეიძლება იყოს, როგორც განზოგადებული, ასევე სიღრმისეული, მათემატიკური სიზუსტის ფუნქციონალური სპეციფიკაცია. არჩევანი დამოკიდებულია კონკრეტულ მოთხოვნებზე. მნიშვნელოვანია R  აღწერდეს  თუ რას უნდა აკეთებდეს და არა როგორ უნდა აკეთებდეს სისტემა.

As much as possible, requirements should describe what the system should do, but not how it should do it.

პრაქტიკული თვალსაზრისით, საინფორმაციული სისტემისადმი ორი ტიპის მოთხოვნა განიხილება:

საინფორმაციო სისტემის მომხმარებლის მოთხოვნები – User requirements
განზოგადებული (High-level abstract requirements), ნატურალური ენით დაწერილი ტექსტი, გრაფიკული დიაგრამები, რომლებიც აღწერენ სისტემის მიერ, მისი მომხმარებლისთვის წარმოებულ სერვისებს და მის ოპერირების საზღვრებს.
საინფორმაციო სისტემის მოთხოვნები – System requirements / functional specificatios
წარმოადგენს სისტემის კომპონენტების ფუნქციების, სერვისების  და ოპერირების სამოქმედო არეალის დეტალურ, ცალსახა და ზუსტ აღწერას.   იგი როგორც წესი ხდება შემსრულებელსა და შემსყიდველს შორის ხელშეკრულების საგანი.

საინფორმაციო სისტემების მოთხოვნები, თავის მხრივ სამ კლასად იყოფა:

  1. ფუნქციონალური მოთხოვნები – Functional requirements,
  2. არა ფუნქციონალური მოთხოვნები –  Non-functional requirements,
  3. ოპერირების გარემოს მოთხოვნები – Domain requirements.

მომხმარებლის საჭიროებები (Needs) და სურვილები (Wants)

ხარისხიანი პროდუქტის შექმნა გულისხმობს სისტემის მომხმარებლისთვის ღირებულების შექმნას.  ამიტომ მომხმარებლის მოთხოვნების მოპოვების და ჩამოყალიბების დროს მნიშვნელოვანია განვასხვავოთ, სისტემის მომხმარებლის საჭიროებები (Needs) მისი სურვილებისგან (Wants). კარგად უნდა გვესმოდეს ამ ორ ცნებას შორის განსხვავება. მომხმარებლის საჭიროებები, ესაა ძირითადი, აუცილებელი ფუნქციონალი რომელიც უნდა ჰქონდეს პროდუქტს, მომხმარებლის მიზნების მისაღწევად.  მომხმარებლის სურვილები  (Wants), როგორც მისი სახელიდან ჩანს, პროდუქტის დამატებითი, არა აუცილებელი შესაძლებლობებია. პროდუქტის შექმნის დაგეგმვის დროს უნდა მოხდეს მათი პრიორიტეტიზაცია, წინააღმდეგ შემთხვევაში მივიღებთ პროდუქტს, რომელიც ერთი შეხედვით სრულყოფილია,  მაგრამ ვერ ასრულებს მომხმარებლის მიზნებს.

მნიშვნელოვანია შევნიშნოთ რომ, ერთი მომხმარებლის სურვილები შესაძლებელია მეორე მომხმარებლის საჭიროებები იყოს და პირიქით. ამ პირობებში, ბიზნეს ოპერირების წარმატებულად წარმართვისთვის, წარმოებული პროდუქტის სახით  ღირებულების შექმნის დროს, ცალსახად უნდა განისაზღვროს პროდუქტის საბოლოო მომხმარებელი.

ასევე უნდა განვასხვავოთ, პროდუქტის მომხმარებელი (User) და  საბოლოო მომხმარებელი (End User).  მომხმარებელი ხშირ შემთხვევაში თქვენ გიხდით სერვისის საფასურს, საბოლოო მომხმარებელი კი მომხმარებელს.  შედეგად მათი საჭიროებების და მთხოვნების ანალიზი და სინთეზი განსაზღვრავს თქვენი ბიზნეს მოდელის წარმატებას.

ფუნქციონალური მოთხოვნები – Functional requirements

ფუნქციონალური მოთხოვნები, წარმოადგენს სისტემის და მისი კომპონენტებისადმი მოთხოვნებს. მასში აღიწერება სისტემის კომპონენტების ურთიერთ ოპერირების და მონაცემების დამუშავების სქემები, ოპერირების მოსალოდნელი, არასასურველი ან მიუღებელი შედეგები. მოთხოვნები ყალიბდება როგორც ცალკეული მოდულების ისე მთლიანი სიტემის ფუნქციონირებისთვის.

რადგან პრაქტიკულად შეუძლებელია ზედმიწვნით ზუსტი ფუნქციონალური მოთხოვნების დეკლარირება (#1), ამიტომ ამოცანის შესრულების ხარვეზების მინიმიზირებისთვის, სამუშაო ჯგუფი უნდა ეცადოს მოთხოვნები დეკლარირებული იქნეს ცალსახად  და აკმაყოფილებდნენ შემდეგ პირობებს:

  • Complete: – სრული – აღიწეროს სისტემის ყველა კომპონენტი და მისი ფუნქციონირების მოთხოვნები;
  • Consistent: – თანმიმდევრული / თავსებადი / ჰარმონიზირებული – სისტემის ცალკეული კომპონენტების მოთხოვნები არ უნდა ეწინაღმდეგებოდენ სისტემის სხვა კომპონენტების და მთლიანად სისტემის მოთხოვნებს.

არა ფუნქციონალური მოთხოვნები –  Non-functional requirements

არა ფუნქციონალური მოთხოვნები, სისტემის და (და არა მისი კომპონენტების) ხარისხობრივი მოთხოვნებია იგი ადგენს მთლიანი სისტემის ფუნქციონირების შესაძლებლობების საზღვრებს და შეზღუდვებს. მაგალითად,  სერვისების ოპერირების დრო, სისტემის შექმნისთვის საჭირო დრო, აქტივობების თანმიმდევრობა და კალენდარული გეგმა, გამოყენებული ინსტრუმენტები, სამუშაო გარემო და მუშაობის სტანდარტები.  
სისტემის ცალკეული კომპონენტის არა ფუნქციონალურმა მოთხოვნამ შეიძლება განსაზღვროს ან შეზღუდოს მთლიანი სისტემის მოთხოვნები და არქიტექტურა. მაგ,  SIA (Security, Integrity Aviability) – უსაფრთხოების, ინტეგრირების, ხელვისაწვდომობის ან გამოყენებლი პროგრამული საშუალებების მოთხოვნებმა, შეიძლება გავლენა მოახდინოს სისტემის ოპერირების გარემოსადმი მოთხოვნებზე.

არა ფუნქციონალური მოთხოვნები,  3 კლასს მიეკუთვნებიან:

  • Product requirements –  სისტემის / პროდუქტის მახასიათებლები, ოპერირების სიჩქარე, კიბერ უსაფრთხოების მოთხოვნები და ა.შ.
  • Organizational requirements – სისტემის შექმნის პროცესის და მისი განთავსების ადგილის ორგანიზაციული მოთხოვნები და რეგულაციები. მაგ სტანდარტები, ინსტრუმენტები და ა.შ.
  • External requirements – მოთხოვნები რომელთა შესრულება აუცილებელია, ორგანიზაციის ოპერირების,  გარემო ფაქტორების გავლენით. მაგ. საკანომდებლო მოთხოვნები, სამთავრობო სისტემაში ოპერირების მოთთხოვნები, გარემოში და დაკავშირებულ სერვისებტან ოპერირების სტანდარტები  და ა.შ.
FuncNonFunct.JPG

ოპერირების გარემოს მოთხოვნები – Domain requirements

აღნიშნულ დოკუმენტში აღიწერება, სისტემის ოპერირების გარემოს მოთხოვნები და შეზღუდვები.  მაგალითად, დამოუკიდებელ სისტემებს შორის ურთიერთ ოპერირების მოთხოვნები (InterOperatibility).  აღნიშნული შეთანხმების გარეშე ცალკეულმა სისტემებმა შეიძლება წარმატების შეასრულონ თავის დავალებები ორგანიზაციიების მასშტაბით, მაგრამ პრობლემები შეიქმნას სხვა სისტემებთან ინფორმაციის გაცვლის მოთხოვნის წარმოშობის შემთხვევაში. .

ამის ნათელი მაგალითია, ქვეყნის მაშტაბით არსებული იუსტიციის სახლები (http://www.psh.gov.ge/),  საზოდადოებრივი ცენტრები (http://www.centri.gov.ge),  დისანციური მომსახურეობის სერვისები, რომელიც საქართველოს მოქალაქეებს საქართველოში და მის ფარგლებს გარეთ, აწოდებს მრავალფეროვან სამთავრობო სერვისებს. თავის მხრივ სერვისების მიმწოდებლები არიან, სამოქალაქო რეესტრი, საჯარო რეესტრი, განათლების და მეცნიერების სამინისტრო, ჯანდაცვის სამინისტრო, საგარეო საქმეთა სამინისტრო, ლტოლვილთა და განსახლების სამინისტრო, აღსრულების ბიურო და ა.შ. და მათ შორის მონაცემტა გაცვლის სტანდარტების არ ქონა, შეაფერხებდა მოქალაქეებისთვის კომბინირებული, სამთავრობო სერვისების მიწოდების ამოცანას.

წარმოდგენილი მაგალითიდან ჩანს, რომ სამთავრობო თუ გლობალური სისტემების შექმნის პროცესში, გათვალისწინებული  უნდა იქნეს, ორგანიზაციის  სერვისების მიწოდების სტრატეგიები და პერსპექტიული მიმართულებები.

მოთხოვნების იდენტიფიცირების, მოგროვების და დამუშავების საკითხს ეხმაურება სტატია – “საინფორმაციო სისტემების მოთხოვნების ინჟინერიიის პროცესი” #1

საკითხავი მასალა:

  • IIBA BABOK® Guide v3 #1, #2
  • Agile Extension to the BABOK Guide – Agile Alliance,
  • Requirements Engineering  #1,
  • Requirements Analysis #2
  • Functional vs Non Functional Requirements #1
  • Requirements Engineering – Georgia Tech – Software Development Process #1, #2
  • The Difference Between Wants vs. Needs in Economics #1

დავალება:

  1. რა შედეგები შეიძლება გამოიწვიოს, სისტემის შექმნის ადრეულ ეტაპზე მოთხოვნების არაზუსტმა  ჩამოყალიბებამ და მის სისტემის საბოლოო მფლობელთან შეუთანმებლობამ ?
  2. წარმოდგენილი სისტემისთვის ჩამოთვალეთ ფუნქციონალური, არაფუნქციონალური და გარემოს მოთხოვნები.
  3. რატომ არის მნიშვნელოვანი, საინფორმაციო სისტემების შემუშავების დროს, დამოუკიდებელ სისტემებს შორის, ოპერირების მოთხოვნების (InterOperatibility) დადგენა ?
  4. რას წარმოადგენს თვითეული მათგანი და რა  განსხვავებაა საინფორმაციო სისტემის მომხმარებლის და საინფორმაციო სისტემის მოთხოვნებს შორის ?
  5. რას წარმოადგენს თვითეული მათგანი დარა  განსხვავებაა საინფორმაციო სიტემების ფუნქციონალურ და არაფუნქციონალურ მოთხოვნებს შორის ?
  6. შესაძლებელია თუ არა, სისტემის ცალკეული კომპონენტის არა ფუნქციონალურმა მოთხოვნამ განსაზღვროს ან შეზღუდოს მთლიანი სისტემის მოთხოვნები და არქიტექტურა ? დასახელეთ მაგალითი.
  7. შესაძლებელია თუ არა, ზედმიწვნით ზუსტი ფუნქციონალური მოთხოვნების დეკლარირება ? რატომ ?
  8. სამთავრობო თუ გლობალური სისტემების შექმნის პროცესში, გათვალისწინებული  უნდა იქნეს თუ არა, ჩართული ორგანიზაციების  სერვისების მიწოდების კონფიგურაციები და სტრატეგიები ? რატომ ?

12 comments

  1. […] Software specification- პროგრამული უზრუნველყოფის  სპეციფიკაცია – შემკვეთის და შემსრულებლის ერთობლივი მუშაობით განისაზღვრება, სისტემის ფუნქციონალური მახასიათებლები და შესრულების საზღვრები (#); […]

    Like

  2. […] სისტემისადმი მოთხოვნები, ამოცანის მიზნები და საზღვრები დგინდება შემსრულებლის და შემკვეთის მონაწილეობით და შეტანხმებით. შედეგად ყალიბდება სისტემის სპეციფიკაციების დოკუმენტი; (Requirements Engineering) […]

    Like

  3. […] წინა სტატიაში  განვიხილეთ ბინზეს იდეის შესაბამისი, შესაძლო მომხმარებლების იდენტიფიცირების საკითხი. წინამდებარე სტატიის მიზანია, მოვახდინოთ ბიზნესის მომხმარებლის რაც შეიძლება ზუსტი პროფილის შექმნა და მისთვის ღირებულების შექმნის და შეთავაზების მექანიზმების შემუშავება. აღნიშნული პროცესი დაგვეხმარება, ბიზნეს მოდელის პროტიტიპის შემუშავებაში, როელიც არ უნდა შეგვიყვარდეს და მოვამზადოთ იგი კრიტიკული შესწავლისთვის.  მომხმარებლის  მოთხოვნების მოკვლევაში და მათ ბიზნეს მოთხოვნებად ჩამოყალიბებაში დაგვეხმარება ჩვენს მიერ განხილული სტატია საინფორმაციო სისტემების მოთხოვნები (… […]

    Like

Leave a comment