Object-Oriented Software Engineering
Practical Software Development using UML and Java
Chapter 4:
Overview of the Software Process
Developing Requirements
(adapted from lloseng by Allen Tucker)
Software process: the classical lifecycle model
Requirements
Specifications
Design
Limitations:
- Requirements change
- User involvement
- Feedback
- Slow
© Lethbridge/Laganière 2001
Coding/Integration
Verification &
Validation
Deployment
Chapter 4: Developing requirements
2
The spiral model
(improving the process)
Review
v 0.2
V&V
Deployment (v 1.0)
v 0.1
Prototype
Coding/
Integration
Requirements
Specifications
Design
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
3
Object oriented design
Focus on classes and objects
• Methods and messages are subordinate
Features
•
•
•
•
Hierarchy/reuse
Information hiding/abstraction
Polymorphism
Class and system have state
Tools
•
•
•
•
Specifications : Java Modeling Language (UML/JML)
Design: Universal Modeling Language (UML)
Coding: Java
V&V: JML and others
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
4
Correctness of software systems
Where?
• Method level: pre- and post-conditions, loop invariant
• Class level: class invariant (class state)
• System level: intra-class invariants (system state)
When?
• Specification and design phases:
Develop method and class specifications (JML/UML)
• Coding phase:
Develop code from the specifications (Java)
• V&V phase:
Prove (rigorously) that code and specifications are
logically equivalent (JML <==> Java)
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
5
UML origins and current status
The Unified Modelling Language (UML) is a widely used graphical standard
for software modeling
Rumbaugh, Jacobson and Booch merged their different notational schemes in 1994
and 1995.
In 1997 they formed the Object Management Group (OMG) and started the process of
UML standardization (http://www.omg.org/)
The current UML standard is widely supported (e.g., argoUML, Omondo UML
http://www.omondo.com/product.html)
UML does not fully embrace formal methods (but it is a good deal more formal than its
predecessors).
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
6
Domain Analysis
The process by which a software engineer learns about
the domain to understand the problem:
• The domain is the general field of business or
technology in which the clients will use the software
—E.g., college/university course registration
• A domain expert is a person who has a deep knowledge
of the domain
—E.g., the registrar, students, faculty
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
7
Domain analysis document
A.
B.
C.
D.
E.
F.
G.
H.
Introduction
Glossary
General knowledge about the domain
Customers and users
The environment
Tasks and procedures currently performed
Competing software
Similarities to other domains
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
8
Business Process Reengineering:
A setting for domain analysis
A business process is a mix of people, procedures, software, and
hardware that surround a domain of activity for that business.
Examples:
• payroll
• accounting
• student registration
• airline reservations
Business Process reengineering (called BPR) is a methodology to redesign
a process so that flaws can be corrected, new capabilities added, and
operational costs reduced.
• A BPR task may take 6 weeks to a year.
• A BPR team has different players: managers, staff, software engineers
For more information on BPR, see: http://www.brint.com/BPR.htm
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
9
Sample process: Bowdoin course registration
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
10
Course registration: a Catalog page
Course Description:
Spanish 210
Division:
c = humanities,
b = social science,
a = science,
d = non-Eurocentric
Prerequisite
© Lethbridge/Laganière 2001
Instructor
Chapter 4: Developing requirements
Cross-listing
course
11
Course registration: the course book
(viewable as a PDF)
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
12
A page in the course book
Schedule for
Spanish 210b
Time slot
© Lethbridge/Laganière 2001
Instructor
Chapter 4: Developing requirements
13
Course offerings encoded
SPAN210A c INTRO TO MODERN HISPANIC LITERATURE Cueto-Asin
capacity: 25
time slot: MW 11:30-12:55 same as: [LAM210]
SPAN210B c INTRO TO MODERN HISPANIC LITERATURE Turner
capacity: 25
time slot: TTH 10:00-11:25 same as: [LAM210]
SPAN325 c SPANISH CIVIL WAR IN LIT AND FILM Cueto-Asin
capacity: 15
prerequisites: [SPAN2(07|08|09|10), SPAN2(07|08|09|10)]
time slot: MW 2:30-3:55
SPAN330 c POETRY AND EMPIRE Turner
capacity: 15
prerequisites: [SPAN2(07|08|09|10), SPAN2(07|08|09|10)]
time slot: TTH 2:30-3:55
id
distrib
© Lethbridge/Laganière 2001
title
instructor
Chapter 4: Developing requirements
14
Time slots
There are lots of these…
50 or more
Notes: a) time slots are prescheduled for courses, as
are classrooms and
capacities.
b) When a course fills to
capacity, noone else can
register for it.
c) Popular courses are filled
using a random process.
© Lethbridge/Laganière 2001
…
F 13:30-15:25
F 13:30-16:25
TH 08:30-11:25
TH 10:00-11:25
TH 13:00-14:25
TH 13:00-15:55
TH 13:00-16:55
TH 14:00-15:55
TH 14:30-16:25
TH 16:00-18:55
TH 19:00-21:00
M 06:00-07:55
M 06:30-08:25
…
Chapter 4: Developing requirements
15
Course registration: sample student card
primary choices
Student id (Smith)
alternates
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
16
Another sample card
Primary choices
More alternates
Student id (Brown)
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
17
Sample card encoded
Student id (Smith)
Semester/year
Course id
NumChoices
Priority (row)
Selection (column)
LabPriority
1 041 4 SPAN210B:11 HIST209:12 BIO158:13 BIO158L2:131 BIO158L1:132
ANTH233:14
SPAN210A:21 HIST236:22 GEO100:23 GEO100L1:231 GEO100L2:232
ARCH204:24
2 041 4 PHIL112:11 PHIL399:12 MUS282:13 MUS243:14
PHIL120:21 PHIL229:22
MUS127:24
3 041 4 GOV245:11 REL221:12 GOV211:13 GOV270:14
4 041 4 ANTH248:11 ANTH310:12 REL219:13 DANCE111:14
5 041 4 CLAS102:11 BIO064:12 HIST142:13 ARTH223:14
ARTH103:21 HIST257:22 IDEP220:23 ENG104:24
HIST204:31 HIST228:32 ASIAN284:33
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
18
Current process: sample transcript
Student id
Pseudonym
Class
Courses completed or in progress
1 SMITH 2007 courses: ENG022 A- FR101 HIST216 A- HIST221 A- HIST206
PHIL025 A- ANTH203 BIO104 ANTH102 A ANTH101 A BIO104L
SPAN207L SPAN209 SPAN207 A- SPAN205 B+
4 JONES 2005 major: [Anthropology, Asian Studies] courses: ECON101 B+
ES287 A GEO103L GEO103 B REL101 B PHYS162 A ARTH010 B ANTH253
A- ANTH203 ASIAN272 ARTH110 B ARTH101 B+ ANTH101 A VART180L
ANTH257 ANTH231 B+ ASIAN227 B+ ASIAN273 A ANTH102 B+
ASIAN276L VART180 B ASIAN276 B+ ASIAN370 ARTH242 B+ ANTH235 B
ANTH201 B REL223 A5 BROWN 2008 courses: ECON014 FR205 HIST218 REL101
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
19
Starting Points for Software Projects
Requirements
must be determined
Clients have produced
requirements
A
B
C
D
New
development
green field project
Evolution of
existing system
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
20
Defining the Problem and the Scope
A problem can be expressed as:
• A difficulty the users or customers are facing,
• Or as an opportunity that will result in some benefit such
as improved productivity or sales.
The solution to the problem normally will entail
developing software
A good problem statement is short and succinct
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
21
Problem statement sketch:
Bowdoin’s Student registration system (Stress)
Strengths
Advising
Equity
Simplicity
Scheduling stability
Weaknesses
Tedious, time-consuming, costly, and error-prone
—Students fill out their cards by hand
—Registrar keys all 1600 cards into a single batch
Access
—Students off campus have difficulty registering
Does not utilize a modern campus network or on-line technology
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
22
Defining the Scope
Narrow the scope by defining a more precise problem
• List all the things you might imagine the system doing
—Exclude some of these things if too broad
—Determine high-level goals if too narrow
Example: A university/college registration system
Initial list of problems
with very broad scope
browsing courses
registering
fee payment
© Lethbridge/Laganière 2001
Narrowed
scope
room allocation
exam scheduling
browsing courses
registering
Scope of
another system
room allocation
exam scheduling
fee payment
Chapter 4: Developing requirements
23
What is a Requirement?
A capability of the system that all stakeholders agree must
be present before the customer’s problem is solved.
Two types:
1. Functional requirements
— describe what the system should do
2. Non-functional requirements
— Constraints that control development
A collection of requirements is a requirements document.
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
24
Requirements document...
A.
B.
C.
D.
E.
Problem
Background information
Environment and system models
Functional requirements
Non-functional requirements
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
25
Functional requirements include:
1. What inputs the system should accept
2. What outputs the system should produce
3. What data the system should store that other systems
might use
4. What computations the system should perform
5. Timing and synchronization of 1-4
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
26
Non-functional requirements
1. Constraints reflecting the system’s performance:
—Responsiveness and throughput
—Resource utilization
—Reliability; recovery from failure
—Availability
—Maintainability, enhancement, reusability
2. Constraints reflecting the system’s environment.
—Platform
—Technology to be used (OS, language, IDE, tools)
3. Categories constraining the project plan and development methods
—Process (e.g., OO, Extreme/agile)
—Cost (e.g., programmers, software designers)
—Calendar (deadlines)
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
27
StressFree = “Stress Fully Reengineered”
Goal: To design an on-line course registration system that would meet the following
functional requirements:
1.
2.
3.
Reduce tedium, cost, and errors:
Students can select and enroll in courses on-line
Students, registrar, and instructors can see
 current enrollment information
 current major requirements
Students can see their transcripts
Student/advisor interaction (e.g., digital signatures)
Improve access:
On-campus (24/7 access) and off-campus (Internet access)
Simultaneous multi-user access
Continuous access throughout registration week (eliminate “Phase II”)
Utilize modern technology:
Internet, client-server framework, database, GUI interface
-
Use Java, UML, and JML modeling tools
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
28
StressFree design elements
Requirements document
Use case definitions (UML)
GUI interface prototype (Java)
Database access prototype (Java)
Class specifications (UML)
Interaction and activity diagrams (UML)
Design by contract specifications (JML)
Presentation: December 15, 2005
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
29
Requirements Gathering Techniques
Learning
—Reading documents and discussing with users
—Shadowing users as they do their work
Interviewing stakeholders
—Ask about details, alternative models, other sources
—Gain their confidence!
Prototyping
—Paper prototype – pictures of the system shown to users
—User interface mockup – written in a rapid design language (Java)
Developing use cases
—Actors: the classes of users that will use the system
—Tasks: that each actor will perform with the system
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
30
E.g., Use cases for StressFree requirements
Actors include:
—Registrar
—Student
—Instructor
Tasks include:
—View transcript
—View courses offered
—View class list
—Add a course
—Drop a course
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
31
Developing a requirements document
• Level of detail depends on:
—system size, interfaces to other systems, audience, level of user
expertise with the domain and the technology
• Requirements should:
—Have benefits that outweigh the costs of development
—Be important for the solution of the current problem
—Be expressed clearly and consistently
—Be unambiguous, logically connected and verifiable
—Lead to a system of sufficient quality
—Be realistic with available resources
—Be uniquely identifiable
—Not over-constrain the system design
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
32
Risks in Requirements Analysis
• Lack of understanding of the domain or the real problem
—Do domain analysis and prototyping
• Requirements change
—Perform incremental development, build flexibility into the design,
do regular reviews
• Too many requirements (attempting to do too much)
—Document the boundaries early, estimate time carefully
• Requirements can conflict with each other
—Brainstorming, competing prototypes
• Some requirements are hard to state precisely
—Break requirements into simple sentences and review them
carefully; make prototypes early
© Lethbridge/Laganière 2001
Chapter 4: Developing requirements
33