Chapter 11 analysis concepts and principles
Download
1 / 25

Chapter 11 Analysis Concepts and Principles - PowerPoint PPT Presentation


  • 69 Views
  • Uploaded on

Chapter 11 Analysis Concepts and Principles. Introduction: What Are the Real Problems?. the customer has only a vague idea of what is. required. the developer is willing to proceed with the. "vague idea" on the assumption that "we'll fill in. the details as we go".

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Chapter 11 Analysis Concepts and Principles' - yukio


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Chapter 11 analysis concepts and principles
Chapter 11Analysis Concepts and Principles


Introduction what are the real problems
Introduction: What Are the Real Problems?

the customer has only a vague idea of what is

required

the developer is willing to proceed with the

"vague idea" on the assumption that "we'll fill in

the details as we go"

the customer keeps changing requirements

the developer is "ratcheted" by these changes,

making errors in specifications and development

and so it goes ...


Requirements analysis
Requirements Analysis

Requirements Analysis - is a software engineering task that bridges the gap between system level requirements engineering and software design



Requirements analysis1
Requirements Analysis design

  • Five areas of efforts

    • Problem recognition

    • Evaluation and synthesis

    • Modeling

    • Specification

    • Review


Techniques for requirements elicitation
Techniques for Requirements Elicitation design

1. Initiating the process – conduct a meeting or interview.

Some questions to ask by the analyst:

  • who is behind the request for this work

  • Who will use the solution

  • What will be the economic benefit of a successful solution?

  • Is there another source for the solution that you need?


Techniques for requirements elicitation1
…Techniques for Requirements Elicitation design

2. Facilitated Application Specification Techniques (FAST)

  • Meeting (often at neutral site)

  • Establish meeting rules

  • Agenda to cover important points

  • A facilitator -- best if not customer or supplier

  • Definition mechanism

  • Understand goal -- to identify problem, specify a preliminary set of requirements


Techniques for requirements elicitation2
…Techniques for Requirements Elicitation design

  • Facilitated Application Specification Techniques (FAST)


Techniques for requirements elicitation3
…Techniques for Requirements Elicitation design

3. Quality Function Deployment

  • Normal Requirements

    • What will make customer happy

  • Expected Requirements

    • Unstated requirements that are so “obvious” that they need not be stated

  • UnexpectedRequirements

    • Enhancements beyond customer requirements


Use cases
Use-Cases design

  • A collection of scenarios that describe the thread of usage of a system. Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way

  • Each scenario answers the following questions:

    • What are the main tasks of functions performed by the actor?

    • What system information will the actor acquire, produce or change?

    • Will the actor inform the system about environmental changes?

    • What information does the actor require of the system?

    • Does the actor wish to be informed about unexpected changes?


Analysis principles
Analysis Principles design

  • Operational principles

    • Represent and understand information domain

    • Define functions that must be performed

    • Represent behavior of software (to external events)

    • Partition information, function and behavior models hierarchically

    • Move from essential information to implementation detail


Guiding principles
Guiding Principles design

  • Understand problem before analysis

  • Develop prototypes for HCI

  • Record the origin of and the reason for every requirement

  • Use multiple views of requirement

  • Rank requirements

  • Eliminate ambiguity


Analysis principle i information domain
Analysis Principle I: designInformation Domain

  • Software processes data

    • Payroll processing

    • Computing control signals for radar system

  • Software also processes events

    • Timer went off -- time to calculate a control

    • Sensor turned on -- indicates intruder

    • Heart rate monitor exceeded threshold -- indicates fibrillation.


Information domain
…Information Domain design

  • Three views of information

    • Information content

    • Information flow

    • Information structure

  • Modeling

    • Functional Models

    • Behavioral Models


Analysis principle ii modeling
Analysis Principle II: designModeling

  • Functional Models

  • Behavioral Models


Analysis principle iii partitioning
Analysis Principle III: designPartitioning


Analysis principle iv essential and implementation view
Analysis Principle IV: designEssential and implementation view

The essential view of a software requirements presents the function to be accomplished and information to be processed without regard to the implementation details.


Prototyping
Prototyping design

Prototyping helps Clarify requirements, Identify missing requirements and Help define user interfaces.

1. Selecting the prototyping approach

  • Throwaway

  • Evolutionary -- a potential problem is that intended throwaways become evolutionary


Prototyping1
Prototyping design

  • Important questions underlying prototyping

    • Customer commitment -- must be involved

      • Must commit resources for evaluation

      • Must be capable of making requirements decisions in timely manner


Prototyping2
designPrototyping

2. Methods and tools

  • Fourth Generation Techniques -- program application generators

  • Reusable Software Components -- build from existing components

  • Formal Specification and Prototyping Environments

    • Translate specifications into code


Specifications
Specifications design

  • Specification principles

  • Separate function from implementation

  • Develop a model

  • Establish the environment

  • Define how software interacts with environ.

  • Create Cognitive model -- how world sees it

  • Recognize specs as imperfect

  • Flexibility -- be amenable to change


2 representation
2. Representation design

  • Format and content relevant to problem

  • Information should be nested

    • Multiple layers or levels

  • Diagrams should be consistent in use

  • Representations should be revisable



Specification review
Specification Review design

  • Software requirements specification is conducted by both the software developer and the customer

  • Macroscopic Level

    • View from the top

    • Goals met ?

    • Alternatives explored ?

    • Customer satisfied ?

  • The specification becomes a “contract” for software development.


End design


ad