View
279
Download
0
Category
Tags:
Preview:
Citation preview
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
Recommended