137 lines
3.0 KiB
Markdown
Executable File
137 lines
3.0 KiB
Markdown
Executable File
- Requirements
|
|
- Design
|
|
- Implementation
|
|
- Verification
|
|
- Maintenance
|
|
|
|
No step can be done without it's pre-requisites.
|
|
|
|
# Intro to Agile
|
|
|
|
Plan, Analyse, Design, Build, Test, Deploy
|
|
|
|
This repeats in a given timebox, building on previous iterations.
|
|
|
|
## Scrum Method
|
|
|
|
Product Backlog -> Sprint Backlog -> 2-4 Weeks, with daily Scrum meetings -> Potentially Shippable Product Increment
|
|
|
|
## Requirements
|
|
|
|
- Process of establishing
|
|
- Services that customer requires
|
|
- Constraints under which it operates or is developed
|
|
- Requirements
|
|
- Descriptions of services and constraints
|
|
- Generated during requirements process
|
|
|
|
### Functional Vs Non-Functional Requirements
|
|
|
|
#### Functional
|
|
|
|
- Statements of services system should provide, how system should react to inputs, how system should behave
|
|
- May state what system should not do
|
|
- Describe functionality or system services.
|
|
- Depend on type of software, expected users and type of system where software is used.
|
|
- Functional user requirements may be high-level statements of what system should do.
|
|
- Functional system requirements should describe system services in detail.
|
|
|
|
#### Non-Functional
|
|
|
|
- Constrains on services or functions offered by system such as timing, development process, standards, etc.
|
|
- Often apply to the system as a whole rather than features of services.
|
|
|
|
#### Domain Requirements
|
|
|
|
id1((Some text))
|
|
|
|
- Constraints on the system from domain of operation
|
|
|
|
### Use Case Diagram
|
|
|
|
- Use Cases
|
|
- Tool for modelling requirement gathering
|
|
- Abstraction focused on user interaction
|
|
- System design / internal structure not evaluated.
|
|
- Detailed description of user interaction
|
|
- Use Case Diagrams
|
|
- Comprise actors and use case titles
|
|
- Lines show which actors permitted to execute each use case.
|
|
- Actor: Anyone / Anything with behaviour
|
|
- Use Case: Contract for behaviour of the system
|
|
|
|
#### Car Rental System Example
|
|
|
|
- 
|
|
|
|
# Workshop
|
|
|
|
Identify name and actors
|
|
For each actor, identify and name use cases
|
|
Draw use case diagram
|
|
|
|
## Example 1
|
|
|
|
Actors:
|
|
|
|
- Students
|
|
- Register
|
|
- Transfer
|
|
- Lecturers
|
|
- Upload Marks
|
|
- Administrators
|
|
- Assign Module
|
|
- Ratify Marks
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
std[/Students/] === rg([Registration])
|
|
std === trm([Transfer Module])
|
|
lec[/Lecturers/] === um([Upload Marks])
|
|
adm[/Administrators/] === am([Assign Module])
|
|
adm === rm([Ratify Marks])
|
|
```
|
|
|
|
## Example 2
|
|
|
|
Actors:
|
|
|
|
- Senior Librarians
|
|
- Archiving Holdings
|
|
- Purchasing Holdings
|
|
- Librarians
|
|
- Register Holdings
|
|
- Borrowers
|
|
- Borrow Holdings
|
|
- Return Holdings
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
sl[/Senior Librarian/] === ar([Archiving])
|
|
sl === pc[(Purchasing)]
|
|
lb[/Librarians/] === rgh([Register Holdings])
|
|
bw[/Borrowers/] === bh([Borrow Holdings])
|
|
bw === rth([Return Holdings])
|
|
```
|
|
|
|
## Example 3
|
|
|
|
Actors:
|
|
|
|
- Travelers
|
|
- Cancellations
|
|
- Search
|
|
- Book
|
|
- Reserve
|
|
- Frequent Fliers
|
|
- Cancellations
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
A[/Travellers/] ==== B([Search])
|
|
A ==== C([Book])
|
|
A ==== D([Reserve])
|
|
A ===== E([Cancel])
|
|
F[/Frequent Fliers/] ===== E
|
|
```
|