Link Search Menu Expand Document

Intro

Here are notes on lectures from Innopolis by Yegor Bugayenko

L2 - Requirements

Use cases

#important

Use case is a structured description of usage scenarios.

Every flow entry should start with an actor followed by it’s action. Use case should not contain ambigous information. This means no will/must/would-be-great-if/etc. Only who doing what.

Example

Blue highlight - Actor
Orange hightlight - Action

Use case: Make a QR Code
Primary Actor: User
Basic flow:
1. The User enters the URL into the HTML box.
2. The System creates a PNG image of a QR code. 
3. The User downloads image through HTTP. 

Extensions:
	1a. The User enters broken URL.
		1. The System shows an error modal dialog box.
		2. The User confirms.
	3a. The User cancels downloading.
		1. The System stops sending data over HTTP.

FPA - Function Point Analysis

[Optional]

COSMIC is the moderd version: ISO/IEC 14143

The method breaks down the requirements into cominations of the four data movement types: Entry (E), Exit (X), Read (R), Write (W)

Function points are used to estimate.

Traceability Matrix

[Optional]

Shows relationship between tests and requirements. Shows where to look when something changes/breaks. What parts of the system you need to update when you update something.

Verification and Validation

#important

Verification - do we do it right? Assuring that 2 + 2 = 4

Validation - do we still do what we need to do?

First should be done always with automated (and maybe manual) tests. Latter should be done as frequent as possible when working with customer.

Non-Functional Requirements

#important

NFRs should be as exact as possible. Can not be measured = can not be achieved.

Quality Attributes

Availability: $A = \frac{E_{up}}{E_{down}+E_{up}}$, $E$ =time

Capacity: Clicks Per Second (CPS), Requests Per Second (RPS)

Recovery: Recovery Time Objective (RTO)

Maintainability: Mean Time To Repair (MTTR)

Example

Bad NFR:

The software should be fast.

Good NFR:

Being installed on a test server (see Annex A), the software must respond in less than 20mss on any request from UC1-UC7.

L3 - Rational Unified Process vs. Agile

Qualities of Good Design

  • It must be simple
  • It must not repeat itself
  • It must be modular