IT6X29 Revision

What Are Requirements? [blank_start]System[blank_end] Requirements: [blank_start]Functional[blank_end] requirements [blank_start]Non-functional[blank_end] requirements

FURPS+ Requirements Acronym? [blank_start]Functional[blank_end] requirements [blank_start]Usability[blank_end] requirements [blank_start]Reliability[blank_end] requirements [blank_start]Performance[blank_end] requirements [blank_start]Security[blank_end] requirements + even more categories…

Information Gathering Techniques Choose 6 that apply.

choose 6 that apply Reasons for Modeling

Some Analysis and Design Models Choose 8

Documenting Workflows with Activity Diagrams Workflow.

Documenting Workflows with Activity Diagrams Activity Diagram

Use Cases [blank_start]Use case[blank_end]— an activity that the system [blank_start]performs[blank_end], usually in response to a [blank_start]request[blank_end] by a user Use cases define functional requirements Analysts decompose the system into a set of use cases (functional decomposition) Two techniques for Identifying use cases User goal technique Event decomposition technique Name each use case using Verb-Noun

Use Case Diagrams Use case diagram— a [blank_start]UML[blank_end] model used to graphically show uses cases and their relationships to actors Recall UML is [blank_start]Unified[blank_end] [blank_start]Modeling[blank_end] [blank_start]Language[blank_end], the standard for diagrams and terminology for developing information systems Actor is the UML name for a end user Automation boundary— the boundary between the computerized portion of the application and the users who operate the application

Use Cases and CRUD CRUD technique – [blank_start]Create[blank_end] [blank_start]Read/Report[blank_end] [blank_start]Update[blank_end] [blank_start]Delete[blank_end] A good cross-check against the existing set of use cases. Used in database context Ensure that all classes have a complete “cover” of use cases Not for primary identification of use cases

Three Layer Architecture

Stakeholders of a comprehensive accounting system for public company

Verifying use cases for Customer

DA and DBA Responsibilities

First Normal Form A [blank_start]table[blank_end] is in first [blank_start]normal[blank_end] form if [blank_start]every[blank_end] field [blank_start]contains[blank_end] only one value. Not [blank_start]multiple[blank_end] [blank_start]values[blank_end] in an [blank_start]attribute[blank_end] Not [blank_start]varying[blank_end] number of [blank_start]columns[blank_end]

Second Normal Form A table is in Second Normal Form if it is First [blank_start]Normal[blank_end] Form and each [blank_start]non-key[blank_end] [blank_start]attribute[blank_end] is only [blank_start]functionally[blank_end] [blank_start]dependent[blank_end] on the entire primary key. This [blank_start]situation[blank_end] only arises with tables that have [blank_start]multiple[blank_end] [blank_start]attribute keys[blank_end]

Third Normal Form A table is in Third Normal Form if it is in [blank_start]2NF[blank_end] and NO [blank_start]non-key attribute[blank_end] (or set) is [blank_start]functionally dependent[blank_end] on any other non-key attribute ([blank_start]or set[blank_end]) In other words, no [blank_start]FDs[blank_end] among any [blank_start]non-key attributes[blank_end]

Steps of Object-Oriented Design Three paths Simple use case use CRC Cards Medium use case use Communication Diagram Complex use case use Sequence Diagram

Example of CRC Card

Example of System Requirment

Activity Diagrams Symbols

Name Analyse and design models

Metaphors of Human Computer Interaction

Many to Many Relationship

User Case Diagram

Systems Analysis Activity