Class 1 - Requirements Flashcards
Requirement
A specific description of your client’s needs
What are the 5 different requirement activities that happen when creating a product for a client?
- Eliciting
- Expressing
- Prioritizing
- Analyzing
- Managing
Want
A functionality or feature that a client would like the product to have, which may add value, but is not necessarily core to the product itself
Need
A core functionality that the product must have in order to fulfill the product’s purpose
Eliciting Requirements
The process of determining what a client needs and wants. It is an in-depth discussion and collaboration between client(s) and the development team
Expressing Requirements
Framing the requirements identified through discussion in a way that allows a product to be built. This is where use cases, user stories, and story maps are created
Use Cases
A usage scenario for a piece of software
User Story
Written description of what a user wants to achieve with a system
Prioritizing Requirements
Prioritizing client needs to ensure the most important needs will be completed. MoSCoW is often used to prioritize requirements
MoSCoW
Must Have
Should Have
Could Have
Would like but won’t get
Analyzing Requirements
Weighing what is possible given scope, schedule, and budget
What are the most important types of requirements?
- User requirements
- Functional requirements
- Non-functional requirements
User Requirements
- Use cases
- User stories
- Story maps
Non-functional Requirements
Quality Requirements. Examples include:
- Accuracy
- Dependability
- Security
- Usability
- Efficiency
- Performance
- Maintainability
Product Vision
The purpose and value of a product to the client. Includes the needs a project solves.
True or False: Changes to a project can change the product vision
False. A project should never move away from the client’s vision. However, it is possible that a project may not fulfill the entire vision (only part of it)
Scope
What a project can realistically achieve
User Story Format
As a who, I want to what, so that why.
E.g. As a customer, I want to be able to identify dietary restrictions, so that I know I can eat the food I order
Scope Creep
Happens when the scope of a project grows as the result of an increase or change in requirements
How can you determine if a user story is good?
Recall INVEST. User stories should be:
- Independent
- Negotiable
- Valuable
- Estimatable
- Small
- Testable
Independent (INVEST)
A requirement can exist outside of other user stories and still be meaningful
Negotiable (INVEST)
User stories should be general enough for the development team and client to work around their implementation. They should not focus on specific technical details
Valuable (INVEST)
User stories should bring value to the client
Estimatable (INVEST)
It should be possible to estimate how much time it would take to design and implement the requirement in the user story
Small (INVEST)
A user story should be small because it is meant to be developed in a short time period
Testable (INVEST)
User stories should be verifiable against a set of criteria in order to determine if it is done. This is often accomplished using acceptance tests
Epic User Story
User stories with descriptions that are too vague or broad. These user stories can be difficult to estimate
Cone of uncertainty
The time estimates to develop a user story become less accurate the further into the future the feature is intended to be developed
How can epic user stories be avoided?
Provide just enough information to implement a feature, but not the implementation details
Acceptance Tests
Basic criteria to determine if a user story is fully implemented. Written from the client’s point of view
Agile Flying Fingers
An exercise used in project planning to determine how many story points to assign to a user story. Each team member holds up the number of fingers corresponding to the number of story points they think a user story should have
Story Points
How long it will take to finish a piece of work in relation to other pieces of work.
True or False: Story points can be represented by number of hours to complete a task
False. Story points are how long a task will take relative to other tasks. They estimate effort rather than time commitment.
Product Backlog
A set or list of software features that the software product manager and development team plan to develop for a product over the course of a project
Wireframes (Mock-ups)
A basic visual representation of a product that shows where buttons, text fields, and images are placed. UI design and colour palettes are not part of a wireframe
