Software Engineering

Table of Contents

Lecture 1: Syllabus/Class Info

  • CSE 361 Course Syllabus
  • Went over syllabus
  • process of engineering software is much different, involves collectinng requirements, developing specifications and the like

Lecture 2

  • Move to Architecture Hall 127
  • lifecycle/process models
    • abstract representations of the processes
    • provides management a way to avoid mangling
  • early process
    • informal requirements, process, product
    • assumes you know what’s going on
    • interaction with customer is at the start and end
    • limited interaction makes it difficult to correctly understand requirements in a timely manner
  • waterfall – linear
    • big design up front
    • first formalized as an example of a flawed model
    • phases
      1. requirements analysis and specification - what
      2. design and specification - how
      3. development and unit testing
      4. integration and system testing
      5. delivery and maintenance
    • Is simple, structured
    • emphasizes documentation
    • Add feedback, and it becomes more useful
  • reuse – assembled from existing components
    • phases
      1. requirements specification
      2. component analysis
      3. requirements modification
      4. system design with reuse
      5. developmentt and integration
      6. system validation
    • can save time and effort
    • builds on reliability
    • can lead to compromises
    • building with future reuse can slow effort
  • incremental – built in distinct increments
    • phases
      1. define outline requirements
      2. assign requirements to increments
      3. design architecture
      4. develop system increment
      5. validate increment
      6. itegrate increment
      7. validate system, if incomplete GOTO 4
    • user requirements are priorityized
    • once an increment is started, requirements are frozen
  • agile – incrementtal approach to an extreme
    • focus on small increments of functionality
    • teams of 5-10 spend 2-4 weeks per increment
    • needs a clear view of requirements and a sound architecture/design
    • uses validated principles
      • pair programming/reviews
      • revisiting/refactoring/iteration and refinements
      • test first
    • provides functionality quickly
    • fast response to changing requirements
    • early/frequent feedback
    • focuses on working software at the expense of documentation
    • development can get off track if customer is not clear about ultimate goals
    • future maintainability based on how well requirements/architecture can be expressed initially
  • formal model
    • based on transforamtion of mathematical spec through different represenations to an executable program
    • transformations are correctness-preserving – straightforward to show that the program conforms to its specification
    • phases
      1. requirements definition
      2. formal specification
      3. formal transformation
      4. integration and system testing

Lecture 4: Requirements Engineering

  • deciding what to build
  • defining real-world goals, functions of and constraints on software systems
  • effects that the client wishes to be brought about in the problem domain
  • what it needs to do
    • potential needs
      • what the problem is, not how to solve it
    • how software will meet the needs
    • how it will be used
    • how it will fit into the work environment
  • essential factor for ensuring sucess
    • resolves conflicts between stakeholders early
    • starts quality control and assurance early
  • there can be a significcant cost of fixing errors
    • error not found until delivery costs 10x as much to fix than if found during programming
    • requirement error 100x
  • benefits
    • fewer defects
    • reduced dev rework
    • fewer unnecessary features
    • reduced project cost and delay
    • improved system quality and custome satisfaction
  • issues
    • insufficient involment
      • customers not understanding importance
      • developers knowing what users want
    • ambiguous requirements – that can be interpreted in multiple ways
    • minimal specifications
    • gold plating - devs ading functions not in the required spec
    • overlooked classes of users
    • inaccurate planning
  • good specs
    • complete – no missing
    • consistent – no conflicts
    • verifiable – able to verify that res are met
    • traceable – linkable to design and code components
  • task
    • ident problem and scope
    • dev understanding of nneeds
      • who will use
      • why is current situation a problem
      • define erminology
    • characterize a good solution to the problem
      • functions to be provided
      • constraints to be met
  • requirements engineering
    • requirements development
      • elicitation
      • analysis
      • specification
      • validation
    • requirements management


  • most difficult, critical and error prone.
  • most communication-intensive
  • success key: collaborative partnership between customers and development team


  • problems of scope
    • boundary is ill-defined
    • unnecessary design info may be given
    • customers requesting features that are too expensive or that lie outside of intended scope
  • problems of understanding
    • users have incomplete understanding of needs
    • poor understanding of capablities and limitations
    • analysts have poor knowledge of problem domain
    • user and analyst speak differen languages
    • conflicting views of different users
  • problems of volatility
    • requirements that evolve over time


  • application domain understanding
    • adk is knowledeg of general area where the system is applied
    • system for the domain
  • problem understanding
    • the details of the specific problem
  • understanding needs and constraints of system stakeholders
    • understand in detail the specific needs of people who require system support
    • consult with them to discover goals


bg reading
  • sources of information
    • company docs, org charts, docs on systems, technical papers
  • advantages
    • understand the org before meeting people who work there
    • may find detailed requirements for current system
  • disadvantages
    • docs often do not match reality
  • requirements engineer or analyst discusses with different stakeholders to build an understanding of requireuments
  • predominant technique
  • types
    pre-defined questions
    no predefined agenda
  • advantages
    • collect a lot of info
    • can probe in depth
  • disadvantages
    • hard to analyze large amounts of qualitative data
    • hard to compare different respondents
  • tips
    • be prepared
    • take notes
    • don’t make them think
      • My time is more valuable than yours.
      • I don’t know what I’m doing.
      • You don’t know what you’re talking about.
    • be intelligible
    • be receptive
  • questions to ask
    • problem to be addressed
    • process to dev solution
      • who is paying?
      • what are the underlying reasons for wanting a system?
      • what is trade-off between delivery date and cost?
    • elicitation itself
      • do my questions seem relevant?
      • are your answers official?
      • is there anything else I should be asking?
      • is there anything you would like to ask me?
  • Construct and admin a survey
  • advantages
    • can collect info from lots of people quickly
    • can be admined remotely
  • disadvantages
    • simplistic questionns can provide very little context
  • be careful of
    • sample size
    • sample selection method
    • ambiguous questions
  • a pilot run of a questionnaire can help eliminate bugs
  • more natural interaction than formal interviews
  • can increase number of ideas
  • relatively short, intense sessions seem to be most productive
  • selection of personnel is critical
  • don’t allow criticism or debate
  • idea reduction
    • prune ideas that aren’t worthy of further discussion
    • group similar ideas into super topics
  • prioritize remaining ideas
  • used for summarization and feedback
    • to discuss results of info gathering stage
    • to conclude on a set of requirements
  • important manegerial tool
task observation
  • advantages
    • can solve the documented v actual problem
    • reveals details other techniques cannot
  • disadvantages
    • can be time consuming
    • subjective
  • variant of observation
  • people often cannot describe what they do as it’s natural to them, observing them is a very good way to understand work
  • technique from social sciences, valuable for understanding actual work processes
  • actual processes often differ from formal processes
  • ethnographers spend some time observing people at work and building up a picture of how they’re done
  • expensive, may be only useful for extremely large, complex and critical systems
  • more on this one later

which techniques to use in project

  • can use any, depends on the project itself

Lecture 5: Requirements Engineering, Continued


  • discover problem,s incompleteness and inconsistencies
  • fed back to stakeholders to resolve them through the negotiation process
  • analysis is interleaved with elicitation as problems are discovered
  • a checklist may be used, each requirement may be assesed against the requirements


  • premature design
    • premature design/implementation details
  • combined requirements
    • can requirements be broken down?
  • unnecessary requirements
    • is it gold-plating?
  • use of non-standard hardware
    • must know platform requirements
  • conformance with business goals
    • consistent with business goals
  • ambiguity
    • can it be understood differently
  • realism
    • does it make sense given the technology
  • testability and verifiability


  • the invention and definition of a hebavior of a solution system such that it will produce the required effects in the problem domian
  • statement of agreement between producer and consumer of a service
  • may have aspects such as
    • requirements
    • features
    • performance characteristis
    • architecture
    • internal and external behavior of modules

requirements specs

  • statement of user requirements
  • major failures occur through misunderstandings between the producer and the user
  • should have the following qualities
    • consistent
      • shouldn’t be contradictory
      • especially problematic when multiple types of requirements documents are used, nat lang for customers, semi-structured models for engineers
    • complete
      • internal completeness, should define any new concept or terminology that it uses
      • external completeness, must document all needed requirements
      • have a way to mark stuff as TBD
    • verifiable / traceable
      • make sure it’s possible to verify that requirements have been met
      • requirements can be linked to output directly
    • precise, clear and unambiguous
  • guidelines
    • find a standard format, use it for all requirements
    • use language in a consistent manner
    • use text highlighting to identify key parts of the requirements
    • avoid the use of jargon
    • label sections, subsections and requirements consistently
    • use white space liberally
    • use visual emphasis consistently
    • label and index all figures

IEEE standard

  • intro
    • purpose
    • scope
    • definitions, acronyms, abbreviations
    • reference documents
    • overview
  • overall description
    • present a high-level overview of product and environment, anticipated users, known contraints and dependencies
    • product perspective
    • product functions
    • user characteristics
    • constraints
    • assumptions and dependencies
  • specific requirements
    • main body
    • contains
      • interface, external
      • functional requirements
      • performance requirements
      • design constraints
      • softtware system attributes
      • other requirements
    • often organized by feature


  • can be used to help discover problems, and help develop specifications
  • often used for interfaces
  • most often mockups, rather than complete implementations
  • docs and ntraining may need to be provided
  • ask users to evaluate the prototype, particularly those who have different jobs
  • develop test scenarios, with careful planning to broadly cover the requirements
  • execute scenarios, have developers watch
  • document problems, use a form if possible
  • can detect
    • misunderstandings
    • missing services
    • confusing services
  • can be used in requirements analysis
  • prototype may serve as a basis for preparing a precise system spec
  • can lead users to think that system construction will be easier than anticipated
  • there may be temptation to morph the prototype into a final solution, don’t do it!
  • paper prototypes
    • similar to story boards
    • allows the reader to walk through an interface, seeing the different screens and layoutts.
    • use captions to explain what is shown

Date: 2017-08-08 Tue 14:32

Author: Samuel W. Flint

Created: 2017-08-30 Wed 14:13