Requirements Flashcards
Requirements
Needs and Constraints that must be satisfied to complete project
technical or functional
typically written for a technical audience
unstructured
who owns requirements?
STAKEHOLDERS decide and own requirements for the project
user stories
informal descriptions of functionality project must provide from perspective of end user
written for non-technical audience
user stories structure
who what why
less detailed than requirements
requirements review issues
lack of detail
changing requirements
inadequate docs
inefficient review process
common pain points:
lack of collaboration
lack of traceability
lack of standardization
lack of sign off
product scope
capabilities of a product
project scope
work performed to deliver a project
scope statement
project objective (goal)
deliverables - specific outputs
in-scope items - what project addresses
out-of-scope items - what project explicitly will not address
constraints - budget, time, etc…
assumptions - items we assume are true
dependencies - external factors
acceptance criteria - conditions that must be met for project completion
risks - what may risk factors of the project
signature and approval - stakeholders
who should be involved in requirements elicitation?
C- Level: Ceos
Middle Management: heads, supervisors
End Users: individuals or groups who will use the completed project
Business Requirements Document
specific needs and goals of business
Functional Requirements Document
specific features product needs to meet the needs of business
System Requirement Specification Document
how the complete system should function
Use Case document
scenarios product will be used with specific actors involved and steps taken
process flow diagrams
flow or steps and tasks in process
workflow diagram
flow of work through an org
user stories
short, simple, perspective of end user
wireframes
quick sketches of user interface
change request logs
tracks records for changes to system
test plans or test case
how a system will work and how it will be tested to ensure it meets requirements
RACI chart
clearly assign roles and tasks to folks
all tasks and decisions to be made, and who is making the decision
when using change sets, what is important to track?
Changes, especially changes that require manual migration.
When you manually migrate a change, you take modifications from one environment and re-create them exactly in another environment
You have to manually migrate a change when that change is not supported by the metadata api
for change sets, how do you know which components are supported in the metadata API?
check the metadata coverage report
why is it important to track changes made during development?
to identify what should go in a change set
why track changes made in production when they are not part of a release in development?
so customizations deployed don’t overwrite anything
