Why New Products?

  • Better meet need

  • Meet unmet need

  • Offer new features and functions

  • Hard but necessary to verify market for software product

Features, Ilities, Design Constraints

  • Feature can be captured by "story card": for example "As an author I need a way to organize the text of my book into chapters and sections."

  • "-ility" is something that needs to be true of the software but isn't really a feature: for example "every software transaction must complete within 60 seconds"

  • Design constraint is a requirement that exists for reasons outside the software product: for example "The software must be written in UCSD Pascal."

Personas

  • Software is always for people

  • Making "representative" people up helps in understanding what software needs to be / do

  • Be a fiction writer — give names and humanizing details, for example: "'Lando' (gamer tag) is a 14-year-old male. He lives with his Mom in a suburb of Portland. He mostly plays multiplayer FPS and TPS games, especially Halo and Counterstrike. He uses Discord for in-game voice and text chat."

  • Maybe five-ish persona depending on product scope? Be sure to cover all major roles that might interact

  • Validate your personas with domain experts

Scenarios

  • Detailed stories about using the software, for example "Lando sits down at his gaming desktop and logs into the game using his Steam account. He starts to create a new character, selecting female gender and combat infantry class, and starts to fill out cosmetics. Lando's mother calls dinner — Lando leaves the screen open and leaves the room to eat. While he is out, there is a momentary power failure. When Lando returns he reboots his computer, logs back in, and proceeds to complete character creation by selecting a starting zone."

  • Detail helps catch missing stuff, and gives basis for organization

  • Again, be a fiction writer, but validate your secenarios with domain experts

  • Should be scenarios for all personas; should be scenarios that cover most normal use

User Stories

  • Story cards contain actual requirements, for example "As a player I want to create a customized character"

  • Developed from scenarios, personas, product vision

  • "Epic" is story that is too big to be directly implementable: include, but then break up into multiple story cards. For example, above might be "As a player, I want to select my character's gender", "As a player, I want to select my character's class", etc…

  • User stories should be directly actionable as code

Reqs Development Tips

  • Ruthlessly eliminate anything not absolutely necessary (can always add back after release)

  • Update/add scenarios to reflect changing vision and requirements

  • Don't forget the -ilities!

  • Avoid design constraints as much as possible, as they can really limit solution space

Last modified: Sunday, 18 October 2020, 9:59 PM