Scrum part 3

User Stories:

- Requirement analysis is an imp part of software development - if its not done right, it can create a lot of issues later
- User stories help get the high level picture of requirements
- It is mostly prepared by the product owner
- Its a living document like the product backlog - that means it keeps evolving throughout the length of the project

User story description:

As a [user role] I want to [goal] so i can [reason/benefit]

Eg: As a registred user I want to log in so I can access subscriber-only content

But then someone also needs to define what a successful registration is so that the above user story can be tested for its validity and completion - that is acceptance criteria
- Each user story has an acceptance criteria

User story characteristics - 2

- Estimable - User stories need to be possible to estimate. They need to provide enough info to estimate, without being too detailed

- Small - they should be small. Not too small or too big. They should be detailed enough for the team to start work from. Further details can be established and clarified at the time of development

- Testable - they need to be worded in a way that is testable. ie: Not too subject and to provide clear details of how they user story should be tested

- User stories should be independent - It is best to avoid dependency between stories because they lead to difficulty while prioritising and planning

- User stories are negotiable - stories do not include all details - too many details give the impression of false precision or completeness - that there's no need to talk further
- They need some flexibility so that we can adjust how much of the story get implemented

Which users should you target while writing user stories?

- Broaden the scope instead of looking at one user
- Allow user to vary by:
* What they use the software for
* How they user the software
* Background
* Familiarity with the software /computers

- Used extensively in usage-centrered design
- Definition:
A user role is a collection of defining attributes that characterise a population of users and their intended interactions with the system

Quality and metrics:

CMMI - Capability maturity model is a set of rules and recommendations which should lead to improvements within and organisation

- It puts best practices used in software development and service management
- CMMI may also be thought as a framework to recognise and improve processes within an organisation.
- Because of its abstraction it can be for all kinds of manufacturers
- CMMI levels is a set of steps which each organisation can obtain in order to increase it value on the market. It requires a lot of involvement and effort to get to level 5

Quality assurance:

- Agile or no Agile, quality is important - only arrogant and novice organisation ignore equality assurance.
- It fits in the project planning, monitoring and control phase of the project lifecycle

What is quality?
- Super or non-inferior
- of high standard
Why is quality a cause for concern?
- Quality supports dependability
- Dependability supports speed
- Speed supports flexibility
- Flexibility supports cost

Software quality assurance:

is the function of software quality that assures that the
- standards
- procedures
- processes
are appropriate for the project and have been correctly implemented

What are standards?

Established criteria for product.
They specify details for - documentation, design and coding

Types: Industry Standard
- International Organisation for Standardisation (ISO)
- Institute of Electrical and Electronics Engineers (IEEE)
-US Department of Defence (DoD

What are procedures?

-Established criteria for development and control process
- Explicit steps to be followed in carrying out a process
- All processes have well documented procedures