Requirements Activities
Your requirements are one of the key pieces of documentation that will create a shared understanding of what needs to be built, and the problem being solved. These activities will help you frame your requirements.
“The hardest single part of building a software system is deciding precisely what to build.” — Fred Brooks
OSU Advantage Accelerator’s Iterate Program
Section titled “OSU Advantage Accelerator’s Iterate Program”Join the Iterate program of the OSU Advantage Accelerator to develop your project idea. This four-workshop program is offered once per school term to inform and prepare you on essential aspects of starting a successful business venture.
Check some of the Accelerator’s other resources.
For this activity, participate in all four workshops as a team, and write a report that includes all artifacts you produced during the program.
Lean Canvas
Section titled “Lean Canvas”Complete the Lean Canvas with as much detail as you can.
Problem
List the top 1-3 problems your product or project aims to solve for your target customers.
Solution
Describe the key features or approaches that address each problem identified.
Unique Value Proposition
Summarize what makes your solution unique and why customers should choose it over alternatives.
Unfair Advantage
Identify something that cannot be easily copied or bought by competitors (e.g., insider information, unique team, patents).
Customer Segment
Define your target customers and users. Who are you creating value for?
Existing Alternatives
List current solutions or competitors your target customers use to solve these problems.
Key Metrics
Identify the key activities or numbers you will measure to track success.
High Level Concept
Describe your idea in a simple, memorable way (e.g., “YouTube for teachers”).
Channels
Explain how you will reach your customers (e.g., social media, direct sales, partnerships).
Early Adopters
Describe the characteristics of your ideal first users or customers.
Cost Structure
List the main costs required to operate your solution (e.g., development, marketing, infrastructure).
Revenue Streams
Explain how your project or product will generate revenue or value.
Something unclear? Look up explanations and some examples online.
Submit your Canvas with any additional information that might be useful to understand it. Consider going more in-depth by detailing the sections of the canvas in a document.
Hypothesis Testing
Section titled “Hypothesis Testing”Most of the information in your Lean Canvas is hypotheses. Identify five of the riskiest hypotheses in your plan’s customer segments, problems, and competition.
For each hypothesis:
- Construct a fail/pass test.
- Interview at least five members of the relevant customer segment (enough to suggest the hypothesis holds or not) and produce anonymized data about the customer interviewed.
- Provide a clear and professional summary of the results of the test (insights, etc.)
- If your initial hypothesis is false, provide a pivot hypothesis.
If working on this activity as a team, have each person focus on a different set of hypotheses.
🔥 User Story Mapping (Use Cases and Scenarios)
Section titled “🔥 User Story Mapping (Use Cases and Scenarios)”After reading this User Story Mapping article from the Nielsen Norman Group, create a comprehensive user story map for your project, and include an initial written set of epics and user stories.
If working on this activity as a team, have each person focus on a different set of stories. Indicate whether each user story is high or low level.
INVEST Criteria
Section titled “INVEST Criteria”When writing user stories, ensure they meet the INVEST criteria:
- Independent: Stories should be self-contained, allowing them to be developed and delivered independently.
- Negotiable: Stories are not contracts; they should be flexible and open to discussion.
- Valuable: Each story should deliver value to the end-user or customer.
- Estimable: Stories should be clear enough to estimate the effort/time required for implementation.
- Small: Stories should be small enough to be completed within a single iteration or sprint.
- Testable: There should be clear acceptance criteria to determine when a story is complete and meets expectations.
User’s Emotional Objectives
Section titled “User’s Emotional Objectives”We often focus on users’ functional goals, but emotional objectives often play a bigger role in decision-making.
- What emotions is the user seeking when using the software?
- How does the software impact their relationships or self-perception?
For example, a peer resume critique website might meet the functional goal of reviewing resumes, but the emotional objective is to ease job search anxiety. Similarly, in the auto industry, messaging focuses on emotions: a car might make someone feel wealthy or adventurous. How can your software address these emotional needs?
Submit an analysis of your project from the perspective of the user emotional objectives, explain which user segment or audience you are targeting. Share it with your team.
Domain Model
Section titled “Domain Model”Create a Domain Model that represents the key entities and relationships within your project’s problem space.
- Identify Entities: List the main objects or concepts relevant to the domain (e.g., users, products, orders).
- Define Attributes: For each entity, specify key characteristics or properties (e.g., name, ID, status).
- Establish Relationships: Map how entities interact with or relate to one another (e.g., “User places Order”).
- Draw the Model: Use diagrams (UML or similar) to visualize the domain.
Submit a diagram along with a brief explanation of the entities and their relationships.
User Manual
Section titled “User Manual”Develop a preliminary user manual that outlines how end-users will interact with your software.
- Identify Key Features: List the core features users need to know about.
- User Instructions: Provide step-by-step guides on how to use the system, including screen navigation and input details.
- Common Issues and Solutions: Include troubleshooting tips for common problems users may face.
- Interface Overview: Provide a brief description of the user interface.
Submit a draft of the user manual with clear instructions on using the main features of your system.
If working on this activity as a team, have each person focus on a different subset of the manual.
Define Your Research Questions
Section titled “Define Your Research Questions”After identifying gaps or unique insights in existing research, write your research question(s). Explain whether your research will be primary (i.e., collecting original data) or secondary (i.e., analyzing existing data), and what you’ll need to get started.
Collect Data Sources
Section titled “Collect Data Sources”If you are conducting secondary research, i.e., analyzing existing data or literature collected by others, list all the relevant data sources needed to answer your research questions.
Specifically, list the data sources, who created them, when, their format/schema, how to access or download them, and what their purpose is in the context of your research.
Define The Data To Collect
Section titled “Define The Data To Collect”If you are conducting primary research, i.e., collecting original data, define what type of data (i.e., qualitative, quantitative, mixed) you need to collect, and what methodologies you will use (i.e., surveys/questionnaires, interviews or focus groups, experiments or observations). Explain the purpose of each category of data collected with regard to your research question(s).
Low or Medium-Fidelity Prototype
Section titled “Low or Medium-Fidelity Prototype”Create a low or medium-fidelity prototype to clarify and validate the project’s functional requirements.
- Define Key Features: Identify the main features to be included in the prototype.
- Create the Prototype: Use tools like Figma, Adobe XD, or similar to build a clickable prototype that demonstrates key user flows.
- Validate Requirements: Review the prototype with stakeholders or users to ensure it meets functional requirements.
Check this fantastic blog post about a SoundCloud iOS redesign.
Submit the prototype link and a brief reflection on how it clarified or influenced the project’s requirements.
Jobs to Be Done Theory
Section titled “Jobs to Be Done Theory”The Jobs to Be Done (JTBD) Theory is a framework for understanding the underlying tasks or “jobs” users are trying to accomplish with your product. Instead of focusing solely on features, JTBD helps you uncover the real motivations and desired outcomes of your users.
- Identify a primary user segment for your project.
- Interview or observe users to understand what “job” they are hiring your product to do.
- Write at least two JTBD statements in the format:
“When [situation], I want to [motivation], so I can [expected outcome] without [pain point].”
Submit your JTBD statements and a brief explanation of how these insights will influence your requirements or design decisions.
Current vs. Ideal Workflow
Section titled “Current vs. Ideal Workflow”Analyzing the current workflow versus the ideal workflow helps you identify pain points, inefficiencies, and opportunities for improvement in your project’s domain.
- Document the current workflow for your target users as a step-by-step process.
- Identify bottlenecks, frustrations, or areas for improvement.
- Describe or diagram the ideal workflow that your solution aims to enable.
Provide a comparison of the current and ideal workflows (as text or diagrams), highlighting key differences and how your project addresses the gaps.
Is / Is-Not
Section titled “Is / Is-Not”The Is / Is-Not analysis helps clarify the scope and boundaries of your project by explicitly stating what the project is and is not.
- Create a table or list with two columns: “Is” and “Is-Not”.
- In the “Is” column, list characteristics, features, or goals that are in scope for your project.
- In the “Is-Not” column, list items that are out of scope or explicitly excluded.
Submit your Is / Is-Not table or list, and include a short explanation of how this analysis will help keep your project focused and aligned.