Part 1 & 2

• There should only be a what in the requierment and not "how" this what is archived.
• 

Acronym RiCW - rice

• Manifesto reads 4 points;
• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

• Exploratory creativity:
• Exploratory creativity involves finding new ideas within the same space.

Combinatorial creativity involves finding new ideas by examining the combination of existing ideas.

Convergent thinking is the type of thinking we do when solving a well-defined, straightforward, correct answer to a problem.

Divergent thinking is the type of thinking we do when solving an abstract or new problem that has many possible answers, solutions, or outcomes.

BLIMP-D

• The lean start up feedback cycle is:
• 1. Ideas
• 2. Build
• 3. Product
• 4. Measure
• 5. Data
• 6. Learn

A confounding variable is an outside influence that changes the effect of a dependent and independent variable.

An independent variable is the variable that is changed or controlled in a scientific experiment to test the effects on the dependent variable.

A dependent variable is the variable being tested and measured in a scientific experiment.

• Users: people who directly use the system (any function of the system)

• Stakeholders: anyone who has a “stake” in the system– Anyone who can be positively or negatively affected

• Users are stakeholders, not all stakeholders are users

• Domain Properties/Assumptions are characteristics of the problem domain that are assumed to hold.
• They are not requirements, because they don’t have to be achieved by the system.

Requirements – Capture Features and Functions of a system or component.

• Constraints – Define the Non-Functional aspects of a system or component, such as restrictions on technology, resources or
• techniques to be used.
• = They are a requirement that doesn’t come from user needs.

• -Independent
• -Negotiable
• -Valuable
• -Estimable
• -Small
• -Testable

• -Context to Use Case
• 1 System actor is system boundary
• 2 Other actors are actors
• 3 Inputs/outputs roughly map to use cases

• Context to Goal Model
• 1 System actor is an actor
• 2 Other actors are actors
• 3 Inputs/outputs are dependencies

Brainstorming, Hall of Fame/Bright Sparks, Creative Search, Pairwise Comparison, Creativity Triggers, Assumption Busting, Roleplaying.

K-Top

• 1 Task time (performance)
• 2 Problem counts
• 3 Keystroke counts
• 4 Opinion polls/surveys

MMMAT

• 1. Missing functionality or bug: function the user wants is not there, or crashes, doesn’t work

• 2. Task Failure: user cannot figure out how to do a task in a fixed amount of time

• 3. Annoying: user can do a task in a reasonable amount of time, but is annoyed

• 4. Medium problem: user succeeds in task after a long time

• 5. Minor problem: user succeeds in task after a short amount of time (but it still took longer than expected)

First I do context diagram.

• Then all entities and system from context diagram become actors,
• Either "open" actors(are more imporant/focused generally of the maintask/system of the system as a whole) that have their own goals or just actors (closed).

• The data-flow arrows become resource boxes that connect from tasks of open actors to 
• other actors or from Task to Task.

Understanding “why?”, not just “what?” or “how?”.

Festuee

•Fit for use (functionality): The system can support the tasks the user has in real life

•Ease of learning: How easy is the system to learn for various groups of users

•Task efficiency: how efficient is it for the frequent user

•Ease of remembering: how easy is it to remember for the occasional user

•Subjective satisfaction: how satisfied is the user with the system

•Understandability: How easy is it to understand what the system does?

•Ease of use (User friendliness): combination of all factors but the first.

• Return on investment
• It tells you how much of your original investment you will get back, in percentage. For example, a 0% return on investment means you only make back your original money, a 100% return on investment means you double your money.

(Net Present value / Estimated lifetime costs)

Someone who is generally smart and tech savvy but ignorant in the specific domain.

This is useful because they will ask good questions about the domain, challenge assumptions, bring out tacit knowledge.

U-CS

Use Case template = Scenarios are captured in text via listing the sequence of steps executed in the use case.

Customer Journey map = Scenarios are capturing by showing the journey of a persona in using the system, the timeline shows the journey, and the touch points show the steps.

Storyboards = Captures a scenario by showing what happens in each frame or square, maps out a scenario in a comic-like board.

DIGO

• Documentation
• • Benefits– Can read on your own time– Don’t need stakeholder resources.

• • Drawbacks:
• – May reflect an ideal version of reality
• – May be out of date
• – May have lots of domain
• -- specific vocabulary and be hard to understand.

• Interviews
• • Advantages
• - Rich source of data
• – Can probe interesting areas, ask follow-up questions
• – Get individual perspectives
• • Disadvantages
• – Hard to analyze large amount of qualitative data.
• – No convergence between interviewees
• – Sometimes hard to conduct.

• Questionnaire/Surveys
• • Advantages
• – Lots of responses
• – Can have statistical significance
• – Can be used remotely (you don’t have to be there)
• • Disadvantages
• – Have to be very carefully designed, piloted, proofread.
• – If questions are misunderstood, no chance to clarify.
• – No chance to ask follow-up questions
• – Broad but shallow
• – Hard to get people to answer, hard to get long answers

• Group techniques/focus groups/workshops
• • Advantages:
• – Interesting discussions and convergent thinking
• – Saves time to talk to many stakeholders at once
• • Disadvantages:
• – Group think: people tend to follow, not diverge
• – Power dynamics: some may be afraid to speak
• – Some are just quiet, hard to involve everyone

• Observation
• • Advantages– Maybe see how things are really done (see things people won’t tell you)
• – Really get to know the working environment
• – Spent time, maybe gain trust?
• • Disadvantages
• – Takes a lot of time
• – Bias: observer may act differently when being observed
• – May not be possible

• Agile Elicitation
• • Benefits:
• – Frequent feedback
• – Joint ownership of requirements and development process= “we” are doing this

• • Challenges:
• – In really your stakeholders are often too busy to do this
• – What if you get the wrong stakeholder? Can one speak for many?

TAMMM

• Here is all 5, one mark for the name, one for the correct description for 3 of them.
• • 1. Missing functionality or bug: function the user wants is not there, or crashes, doesn’t work
• • 2. Task Failure: user cannot figure out how to do a task in a fixed amount of time
• • 3. Annoying: user can do a task in a reasonable amount of time, but is annoyed
• • 4. Medium problem: user succeeds in task after a long time
• • 5. Minor problem: user succeeds in task after a short amount of time (but it still took longer than expected)

Application Domain: the world, where people, organizations and problems live.

• Market space
• Competition
• Demand
• Cost-Value
• Align whole firm

In a blue ocean strategy one wants to: (don’t expect all of this for full marks)

Create an uncontested market space.

Make the competition irrelevant.

Cost-value


Create and capture new demand.

Break the value-cost trade-off.

Align the whole system of a firm’s activities in pursuit of differentiation and low cost.

• • Validation: Are we building the right system?
• – Does our solution solve the real problem?
• – Did we account for the most important stakeholder needs?

• • Verification: Are we building the system right?
• – Does our design meet the requirements?
• – Does the system do what we say it would do?
• – Are our requirements representations consistent?

• Any of these well-explained will count:
• • Thin spread of domain knowledge
• – It is rarely available in an explicit form (i.e. not written down)
• – ...distributed across many sources
• – ...with conflicts between knowledge from different sources

• • Tacit knowledge (The “say-do” problem)
• – People find it hard to describe knowledge they regularly use
• – Limited Observability
• – The problem owners might be too busy coping with the current system
• – Presence of an observer may change the problem

• • Bias
• – People may not be free to tell you what you need to know
• – People may not want to tell you what you need to know
• BAST-D

• The outcome will affect them, so they may try to influence you (hidden agendas)

• Stakeholder identification– Hard to figure out who to talk to

• – Minimum Viable Product:
• create the minimum product you can release. Must be functional and useful.

• – Useful:
• to test and learn in order to gradually improve product. Reduce effort to release. Agile thinking.

• Valid across different platforms and systems
• – The best patterns aren’t specific to a single platform or idiom

• Suggestions, not requirements
• – patterns are intended to be only suggestions; you can follow them or reject them, depending on your design context and user needs

Structured format = B:date _-_-_-_ - _/_ -_ _ _ _

• Input prompt = "like Japan"
• used in textbox

• drop-down chooser = "card brands..."
• List of set values below eachorder in list

prompt done button = to make completion obvious.

• row striping = line up repeated alternatives
• like apprive decline buttons to make them easier to distuinguish

infinete list - list that keeps on expanding as scroll down

"Employee: you have travelled to Spain last month, submit a travel statement in the system including all relevant details of your travels (screen 1)."

"Acceptor: You have received a notice that R. Smith has submitted a travel statement for acceptance. Find the statement, look at the details, and decide to accept or reject the travel (screen 2)."

• 1. Open actors, often use 2.
• 2. Closed actors, often use 1.
• 3. Draw Goals, what goals are use-cases made for? could be "facilitate car rentals" done by tasks move cars, rent cars, accept returns.
• 4. draw resources boxes(constraints and domain asuptions/requerments), using data flow arrows from context, can be in both domain(outside openactor) and inside?.
• 5. draw tasks inside open actors using use case to-do style.
• 6. Draw qualities=how usability is impacted, connect them to things that impacts this.