Class#4 Requirements Documentation PDF
Document Details
Uploaded by Deleted User
Tags
Summary
This document details software requirements documentation, encompassing functional and non-functional aspects. It includes explanations, examples, and guidelines for creating user stories and acceptance criteria. The content is useful for software development teams.
Full Transcript
CLASS#4 - REQUIREMENTS DOCUMENTATION WORKING SOFTWARE OVER DOCUMENTATION Does this mean no documentation at all? – No? then why do we still document? WHY DOCUMENT? Why Good Documenation Matter: Ensures understanding across teams, avoids scope creep, and helps developers work together. Princ...
CLASS#4 - REQUIREMENTS DOCUMENTATION WORKING SOFTWARE OVER DOCUMENTATION Does this mean no documentation at all? – No? then why do we still document? WHY DOCUMENT? Why Good Documenation Matter: Ensures understanding across teams, avoids scope creep, and helps developers work together. Principles of Requirements Documentation: Clear and Specific: Ambiguity leads to misinterpretation. Testable and Measurable: Especially for non-functional requirements. Consistent and Concise: Information should be precise and to the point. complete, consistent, precise, and concise. SRS DOCUMENT – (SOFTWARE REQUIREMENTS SPECIFICATIONS) FUNCTIONAL VS NON-FUNCTIONAL Non-Functional Criteria Functional Requirements Requirements Specific functions and Quality and performance Focus behaviors characteristics Performance, security, Functional testing (Does it Testable By usability testing (Does it work as specified?) meet quality?) Login functionality, order System speed, security Examples processing, search standards, uptime, capability scalability Impacts user satisfaction, Directly impacts user Dependency experience, and system interaction longevity EXAMPLE Non-Functional Feature Functional Requirement Requirement The system must allow The login page should Login System users to log in with a load within 1 second. username/password. Users can search for Search results should Product Search products by name, load within 2 seconds category, or price. after user input. The system must process The payment process Payment Processing payments through a should be secure and payment gateway. meet PCI compliance. The system should Users should be able to update the order status Order Tracking track their order status. within 5 minutes of change. EXAMPLE SRS DOCUMENT EXAMPLE USE CASE DIAGRAM USE CASES The typical structure of a use case includes several components: 1. Actors: These can be individuals or systems interacting with the system described. 2. Description: A summary of the main goal or objective. 3. Preconditions: These define the prerequisites before the use case can start. 4. Basic flow: A step-by-step description of the critical interactions and actions between the actors and the system. 5. Alternative flows: Descriptions of alternative paths or variations from the main flow that may happen. 6. Dependencies: These are related use cases, systems, or modules needed for successful use case execution. USER STORY A User Story is a note that captures what a user does or needs to do as part of his work. The details of a User Story may not be documented to the same extreme as a Use Case. User Stories deliberately leave out a lot of important details. User Stories are meant to elicit conversations by asking questions during scrum meetings. [Self Organized Teams] HOW TO WRITE A USER STORY Description: “As a [persona], I [want to], [so that].” USER STORY 3C S Card (fits on a post it) Conversation (with dev team) Confirmation (Acceptance Criteria) ACCEPTANCE CRITERIA Acceptance criteria is an important component of every user story that an agile team works on. It clearly defines the scope, desired outcomes of, and testing criteria for pieces of functionality that the delivery team is working on. The process of creating and agreeing on acceptance criteria itself is also an invaluable communication opportunity between developers and product. Acceptance Criteria: - List of criteria - Given, When, Then EXAMPLE (Given) some context (When) some action is carried out (Then) a particular set of observable consequences should obtain An example: Given my bank account is in credit, and I made no withdrawals recently, When I attempt to withdraw an amount less than my card’s limit, Then the withdrawal should be complete without errors or warnings INVEST MARTHA'S STORY SHE WANTS TO GO BUY PIZZA WITH HER FRIENDS BUT SHE DOESN'T HAVE CASH.