カテゴリー 全て

によって Halim Munawar 6か月前.

47

embedding RAI into RE

Dalam proses pengembangan perangkat lunak, penting untuk memastikan bahwa semua persyaratan yang dianalisis terdokumentasi dengan jelas dan tepat. Proses ini melibatkan pengumpulan persyaratan dari pemangku kepentingan melalui berbagai teknik seperti wawancara, survei, kuesioner, observasi, dan analisis dokumen.

embedding RAI into RE

embedding RAI into RE

management

melakukan penilaian kembali akan RAI requirement ketika ada perubahan requirement

mengubah prioritas RAI requirement yang sudah ada

mengeliminasi RAI requirement yang sudah ada

memunculkan RAI requirement yang baru

Outcome: Controlled and managed evolution of requirements over time, ensuring that changes are systematically handled.
Activities: Version control, traceability, change impact analysis, and communication with stakeholders.
Objective: Handle changes to requirements throughout the project lifecycle.

validation

melakukan workshop untuk mereview kembali software requirement specification

memastikan semua stakeholder paham akan pentingnya pemenuhan RAI requirement

resiko dan dampak harus dapat diquantisasi

memastikan semua RAI requirement dapat diverifikasi pada semua tahap dan lingkungan pengembangan software

memastikan tidak ada principle RAI yang penting untuk diimplementasikan terlewat

Outcome: Validation of requirements to ensure correctness, completeness, and feasibility.
Techniques: Reviews, walkthroughs, inspections, and prototyping.
Objective: Ensure the documented requirements accurately reflect the stakeholders' needs and are feasible to implement.

specification

Spesifikasikan emergency measurement ketika RAI requirement dilanggar
RAI requirement perlu dimasukan kedalam user story, sehingga dapat ditrack pada proses design, development, testing sampai development
Spesifikasikan bagaimana melakukan verifikasi RAI requirement

lingkungan

production

testing

development

user acceptance criteria

acceptable treshold value

bagaimana cara mengukurnya

metric apa yang diukur

Outcome: A formal requirements document that serves as a reference for the development team.
Documents: Software Requirements Specification (SRS), use cases, user stories, and models (e.g., UML diagrams).
Objective: Document the analyzed requirements in a clear and precise manner.

analysis

melakukan conflict resolution dan prioritization berdasarkan risk based analysis yang sudah dilakukan sebelumnya
menilai apakah requirement RAI tersebut dapat secara kontinyu divalidasi selama development dan selama software digunakan di production (feasibility)
melakukan risk based analysis terhadap setiap RAI principle non functional requirement, apabila principle di takeout dari list requirement, seberapa kemungkinannya principle tersebut dilanggar, dan apa dampaknya terhadap pengguna, dan semua stakeholder terkait
Outcome: A detailed understanding of the requirements and identification of potential issues.
Activities: Conflict resolution, prioritization, and feasibility analysis.
objective: Analyze and refine the gathered requirements to ensure they are complete, consistent, and unambiguous.

elicitation

embedding principal RAI
melakukan diskusi/workshop dengan semua domain expert yang berhubungan dan AI expert untuk melakukan finalisasi terhadap list RAI principle yang perlu didaftarkan sebagai requirement.
untuk setiap requirement, minta stakeholder untuk memberikan pandangannya apakah requirement tersebut memiliki dampak terhadap RAI priciple dan seberapa besar (dapat dikuantisasi dengan nilai 1-5)
melakukan penilaian kembali apakah sistem yang dibangun benar-benar membutuhkan AI, bisa dilakukan dengan metode questionnaire
outcome: comprehensive list of functional and non functional requirement
technique: interview, survey, questionaire, observation, document analysis, workshop
objective: gather requirement from stakeholder