355 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.

Learn

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. although an "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).
  • If you're not familiar with the pattern, read or re-read "New rules for Rails" from Growing Rails Applications in Practice (in our library)
• 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.
   • You can use any tool, for example this one Show archive.org snapshot
2. Mockups for the key screens of this application.
   • You can use paper or any mockup tool you like.
   • We recommend using Balsamiq Show archive.org snapshot . Ask your mentor for an invite.
3. User stories in Linear for the following features:
   • CRUD for stands
   • Everything related to viewing and editing weekly reports
   • Read Project management best practices: Issues on how we write user stories. Note that in practice we would do the estimation and wait for customer feedback before creating user 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
• When clarifying a requirement with your customer (here: your mentor), always present the customer with multiple options and explain their effect on complexity and implementation effort.
• 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?