The document discusses key aspects of the software engineering design process including requirements specification, architectural design, detailed design, coding and testing. It emphasizes that usability engineering should occur throughout the design lifecycle. The document also discusses iterative design and prototyping techniques which help address limitations of incomplete requirements specifications. Design rationale is presented as an important part of the process to explain and communicate the reasons behind design decisions.

2.  Software engineering and the design
process for interactive systems
 Usability engineering
 Iterative design and prototyping
 Design rationale

4.  Software engineering is the discipline
for understanding the software design
process, or life cycle
 Designing for usability occurs at all
stages of the life cycle, not as a single
isolated activity

5. Requirements
specification
Architecture
design
Detail design
coding and unit
testing
Integration and
testing
Operation and
maintenance

7.  Requirements specification
 Designer and customer try capture what the
system is expected to provide
 Expressed in natural language or more precise
languages, such as a task analysis would
provide
 Architectural design
 High-level description of how the system will
provide the services required
 Factor system into major components and how
they are interrelated
 Must satisfy both functional and nonfunctional
requirements

8.  Detailed design
 Refinement of architectural components and
interrelations to identify modules to be
implemented separately
 Coding and unit testing
 Implementing and testing the individual
modules in some executable programming
language

9.  Integration and testing
 Combining modules to produce components
from the architectural description
 Operation and maintenance
 Product is delivered to customer and any
problems/enhancements are provided by
designer while product is still live
 The largest share of the life cycle

10.  Verification
Designing the product right
 Validation
Designing the right product
 The formality gap
Validation will always rely to some extent on
subjective means of proof
 Management and contractual issues
Design in commercial and legal contexts
Real-world
requirements
and constraints
The formality gap

13.  The ultimate test of usability based
on measurement of user experience
 Demands specific usability measures
be made explicit in requirements
 Usability specification
 Usability attribute/principle
 Measuring concept
 Measuring method
 Now level/ worst case/ planned
level/ best case

14.  Problems
 Usability specification requires level
of detail that may not be possible
early in design
 Satisfying a usability specification
does not necessarily satisfy usability

16.  Iterative design overcomes inherent problems
of incomplete requirements
 Prototypes
 Simulate or animate some features of intended
system different types of prototypes
 Different models
 Throw-away
 Incremental
 Evolutionary

17.  Management issues
 Time
 Planning
 Non-functional features
 Contracts

18.  Storyboards
 Need not be computer-based can be
animated
 Limited functionality simulations
 Some part of system functionality
provided by designers
 Tools like hypercard are common for
these
 Wizard of oz technique

19.  Warning about iterative design
 Design inertia – early bad decisions stay
bad
 Diagnosing real usability problems in
prototypes…. and not just the
symptoms

20.  Team members can communicate
effectively
 You can test out ideas for yourself
 It encourages reflection: very important
aspect of design
 Prototypes answer questions, and
support designers in choosing between
alternatives

22.  Design rationale is information that
explains why a computer system is
the way it is.
 Rationale has to do with logical
explanations and reasons
 Discussions, debates, negotiations
 Reasons for features
 Reasons against features

24. Benefits of design rationale
Communication throughout life
cycle
Reuse of design knowledge across
products
Enforces design discipline
Presents arguments for design
trade-offs
Capturing contextual information

25. Types of DR:
 Process-oriented
Preserves order of deliberation and
decision-making
 Structure-oriented
Emphasizes post hoc structuring of
considered design alternatives
 Two examples:
Issue-based information system (IBIS)
Design space analysis