Transcript Lecture 2 - DePaul University

SE 430
Object Oriented Modeling
Dennis Mumaugh, Instructor
[email protected]
Office: CDM, Room 432
Office Hours: Thursday, 4:00 – 5:30
September 17, 2015
SE 430: Lecture 2
1 of 100
Administrivia
 Comments and feedback
 Class Participation:


Please feel free to ask questions during the lecture. Wave your hand,
etc.
Let me know you are listening: a nodding of a head, a frown, etc.
 Solutions will be posted shortly after they are due.
September 17, 2015
SE 430: Lecture 2
2 of 100
SE 430 – Class 2
Topic: Requirements





The Unified Process
Introduction
» Communicating Design: Problem Statement; “Vision”
Defining Requirements;
The Requirements Workflow
» Requirements Analysis;
» Business Rules;
Activity Diagrams
Reading:
Arlow & Neustadt: Ch’s 3 & 14
Articles on the Class Page and Reading List
September 17, 2015
SE 430: Lecture 2
3 of 100
The Domain
 The problem domain for the assignments and many of the
examples in the lecture is The PDQ Bach Museum of Art and
Music at the University of Southern North Dakota at Hoople.
 The project is to automate the Museum: tracking of
collections, membership, climate control, etc. and a Visitor
Education system.
 A description is on-line for the problem and some references
are given in the reading list.

See: The Museum Automation Project
September 17, 2015
SE 430: Lecture 2
4 of 100
Assignment 1
The Museum Automation Project
 Develop project description and requirements document
for the Visitor Information Subsystem



What is the Museum Automation Project?
What is the Visitor Information Subsystem (VIS)?
» It is more than just a hand-held device!
What is the scope of the VIS?
 Check on Google for:
mobile context-aware tour guide
 See class reading list page for references.
 Due September 24, 2015.
September 17, 2015
SE 430: Lecture 2
5 of 100
Thought for the Day
Whatever can possibly go wrong will.
— Murphy's Law
Events that are extremely improbable tend to occur at the most inopportune
time. [Or, The probability of an event is inversely proportional to its
desirability.]
— Gumperson's Law
September 17, 2015
SE 430: Lecture 2
6 of 100
Last Time
Topics:



Important Object-Oriented Concepts
Software Development Life Cycle
Object-Oriented Analysis & Design
September 17, 2015
SE 430: Lecture 2
7 of 100
The Unified Process
To be discussed more in lecture 10
September 17, 2015
SE 430: Lecture 2
8 of 100
The Unified Process
Iterative software development process derived from Booch,
Rumbaugh and Jacobsen's methodology
 Use-case based
 Risk-driven
 Client-driven
 Architecture-centric
September 17, 2015
SE 430: Lecture 2
9 of 100
Why the Unified Process?
 The Unified Process (UP) represents a mainstream approach for
software development across the spectrum of project scales
 The process is scalable: you need not use the entire framework of the
process for every project, only those that are effective
 It employs several software best practices: commercially-proven
approaches to software development

Example: Develop software iteratively
 The process is effective: it has been successfully employed on a large
population of projects, both in its specific (Rational—RUP) and core
forms
September 17, 2015
SE 430: Lecture 2
10 of 100
Features of Unified Process
 Combines effective elements of earlier O-O processes.
 Improves productivity through use of practical methods that
you’ve probably used already (but didn’t know it).
 Employs:
 Breadth-first rather than a depth-first approach.
 Iterative and incremental approach allows start of work
with incomplete, imperfect knowledge.
 Succession of architectural releases as on-going ‘proof
of concept.’
September 17, 2015
SE 430: Lecture 2
11 of 100
Use-case-driven
 What is a use case?



A prose representation of a sequence of actions
Actions are performed by one or more actors (human or non-human)
and the system itself
These actions lead to valuable results for one or more of the
actors—helping the actors to achieve their goals
 Use cases are expressed from the perspective of the users,
in natural language, and should be understandable by all
stakeholders
 Use-case-driven means the development team employs the
use cases from requirements gathering through code and
test
September 17, 2015
SE 430: Lecture 2
12 of 100
Architecture-centric
 Software architecture captures decisions about:
The overall structure of the software system
 The structural elements of the system and their interfaces
 The collaborations among these structural elements and
their expected behavior
 Architecture-centric: software architecture provides the
central point around which all other development evolves
 Provides a ‘big picture’ of the system
 Provides an organizational framework for development
 Facilitates reuse
 Provides a framework for evolving the system by
attending to modifiability qualities of the system
 Guides the prioritization and choice of use cases for
development

September 17, 2015
SE 430: Lecture 2
13 of 100
Iterative and incremental
 An iterative and incremental approach allows start of
development with incomplete, imperfect knowledge
 An iterative and incremental process is like solving a jigsaw
puzzle: neither top-down nor bottom-up but accretionary and
convergent
 Iterative and incremental the following advantages:






Logical progress toward a robust architecture
Effective management of changing requirements
Effective means to address changes in planning
Continuous integration
Early understanding of the system (‘Hello world!’ effect)
Ongoing risk assessment
September 17, 2015
SE 430: Lecture 2
14 of 100
Workflows
 Workflows define a set of activities that are performed
 Workflows cut across the phases, but with different levels of emphasis in
each phase
 The core workflows are:
 Requirements
 Analysis
 Design
 Implementation
 Test
September 17, 2015
SE 430: Lecture 2
15 of 100
The five core workflows
 Requirements





Develop and refine the problem definition
Identify stakeholder needs
Define system features to be considered
Define the system scope
Build the use-case model
 Analysis




Refine use-case model
Define the domain model
Define a candidate architecture (transitions to design)
Refine the architecture (transitions to design)
September 17, 2015
SE 430: Lecture 2
16 of 100
The five core workflows
 Design



Design the physical realizations of the use cases
Develop the design model
Develop the deployment model
 Implementation




Plan subsystem implementation
Implement components: classes, objects, etc.
Perform unit-level testing
Perform component and system integration
 Test


Build the test model: test cases and expected results
Plan, design, implement, execute, and evaluate tests
September 17, 2015
SE 430: Lecture 2
17 of 100
Artifacts, Workers, and Activities
 These three elements are part of each workflow
 An artifact is a piece of information that is used as input to,
changed by, or output from a process
 Examples include:





Models—use-case, domain, and design
Model elements—use case, domain class, design class
Diagrams and documents
Source code
Executable elements
September 17, 2015
SE 430: Lecture 2
18 of 100
Artifacts, Workers, and Activities
Workers (called roles in RUP 2001—a better name) define
the behavior and responsibilities of an individual or a team
 Examples: Architect, use-case engineer, component
engineer, system integrator
 Some important distinctions:



Workers participate in the development of the system
Actors are outside the system and have usage relationships with
the system
Stakeholders encompass both actors and workers, as well as
others involved with the project
September 17, 2015
SE 430: Lecture 2
19 of 100
Artifacts, Workers, and Activities
Activities are the tasks performed within a workflow
 Activities can describe a wide range of abstraction levels,
from high-level (‘construct domain model’) to low-level
(‘implement class’)
 Examples include:




Plan iteration
Find use cases and actors
Execute integration test
Review test results
September 17, 2015
SE 430: Lecture 2
20 of 100
Software best practices
1.
2.
3.
4.
5.
6.
Develop software iteratively
Manage requirements
Use component-based architectures
Visually model software
Continuously verify software quality
Control changes to software
September 17, 2015
SE 430: Lecture 2
21 of 100
Applying the requirements workflow
 For the next few classes, we will be concentrating on the requirements
workflow, which spans the inception and elaboration phases
 In this context, we will discuss:

Developing the system overview statement

Identifying stakeholders and understanding user goals

Building a feature list for the system

Building a system context description

Capturing high-level functional requirements via use cases
(upcoming lectures)

Identifying supplementary (non-functional) requirements

Building a glossary (technical dictionary)
September 17, 2015
SE 430: Lecture 2
22 of 100
This course
 Provides sequence of steps to take

Problem Statement and Requirements

Use cases

System Sequence Diagram

Conceptual Model (and CRC cards)

Robustness Diagrams

Operation Contracts

Collaboration/Communication/Interaction Diagrams

Use-case Realization and Design Scenarios

Class Diagram
September 17, 2015
SE 430: Lecture 2
23 of 100
UML
September 17, 2015
SE 430: Lecture 2
24 of 100
The Unified Modeling Language
 The UML is standard diagramming language to visualize the results
of analysis and design.
 Notation (the UML) is a simple, relatively trivial thing.
 Much more important: Skill in designing with objects.
 Learning UML notation does not help
 The UML is not
 a process or methodology
 object-oriented analysis and design
 guidelines for design
September 17, 2015
SE 430: Lecture 2
25 of 100
UML: What's Important?
Harmful is knowing
how to read and draw
UML diagrams, but
not being an expert in
design and patterns.
Important is object and
architectural design skills, not
UML diagrams, drawing, or
CASE tools.
September 17, 2015
SE 430: Lecture 2
26 of 100
Summary
 Software development processes are undergoing change –
new systems are emerging:


Iterative development
Agile methodologies such as Extreme Programming and Scrum
 The object oriented development process offers some
challenges


applying iterative and incremental development effectively
adding new requirements late in the development process
 The Unified Process (UP) is an attempt to merge competing
methodologies
 The Unified Modeling Language is an attempt to merge
competing notations.
September 17, 2015
SE 430: Lecture 2
27 of 100
Requirements
Requirements are the “what you want,” like when your kid
says, “I wanna pony.” Analysis is what you get, as in
“You're getting a tricycle.”
September 17, 2015
SE 430: Lecture 2
28 of 100
Requirements
“What the customer wanted.”
September 17, 2015
SE 430: Lecture 2
29 of 100
Requirements Analysis
As Marketing requested it.
September 17, 2015
SE 430: Lecture 2
30 of 100
Requirements Analysis
As Sales ordered it.
September 17, 2015
SE 430: Lecture 2
31 of 100
Requirements Analysis
As Engineering designed it.
September 17, 2015
SE 430: Lecture 2
32 of 100
Requirements Analysis
As Production manufactured it.
September 17, 2015
SE 430: Lecture 2
33 of 100
Requirements Analysis
As Maintenance installed it.
September 17, 2015
SE 430: Lecture 2
34 of 100
Requirements Analysis
What the customer wanted.
September 17, 2015
SE 430: Lecture 2
35 of 100
First stage in a project
 Typical first phase of a project is the requirements.


Before we can do anything we need to know what it is we want to do.
We need useful forms of input data.
 Sloppy requirements specification and management is a
major risk in software development.


Majority of project failures can be attributed to incomplete or
incorrect requirements.
Therefore, worth the effort to do very well.
 Requirements capture is an entire course in itself.
 It is not an OO activity per se.
September 17, 2015
SE 430: Lecture 2
36 of 100
Establishing Requirements
 Introduction
 Requirements Process Fundamentals
 Requirements in the SDLC
September 17, 2015
SE 430: Lecture 2
37 of 100
Definitions
 A requirement is a statement about an intended system that specifies





what the system should do or how the system should perform
Stakeholders are those people or organizations that will be affected
directly or indirectly by the system, or who will have an effect on the
system
The phrase establishing requirements represents the understanding
that requirements arise from a progressive understanding of
stakeholders’ needs
A goal of the requirements activity is to make requirements specific,
unambiguous, and clear
Requirement – a capability needed by a user to solve a problem or
achieve an objective
Requirements document – an unambiguous (written) description of
the external behavior of the system to be built
September 17, 2015
SE 430: Lecture 2
38 of 100
The importance of getting requirements right:
Standish Group’s CHAOS Report (2009)
Rank
Successful
Challenged
Failure
Factors Cited
%
Factors Cited
%
Factors Cited
%
1
User
Involvement
15.9
Lack of User Input
12.8
Incomplete
Requirements
13.1
2
Executive
Management
Support
13.9
Incomplete
Requirements
12.3
Lack of User
Involvement
12.4
3
Clear Statement
of
13
Requirements
Changing
Requirements
11.8
Lack of
Resources
10.6
Definitions:
 Successful: On-time and on-budget
 Challenged: Complete and operational, but
over-time, over-budget, reduced scope
 Failure: Cancelled
September 17, 2015
Standish CHAOS results:
- ~32% Successful
- ~45% Challenged
- ~23% Failure
SE 430: Lecture 2
39 of 100
Common elements and differences
 Sequential, evolutionary, and agile methodologies all treat establishing
requirements as one of the most critical elements of the SDLC
 The significant differences among the methodologies center on when
requirements are established and who is responsible for requirements once
they are documented.
September 17, 2015
SE 430: Lecture 2
40 of 100
Major kinds of requirements
 Functional requirements



Are the most readily-understood requirements type
Describe what the system should do
Are usually active, visible aspects of how the system works
 Quality attributes—commonly known as non-functional requirements


Support and enhance the functional requirements of a system
Examples: Usability, performance, security, availability, modifiability,
maintainability (including portability and scalability), testability
September 17, 2015
SE 430: Lecture 2
41 of 100
Requirements
 Problem Definition —> Requirements Specification



Determine exactly what the customer and user want
Develop a contract with the customer
Specifies what the software product is to do
 Difficulties




Client asks for wrong product
Clients lie [not consciously].
Client is computer/software illiterate
Specifications are ambiguous, inconsistent, incomplete
September 17, 2015
SE 430: Lecture 2
42 of 100
Why is requirements capture so difficult?
 People issues:



Developers are usually building software for someone else.
Most users have narrow perspective on what system should do.
Few users have a broad view of what the system should do.
 A solution: develop use cases or ‘stories’ (per ‘agile’
processes)—each itself a narrow view of the system—and
‘stitch’ these views together like a digital panoramic photo
September 17, 2015
SE 430: Lecture 2
43 of 100
Why is requirements capture so difficult?
 Process issues:
Traditionally, requirements were untouchable once analysis had
begun, even in projects that have high levels of risk.
 Requirements are discovered and revised throughout analysis,
design, and even into implementation.
 The best approach to discovering what software should do is to
‘learn by doing.’
 A solution: iterative and incremental process allows ongoing
requirements capture and revision.
 Exceptions: Some safety-critical domains (e.g., medical life-support
and public transportation systems) require rigid requirements stability
in order to ensure meeting safety and certification requirements

September 17, 2015
SE 430: Lecture 2
44 of 100
Requirements
 Requirements Capture (A List of Requirements)
Delimit the system
 Form agreement on what the system should do
 Provide a basis for planning the technical content of iterations
 Give developers a better understanding of the system
 Roles of requirements
 Describe customer needs and desires for the system.
 Provide the framework for defining the scope of the system.
 Identify broad areas of risk, reuse, and systems-level
interdependencies.
 Establish essential contractual obligations.
 Provide the foundation for testing criteria.
 Requirements gathering and analysis are not specifically O-O
activities

September 17, 2015
SE 430: Lecture 2
45 of 100
Features and requirements
 A feature is defined as an externally observable service provided by the




system that directly fulfills a stakeholder need
 ‘Feature’ and ‘high-level requirement’ are often used
interchangeably
 Example: Provide basic trouble-shooting app for customers
A feature may fall under either of the requirements categories, though
most are functional
When decomposed, a feature represents one or more logically-related
requirements
 Example: Provide product-specific diagnostic tool
It is often difficult to distinguish between features and requirements,
hence the interchangeable use of ‘feature’ and ‘high-level requirement’
 Example: A feature for the customer support app is to support
email access to support staff
A requirement should be specific enough to allow a developer to easily
translate the requirement directly into an implemented solution—it needs
no further decomposition
September 17, 2015
SE 430: Lecture 2
46 of 100
Inputs to analysis
Object oriented methods can’t make up for solving the wrong
problem.
 We can reduce the risk of solving the wrong problem by collecting
requirements data. Three useful forms of requirements data are:



text information
the problem statement or Problem Charter
scenarios that characterize the system's behavior
 How to collect requirements



Informal discussions
Competitive Analysis
Laundry list of features
 After collecting requirements we can document them in a consistent
form: use cases or user stories
September 17, 2015
SE 430: Lecture 2
47 of 100
Requirements inputs
Some examples of text inputs:
 Inputs from customers,
 Market surveys,
 Standards specifications,
 Text-based requirements documents,
 Competitive analysis
 Architectural documentation
 Interface specifications
 Design documents
 Requirements specifications
 E-mail messages
 Lists of system assumptions
You need to scan through these documents to find the real requirements.
September 17, 2015
SE 430: Lecture 2
48 of 100
I Get Out of Bed, and then I ...
Discovering requirements, delighting customers
Goal: Understand how and when your customer uses your product.
Activity: Ask your customers to describe their daily events in a way that makes
sense to them. You can use a poster-sized date planner or a simple timeline
on butcher paper.
Make certain you ask them to describe different kinds of days, such as:
 The beginnings and ends of weeks, months, quarters or years.
 Special events unique to their industry.
 Days on which everything goes horribly awry and they need help.
While they're doing this, be alert for how your system helps or hinders their day.
Materials: Butcher paper, markers and calendars in normal or large print format.
September 17, 2015
SE 430: Lecture 2
49 of 100
Risks of customer misconceptions
From Simple and Usable: Web, Mobile, and Interaction Design by Giles
Colborne (New Riders, 2011):
A few years ago I was asked to redesign some software to help car dealers put
together a marketing plan. The brief was to merge several components into one, so
that a dealer could write a plan in one sitting.
Fortunately, a colleague of mine visited some dealerships to talk to the
managers about their needs. At the first dealership she visited, the manager sat in
an office with a glass front that opened onto the showroom. As they spoke, the
manager kept glancing up to scan the showroom. Whenever a customer looked
lost, he would hurry out and attend them. It was the same in every dealership she
visited: the managers were constantly interrupted by the needs of their customers.
Instead of merging the components, we needed to break them into smaller
chunks so that the manager could complete them in the short bursts of time they
had.
Visiting users in their workplaces was vital—if we’d simply imagined the
manager at his desk we would have missed the crucial aspects.
September 17, 2015
SE 430: Lecture 2
50 of 100
Requirements levels
 A requirement represents a form of abstraction: it abstracts
functionality.
 Like all forms of abstraction, requirements are subject to the
perspective of the viewer.
 Chosen perspective translates to a requirements level.
 High-level: Broad with little detail.
Example: Track appointments, contacts, and tasks.
 Mid-level: Typical analysis level. More specific with some details.
Example: User may enter contact name, address, and phone
number.
 Low-level: Implementation-level. Specific and detailed.
Example: Present user with scrollable time line from which user
may choose appointment start time.
September 17, 2015
SE 430: Lecture 2
51 of 100
System attributes and constraints
 Attributes specify characteristics or dimensions of system requirements –
limit designer options
 Constraints specify limits or bounds – more flexible
 Specify characteristics, dimensions, or limits of system requirements.
 Qualitative attributes and constraints:

Example: The user interface must be graphical and usable by color-blind
persons.
 Quantitative attributes and constraints state measurable objectives or
metrics for the attribute:


Example: The security system must provide coverage for 99.998% of
every operating year (< 11 minutes downtime).
Example: The system must have < 11 minutes downtime for every
operating year (constraint—flexible target)
 Quantitative attributes and constraints are preferable to qualitative ones.
September 17, 2015
SE 430: Lecture 2
52 of 100
The Unified Process
Requirements Workflow
September 17, 2015
SE 430: Lecture 2
53 of 100
UP - Introduction
 The UP defines several artifacts:








Vision document; charter; project overview
Use-case model
Supplementary Specifications
» Includes requirement lists and attributes
Stakeholder requests
UI prototype
Use-case UI or storyboard
Competitive Analysis
Glossary
 Advice: Create every one!
September 17, 2015
SE 430: Lecture 2
54 of 100
Requirements workflow
Write System
Overview
Statement
Identify
Stakeholders
Understand User
Goals
Develop a
Feature List
Build a System
Context
Description
Identify
Functional
Requirements
Identify
Supplementary
Requirements
Build a Glossary
as You Go
September 17, 2015
SE 430: Lecture 2
55 of 100
Problem Charter
 The problem charter describes the basic theme of the
system to be developed. Also can be a “vision” document
or a “Project Overview”
 It helps to focus the team
 It is a good idea to limit the charter to one page
 Example:
The product to be developed is a Course Registration Management
System (CRMS). Courses are offered both live and via online
streaming video. The system will be used by both students and
administrators. Students use it for registration and drop procedures
for course offerings. The system is used by administrators for
managing course and course offering information.
September 17, 2015
SE 430: Lecture 2
56 of 100
Start with a Project Overview Statement
 Project overview statement should be considered an executive
summary or extended abstract, giving the highest-level view of the
system
 Contains all the essential project elements:
 Brief project description. Defines the purpose of the project
 (Optional) Competitive analysis.
 Project objective(s). Identify concrete accomplishments and/or
deliverables
» Examples: ‘Reduce prescription fulfillment time by 50%’ or
‘Provide on-line, up-to-date patient medication reports’
 Qualitative estimates of benefits and costs. Include both tangibles
and intangibles
» Examples: ‘Increase patient confidence levels’ or ‘Will require
moderate-to-high investment in staff training’
September 17, 2015
SE 430: Lecture 2
57 of 100
Write System Overview Statement
 Contains all the essential project elements:
Scope. Indicate what capabilities will and will not be included in
the project. State the boundaries of a (sub)system if it works with
other (sub)systems
» Examples: ‘System will monitor all medications prescribed
within the hospital network’ or ‘System will not attempt to
monitor prescriptions outside the hospital network’
 Interfaces. Identify other systems (computer or otherwise) with
which the system must interact
» Examples: Central patient records and office systems of doctors
affiliated with hospital network
» This covers electronic connections to third party systems as
well as other parts of a “system” that is not part of the current
project scope.
 Gives the broadest, highest-level picture of the system.

September 17, 2015
SE 430: Lecture 2
58 of 100
Scope
 Scope refers to two different but related concepts:
 Product scope represents the features and functions that define
the product—what will and will not be included in the product
 Project scope represents the work that needs to be performed to
deliver the product with those features and functions
 It is clear that product scope and a significant part of project scope
are tightly coupled
 In any evolutionary process—plan-driven or agile—requirements are
expected to evolve with time
 Thus, scope of the product and project are viewed as a function of time,
rather than as a fixed boundary
September 17, 2015
SE 430: Lecture 2
59 of 100
Scope
 Scope creep refers to unplanned changes to requirements scope
 In a well-managed evolutionary project, there is no scope creep
 Scope is expected to change
 Customer is closely involved and understands the total cost of
changes
 New requirements are openly evaluated and incorporated, with
minimal administrative overhead
September 17, 2015
SE 430: Lecture 2
60 of 100
Scope
 Determine the boundaries of the system.
What is the system?
 What is the system’s environment?
 Develop a context model that shows the context of the system within
its environment.

Branch
accounting
System
Branch
counter
System
September 17, 2015
Security
System
Account
Database
Auto-Teller
System
Usage
Database
Maintenance
System
SE 430: Lecture 2
61 of 100
Competitive Analysis
Normally, this is done before we start requirements
 What other products that are similar to ours?
 Their features and capabilities
 Why is the competitive product


Unusable
Unacceptable
 Cautions


Beware of NIH (Not Invented Here)
Beware of doing something because we can
 COTS (Commercial off the shelf software)
 Do other people have similar problems (beware of “our
problems are different”)?
September 17, 2015
SE 430: Lecture 2
62 of 100
Identify stakeholders
 Stakeholders are those people or organizations that will be
affected directly or indirectly by the system or who will
have an effect on the system
 Examples of stakeholders include:





The system (non-end-user) customer
Various users of the system: end-users, system administrators,
configurers, training staff, service staff
Development organization, individual developers
Marketing, sales, and distribution
Opponents and supporters
 We will primarily address system customers and users,
focusing on the latter
September 17, 2015
SE 430: Lecture 2
63 of 100
System customers and users
 System customers are those entities responsible for initiating the




system project and providing material, financial, or staffing resources
for system
Actual users may be a subset of system customers or may be a
completely disjoint set
Be as specific as possible in identifying system customers and users
 Medical records PDA example: Customer will be the hospital or
department administration; users will be doctors, nurses, physical
therapists, etc.
In all cases, be sure to understand user needs and be willing to
correct system customer misconceptions
May need to reconcile system customer goals and user goals
September 17, 2015
SE 430: Lecture 2
64 of 100
Understand user goals
 User goals are specific, but
not detailed, descriptions of
what user wants the
system to do.
 A user goal may lead to
one or more requirements.
 User goals provide the
foundation for use-case
analysis.
PDA example
leads to
User goal 1:
Track
appointments
Requirement
1.1:
Provide
calendar
leads to
Requirement
1.2:
Allow
appointment
in calendar
leads to
Requirement
1.3:
Allow repeating
appointments
September 17, 2015
SE 430: Lecture 2
65 of 100
Develop a feature list
 Feature list identifies a list of high- or mid-level
requirements, out of a (usually) much larger wish list, that
are candidates for inclusion in the system.
 For each requirement, provide:







Number each feature, e.g. F003
A name, as descriptive as possible.
Description in the form of an explanation or a definition.
Associated user goal (optional). A single goal may have more than
one requirement associated with it.
Priority (required, desirable, or optional).
Visibility (visible to user or hidden from user).
Estimated implementation risk for this requirement (high, normal,
minimal).
September 17, 2015
SE 430: Lecture 2
66 of 100
Build a system context description
 System context description describes the environment
in which the system is embedded.
 Identifies entities that are directly relevant to the system:



Domain objects.
Domain processes.
Domain actors.
 These are examples of conceptual classes
 System context description acts as the foundation for the
Domain Model.
September 17, 2015
SE 430: Lecture 2
67 of 100
System context: identify domain objects
 Domain objects are the entities encountered in the world
in which the system will operate.
 Domain objects for (Medical) PDA software include:



‘Business’ objects and abstractions: Patient record, appointment
record, medication list, synchronization schedule.
Real-world objects: Touch screen, synchronization link (e.g.
cradle, IR, Bluetooth), host PC
Events: Last synchronization date/time with host, create new
medication record request, medication alarm notification; anything
that occurs within a limited time
September 17, 2015
SE 430: Lecture 2
68 of 100
System context: identify domain processes
 Discovery of domain processes often proceeds concurrently with




domain object discovery.
Types of domain processes might include:
 Start-up: Touch screen initialization; set time, time zone, and date.
 Standard operating procedures: Add/delete PDA database entry,
change font size, soft reset.
 Exceptional circumstances: ‘Hard’ reset, delete private records.
For requirements phase, just name and define processes.
Do not explore process detail here! This will be captured later in
use-case descriptions, sequence diagrams, and statecharts.
Sometimes domain processes are very similar to functional
requirements.
September 17, 2015
SE 430: Lecture 2
69 of 100
System context: identify domain actors
 Domain actors interact in some way with the system



Users are a subset of domain actors
Actors may be active (directly interacting with system) or passive
(indirect interaction)
Actors may be human or non-human
 Examples:




Active/human: device user (doctor, nurse, etc.)
Active/non-human: PDA/host synchronization software
Passive/human: recipient of consultation reminder
Passive/non-human: PC-based calendar/contact manager (e.g. MS
Outlook)
September 17, 2015
SE 430: Lecture 2
70 of 100
Build a glossary as you go
 Glossary is the repository for any terms used to describe the system.
 Includes items identified in the System Context Description as well as
any terms encountered in interfaces to the system.
 Include only terms that are unique or the definitions of which differ
from their general use.
 Will evolve into the standard reference for abstractions.
 Benefits:
 Establishes a common and consistent vocabulary among all
stakeholders
 Provides global view which may lead to discovering commonalties
and simplification.
 Allows browsing which promotes reuse.
September 17, 2015
SE 430: Lecture 2
71 of 100
Identify functional requirements
 Features vs. functional requirements:



A feature may have behavior or it may not, e.g. ‘Use a color
display’ or ‘support non-Latin character sets.’
A functional requirement has behavior, e.g. ‘Sound alarm n
minutes before appointment.’
Functional requirements represent a subset of the feature list.
 Functional requirements specify what behavior the
system will exhibit, but not how the behavior will be
implemented!
 Some functional requirements can be identified from the
system features list and the system context description.
 Most functional requirements are discovered through
use cases.
September 17, 2015
SE 430: Lecture 2
72 of 100
Functional vs. Non-Functional
 A functional requirement (FR) describes what the
system needs to do.
 Example: ‘The system shall display the current customer balance’.
 A non-functional requirement (NFR) describes a constraint upon the
solution space.
 Example: reliability, portability, maintainability, usability, safety, and
security.
 Also called “quality” requirements, “ilities”, or even “systemic”
requirements.
 Emergent Properties: An NFR that is realized through the careful
implementation of other requirements on which it depends.
 Example: “The query must return its results in less than three
seconds” is only realizable once the architecture and much of the
system functionality has been implemented.
September 17, 2015
SE 430: Lecture 2
73 of 100
Identify supplementary requirements
 Supplementary requirements are those not associated
with a particular functional requirement of the system.
 May span several functional requirements, use cases, or
none at all.
 Some may be addressed by aspect-oriented programming
(AOP), e.g. error handling and logging, failure recovery
 More examples:




Hardware platforms, system software, security, reliability and
availability, performance, file formats.
System modifiability, subsystem availability, ease of learning.
Legal, regulatory, fiduciary responsibility, and liability requirements
or constraints.
Bold examples indicate architectural quality attributes
September 17, 2015
SE 430: Lecture 2
74 of 100
Feature/requirement example
 Consider the requirement to monitor all medications
prescribed within the hospital network
Identification: REQ003
Name: Monitor all prescribed medications
Description: Monitor all medications prescribed within the hospital
network. System will not monitor prescriptions from outside the
hospital network
User goals: Avoid unwanted drug interactions; avoid over- or undermedicating patients
Priority: Required
Visibility: Visible
Implementation risk: Normal
September 17, 2015
SE 430: Lecture 2
75 of 100
Conceptual class categories
 Conceptual class
categories are a way of
helping identify domain
objects, processes, and
actors
 These conceptual class
categories are adapted from
Craig Larman, Applying UML
and Patterns: An Introduction
to Object-Oriented Analysis
and Design and Iterative
Development, 3rd edition,
Prentice Hall, 2004
September 17, 2015
Conceptual Class
Category
Example
Physical or
tangible objects
TouchScreen, PDA,
HostPC
Specifications,
designs, or
descriptions
Consultation-Protocol
Places
PatientBed
Transactions
DrugDosage-Change
Transaction line
items
OriginalDose,
NewDose
Roles of people
Patient, PrimaryCarePhysician
Containers
RadiologyLab,
OperatingRoom
Contained items
PatientMonitor,
MRIUnit
SE 430: Lecture 2
76 of 100
Conceptual class categories
Conceptual Class Category
Example
Other collaborating systems
Originating hospital, primary care
physician's records
Abstract nouns concepts
QualityOfLife
Organizations
AMA, InsuranceCompany
Events
PatientAdmitDate,
PatientDischargeDate
Processes
MedicalHistoryReview,
PatientAdmission
Rules and policies
DischargePolicy
Catalogs
AllowedProcedures
Records of finance, work, contracts,
legal matters
Receipt, PreAuthorization
Financial instruments and services
PatientAccount, PatientCharge
Manuals, schedules, documents,
references
PhysiciansDeskReference
September 17, 2015
SE 430: Lecture 2
77 of 100
Requirements Specification
 Concept of Operations
Defines the high-level system requirements from the user or domain
perspective.
 Depicts the system context in which the proposed system will
operate, primary data stores, and events that the system must
respond to.
 Systems requirement specification
 Primarily used for large systems with substantial non-software
components
 Software Requirements Specification
 Defines what the software component of the product is expected to
do, and where necessary explicitly states what it should not do.
 Supported by the requirements definition document
 SRS is normally written in natural language but complex or critical
requirements may be more formally specified.

September 17, 2015
SE 430: Lecture 2
78 of 100
Requirements
A Requirements document can include:
 Overview statement (purpose of the project)
 Charter
 Vision statement
 Scope: what is covered and what is not
 Customers (who will use the product / buy the product)
 Goals (support faster, cheaper, more reliable, etc. Business operations)
 System functions (what the system is supposed to do)
 System attributes (ease of use, fault tolerance, response time, etc.)
 Competitive analysis: who is doing something similar and what does the
product do (features)
 System Context: description of major processes, actors and concepts
September 17, 2015
SE 430: Lecture 2
79 of 100
Requirements
Requirements should:
 Be measurable

Not “fast”, but “10ms to accomplish . . .”
 Have verifiable objectives

Not “easy to use”
 Have concrete requirements
 Must be able to determine if requirement has been satisfied
by the design.
 Must be traceable (next time).
September 17, 2015
SE 430: Lecture 2
80 of 100
Requirements
Requirements document should not include:
 Discussion of the language to implement
 Details on how the system should work
 Details on the equipment involved
 Algorithms or implementation details
Typical problem with many requirement statements:
 Embedded design (How vs. What).
 Vague
 Computer industry language instead of user's language.
September 17, 2015
SE 430: Lecture 2
81 of 100
Validating Requirements
 Is each requirement consistent with the overall objective for the








system/product?
Have all requirements been specified at the proper level of abstraction?
That is, do some requirements provide a level of technical detail that is
inappropriate at this stage?
Is the requirement really necessary or does it represent an add-on
feature that may not be essential to the objective of the system?
Is each requirement bounded and unambiguous?
Does each requirement have attribution? That is, is a source (generally,
a specific individual) noted for each requirement?
Do any requirements conflict with other requirements?
Is each requirement achievable in the technical environment that will
house the system or product?
Is each requirement testable, once implemented?
Does the requirements model properly reflect the information, function
and behavior of the system to be built.
September 17, 2015
SE 430: Lecture 2
82 of 100
Requirements
Do these requirements avoid the typical problems?
Ref #
Function
R1
The system must provide a log to capture all the customer transactions
for the fiscal year.
R2
The system will barcode documents automatically prior to distribution.
At a minimum, the codes will be used to identify to which work queue
the documents should be routed within the organization when they are
returned.
R3
When a workflow is initiated, the system must be able to pre-fetch the
documents that are in electronic image format by document type or
grouping of documents by process.
R4
The system must create an entry in the journal file whenever a letter is
created
R5
If an individual double-clicks on an event in a journal, the system will
display the images associated with the event.
R6
The telephone system must be able to inform callers of the anticipated
wait time based on the number of calls, average duration of calls, and
number of calls ahead of them.
September 17, 2015
SE 430: Lecture 2
83 of 100
Business Rules
September 17, 2015
SE 430: Lecture 2
84 of 100
Business Rules
Business Rules – dictate how a company conducts its
business.
Business rules are likely to apply to several or all use cases
developed for a particular application.
Domain Rules – facts and information on the domain.
Domain rules are likely to apply to several or all use cases
developed for a particular application.
September 17, 2015
SE 430: Lecture 2
85 of 100
Business Rules
Rules and policy required by the “business” or other agency
(IRS)
Checks must be approved by manager
Credit cards must get approval
Books are due in 14 days
Tax must be collected for all sales
14 day wait for purchasing firearms
No cigarettes to minors
September 17, 2015
SE 430: Lecture 2
86 of 100
Domain Rules
 Examples:





RFID sensors have a range of X meters
GPS has an accuracy of X meters
UV light damages paper (shield old documents)
Temperature and humidity need to remain constant
Documents must be handled with cloth gloves
September 17, 2015
SE 430: Lecture 2
87 of 100
Activity Diagrams
September 17, 2015
SE 430: Lecture 2
88 of 100
Description
 Activity diagrams are an updated version of flowcharts
 Use activity diagrams to describe procedural activities,
business processes, and work flow

Useful to document current ways a business works
 Activity diagrams can show different actors through the
use of partitions
 Essential elements: initial node, activity/action, flow/edge,
fork and join, send/accept signal, object, decision/merge,
partition, activity final
September 17, 2015
SE 430: Lecture 2
89 of 100
Activity diagram
September 17, 2015
SE 430: Lecture 2
90 of 100
Agile Perspective
September 17, 2015
SE 430: Lecture 2
91 of 100
Requirements in agile
 Requirements in agile are under the least methodological constraint
among all SDLC methodologies
 Agile views requirements as evolving throughout the system
development project
 This evolution is driven by the business value of the requirements to the
customer; this means:
 Established requirements may change
 New requirements may emerge, often driven by market changes
 Established requirements may become redundant or irrelevant
September 17, 2015
SE 430: Lecture 2
92 of 100
Requirements focus: product vision
 The product vision (also known as the ‘elevator statement’) defines the business

needs and objectives that the project intends to accomplish.
A suggested agile product vision statement format:






For (target customer)
Who (statement of the need or opportunity)
The (product name) is a (product category)
That (key benefit, compelling reason to buy)
Unlike (primary competitive alternative)
Our product (statement of primary differentiation)
 Keep the product vision short and concise—‘laser-sharp’—it should be easy to
remember so it can be used readily to maintain focus
Adapted from: Making Sense of Agile Project Management, Charles Cobb, Wiley, 2011
September 17, 2015
SE 430: Lecture 2
93 of 100
Requirements focus: product vision
‣ Product vision example:
 For the customer who needs to quickly diagnose minor problems
with their software, the DTApp is a diagnostic tool that provides a
quick check for common software problems. Unlike a call to
customer support, the DTApp allows the customer to resolve
common problems quickly and efficiently.
September 17, 2015
SE 430: Lecture 2
94 of 100
Documenting features and requirements
 Use cases are traditionally used for documenting features and





requirements. We will discuss them in the next lecture.
In agile development we call them user stories and they are somewhat
different:
User stories are the most effective tool for documenting features and
requirements
User stories are brief, high-level, informal descriptions of what people
do, or want to do
Consider user stories as the ‘Post-It®’ notes for establishing
requirements
The analyst or developer needs to perform analysis on collected user
stories in order to classify each as a need, a feature, or a requirement
 Features require additional refinement (decomposition) to the
requirements level before they can be realized in a system
implementation
September 17, 2015
SE 430: Lecture 2
95 of 100
Documenting features and requirements
 For each identified feature, provide:
 User story in the form: As a <role>, I do/want/need <something>
so that <result/benefit>
 Or, more simply: As a <role>, I do/want/can <something>
 Example: As a consultant, I need a mobile diagnostic application
so that I can pinpoint customer problems while at the customer site
 User stories for requirements follow the same format, but are more
specific:
 Example: As a consultant, I want the mobile diagnostic application
to allow me to access the company’s internal software issues
database for all of our supported applications
September 17, 2015
SE 430: Lecture 2
96 of 100
Requirements repository: product backlog
 The product (features) backlog is the repository of all high-level product
features, prioritized by business value
 The product backlog is owned by the product owner
 The backlog is assumed to be incomplete and subject to change
 The product backlog is prioritized and re-prioritized continuously,
across all releases and iterations, in response to project progress,
completed work, and an evolving understanding of requirements
 At the iteration level, the team selects as many of the highestpriority items from the product backlog as the team feels can be
completed within the fixed time box of the iteration—this is the
iteration backlog
 This is the only point in the agile SDLC at which a backlog is
locked: no changes to the iteration backlog are allowed during the
iteration
September 17, 2015
SE 430: Lecture 2
97 of 100
Requirements in time: product roadmap
 The product roadmap decomposes the product vision into releases,
each with a working set of features
 Each release defines a subset of the overall functionality of the
product
 The product roadmap maps the features of overall functionality
contained in the product backlog onto the release structure
 The roadmap includes estimated dates, but makes no schedule
commitments
September 17, 2015
SE 430: Lecture 2
98 of 100
Summary
 Requirements Analysis starts with the




Problem Statement or Project Charter or Vision
Requirements Document
» Formal list of what the product will do
Business Rules
Competitive analysis
 A set of well thought-out and complete requirements is
needed to do a good job with the rest of analysis and
design.
 The major cause of problems in a project can be traced to
incomplete, misleading or incorrect requirements.
 We have a course in Requirements Analysis.
September 17, 2015
SE 430: Lecture 2
99 of 100
Next Class
Topic:
Use Cases
Reading:
Arlow & Neustadt: Ch’s 4 & 5
Articles on the Class Page
Assignment 1 – The Museum Automation Project


Develop project description and requirements document for the
Visitor Information Subsystem
Due September 24, 2015.
September 17, 2015
SE 430: Lecture 2
100 of 100