SOFTENG Chapter 6-7

Structured analysis

considers data and the processes that transform the data as separate entities

Object-oriented analysis

• focuses on the

  • Definition of classes

  • Manner in which they collaborate

Flow Oriented Modeling

• Represents how data objects are transformed as they move

• ‘Old school’ approach

• external entity

• process

• data flow

• data stores

Flow Modeling Notation

External entity

a producer or consumer of data

Process

data transformer (compute taxes, determine area, display graph) “Data must always be processed in some way to achieve system function”

Data Flow

data flows through a system, beginning as input and into output

Data stores

data is stored for later use

Control Flow Modeling

Represents ‘events’ and the processes that manage events

event

•  is a boolean condition that can be ascertained by:

  • Listing all sensors that are ‘read’ by the software

  • Listing all interrupt conditions

  • Listing all ‘switches’ that are actuated by an operator

Behavioral Modeling

How software will respond to external events or stimuli

State Representations

State of each class as the system must performs its function

Passive state

 simple the current status of all object’s attributes

Event

occurrence that causes the system to exhibit some predictable form of behavior

Action

process that occurs as a consequence of making a transition

Semantic analysis pattern (SAP)

 pattern that describes a small set of coherent use cases that describe a basic generic application

Content analysis

 full spectrum of content to be provided by WebApp is identified

Interaction analysis

 the user interacts with the WebApp is described in detail

Functional analysis

use-cases created as part of interaction analysis define the operations that will be applied

Configuration analysis

 environment and infrastructure in which the WebApp resides are described in detail

 use case

The most basic element of a requirement model

The Content Model

• Content objects are extracted from use cases to examine the scenario description for direct and indirect references

• Attributes are identified

Relationships

entity-relationships diagram or UML

Hierarchy

data tree or UML

• Use-cases

• Sequence diagrams

• State diagrams

• A user interface prototype

The Interaction Model

The Functional Model

• Addresses two processing elements:

  • User observable functionality that is delivered by the WebApp

  • The operations contained within analysis classes that implements behaviors associated

• An activity diagram can be used to represent processing flow

• server side

• client side

The Configuration Model

Server-side

Server hardware and OS environment must be specified

Client-side

Browser configuration issues must be identified

• Lack of consistency

• Too much memorization

• No guidance/help

• No context sensitivity

• Poor response

• arcane/unfriendly

Typical Design Errors

1. place the user in control

2. reduce the user’s memory load

3. make the interface consistent

Golden Rules

Place the user in control

• Define interaction modes in a way that does not force a user into unnecessary or undesired actions

• Provide flexible interaction

• Allows user interaction to be interruptible and undoable

Reduce the user’s memory load

• Reduce demand on short-term memory

• Establish meaningful defaults

• Define shortcuts that are intuitive

• The visual layout of the interface should be based on a real-world metaphor

• Disclose information in a progressive fashion

Make the interface consistent

• Allow the user to put current task into meaningful context

• Maintain consistency across a family of applications

• Do not make changes unless there is a reason to do so

• user model

• design model

• mental model

• implementation model

User Interface Design Models

user model

a profile of all end users of the system

design model

a design realization of the user model

mental model

user’s mental image of what the interface is

Implementation model

 interface “look and feel” coupled with supporting information that describe interface syntax

Interface Analysis

• Understanding people who will interact with the system

• Understanding the tasks that end-users must perform to do their work

• Understanding the context that is presented as part of the interface

• Understanding the environment which these tasks will be conducted

• interface analysis

• user analysis

• task analysis and modeling

• analysis of display content

User Interface Design Process

Use-cases

define basic interaction

Task elaboration

refines interactive tasks

Object elaboration

identifies interface objects

Workflow analysis

defines how a work process is completed when people are involved

• Response time

• Help facilities

• Error handling

• Menu and command labeling

• Application accessibility

• Internationalization

design issues

• anticipation

• communication

• consistency

• controlled autonomy

• efficiency

• focus

• fitt’s law

Interface Design Principles

Anticipation

a WebApp should be designed so that it anticipates the user’s next move

Communication

communicate the status of any activity initiated by the user

Consistency

the use of navigation controls, menus, icons, and aesthetics

Controlled autonomy

 facilitate user movement throughout the WebApp

Efficiency

optimize the user’s work efficiency

Focus

Fitt’s Law

Learnability

designed to minimize learning time

Maintain work product integrity

work product must be automatically saved

Readability

all information presented through the interface should be readable

Track state

state of the user interaction should be tracked and stored

Visible navigation

provides “the illusion that users are in the same place, with the work brought to them”

• inception

• elicitation

• elaboration

• negotiation

• specification

• validation

• requirements management

requirements engineering

Inception

• ask a set of questions that establish:

  • Basic understanding of the problem

  • The people who want a solution

  • The nature of the solution

  • The effectiveness of preliminary communication and collaboration between the customer and the developer

Elicitation

elicit requirements from all stakeholders

Elaboration

create an analysis model that identifies data, function and behavioral requirements

Negotiation

agree on a deliverable system that is realistic for developers and customers

Specification

• can be any one of the following:

  • Written document

  • Set of models

  • Formal mathematical

  • Collection of user scenarios

  • Prototype

Validation

•  review mechanism that looks for:

  • Errors in content or interpretation

  • Areas where clarification may be required

  • Missing information

  • Inconsistencies

  • Conflicting or unrealistic requirements

Inception

• identify stakeholders

• recognize multiple POVs

• work toward collaboration

Eliciting Requirements

• Meetings are conducted

• rules are established

• agenda is suggested

Facilitator

controls the meeting

definition mechanism

work sheets, flip charts, wall stickers

• problem solving

• elaboration

• negotiation

• specification

Requirements elicitation (requirements gathering) combines elements of

Elicitation Work Products

• Statement of need and feasibility

• Bounded statement of scope for the system

• List of customers, users and stakeholders who participated in requirements elicitation

functional

processing narratives for software functions

use-case

description of the interaction

class-based elements

implied by scenarios

scenario-based elements

• functional

• use-case

behavioral elements

state diagram

flow-oriented elements

data flow diagram

use-cases

• collection of user scenarios

• described from POV of an actor

actor

person or device that interacts with software

pattern name

 descriptor that captures the essence of the pattern

Intent

describes what the pattern accomplishes or represents

Motivation

illustrates how the pattern can be used to address the problem

Forces and context

external issues that can affect how the pattern is used

Solution

how the pattern is applied to solve the problem

Consequences

what happens when the pattern is applied and what trade-offs exist during applicatio

Design

discusses how the analysis pattern can be achieved through the use of known designs

Known uses

examples of uses within actual system

Related patterns

one or more analysis patterns related

Negotiating Requirements

• Identify the key stakeholders

• Determine each of the stakeholders ‘win conditions’

• Negotiate