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