Software Engineering I
Sept 16,2013

Requirements
  -Describe an aspect of what the proposed system must do, or
  -Constrain the system's development
  -Must contribute to the problem solution
  -Should be statements or facts
  -Should be agreed upon by stakeholders

Types of requirements
  -Functional
    +describe what the system should do
    +services provided for users and for other systems
    +includes
      1) everything the user needs to know about what the system does
      2) everything needed by any other system to interface with this one
      3) details about how the requirements are implemented are left out
    +What input should system accept?
      -Under what conditions
      -Include data and commands from other systems and users
    +Outputs - what and how produced
    +Data stored - especially what other systems might use
    +Computations performed at a level all readers can understand
      -don't usually specify algorithms
    +Timing and synchronization
      -especially important in Real-Time systems
      -Teleconference, powerplant, cars, planes, factories

  -Functional requirements examples
    Requirements for a microwave?
    In class assignment

    System - Keypad, door sensor, steam sensor, LCD, audio, microwave emitter,
             Fan, turntable, others?

    System Modes - idle, suspended, accepting input, cooking

    Inputs - defrost, reheat, regular cooking
             cook time
             clock setting
             power level

    Operations during those states

    Outputs - ?

  -Quality Requirements
    -usability, efficiency, reliability, maintainability, reusability
    -constrain the design
    -must be verifiable
    Includes
      Response time - time to calculate result
      Throughput - ops / second
      Resource usage
      Reliability including mean time to failure
      Availability - server uptime, very rigorous for telecommunications
      Recovery from failure - what happens when SW crashes?
      Allow for maintenance and enhancement
      Allow for reuse

  -Platform Requirements
    Which platform to use?
    Minimum system requirements?
    Technology to be used
  -Process requirements
    Development process or methodology to be used
    Cost and delivery date

Use Cases

  Use case analysis - systematic approach to what users should be able to do
    with your SW.

  1. Actors - types of users and other systems that will use this system
     (the one being created)

     Actor is a role some user/other system plays when interacting with your
     system.

     Users should be determined during domain analysis

  2. Look at (determine) all tasks each actor will need to do with a system
     Each task is a _use_case_

     A use case is a sequence of actions an actor performs to complete a given
     task.

  3. Use case model - set of use cases and descriptions/diagrams indicating how
     they are related.

Single Use Case

   Name - explains what action the user will do with the system and a number

   Actors - who can perform this use case

   Goals - what the actor is trying to do

   Preconditions - what needs to be true before starting the use case

   Summary of what occurs

   Related use cases (Generalization/specialization/extensions)

   Steps

   Post-conditions - system state after completing the use case

Example - Name - check out a book for a borrower

  Actors - Student, Faculty, Staff/Librarian

  Goal - help borrower get book from library to take home

  Preconditions - has library card or student/faculty ID card, no fines, item
    has valid barcode, not a reference book 

  Summary - go in library
            get book
            go to check out
            provide library card/ID
            book checked out

  Steps
  1. Scan barcode and card
  2. Confirm checkout is allowed
  3. Stamp item with due date
  4. Confirm loan is ok
  5. Display information and provide item to client

  Postcondition - have book
                  library has record of checkout

  Related - checkout interlibrary loan

  Use case diagrams may be completed in UML

Use case extensions, generalizations, and inclusions

  Extensions - optional interactions to handle explicit or exceptional cases

    Need to indicate extension point when changing the basic sequence of
    operations

  Generalization - example - open file vs. open specific file type

  Inclusion - express part of a use case to capture commonality between several
    use cases (shared sequence of actions).