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

CS 4850: Senior Project

Spring 2009

Overview of Software Requirementsand OO Analysis


Introduction toSoftware Requirements Analysis


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.


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.


Overview ofObject-Oriented Analysis


The Big Picture - 1

Domain Level

System Level

Domain Engineering

OO Engineering

OO AnalysisOO DesignImplementationOO TestingDeployment


The Big Picture - 2

OO AnalysisOO DesignImplementationOO TestingDeployment

ObjectRelationship

Modeling

ClassModeling

ObjectBehaviorModeling


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.)


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)


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)


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


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


OOA Process

1. Define use cases2. Extract/Select candidate classes3. Identify attributes for each class4. Specify methods that service the attributes5. Establish basic class relationships6. Define a class hierarchy7. Build a behavioral model

Repeat these steps for lower-level (other) use-cases.

Steps 2 through 5 may be done using CRC modeling.


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:


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.


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.


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.


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.


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.


Here is what you need to dofor your class project…


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


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


Develop Use-Cases (1)

Step 2: Develop reasonably detailed use-cases

- For each potential user of the system, develop high-level use-case 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


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.


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)


Specific Requirements for OO System

Table of Contents1. Introduction2. Overall description3. 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 ComponentsHandout for table format. We’ll use table format for this course>>>

4. Supporting information

IEEE Standard 830-1999 SRS.


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


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.



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.



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.


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.


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.


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…)


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.


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!

Documents

CS 4850: Senior Project – Spring 2009 CS 4850: Senior Project Spring 2009 Overview of Software Requirements and OO Analysis