Week 2 Flashcards
What is a software requirement
The business functions that users will be able to perform and the experience their will have have
includes how the system will manage resources or protect user data
Questions to ask when understanding requirements
What matters?
Features
Security (authentication and authorisation)
Data Sovereignty ( where its stored and the country’s laws that govern it)
Availability and reliability
User personas
What is Requirements engineering
Understanding what matters
3 types of requirements
Functional
non functional
UI
Examples of non functional
usability
security
performance
scalability
reliability and availability
3 artefacts for UI req gathering
Wireframes - sketch
mockups - formal with colours and shit
prototype - interactive demo
3 steps for requirements engineering
Requirements gathering
requirements analysis
requirements speficication
what are use cases
list of actions or event steps typically defining the interactions between a role and a system to achieve a goal
shown in diagrams with
Ovals = use cases
Stick figures = actors
Boxes = system boundary
Lines = associations
explain requirements gathering
help the customer define what is required, what the system needs to do and how it will be used
explain requirements analysis
refining and modifying the gathered requirements ( more in depth)
back and forth between dev and client
This involves evaluating feasibility and realism
helping anticipate future changes in policy so code can be future proof
explain requirements specification
Involves documenting requirements
requirements should be:
traceable
actionable
testable
related to business needs ( user stories)
what 3 questions must be answered in a user story
who - what - why
What is an acceptance test and 2 types of it
it specifies for a given situation or context defined by system input, what the correct output or behaviour should be.
User acceptance test - focused on user experience
Operational acceptance test - checks readiness of the system
why and who does acceptance testing
WHY
It is a way of assessing if the requirements have been met
However cannot guarantee 100% but can cover majority and vital checks. With a systematic approach you increase the degree of coverage
WHO
It can be done by client and end users
How do develop acceptance tests
Taking user stories with the who-what-why and then applying the GIVEN-WHEN-THEN
given something, when i do something, then something should happen
on top of that can be some non functional tests like should happen in a certain time frame.
how do we prioritise requirements
identify what’s urgent and what’s important
both = do
only important = plant
only urgent = delegate
neither = mize
how do we know how long we should take
we use SIZE POINTS and assign it to user stories to help identify which tasks require the most effort
velocity or burn rate is the average amount of points finished in a day
project duration = total / velocity
