Requirements discovery and feasibility
Most failed projects fail before design starts, because the team solved the wrong problem. The PL-600 exam tests whether you can find the real requirement, check it is feasible, and agree how success is measured.
Learn how work really happens
Use more than one technique and match it to the question.
| Technique | Best for |
|---|---|
| Job shadowing | Seeing the real process, workarounds and pain points |
| Interviews | Goals, rules and priorities from stakeholders |
| Workshops | Agreeing scope across departments |
| Document review (RFP, policies) | Stated requirements and constraints |
| Process mining and task mining | Finding automation candidates from data |
When a scenario says processes are inconsistent across departments, the answer is almost always to observe the work, not to ask managers.
Task mining and process mining
Process advisor in Power Automate has two parts. Process mining analyses event logs from systems. Task mining records what users do on the desktop with a recorder and builds a process map, which shows where desktop flows could help. The exam may ask you to order the steps: create the process, install and run the recorder, record, then analyse.
Evaluate the data
When you review the current data landscape, ask about its influences:
- Quality: duplicates, gaps, inconsistent formats.
- Location: where it lives and in which region.
- History: how much must be kept and migrated.
- Pain points: where users struggle today.
User access matters for security design, but the classic data influences are quality, location, history and pain points.
Test feasibility
Each requirement is checked on three fronts:
- Technical: can the platform do it with standard features?
- Level of effort: is the cost and time reasonable?
- Compliance: does it meet legal and industry rules?
A requirement can be technically possible and still be rejected on compliance or effort.
Prioritise and define success
Group requirements with a method such as MoSCoW (must, should, could, won’t). Success criteria must be measurable and connect to business value, such as reduced handling time or employee adoption. Technical numbers like tables built are outputs, not outcomes.
Fit-gap in one sentence
Fit-gap compares requirements with what a standard app or Dataverse feature already does. Prefer configuration over customisation, because it survives platform updates and costs less.
Exam traps
- Interviewing directors instead of shadowing the people who do the work.
- Treating “technically possible” as “feasible” when compliance or effort fails.
- Choosing a cost or technical metric as the success criterion when the goal is a business outcome.
- Confusing process mining (system logs) with task mining (desktop recording).
- Recommending custom code when a standard feature meets the requirement.
Practice questions
Choose an answer, then review the explanation to check your understanding.
1. A company sends meeting summaries in many different ways. You must understand the real current process before looking for automation. What is the best approach?
Show answer
Answer: B.Job shadowing shows what people actually do. Directors describe the intended process, and an RFP describes the wish, not the practice.
2. A bank wants a feature that records customer data. Which feasibility check confirms that laws and regulations are respected?
Show answer
Answer: C.Regulated industries need a compliance feasibility check, separate from technical feasibility and effort.
3. A new checkout system must be usable by all workers. Which success criterion best shows the project works?
Show answer
Answer: A.A success criterion measures a business outcome tied to the goal. If workers do not use the system, it has failed, so adoption is the right measure.