Class 4 - Requirements Documentation

Class#4 - Requirements Documentation

• This class focuses on the requirements for documentation of software.
• The question presented is whether software needs documentation, and why it is important to maintain documentation for software.

Working Software Over Documentation

• The question explored is whether working software eliminates the need for documentation.
• The answer is no, as documentation helps various teams understand the software, avoids scope creep, and facilitates collaboration among developers.

Why Document?

• Good documentation ensures understanding across teams.
• It helps avoid scope creep and facilitates collaborative efforts among developers.
• Principles of Requirements Documentation:
  • Clear and specific requirements to avoid misinterpretations.
  • Testable and measurable requirements, especially for non-functional aspects.
  • Consistent and concise information for clarity and precision.
  • Requirements should be complete, consistent, precise, and concise.

SRS Document (Software Requirements Specifications) Functional vs Non-Functional

• SRS documents outline software requirements.
• Functional requirements describe specific functions and behaviors of the software.
• Non-functional requirements describe quality and performance characteristics, such as performance, security, usability, testing, system speed, and security standards, uptime, scalability.

Example

• Functional and non-functional requirements are explained for Login System, Product Search, Payment Processing, and Order Tracking features.
• Examples provided include login speed, search result loading time, security requirements, and order update speed.

Example SRS Document

• This provides a template for a detailed software requirements specification (SRS).

Example Use Case Diagram

• A diagram illustrating the actors and their interactions with the online ordering system.
• Includes actors like Prospective Customer, Customer, Procurement Manager, and Service Representative.
• The system includes actions such as create profile, expedite order, view menu, place order, change order, view reports, update prices, and get ingredient requests.
• Links show actions between different actors and the system.

Use Cases

• Components of a use case include actors, description, preconditions, basic flow, alternative flows, and dependencies.
• Actors are individuals or systems interacting with the system.
• Description summarizes the main goal or objective.
• Preconditions define prerequisites before a use case can start.
• Basic flow describes critical interactions and actions between actors and the system.
• Alternative flows detail variations or alternative paths.
• Dependencies identify related use cases, systems, or modules.

User Story

• A user story is a high-level description of a user's need or goal.
• User stories capture what a user does or needs to do as part of their work.
• Details might not be as extensive as in a use case, focusing on eliciting conversations through questions during scrum meetings.

How to Write a User Story

• Structure: As a [persona], I [want to], so that [benefit].
• Acceptance criteria define conditions of satisfaction to verify requirements.

User Story 3Cs

• Components include card (on a post-it note), conversation (with the development team), and confirmation (of acceptance criteria).

Acceptance Criteria

• Acceptance criteria clearly define the scope, desired outcomes, and testing criteria for software features.
• This is crucial for communication between product owners and developers.
• The list of acceptance criteria often uses "Given, When, Then" approach to describe conditions/situations.

Example

• A sample "Given, When, Then" scenario is provided, illustrating how to define observable consequences based on given conditions and actions.

INVEST

• Criteria for evaluating user stories, including Independent, Negotiable, Valuable, Estimable, Small, and Testable.

Story Slicing Phases

• Two phases in story slicing are discussed
  • Phase 1: Focus on the user and goal
  • Phase 2: Gather more details on implementation

Story Mapping With Personas

• Story mapping with personas is a technique for organizing user stories into a visual representation of flow and user journeys.

Martha's Story

• User story about a user who wants to buy pizza with friends but doesn't have cash.

Visual Story Slicing

• Detailed illustrations and diagrams describe scenarios for a user's actions
• For example, using card payment at ATM

Indicators of Poor User Stories

• Recognizing warning signs of poorly defined user stories to avoid difficulties during development
• Examples include: significant questions during sprint planning, rework, missing sprint commitments, and surprising product owners.

Further Considerations

• Emphasis on avoiding distractions by focusing initially on the core functionality rather than nonfunctional or supportive details.