embedding RAI into RE
elicitation
objective: gather requirement from stakeholder
technique: interview, survey, questionaire, observation, document analysis, workshop
outcome: comprehensive list of functional and non functional requirement
embedding principal RAI
melakukan penilaian kembali apakah sistem yang dibangun benar-benar membutuhkan AI, bisa dilakukan dengan metode questionnaire
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 diskusi/workshop dengan semua domain expert yang berhubungan dan AI expert untuk melakukan finalisasi terhadap list RAI principle yang perlu didaftarkan sebagai requirement.
analysis
objective: Analyze and refine the gathered requirements to ensure they are complete, consistent, and unambiguous.
Activities: Conflict resolution, prioritization, and feasibility analysis.
Outcome: A detailed understanding of the requirements and identification of potential issues.
embedding principal RAI
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
menilai apakah requirement RAI tersebut dapat secara kontinyu divalidasi selama development dan selama software digunakan di production (feasibility)
melakukan conflict resolution dan prioritization berdasarkan risk based analysis yang sudah dilakukan sebelumnya
specification
Objective: Document the analyzed requirements in a clear and precise manner.
Documents: Software Requirements Specification (SRS), use cases, user stories, and models (e.g., UML diagrams).
Outcome: A formal requirements document that serves as a reference for the development team.
embedding principal RAI
Spesifikasikan bagaimana melakukan verifikasi RAI requirement
user acceptance criteria
metric apa yang diukur
bagaimana cara mengukurnya
acceptable treshold value
lingkungan
development
testing
production
RAI requirement perlu dimasukan kedalam user story, sehingga dapat ditrack pada proses design, development, testing sampai development
Spesifikasikan emergency measurement ketika RAI requirement dilanggar
validation
Objective: Ensure the documented requirements accurately reflect the stakeholders' needs and are feasible to implement.
Techniques: Reviews, walkthroughs, inspections, and prototyping.
Outcome: Validation of requirements to ensure correctness, completeness, and feasibility.
embedding principal RAI
melakukan workshop untuk mereview kembali software requirement specification
memastikan tidak ada principle RAI yang penting untuk diimplementasikan terlewat
memastikan semua RAI requirement dapat diverifikasi pada semua tahap dan lingkungan pengembangan software
memastikan semua stakeholder paham akan pentingnya pemenuhan RAI requirement
resiko dan dampak harus dapat diquantisasi
management
Objective: Handle changes to requirements throughout the project lifecycle.
Activities: Version control, traceability, change impact analysis, and communication with stakeholders.
Outcome: Controlled and managed evolution of requirements over time, ensuring that changes are systematically handled.
embedding principal RAI
melakukan penilaian kembali akan RAI requirement ketika ada perubahan requirement
memunculkan RAI requirement yang baru
mengeliminasi RAI requirement yang sudah ada
mengubah prioritas RAI requirement yang sudah ada