I am a Business Analyst/Project Manager hybrid by day and often I have to write use cases for systems I am working on. Simply put, a use case describes a need and then how to go about fulfilling that need. It has structure and uses specific words to indicate what is happening to whom.
An example might be….
As a person, I get hungry regularly, I need to eat to satisfy that hunger as a result I can function well for another period of time.
Here are the key points highlighted: As a person, I get hungry regularly, I need to eat to satisfy that hunger as a result I can function well for another period of time.
who (person), what (eat), result (function well)
There are some awful parts to that sentence that would cause problems if I left it at that. I work in software development with programmers and they would rightly challenge the language in that use case as imprecise.
We would need to define: hungry, regularly, eat, satisfy, function, well and period of time.
hungry : how are we measuring that ? will we always know, can we be hungry for a period of time or does the hunger condition need satisfying immediately or within a specific timeframe.
regularly : how often, what is the priority of this over other tasks for example breathing and sleeping.
…and we could go on with each of these words.
Pseudocode takes that use case and tried to turn it into a set of statements that have conditions and inputs and outputs…just like real code. The aim of the pseudocode is to clearly delineate the scope of the need in system and data terms. This is closer to programming than the use case is and will enable the programmer involved to search out the weaknesses in the idea and where the rigid rules needed to program successfully are missing and need definition.
The sentence above becomes something like this:
Check persons hunger value every 15 minutes, when it is less than 5 then eat a portion (defined in calories, weight and size, suitability for time of day and type from appropriate food table) of food. Recheck hunger value every 30 seconds during the eating process and stop eating when the hunger value gets to 10.
So we have parameters: every 15 minutes, every 30 seconds, the food type/size/quantity and the value of the hunger.
This still isn’t quite enough for the programmer as we haven’t put any constraints on context for example if the person is sleeping they should not be disturbed. Maybe this is just about waking hours or maybe if the time is within 15 minutes of normal waking, the waking process should be started, similarly if the time is within 15 minutes approaching sleeping time then skip this process as it may be difficult to get to sleep if you have just eaten.
Maybe there are time constraints in the table of food on what foods can be consumed at what times of the day. Maybe there are constraints on how many times you can have a particular food in a period of time. These constraints also deserve a sentence each as they stop the programmer doing something that testing shows as waking up the person at 2am and 5am to give them some soup and bread for the fifth time in the last 24 hour period!
Clearly THAT wasn’t the intention of the use case but if we write use cases for everything we can get tangled up in the semantics of the writing and tie ourselves in knots with conditional statements written from the point of view of the person or system. Easier and more effective to do it in the pseudocode.
So in summary, we write the use case so we understand what is wanted by our user/customer and we can reflect that back to them to get their agreement that we understood correctly.
Then we write pseudocode to explain the use case to the programmer/developer in terms they can easily read to apply to the codebase.
This method seems to work far better than the original intention of use cases as part of a unified modelling language process that results in diagrams. A further article here may go into the shortcomings of that approach in business.
Thanks for reading this and I hope it provides you with some food for thought. I would love to hear of your experiences with use cases and/or pseudocode, there is a comments box below for your convenience. All comments will get an answer.