CS 4850: Senior Project – Spring 2009
CS 4850: Senior Project
Spring 2009
Overview of Software Requirements
and OO Analysis
CS 4850: Senior Project – Spring 2009
Introduction to
Software Requirements Analysis
CS 4850: Senior Project – Spring 2009
What is Software Requirements Analysis? (1)
Software requirements analysis is process of understanding
customer requirements of the software system to be built, and
building analysis model to help assess the quality of the
system to be built.
This process requires active participation of the customer, and
it is crucial step in the development process. The developer
(analyst) may play different roles - interrogator, advisor,
problem solver, and negotiator.
CS 4850: Senior Project – Spring 2009
What is Software Requirements Analysis? (2)
The outcome of the process:
1. A Software Requirements Specifications (SRS). The SRS
should be clear, complete, and consistent with customer
needs.
2. Quality Assurance Plan - set of activities that the project team
can follow to ensure software quality throughout the product
life cycle (portability, reliability, efficiency, V&V criteria, cost,
acceptance criteria, etc…)
Only the SRS part is required for our class projects.
CS 4850: Senior Project – Spring 2009
Overview of
Object-Oriented Analysis
CS 4850: Senior Project – Spring 2009
The Big Picture - 1
Domain
Level
Domain
Engineering
OO
Engineering
System
Level
OO Analysis
OO Design
Implementation
OO Testing
Deployment
CS 4850: Senior Project – Spring 2009
The Big Picture - 2
OO Analysis
OO Design
Implementation
OO Testing
Deployment
Class
Modeling
Object
Relationship
Modeling
Object
Behavior
Modeling
CS 4850: Senior Project – Spring 2009
OOA Methods
OOA methods vary in their process steps, diagrams, notations,
terminologies, but they all produce similar results.
Examples:
•
•
•
•
•
Booch method
Rumbaugh method
Jacobson method
Coad/Yourdon method
Wirfs/Brock method
See OOA Handout (Chapter 21 of Pressman’s SE Book, 5th Ed.)
CS 4850: Senior Project – Spring 2009
The UML Approach
UML is a modeling language that can be used with any modeling
method/process.
UML components:
Syntax ===> the look of each symbol.
Semantic ===> the meaning of each symbol.
Pragmatic Rules ===> the intention/purpose of grouped symbols.
UML Views:
User model view (user view)
Structural model view (data and functionality view)
Behavioral model view (object interactions view)
Implementation model view (the software static and dynamic aspects)
Environment model view (the environment static and dynamic aspects)
CS 4850: Senior Project – Spring 2009
Use-Cases (1)
Use-cases are scenarios of system usage by different actors
(classes of users and devices).
e.g., student, faculty, and registrar are actors for a student
registration system.
Uses-cases are used to:
- obtain requirements from the customer
- effectively express requirements to the customer
Annotated diagrams are common way to construct use-cases.
In UML, use-cases are represented by use-case diagrams (see
handout page 582 or check you CSIS 3600 textbook)
CS 4850: Senior Project – Spring 2009
Use-Cases (2)
Some of the questions a use-case should answer:
- What are the main functions performed by the actor (people
or devices)?
- What information will the actor acquire, produce or change?
- What information does the actor desire of the system?
- others…
Note that an actor can play different roles for a given scenario.
High-level use-case may be elaborated by lower-level use-cases.
Please read the report “Structuring Use Cases with Goals” at:
http://alistair.cockburn.us/Structuring+use+cases+with+goals
CS 4850: Senior Project – Spring 2009
Components of OOA
Static components:
classes
class attributes
class operations
class relationships (inheritance structure)
Dynamic components:
interactions among objects (events)
control events that cause state transitions
CS 4850: Senior Project – Spring 2009
OOA Process
1.
2.
3.
4.
5.
6.
7.
Define use cases
Extract/Select candidate classes
Identify attributes for each class
Specify methods that service the attributes
Establish basic class relationships
Define a class hierarchy
Build a behavioral model
Repeat these steps for lower-level (other) use-cases.
Steps 2 through 5 may be done using CRC modeling.
CS 4850: Senior Project – Spring 2009
CRC Modeling
CRC modeling involves selecting classes, defining their
responsibilities, and identifying collaborations among classes.
class name:
class type: (e.g., device, property, role, event, person ...)
class characteristics: (e.g., tangible, atomic, concurrent, ...)
responsibilities:
collaborators:
CS 4850: Senior Project – Spring 2009
Selecting Classes
Selection criteria for potential objects (classes), page 583:
• Retained information: Does the system need to know about the
object?
• Needed services: Does the object provide needed operations?
• Multiple attributes: Does the object have multiple attributes?
• Common attributes: Do attributes apply to all instances of the
object?
• Common operations: Do operations apply to all instances of the
object?
• Essential requirements: Does the object represent essential
entity of the system?
An object that satisfies all or most of these criteria is a potential
class candidate.
CS 4850: Senior Project – Spring 2009
Allocating Responsibilities
Class responsibility implies attributes and operations (i.e.,
needed content such that the class performs its intended
function as per the scope statement or system narrative).
See handout, page 584, for helpful guideline for allocating class
responsibilities.
CS 4850: Senior Project – Spring 2009
Identifying Collaborations
Collaboration is required when a class cannot fulfill all of its
responsibilities on its own (i.e., the class doesn’t have
method(s) to manipulate its attributes).
Common relationships:
part-of: Subclass relationship (part of aggregate).
has-knowledge-of: Relationship to a non-sub (parent) class.
For a potential class, the names of collaborator classes and their
relationships are recorded on the class index card.
CS 4850: Senior Project – Spring 2009
Reviewing the CRC Model (1)
Reviewing CRC model index card can be done in different ways.
The following approach is described in the handout, page 588.
1. All participants in the review process are given a subset of the
index cards.
2. All use-case scenarios and corresponding use-case diagrams
should be organized into categories.
3. The review leader reads the use-case deliberately. As the
leader comes to a named object, he/she passes the token to
the person holding the corresponding class index card.
CS 4850: Senior Project – Spring 2009
Reviewing the CRC Model (2)
4. When the token is passed, the holder of the class card is
asked to describe the responsibilities noted on the card. The
group determines whether one (or more) of the
responsibilities satisfies the use-case requirement.
5. If the responsibilities and collaborations noted on the index
cards cannot accommodate the use-case, modifications are
made to the cards.
CS 4850: Senior Project – Spring 2009
Here is what you need to do
for your class project…
CS 4850: Senior Project – Spring 2009
Understand Customer Requirements (1)
Step 1: Get good understanding of customer requirements
- Write down what the customer need from the system
(functionality)




Often the customer has a vague idea of needed system
Note the difference between customer wants and needs!
Differentiate between requirements and design issues
Pay attention to doability (applicability) of needs/wants
CS 4850: Senior Project – Spring 2009
Understand Customer Requirements (2)
- Don’t rely on memorizing gathered information. Document
gathered information (requirements).
 Clearly express customer wants and needs
 Clearly identify and document all potential users (actors)
and their roles
 Develop high-level use-cases to clarify the customer’s
view of system functions and potential system interactions
CS 4850: Senior Project – Spring 2009
Develop Use-Cases (1)
Step 2: Develop reasonably detailed use-cases
- For each potential user of the system, develop high-level usecase scenario (plain-English description)
 State the use-case name, and the user's role(s) (student,
faculty, staff, etc..)
 List the user’s main interactions with the system (minimize
branching and avoid specific names and values)
 Briefly elaborate on each interaction (system functions) to
indicate if lower-level use-cases are needed
 Document the use-case (See CSIS 3600 textbook
handout)
 Develop UML diagram for each use-case
CS 4850: Senior Project – Spring 2009
Develop Use-Cases (2)
- Develop needed lower-level use-cases in a similar manner. In
our case, please use your judgment to determine reasonable
level of details for each use case your team defines.
- Review your use-cases for each actor and each role, and
save all resulted data (text and diagrams).
Note 1: In addition to specifying requirements, use-cases are
useful for developing the system design and test cases.
Note 2: Since most requirements documentation standards
predate use-cases, use-cases are often amended to the SRS.
CS 4850: Senior Project – Spring 2009
Develop Specific Requirements
Step 3: Analyze gathered requirements an develop specific
requirement specifications (See Handout)
- Specific requirements are detailed requirements intended for
the development team. But also reviewed by the customer!
- They consist of detailed and well expressed listing of
properties and functions of the system
- They are written from the customer requirements
- For this course, we’ll use table format for this course as
shown in the SRS Components document (posted)
CS 4850: Senior Project – Spring 2009
Specific Requirements for OO System
Table of Contents
1. Introduction
2. Overall description
3. Specific requirements (OO format)
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.1.6 Memory constraints
3.2 Classes/Objects
3.2.1 Class/Object 1
3.2.1.1 Attributes
3.2.1.1.1 Attribute 1
...
3.2.1.2 Methods
3.2.1.2.1 Method 1
...
3.2.2 Class/Object 2
...
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements
<<See posted SRS Components
Handout for table format. We’ll use
table format for this course>>>
4. Supporting information
IEEE Standard 830-1999 SRS.
CS 4850: Senior Project – Spring 2009
Organizing Requirements for OO systems
For OO systems, specific requirements can be organized by
- use-cases
> based on operational sequence
> desired approach by the Unified Software Development
process
- classes (We’ll follow this approach for our class projects)
> known as OO style
> promotes traceability (correspondence between
requirements and their design and implementation
> promotes reuse of classes that correspond to “real-world”
concepts
> identifies classes early on
CS 4850: Senior Project – Spring 2009
Recommended Steps Using OO Style (1)
The following steps are summary of the handout.
1. List classes you mentioned in the use-cases. Here, create a
sequence diagram for each use-case to compile your list of
classes.
2. Apply the “Class Selection Criteria” discussed in the handout,
page 583, to revise the initial list and identify potential classes.
Notice that we are actually applying the CRC method.
3. For each class, determine its responsibilities (attributes/variables
and methods). Consider using index cards (sheets of paper) for
individual classes.
CS 4850: Senior Project – Spring 2009
Recommended Steps Using OO Style (2)
4. For each class, determine its collaborators and the sort of
relations between them (is-a, uses, etc..). Write this info on the
class index card (or sheet of paper).
5. Review the index cards (or sheet of papers).
6. Draw Class Diagram(s) showing relationships between classes.
(similar to figures 21.4 through 21.7). This is your Class
Modeling.
7. In addition to class relationships (which are eventually
relationships among objects of related classes), identify other
potential relationships among objects of the system. Draw object
relationship diagram(s) (similar to figure 21.8). Remember, this
step results in your Object Relationship Modeling.
CS 4850: Senior Project – Spring 2009
Recommended Steps Using OO Style (3)
8. List all events that objects of a class must respond to (behavior
modeling for individual objects). Draw object state diagrams
(similar to figure 21.9).
9. From your object relationship modeling, list potential events
among objects of the system (behavior modeling for all objects).
Draw event trace diagrams (similar to figure 21.10).
10. Develop event flow diagram for the system by aggregating
events on the event trace diagrams (similar to figure 21.11).
Materials developed under the last three steps above represent
your Behavior Modeling of your system.
CS 4850: Senior Project – Spring 2009
Other Requirements
In addition to Class/Object requirements, you need to think
about and document the following:
- Interface requirements.
Note: GUI design is part of the design phase. However, you
may consider drafting screen designs for GUI interfaces.
- Performance requirements.
Are there processing speed, response time, efficiency,
throughput, resource allocation requirements?
- Other requirements specific to your project.
CS 4850: Senior Project – Spring 2009
SRS Content Organization (1)
As you prepare your SRS, please take a close look at the SRS
Components document posted on the website, and make a
note of the following:
1.
In section 3.2 of the SRS document, use table format to
present each class as shown in the posted SRS
Components document. This way you can reuse this
document to generate your Software Design document.
2.
Add the Sequence Diagrams, Object Collaboration
Diagram(s), and Object Relationship (collaboration)
Diagram(s) to section 3.0 of the SRS, under appropriate
titles as shown in the SRS Components document.
CS 4850: Senior Project – Spring 2009
SRS Content Organization (2)
3.
Add your CRC cards info as support martial in section 4.0
4.
The blue italic text in the tables (in file SRS Components) is
for directions. When you add your text to the templates and
tables, use non-italic, black color, regular size font.
5.
Be consistent throughout the document with regard to style
and appearance (type, style, size, color, etc…)
CS 4850: Senior Project – Spring 2009
Milestone #2
SRS Document
Due: Wednesday 2/18/09 in class
The document includes UML use-case modeling diagrams.
Each team will submit a professionally prepared printout of the
document along with a cover page.
Check the course website for a revised SRS template and other
handouts.
CS 4850: Senior Project – Spring 2009
Project Final Report
Your project final report will consist of all the deliverables you
product throughout the semester (milestones), including
software development plan (scope statement, project plan),
requirement specifications, design document, and
implementation result.
In the final report, an “Updates” section will added to include
updates to each of those deliverables, and potential future
functions and enhancements for the system.
Save copies of all deliverables!