OOSE

UNIT 2

REQUIREMENT ELICITATION CONCEPTS

• FUNCTIONAL REQUIREMENTS• NONFUNCTIONAL REQUIREMENTS• COMPLETENESS,CONSISTENCY,CLARITY AND

CORRECTNESS• REALISM,VERIFIABILITY AND TRACEABILITY• GREENFIELD ENGINEERING,REENGINEERING

AND INTERFACE ENGINEERING

FUNCTIONAL REQUIREMENTS

• It describe the interactions between the system and its environment independent of its implementation

Example for Functional Requirement-Satellite Watch

• Satwatch is a wrist watch that displays the time based on its current location.Satwatch uses GPS Satellites to determine its location and internal data structures to convert thisl location into a time zone

• The information stored in satwatch and its accuracy measuring time is such that the watchowner never needs to reset the time.It adjust the time and date displayed as the watch owner crosses time zones and political boundaries

• Satwatch determine its location using GPS Satellites.During Black out periods,Satwatch assumes that it does not cross a time zone or a political boundary.It corrects its time zone as soon as the blackout period ends.

• It has two line display showing on the top line,the time and on the bottom line,the date.

• When political boundaries change,the watch owner may upgrade the software of the watch using webifywatch device and a personal computer connected to the internet.

Non-Functional Requirements• Non-Functional requirements describe the aspects of the system that are not directly related to the

functional behavior of the system• FURPS+ Model provides the following categories of non functional requirements.1)Usability – It is the ease with which a user can learn to operate, prepare inputs for, and interpret

outputs of a system or component.2)Reliability – It is the ability of a system or component to perform its required functions under stated

conditions for a specified period of time.Dependability include Reliability, Robustness and Safety– Robustness – The degree to which a system or component can function correctly in the

presence of invalid inputs or stressful environment conditions.– Safety – A measure of the absence of catastrophic consequences to the environment.

3)Performance Requirements – It is concerned with quantifiable attributes of the system such as • Response time – How quickly the system reacts to a user input.• Throughput – How much work the system can accomplish within a specified amount of time• Availability – The degree to which a system or component is operational and

accessible when required for use• Accuracy4)Supportability – Requirements are concerned with the ease of changes to the system after

deployment• Adaptability – The ability to change the system to deal with additional application domain concepts• Maintainability – The ability to change the system to deal with new technology or to fix defects• Portability – The ease with which a system or component can be transferred from one hardware or

software

Non-Functional Requirements-contd..• FURPS+ Model provides additional categories of

requirements which include1)Implementation requirement – Constraints on the

implementation of the system including the use of specific tools , programming languages or hardware platforms.

2)Interface Requirements – Constraints imposed by external systems including legacy systems and interchange formats

3)Operations requirements – Constraints on the administration and management of the system

4)Packaging requirements – Constraints on the actual delivery of the system.( e. g) constraints on the installation media for setting up the software

5)Legal Requirements – It is concerned with licensing , regulation and Certification issues

Quality requirements for Satwatch• Any user who knows how to read a digital watch and understands

international time zone abbrevations should be able to use satwatch without the user manual[usability requirement]

• Satwatch should display the correct time zone within 5 minutes at the end of a GPS blackout period.[Performance requirement]

• Satwatch should accept upgrades via the webify watch serial interface[Supportability requirement]

• All related software associated with satwatch,including the onboard software will be written using java,to comply with current company policy[Implementation Requirement]

• Satwatch complies with the physical,electrical and software interfaces defined by webify watch API 2.0[interface requirement]

• Completeness – All features of interest are described by requirementsExample of completeness : The Satwatch specification does not specify the boundary behavior when the user is standing within GPS accuracy limitations of a state’s boundary.

• Consistent – No two requirements of the specification contradict each other.Example of inconsistency: A watch does not contain any software faults need not provide an upgrade mechanism for downloading new versions of the software.

• Unambiguous – A requirement cannot be interpreted in two mutually exclusive waysExample of ambiguity – The Satwatch specification refers to time zones and political boundaries. Does the Satwatch deal with daylight saving time or not.

• Correct – The requirements describe the features of the system and environment of interest to the client and the developer, but do not describe other unintended features.Example of Fault: There are more than 24 time zones. Several countries and territories are half an hour ahead of a neighboring time zone.

• GreenField Engineering – the developer starts from scratch-no prior system exists – so the requirements are extracted from the users and the client.

• Re-engineering – It is the redesign and reimplementation of an existing system triggered by technology enablers or by business processes.

• Interface Engineering - It is the redesign of the user interface of an existing system.

REQUIREMENTS ELICITATION ACTIVITIES

• IDENTIFYING ACTORS• IDENTIFYING SCENARIOS• IDENTIFYING USE CASES• REFINING USE CASES• IDENTIFYING RELATIONSHIPS AMONG ACTORS

AND USES CASES• IDENTIFYING INITIAL ANALYSIS OBJECTS• IDENTIFYING NON FUNCTIONAL REQUIREMENTS

IDENTIFYING ACTORS

QUESTIONS FOR IDENTIFYING ACTORS• Which user groups are supported by the system

to perform their work• Which user groups execute the system’s main

functions.• Which user groups perform secondary functions ,

such as maintenance and administration.• With what external hardware or software system

will the system interact.

IDENTIFYING SCENARIOS• A scenario is a concrete, focused,informal description of a single feature of the

system from the viewpoint of a single actor.• Scenarios cannot contain description of decisions.• The scenario types include

– As-is scenarios Describe a current situation– Visionary scenarios Describe a Future System– Evaluation scenarios Describe user task against

which the system is to be evaluated– Training Scenario Tutorial used for introducing new

users to the system• In FRIENDSYSTEM example the following are the scenarios

– Warehouse on fire– Cat in tree– Earthquake

Questions for identifying Scenario

• What are the task that the actor wants the system to perform

• What information does the actor access? Who creates the data ? an it be modified or removed? By whom

• Which external language does the actor need to inform the system about ? How often ? When?

• Which events does the system need to inform the actor about ? with what latency.

IDENTIFYING USE CASESSimple USE CASE Writing Guide

• Use Cases should be named with verb phrases.• Actor should be named with noun phrases.• The boundary of the system should be clear.• Use case steps in the flow of events should be phrased in the

active voice.• The casual relationship between successive steps should be

clear.• A use case should describe a complete user transaction.• Exceptions should be described seperately.• A use case should not describe the user interface of the system• A use case should not exceed two or three pages in length.

REFINING USE CASES

Heuristics for developing scenarios and use cases• Use scenarios to communicate with users and to

validate functionality• Refine a single scenario to understand the user’s

assumptions about the system• Define many not-very-detailed scenarios to define the

scope of the system. Validate with the user.• Use mock-ups as visual support only.• Present the user with multiple and very different

alternatives.

IDENTIFYING RELATIONSHIP AMONG ACTOR AND USE CASES

• COMMUNICATION RELATIONSHIP• EXTEND RELATIONSHIP

A Behavior that happen anytime or whose occurrence can be more easily specified as an entry condition should be represented with extend relationship.

Report Emergency

Connection Down

<<extend>>

Field Officer

IDENTIFYING RELATIONSHIP AMONG ACTOR AND USE CASES

• Include RelationshipA behavior that is strongly tied to an event and that occurs only in a relatively few use cases should be represented with include relationship

Open Incident

Allocate Resources

View Map

<<include>>

<<include>>

Extend versus Include Relationship

Heuristics for extend and include relationship• Use extend relationship for exceptional , optional

or seldom occurring behavior. An example of seldom- occurring behavior is the breakdown of a resource.(e .g ) A fire truck

• Use include relationship for behavior that is shared across two or more use cases

• Use discretion when applying the above two heuristics and do not over structure the use case model.

IDENTIFYING INITIAL ANALYSIS OBJECTS

Heuristics for identifying initial analysis objects• Terms that developers or users must clarify to understand

the use case• Recurring nouns in the use case(e.g incident)• Real world entities that the system must track(e.g.,Field

Officer)• Real world process that the system must

track(e.g,Emergency Operation plan)• Use Cases(e.g Report Emergency)• Data Sources or sinks(e.g.,printer)• Always use application domain terms.

Managing Requirements Elicitation

• Negotiating Specifications with Clients:Joint Application Design

• Maintaining Traceability• Documenting Requirements Elicitation

The results of the requirement elicitation and the analysis activities are documented in Requirements Analysis Document(RAD)

Negotiating specifications with clients:Joint Application Design

JAD is a requirements method which consist of five activities

• Project definition• Research• Preparation• Session• Final document

Analysis concepts

• Analysis Object Models and Dynamic Models• Entity,Boundary and Control Objects• Generalization and Specialization

Analysis Object Models and Dynamic models

• Analysis object model focuses on the individual concepts that are manipulated by the system , their properties and their relationships.

• The Dynamic Model focuses on the behavior of the system . It includes Sequence diagram and State Charts.

Entity,Boundary and Control Objects

• Entity objects represent the persistent information tracked by the system.year , month and day are entity objects

• Boundary Objects represent the interactions between the actors and the systemButton and LCD Display are boundary objects

• Control Object are in charge of realizing use casesChangedatecontrol is control object

Generalization and SpecializationGeneralization and Specialization result in the specification of inheritance relationship between concepts . In some instances modelers call inheritance relationships generalization-specialization

Incident

Low priority Emergency Disaster

Cat In tree Earth Quake Chemical Leak

Traffic Accident Building Fire

Generalized class

Specialized class

Analysis Activities:From Use Cases to Objects

• Identifying Entity Objects• Identifying Boundary Objects• Identifying Control Objects• Mapping Use cases to Objects with sequence Diagram• Modeling interactions among objects with CRC Cards• Identifying Associations• Identifying Aggregates• Identifying Attributes• Modeling State-Dependent behavior of Individual Objects• Modeling Inheritance Relationships• Reviewing the Analysis Model

IDENTIFYING ENTITY OBJECTS

Heuristics for identifying entity objects• Terms that developers or users need to clarify in

order to understand the use case• Recurring nouns in the use cases(e.g.,incident)• Real world entities that the system needs to

track(e.g.,field officer,dispatcher)• Real world activities that the system needs to

track(e.g.,emergencyOperationsplan)• Data sources or sinks(e.g.,printer)

IDENTIFYING BOUNDARY OBJECTS

Heuristics for identifying Boundary objects• Identify user interface controls that the user needs to initiate the

use case(e.g.,ReportEmergencyButton)• Identify forms the users needs to enter data into the

system(e.g.,EmergencyReportForm)• Identify notices and messages the system uses to respond to the

user(e.g.,Acknowledgment Notice)• When multiple actors are involved in a use case,identify actor

terminals(e.g.,DispatcherStation)• Do not model the visual aspects of the interfaces with boundary

objects• Always use the end user’s terms for describing interfaces.

IDENTIFYING CONTROL OBJECTS

Heuristics for identifying control objects• Identify one control object per use case• Identify one control object per actor in the use

case• The life span of a control object should cover

the extent of the use caseControl Objects for the Report Emergency Use Case• Report Emergency Control• Manage Emergency Control

MAPPING USE CASES TO OBJECTS WITH SEQUENCE DIAGRAM

• A Sequence diagram ties use cases with objects• Sequence diagrams depict the lifetime of objectsHeuristics for drawing sequence diagram• The first column should correspond to the actor who

initiated the use case• The second column should be a boundary object• The third column should be the control object• Control objects are created by boundary objects• Boundary objects are created by control objects• Entity objects are accessed by control and boundary objects

MAPPING USE CASES TO OBJECTS WITH SEQUENCE DIAGRAM

Report Emergency

ButtonReport

Emergency Control

Press()<<create>>

Report Emergency

Form

<<create>>

Fill Contents()

Submit()

Submit Report()Emergency

Report<<create>>

Manage Emergency

Control

Submit Report To Dispatcher()<<destroy>>

Field Officer

MODELING INTERACTIONS AMONG OBJECTS WITH CRC CARDS

• An alternative for identifying interactions among objects are CRC Cards

• CRC stands for Classes, Responsibilities and collaborator

• CRC can be used during modeling sessions with teams

EXAMPLE OF CRC CARDS

REPORT EMERGENCY CONTROLRESPONSIBILITIESCollect input from Field OfficerControl sequence of forms during Emergency Reporting

COLLABORATORSEmergencyReportFormEmergencyReportAcknowledgementNotice

IDENTIFYING ASSOCIATIONS

Heuristics for identifying Associations• Examine verb phrases.• Name associations and roles precisely.• Use qualifiers as often as possible to identify

namespaces and key attributes.• Eliminate any association that can be derived from

other associations.• Do not worry about multiplicity until the set of

association is stable.• Too many associations make a model unreadable.

IDENTIFYING AGGREGATES• A Composition aggregation indicates that the

existence of the parts depends on the whole. A solid diamond indicates composition aggregation.

• Shared aggregation indicates the whole and the part can exists independently. It is represented as hollow diamond.

State

Country

Township

FireStation

FireEngine FireFighter

Shared Composi

tion

IDENTIFYING ATTRIBUTES

• Attributes are properties of individual objects• Attributes have

NameA brief Description Name

A type type

Description

Emergency ReportemergencyType:{fire,traffic,other}

Location:StringDescription:String

Heuristic for identifying attributes• Examine possessive phrases• Represent stored state as an attribute of the

entity object• Describe each attribute• Do not represent an attribute as an object;use

an association instead.• Do not waste time describing fine details

before the object structure is stable.

MODELLING STATE DEPENDENT BEHAVIOR-State chart for Incident

• Active

Reported Assessment

Response Disengagement

Inactive Closed Archived

Field Officer arrives on site

Dispatcher allocates Resources

Field Officer request additional resources

Field Officer releases resources

All resources deallocated

All resources submitted reports

When date > 1 yr

MODELLING INHERITANCE RELATIONSHIP BETWEEN OBJECTS

POLICE OFFICER

FIELD OFFICER DISPATCHER

MANAGING ANALYSIS

• Documenting Analysis• Assigning Responsibilities• Communicating about Analysis• Iterating over the Analysis Model• Client Sign-Off

DOCUMENTING ANALYSISRequirement Analysis Document1.Introduction2.Current System3.Proposed System

3.1 Overview3.2 Functional Requirements3.3 Non-Functional Requirements3.4 system Models

3.4.1 Scenarios3.4.2 Use Case Model3.4.3 Object Model3.4.3.1 Data Dictionary3.4.3.2 Class diagrams3.4.4 Dynamic models3.4.5 User Interface

4. Glossary

ASSIGNING RESPONSIBILITIES• END USER• CLIENT• ANALYST• ARCHITECT• DOCUMENT EDITOR• CONFIGURATION MANAGER• REVIEWER

COMMUNICATING ABOUT ANALYSIS

Contributing Factors include• Different backgrounds of participants• Different expectations of stakeholders• New teams• Evolving system

ITERATING OVER THE ANALYSIS MODEL

The requirements activity can be viewed as several steps

• Brainstorming – The objective of brainstorming process is to generate as many ideas as possible without necessarily organizing them.

• Solidification – Functionality is organized into groups of use cases with their corresponding interfaces.

• Maturity – When changes are necessary , the client and developer define the scope of the change and its desired outcome and change the analysis model.

CLIENT SIGN-OFF

• The client sign off represents the acceptance of the analysis model by the client.In addition they agree on

• A list of priorities(High,Medium,Low)• A revision Process• A list of criteria that will be used to accept or reject the

system• A schedule and Budget

An example of revision process• Client Developer

Report Problem or Change Request

Review Proposed change

Design Change

Update Requirements

Archive Request

Design TestUpdate Design

Update Code

Review actual change Execute all

relevant test

Change approved