synchronize for second week n.
Download
Skip this Video
Download Presentation
Synchronize for Second Week

Loading in 2 Seconds...

play fullscreen
1 / 17

Synchronize for Second Week - PowerPoint PPT Presentation


  • 79 Views
  • Uploaded on

Synchronize for Second Week. You have read: Chaos, Student Survival Guide Gause & Weinberg Ch. 1,2,3 Jackson on “Descriptions” and “Machines” Wiegers Ch. 1 Now go read: Gause & Weinberg Ch. 4, and Part II Wiegers Ch. 6, 7 Jackson on “Procrustes” “Rough Sketches”

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 'Synchronize for Second Week' - yasir-alford


Download Now 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
synchronize for second week
Synchronize for Second Week

You have read: Chaos, Student Survival Guide

Gause & Weinberg Ch. 1,2,3

Jackson on “Descriptions” and “Machines”

Wiegers Ch. 1

Now go read: Gause & Weinberg Ch. 4, and Part II

Wiegers Ch. 6, 7

Jackson on “Procrustes” “Rough Sketches”

“Application domain”

Prepare to meet with the client and develop a

“Vision and Scope” document

slide2

Requirements Analysis and Specification

informal statement of need for system

Problem Definition

natural language statement of what system is to provide

Requirements Definition

notational and/or formal description of a software system

Requirements Specification

why do requirements
Why do requirements?
  • Develop a contract between customer and developer
    • Enables both sides to be clear about what is to be done
  • Understand and specify requirements based on customer’s needs
    • Not on what the developer thinks the customer needs
  • Provide basis for definitive testing and verification
    • System is acceptable if its passes the “acceptance” test
goals for a requirements specification
Goals for a requirements specification
  • Identify the functional capabilities of the system
  • Identify desired responses to undesired events
  • Identify non-functional and environmental constraints to be satisfied
    • “My users will submit input in the form of Microsoft Word documents”
    • “It has to run on a ‘386 under Win 3.1!”
  • Avoid specifying “how” focus simply on “what”
    • but recall Michael Jackson’s thoughts about “machines”
  • Serve as a guide to the development team
desirable characteristics of a requirements specification
Abstract

one model, many realizations

Complete

to the extent required

Consistent

no contradictions

Unambiguous

concrete acceptance test

Precise

uniquely interpretable

Testable

Concise

no extraneous details

Feasible

realistic constraints

Even

consistent level of detail

Modifiable

living document

Reference Tool

readable by all stakeholders

No implementation bias

Desirable Characteristics of a Requirements Specification
common problems
Common Problems
  • Incompleteness
    • customer may be unavailable or inaccessible
    • customer asks for too little
    • customer doesn’t think of everything
    • the world changes
    • (sometimes incompleteness is okay (as long as its noted!))
  • Inconsistency
    • customer may be a group that disagrees
    • different people may negotiate different parts
  • Ambiguity
    • customer may be a group where noone sees the whole picture
    • difficult to spot ambiguity in large, complex applications
common problems 2
Common Problems - 2
  • Imprecision
    • customer may be a group with a different vocabulary
    • precision easiest in mature application areas (e.g. accounting)
    • precision difficult in new disciplines
  • Infeasibility
    • customer asks for too much
      • no conceivable algorithm
      • unrealistic requests
  • Unevenness
    • different sources of information
    • different people write different parts
    • different parts of specification are more difficult than others
basic techniques
Basic Techniques
  • Customer teaches; developer learns and organizes
    • Developer applies discipline to process and helps discover ambiguity, inconsistency, and incompleteness
  • Interviews, investigations, questionnaires
  • Develop glossaries to aid communication
  • Describe in a (semi-)formal notation
  • Hierarchical decomposition
  • System modeling
    • Dataflow diagrams, E-R Diagrams, Finite state machines, Petri nets, [UML diagrams]
informal requirements specification
Informal Requirements Specification
  • Typical method
    • useful first attempts during problem definition
  • Structured Natural Language
    • Extended, more detailed form of requirements definition
  • Advantage
    • Uses expressiveness and understandability of natural language
  • Problems
    • Inherent ambiguity of natural language
    • Requirements are not partitioned effectively by the language itself (difficult to find related requirements)
typical contents of a textual req spec check the many templates available
Description

restatement of problem definition

Functionality

“what” the system does

Data

“what” the system processes

Environment

“where” the system operates

Robustness

“what“ is expected of the system when an error occurs

Security

“who” has access to “what”

Safety

Can this system harm anyone

Performance

“what” constraints are placed on the system’s performance

Resources

“what” information/other systems is/are available to help the system accomplish its job

Typical contents of a textual Req. Spec. (check the many templates available!)
rapid prototyping
Rapid Prototyping
  • A means to understand and acquire requirements
  • Most often
    • a mockup of (some aspect of) a software product
      • serves as a communication device with the user
        • “I don’t know what I want, but I don’t want THAT!”
      • facilitates technical exploration
        • “Is this possible?”
      • aids the development and assessment of specifications
        • “I want that...”
rapid prototyping see schach pg 71

Rapid Prototype

Verify

Design

Verify

Implementation

Test

Rapid Prototyping - See Schach, pg. 71

Req. Change

Operations

Retirement

understanding user needs
Understanding user needs...
  • A prototype can help understand user needs
    • Is the proposed service/system adequate?
    • Is the user-interface usable?
    • Are the requirements complete?
    • Which alternative should we take?
      • e.g. present the user with multiple “throw-away” prototypes
rapid is key
“Rapid” is key!
  • The prototype must be constructed quickly!
    • Thus, inconsequential problems are minor as long as main aspect of the prototype functions correctly
  • A prototype should be designed to be rapidly changed
    • This supports iteration in the process
      • If the user doesn’t like it, incorporate the feedback and try again!
  • To support these requirements, fourth-generation languages or interpreted languages are often used to generate prototypes
rapid prototypes as specifications
Rapid Prototypes as specifications...
  • Instead of discarding the prototype, use it to serve as the specification
    • Saves time having to write a specification document!
  • Generally considered a bad idea...
    • because
      • a rapid prototype can’t serve as a legal contract
      • a rapid prototype does not make for good documentation
        • It can’t serve as a reference tool for maintenance, for example.
  • Prototypes should be used to elicit requirements and then discarded, next comes design...
rapid prototypes as the finished product
Rapid Prototypes as the finished product!
  • Also considered a bad idea...
    • Same problems as previous slide...
    • Plus
      • Its too easy to slip into the build-and-fix lifecycle!
training the client
Training the client...
  • Customer and/or users may confuse a prototype with the operational system
    • “Why do we have to wait so long for the system, didn’t you have it working three months ago?”
  • Customer may request more features than originally intended
    • “Hey that’s great! Can you add this...and this?”
  • Thus...client should be informed as to the purpose of the prototype and be aware of the position of requirements in the life-cycle...