Chapterبەش 1 · Lectureوانە 1.3
Requirements and Design: Deciding What to Buildپێداویستییەکان و دیزاین: بڕیاردان لەسەر ئەوەی چی دروست بکەین
How a team finds out what to build and plans how: asking why until the real need appears, stakeholders, gathering requirements, functional and non-functional requirements, testable requirements, user stories with INVEST and Given–When–Then acceptance criteria, use cases, MoSCoW and the product backlog, architecture and detailed design, a UML class diagram, modularity, coupling and cohesion, and a requirement turned into runnable checks with traceability — all on Bazaar Cart, an order app for a Sulaimani spice shop.
تیمێک چۆن دەدۆزێتەوە چی دروست بکات و چۆن پلانی بۆ دادەنێت: پرسینی بۆچی تا پێویستییە ڕاستەقینەکە دەردەکەوێت، ، کۆکردنەوەی ، و ، تاقیکراوە، لەگەڵ INVEST و Given–When–Then، ، و ، و دیزاینی ورد، ، ، و و کە دەکرێت بە پشکنینی جێبەجێکراو لەگەڵ — هەمووی لەسەر Bazaar Cart، داواکاری بۆ دوکانێکی بەهارات لە سلێمانی.
What you will learnچی فێر دەبیت
- Find the real need behind a request by asking why, and list a project's stakeholders.
- Tell functional from non-functional requirements and rewrite vague requirements so they can be tested.
- Write user stories with Given–When–Then acceptance criteria and order a backlog with MoSCoW.
- Explain architecture vs detailed design, read a simple UML class diagram, and judge coupling and cohesion.
- Turn a testable requirement into runnable checks and trace it from rule to code.
- بە پرسینی بۆچی پێویستییە ڕاستەقینەکەی پشت داواکارییەک بدۆزیتەوە و پڕۆژەیەک لیست بکەیت.
- لە جیا بکەیتەوە و ناڕوون دووپاتە بنووسیتەوە بۆ ئەوەی تاقی بکرێنەوە.
- لەگەڵ Given–When–Then بنووسیت و بە ڕیز بکەیت.
- جیاوازیی و دیزاینی ورد ڕوون بکەیتەوە، سادە بخوێنیتەوە و و هەڵبسەنگێنیت.
- تاقیکراوە بکەیت بە پشکنینی جێبەجێکراو و لە یاساوە تا کۆد بەدوای دابچیت.
What does Soran really need?سۆران بە ڕاستی چی پێویستە؟
Soran sells dried fruit, spices, black tea and honey in the Sulaimani bazaar (meet Bazaar Cart and the team). One day he tells Aram's team: “I want an app.” That sentence is not a requirement yet. A requirement is something the software must do, or must be, so that it solves a real problem. So Aram first asks why — and asks again after every answer.
سۆران لە بازاڕی سلێمانی میوەی وشک، بەهارات، چای ڕەش و هەنگوین دەفرۆشێت (Bazaar Cart و تیمەکە بناسە). ڕۆژێک بە تیمەکەی ئارام دەڵێت: « دەوێت». ئەم ڕستەیە هێشتا نییە. ئەو شتەیە کە دەبێت بیکات، یان دەبێت وا بێت، بۆ ئەوەی کێشەیەکی ڕاستەقینە چارەسەر بکات. بۆیە ئارام سەرەتا دەپرسێت بۆچی و دوای هەر وەڵامێک دیسان دەپرسێتەوە.
Why an app? Because phone orders get lost. Why do they get lost? Because on busy Thursday evenings the assistant writes them in a notebook while the phone keeps ringing, and some totals are wrong. Engineers call this the five whys: stop when the answer is “if we do not solve this, Soran's problem is not solved”. Two or three whys are often enough. Now the goal is clear: orders that cannot get lost, and totals that are always right.
بۆچی ؟ چونکە داواکارییە تەلەفۆنییەکان ون دەبن. بۆچی ون دەبن؟ چونکە لە ئێوارە قەرەباڵغەکانی پێنجشەممەدا یاریدەدەرەکە لە کاتێکدا تەلەفۆن بەردەوام زەنگ لێدەدات، داواکارییەکان لە دەفتەرێکدا دەنووسێت و هەندێک کۆی گشتی هەڵەن. ئەندازیاران ئەمە ناو دەنێن پێنج بۆچی: کاتێک بوەستە کە وەڵامەکە ئەوە بێت «ئەگەر ئەمە چارەسەر نەکەین، کێشەکەی سۆران چارەسەر نابێت». زۆرجار دوو یان سێ بۆچی بەسە. ئێستا ئامانجەکە ڕوونە: داواکارییەک کە ون نەبێت و کۆی گشتییەک کە هەمیشە دروست بێت.
Stakeholders: whom to askلایەنە پەیوەندیدارەکان: لە کێ بپرسین
A stakeholder is any person, group or organisation that takes part in the project, is affected by its result, or can change its result. Each one needs different things, so the team lists them before it asks any questions. For Bazaar Cart:
هەر کەس، گرووپ یان دامەزراوەیەکە کە بەشداری پڕۆژەکە دەکات، ئەنجامەکەی کاری تێدەکات، یان دەتوانێت ئەنجامەکەی بگۆڕێت. هەر یەکێکیان پێویستیی جیاوازی هەیە، بۆیە تیمەکە پێش هەر پرسیارێک لیستیان دەکات. بۆ Bazaar Cart:
- Soran, the owner: he pays for the app and decides what it must do.
- Customers: young people who order fast, and older customers who read only Kurdish.
- The delivery driver: he needs the address and the amount to collect.
- The assistant who takes phone orders today: the app changes his work.
- The team (Aram, Shilan, Karwan, Dilan), who build it and keep it working.
- The rules: customers' phone numbers and addresses must stay private.
- سۆران، خاوەنی دوکانەکە: پارەی دەدات و بڕیار دەدات دەبێت چی بکات.
- کڕیاران: گەنجان کە خێرا داوا دەکەن و کڕیارە بەتەمەنەکان کە تەنیا کوردی دەخوێننەوە.
- شۆفێری گەیاندن: ناونیشان و ئەو بڕە پارەیەی پێویستە کە وەری بگرێت.
- یاریدەدەرەکە کە ئەمڕۆ داواکاریی تەلەفۆنی وەردەگرێت: کارەکەی دەگۆڕێت.
- تیمەکە (ئارام، شیلان، کاروان، دیلان)، کە دروستی دەکەن و بە کارکردوویی دەیهێڵنەوە.
- یاساکان: کڕیاران دەبێت بپارێزرێت، واتە ژمارەی تەلەفۆن و ناونیشانەکانیان.
Gathering requirementsکۆکردنەوەی پێداویستییەکان
Requirements rarely arrive ready. People forget to mention what seems obvious to them, so the team digs in several ways:
بە دەگمەن ئامادە دێن. خەڵک ئەوەی بە لای خۆیانەوە ڕوونە لەبیریان دەچێت بیڵێن، بۆیە تیمەکە بە چەند ڕێگایەک هەڵیدەکۆڵێت:
- Interviews: Aram asks Soran and three regular customers open questions (“How do you take an order today?”). The English for such talks is practised in Collecting requirements.
- Watching the work: Dilan spends a busy Thursday evening in the shop and sees what really happens.
- Questionnaires: five short questions for 30 customers — which phone, which language, what time they order.
- Old records: the order notebook shows what sells and how orders are written.
- Prototypes and personas: paper screens that customers try, and one typical customer with a name — see Finding out who your users are.
- چاوپێکەوتن: ئارام پرسیاری کراوە لە سۆران و سێ کڕیاری بەردەوام دەکات («ئەمڕۆ چۆن داواکارییەک وەردەگریت؟»). ئینگلیزیی ئەم گفتوگۆیانە لە کۆکردنەوەی پێداویستییەکان ڕاهێنانی لەسەر کراوە.
- سەیرکردنی کارەکە: دیلان ئێوارەیەکی قەرەباڵغی پێنجشەممە لە دوکانەکە بەسەر دەبات و دەبینێت بە ڕاستی چی ڕوو دەدات.
- فۆرمی پرسیار: پێنج پرسیاری کورت بۆ 30 کڕیار — کام مۆبایل، کام زمان، لە چ کاتێکدا داوا دەکەن.
- تۆمارە کۆنەکان: دەفتەری داواکارییەکان پیشان دەدات چی دەفرۆشرێت و داواکارییەکان چۆن دەنووسرێن.
- و : شاشەی کاغەزی کە کڕیاران تاقیی دەکەنەوە و کڕیارێکی ئاسایی بە ناوێکەوە — بڕوانە دۆزینەوەی ئەوەی بەکارهێنەرەکانت کێن.
Then the team writes down what it heard and reads it back to Soran. The picture shows why.
دواتر تیمەکە ئەوەی بیستوویەتی دەینووسێت و بۆ سۆرانی دەخوێنێتەوە. وێنەکە پیشان دەدات بۆچی.
Functional and non-functional requirementsپێداویستییە فەنکشنییەکان و پێداویستییە نافەنکشنییەکان
Requirements come in two kinds. A functional requirement describes behaviour that people can see: what the software does — the rules it enforces and the steps it carries out. A non-functional requirement limits how it is built or how well it must work: which phones, which languages, how fast, how safe.
دوو جۆرن. ڕەفتارێک وەسف دەکات کە خەڵک دەیبینن: ئەوەی دەیکات — ئەو یاسایانەی جێبەجێیان دەکات و ئەو هەنگاوانەی ئەنجامیان دەدات. سنوور بۆ ئەوە دادەنێت کە چۆن دروست دەکرێت یان دەبێت چەند باش کار بکات: کام مۆبایل، کام زمان، چەند خێرا، چەند پارێزراو.
A test from SWEBOK, the IEEE guide to the field: imagine a perfect computer — endlessly fast, endless memory, free and never broken. Would you still need to write the requirement down? Then it is functional. If it matters only because real computers and networks are slow, limited or attacked, it is non-functional.
تاقیکردنەوەیەک لە SWEBOK، ڕێبەری IEEE بۆ ئەم بوارە: کۆمپیوتەرێکی تەواو بهێنە بەرچاوت — بێسنوور خێرا، بیرگەی بێسنوور، بێبەرانبەر و هەرگیز تێکناچێت. ئایا هێشتا پێویستە بنووسیت؟ کەواتە فەنکشنییە. ئەگەر تەنیا لەبەر ئەوە گرنگە کە کۆمپیوتەر و تۆڕە ڕاستەقینەکان خاو، سنووردار یان لەژێر هێرشدان، ئەوا نافەنکشنییە.
Good requirements can be testedپێداویستییەکانی باش تاقی دەکرێنەوە
A good requirement is clear (it can be read only one way), holds one idea, is testable (a tester can say pass or fail), and states the stakeholder's real need, not a solution. Words like fast, easy and modern cannot be tested until they get a number.
باش ڕوونە (تەنیا بە یەک شێوە دەخوێندرێتەوە)، یەک بیرۆکەی تێدایە، تاقی دەکرێتەوە ( دەتوانێت بڵێت دەرچوو یان دەرنەچوو) و پێویستیی ڕاستەقینەی دەڵێت، نەک چارەسەرێک. وشەی وەک خێرا، ئاسان و نوێ تاقی ناکرێنەوە تا ژمارەیەکیان بۆ زیاد نەکرێت.
| Vagueناڕوون | Betterباشتر |
|---|---|
| “The app must be fast.”« دەبێت خێرا بێت.» | On 4G, the total appears within 2 seconds after a line changes.لەسەر 4G، کۆی گشتی لە ماوەی 2 چرکەدا دوای گۆڕانی دێڕێک دەردەکەوێت. |
| “Delivery should be cheap.”«گەیاندن دەبێت هەرزان بێت.» | Delivery inside Sulaimani costs 3,000 IQD and is free from a 50,000 IQD goods total (R4).گەیاندن لە ناو سلێمانی 3,000 دینارە و لە کۆی 50,000 دیناری کاڵاوە بێبەرانبەرە (R4). |
| “The app must be easy to use.”« دەبێت ئاسان بێت.» | A first-time customer places an order in under 3 minutes without help.کڕیارێکی نوێ لە کەمتر لە 3 خولەکدا بێ یارمەتی داواکارییەک دەنێرێت. |
| “Handle orders, payments, SMS and receipts.”«داواکاری، پارەدان، و پسوولە بەڕێوە ببات.» | Four requirements, one idea each.چوار ، هەر یەکەیان یەک بیرۆکە. |
| “Use a MySQL table for orders.”«خشتەیەکی MySQL بۆ داواکارییەکان بەکار بهێنە.» | Orders are still there after the phone or the server restarts. (Ask why — the table was a solution.)داواکارییەکان دوای دووپاتە هەڵکردنەوەی مۆبایل یان هێشتا هەن. (بپرسە بۆچی — خشتەکە چارەسەرێک بوو.) |
User storiesچیرۆکەکانی بەکارهێنەر
Agile teams often write requirements as user stories: one sentence from the user's point of view, in the form As a ⟨role⟩, I want ⟨something⟩, so that ⟨benefit⟩. For example: As a customer, I want to see the delivery fee before I order, so that I know the full price.
تیمە زۆرجار وەک دەنووسن: یەک ڕستە لە ڕوانگەی ، بەم شێوەیە: وەک ⟨ڕۆڵ⟩، دەمەوێت ⟨شتێک⟩، بۆ ئەوەی ⟨سوود⟩. بۆ نموونە: وەک کڕیارێک، دەمەوێت پێش داواکردن کرێی گەیاندن ببینم، بۆ ئەوەی نرخی تەواو بزانم.
A story is not a full document. Ron Jeffries (2001) described three C's: a card that names it, a conversation in which the team and the customer fill in the details, and a confirmation — the tests that show it is done. Bill Wake's checklist INVEST (2003) says a good story is Independent, Negotiable, Valuable, Estimable, Small enough for one sprint, and Testable.
بەڵگەنامەیەکی تەواو نییە. ڕۆن جێفریز (2001) سێ C وەسف کرد: کارتێک (card) کە ناوی دەنێت، گفتوگۆیەک (conversation) کە تیمەکە و کڕیارەکە وردەکارییەکانی تێدا پڕ دەکەنەوە و پشتڕاستکردنەوەیەک (confirmation) — ئەو تاقیکردنەوانەی پیشان دەدەن تەواو بووە. لیستی پشکنینی INVESTـی بیل وەیک (2003) دەڵێت باش سەربەخۆیە (I)، دەکرێت گفتوگۆی لەسەر بکرێت (N)، بەهای هەیە (V)، دەکرێت ماوەکەی خەمڵێنرێت (E)، ئەوەندە بچووکە کە لە یەک جێی ببێتەوە (S) و تاقی دەکرێتەوە (T).
User storiesچیرۆکەکانی بەکارهێنەر
Acceptance criteria: Given, When, Thenپێوەرەکانی پەسەندکردن: Given، When، Then
The confirmation is written as acceptance criteria: the exact conditions under which Soran accepts the story. A popular form comes from behaviour-driven development (Dan North and Chris Matts): Given the situation before, When the user acts, Then the result that must follow. Each scenario is one example with real numbers.
پشتڕاستکردنەوەکە وەک دەنووسرێت: ئەو مەرجە وردانەی کە سۆران لەژێریاندا چیرۆکەکە پەسەند دەکات. شێوەیەکی باو لە گەشەپێدانی ڕەفتارتەوەرەوە هاتووە (دان نۆرث و کریس ماتس): Given (بەو پێیەی) بارودۆخی پێشوو، When (کاتێک) کارێک دەکات، Then (ئەوا) ئەو ئەنجامەی دەبێت دوای بکەوێت. هەر سیناریۆیەک یەک نموونەیە بە ژمارەی ڕاستەقینە.
Why 49,750? Line prices are rounded up to multiples of 250 IQD, so 49,750 is the largest goods total below the limit. Writing scenarios also shows gaps: what happens outside Sulaimani? R4 does not say, so Aram asks Soran before anyone writes code.
بۆچی 49,750؟ نرخی دێڕەکان بۆ چەندجارەکانی 250 دینار بەرز دەکرێنەوە، بۆیە 49,750 گەورەترین کۆی کاڵایە لە خوار سنوورەکەوە. نووسینی سیناریۆ کەلێنەکانیش پیشان دەدات: لە دەرەوەی سلێمانی چی دەبێت؟ R4 هیچی لەسەر نالێت، بۆیە ئارام پێش ئەوەی کەس کۆد بنووسێت لە سۆران دەپرسێت.
User storiesچیرۆکەکانی بەکارهێنەر
Use case or user story?حاڵەتی بەکارهێنان یان چیرۆکی بەکارهێنەر؟
You will also meet use cases, for example in the database life cycle. A use case describes step by step how an actor reaches a goal with the system: the main path and what happens when something goes wrong. A user story is shorter: a promise of a conversation, small enough to plan.
دەبینیت، بۆ نموونە لە خولی ژیانی بنکەدراوە. هەنگاو بە هەنگاو وەسف دەکات کە ئەکتەرێک چۆن لە ڕێگەی سیستەمەکەوە دەگاتە ئامانجێک: ڕێگا سەرەکییەکە و ئەوەی کاتێک شتێک هەڵە دەچێت ڕوو دەدات. کورتترە: بەڵێنی گفتوگۆیەکە و ئەوەندە بچووکە کە پلانی بۆ دابنرێت.
| Use case | User story | |
|---|---|---|
| Sizeقەبارە | A page of numbered stepsپەڕەیەک هەنگاوی ژمارەدار | One sentence + acceptance criteriaیەک ڕستە + |
| Holdsچی تێدایە | Main path, other paths, errorsڕێگای سەرەکی، ڕێگاکانی تر، هەڵەکان | Role, want, benefitڕۆڵ، ویست، سوود |
| Best forباشترە بۆ | Understanding a whole interactionتێگەیشتن لە کارلێکێکی تەواو | Planning small pieces of workپلاندانان بۆ پارچە کاری بچووک |
MoSCoW and the product backlogڕێگەی MoSCoW و لیستی کاری بەرهەم
Everything the product might need goes into the product backlog, an ordered list that the product owner — Aram — keeps up to date (the Scrum artifacts). To order it, many teams use the MoSCoW method from DSDM: Must have, Should have, Could have, Won't have this time. The English words are practised in MoSCoW; this is how a team decides:
هەموو ئەو شتانەی بەرهەمەکە لەوانەیە پێویستی پێیان بێت دەچنە ناو ، لیستێکی ڕیزکراو کە — ئارام — نوێی دەکاتەوە (بەرهەمەکانی Scrum). بۆ ڕیزکردنی، زۆر تیم لە DSDMـەوە بەکار دەهێنن: Must have، Should have، Could have، Won't have this time. وشە ئینگلیزییەکان لە MoSCoW ڕاهێنانیان لەسەر کراوە؛ تیمێک بەم شێوەیە بڕیار دەدات:
- A Must is part of the minimum usable product. Ask: “What happens if it is missing?” If the release is pointless without it, it is a Must; if there is a workaround, it is not.
- Musts take no more than about 60 % of the effort, and Coulds about 20 %. When time runs short, Coulds go first, so the Musts still arrive.
- Won't have this time is written down too, so nobody adds it quietly. It can return in a later version.
- Priorities are checked again at the end of every sprint.
- Must بەشێکە لە بچووکترین بەرهەمێک کە هێشتا بەکار بێت. بپرسە: «ئەگەر نەبێت چی دەبێت؟» ئەگەر بەبێ ئەو بێسوود بێت، Mustـە؛ ئەگەر ڕێگایەکی تر هەبێت، نا.
- Mustـەکان لە دەوروبەری 60%ی هەوڵ زیاتر نابن و Couldـەکان نزیکەی 20%. کاتێک کات کەم دێنێت، سەرەتا Couldـەکان لادەبرێن، بۆیە Mustـەکان هەر دەگەن.
- Won't have this timeـیش دەنووسرێت، بۆ ئەوەی کەس بە بێدەنگی زیادی نەکات. لە دواتردا دەتوانێت بگەڕێتەوە.
- پێشینەییەکان لە کۆتایی هەموو دووپاتە دەپشکنرێنەوە.
From requirements to designلە پێداویستییەکانەوە بۆ دیزاین
Requirements say what to build; design decides how. SWEBOK describes design as turning requirements into plans that programmers can build from, in stages that zoom in:
دەڵێن چی دروست بکرێت؛ دیزاین بڕیار دەدات چۆن. SWEBOK دیزاین وەک گۆڕینی بۆ پلان وەسف دەکات کە بتوانن لێیەوە دروست بکەن، بە چەند قۆناغێک کە لێی نزیک دەبنەوە:
- Architecture: the whole system and how its big pieces talk — for Bazaar Cart, a phone app, a server and an SQLite database.
- High-level design: the main parts inside and how they connect — prices, delivery, orders, storage.
- Detailed design: inside each part — classes, functions, data and algorithms, such as
line_price(price_per_kg, grams).
- : هەموو سیستەمەکە و ئەوەی پارچە گەورەکانی چۆن قسە دەکەن — بۆ Bazaar Cart، مۆبایل، و .
- دیزاینی ئاستی بەرز: بەشە سەرەکییەکانی ناوەوە و ئەوەی چۆن بە یەکەوە دەبەسترێن — نرخ، گەیاندن، داواکاری، هەڵگرتن.
- دیزاینی ورد: ناوەوەی هەر بەشێک — ، ، و ئەلگۆریزمەکان، وەک
line_price(price_per_kg, grams).
A house in Sulaimani is planned the same way: the plot plan, then the floor plan, then where each socket goes. Chapter 4 of this course returns to architecture with layers and MVC, MVP and MVVM.
خانوویەک لە سلێمانی بە هەمان شێوە پلانی بۆ دادەنرێت: نەخشەی زەوییەکە، دواتر نەخشەی نهۆمەکان، دواتر شوێنی هەر پریزێک. بەشی 4ی ئەم خولە بە چینەکان و MVC، MVP و MVVM دەگەڕێتەوە بۆ .
From requirements to designلە پێداویستییەکانەوە بۆ دیزاین
Design drawings, and one class diagramوێنەکانی دیزاین و هێڵکارییەکی کلاسی UML
Each design question has its own drawing, and each is taught in its own CêIT lesson: what a screen shows → a wireframe; what data is stored → an E-R model; in which order steps happen → a flowchart; which classes the code needs → a UML class diagram (how to draw a class box).
هەر پرسیارێکی دیزاین وێنەی خۆی هەیە و هەر یەکەیان لە وانەیەکی تایبەتی CêITـدا فێر دەکرێت: شاشەیەک چی پیشان دەدات ← وایەرفرەیم؛ چ هەڵدەگیرێت ← مۆدێلی قەوارە و پەیوەندی؛ هەنگاوەکان بە چ ڕیزێک ڕوو دەدەن ← هێڵکاریی ڕەوت؛ کۆدەکە چ پێویستە ← (چۆن چوارگۆشەی کلاسێک بکێشیت).
Here is Bazaar Cart's first class diagram. An Order holds one or more OrderLines, and each line refers to exactly one Product. Each box shows the data first and the methods below.
ئەمە یەکەم Bazaar Cartـە. Order یەک یان زیاتر OrderLineـی تێدایە و هەر دێڕێک ئاماژە بە ڕێک یەک Product دەکات. هەر چوارگۆشەیەک سەرەتا و لە خوارەوە پیشان دەدات.
Good parts: coupling and cohesionبەشی باش: پێکەوەبەستراوی و یەکگرتوویی
Two old principles guide good designs. Modularity: split a program into parts with one job each, as David Parnas argued in 1972. Separation of concerns: keep screens, rules and storage apart (separation of concerns). Then judge your parts in two ways:
دوو بنەمای کۆن ڕێنمایی دیزاینی باش دەکەن. : دابەش بکە بۆ چەند بەشێک کە هەر یەکەیان یەک کاری هەیە، وەک دەیڤید پارناس لە 1972ـدا بەرگریی لێ کرد. : شاشەکان، یاساکان و هەڵگرتن لێک جیا بکەرەوە (جیاکردنەوەی بەرپرسیارێتییەکان). دواتر بەشەکانت بە دوو شێوە هەڵبسەنگێنە:
- Coupling — how much one part depends on the inside of another. Aim for low (loose) coupling: you can change
delivery.pywithout touching the screens. - Cohesion — how well the things inside one part belong together. Aim for high cohesion:
delivery.pyholds only delivery rules.
- — بەشێک تا چەند پشت بە ناوەوەی بەشێکی تر دەبەستێت. ئامانج کەم (شل)ە: دەتوانیت
delivery.pyبگۆڕیت بێ ئەوەی دەست لە شاشەکان بدەیت. - — ئەو شتانەی لە ناو یەک بەشدان تا چەند پێکەوە دەگونجێن. ئامانج زۆرە:
delivery.pyتەنیا یاساکانی گەیاندنی تێدایە.
In a wedding kitchen one cook makes the rice, one the dolma and one the kebab. Each station keeps its own tools (high cohesion), and only finished pots pass through one window (low coupling). If the dolma cook is ill, someone else takes his station and the rice does not change.
لە چێشتخانەی ئاهەنگی بووک گواستنەوەدا، چێشتلێنەرێک برنج دروست دەکات، یەکێک دۆڵمە و یەکێک کەباب. هەر شوێنێک ئامرازەکانی خۆی لای خۆی دەهێڵێتەوە ( زۆر) و تەنیا مەنجەڵی ئامادە لە یەک پەنجەرەوە دەدرێت ( کەم). ئەگەر چێشتلێنەری دۆڵمە نەخۆش بێت، کەسێکی تر شوێنەکەی دەگرێتەوە و برنجەکە ناگۆڕێت.
Where the analogy stops workingسنووری ئەم نموونەیە
Cooks can talk and help each other; software parts only “talk” through the functions you give them.
چێشتلێنەرەکان دەتوانن قسە بکەن و یارمەتیی یەکتر بدەن؛ بەشەکانی تەنیا لە ڕێگەی ئەو پێیانی دەدەیت «قسە دەکەن».
From a requirement to a checkلە پێداویستییەکەوە بۆ پشکنینێک
A testable requirement can become a check that the computer runs. Here are R4's acceptance criteria as three assert lines (what assert does). If every check holds, the program prints its message; if one fails, Python stops with AssertionError.
تاقیکراوە دەتوانێت ببێت بە پشکنینێک کە کۆمپیوتەر جێبەجێی دەکات. ئەمانە R4ن وەک سێ دێڕی assert (assert چی دەکات). ئەگەر هەموو پشکنینەکان ڕاست بن، پەیامەکەی چاپ دەکات؛ ئەگەر یەکێکیان شکست بهێنێت، Python بە AssertionError دەوەستێت.
# Bazaar Cart, rule R4 (made-up prices in IQD):
# delivery inside Sulaimani costs 3,000 IQD,
# and it is free when the goods total is 50,000 IQD or more.
DELIVERY_FEE = 3_000
FREE_DELIVERY_FROM = 50_000
def delivery_fee(goods_total):
"""Delivery fee in IQD for one order inside Sulaimani."""
if goods_total >= FREE_DELIVERY_FROM:
return 0
return DELIVERY_FEE
# R4's acceptance criteria as three checks
assert delivery_fee(49_750) == 3_000 # just below the limit: pay
assert delivery_fee(50_000) == 0 # exactly at the limit: free
assert delivery_fee(120_000) == 0 # far above the limit: free
print("R4: all three checks passed")R4: all three checks passed
Explain the codeڕوونکردنەوەی کۆدەکە
- Lineدێڕی 10
>=because the limit itself (50,000) is already free.>=چونکە خودی سنوورەکە (50,000) بێبەرانبەرە.- Lineدێڕی 16-18
One check per example: just below, exactly at and far above the limit.
یەک پشکنین بۆ هەر نموونەیەک: کەمێک لە خوار، ڕێک لەسەر و زۆر لە سەرووی سنوورەکە.
Now one thread runs from Soran's rule to the code: R4 → story BC-7 → acceptance criteria → checks → delivery_fee(). This traceability tells the team, when a rule changes, which stories, tests and code must change too. Automated tests turn checks like these into a real test suite.
ئێستا یەک دەزوو لە یاساکەی سۆرانەوە بۆ کۆدەکە دەڕوات: R4 ← چیرۆکی BC-7 ← ← پشکنینەکان ← delivery_fee(). ئەمە پێی دەوترێت : کاتێک یاسایەک دەگۆڕێت، بە تیمەکە دەڵێت کام چیرۆک، تاقیکردنەوە و کۆد دەبێت ئەوانیش بگۆڕێن. تاقیکردنەوەی خۆکار پشکنینی لەم جۆرە دەکات بە کۆمەڵە تاقیکردنەوەیەکی ڕاستەقینە.
From a requirement to a checkلە پێداویستییەکەوە بۆ پشکنینێک
When a check failsکاتێک پشکنینێک شکست دەهێنێت
Karwan types > instead of >= on line 10. Two checks still pass, but the one exactly at the limit fails:
کاروان لە دێڕی 10ـدا لەبری >= دەنووسێت >. دوو پشکنین هێشتا دەردەچن، بەڵام ئەوەی ڕێک لەسەر سنوورەکەیە شکست دەهێنێت:
# Bazaar Cart, rule R4 (made-up prices in IQD):
# delivery inside Sulaimani costs 3,000 IQD,
# and it is free when the goods total is 50,000 IQD or more.
DELIVERY_FEE = 3_000
FREE_DELIVERY_FROM = 50_000
def delivery_fee(goods_total):
"""Delivery fee in IQD for one order inside Sulaimani."""
if goods_total > FREE_DELIVERY_FROM:
return 0
return DELIVERY_FEE
# R4's acceptance criteria as three checks
assert delivery_fee(49_750) == 3_000 # just below the limit: pay
assert delivery_fee(50_000) == 0 # exactly at the limit: free
assert delivery_fee(120_000) == 0 # far above the limit: free
print("R4: all three checks passed")Traceback (most recent call last):
File "~/se/bazaar-cart/delivery.py", line 17, in <module>
assert delivery_fee(50_000) == 0 # exactly at the limit: free
^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionErrorThe traceback names line 17, the check at exactly 50,000 IQD, so the bug is found before any customer pays a wrong fee. The fix is one character: goods_total >= FREE_DELIVERY_FROM. Checks written straight from the acceptance criteria catch exactly these mistakes at a limit.
ناوی دێڕی 17 دەبات، پشکنینەکەی ڕێک لەسەر 50,000 دینار، بۆیە پێش ئەوەی هیچ کڕیارێک کرێیەکی هەڵە بدات دەدۆزرێتەوە. چاککردنەکە یەک پیتە: goods_total >= FREE_DELIVERY_FROM. ئەو پشکنینانەی ڕاستەوخۆ لە دەنووسرێن ڕێک ئەم هەڵانە لەسەر سنوور دەگرن.
Common mistakesهەڵە باوەکان
Exercisesڕاهێنانەکان
Lana is building a timetable app for her high school in Duhok. Sort these into functional (F) and non-functional (NF): (a) a student sees today's lessons; (b) the app opens in under 2 seconds; (c) a teacher can swap two lessons; (d) it works without internet after the first download; (e) it shows the next lesson's room; (f) all text is in Kurdish (Badini and Sorani spelling).
لانا خشتەی وانەکان بۆ قوتابخانە ئامادەییەکەی لە دهۆک دروست دەکات. ئەمانە ڕیز بکە بۆ فەنکشنی (F) و نافەنکشنی (NF): (a) قوتابییەک وانەکانی ئەمڕۆ دەبینێت؛ (b) لە کەمتر لە 2 چرکەدا دەکرێتەوە؛ (c) مامۆستایەک دەتوانێت دوو وانە بگۆڕێتەوە؛ (d) دوای یەکەم بەبێ کار دەکات؛ (e) ژووری وانەی داهاتوو پیشان دەدات؛ (f) هەموو دەقەکان بە کوردین (ڕێنووسی بادینی و سۆرانی).
Hintئاماژە
Use the perfect-computer test.
تاقیکردنەوەی کۆمپیوتەری تەواو بەکار بهێنە.
Show answerوەڵامەکە پیشان بدە
F: (a), (c), (e) — behaviour you would still need on a perfect computer. NF: (b) speed, (d) working offline (a limit of real networks), (f) language.
F: (a)، (c)، (e) — ڕەفتارێک کە لەسەر کۆمپیوتەرێکی تەواویش هەر پێویستە. NF: (b) خێرایی، (d) کارکردن بەبێ (سنوورێکی تۆڕە ڕاستەقینەکان)، (f) زمان.
Rewrite each requirement so that Dilan can test it: (1) “The timetable must load quickly.” (2) “Changes must reach students soon.” (3) “The app must be secure.”
هەر دووپاتە بنووسەوە بۆ ئەوەی دیلان بتوانێت تاقیی بکاتەوە: (1) «خشتەکە دەبێت بە خێرایی بار ببێت.» (2) «گۆڕانکارییەکان دەبێت زوو بگەنە قوتابیان.» (3) « دەبێت پارێزراو بێت.»
Show answerوەڵامەکە پیشان بدە
- (1) On the school Wi-Fi, today's timetable appears within 2 seconds after the app opens.
- (2) A lesson change made by a teacher appears on students' phones within 5 minutes.
- (3) Split it: only teachers who sign in can change lessons; students' names are never shown to other schools. Each part can now be checked.
- (1) لەسەر قوتابخانە، خشتەی ئەمڕۆ لە ماوەی 2 چرکەدا دوای کردنەوەی دەردەکەوێت.
- (2) گۆڕینی وانەیەک کە مامۆستایەک کردوویەتی لە ماوەی 5 خولەکدا لەسەر مۆبایلی قوتابیان دەردەکەوێت.
- (3) دابەشی بکە: تەنیا ئەو مامۆستایانەی چوونەتە ژوورەوە دەتوانن وانەکان بگۆڕن؛ ناوی قوتابیان هەرگیز بە قوتابخانەکانی تر پیشان نادرێت. ئێستا هەر بەشێک دەپشکنرێت.
Write three user stories for Lana's app (one for a student, one for a teacher, one for the head teacher), then one Given–When–Then scenario for the teacher's story.
سێ بۆ لانا بنووسە (یەکێک بۆ قوتابی، یەکێک بۆ مامۆستا، یەکێک بۆ بەڕێوەبەر)، دواتر یەک سیناریۆی Given–When–Then بۆ چیرۆکەکەی مامۆستا.
Show answerوەڵامەکە پیشان بدە
- Student: As a student, I want to see my next lesson and its room, so that I am not late.
- Teacher: As a teacher, I want to swap two of my lessons, so that I can cover a sick colleague.
- Head teacher: As the head teacher, I want to see which rooms are free, so that I can plan exams.
- قوتابی: وەک قوتابییەک، دەمەوێت وانەی داهاتووم و ژوورەکەی ببینم، بۆ ئەوەی دوا نەکەوم.
- مامۆستا: وەک مامۆستایەک، دەمەوێت دوو لە وانەکانم بگۆڕمەوە، بۆ ئەوەی جێگای هاوکارێکی نەخۆشم بگرمەوە.
- بەڕێوەبەر: وەک بەڕێوەبەر، دەمەوێت ببینم کام ژوور بەتاڵە، بۆ ئەوەی پلانی تاقیکردنەوەکان دابنێم.
Given Mr Soran teaches class 10B in lesson 3 on Monday
And Ms Lana teaches class 10B in lesson 5 on Monday
When Mr Soran swaps lesson 3 with lesson 5
Then class 10B shows Ms Lana in lesson 3 and Mr Soran in lesson 5
And both teachers get a notificationLana has 10 working days for version 1. Estimates: see today's timetable (2 days), sign in for teachers (2), swap lessons (2), offline mode (3), dark theme (1), exam calendar (3), chat between students (4). Sort them with MoSCoW so that Musts stay near 60 % of the time.
لانا 10 ڕۆژی کاری هەیە بۆ 1. خەمڵاندنەکان: بینینی خشتەی ئەمڕۆ (2 ڕۆژ)، چوونەژوورەوە بۆ مامۆستایان (2)، گۆڕینەوەی وانەکان (2)، کارکردن بەبێ (3)، ڕووکاری تاریک (1)، ساڵنامەی تاقیکردنەوەکان (3)، چات لە نێوان قوتابیاندا (4). بە MoSCoW ڕیزیان بکە بۆ ئەوەی Mustـەکان لە نزیک 60%ی کاتەکەدا بمێننەوە.
Show answerوەڵامەکە پیشان بدە
One good answer: Must — timetable, teacher sign-in, swapping (6 days = 60 %). Should — offline mode (3). Could — dark theme (1). Won't have this time — exam calendar and chat (they do not fit, and chat needs safety rules for students). If time runs short, the dark theme goes first.
وەڵامێکی باش: Must — خشتە، چوونەژوورەوەی مامۆستا، گۆڕینەوە (6 ڕۆژ = 60%). Should — کارکردن بەبێ (3). Could — ڕووکاری تاریک (1). Won't have this time — ساڵنامەی تاقیکردنەوە و چات (جێیان نابێتەوە و چات پێویستی بە یاسای پاراستن هەیە بۆ قوتابیان). ئەگەر کات کەم بێنێت، سەرەتا ڕووکاری تاریک لادەبرێت.
Hana and Rebin are building Hawler Ride, a taxi app for Erbil. List at least six stakeholders and one thing each needs.
هانا و ڕێبین Hawler Ride دروست دەکەن، تەکسی بۆ هەولێر. لانیکەم شەش بنووسە و یەک شت کە هەر یەکەیان پێویستیەتی.
Show answerوەڵامەکە پیشان بدە
- Passengers: a fair price shown before the ride.
- Drivers: clear pickup points and fast payment.
- The taxi company owner: income and reports.
- Traffic police and city rules: licensed drivers only.
- Ordinary taxi drivers outside the app: the app affects their work.
- Hana and Rebin, the team: code they can keep fixing for years.
- سەرنشینان: نرخێکی دادپەروەرانە کە پێش سەفەرەکە پیشان بدرێت.
- شۆفێران: شوێنی هەڵگرتنی ڕوون و پارەدانی خێرا.
- خاوەنی کۆمپانیای تەکسی: داهات و ڕاپۆرت.
- پۆلیسی هاتوچۆ و یاساکانی شار: تەنیا شۆفێری مۆڵەتدار.
- شۆفێرە ئاساییەکانی تەکسی لە دەرەوەی : کار لە ئیشەکەیان دەکات.
- هانا و ڕێبین، تیمەکە: کۆدێک کە بتوانن بۆ چەندین ساڵ چاکی بکەنەوە.
In Lana's app, timetable.py reads the database, decides who may swap lessons, and builds the screen. Suggest a better split and say what improves.
لە لانادا، timetable.py دەخوێنێتەوە، بڕیار دەدات کێ دەتوانێت وانەکان بگۆڕێتەوە و شاشەکە دروست دەکات. دابەشکردنێکی باشتر پێشنیار بکە و بڵێ چی باشتر دەبێت.
Show answerوەڵامەکە پیشان بدە
Split it into storage.py (reading and saving), rules.py (who may swap what) and screens.py (showing). Each file now has high cohesion, and they talk only through a few functions (low coupling), so the swap rule can change — and be checked with asserts — without touching the screen code.
دابەشی بکە بۆ storage.py (خوێندنەوە و پاشەکەوتکردن)، rules.py (کێ دەتوانێت چی بگۆڕێتەوە) و screens.py (پیشاندان). ئێستا هەر زۆری هەیە و تەنیا لە ڕێگەی چەند قسە دەکەن ( کەم)، بۆیە یاسای گۆڕینەوە دەتوانێت بگۆڕێت — و بە assert بپشکنرێت — بێ ئەوەی دەست لە کۆدی شاشەکە بدرێت.
Summaryپوختە
- Ask why until you reach the real need; “an app” is a solution, not a requirement.
- Stakeholders: everyone who takes part in, is affected by or can change the project. Gather requirements by interviews, watching the work, questionnaires, old records and prototypes — then read them back.
- Functional = what the software does; non-functional = how well and with what. Good requirements are clear, one idea, testable and about the need.
- User stories: As a …, I want …, so that … (card, conversation, confirmation; INVEST). Acceptance criteria: Given … When … Then … with real numbers.
- MoSCoW orders the product backlog: Musts ≈ 60 % of the effort at most, Coulds are the contingency, Won'ts are written down.
- Design zooms in: architecture → high-level design → detailed design; use the right drawing (wireframe, E-R model, flowchart, UML class diagram).
- Aim for low coupling between parts and high cohesion inside them. Turn testable requirements into checks and keep traceability from rule to code.
- بۆچی بپرسە تا دەگەیتە پێویستییە ڕاستەقینەکە؛ «» چارەسەرێکە، نەک .
- : هەر کەسێک کە بەشداری پڕۆژەکە دەکات، کاری تێدەکرێت یان دەتوانێت بیگۆڕێت. بە چاوپێکەوتن، سەیرکردنی کار، فۆرمی پرسیار، تۆماری کۆن و کۆ بکەرەوە — دواتر بیانخوێنەرەوە بۆیان.
- فەنکشنی = ئەوەی دەیکات؛ نافەنکشنی = چەند باش و لەگەڵ چی. باش ڕوون، یەک بیرۆکە، تاقیکراوە و لەبارەی پێویستییەکەن.
- : وەک …، دەمەوێت …، بۆ ئەوەی … (کارت، گفتوگۆ، پشتڕاستکردنەوە؛ INVEST). : Given … When … Then … بە ژمارەی ڕاستەقینە.
- ڕیز دەکات: Mustـەکان زۆرترین ≈ 60%ی هەوڵ، Couldـەکان یەدەگن، Won'tـەکان دەنووسرێن.
- دیزاین نزیک دەبێتەوە: ← دیزاینی ئاستی بەرز ← دیزاینی ورد؛ وێنەی گونجاو بەکار بهێنە (، ، ، ).
- ئامانج کەمە لە نێوان بەشەکان و زۆرە لە ناویاندا. تاقیکراوە بکە بە پشکنین و لە یاساوە تا کۆد بپارێزە.
Next in the course: Git keeps the history of every change to Bazaar Cart's code — Git basics.
داهاتوو لەم خولەدا: Git مێژووی هەموو گۆڕانکارییەک لە کۆدی Bazaar Cartـدا هەڵدەگرێت — بنەماکانی Git.
Lesson complete!وانەکە تەواو بوو!
Well done. Review the key terms, then go on to the next lesson.دەستخۆش. سەیرێکی زاراوە سەرەکییەکان بکەرەوە، پاشان بڕۆ بۆ وانەی داهاتوو.
Key termsزاراوە سەرەکییەکان
Git Basics: Saving the History of Your Codeبنەماکانی Git: پاشەکەوتکردنی مێژووی کۆدەکەت
Related lecturesوانە پەیوەندیدارەکان
- What Is Software Engineering?ئەندازیاریی نەرمەواڵە چییە؟
- Building Softwareدروستکردنی نەرمەواڵە
- User Experience: Users, Wireframes and Prototypesئەزموونی بەکارهێنەر: بەکارهێنەران، وایەرفرەیمەکان و نموونە سەرەتاییەکان
- Entity-Relationship Modellingمۆدێلی قەوارە و پەیوەندی
- Algorithms, Pseudocode and Flowchartsئەلگۆریزمەکان، نیمچەکۆد و هێڵکارییەکانی ڕەوت
- Classes and Objects: Attributes and Methodsکلاسەکان و ئۆبجێکتەکان: تایبەتمەندییەکان و میتۆدەکان
- App Architecture: the MVVM Patternتەلارسازیی نەرمەواڵە: شێوازی MVVM
- Handling Errors with try and exceptمامەڵەکردن لەگەڵ هەڵاوێردە بە try و except
- Automated Testing: Code That Checks Your Codeتاقیکردنەوەی خۆکار: کۆدێک کە کۆدەکەت دەپشکنێت
- Layers and Business Logic: Where Each Rule Livesچینەکان و لۆجیکی کاروبار: هەر یاسایەک لە کوێ دەژی
- MVC, MVP and MVVM: Three Ways to Organise the ScreenMVC، MVP و MVVM: سێ ڕێگە بۆ ڕێکخستنی شاشە
- Course Project: Ship Bazaar Cart 1.0.0پڕۆژەی خولەکە: Bazaar Cart 1.0.0 بڵاو بکەرەوە
References and further readingسەرچاوەکان و خوێندنەوەی زیاتر
- SWEBOK Guide V4.0a (IEEE Computer Society, 2024): Software Requirements KA §1.4–1.8 (functional and nonfunctional requirements, the Perfect Technology Filter), §2 elicitation and stakeholders, §3.1 properties of good requirements and the 5 whys, §4.3 acceptance criteria and BDD, §7.3 tracing; Software Design KA §1.4 principles (coupling, cohesion, separation of concerns) and §2 design stages
- Agile Alliance glossary: User Stories
- Agile Alliance glossary: INVEST
- Ron Jeffries: Essential XP — Card, Conversation, Confirmation (2001)
- Martin Fowler: GivenWhenThen (2013)
- Agile Business Consortium (DSDM): MoSCoW Prioritisation
This lecture is a first edition. The Kurdish text and terminology are waiting for review by Kurdish IT teachers.ئەم وانەیە چاپی یەکەمە. دەقە کوردییەکە و زاراوەکانی چاوەڕێی پێداچوونەوەی مامۆستایانی کوردی بواری IT ن.