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).
- 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:
- An ER diagram of the models involved.
- Mockups for every screen of this application. You can use paper or any mockup tool you like.
- 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.
- 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?