BA / SE

SE#4.2 საინფორმაციო სისტემის მოთხოვნების შექმნის პროცესი (Requirements Engineering process)

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

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

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

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

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

hass June30 table

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

Related imageპრაქტიკული თვალსაზრისით, აღნიშნული პროცესი განმეორებადია (iterative process), მუდმივად მიმდინარეობს მოთხოვნების გადახედვა და დაზუსტება. იგი შედგება შემდეგი აქტივობებისგან:

  • Requirements elicitation – მოთხოვნების მოგროვება;
  • Requirements analysis – მოთხოვნების ანალიზი;
  • Requirements validation – მოთხოვნების დადასტურება;
  • Requirements management- მოთხოვნების მართვა.

რომელიც დიაგრამაზე ასე შეიძლება გამოვსახოთ:

 

Image result for Requirements Engineering process picture

საინფორმაციო სისტემის მოთხოვნების შექმნის პროცესი

 

 

აღნიშნული საკითხები განხილულია განხილულია შემდეგ თავში – BA #1.2 Requirements elicitation and analysis აქ მოკლედ ავღნიშნავთ, რომ ამ პროცესის შემდეგნაირად მიმდინარეობს:

  1. Requirements discovery – სისტემის გამოვლენილ მფლობელებთან (stakeholders)  ერთად,  მომხმარებლის და სისტემის  მოთხოვნების მოგროვება
  2. Requirements classification and organization – მოგროვილი ინფორმაციის კლასიფიკაცია და დაჯგუფება;
  3. Prioritization and negotiation – მოგროვილი ინფორმაციის პრიორიტიზირება, შესაძლო შეუსაბამობების აღმოფხვრა და სისტემის მფლობელებთან შეთანხმება;
  4. Requirements specification – შეთანხმებული მოთხოვნების დოკუმენტირება და წარდგენა შემდეგი ანალიზისთვის ან შესრულებისთვის (დამოკიდებულია გამოყენებულ SE მეთოდოლოგიაზე).

როგორც ზემოთ ჩანს, პროცესის დასაწყისში წარმოებს უმნიშვნელოვანესი აქტივობის  – სისტემასთან კავშირში მყოფი ობიექტების გამოვლენა (stakeholders identification and analysis). მათგან მოგროვებული ინფორმაციის ხარისხზე და შემდგომ ანალიზზე, მნიშვნელოვნად არის დამოკიდებული სისტემის შექმნის გეგმის ხარისხი, მის შესრულების  და შემდეგი მომსახურების წარმატება.

Categories of stakeholders #1

  • Players – Have both an interest and significant power.
  • Subjects – Have interest but little power
  • Context Setters – Have power but little direct interest
  • Crowd – Those with little interest or power

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

ინტერვიუების ჩანაწერების შედეგად, ნატურალურ, თხრობით ფორმაში, იქმნება მომხმარებლის სისტემასთან ურთიერთობის შესახებ ჩანაწერები მათ საფუძველზე იქმნება მომხმარებლის აქტივობები და სისტემასთან ურთიერთობის სცენარები (User stories and scenarios).

Requirements specification

მოთხოვნების სპეციფიკაციების  (Requirements specification) დადგენის პროცესი წარმოადგენს, სისტემის მომხმარებლის და სისტემის მოთხოვნების დოკუმენტირების აქტივობებს.

  • User requirements – are almost always written in natural language supplemented by appropriate diagrams and tables in the requirements document.
  • System requirements may also be written in natural language but other notations based on forms, graphical system models, or mathematical system models can also be used.
  • Natural language is expressive, intuitive and universal. This means that the requirements can be understood by users and customers. #1

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

  • User requirements have to be understandable by end-users and customers who do not have a technical background.
  • System requirements are more detailed requirements and may include more technical information.
  • The requirements may be part of a contract for the system development and it is important that these are as complete as possible. #1

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

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

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

User stories and scenarios are real-life examples of how a system can be used, which are usually easy for stakeholders to understand. Scenarios should include descriptions of the starting situation, the normal flow of events, what can go wrong, other concurrent activities, the state of the system when the scenario finishes. #1, #2

მომხმარებლის აქტივობები და სისტემასთან ურთიერთობის სცენარები (User stories and scenarios, User Cases) –  UML  სტანდარტში შემდეგი გრაფიკული გამოსახულება აქვთ:

User stories და scenarios –  საკითხები განხილულია სტატიაში BA #1.3 Use Case Modeling

მოკლედ ავღნიშნოთ პროგრამული სისტემების მოთხოვნების ინჟინერიიის პროცესის თავისებურებები:

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

Problems to look for during requirements elicitation and analysis:

  • Stakeholders don’t know what they really want.
  • Stakeholders express requirements in their own terms.
  • Different stakeholders may have conflicting requirements.
  • Organizational and political factors may influence the system requirements.
  • The requirements change during the analysis process.
  • New stakeholders may emerge and the business environment may change.

Requirements validation – სისტემის მოთხოვნების ვალიდაცია

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

რას უნდა მიექცეს ყურადღება:

  • Validity – შესაბამისობა:  სისტემის სპეციფიკაციების და შემკვეთის მოთხოვნების შესაბამისობა;
  • Consistency –  თავსებადობა:  მომხმარებლის და სისტემის მოთხოვნებს შორის კონფლიქტებს (ტექნოლოგიური, ხარისხი, საკანომდებლო, უსაფრთხოება …);
  • Completeness – სისრულე: გათვალისწინებულია თუ არა ყველა წყაროს მოთხოვნა;
  • Realism: can the requirements be implemented given available budget and technology – შესაძლებელია თუ არა არსებული ბიუჯეტით და რესურსებით დოკუმენტირებული მოთხოვნების შესაბამისი სისტემის შექმნა;
  • Verifiability – შესრულების შემოწმების შესაძლებლობა – შესაძლებელია თუ არა სამუშაოების შესრულების შემდეგ,  ფაქტობრივად მიღებულ შედეგების დოკუმენტირებულ მოთხოვნებთან შედარება.

Requirements validation techniques – სისტემის მოთხოვნების ვალიდაციიის ინსტრუმენტები

    ამ მიზნით გამოიყენება შემდეგი ინსტრუმენტები:

1. Requirements reviews – დაფიქსირებული მოთხოვნების მუდმივი, განხილვა, განახლება და ანალიზი, რომლის დროსაც უნდა გავითვალისწინოთ შემდეგი:

  • Verifiability: is the requirement realistically testable? – შესაძლებელია მოთხოვნების შესრულების გადამოწმება ?
  • Comprehensibility: is the requirement properly understood? – შესაძლებელია მოთხოვნების ცალსახა შეფასება?
  • Traceability (#): is the origin of the requirement clearly stated? – შესაძლებელია მოთხოვნის წარმოშობის ძირითადი მიზეზის დადგენა?
  • Adaptability: can the requirement be changed without a large impact on other requirements? – შესაძლებელია თუ არა მოთხოვნების შეცვლა, სხვა მოთხოვნების რადიკალურად შეცვლის გარეშე.

2. Prototyping – სისტემის პროტოტიპის, მინიმიზებული მუშა ვერსიის შექმნა, დეკლარირებული  მოთხოვნების შესამოწმებლად;

3. Test-case generation – სისტემის ტესტირების სცენარების შექმნა, სისტემის შემოწმების შესაძლებლობის დასადგენად.

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

  • Stakeholders Identification #1
  • Stakeholder Analysis #1, #2, #3
  • Stakeholders Identification and Analysis Techniques #1#2, #3
  • UML 2 Use Case Diagrams: An Agile Introduction #1
  • All about Requirements #1, #2
  • ღია და დახურული კითხვები #1

კითხვები:

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

2 thoughts on “SE#4.2 საინფორმაციო სისტემის მოთხოვნების შექმნის პროცესი (Requirements Engineering process)

  1. Pingback: SE#4.1 Requirements Engineering | Innovation Times

  2. Pingback: SE#8.1 Software Testing – სისტემის ტესტირება | The Digital Times

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s