Glossary

Requirements Document which becomes

Business Rules

Refining requirements process

Interview Guidelines

Primary and alternative flows ; entry and exit conditions

Entry conditions (Preconditions)

Exit Conditions (Post-conditions)

Actors involved

An actor is/are entities that are external to the system that directly perform "use cases". An internal DB, is not an actor.

make actor’s names actually reflect their role; ”user” is too generic; ”Fred” is too specific.

Actor names should be specific and unambiguous: ”family tree database” is more informative than ”database”.

Actors can use the system and can be used by the system

Use cases capture goals or actions of actors.

Make sure UC names contain verbs ( Create; add; modify; delete; search; report; inspect)

Looking for symmetry can help: ”create” must be matched by ”delete”.

remember fundamental things: ”a user will read a document; will look at a picture; etc.”

This means avoiding mindless detail—”genealogist presses mouse button”.

Each UC should be self-contained.

try and be precise and avoid vagueness. ‘who is doing x’; ’what y is being done'; 'how is z being done?';

Avoid the passive voice in descriptions; it leaves open the questions as to who is doing what

Don’t repeat the use case name in the entry condition. eg ”Print document” has "doc exists" not "ready to print"

Don’t make up UC not in the requirements. ”add person” subsumes ”add father”

Avoid UC that look like algorithm steps: for example, save tree, enter tree

A use case diagram should look like a star, not an activity diagram.

Name the System box and, again, make it informative.

system should be a black box.

UC diagrams show what use cases exist, including choice points and parrallelism. but not necessarily how they are related.

Activity diagrams show a flow-chart process of the system.

bad names

fine grained task

chaining

missing uc

wrong uc

mis-identified actor

missing actor

mis-named actor

what do the arrows mean: control; data flow; initiating actor

wrong level of abstraction: Fine at start; big at end

main flow is normal; alternative catches deviations in AF should still meet

goal(pay by cheque rather than credit card)

exceptional flow is not meeting goal (card doesn’t work)

including too much UI

building data structure

more detailed than domain class diagrams

include operations as well as attributes

include software-oriented things such as types and visibilities.

deal with a small number of classes at once, since each is described in more detail.

Types. Shown after the name, e.g. name:String

Visibilities + (public) – (private)

Parameters on operations e.g. addOption(option: MCQOption)

Static attributes and operations e.g. inputFromFile(filename:String):Question

Constructors: Student(name, ID)

Types and visibilities are still optional

Requirements gathering

Systems analysis

Design

Coding

Testing

Maintenance

Later a problem is found, the more expensive it costs to fix

Well defined milestones/deliverables make budgeting/planning easier

Well documented, problems clearly identified

Promotes specilisation because of layers

Deliverables offen late or fudged (blank tape trick)

Analysis Paralysis offen occurs

Specialisation can cause poor communication.

The system delivered does not meet the users’ needs

“maintenance” phase is often prolonged and traumatic.

project is usually grossly late and over-budget.

you won’t get the requirements right the first time

cope much better with requirements change than waterfall

code quality should be good

requires competence and confidence from all developers

long-term planning may be difficult

lack of documentation may cause problems later

probably not suitable for large projects

Requirements are determined from “user stories” (similar to informal use cases)

Customer representative always available

Unit tests are written before the code to be tested

Programming in pairs – one codes the other reviews, swapping frequently.

Strong emphasis on simplicity of design.

“Refactor whenever and wherever possible”

Example of an Agile Method

Iterative

Phases

Disiplins

Artefacts

What we are learning

Ergonomics

Dialogue Design

Rendering State

Defined start point

Restricted set of known steps

Set of known options

Ability to move back and forth and change options

One choice affects what is offered for another

Typical of an installation process

Again, set of known step and known options

No defined start point

I might want to start anywhere

Choosing Specifying a package holiday: Start point; end point; dates; hotels; tours; etc.

I might wish to start at any point

One choice affects another

Humans work by manipulating things both mentally and physically

A user reaches for what he/she wants, uses and puts it down again

Humans also wish to see the results of their actions

Dragging a file to the printer; putting files in the bin; making words bold; drawing lines etc.

“hey you do that”

Lots of functionality available all the time

Typicall not for everyday users

Very good for mass action

“mv *.txt ../other-folder”

Very good for constructing arbitrary, complex actions

Often very fast for the power user

A set of repeated steps

Need to be run repeatedly in the same way

“A batch” of commands

Don’t necessarily need to interact as the process runs

Bbut do need feedback like logs

Still an interaction style

Long-term modes modes

Short term “spring-loaded” modes

Alert modes modes

Modes that emulate a real-life situation that is itself modal

Modes that change the attributes of something

Modes that stop functionality, as in error conditions

There should be a clear indicator of the current mod

It should be easy to change modes

Try to be modeless, but some are useful

Ease to learn; easy to remember

return after long break and know how to use the tool

return after a short break (cup of tea) and apprehend state

Consistent application design

Closeness to user’s model of the task helps mapping

UI aims

Most users don’t read manuals

Users prefer to learn by playing or exploring

Therefore good presentation of model to user is vital

“Walk up and use”

Transferable skills

Users like to explore

External consistency: Consistency with task

Ergonomic issues

Internal consistency: Arbitrary consistency

Does the UI map from all parts of task model to system model?

Can the system do things that I cannot ask it to do?

Can the input reach the(and only the) necessary states of the system ?

Match task analysis or activity diagrams to use cases and class/collaboration diagrams

Small cost to user, larger cost in implementation

Translate state from core to output language

Must preserve state attributes in terms of domain concepts

Output language often limited in expressivity

Video simply limited in size – difficult to see context in documents etc.

Means tests will be written without preconceptions about how the code works.

If the code is changed, the same tests are still valid.

Allows more tests to be done

Allows tester to apply pressure to those places which look most likely to break.

Relatively simple, but the class you’re testing will usually rely on other classes.

The search space is generally well defined so techniques like EP ad BVA are most useful here.

Often possible to be systematic and reasonably confident that a single class is bug-free.

In Java, often done with the JUnit testing framework.

Unit Testing

Harder to define than unit testing; shape of testing space is less obvious.

Check that the use cases can be performed without problems.

This will generally be a lot more varied than the context in which it was developed.

May involve different hardware, operating systems, performance issues etc.

Need to check the documentation and procedures as well as the code.

In general, users don’t really know in advance what they want (the “waterfall fallacy”).

Who within the customer organisation defines the spec? e.g. Managers and end users will have different views.

Fixating on passing the acceptance test could result in serious problems being missed.

Applies to all non-trivial(>10k lines) projects

Some components of SW will be bug-free

Causes crashes/freezes

Fail to provide functionally the user needs

Failure to conform non-function requirements

Inappropriate UI design

Documentation/training bugs

Requirement bugs

Testing

Code review

Refactoring

Frequent contact with users and stakeholders

Risk-driven development

Experience

On average, 3-5 bugs per 100 lines

concurrent, reactive systems are more diffcult than sequential transformations systems

Programming language: Java < C < Perl

Programmer competence and experience

High cohesion/low coupling

Always separate internal data structures (model) from the UI code (view)

Allow each to change without affecting the other

Could also be a MVC where the controller is between M and V

MVC