Text Layout

1
Text Layout

• Introduction (1-4_
• Team Skill 1 Analyzing the problem (5-7)
• Team Skill 2 Understanding User and Stakeholder
  Needs (8-13)
• Team Skill 3 Defining the System (14-17)
• Team Skill 4 Managing Scope (18-19)
• Team Skill 5 Refining the System Definition (
  20-24)
• Team Skill 6 Building the Right System (25-31)

2

• From Use Cases to Implementation
• Chapter 25

3
Use Cases to Implementation

• For 40 years, we have built complex software
  systems
• Not all failures Internet, online trading,
  desktop productivity tools, lifesaving medical
  equipment, safe power plants, and communications
• Some systems conform to their requirements, but
  others that require a high degree of safety or
  reliability do not
• Requirements do not lend themselves to being
  exposed for inspection within implementation
• Proving that any particular requirement is
  fulfilled in the code is a nontrivial matter

4
Mapping Requirements to Design and Code

• Trace requirements to Design Code modules
• Test modules for requirement satisfaction
• Some traces are straight-forward and easy to do
• Support up to an eight-digit floating-point
  parameter
• Indicate compilation progress to the user

Requirement
v
Design Progress Monitor ID header
Implementation
Progress1 True ElseIf (WminSc ltgt WMAXSc)
Then ProgressBar1.Max WMaxSc
5
The Orthogonality Problem

• There is little correlation between the
  requirement, the design, and the implementation,
  they are orthogonal
• The form of our requirements and the form of our
  design and implementation are different
• There is no one-to-one mapping to make
  implementation and verification easier
• Requirements speak in real-world terms, code
  speaks in stacks, queues, and algorithms
• Some requirements, performance, have little to do
  with the logical structure of the code, but a lot
  to do with the process structure
• Some functional requirements require that a
  number of system elements interact to achieve the
  functionality
• Most importantly, good system design is not
  driven optimizing the ease of proving requirement
  satisfaction

6
Object Orientation

• Applying OO concepts, we build code entities that
  are a better match to the problem domain, and
  this improved the mapping
• People still get paychecks today, but they may be
  electronically
• With OO, we started to find paycheck objects
• However, requirements are still functional in
  nature, not object oriented, so some degree of
  orthogonality will still exist

7
Use Case as a Requirement

• Use cases provide a sequence of actions between
  the system and the user
• This improves the mapping significantly
• Now the requirements do a better job of providing
  the behavior of the system in a sequential
  fashion
• Using OO and use cases increase the parallels
  between requirements and code
• A better understanding of the requirements should
  help to drive a better design

8
Modeling Software System

• Modeling aids in our understanding and
  communicating that understanding of the system
• Purpose to simplify the details down to an
  understandable essence but not to oversimplify
  to the point that the model does not adequately
  represent the system
• Model is a powerful way to reason about a complex
  problem and to derive useful thought
• The Model is not reality it must evolve
• Many different aspects of the system can be
  modeled
• Application concurrency
• Logical structure
• Process structure

9
Architecture of Software Systems

• Shaw and Garlan definition
• Description of elements from which systems are
  built, interactions amongst those elements,
  patterns that guide their composition, and
  constraints on those patterns
• Components and connectors
• According to Krutchen, we use architecture to
• Understand what the system does
• Understand how the system works
• Think and work on pieces of the system
• Extend the system
• Reuse part(s) of the system to build another one
• 41 View of Architecture
• Logical View, Implementation View, Process View,
  and Deployment View are all tied together with
  the Use-case View

10
HOLIS Use-Case Initiate Emergency Sequence
Impacts the design in all four views

• Feature The system has a built-in security
  feature that provides a one-button, panic alarm
  emergency sequence activation from any control
  switch in the house. The security sequence sets
  the lights to a predetermined scene setting and
  will also flash the lights, activate an alarm,
  make a dial-up call, and deliver a voice-based
  message
• Logical view would describe the various classes
  and subsystems that implement the behaviors
  called for by the emergency sequence
  functionality
• Implementation view would describe the various
  code artifacts for HOLIS, including source and
  executable files
• Process view would demonstrate how the
  multitasking capability of HOLIS was always
  available to initiate an emergency sequence
• Deployment view would show that we distrubuted
  the functionality of HOLIS across the 3 HOLIS
  nodes or subsystems Control Switch, Central
  Control Unit, and Homeowners PC

11
Use Case Driven Design

• Use cases are realized via collaborations
• Collaborations represents the way in which the
  use case is implemented in the design
• Societies of classes, interfaces, subsystems or
  other elements that cooperate to achieve some
  behavior
• We can trace from the requirements to the design

Emergency Messaging
Use case
Collaboration
trace
Participating classes
12
Structural and Behavioral Aspects of Collaboration

• Structure specifies the static structure of the
  system
• Classes
• Elements
• Interfaces
• Subsystems
• Behavioral specifies the dynamics of how the
  elements interact to accomplish the result
• Collaboration is not a physical thing
• Collaboration is a description of how cooperating
  elements of the system work together

13
Class Diagram for HOLIS Emergency Message
Sequence Collaboration
Notification Agent Sender Received sendMessage()
IRemote
1



Message ID Header Body
Queue addMessage() removeMessage() Count()
14
Sequence Diagram for the HOLIS Emergency Message
Sequence
Message
OutgoingQueue
NotificationAgent
create
addMessage
removeMessage
15
Using Collaborations to Realize Sets of
Individual Requirements

• Just as we traced use cases to collaboration, we
  can also trace requirement statements

• Requirements
• The system shall
• Every 24 hours
• Synchronization occurs

Collaboration
trace
Participating classes
16
Key Points

• Some requirements map well from design to
  implementation in code
• Other requirements have little correlation to
  design and implementation the form of the
  requirements differs from the form of the design
  and implementation (the problem of orthogonality)
• Object orientation and use cases can help
  alleviate the problem of orthogonality
• Use cases drive design by allowing all
  stakeholders to examine the proposed system
  implementation against a backdrop of system uses
  and requirements
• Good system design is not necessarily optimized
  to make it easy to see how and where the
  requirements are implemented

17

• From Use Cases to Test Cases
• Chapter 26

18
Common Testing Terms

• Test Plan contains information about the
  purpose and goals of testing within the project,
  and identifies the test strategy
• Test Case set of test inputs, execution
  conditions, and expect results developed for a
  particular objective
• Test Procedure set of detailed instructions for
  the setup, execution, and evaluation of results
  for a test case
• Test Script software script that automates the
  execution of a test procedure
• Test Coverage defines the degree to which a
  given test or set of test addresses all specific
  test cases
• Test Item a build that is an object of testing
• Test Results data captured during the execution
  of a test

19
Role of Test Cases

• Constitute the bulk of the testing activity
• The quality and thoroughness with which they are
  designed determine the quality of the final
  result
• Test cases form the foundation on which to design
  and develop test procedures
• The depth of the testing is proportional to the
  number of test cases
• The scale of the test effort is proportional to
  the number of test cases
• Test design and development, and the resources
  needed, are largely governed by the required test
  cases
• Use cases serve directly as an input to this
  process

20
Use Case Scenarios

• A scenario, or instance of a use case, is a
  use-case execution wherein a specific user
  executes the use case in a specific way
• Think in terms of specific scenarios that occur
  for each use case
• Even with a limited number of use cases, a large
  number of specific scenarios must be tested

21
Deriving Test Cases From Use Cases

• Identify the use-case scenarios
• Not all scenarios may be described in the
  original use case
• For each scenario, identify one or more test
  cases
• Test case contains the parameters of the test,
  including the conditions and expected results
• For each test case, identify the conditions that
  will cause it to execute
• Complete the test case by adding data values
• Infinite combination, use boundary conditions

22
Key Points

• One of the greatest benefits of the use-case
  technique is that it builds a set of assets that
  can be used to drive the testing process
• Use cases can directly drive, or seed, the
  development of test cases
• The scenarios of a use case create templates for
  individual test cases
• Adding data values completes the test cases
• Testing nonfunctional requirements completes the
  testing process

23

• Tracing Requirements
• Chapter 27

24
Role of Traceability in Systems Development

• Experience has shown that tracing requirements is
  a significant factor in assuring quality
• It is also significant in analyzing the impacts
  of changes
• IEEE definition
• The degree to which a relationship can be
  established between two or more products of the
  development process, especially products having a
  predecessor-successor or master-subordinate
  relationship to one another (IEEE 610.12-1990 3)
• e.g. degree to which the requirements and
  design of a given software component match
• The degree to which each element in a software
  development product establishes its reason for
  existing (IEEE 610.12-1990 3)
• e.g. the degree to which each element in a
  bubble chart references the requirement it
  satisfies

25
Requirement to Requirement Traceability

• User Needs to Features
• Typically a one-to-many mapping
• Features to Use Cases
• Typically a many-to-many mapping
• Features to Supplementary Requirements
• Typically a many-to-many mapping
• Check that every element is traced to something
• This ensures that all needs and features are in
  the requirements
• This ensures that there is not a requirement not
  needed by the user gold plating

26
Requirement to Implementation Traceability

• Use cases to use-case realizations
  (collaborations)
• Typically a one-to-one mapping
• Use-case realizations to implementation
• Mapping collaborations to their parts, classes
• Supplementary requirements to implementation
• Trace individual requirements to a collaboration

• Requirements
• The system shall
• Every 24 hours
• Synchronization occurs

Collaboration
trace
Participating classes
27
Requirement to Testing Traceability

• Use case to scenario
• Typically a one-to-many mapping
• Scenario to test case
• Typically a one-to-many mapping
• Supplementary requirements to test cases
• Requirements traced individually to scenarios and
  test cases or grouped into packages

28
Key Points

• Requirements traceability is a proven technique
  that can increase the quality and reliability of
  software
• Traceability is mandated in certain
  high-assurance software development environments
• Traceability extends from user needs to product
  features to use cases and supplementary
  requirements, and from there to implementation
  and testing
• The value and cost of traceability varies with
  project context and available tooling

29

• Managing Change
• Chapter 28

30
Why Do Requirements Change

• External factors
• The problem changes regulations, economy,
  consumer preferences
• Users change their minds or perceptions on what
  they want identity of users change, perceptions
  of market change
• External environment changes ongoing
  improvements in hardware, Internet
• New system comes into existence behavior
  evolves around the new system, new types of
  information emerge, new interfaces

31
Why Do Requirements Change

• Internal factors
• Failed to ask the right questions at the right
  time to the right people
• Failed to create a practical change management
  process changes pile up and create pressure
  that leads to an explosion
• Iterating from requirements to design begets new
  requirements process of designing the system
  exposes new requirements

32
Requirements Leakage or Creep

• Unofficial changes creep into the system
• Enhancements mentioned by distributors who had
  been overheard by programmers at a sales
  convention
• Direct customer request to programmers
• Mistakes that had been made and shipped and had
  to be supported
• Hardware features that didnt get in or didnt
  work
• Knee-jerk change-of-scope reactions to
  competitors
• Functionality inserted by programmers with
  careful consideration of whats good for the
  customer
• Programmers Easter Eggs hidden behavior
  built into system for debugging

33
Process for Managing Change

• Recognize that change is in inevitable, and plan
  for it
• Good changes come from all sources
• Baseline the requirements
• Baseline for each iteration or release version
  control
• Publish the baseline for the team
• Once baselined, new requirements are more easily
  identified
• Establish a single channel to control change
• Change can cause unanticipated consequences
• Analyze impacts for budget, schedule and
  technical impacts
• Use a change control system to capture changes
• A needed change can turn into a feature 16
  character names
• Change control board (CCB)

34
Process for Managing Change

• Change control board (CCB) must consider the
  following
• The impact of the change on the cost and
  functionality of the system
• The impact of the change on customers and other
  external stakeholders not well represented on the
  CCB
• The potential for the change to destabilize the
  system
• When to implement the change
• CCB must notify everyone of the change
• Manage change hierarchically
• A change to one requirement can have a ripple
  effect in other related requirements
• Change the needs, then requirements, then design,
  then code, this helps manage the ripple effect
• A programmer never has the authority to introduce
  new features and requirements directly into the
  code, no matter how well intentioned

35
Requirements Configuration Management

• Benefits
• Prevents unauthorized and potentially destructive
  or frivolous changes
• Preserve the revisions to requirements documents
• Facilitates the retrieval and/or reconstruction
  of previous versions of documents
• Supports a managed, organized baseline release
  strategy for incremental improvements
• Prevents simultaneous update of documents or
  conflicting and uncoordinated updates to
  different documents at the same time
• Elements Impacted by Change
• Use traceability linkages to help identify impacts

36
Requirements Configuration Management

• Audit trail of change history
• Document why the change was made
• Configuration Management and Change Management
• Change history should exist at 3 levels
• Finest level of detail for all use cases and
  requirements
• At a middle level of detail for all project
  documents
• At the general level for the project
• Configuration management always means versioning
  of the software and checking out the code
• Configuration management is sometimes called
  change management when versioning the project
  documents like the requirements
• No matter what you call it, you should do both

37
Key Points

• A process to manage requirements can be useful
  only if it recognizes and addresses the issue of
  change
• Internal change factors include failing to ask
  the right people the right questions at the right
  time and failing to create a practical process to
  help manage changes to requirements
• In order to have a reasonable probability of
  success, requirements leakage must be stopped or
  at least reduced to a manageable level

38

• Assessing Requirements Quality in Iterative
  Development
• Chapter 29

39
Software Project Quality

• Definition by Rational
• The characteristic of having demonstrated the
  achievement of producing a product that meets or
  exceeds agreed-on requirementsas measured by
  agreed-on measure and criteriaand that is
  produced by an agreed-on process
• Additional aspects (besides requirements) include
• Time to market
• Budget adherence
• Scope of team
• Project
• Company investment
• Quality has two major dimensions
• End result of application
• Business impact on the producer and consumer

40
Quality Assessment Checklists

• Quality assessment checklists are very common
  practice
• Checklists can be used by independent auditors or
  the team itself
• Those conducting the assessment must take into
  account the level of specificity and completeness
  expected for that iteration
• Checklists are provided on pgs. 361-368

41
Key Points

• In iterative development, the primary quality
  check is the objective evidence provided by the
  availability and suitability of intermediate
  iterations
• Assessment of requirements process quality and
  requirements artifacts can also occur at these
  checkpoints
• Assessments must take into consideration the
  point in the lifecycle at which the assessment
  occurs
• Successive refinement, rather than absolute
  completeness or specificity, is the goal