Object Oriented Analysis and Design 1 Chapter 3 Understanding Requirements Requirements Vision Use-Case Modeling Software Requirements Specification

Object Oriented Analysis and Design 1

Chapter 3 Understanding Requirements Requirements Vision Use-Case Modeling Software Requirements Specification Requirements Management Case Study and Project


Requirements


3.1 RequirementsWhat is RequirementsTypes of RequirementsRequirements Documents


What is requirement? Requirements are capabilities and conditions to

which the system (and more broadly, the project) must conform. [JBR99].

The purpose of Requirements is: To provide system developers with a better understanding

of the system requirements. To define the boundaries of (delimit) the system. To provide a basis for planning the technical contents of

iterations. To provide a basis for estimating cost and time to develop

the system. To define a user-interface for the system, focusing on the

needs and goals of the users.


Requirements Factors on challenged software projects

37% of factors related to problems with requirements,


Requirements Management Requirements management is a systematic

approach to eliciting, organizing, and documenting the requirements of

the system establishing and maintaining agreement between the

customer and the project team on the changing requirements of the system.

Keys to effective requirements management include maintaining a clear statement of the requirements, along

with applicable attributes for each requirement type traceability to other requirements and other project

artifacts.


Types of Requirements – FURPS+

Functional features, capabilities, security.

Usability human factors, help, documentation.

Reliability frequency of failure, recoverability, predictability.

Performance response times, throughput, accuracy, availability, resource

usage. Supportability

adaptability, maintainability, internationalization, configurability.


Types of Requirements – FURPS+ The "+" in FURPS+ indicates ancillary and sub-

factors, such as: Implementation

• resource limitations, languages and tools, hardware, ...

Interface

• constraints imposed by interfacing with external systems.

Operations

• system management in its operational setting. Packaging Legal

• licensing and so forth.


Types of Requirements – RUP Requirements are categorized as functional

(behavioral) or non-functional (everything else); Functional Requirements

Functional requirements are explored and recorded in

• the Use-Case Model • the system features list of the Vision artifact.

Non-functional Requirements Other requirements can be recorded in the use cases they

relate to, or in the Supplementary Specifications artifact.


Requirement Documents Vision

The Vision artifact summarizes high-level requirements that are elaborated in these other documents.

The Vision is a general vision of the core project's requirements, and provides the contractual basis for the more detailed technical requirements.

Include:

• Problem Statement• User or Stakeholder Descriptions• Product Overview • Features • Constraints


Requirement Documents SRS (Software Requirements Specification)

Functional requirements • Use case Model

Non-functional requirements• Supplementary Specification

Glossary • records and clarifies terms used in the requirements.

• also encompasses the concept of the data dictionary, which records requirements related to data, such as validation rules, acceptable values, and so forth

User-Interface Prototype

Prototypes are a mechanism to clarify what is wanted or possible.


Requirement Artifacts in UP


Vision


3.2 Vision Introduction Template Example How to develop Vision


Vision - Introduction The Vision document provides

a complete vision for the software system under development and supports the contract between the funding authority and the development organization.

The vision document is written from the customers' perspective, focusing on the essential features of the system and acceptable levels of

quality.

The Vision should include a description of what features will be included as well as those considered but

not included. It should also specify operational capacities (volumes, response times,

accuracies), user profiles (who will be using the system), and inter-operational interfaces with entities outside the system boundary, where applicable.

The Vision document provides the contractual basis for the requirements visible to the stakeholders.


Vision - Introduction The Vision document

is created early in the inception phase, and it is used as a basis for the Business Case and the

first draft of the Risk List The Vision document

serves as input to use-case modeling, and is updated and maintained as a separate artifact

throughout the project.


Vision - Introduction Purpose of Vision

Gain agreement on what problems need to be solved.

Identify stakeholders to the system. Define the boundaries of the system. Describe primary features of the system.


Vision - Template for small project 1. Introduction 2. Positioning

2.1 Problem Statement 2.2 Product Position Statement

3. Stakeholder and User Descriptions 3.1 Stakeholder Summary 3.2 User Summary 3.3 Key High-Level Goals and Problems of the

Stakeholders 3.4 User-Level Goals 3.5 User environment


Vision - Template for small project 4. Product Overview

4.1 Product Perspective 4.2 Assumptions and Dependencies

5. Product Features 5.1 <aFeature> 5.2 <anotherFeature>

6. Other Requirements and Constraints


Vision - Commentary to Template Problem Statement

Provide a statement summarizing the problem being solved by this project.

The following format may be used:The problem of [describe the problem]

affects [the stakeholders affected by the problem]

the impact of which is [what is the impact of the problem?]

a successful solution would be

[list some key benefits of a successful solution]


Vision - Commentary to Template Product Position Statement

Provide an overall statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace.

The following format may be used:

For [target customer]

Who [statement of the need or opportunity]

The (product name) is a [product category]

That [statement of key benefit; that is, the compelling reason to buy]

Unlike [primary competitive alternative]

Our product [statement of primary differentiation]


Vision - Commentary to Template User Summary

Present a summary list of all identified users. The following format may be used:

Name Description Responsibilities Stakeholder

[Name the user type.]

[Briefly describe what they represent with respect to the system.]

[List the user’s key responsibilities with regard to the system being developed; for example:captures detailsproduces reportscoordinates workand so on]

[If the user is not directly represented, identify which stakeholder is responsible for representing the user’s interest.]


Vision - Commentary to Template Product Perspective

This subsection puts the product in perspective to other related products and the user’s environment.

If the product is independent and totally self-contained, state it here.

If the product is a component of a larger system, then this subsection needs to relate how these systems interact and needs to identify the relevant interfaces between the systems.

One easy way to display the major components of the larger system, interconnections, and external interfaces is with a block diagram.• System context diagram• High-level deployment diagram


Vision - Commentary to Template Product Features

Use cases are not necessarily the only way one needs to express functional requirements.

An alternative, a complementary way to express system functions is with features, or more specifically in this context, system features,

System features are high-level, terse statements summarizing system functions.

A system feature is "an externally observable service provided by the system which directly fulfills a stakeholder need" [Kruchten00].

Features are things a system can do. The point of system features in the Vision is

• to summarize the functionality, • not decompose it into a long list of fine-grained elements.

Keep feature descriptions at a general level. • Focus on capabilities needed and why (not how) they should be

implemented. • Avoid design.• It is common to organize a two-level hierarchy


Vision - Commentary to Template Other Requirements in the Vision

In the Vision, system features briefly summarize functional requirements expressed in detail in the use cases.

Likewise, the Vision can summarize other requirements (for example, reliability and usability) that are detailed in the Special Requirements sections of use cases, and in the Supplementary Specification (SS).


Vision - Example Course Registration System example

Vision 1 NextGen example


Vision - How to develop Vision Gain agreement on the problem being solved Identify stakeholders Define the system boundaries Identify constraints to be imposed on the system Formulate problem statement Define features of the system Evaluate your results


Vision - Checkpoints Have you fully explored what the "problem behind the

problem" is? Is the problem statement correctly formulated? Is the list of stakeholders complete and correct? Does everyone agree on the definition of the system

boundaries? If system boundaries have been expressed using actors, have

all actors been defined and correctly described? Have you sufficiently explored constraints to be put on the

system? Have you covered all kinds of constraints - for example

political, economic, and environmental. Have all key features of the system been identified and

defined? Will the features solve the problems that are identified? Are the features consistent with constraints that are identified?


3.3 Use-Case ModelingKey ConceptsUse-Case DiagramUse-Case SpecificationRelationship between Use-caseCheckpoints


Key Concepts


What Is System Behavior? System behavior is how a system acts and

reacts. It is the outwardly visible and testable activity of

a system System behavior is captured in use cases.

Use cases describe the system, its environment, and the relationship between the system and its environment.


What Is a Use-Case Model? A model that describes a

system’s functional requirements in terms of use cases

A model of the system’s intended functionality (use cases) and its environment (actors)

Student

View Report Card

Register for Courses

Login


What Are the Benefits of a Use-Case Model? Used to communicate with the end users and

domain experts Provides buy-in at an early stage of system

development Insures a mutual understanding of the requirements

Used to identify Who interacts with the system and what the system

should do The interfaces the system should have

Used to verify All requirements have been captured The development team understands the requirements


Major Concepts in Use-Case Modeling An actor represents anything

that interacts with the system. A use case is a sequence of

actions a system performs that yields an observable result of value to a particular actor.

Use Case

Actor


What Is an Actor? Actors are not part of the system. Actors represent roles a user of the

system can play. They can represent a human, a

machine, or another system. They can actively interchange

information with the system. They can be a giver of information. They can be a passive recipient of

information.

Actors are EXTERNAL.

Actor


Useful Questions in Finding Actors? Who will supply, use, or remove information? Who will use this functionality? Who is interested in a certain requirement? Where in the organization is the system

used? Who will support and maintain the system? What are the system’s external resources? What other systems will need to interact with

this one? Actor


Focus on the Roles An actor

represents a role that a human, hardware device, or another system can play.

?


A User May Have Different Roles

Charlie

Charlie asstudent

Charlie asprofessor

Professor

Student


Practice: Find the Actors In the Course Registration System

Requirements document, read the Problem Statement for the Course Registration case study.

As a group, identify the following Actors Description of the actor


Practice: Solution

Billing System

Registrar

ProfessorCourse Catalog

Student

A person who is registered to take courses at the University

The unabridged catalog of all courses offered by the University

The external system responsible for student billing

A person who is teaching classes at the University

The person who is responsible for the maintenance of the course registration system


What Is a Use Case?

Use Case

A sequence of actions a system performs that yields an observable result of value to a particular actor


Use Cases and Actors A use case models a dialog between actors

and the system. A use case is initiated by an actor to invoke a

certain functionality in the system.

Actor Use Case

Communicates Association


How to Find Use Cases Answer the following questions to

find use cases. For each actor you have identified,

what are the tasks the system would be involved in?

Does the actor need to be informed about certain occurrences in the system?

Will the actor need to inform the system about sudden, external changes?

What information must be modified or created in the system?


Naming the Use Case The name indicates what is

achieved by its interactions with the actor(s).

The name may be several words in length.

No two use cases should have the same name.

Register forCourses

Login

Maintain StudentInformation


Use-Case Diagram


Use case diagram Captures system functionality as seen by

users Built in early stages of development Purpose

Specify the context of a system Capture the requirements of a system Validate a system’s architecture Drive implementation and generate test cases

Developed by analysts and domain experts


How Would You Read This Diagram?

Course Catalog

View Report Card

Register for Courses

Submit Grades

Select Courses to Teach

Student

Professor

Billing System

Maintain Student Information

Maintain Professor Information

Login

Close Registration

Registrar


Use Case Diagram - Example

Development Manager

User Management

System ConfigurationAdministrator

Normal User

User Authentication

Query

Project Management

Project Manager


Use-Case Specification


Use-Case Specifications

Name Brief description Flows of Events Relationships Activity diagrams Use-Case diagrams Special requirements Pre-conditions Post-conditions Other diagrams

Use-Case Specifications

...

Use-Case Model

Actors

Use Cases


Use-Case Specifications - Flow of Events• A use case describes what a system (or a subsystem,

class, or interface) does but it does not specify how it does it.

• You can specify the behavior of a use case by describing a flow of event in text clearly enough for outsider to understand it easily.

• When you write this flow of events, you should include how and when the use case starts and ends, when the use case interacts with the actors and what objects are exchanged, and the basic flow and alternative flow of the behavior.


Use-Case Flow of EventsHas one normal, basic flow Several alternative flows

Regular variantsOdd casesExceptional flows handling error situations


Use-Case Specifications - Scenarios • A use case actually describes a set of sequences in

which each sequence in the set represents one possible flow through all those variations.

• A scenario is a specific sequence of actions that illustrates behavior.

• Scenarios are to use cases as instances are to classes, meaning that a scenario is basically one instance of a use case.


What Are Scenarios ? A scenario is an instance of a use case


What Is an Activity Diagram? An activity diagram in the use-case model can be

used to capture the activities in a use case. It is essentially a flow chart, showing flow of control

from activity to activity.

Flow of EventsThis use case starts when the Registrar requests that the system close registration.

1. The system checks to see if registration is in progress. If it is, then a message is displayed to the Registrar and the use case terminates. The Close Registration processing cannot be performed if registration is in progress.

2. For each course offering, the system checks if a professor has signed up to teach the course offering and at least three students have registered. If so, the system commits the course offering for each schedule that contains it.


Select Course

Check Schedule

Check Pre-requisites

Assign to course

Resolve conflicts

Update schedule

[ student added to the course ]

[ add course ]Delete Course

[ delete course ]

[ checks completed ] [ checks failed ]

Example: Activity DiagramActivity State

Synchronization Bar (Fork)

Guard ConditionSynchronization Bar (Join)

Decision

Concurrent threads

Transition


Use-Case Specifications - Example- User Management

1. Brief Description This use case is for adding and deleting users. When adding user, the privilege of the user will be assigned.2. Basic Flow B1. Start of use case Actor chooses User Management in main screen. B2. Prompt welcome screen System shall prompt actor the user management welcome screen. A1. Choose delete user B3. Choose add user Actor chooses Add User. B4. Prompt add user screen System shall prompt actor the add user screen which needs actor to input some information. These information include: User Name, User ID, User Password, User Role. B5. Submit Actor inputs the information and submits the screen. E1. User ID already exists E2. Not enough information B6. Prompt success System shall prompt actor success information.


Use-Case Specifications - Example3. Alternative FlowsA1. Choose Delete User From B2. Prompt welcome screenA1.1 Choose delete Actor chooses delete user.A1.2 Prompt delete user screen System shall prompt actor the delete user screen. In this screen, system shall lists all the user ID stored in system.A1.3 Choose user to delete Actor chooses the user ID to delete and submit this screen. E3. No user ID chosenA1.4 Prompt success System shall prompt actor success information.

4. Exception FlowsE1. User ID already exists From B5. Submit, The User ID actor inputs has already existed in the system. The system shall prompt actor to try another User ID。E2. Not enough information From B5. Submit, If actor does not input all the information, system can not add a user. The system shall prompt actor to input all the information.E3. No user ID chosen From A1.3 Choose user to delete, If actor does not choose a user to delete before submitting the screen, the system shall prompt actor an error that he/she should choose a user to delete.


Relationship between Use-Case


Relationship between Use-case (optional) include extend generalization


Relationship between Use-cases - include• <<include>> – An include relationship from use case A to use case B indicates that an instance of the use case A will also contain the behavior as specified by B. The behavior is included at the location which defined in A.

Offer a line of credit

Submit a load request

Perform credit check

<<include>> <<include>>


Relationship between Use-cases - include

<<include>>: Functional Decomposition Problem:A function in the original problem statement is too complex to be solvable

immediatelySolution:Describe the function as the aggregation of a set of simpler functions. The

associated use case is decomposed into smaller use cases

ManageIncident

CreateIncident

HandleIncident

CloseIncident

<<include>>

<<include>>

<<include>>


Relationship between Use-cases - include

<<include>>: Reuse of Existing Functionality

Problem:There are already existing functions. How can we reuse them?

Solution:The include association from a use case A to a use case B indicates that an instance of the use

case A performs all the behavior described in the use case B (“A delegates to B”)

Example: The use case “ViewMap” describes behavior that can be used by the use case “OpenIncident”

(“ViewMap” is factored out)

Note :The base case cannot exist alone. It is always called with the supplier use case

AllocateResources

OpenIncident

ViewMap

<<include>>

<<include>>

Base Usecase

Supplier Usecase


Relationship between Use-cases - extend

<<extend>>– An extend relationship from use case A to use case B indicates that an instance of use case B may be augmented (subject to specific conditions specified in the extension) by the behavior specified by A. The behavior is inserted at the location defined by the extension point in B which is referenced by the extend relationship.

Evaluate loan request

Request additional credit information

Refer loan request to loan committee

<<extend>>

<<extend>>


Relationship between Use-cases - extendProblem:The functionality in the original problem statement needs to be extended.Solution:An extend association from a use case A to a use case B indicates that use case B is

an extension of use case A.Example:The use case “ReportEmergency” is complete by itself , but can be extended by the

use case “getHelp” for a specific scenario in which the user requires help

Note :In an extend assocation, the base use case can be executed without the use case extension

getHelpFieldOfficer ReportEmergency

<<extend>>


Relationship between Use-cases - Generalization

Withdraw funds

Withdraw from savings

Withdraw from checking

Request credit card advance

With the introduction of UML 1.3, a new relationship between use cases was introduced - generalization

Generalization – A generalization from use case A to use case B indicates that A is a specialization of B.


Relationship between Use-cases - GeneralizationProblem:You have common behavior among use cases and want to factor this out.

Solution:The generalization association among use cases factors out common behavior. The

child use cases inherit the behavior and meaning of the parent use case and add or override some behavior.

Example:Consider the use case “ValidateUser”, responsible for verifying the identity of the

user. The customer might require two realizations: “CheckPassword” and “CheckFingerprint”

Parent usecaseChild usecase

CheckPasswordValidateUser

CheckFingerprint


Checkpoints


Checkpoints: Requirements: Use-Case Model Is the use-case model

understandable? By studying the use-case model, can

you form a clear idea of the system's functions and how they are related?

Have all functional requirements been met?

Does the use-case model contain any superfluous behavior?

Is the division of the model into use-case packages appropriate?


Checkpoints: Requirements: Actors Have all the actors been identified? Is each actor involved with at least one

use case? Is each actor really a role? Should any

be merged or split? Do two actors play the same role in

relation to a use case? Do the actors have intuitive and

descriptive names? Can both users and customers understand the names?


Checkpoints: Requirements: Use-Cases Is each use case involved with at least

one actor? Is each use case independent of the

others? Do any use cases have very similar

behaviors or flows of events? Do the use cases have unique,

intuitive, and explanatory names so that they cannot be mixed up at a later stage?

Do customers and users alike understand the names and descriptions of the use cases?


Checkpoints: Requirements: Use-Case Specifications Is it clear who wishes to perform a use-

case? Is the purpose of the use-case also

clear? Does the brief description give a true

picture of the use-case? Is it clear how and when the use-case's

flow of events starts and ends? Does the communication sequence

between actor and use-case conform to the user's expectations?

Are the actor interactions and exchanged information clear?

Are any use-cases overly complex?


Review: Requirements Overview What are the main artifacts of Requirements? What are the Requirements artifacts used for? What is a use-case model? What is an actor? What is a use case? List examples of use case

properties. What is the difference between a use-case and a

scenario? What is a supplementary specification and what

does it include? What is a glossary and what does it include?


3.4 Software Requirements Specification Identifying other requirements

Supplementary Specifications Glossary


Supplementary Specifications


SupplementarySpecification

Supplementary Specification

Functionality Usability Reliability Performance Supportability Design constraints


Supplementary Specification - Example Review the Supplementary Specification

provided in the Course Registration Requirements Document


Glossary


Glossary

Glossary

Course Registration System Glossary

1. Introduction

This document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information.

2. Definitions

The glossary contains the working definitions for the key concepts in the Course Registration System.

2.1 Course: A class offered by the university.

2.2 Course Offering: A specific delivery of the course for a specific semester – you could run the same course in parallel sessions in the semester. Includes the days of the week and times it is offered.

2.3 Course Catalog: The unabridged catalog of all courses offered by the university.


Glossary - Example Review through the Glossary provided in the

Course Registration Requirements Document


3.5 Requirements ManagementMaking sure you

Solve the right problemBuild the right system

By taking a systematic approach toeliciting organizing documenting and managing

the changing requirements of a software application.


Aspects of Requirements Management Analyze the Problem Understand User Needs Define the System Manage Scope Refine the System Definition Build the Right System


Problem

Solution Space

Problem Space

Needs

Features

Use Cases and SoftwareRequirements

Test ProceduresDesign User

Docs

The The Product Product To Be To Be BuiltBuilt

Traceability

Map of the Territory


3.6 Case Study and Project Inception Phase Case Study - CRS Project - Inception Phase


Inception Phase


Inception Phase Inception Phase :

Define the scope of the project and develop business case

The primary objectives of the inception phase include: Establishing the project's software scope and boundary

conditions, including an operational vision, acceptance criteria and what is intended to be in the product and what is not.

Discriminating the critical use cases of the system, the primary scenarios of operation that will drive the major design trade-offs.

Exhibiting, and maybe demonstrating, at least one candidate architecture against some of the primary scenarios

Estimating the overall cost and schedule for the entire project.

Estimating potential risks. Preparing the supporting environment for the project.


What Artifacts May Start in Inception?Artifact Comment

Vision and Business Case Describes the high-level goals and constraints, the business case, and provides an executive summary.

Use-Case Model Describes the functional requirements, and related non-functional requirements.

Supplementary Specification

Describes other requirements.

Glossary Key domain terminology.

Risk List & Risk Management Plan

Describes the business, technical, resource, schedule risks, and ideas for their mitigation or response.

Prototypes and proof-of-concepts

To clarify the vision, and validate technical ideas.

Iteration Plan Describes what to do in the first elaboration iteration.

Phase Plan & Software Development Plan

Low-precision guess for elaboration phase duration and effort.Tools, people, education, and other resources.

Development Case A description of the customized UP steps and artifacts for this project. In the UP, one always customizes it for the project.


Inception Phase - a suggested sequence 1. Write a brief first draft of the Vision. 2. Identify user goals and the supporting us

e cases. 3. Write some use cases and start the Suppl

ementary Specification. 4. Refine the Vision, summarizing informati

on from these.


Checkpoint: What Happened in Inception? Inception is a short step

to determine basic feasibility, risk, and scope.

Some likely activities and artifacts in inception include: a short requirements workshop most actors, goals, and use cases named most use cases written in brief format; 10-20% of the use cases are written in fully

dressed detail to improve understanding of the scope and complexity. most influential and risky quality requirements identified version one of the Vision and Supplementary Specification written risk list technical proof-of-concept prototypes and other investigations to explore the

technical feasibility of special requirements user interface-oriented prototypes to clarify the vision of functional requirements recommendations on what components to buy/build/reuse, to be refined in

elaboration high-level candidate architecture and components proposed plan for the first iteration candidate tools list


Sample requirements effort across the early iterations


Case Study (Covered in GCIS501)


Case Study - Course Registration System Vision SRS - Use Case Model SRS - Supplementary Specification SRS - Glossary


Project – Inception Phase


Project - Requirements Work as a team (max 3 person) Select topic Write the following Requirements artifacts:

Vision SRS

• Use-case model(Use-case diagram, Use-case specification, Activity Diagram)

• Supplementary specification • Glossary• User Interface (optional)