All BCS exams leading to practitioner certificates in a business analysis topic are based on a business scenario. The scenario is typically seeded with phrases that are intended to be the answers to the questions set in the exam. So, for example, in a Business Analysis Practice paper you might be asked to apply at least a partial PESTLE analysis; inspection of the scenario might identify a phrase such as "planned legislation to reduce planning requirements for converting business to residential property will ...". Thus one has found a Political factor.
Similarly, Modelling Business Processes includes the development of a to-be model and so the exam may ask for suggestions of possible improvements to the business practice. The scenario could include phrases indicating that staff are overworked, or that transactions pass through many hands, or that transactions are overly controlled and checked or handled in a poor sequence. So one simply needs to find these and suggest what sort of change would make improvements.
My point is that the intention of many questions is to see whether a candidate can marry a technique to a business situation. There is often an obvious answer lurking in the scenario, but exam candidates have the unfortunate habit of discarding the obvious perhaps they think it too obvious to be correct and provide answers which betray a fear that there could be something hidden. There is never a trick in exam questions for BCS Certificates!
This belief that there must be a devious trick shows itself all too frequently in respect of Requirements Engineering papers. It should come as no surprise to candidates that a key topic of the RE syllabus is the identification of requirements, it is fundamental to the role of a BA. It should also be no surprise that a scenario may well be seeded with phrases indicating requirements. All one has to do is find them. OK, it may not always be that simple, but the chances are that there is little need to conjure a requirement from thin air.
On various notes on our website I have tried to distinguish functional requirements from non-functional requirements and from acceptance criteria. In this note I am concerned solely with functional requirements.
Everyone knows what a requirement is, dont they? You might think that an exam question such as identify a functional requirement from the scenario would be trivially simple because the meaning of requirement is so well understood that there could not possibly be any confusion or misunderstanding. You would be wrong.
So, what is a requirement or, to be more precise, what is a business requirement? The standard answer to this is that it is something that needs to be conducted or achieved in order to meet a business objective. We would go further and add that it needs to be achieved, irrespective of how it is achieved.
Candidates in general seem to have grasped this but where they trip up is over granularity or, more correctly perhaps, the extent of processing to be regarded as a single requirement.
A scenario might say that users want to be able to retrieve details of an employee's address and project experience. Is this one or more than one requirement? Many exam candidates will state that this is two requirements. But lets analyse the situation. If the user is trying to assess whether the employee's experience and location together fit the employee for a new role then the combination of data is obviously necessary. It is one requirement.
A second example might be that users need to retrieve details of products satisfying certain materials characteristics, along with suppliers and likely order lead times. Is this a single requirement? Again, an analysis of why users are asking for this combination of data might reveal that they need to be able to find the best match for a set of material characteristics and to find who can supply them in the shortest time. If we separated the components of the stated requirement into parts then I believe we are mis-stating then need. It is one requirement!
In this second case we might want to discuss with the users why we could not devise an algorithm to give them a single answer rather than have them make a judgement, but thats a different question. The general point is that, simply because the description of a requirement includes 'and' does not automatically make it two requirements. It is totally dependent on what the users are trying to achieve.
So, getting back to exams and scenarios, functional requirements should be identifiable from the given case; requirements generally start with the words 'to do' or at least include them somewhere; but consider carefully whether the extent of the requirement is expressed adequately.
After all, nobody would separate into two requirements the recording of an order header from the recording of the detail of order lines. It is obviously not sensible because we recognise that the business needs both parts to be executed as one.
And there's the key question that BAs should always ask - what needs to be achieved when some transaction arrives, or when a business event occurs? (The utility of business events is described in multiple other notes on the website.)