ECE 355, W07 Software Engineering Instructor Sagar Naik Handouts: 1

1
ECE 355, W07 Software EngineeringInstructorSa
gar NaikHandouts 1
2
About the Instructor

• Teaching Interest
• ECE 355
• ECE 453 (Testing and QA SE Option and SE
  program)
• ECE 428 (Computer Networks and Security)
• ECE 454 (Distributed and Network Centric
  Computing)
• ECE 750 (Mobile Communication and Computing)
• Research Interest
• Network Protocols
• Wireless, Sensor, and Peer-to-Peer Networks
• Energy Efficient Protocols and Applications

3
Welcome

• Get a glimpse of what SE in industry is all about
• SE course characteristics
• Non-algorithmic and non-mathematical
• Largely consisting of
• Principles (abstraction, rigorousness, )
• Processes (how to do)
• Techniques and Methods
• Demanding and challenging, but a rewarding course

4
Software Engineering

• SE is a collection of techniques, methodologies
  and tools that help with the production of
• a high quality software system
• with a given budget
• before a given deadline
• while change occurs.

5
Goals of this course

• Become familiar with SE concepts
• Learn about
• Requirements and Analysis
• Kinds of requirements, how to gather and specify
  
• Design Architectures, patterns, activities
• UML
• Process Models Ex. Waterfall, spiral, RUP, XP,
• Testing and Quality Assurance
• Experience SE in a larger project with several
  components

6
Marking Scheme

• Project 30
• Two deliverables
• Midterm 20
• Final 50

7
Project

• Project domain Voice-over-IP (Internet Protocol)
• You will
• Download source code Proxy location server,
  Communicator
• Understand the VoIP system ? Gain domain
  knowledge
• Add new functionalities to the system
• Your work
• Write a requirements specification ? Document 1
• Redesign the system ? Document 2
• Implement your design ? Demo
• Form groups of FOUR (after class)

8
Books and reading materials

• Object Oriented Software Engineering Using UML,
  Patterns and Java, 2nd edition B. Bruegge, A.
  Dutoit, Prentice Hall, 2004
• Mastering the Requirements Process, S. Robertson
  and J. Robertson, Addison-Wesley, 1999
• 250 slides

9
SE An activity to solve a real world problem
Real World Problem
The activities on the path???
printf(Hello)
10

The main activities in software development

Requirement Specification
Requirements Analysis
The idea
Design

Test

Implement
Hello World!
11
ECE 355, Fall 2006

• Software Requirements
• Sources
• Mastering the Requirements Process, S.
  Robertson and J. Robertson, Addison Wesley, 1999
• Software Engineering, R. Pressman, McGraw Hill,
  2001
• Handouts 1
• Prepared by Sagar Naik

12
You will learn about .

• What is a requirement
• Functional
• Non-functional
• Constraints
• Requirement Shell
• Trawling for Requirements
• Techniques, models (traditional, OO)
• Properties of Requirements
• Validation of Requirements

13
What is a requirement

• A requirement is something
• That the product must do (functional
  requirements)
• An action that the product must take to provide
  functionality
• Fundamental reason for the products existence
• Ex. The security system shall detect motion
• That the product must have (non-functional
  requirement)
• This is a property, or quality, that the product
  must have
• Critical to the products success
• Ex. The security system shall make a call in
  less than 0.25s
• Ex. The product shall use company colors and
  logo
• Note NFRs can be tied up with FRs, or they can
  exist separately
• A requirement exists because
• The type of the product demands it
• The client wants it

14
What is a requirement

• Constraints
• These are global requirements they apply to the
  entire product
• Examples
• Passengers on board an aircraft will use the
  product
• The product is for children ? Users are a
  constraint
• The product shall run on UNIX machines
• Note
• Constraints are determined early
• Constraints are used to gauge the correctness and
  appropriateness of the requirements

15
Requirement Template

• Product Constraints
• The purpose reason for building and the business
  advantage
• Customer other stakeholders people with an
  interest in the product
• Users of the product intended end-users, and how
  they affect usability
• Requirements Constraints limitations on the
  project, restrictions on the design
• Relevant facts Outside influences that make some
  difference to the product
• Assumptions that the developers are making
• Functional Requirements
• Non-functional Requirements

16
Requirement Template

• Functional Requirements
• The scope of the product Defines the product
  boundaries, and its connections to adjacent
  systems
• Functional and Data requirements Things the
  product must do and the data manipulated by the
  functions
• Non-functional Requirements
• Look and feel requirements appearance
• Usability requirements based on the intended
  users
• Performance requirements how fast, accurate,
  reliable, etc.
• Operational requirements operating environment
• Maintainability and portability requirements how
  changeable the product must be
• Security requirements security, confidentiality,
  integrity of the product
• Cultural and political requirement human factors
• Legal requirements conformance to applicable laws

17
Requirement Shell

• Individual requirements have a structure
• Each component contributes something to your
  knowledge
• Each component is necessary to understand the
  whole requirement
• The components are identified progressively
• The components are written informally in plain
  text
• Gives flexibility

18
Requirement Shell

• Components of a requirement
• Requirement ID Unique
• Requirement type
• Event/use case Origin of the requirement
• Description 1-sentence statement of the
  intention of the requirement
• Rationale Why is it considered important or
  necessary?
• Source Who raised this requirement?
• Fit criteria A quantification of the requirement
  used to determine whether the solution meets the
  requirement
• Customer satisfaction Measure of the desire to
  have the requirement
• Customer dissatisfaction Unhappiness if it is
  not implemented
• Dependencies Other requirements with a change
  effect
• Conflicts Requirements that contradict this one
• Supporting material pointer to supporting
  information
• History Origin and changes to the requirement

19
Trawling for Requirements

• Goal
• Extract precise information from the brains of
  the stakeholders users, clients, customers,
• Translate
• (Users words, own vision) ? potential
  specification

20
Trawling for Requirements

• Tools for extracting information
• Brainstorming
• Observe and learn their work
• Question what they are doing, why they are doing
  it
• Build models to understand the system
• Properties of requirements
• Validation of requirements

21
Trawling for Requirements

• Brainstorming
• Participants should come from a wide range of
  disciplines
• ATM example Banking, marketing, security,
  software,
• Suspend judgment, evaluation, and criticism
  ?Think Big. Move Fast.
• Fast way to develop a creative and energized
  atmosphere
• Produce lots of ideas. Quantity will give us
  quality
• Come up with as many ideas as you can that are
• Unconventional, unique, crazy, wild,
• After brainstorming
• The lead requirements analyst (RA) and the client
  evaluate the ideas
• More practical ones, providing there is a
  reasonable chance of implementing them within the
  project constraints
• Some of the ideas may be merged to make a fully
  formed idea
• Explore the ideas further to turn them into
  requirements

22
Scenarios and How to Find Them

• Scenario
• A description of what people do and experience
• Types
• As-is Used in describing a current system
• Visionary Describe a future system
• Evaluation User tasks against which the system
  is evaluated
• Training Step-by-step instructions to guide a
  novice user
• Finding Scenarios
• Ask the following questions
• Primary task of the system?
• What data will the actor create, modify, or store
  in the system?
• Perform task observation see the user doing it
• Engage in Analyst ?? Client dialogue

23
System Modeling

• Traditional Approach
• A system is viewed as a collection of processes
• Processes interact with the outside world and
  with data elements
• Processes accept inputs and produces outputs
• Object-Oriented Approach
• A system is a collection of objects
• Objects interact with the outside world and with
  each other
• Objects send and respond to messages

24
Three views of the traditional approach

• Process/Functional
• Notation Data Flow Diagrams
• Purpose Give a graphical view of what is
  happening
• Elements External agents, processes, data
  stores, data flows
• Data
• Notation Entity-Relationship Diagram
• Purpose Describe things and their properties and
  relationships
• Elements Things, relationships, and properties
• Behavior
• Notation State-transition diagram
• Purpose Describe behavior as sequences of
  actions
• Elements States, inputs, outputs

25
Data Flow Diagrams

• Elements of a DFD
• External agents exist in the systems
  environment
• Produce and consume events and their attributes
• Examples
• People, hardware, network, other software, DB
• Processes help us in identifying what the system
  does
• Processes have different levels of abstraction
• Processes can be refined
• Data store in conceptual form
• Data flow denote input/output relationship

26
DFD Different levels of abstraction

• View the system at different levels of details
• Level 0 (Context diagram)
• Comprises a single process, all agents, and
  input/output data flows
• Purpose Identify and examine the external
  interfaces
• Guidelines for drawing Level 0
• Look for entities that give data to the system
• Look for entities that accept data from the
  system
• Identify the data elements at an abstract level
• Draw the diagram

27
Data Flow Diagram

• Example Home Security System (Context level)

Display
Display info
Control Panel
User commands and data
HomeSecurity Software
Alarm
Alarm type
Sensors
Sensor status
Telephone line
Tel. tones
28
DFD Level 1

• Show
• the system in more detail
• how data enter the system
• how these data items are transformed
• how they leave the system
• Preserve the and type of inputs and outputs
• Guidelines
• Try to identify potential processes 3-7
• Identify data flows anything that moves around
• Identify and list the data stores
• Draw the level 1 diagram

29
Data Flow Diagram

• Example Home Security System (Refined)

Configure System
Control Panel
Config. data
Configure request
Config. info
Interact with user
Config. data
User commands and data
Start/stop
Display
Display info
Activate/ Deactivate System
Display Msg Status
A/D msg
Password
Process Password
Alarm
Alarm type
Valid ID msg
Config. data
Telephone line
Sensors
Sensor status
Monitor sensors
Tel. tones
30
DFD Further Refinement

• Continue decomposing a DFD into finer details
  until the processes get so simple that you can
  describe them using
• Pseudocode
• Ex. IF water-sensor activated and sensor reports
  water THEN
• Activate alarm, call monitoring center, call
  owners mobile phone
• Decision table
• A tabular rep. of processing logic containing
• Decision variables, decision values, and actions

31
DFD Decision Table
32
Entity Relationship Diagrams

• Entities Things of interest (want/need)
• Ex. Owner, control panel, display, alarm,
  sensors, comm links
• Attributes Properties of entities
• Example
• Alarm -- type, numbers, manufacturer,
• Structure
• Atomic Cant decompose it (SIN)
• Compound Can expand it (Address)
• Multi-valued (hobbies)
• Derived (Date of Birth gt Age)
• Key Uniquely identifies a thing

33
Entity Relationship Diagrams

• Relationships Association between 2 entities
• Ex. Owner has subscribed to a monitoring service
• Cardinality
• 11 (wife-husband)
• 1N (mother-children)
• MN (grandparents-grandchildren)
• Participation
• Total Every child has a mother.
• Partial Not every person has a child.

34
ER Diagram

• Example

1
1
1
n
Wife
Husband
Mother
Children
4
m
Grand parent
Grand Children
Exactly one
Many (0)
1, 3-6
Optional (0/1)
Numerically specified
1
One or more
35
ER Diagram

• Example Home Security System

Homeowner
Control Panel
Monitoring Service
Security System
n
m
Sensor
Alarm
36
ER Diagram (Developing Relationships)

• Example Home Security System

Tests
Sensor
Security System
Programs
Enables/Disables
Monitors
37
ER Diagram (Developing Relationships)
User on Floor
F Button
Floor
Elevator
E Button
User in Elevator
38
ER Diagram (Developing Relationships)
pushes
User on Floor
F Button
requests
is placed on
is at
on
Elevator
Floor
moves to
becomes
specifies
desires
causes movement of
pushes
E Button
User in Elevator
39
Finite State Machines
push
Off
On
push
Switch
Garage Door
push
Closed
Open
i (internal)
DO1
40
Finite State Machines
push
Garage Door
Closed
Open
i (internal)
push
DO2
Opening
i
push
push
Closed
Open
push
i
i
Closing
41
Properties of Requirements

• Unambiguous Meaning is clear
• Consistent One must not contradict another
• Complete
• Ex. The authorization process terminates if the
  wrong PIN has been entered more than a certain
  number of times. ? How many?
• Verifiable (Testable)
• The system should work in real-time mode. ? How
  to verify?
• Free of implementation bias
• Specification (what) vs. solution (how)
• The system shall accept a password when data is
  accessed ? solution
• The system authenticates users before they access
  data ? spec.

42
Requirements Validation

• Validation criteria
• Correctness Requirement represents clients view
• Completeness
• All possible scenarios in which the system can be
  used (exceptions)
• Consistency Requirements do not contradict
• Realism Requirements can be implemented and
  delivered
• Traceability Each system function can be traced
  to some reqs.
• Difficulties in validation
• Requirements change very fast during elicitation
• Tool support
• Store requirements in a shared repository
• Provide multi-user access
• Provide traceability throughout the project
  lifecycle

43
Ambiguous Requirement(Information from a real
document)

• 4. Graduation Requirement
• A minimum grade of 65 is required to pass a
  course and the student must maintain a minimum
  cumulative average of 70 marks, all through, to
  remain in the Program.

44
Inconsistent Requirement(Information from a real
document)
5. TUITION FEES (2007)
Constraint One must take 8 courses to graduate.
Full Time (max 3 courses/ term)
Canadian and Permanent Resident International
(Visa)