Week 6 - Software Requirements Specification and Documentation

Iterative and incremental development

- The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. - Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. - Incremental development slices the system functionality into increments (portions). In each increment, a slice of functionality is delivered through cross-discipline work, from the requirements to the deployment.

SRS (Purpose)

- To analyse the elicited requirements. - Define what designers/developers have to build. - Verification against the delivered system. - Validating that they are indeed what stakeholders want. - Baseline for evaluating the software. - Support for testing (verification and validation).

Requirements Specification

- Traditional approach using IEEE template -- Upfront and detailed -- Simple plain language requirements statements -- Structured use cases (next week's lecture) - Agile approach (used in this subject) -- Iterative -- User stories: card, conversation, confirmation -- User story map -- User story estimation and prioritisation -- User story or agile card wall

The Team

- Typically 5-9 people - Cross-functional: -- Programmers, testers, user experience designers, etc. - The development team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each sprint (the sprint goal). - Teams are self-organizing -- Ideally, no titles but rarely a possibility - Membership should change only between sprints

User Story

- User stories are short, simple description of a *feature* told from the perspective of the person who desires the new capability, usually a user or customer of the system. - User stories are short descriptions of *functionality-told from the perspective of a user*-that are valuable to either a user of the software or the customer of the software.

User Story (Guidelines)

- Write your stories so that they are easy to understand. - Keep them simple and concise. Avoid using multiple sentences in each user story (one sentence only). - Avoid using conjunctions such as 'and', 'or', 'but', etc. Also avoid using limiting phrases such as 'unless', 'except', 'without', etc. Avoid confusing and ambiguous terms, and use active voice. - Keep user stories short and simple with one functionality only. - User stories should be clear, feasible, and testable and comfortably fit into a sprint. - User stories should have *acceptance criteria*. Acceptance criteria for a user story allow analyst to describe the conditions that have to be fulfilled so that the story is done/completed. The criteria enrich the story, they make it testable, and they ensure that the story can be demoed or released to the users and other stakeholders

User Story (Estimation and Priortisation)

- estimated in terms of time taken to complete/implement a user story by the development team. - prioritised (importance) to be included in a certain release (which user stories should be included in each release)

User Story Map

1. Capture PR | 2. Get Quote | 3. Review Quote | 4. Place Holder Each column contains user stories, organised by priority

Agile SRS

1. Document Management 1.1 Revision History 1.2 Intended Audience 1.3 Reference Documents 1.4 Glossary 2. Introduction 2.1 Document Purpose 2.2 Project Purpose 2.3 Project Scope 2.3.1 In Scope 2.3.2 Out of Scope 2.4 Assumptions 3. Functional Requirements 3.1 User Story Map 3.2 User Stories and Use Cases 3.2.1 Use Case: Name of the Use Case 3.2.2 Use Case: 3.3 Sequence Diagrams 4. Data Requirements 4.1 Class Diagram 4.2 State Transition Diagram 5. Non-functional requirements5.1 User Interface Requirements 5.2 Security Requirements 5.3 Performance Requirements 6. Bibliography 7. Appendices

User Stories (Importance and Prioritisation)

- Common methods to prioritise (importance) each user story include: -- MoSCoW method (Must, Should, Could, Would/Won't) http://en.wikipedia.org/wiki/MoSCoW_method -- Weighted Shortest Job First (WSJF) http://agile102.blogspot.com.au/2013/01/weighted-shortest-job-first-bit-of-safe.html http://www.scaledagileframework.com/wsjf/ -- High, Medium, Low (HML) - (method used in this subject)

ScrumMaster

- Is a Facilitator. - Represents management to the project. - Responsible for enacting Scrum values and practices. - Removes impediments. - Ensure that the team is fully functional and productive. - Enables close cooperation across all roles and functions. - Shields the team from external interferences.

Epic

- It feature is a large user story. It is a big, sketchy, coarse-grained story. - Because it is generally too large for an agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on. - It will later be decomposed into smaller stories that fit more readily into a single iteration. This is done in the Backlog Refinement Meeting. Watch "Backlog Refinement Meeting" video on UTS Online

User Story (purpose)

- It serves as placeholders for conversations about the users' detailed needs. It is a starting point of *conversation and confirmation* between the analyst and stakeholders (e.g. product owner or process owner). - Based on the User Story, you have further conversations with the user or proxy user and identify the additional details. The Product Owner has further conversations with developers. - Is planned for project releases and iterations - Is written on a *story card, index cards or sticky notes* stored in a shoe box, and arranged on walls or tables to *facilitate planning* (releases and iterations) and discussion - they strongly shift the focus from *writing about features to discussing them*. These *discussions are more important* than whatever text is written in user stories.

Software Requirements Specification

It is a document that provides the detailed description of what the system should do. - structured document setting out the system services and capabilities in detail. - sometimes called as functional specification. - often serves as a contract between the client and vendor.

Product Owner

- *Represents the stakeholders* and is the voice of the customer and is accountable for ensuring that the team delivers value to the business. - Writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog. - Defines the features of the product. - Decides on release date and content. - Responsible for the profitability of the product (ROI). - *Prioritizes features* according to market value in the Product Backlog Items. - Adjusts features and priority every iteration, as needed. - Accepts or rejects work results

User Stories (Importance/Prioritisation of user stories)

- *Requirements prioritisation* is used in software development for determining which candidate requirements of a software product should be included in a certain release. - Requirements (user stories) are also prioritized to minimise risk during development so that the *most important or high-risk requirements (user stories) are implemented first.* - Remember, the Product Owner prioritises the user stories and decides on which user stories will be included in a certain release in consultation with the development team. Please watch "Backlog Refinement Meeting" video available on UTS Online

SRS (Role and Purpose)

- A legal document. A contractual device for judging the completion of the specified job. - Functional device for improving the understanding of the customer's real needs (both in business and technical terms). - So, it is a communication device that conveys an understanding between different teams in the software development process. - Used as basis for a user manual. - Statement of commitment. Validation device for validating the requirements stated in a formal manner. - Used to develop test cases.

Sprints

- A sprint (or iteration) is the basic unit of development in Scrum. Scrum projects make progress in a series of "sprints". -- Analogous to Extreme Programming iterations - Typical duration is 2-4 weeks or a calendar month at most - A constant duration leads to a better rhythm. - Product is designed, coded, and tested during the sprint. - Each sprint starts with a sprint planning event, the aim of which is to define a sprint backlog, where the work for the sprint is identified and an estimated commitment for the sprint goal is made. - Each sprint ends with a sprint review and a sprint retrospective, where the progress is reviewed and lessons for the next sprint are identified.

Agile Card Wall

Backlog | Planned | Ready | In progress | QA | Done Each column contains user stories

User Stories (Estimation of effort)

Common methods to estimate the time/effort to complete each user story include: - T-shirt sizes (S, M, L, XL and XXL) - Powers of 2 (1, 2, 4, 8) - The Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.) - Story Point (1 to 10) - (method used in this subject)

Scrum Framework

Roles: - Product Owner - ScrumMaster - Team Ceremonies: - Sprint Planning - Sprint Review - Sprint Retrospective - Daily scrum meeting Artifacts: - Product backlog - Sprint Backlog - Burndown charts