انتقل إلى المحتوى
أمين أبوزيد
SRC-001

هندسة المتطلبات

  • 7 درس
  • 4 ساعة تدريب (تقدير)
في هذه الصفحة 9 موضوعات

نص الدروس والتمارين باللغة الإنجليزية، بينما تبقى واجهة الموقع وعناوين الدروس بالعربية.

نظرة عامة

الموضوعات

  • المتطلبات الوظيفية مقابل غير الوظيفية
  • القيود
  • الافتراضات

تعلّم أولًا

4 ساعة تدريب (تقدير)

مخرجات التعلم

  1. Elicit functional and nonfunctional requirements from stakeholders who state goals, not requirements.
  2. Separate requirements, constraints, and assumptions, and record each explicitly.
  3. Write quality-attribute scenarios (source, stimulus, environment, response, measure).
  4. Identify missing, conflicting, and untestable requirements and resolve them with stakeholders.

الدروس

  1. 01لماذا تفشل الأنظمة في مرحلة المتطلبات
  2. 02المتطلبات الوظيفية مقابل غير الوظيفية
  3. 03القيود والافتراضات
  4. 04مقابلات أصحاب المصلحة التي تكشف الاحتياجات الحقيقية
  5. 05سيناريوهات سمات الجودة (Quality-attribute scenarios)
  6. 06التعارضات ومحادثات المفاضلة
  7. 07عرض عملي: تحويل "يجب ألا تضيع الطلبات أبدًا" إلى متطلبات قابلة للاختبار

المختبر والتمارين

Lab

SRC-001-LAB1 · Requirements for 10×

Outcomes: 1–4 · Time: ~2 h

  1. Role-play product, finance, and operations interviews (record them); a peer or assessor plays each stakeholder.
  2. Extract functional and nonfunctional requirements; separate constraints and assumptions into their own register.
  3. Write at least eight quality-attribute scenarios (source, stimulus, environment, artifact, response, measure) covering availability, latency, durability, scalability, security, and operability.
  4. List missing, conflicting, and untestable items; assign an owner to each conflict and propose options.
  5. Assemble the requirements document.

Acceptance: every scenario is measurable; conflicts listed with owners.

Exercises (case-based; six exercises)

IDOutcomeTask
SRC-001-EX011Product says "checkout must be fast and scalable". Write six interview questions that convert it into requirements.
SRC-001-EX022Classify ten statements about the order subsystem as requirement, constraint, or assumption and name an owner for each assumption.
SRC-001-EX033Write a six-part scenario for "order tracking stays available during a database failover".
SRC-001-EX043Rewrite three vague scenarios ("quick", "highly available", "secure") so each has a measure.
SRC-001-EX054Find the missing, conflicting, and untestable requirements in a given draft list of eight items.
SRC-001-EX064Prepare a trade-off conversation: 99.95% availability vs a flat infrastructure budget. Present two options with cost, risk, and recommendation.
أظهر الحلول
  • EX01 Examples: Which actions? What response time at which percentile? Peak load and when? What does a minute of downtime cost? What may degrade first? Who decides trade-offs?
  • EX02 Constraints are fixed (PostgreSQL as system of record, EU data residency); assumptions are beliefs to verify (peak 6× average); requirements need an owner and a measure.
  • EX03 Source: operations-triggered failover; stimulus: primary database loss; environment: peak hour; artifact: tracking API; response: reads served from replica, stale data flagged; measure: 99.9% of tracking requests succeed during a 60 s failover, staleness under 30 s.
  • EX04 "Quick" becomes p99 under 800 ms at 600 req/s; "highly available" becomes 99.95% monthly measured at the load balancer excluding planned maintenance; "secure" becomes a named threat and a response, e.g. credential stuffing blocked after 5 attempts per minute.
  • EX05 Missing: retention and recovery targets; conflicting: zero downtime deploys vs no extra environment; untestable: "user friendly". Resolve each with stakeholders and record the answer.
  • EX06 Option A second region (higher cost, meets target), option B multi-AZ with automated failover and a 15-minute recovery (cheaper, risk of regional outage); recommend by quantifying outage cost with Finance; record the decision and owner.

Outcome 1 is also covered by the interview recording in the lab; outcome 2 by the lab register.

Workplace evidence: a requirements or design document you wrote that changed scope or a target after stakeholder discussion.

الاختبار

Outcomes: O1 eliciting requirements · O2 requirements, constraints, assumptions · O3 quality-attribute scenarios · O4 missing, conflicting, untestable requirements.

اختبار ذاتي لك: لا توجد درجات، ولا يُحفظ أو يُرسل أي شيء. اختر إجابة ثم تحقق منها، ويمكنك المحاولة مرة أخرى كما تشاء.

  1. 1A stakeholder says "make it scalable". The best first move is to:O1
  2. 2Which interview question best surfaces a real need?O1
  3. 3"PostgreSQL remains the system of record" is a:O2
  4. 4"Peak traffic is about 6× the daily peak" not yet verified is a:O2
  5. 5What should every recorded assumption have?O2
  6. 6Which part of a scenario makes it testable?O3
  7. 7Which is a well-formed measure?O3
  8. 8"99.95% availability" and "no budget for extra infrastructure" are:O4
  9. 9"The UI must be user friendly" is mainly:O4
  10. 10Who should resolve a conflict between two stakeholders' requirements?O4

الجزء العملي

Six case exercises SRC-001-EX01 to EX06 plus the lab, with a recorded role-played interview. Pass: at least five of six exercises correct, quiz at least 8/10, and a requirements document passing the rubric (all scenarios measurable, conflicts with owners).

أخطاء شائعة

Accepting "fast" and "scalable" as requirements; hidden assumptions; designing before asking.

التقييم

Requirements review against a rubric; interview role-play recorded.

دليل من بيئة العمل

A requirements or design document you wrote that changed scope or a target after stakeholder discussion.

الصلة بالمسار الوظيفي

Requirements discovery for architects (ARC-003).

اكتب للبحث في المستويات والمراحل والوحدات والدروس.