# 1531 2020t3 Week 4

## QA

### Group 1

Review 1
- No commenting
- Vague variable names - X could refer to anything.
- Very lengthy lines of code

Review 2
- Easier to read, more compacted code through the use of booleans to indicate the state.
- Includes commenting
- Uses boolean values
- More pythonic

### Group 2
Review 1:
Pros:
- Readable code
- Flat code

Cons:
- Overcomplicated statements:
- Could use boolean values as if statement conditions
- No header comment
- No newline character at the end

Review 2:
Pros:
- Uses lists to store the values of horrible_pw
- Uses boolean values

Cons:
- Over deep nesting
- Could use functions to negate overdeep nesting
- Complicated logic
- No newline character at the end

### Group 3
* Review_1:
* Code structure seems cleaner, e.g. no overnesting or nesting like `review_2.py`
* Good use of the `any` function combined with `isdigit()` and `islower()`
* First `elif` statement has too many conditions - could possibly break the digit, lower and upper part right below
* Review_2:
* stores all horrible passwords in a list and checks whether the password is in this list.
* docstrings -> clearer, explains what each definition
is and is generally more understandable (e.g. which passwords are horrible)

### Group 4
Review_1:
- Difficult to understand
- No comments to supplement understanding
- It is pythonic as it uses python methods and other python tools (i.e. the 'in' keyword)

### Group 5
Too much nesting
pythonic but not very readable
There should be more comments explaining stuffc
inefficient use of for loops
condition comparisions should be split up on different lines (so one statement per line)

## QA

### Group 1

- Good requirements are to be as precise and specific as possible, the less ambiguous the better. Requires very little assumptions to be made.
- Clear, concise explanation of project direction and objectives in order to determine non-specified directives and limit the likelihood of goals not being achieved.
- Requirements which aren't conflicting & contradictory.
- No spelling or grammatical errors (preferable)
- Should outline the budget, the timeframe etc and also should be accommodating to any changes that are made during the project.
- Burger: Make a burger within 5 minutes of a customers' order. Place an even layer of pickles that evenly fills the surface of the bottom bun and an even 2mm (height) spread of mayo on top of the pickles. Place upper bun on top of mayo. Package in a brown paper bag.

### Group 2
- Concise and specific requirements
-
### Group 3
* Clear explanation of purpose
* Requirements should be specific as possible - it is better to be overly specific than have holes in requirements
* Achievability should be a core consideration when discussing requirements
* Single reponsibility principle - function does only one thing and one thing only
* No contradictions in requirements
* Specific quantities instead of words like 'a lot, many, some'

* Burger part:
What: burger w/
- specific number of pickles (e.g. 5)
- mayo - quantity e.g. 10mL - ensure the bun is not soggy
Temperature:
- specify the temperature ...
Packaging:
- brown paper bag - environemntal concern, good colour
When:
- Now

### Group 4
- Review_2:
- Contains docstring allowing users to instantly understand whats going on
- Use of lists to store horrible passwords
- Has docstring and comments
- Variable names are clearer and structured better
- Not very pythonic

### Group 5
good style, fairly readable
variables are named well
has a doc string

## QB

### Group 1

### Group 2
a. Doesn't require engineer to make any assumptions because the requirements are concise. Not too convuluted.
b. "I want a burger with lots of pickles and mayo but I need to make sure that the mayo doesn't make the burger bun really wet. Oh, and it needs to be warm, like, made less than 5 minutes ago warm but not so hot that I burn myself. I'm also not a big fan of plastic containers so if it could be in a paper bag that would be good. Actually, make that a brown paper bag, I like the colour of that"

I want a burger with 10 slices of pickles.
1 tablespoon of mayo on each bun.
I want it served fresh
I want the burger served in a brown paper bag

### Group 3

### Group 4
a. Good requirements are detailed and specific while also being readable and can be compartmentalized
b. Specific (time-wise and information-wise)
c. Consistently revised over time
d. Reached through negotiation between end users, design team and client(s)

"I want a burger with lots of pickles and mayo but I need to make sure that the mayo doesn't make the burger bun really wet. Oh, and it needs t obe warm, like, made less than 5 minutes ago warm but not so hot that I burn myself. I'm also not a big fan of plastic containers so if it could be in a paper bag that would be good. Actually, make that a brown paper bag, I like the colour of that"

-> The burger must have 6 slices of pickle

Food: Burger
Pickles: Yes, lots of pickles (pickles > 0)
Mayo: Yes (a dollop)
Priority: nothingness < Pickles + Mayo < not wet bun
Temperature: Freshly cooked but also ready to consume
Packaging: Brown paper bag

### Group 5
a. Good requirements are as detailed as possible and specific in terms of functional and non functional requirements.
Concise and Consistent

b.
Requirements:
The burger must have lots of pickles and mayo. The mayo must not make the bun wet.

The burger needs to be less than 5 mins ago, however it must be suitable to consume.

The burger must be served in a brown paper bag