Flowcharts and Pseudo-code work really well in certain situations, like when you have a defined task that needs to be completed, and/or your program follows a simple logical flow.
However, in today’s modern computer application, users will perform things out of order because they can with a modern graphical user interface (GUI). As a developer, I have little control over my user’s actions.
Think about a common application like Microsoft Word. Will the user type, print, or copy/paste next? Will the move the cursor with a keyboard, or mouse? Will they insert an image, chart, or delete a section? I as a developer will never be able to determine it.
So instead, we’ll use user stories when we plan an application. A project manager, or team, will go about creating a basic story. It might read something like:
A user should be able to click on a location with a mouse, and then insert an image at that location in the Word document.
or
A user should be able to copy a selection of text to the clipboard for use in the application later, or a different application.
This may seem like pseudo-code, but notice how these are very vague? Pseudo-code should be never be this vague!
User stories are designed to give a “30,000” foot overview of features. A development team will then take these, and break them down into smaller steps though pseudo-code, or a flowchart, so they can verify what will be needed to be done, and then write the code.
User stories are often seen in agile programming. A lot of companies have moved to agile programming for their programming process, so there is a strong chance you will see user stories in your career if you choose to go into programming.
However, while they work well for large applications, making sure the user gets all the features they need, they tend to be overkill for a programming class, and so we won’t use them as much.
An Introduction to User Stories was originally found on Access 2 Learn
