Requirements Analysis & UML Models

Week 8 Agenda

• Topics for this week include requirement analysis along with modeling techniques, structured analysis models, and UML models.

Requirements Analysis

• Specifies the operational characteristics.
• Indicates the software's interface with other system elements.
• Establishes constraints that the software must meet.
• Requirements analysis allows for software engineers to elaborate on basic requirements established.
• Models are built to depict user scenarios, functional activities, problem classes and relationships, system behavior, and data flow.
• Processes system specifications into the design which can transform the requirements from the elicitation results.
• Systematic with heuristics.
• Problem domain analysis occurs specifically for design.
• Models are composed of static and dynamic UML models.
• A model's static aspects are classes, relationships, and attributes, for modeling system structure.
• A model's dynamic aspects capture object behavior and interactions for modeling system behavior.
• Models should be correct, complete, consistent, and verifiable.
• Supplies first technical representation of a system.
• Promotes ease of understanding and maintenance.
• Deals with size issues by partitioning the system.
• Uses graphics when possible.
• Differentiates between essential and implementation information.
• Tracks and evaluates interfaces.
• Provides tools besides narrative text to describe software logic and policy.

Purpose

• Specifies the software's operational characteristics.
• Indicates the software's interfaces with other system elements
• Establishes the constraints that the software must meet.
• Provides the software designer with a representation of these considerations: information, function, and behavior
• This is later translated into architectural, interface, class/data and component-level designs.
• Provides the developer and customer with the means to assess quality once the software is built.

Analysis Phase Objectives

• Customer requirements are described.
• Establishes a foundation for software design.
• Provides requirements that are validated once the software is done.
• Elements of an analysis model are traceable to parts of the design model, sometimes overlapping.

Analysis Rules of Thumb

• Analysis models should focus on requirements that are visible within problems or business domains.
  • Level of abstraction should be relatively high
• Each element should increase understanding of software and insights to:
  • Information domain, function, and behavior of system
• Delay infrastructure and non-functional considerations until the design phase.
  • First complete the analysis of the problem domain
• The model should minimize coupling throughout the system
  • Reduce the level of interconnectedness among functions and classes
• Should provide value to all stakeholders.
• Keep as simple as possible.

Domain Analysis

• Identifies, analyzes and specifies common, reusable capabilities within a specific application domain.
  • Do this in common objects, classes, subassemblies, and frameworks
• Sources of domain knowledge:
  • Technical literature
  • Existing applications
  • Customer surveys and expert advice
  • Current/future requirements
• Outcome:
  • Class taxonomies
  • Reuse standards
  • Functional and behavioral models
  • Domain languages

Set of Models

• Flow-oriented modeling indicates transformation of data objects by functions.
• Scenario-based modeling represents the system from the user's point of view.
• Class-based modeling defines objects, attributes, and relationships.
• Behavioral modeling depicts the states of the classes and the impact of events on these states.

Elements of the Analysis Model

• Scenario-based elements.
  • Use-case diagrams
  • Use case-text
  • Activity Diagrams
  • Swim lane diagrams
• Flow-oriented elements.
  • Data-flow diagrams
  • Control flow diagrams
  • Processing narratives
• Class-based elements.
  • Class diagrams
  • Analysis Packages
  • CRC Models
  • Collaboration diagrams
  • ER Diagrams
• Behavioral elements.
  • State diagrams
  • Sequence diagrams
• Scenario-based elements focuses on a high level of the system from the user or a functional perspective.
• How information flows throughout the system is the focus of flow-oriented elements: data and control flow.
• Behavioral elements respond to the systems external events and models the internal behavior.
• Class-based elements focuses on a static view of the system and relating the different parts, with object-oriented development.

Analysis Modeling Approaches

• The definition of classes is the focus of Object-oriented analysis (UML).
  • Classes collaborate with inter-relationships.
  • Predominantly object-oriented
• Considers data and the processes that transform the data as separate entities in a structured analysis.
• Data is modeled with only attributes and relationships (but no operations).
  • The processes will transform the data to show input data, transformations on the data and resulting output.

Object-Oriented, UML-based Analysis Model (Bruegge and Dutoit, 2000)

• Includes:
  • Operation's pre-and post-conditions
  • Class invariants

Analysis Model (alternative to Object-Oriented, UML-based)

• Focus of Structured Analysis.
  • Considers separately.
• Attributes and relationships are used to models.
• Transformations between data models.
• Analysis model does not focus on a type.
  • can be applied and used to OO or structured design

Structural Analysis

• The essential model is the element of a structural analysis.
• Contains environmental and behavioral models.

Structured Analysis: Essential Model

• The model describes what the system must do.
• Defines what how the system will achieve its goals
• Model is combined from behavioral and environmental model.

Structured Analysis : Environmental Model

• Defines the scope of the proposed system.
• Defines the boundary and interaction between the system and the outside world.
• Contains:
  • Statement of Purpose,
  • Context Diagram, and
  • Event List.

Structured Analysis : Behavioral Model

• Behavioral analysis models the system's internal behaviour and data entities.
• Functional requirements are modelled.
• Consists of
  • Data Dictionary
  • Data Flow Dlagram
  • Entity Relationship Diagram
  • Process Specification, and State Transition Diagram.

Structured Analysis : Environmental Model

• Contains a statement of purpose.
• Contain text diagrams.
• An event list.

Statement of Purpose

• Clear and concise textual description
• For top level management, user management, and others not directly in the system.

System-Context Diagram (SCD)

• Context Diagrams are used to define a system's or component's boundary with external entities, shown as high-level systems similar to block diagrams.
• SCDs are graphical system models describing the most abstract system view.
• System boundary and scope as well as interacting people, organizations, and systems are defined.
• Includes logical data flows, non-physical. System Context Diagram (SCD)
• Used early to agree on scope.
• Written plainly for all project stakeholders.

System Context Diagram (SCD)

• Two building blocks:
  • Entities (Actors)
  • labeled boxes in the center, representing the system. Also around it, multiple boxes for actors.
  • Relationships: labeled lines between the entities.

Yourdon and Coad Notation

• Includes the terminator on where the datastore is located.

SCD Elements: Single Bubble

• Represents system as a whole, hiding local processing / internal details and stores.
• Has a general name. such as a company and department

SCD Elements: Data Flow

• Normally flows are IN and OUT of the system.
• Data flow describes data/information passing between system (single bubble) and terminators.
• Connects single bubble to terminators and connects terminators to shared stores.
  • Shared stores become part of system boundary
• Data flow labels: data item, collection of data items, record,

SCD Elements: Terminator (entity)

• Person, organization, another system interacting with the information system.
• Always connected to single bubble and shared store.
• Name them with singular noun describing role: customer, manager.
• There are no terminators.

SCD Elements: Data Store

• Shows databases/files
• Internal are not shown but shared are.
• Shared stores part of IS boundary.
• Name then by plural nouns (eg. Sales)
• They don't communicate directly, passive.

Boundary and Scope

• System Boundary: Number of terminators and shared stores.
  • Modify it adding or deleting and adding a shared store.
• System Scope: Number of lines connected. -Can be modified by adding or deleting lines connecting to share stores or terminators.

Steps to Draw a Context Diagram

• List activity
• Draw system bubble
• Identify external data stores
• Recognize all details of the store.

Practical Exercise: University Enrollment System

• A student sends an application form containing his personal and desired course.
• The university checks the course availability.
• If the course is available, the student is registered, and the university confirms the enrollment by sending a confirmation letter.
• If the course is unavailable or the student is not registered/ the university sends a rejection letter.

Event List

• A narrative list of "stimuli" in the outside world.
• Time/place events which should be remembered by target system.
• IS must prep responses to what occurs.
• Respond only to some events and functions.

Types of Events: F-Type

• Flow-oriented events (F-Type)
  • Initiated & triggered by terminator
  • Associated with data sent by terminator to IS
  • External, the system makes respond aware of them. -Triggered by the environment with data sent to IS -One response

Types of Events: T-Type

• Occurs at a point of time.
  • Daily
• Acts based on the clock
  • Time pre programmed
• Is an outgoing flow

Events Table

• Outlines everything about how the diagrammed actions occur.
• The Event is whatever initiates the action.
• The Trigger describes what starts the Event.
• The Source is whoever is doing the action
• The Activity describes the outcome of the action
• Lists if its temporal or a response action.

F-Event and ERF

• Is every incoming flow an F-Type?
  • No, can be flows related.
• Long break between events create separate.
• Short pause causes the second event to require to “"ERF” and is not listed on Event Table"

Structured Analysis : Behavioral Model

• Data Dictionary
• Data Flow Diagram
• Entity Relationship Diagram
• Process Specification, and State Transition Diagram.

Data Flow Diagram(DFD)

• Proposed by Larry Constantine of structured design based on Martin and Estrin's "Graph Model" of computation.
• Became a popular way to visualize the major steps and data in software system processes.
• Used to show the process of modeling data.
• Useful to documentation.

DFD

• A Data Flow Diagram models "flow" of data, process aspects. and information through a system.
• Used as prelinary to overview or used to for data processing for structured design.

Data Flow Diagram

• Shows what information is to and from system
• Shows timing / information

Why DFDs

• View systems as networks of data transformation.
• Show systems functional model
• SSAD uses organize for it.

Applications

• Used in business analysis in for finding inefficiencies using processes.
• To visualizing things.

Data Flow Diagram

• Is a structured analysis technique for creating a graphical representation of data flow.
• Is series of steps and decisions
• Shows input proccessed put, stored

DFD Consists of:

1. Sources (originator of data)
2. Processes
3. Data stores (e.g. file or database)
4. Sinks (consumer of data)
5. Data Flow (arrow)

A Process

• Transformation of data is placed here
• Input and give an output
• Processes needs: Name, Number, Description
• Represented by rounded rectangle

Examples

• Used to show look if you are able to have

Process Modeling

• May be of two types can be use
  • Logic
  • physical

Description

• Writing method for specs
• Combines methods.
• Logic for steps.
• Good for loops.

Description

• To if a customer then proceed to next step
• While adding to check what being.

A process with description

• Logic description of the process.

Processes Rules:

• More has than one out/Input
• Needs to be followed by all functions.

Data Flow

• Must be followed with data
• has names /description

DFD Consists of:

• Most can be found using data flow

Data Store

• Data put away long time
• Named with an ID and description
• Used for data

External Entity (Source of Sink)

• Connects to the system that takes/sends out
• Can be used multi
• Has name and name details

Types

• Rules connect
• Processes to processes

Data Flow

• Some incorrect ones exist , use all the connection for DFD.

Evaluation

• If is correct that should be followed through each step.

Levels

• Each need to start with data, all DFD.

Building

List 1 data and major functions system processes Identify which process produce data and which process require data production from external identities.

Evaluation

• Name and description
• Follow these details as name
• Number must be follow 10

Rules summary and validation

• DFDs must be valid based on the Context Diagram, Decomposition, and Balance

Types

• Errors can be committed in making
• Evaluation of DFD can can improve process

Validating evaluation

• Evaluation is done as you look for details and issues.

<