Note: These notes are a mixture of lecture material, textbook material and private research. All credit to the University of Melbourne.

Interviews

Communication Principles

1. Listen to the client
2. Prepare
3. Use a facilitator
4. Prioritise face-to-face communication
5. Take notes
6. Collaborate
7. Stay focused
8. Always move on
9. Don’t treat it as a contest

Types

1. Structured
2. Unstructured
3. Semi-structured

General protocol

1. Identify
   • understand organisations
   • clarify sought data
2. Plan
   • learn about domain/terminology
3. Conduct
   • ask questions and record answers
   • follow up answers
4. Analyse Results
   • get feedback

Pros	Cons
Answers trigger new questions	Subjective
Captures perceptions and feelings	Hard to consolidate viewpoints
	Results dependent on interviewer

Guidelines

• Identify set of stakeholders
• Establish rapport
• Focus on work/problems
• Keep open ended questions for end
• Follow up interesting answers
• Ask ‘why’ of established solutions
• Never say ‘usually’
• Encourage stories
• Find inconsistencies
• Don’t feat silence

Requirements Engineering

Repeatable process of gathering and refining requirements.

Waterfall Process

• Communication
  • Gather requirements
• Planning
  • Estimation
  • Scheduling
  • Tracking
• Modelling
  • Analysis
  • Design
• Construction
  • Code
  • Design
• Deployment
  • Delivery
  • Support
  • Feedback

V-Model

• Requirements ↔ Acceptance
• Architectural ↔ System
• Component ↔ Integration
• Code ↔ Unit

Scope Creep refers to changes or continuous/uncontrolled growth in a project’s scope at any point after the project begins. Can occur when the scope is not properly defined or controlled.

Classic Requirements Engineering Process

• Inception
• Elicitation
• Specification/Modelling
• Negotiation
• Validation
• Requirements Management

Agile Inception

Helps to reach alignment and set expectations.

• Team gets ready to start a project
• 1-2 day meeting
• Involves dev team and clients

Identify:

• Vision/Goals
• Non-goals (out of scope)
• Risks
• Roles/Personas
• Activities/Workflows
• Stories
• Estimations
• Priorities
• Retrospective

Cultural Differences

Geert Hofstede factors:

1. Power distance
2. Individualism
3. Masculinity
4. Uncertainty avoidance
5. Long Term Orientation
6. Indulgence

Goal Modelling

How to keep “big picture” in software projects.

Why are we doing what we are doing?

Creates a shared understanding for everyone, and can be communicated with stakeholders.

Models

A model is an abstraction from the real world.

Benefits of a model:

• doesn’t over-elaborate
• supports discussion between stakeholders
• brings you closer to the final product

Lists

An intermediate step to organise data.

Created:

1. Through a workshop with stakeholders
2. By analysing data

Lists to create:

• Who - the stakeholders involved in the system
• Do - functional requirements of system
• Be - constraints/quality requirements on functionalities
• Feel - emotional/social considerations/concerns regarding features

Goal Model

Introduces the domain problem. Figure out the goal of the sought system.

Mapping the list to a goal model:

• Who → roles
• Do → functional goals
• Be → quality goals
• Feel → emotional goals and concerns/risks

Hierarchy:

• Top-down - general → specific, “how the super-goal will be achieved”
• Bottom-up - specific → general, “why the sub-goal is done”

Functional goals are linked to roles. If no explicit roles are listed, they inherit from above.

Quality and emotional goals are linked to functional goals.

Elicitation Techniques

Background Study

Study existing documents on:

1. The organisation - e.g. org charts, business plans
2. The domain - e.g. articles, regulations, reports
3. The system-as-is - e.g. work procedures, business rules, user manuals

Questionnaires

Allows elicitation of subjective information. Can be a complement to interviews.

Style of questions:

• Multiple choice
• Likert scale (1-5, strongly agree-strongly disagree)

Pros	Cons
Low Cost	Biased information
Remote respondents	No direct interaction
Large Pool	Hard to provide context

Questionnaires should be validated to mitigate problems. Some methods:

• Statistical significance of target audience
• No bias in formulation/presentation of Q/A
• No ambiguity in Q/A

Some implicitly redundant questions can help.

Repertory Grids

Useful to learn about certain concepts. One card per concept.

• Attributes
• Values (ranges) for attributes

Card Sorting

Useful to understand implicit classification. One concept per card. Partition the cards into subsets.

Focus Groups

Interviews with more than one participant.

Pros	Cons
Saves Time	Risky if there are alpha individuals
Larger pool of opinions	Personal agendas may silence opinions
	Harder to analyse recordings

Observation and Ethnographic Studies

Observing someone doing their job to help understand the problem.

Appropriate for complex organisations or cultural contexts.

Can be passive or active observation.

Pros	Cons
Elicit tacit knowledge	Very Expensive
	Takes a long time
	Needs trust
	Hawthorne effect

The Hawthorne effect (observer effect) is where the subject of studies behaviour is altered due to the awareness of the study.

Processing the Data

Identify:

• Themes - e.g. types of goals
• Topics - e.g. instances

Storyboards

Loose form narrative of:

• System-as-is
• System-to-be

Tell the story as a series of quick, easy-to-understand snapshots.

• Passive - e.g. create story for understanding, validation
• Active - e.g. joint effort with client for exploration

Covers:

• Roles
• What happens to roles
• Why things happen
• “What if” scenarios
• Positive/negative consequences

Scenarios

Structured storyboard form. Used to understand how things are and how they should be.

Used to:

• Ask specific questions
• Understand underlying motivations and goals
• Represent desired behaviour

Pros	Cons
Concrete/Easy to understand	Partial, not comprehensive
Brings stakeholders to same page	Hard to integrate all views
	Over-specification of interactions
	Don’t detail motivation of interactions

Product backlog and User Stories

Limitations of Classic Models

• Heavyweight development process
• Too slow
• Too much documentation
• Hard to adapt to change
• Hard to freeze requirements
• Projects run over-time, over-budget

Agile

Alternative to document-driven, heavyweight software development processes. Against process for the sake of process.

• Planning vs Immutable Plans
• Modelling vs 100s of unused pages

Manifesto

Individuals and interactions over proccesses and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Principles

1. Satisfy customer through early and continuous delivery of working software
2. Welcome changing requirements
3. Deliver working software frequently
4. Business people/developers work together daily
5. Utilise motivated individuals
6. Face-to-face conversation
7. Primary measure of progress is working software
8. Sustainable development
9. Technical excellence and good design
10. Simplicity
11. Self-organising teams
12. Reflect on how to become more effective

Scrum

One of many different agile processes.

• Hard to understand problem from beginning
• Requirements are volatile
• Not realistic to stick to a plan
• Be quick to adapt
  • Unexpected requirements
  • New technologies
  • New market conditions

Product Owner

• Defends clients interests
• Writes user stories
• Defines when user story is done
• Prioritises user stories
• Adds user stories to sprint backlog
• Stays away from technical aspects

Scrum Master

• Ensures integrity of scrum process
• Facilitates team events
• Steers team towards improvement
• Manages sprint bakclog and determines completion of tasks
• Promotoes self-organisation of team

Development Team

• Self-organised
• Analyse, design, develop, test
• Tackle complete iterations

Scrum Meetings

• Sprint planning
  • 1 hr per week
  • Define sprint backlog
    • Correct story size
    • Sprint duration, velocity, priorities, item size
  • Scrum master
    • Facilitator
  • Product owner
    • Clarify requirements
    • Define acceptance criteria
    • Resolve dependencies
  • Dev team
    • Determine effort involved
• Daily scrum/stand-up
  • < 15mins
  • Members commmit to each
    • What did i do yesterday?
    • What am i going to do today?
    • Any impediments in the way?
• Sprint review meeting
  • 30 mins
  • Demo a product improvement, live not a report
  • Assess items that are completed
  • Incomplete items back to product backlog
  • Product owner rethinks priorities
• Sprint retrospective
  • 1 hr
  • What is not working?
  • What are we doing well?
  • What should we start doing?
  • Everyone votes on decisions for next sprint

Product Backlog

Requirements document for scrum. Shows what will be delivered in the order that it will be delivered. Continuously evolving docuement with initially only the well understood requirements. It can change dynamically to keep the product useful or adapt to market/new technologies. Product owner orders the product backlog and calculates priorities/dependencies.

Priorities

Used to order importance in product/sprint backlog.

MoSCoW:

• Must
• Should
• Could
• Won’t

Cumulative voting - resources are distributed across features

Priority = Urgency * Value

Urgency - time constraints, dependencies

Business value - importance to many customers, impact on brand/rep, competitive advantage

User Stories

As a role, I want to do something, so that I get some benefit.

Can also add given, when and then.

Number → Story → Weight

Weight:

• for comparison purposes
• can use Fibonacci numbers, t-shirt sizes
• hard to estimate without experience
• each team member should know how much weight they can pull
• velocity will change as teams adjust to each other

Acceptance Criteria:

• defined with user stories
• Given some precondition, when I do something then expected result

User story taxonomies:

• Product has features
• Feature has epics
• Epic has stories

User stories eventually decomposed into tasks.

In practice, user stories are conversation holders to be had between product owner and dev team.

User Acceptance Testing

Client determines whether they accpet the software. Whether it is:

• fit for purpose
• adheres to quality requirements
• meets contractual agreements

Just before the product is deployed. Black-box type of testing. Only performed when product has gone through all other testing (unit, integration, system)

Can be demo-based (product owner runs) or user-driven (client runs it)

Example template

Description - Preconditions - Steps to execute - Expected Results - Pass - Fail

• Comments

UAT Session:

• Before - ensure no bugs, give client test cases
• Client, QA team, Dev team
• Bugs - fix, leave in, leave in for future fix
  • describe known bugs beforehand
• Result - go, no-go
• Use realistic data
• Don’t argue/agree with client

Quality Requirements

Non-functional requirements

Constraints on the software-to-be.

Not always clear seperation between:

• functional and non-functional requirements
• non-functional categories (often involve multiple categories)

Taxonomies

Help to identify hidden requirements and confilicts between requirements.

Taxonomies aren’t exhaustive but give a good indication of main classes.

• Van Lamsweerde’s
• ISO/IEC

Van Lamsweerde

• Safety - rule out effects that might result in accidents, degradations
• Security - prescribe protection against undesirable environment behaviours
  • confidentiality
  • integrity
  • availability
• Reliability - operate as expected over long periods
• Performance - operational conditions e.g. time/space, frequency, throughput
• Interface - phenomena shared by software-to-be and environment
• Useability - input/output formats to fit expectations/abilities of users
• Interoperability - effective cooperation with environment components
• Accuracy - state of information reflects physical environment
• Compliance - conform to laws, regulations, standards
• Architectural - distributions constraints - geographic, data, devices
• Development - way it should be developed - costs, schedules, maintainability, portability

ISO/IEC 25010:2011

• Product Quality model - static properties of software, dynamic properties of system
• Quality in use model - outcome of using product in particular context, human- computer system

Product Quality Model

• Functional suitability
  • suitability
  • accuracy
  • interoperability
  • security
  • compliance
• Reliability
  • maturity
  • fault tolerance
  • recoverability
  • compliance
• Operability
  • appropriateness
  • recognisability
  • ease of use
  • learnability
  • attractiveness
  • technical accessibility
  • compliance
• Performance Efficiency
  • time behaviour
  • resource utilisation
  • compliance
• Security
  • confidentiality
  • integrity
  • non-repudiation
  • accountability
  • authenticity
  • compliance
• Compatibility
  • replaceability
  • co-existence
  • interoperability
  • compliance
• Maintainability
  • modularity
  • reusability
  • analysability
  • changeability
  • modification stability
  • testability
  • compliance
• Transferability
  • portability
  • adaptability
  • installability
  • compliance

Quality in use

• Effectiveness - accuracy/completeness of user achieving goals
• Efficiency - resources expended in achieving goals
• Satisfaction
  • likability
  • pleasure
  • comfort
  • trust
• Safety
  • economic damage
  • healthy and safety
  • environmental
• Usability
  • learnability
  • flexibility
  • accessibility
  • context conformity

Brainstorming

Team effort to propose creative ideas to solve a problem.

Guidelines:

• Do not judge, no bad ideas
• More ideas the better
• Wild ideas can bring new perspectives
• Ideas can be combined into new ones

Choose best ideas to prototype.

Obstacles:

• Ideas blocked by other ideas
• Fear of judgement
• Extroverts/Introverts may be incompatible
• Group behaviour adjustment

Tips/tricks:

• write ideas down
• change perspective
• write on walls
• numbered lists
• role play
• reframe prolbem
• non-stop writing

Mind Maps

• Visually organise info
• Central concept, hierarchical, relationships
• Start in cenre of page
• Use symbols, colours
• Branch out from centre

Technical Natural Language

Specifying requirements (elicited)

• system-to-be
• aids discussion betwen clients and dev team
• range of formalities

Natural Language

First obvious choice

Pros	Cons
No limitation in expressiveness	Prone to errors/flaws
No communication barrier	Inherently ambiguous
No special training

Guidelines:

• identify audience first
• say what you are going to do
• motivate first, summarise after
• define concepts before using them
• one requirement per sentence
• keep sentences short
• avoid jargon/acronyms
• ‘shall’ = mandatory, ‘should’ = desirable
• use exmaples
• use bulleted lists for conditions of related items
• use diagrams
• use figures
• use tables
• avoid complex combinations of conditions

Errors in requirements

• Ommission
  • missing objective, unstated software reponse to input
  • very hard to detect
• Contradiction
  • conflicting viewppints
• Inadequacy
• Ambiguity
• Unmeasurability

Flaws in requirements

• Noise - doesn’t convey information on problem
• Overspecification - thinking in terms of solution instead of problem
• Unfeasibility
• Unintelligibility
• Poor structuring
• Forward reference - references to not yet defined features
• Remorse - stating a feature too late
• Poor modifiability
• Opacity - rationale, authoring or dependencies are invisible

Quality factors

• Completeness
  • include quality goals
  • requirements to prevent undesirable effects
  • output for all possible inputs
  • sufficient detail for development
• Consistency
• Adequacy
• Unambiguity
• Measureability
• Pertinence - problem space nnot soltion space
• Feasibility
• Comprehensibility
• Good structuring
• Modifiability
• Traceability

Digital Prototypes

Shows key interface elements to be created. Show navigation to ensure expectations are met. Created early in development project as they are easy to change. Next natural step after a paper prototype. Allows client to use and “have a play”.

• Enables client to interact with system
• Client must understand they are only the skeleton, proof of concept
  • Can give it a “sketched” look to prevent this risk

Conversation starter:

• Dev team - clarify functionality, navigation, business model, UI design
• Client - content position, interactive elemtns, functions, priorities

Uses:

• ideation
• usability testing

High vs low fidelity - depends what you want to get out of them

Low fidelity (e.g. paper prototype):

• major navigation/content elements
• don’t show colour, images, fonts

High fidelity (e.g. digital prototype):

• closer to UI design
• include click through navigation
• realistic data/images

Tips:

• keeps simple
• use a grid to ensure alignment
• add meaningful annotations
• encourage feedback

User Journeys

Scenario depicting how a user/customer interacts with a product being designed. Can be narrative or visual and are based on client research. Told from the perspective of the client, and considers the complete user experience (e.g. building trust, loyalty, not just based on transactions)

Uses:

• Understanding users behaviour e.g. pain points
• Demonstrate how the system could be used

Business goals:

• Change focus of organisations
• Break down silos (departments in company)
• Give ownership of problems to specific teams
• Target specific customers
• Understand quantitative data

Key elements of user journey:

1. Persona (1 user journey per persona)
   • Goals
   • Motivations
   • Pain points
   • Character
   • Tasks to achieve
2. Scenario
3. Stages (steps)
4. Actions
5. Thoughts
6. Emotional Experience
7. Opportunities
8. Internal Ownership

Inconsistent Requirements

In Real World (as opposed to SWEN)

• range of goals
• range of support
• politics

Inconsistencies:

• multiple viewpoints/concerns
• must be detected
• identify hidden requirements

Types of inconsistencies:

• Terminology clashes - same concept different names
• Designation clash - same name different concpets
• Structure clash - same concept different structures
• Strong conflict - inconsistent logic when conisdered together
• Weak conflict - not always inconsistent, unless a boundary condition happens

Handling inconsistencies:

• Terminology, designation, structure
  • Glossary of terms
  • Precise and clear definitions
  • Include accepted synonyms
• Strong/weak conflicts - look at the causes
  • Inherent requirements incompatibilites
  • Conflicting viewpoints

Why are there viewpoints?

• Large projects - partial expertise/uses of system
• Many stakeholders. Each is certain that
  • their problem is hardest
  • they are right
  • their problem is most critical to solve
  • everyone else can wait

Dealing with conflicting viewpoints

• Identify stakeholders
• Determine ‘win’ conditions
• Identify risks and uncertainties of win conditions
• Negotiate with everyone to seek win-win conidtions

For negotiations

• Identify non-conflicintg
• Identify conflicting
• Present conflicts to decision makers

Democractic decisions

• Vote to resolve
• Sticky dots on requirements

Hints

• Not a competition/fight
• Everyone should feel they have won
• Think out of the box
• Listen and empathise
• Not personal, focus on problem
• Commit to decisions and move on

Validation and Traceability

Requirements Validation

Requirements quality assurance.

Aim at finding errors/flaws e.g. incorrectness, incompleteness, ambiguity

Cost of errors increment with time so best to identify early.

Process:

• identify defects
• report
• analyse cause
• fix

Techniques

• query requirements DB
• animation-based validation
• formal verification - formal language, logic
• inspection and reviews

Inspection and Reviews

• widest applicability and scope
• applicable to any spec format
  • textual
  • diagrams
  • formal
• get a person to look at doc and find problems
• potentially time consuming

Inspection Process

• varying degrees of formality
  • internal vs external
• formal process
  • inspection planning
    • team size
    • timeframe
    • meetings
  • reviewing
    • looks for defects
    • free mode - no instructions
    • checklist based
    • process based - split between inspectors
  • defect evaluation
    • collected and discussed - eliminate false positives
    • identify causes of defects
    • problems in process
    • recommend actions
  • documentation consolidation

Types of Checklists

• Defect-based
  • incompletenes
  • inconsistent
• Quality-based
  • non-functional requirements
  • security, performance
• Domain-based
• Language-based
  • formal/semi formal specs
  • types, decision tables

Guidelines

• Identify objective facts, not opinions
• Constructive criticism
• Inspection team different from spec team
• Focus on critical aspects of system
• Focus on aspects presenting more errors and dependent parts

Requirements Traceability

System-to-be will have to evolve:

• new technologies
• new policies
• changes in business model

Need to prepare for change from the beginning. Traceability allows propagation of changes along all artefacts of the life cycle.

Traceability diagram:

• forward/backward
• horizontal/vertical

Traceability links:

• Dependency
  • A affects B, B depends on A
  • Change in A might require changing B
• Variant
  • A source (master), B target (variant)
  • B has all features of A plus more
• Revision
  • B (next version) overrides A
• Use
  • A used by B
  • Changing A makes B incomplete

Maintaining traceability:

• Cross References
  • Unique identifiers
  • Indexing/tagging
  • No semantics
• Traceability matrix
  • Columns and rows are the items
  • One type of relation
  • Prone to errors if too large
• Feature diagram
  • Decomposition of features as a tree
• Traceability database
  • Stores all traceability info

Formal Methods

Rigorous mathematically based notation and language.

Concerned with reducing the number of faults in a system.

Mainly applicable for critical systems engineering. Cost-effective as there are high system failure costs.

Elements of formal methods:

• Specification Languages - mathematical basis for a formal method
• Program Refinement and Derivation
• Formal Verification
• Logical Inference

Formal methods reduce cost of validation, but increase cost of specification.

Users of formal methods:

• aviation
• rail
• medical devices
• nuclear power
• defence

Approaches to Formal Specification

Algebraic

• system described in terms of operations and their relationships
• define data types, functions and equations relating the functions

Model-based

• system modelled using math constructs e.g. sets, sequences
• operations defined by how they modify the system state

Can have Sequential or Concurrent languages

	Sequential	Concurrent
Algebraic	OBJ	Lotos
	Larch
Model-based	VDM	Petri Nets
	Z	CSP
	B

Formal Specification

Investing more effort in the early phases of software development.

Forces detailed analysis of requirements → less errors.

Incompleteness and inconsistencies can be uncovered → savings as less rework.

They are precise and unambiguous. Remove areas of doubt.

Statecharts

An evolution of formal methods. Shows a good level of abstraction.

Questions

• Biased information (07 elicitation)
• Some implicitly redundant questions can help.
• Obersvation - Elicit tacit knowledge
• Passive vs active observation
• Hard to freeze requirements
• Scrum master “micromanages at times”
• Self-organised dev team, do they pick their team or just their tasks?
• All agile have those 4 meetings, or just scrum?
• 30 min sprint review meeting really enough to do QA?
• Cumulative voting in agile priorities
• Group behaviour adjustment
• Technical language - errors in requirements
• Democratic decisions - should we get involved?
• Animation based valiation
• Storyboard, Scenario, User Journey