tcss 360 spring 2005 lecture notes l.
Skip this Video
Loading SlideShow in 5 Seconds..
TCSS 360, Spring 2005 Lecture Notes PowerPoint Presentation
Download Presentation
TCSS 360, Spring 2005 Lecture Notes

Loading in 2 Seconds...

play fullscreen
1 / 30

TCSS 360, Spring 2005 Lecture Notes - PowerPoint PPT Presentation

  • Uploaded on

TCSS 360, Spring 2005 Lecture Notes. Requirements Analysis Relevant Reading: Software Requirements: A Tutorial Stuart Faulk. Software requirements. requirements : specify what to build tell "what" and not "how" tell the system design, not the software design

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

TCSS 360, Spring 2005 Lecture Notes

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
tcss 360 spring 2005 lecture notes

TCSS 360, Spring 2005Lecture Notes

Requirements Analysis

Relevant Reading:

Software Requirements: A TutorialStuart Faulk

software requirements
Software requirements
  • requirements: specify what to build
    • tell "what" and not "how"
    • tell the system design, not the software design
    • tell the problem, not the solution (in detail)
  • What are some goals of doing requirements?
  • understand precisely what is required of the software
  • communicate this understanding precisely to all development parties
  • control production to ensure that system meets specs (including changes)
requirements abstraction
Requirements abstraction

"If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization's needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system."

software lifecycle review
Software lifecycle, review
  • The software lifecycle (Faulk's view):

requirements -> system testing -> deployment -> maintenance

| ^

| |

+- preliminary design -> integration testing

| ^

| |

+- detailed design -> unit testing

| ^

| |

+- coding ----------+

requirement roles to people
Requirement roles to people
  • roles of requirements
    • customers: show what should be delivered; contractual base
    • managers: a scheduling / progess indicator
    • designers: provide a spec to design
    • coders: list a range of acceptable implementations / output
    • QA / testers: provide a basis for testing, validation, and verification
a sample requirement
A sample requirement
  • requirement documents do not have a unified format, but generally the reqs are numbered and listed categorically, like this:
requirement doc examples
Requirement doc examples
  • Let's look at some SRS documents that we can scrape from the web. It's easy to find them on Google by searching for things like:requirements document filetype:doc
classifying requirements
Classifying requirements
  • Faulk doesn't like the normal way to classify requirements, which is the following:
    • functional: map inputs to outputs
    • nonfunctional: other constraints
      • performance, dependability, reusability, safety
  • How does Faulk prefer to classify them?
  • behavioral: everything about implementation
    • features, performance, security
    • can be objectively observed / measured
  • development quality attributes: things about internal construction
    • flexibility, maintainability, reusability
    • subjective, relative; who says what design is more maintainable?
functional requirements
Functional requirements
  • Examples of functional requirements:
    • The user shall be able to search either all of the initial set of databases or select a subset from it.
    • The system shall provide appropriate viewers for the user to read documents in the document store.
    • Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.
non functional requirements
Non-functional requirements
  • Examples of non-functional requirements:
    • It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard ASCII character set.
    • The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.
    • The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.
requirements example
Requirements example
  • What are some behavioral and development quality requirements in the following text?
    • We will implement our bank teller ATM software in Java. It should handle cash withdrawals and deposits in under 5 seconds wait time. It should be done in such a way that we can adapt it to our other types of ATMs and machines for our bank. We will use encrypted network connections to avoid hackers spying on users' account information.
  • behavioral: use Java, 5 sec transaction, encryption
  • dev. quality attributes: adaptable to other machines
some requirement measures




Processed transactions/second

User/Event response time

Screen refresh time


K Bytes

Number of RAM chips

Ease of use

Training time

Number of help frames


Mean time to failure

Probability of unavailability

Rate of failure occurrence



Time to restart after failure

Percentage of events causing failure

Probability of data corruption on failure


Percentage of target dependent statements

Number of target systems

Some requirement measures
essential difficulties
Essential difficulties
  • What does "essential" difficulty mean?
  • What are some of the essential difficulties?
    • comprehension: people don't know what they want
    • communication: hard to specify clearly what is wanted
    • control: can't see which requirements will dominate schedule
    • inseparable concerns: can't divide up problem, or freeze from change
    • must compromise on divide-and-conquer, and make tough trade-offs
  • something that is hard about reqs, by nature
accidental difficulties
Accidental difficulties
  • What does "accidental" difficulty mean?
  • What are some of the accidental difficulties?
    • written as an afterthought: devs write requirements after coding, instead of at beginning
    • confused in purpose: has too much marketing info, too imprecise (to let the customer change it later), or has too much design/implementation info in it
    • not designed to be useful: no time or thought put in; makes requirements poor and useless
    • lacks essential properties: incomplete
  • something made difficult by writing reqs poorly
faulk s requirements approach
Faulk's requirements approach
  • requirements approach defines:
    • process: activities, entrance/exit criteria, people to do work
    • products: the tangible products to produce, and their details
  • requirements phase
    • problem analysis: describe the problem situation
    • requirements specification: create SRS(Software Requirements Specification) document
problem analysis basic issues
Problem analysis, basic issues
  • This phase describes the problem that must be solved by the software we will produce
  • elicit requirements from customer
    • how might this be done?
  • decompose problem into pieces
  • organize info, communicate to involved parties
  • resolve conflicting needs
    • what is an example of some conflicting needs?
  • know when to stop
semantic packaging properties
Semantic/packaging properties
  • Faulk says that a well-written SRS document should have the following semantic properties (qualities of its content):
    • complete, precise, unambiguous, consistent
    • implementation-independent
    • verifiable: it can be shown whether or not a given implementation meets spec
  • Faulk also recommends pleasant packaging:
    • modifiable, readable, ready for reference/review
state of the practice
"State of the practice"
  • Faulk notes several trends in requirements that have been used over the years:
    • functional decomposition
    • structured analysis
    • operational specification
    • object-oriented analysis
    • software cost reduction
  • Let's discuss each of these in detail.
functional decomposition
Functional decomposition
  • What is functional decomposition?
  • What are some advantages and disadvantages of functional decomposition?
  • specifying what the software is supposed to do
  • mapping from inputs to outputs
  • proceeding top-down, dividing each function into subfunctions

+ close to the code; developers like it

- forces design/code decisions too early; inflexible

example functional decomp
Example functional decomp.
  • A functional decomposition requirement might look like this:
structured analysis
Structured analysis
  • What is structured analysis?
  • What are some advantages and disadvantages of structural analysis?
  • address accidental difficulties with a model of problems, and procedures for what to do
  • shifts to focus on the data being processed and the transformations made on that data (from MIS)
  • common artifact: data flow diagram (DFDs)

+ systematic, not ad-hoc

- hard to know where to divide data / transform; DFD is more about design

data flow diagram syntax
Data flow diagram syntax







Account #

& deposit



of data flow


Data type













Data store

operational specification
Operational specification
  • What is an operational specification?
  • What are some advantages and disadvantages of operational specifications?
  • a prototype; executable requirements written in some sort of formal language
  • a layer of abstraction to allow design decisions later

+ requirements lead directly to executable result

- does not always work, in practice; sometimes can't distinguish from programming the actual product!

object oriented analysis
Object-oriented analysis
  • What is object-oriented analysis?
  • What are some advantages and disadvantages of object-oriented analysis?
  • decomposing the problem into a set of interacting objects and classes
  • focuses on abstraction, decomposition, and real-world entities

+ more closely related to modern prog. languages

- can't represent everything as an object; tailors to a certain language; doesn't always lead to an SRS

software cost reduction
Software cost reduction
  • What is software cost reduction?
  • What are some advantages and disadvantages of software cost reduction?
  • used by Navy for aircraft flight system
  • S. Faulk worked on this; continues involvement with ongoing SCR work
  • Faulk now teaches at U. of Oregon Software Engineering program

+ saving money is good

- not well-documented; only used to rewrite existing code; done only by researchers, not programmers

trends and emerging tech
Trends and emerging tech.
  • domain specificity
    • most engineering disciplines have subdomains with different methodologies for each
  • practical formalisms
    • formal methods, slow to be adopted by industry
  • improved tool support
    • CASE: computer-aided system engineering
    • since SW Engr. is immature, tools haven't been able to be standard and specific (note: this hasn't changed much!)
  • integrated paradigms
    • the different requirement styles are becoming more similar over time (evolutionary)
    • government tools use formal semantics
requirements exercise
Requirements exercise
  • Let's sketch out some requirements for a bank ATM software program. This is the software that appears on the screen of the ATM and walks you through deposits and withdrawals.With a partner, come up with 4 requirements for such software, that you think are important. Try to be specific. Write them down and classify each as functional/non-functional or behavioral/development quality, to the best of your ability. Then we'll discuss them together.