Posted almost 5 years ago. Visible to the public.

Requirements analysis and minimum viable UIs [3d]

Many of our clients can't or don't want to design their user interfaces. In the absence of a good UI design, you should always be able to come up with a default. Since the user interface makes up 70% of a typical web application, this is closely related to requirements analysis and cost estimation.


Talk with your mentor about the following topics:

  • Extracting nouns from requirements prose
  • Drawing ER diagrams and minimizing boxes
  • Why nouns from the client domain do not always map to Ruby models 1:1. E.g. only if a "address book contact" and a "user" are both human beings, it's rarely practical to have them share a model or inheritance hierarchy.
  • Try to model everything as CRUD (regardless of whether a model is backed by a database or not).
  • How to navigate between indexes, show views, forms
  • Where to place actions related to a collection of records
  • Where to place actions related to a single record
  • How to deal with roles that have different access privileges on a shared set of records
  • Why you always want an admin to be able to override all the rules from the requirements and edit records freely.
  • How mockups are a great way to flush out misunderstandings and wrong expectations between you and your client.

Exercise: Lemonade Empire

Here is some requirements prose for an imaginary client application.

  • Your client runs an empire of 75 lemonade stands.
  • Each lemonade stand has a name and address.
  • Each lemonade stand is operated by one or more lemonade salespeople.
  • At one point in time, a salesperson will only operate one stand. However, salespeople may change their stand.
  • Every week, a lemonade stand needs to report the number of lemonades sold this week. Every salesperson can hand in this report for the entire stand.
  • Each salesman has their own commission rate (cents per lemonade sold).
  • There should be a search functionality to quickly find a lemonade stand or salesperson.
  • Once a month, the client should be able to see a report of
    • the sales of each lemonade stand
    • the total commission she needs to pay to each salesperson.
  • For the purpose of commission calculation, the number of lemonades sold is distributed evenly among all the salespeople that work for a particular stand.

Please prepare the following deliverables:

  1. An ER diagram of the models involved.
  2. Mockups for every screen of this application. You can use paper or any mockup tool you like.
  3. User stories in Pivotal Tracker. Read Project management best practices: Stories on how we write stories.

After each step, have your mentor review your deliverable before you proceed.
We will practice cost estimation in a later lesson.

Some hints

  • Try to not create a UI that has edge cases
  • Do you store or live-generate the monthly report?
    • What are the pros and cons?
    • What happens if lemonade stand report hand-in happens late?
    • What happens if the commission of a sales person changes in the middle of the year? Does this change past monthly reports? How can we fix this?

Owner of this card:

Henning Koch
Last edit:
2 months ago
by Henning Koch
Posted by Henning Koch to makandra Curriculum
This website uses short-lived cookies to improve usability.
Accept or learn more