requirements analysis
DESCRIPTION
- PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/1.jpg)
1
Chapter 8Analysis Modeling
Adapted by Dan Fleck from:- Roger Pressman’s Slides- http://www.informatics.sussex.ac.uk/users/lb203/se/SE04.pdf- Jochen Rick’s slides from GA Institute of Technology- http://webfuse.cqu.edu.au/Courses/aut2001/95169/
Extra_Examples/DFD_Example_1/- System Analysis and Design slides edited by Yale Braunstein
![Page 2: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/2.jpg)
2
Requirements Analysis Requirements analysis
specifies software’s operational characteristics indicates software's interface with other system elements establishes constraints that software must meet
Requirements analysis allows the software engineer (called an analyst or modeler in this role) to: elaborate on basic requirements established during earlier
requirement engineering tasks build models that depict user scenarios, functional activities,
problem classes and their relationships, system and class behavior, and the flow of data as it is transformed.
![Page 3: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/3.jpg)
3
Analysis Phase: What is it?
systemdescription
analysismodel
designmodel
Three objectives:
• To describe what the customer requires
• To establish a basis for the creation of a software design
• To define a set of requirements that can be validated once the software is built
Three objectives:
• To describe what the customer requires
• To establish a basis for the creation of a software design
• To define a set of requirements that can be validated once the software is built
![Page 4: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/4.jpg)
4
Analysis Modeling Approaches
Structural analysis: The data: The model defines their attributes and
relationships. The processes that transform the data: The
model shows how they transform the data objects as they flow through the system.
Object-oriented analysis: Focus: Classes and their inter-relationships UML is predominantly object-oriented
But don’t be to dogmatic!
![Page 5: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/5.jpg)
5
Elements of the Analysis Model
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Scenario-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Class-based elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Flow-oriented elements
State diagrams
Sequence diagrams
Behavioral elements
Analysis Model
![Page 6: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/6.jpg)
6
Data Modeling
examines data objects independently of processing
focuses attention on the data domain
creates a model at the customer’s level of abstraction
indicates how data objects relate to one another
![Page 7: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/7.jpg)
7
What is a Data Object?
ObjectObject ——something that is described by a setsomething that is described by a setof attributes (data items) and that will be of attributes (data items) and that will be manipulated within the software (system)manipulated within the software (system)
each each instanceinstance of an object (e.g., a book) of an object (e.g., a book) can be identified uniquely (e.g., ISBN #) can be identified uniquely (e.g., ISBN #)
each plays a necessary role in the systemeach plays a necessary role in the systemi.e., the system could not function without i.e., the system could not function without access to instances of the objectaccess to instances of the object
each is described by attributes that are each is described by attributes that are themselves data itemsthemselves data items
What are some typical data objects?
![Page 8: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/8.jpg)
8
Typical Data Objects
external entitiesexternal entities (printer, user, sensor)(printer, user, sensor)thingsthings (e.g, reports, displays, signals) (e.g, reports, displays, signals) occurrences or eventsoccurrences or events (e.g., interrupt, alarm)(e.g., interrupt, alarm)rolesroles (e.g., manager, engineer, salesperson)(e.g., manager, engineer, salesperson)organizational unitsorganizational units (e.g., division, team)(e.g., division, team)placesplaces (e.g., manufacturing floor) (e.g., manufacturing floor)
structuresstructures (e.g., employee record)(e.g., employee record)
![Page 9: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/9.jpg)
9
Data Objects and Attributes
A data object contains a set of attributes that A data object contains a set of attributes that act as an aspect, quality, characteristic, or act as an aspect, quality, characteristic, or descriptor of the objectdescriptor of the object
object: automobileobject: automobileattributes:attributes: makemake modelmodel body typebody type priceprice options codeoptions code
How do data objects differ from OO classes or do they?
![Page 10: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/10.jpg)
10
What is a Relationship?
relationshiprelationship ——indicates “connectedness”; indicates “connectedness”; a "fact" that must be "remembered" a "fact" that must be "remembered" by the system and cannot or is not computed by the system and cannot or is not computed or derived mechanicallyor derived mechanically
several instances of a relationship can exist objects can be related in many different ways
![Page 11: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/11.jpg)
11
ERD Notation
(0, m) (1, 1)
objectobject objectobjectrelationshiprelationship11 22
One common form:One common form:
(0, m)(0, m)
(1, 1)(1, 1)
objectobject11 objectobject22relationshiprelationship
Another common form:Another common form:attributeattribute
See http://www.smartdraw.com/tutorials/software/erd/tutorial_01.htm for a tutorial on how to draw entity relationship diagrams.
![Page 12: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/12.jpg)
12
The ERD: An Example
(1,1)(1,1) (1,m)(1,m)placesplacesCustomerCustomer
requestrequestfor servicefor service
generatesgenerates (1,n)(1,n)
(1,1)(1,1)
workworkorderorder
workworktaskstasks
materialsmaterials
consistsconsistsofof
listslists
(1,1)(1,1)(1,w)(1,w)
(1,1)
(1,i)(1,i)
selectedselectedfromfrom
standardstandardtask tabletask table
(1,w)(1,w)
(1,1)(1,1)
![Page 13: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/13.jpg)
13
The Flow Model
Every computer-based system is an Every computer-based system is an information transform ....information transform ....
computercomputerbasedbased
systemsysteminputinput outputoutput
![Page 14: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/14.jpg)
14
Flow Modeling Notation
external entityexternal entity
processprocess
data flowdata flow
data storedata store
![Page 15: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/15.jpg)
15
External Entity
A producer or consumer of dataA producer or consumer of data
Examples: a person, a device, a sensorExamples: a person, a device, a sensor
Another example: computer-basedAnother example: computer-basedsystemsystem
Data must always originate somewhereData must always originate somewhereand must always be sent to somethingand must always be sent to something
![Page 16: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/16.jpg)
16
Process
A data transformer (changes inputA data transformer (changes inputto output)to output)
Examples: compute taxes, determine area,Examples: compute taxes, determine area,format report, display graph format report, display graph
Data must always be processed in some Data must always be processed in some way to achieve system functionway to achieve system function
![Page 17: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/17.jpg)
17
Data Flow
Data flows through a system, beginningData flows through a system, beginningas input and be transformed into output.as input and be transformed into output.
computecomputetriangle triangle
areaarea
basebase
heightheight
areaarea
![Page 18: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/18.jpg)
18
Data Stores
DataData is often stored for later use.is often stored for later use.
look-uplook-upsensorsensor
datadata
sensor #sensor #
report requiredreport required
sensor #, type, sensor #, type, location, agelocation, age
sensor datasensor data
sensor numbersensor number
type, type, location, agelocation, age
![Page 19: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/19.jpg)
19
Data Flow Diagramming:Guidelines
all icons must be labeled with meaningful names
the DFD evolves through a number of levels of detail
always begin with a context level diagram (also called level 0)
always show external entities at level 0 always label data flow arrows do not represent procedural logic
![Page 20: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/20.jpg)
20
Constructing a DFD—I
review the data model to isolate data objects and use a grammatical parse to determine “operations”
determine external entities (producers and consumers of data)
create a level 0 DFD
![Page 21: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/21.jpg)
21
Level 0 DFD Examplesuseruser
processing processing requestrequest
videovideosourcesource NTSCNTSC
video signalvideo signal
digitaldigitalvideovideo
processorprocessor
requestedrequestedvideovideosignalsignal
monitormonitor
![Page 22: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/22.jpg)
22
Constructing a DFD—II
write a narrative describing the transform
parse to determine next level transforms
“balance” the flow to maintain data flow continuity
develop a level 1 DFD use a 1:5 (approx.) expansion ratio
![Page 23: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/23.jpg)
23
The Data Flow Hierarchy
PPaa bbxx yy
p1p1p2p2
p3p3p4p4 55
aa
bb
cc
ddee
ff
gg
level 0level 0
level 1level 1
![Page 24: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/24.jpg)
24
Example DFD: Level 1
![Page 25: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/25.jpg)
25
DFD: A practical example
Launched Dec. 11, 1998, the Climate Orbiter plunged too steeply into the Martian atmosphere Sept. 23, 1999, and either burned up or crashed. In an initial failure report released Oct. 15, 2000 the review board blamed the navigation error on a communications foul-up between NASA's Jet Propulsion Laboratory and prime contractor Lockheed Martin.
Launched Dec. 11, 1998, the Climate Orbiter plunged too steeply into the Martian atmosphere Sept. 23, 1999, and either burned up or crashed. In an initial failure report released Oct. 15, 2000 the review board blamed the navigation error on a communications foul-up between NASA's Jet Propulsion Laboratory and prime contractor Lockheed Martin.
Collect,analyze,
generate flightcontrol data
JPL-1
J1 JPL store
Convert datafrom Metric to
English
?
LM1 LM store
Controlspaceflight
LM-1
English data
Transfer of Flight Control DataThis processwas missing
Metric data
Transfer data
?
Who wasresponsible
for this task?
![Page 26: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/26.jpg)
26
Flow Modeling Notes
each bubble is refined until it does just one thing
the expansion ratio decreases as the number of levels increase
most systems require between 3 and 7 levels for an adequate flow model
a single data flow item (arrow) may be expanded as levels increase (data dictionary provides information)
![Page 27: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/27.jpg)
27
Activity DiagramSupplements the use-case Supplements the use-case by providing a diagrammatic by providing a diagrammatic representation of procedural representation of procedural flowflow
How might we make this How might we make this better?better?
enter passwordand user ID
select major function
valid passwords/ID
prompt for reentry
invalid passwords/ID
input tries remainno inputtries remain
select surveillance
other functionsmay also beselected
thumbnail views select a specific camera
select camera icon
prompt foranother view
select specificcamera - thumbnails
exit this function see another camera
view camera outputin labelled window
![Page 28: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/28.jpg)
28
Swimlane Diagrams
Allows the modeler to Allows the modeler to represent the flow of represent the flow of activities described by the activities described by the use-case and at the same use-case and at the same time indicate which actor time indicate which actor (if there are multiple (if there are multiple actors involved in a actors involved in a specific use-case) or specific use-case) or analysis class has analysis class has responsibility for the responsibility for the action described by an action described by an activity rectangleactivity rectangle
enter passwordand user ID
select major functionvalid passwords/ID
prompt for reentry
invalidpasswords/ID
input triesremain
no inputtries remain
select surveillance
other functionsmay also beselected
thumbnail views select a specific camera
select camera icon
generate videooutput
select specificcamera - thumbnails
exit thisfunctionsee
anothercamera
homeowner camera interface
prompt foranother viewview camera output
in labelled window
![Page 29: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/29.jpg)
29
Activity Diagram Example
- To show concurrent activity, activity diagrams allow branches and joins.
- You can also reference or include other activity diagrams
![Page 30: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/30.jpg)
30
Lets Try It
Lets create a swimlane activity diagram for opening a Lemonade stand.
![Page 31: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/31.jpg)
31
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Scenario-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Class-based elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Flow-oriented elements
State diagrams
Sequence diagrams
Behavioral elements
Analysis Model
Elements of the Analysis ModelOnward to data flow diagrams!
![Page 32: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/32.jpg)
32
Flow-Oriented Modeling
Represents how data objects are transformed at they Represents how data objects are transformed at they move through the systemmove through the system
A A data flow diagram (DFD)data flow diagram (DFD) is the diagrammatic form that is the diagrammatic form that is usedis used
Considered by many to be an ‘old school’ approach, flow-Considered by many to be an ‘old school’ approach, flow-oriented modeling continues to provide a view of the oriented modeling continues to provide a view of the system that is unique—it should be used to supplement system that is unique—it should be used to supplement other analysis model elementsother analysis model elements
![Page 33: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/33.jpg)
33
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Scenario-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Class-based elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Flow-oriented elements
State diagrams
Sequence diagrams
Behavioral elements
Analysis Model
Elements of the Analysis Model
Oh behave!
![Page 34: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/34.jpg)
34
Behavioral Modeling The behavioral model indicates how software will
respond to external events or stimuli. To create the model, the analyst must perform the following steps:
Evaluate all use-cases to fully understand the sequence of interaction within the system.
Identify events that drive the interaction sequence and understand how these events relate to specific objects.
Create a sequence for each use-case. Build a state diagram for the system. Review the behavioral model to verify accuracy and
consistency.
![Page 35: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/35.jpg)
35
State Representations In the context of behavioral modeling, two different
characterizations of states must be considered: the state of each class as the system performs its function and the state of the system as observed from the outside as the
system performs its function The state of a class takes on both passive and active
characteristics [CHA93]. A passive state is simply the current status of all of an object’s
attributes. The active state of an object indicates the current status of the
object as it undergoes a continuing transformation or processing.
![Page 36: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/36.jpg)
36
State Diagram for the ControlPanel Class
reading
locked
selecting
passwordentered
comparing
password = incorrect& numberOfTries < maxTries
password = correct
activation successful
key hit
do: validatePassword
numberOfTries > maxTries
timer < lockedTime
timer > lockedTime
![Page 37: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/37.jpg)
37
The States of a System state—a set of observable
circumstances that characterizes the behavior of a system at a given time
state transition —the movement from one state to another
event —an occurrence that causes the system to exhibit some predictable form of behavior
action —process that occurs as a consequence of making a transition
![Page 38: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/38.jpg)
38
Behavioral Modeling
make a list of the different states of a system (How does the system behave?)
indicate how the system makes a transition from one state to another (How does the system change state?) indicate event indicate action
draw a state diagram or a sequence diagram
![Page 39: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/39.jpg)
39
State Diagram - Lets Try It!You are designing a traffic light system for this intersection.
Draw a state diagram showing the different states and how they transition.
North
South
East
West
![Page 40: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/40.jpg)
40
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Scenario-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Class-based elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Flow-oriented elements
State diagrams
Sequence diagrams
Behavioral elements
Analysis Model
Elements of the Analysis Model
Onward to Class-based elements!
![Page 41: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/41.jpg)
41
Object Oriented Analysis (OOA)
The intent of OOA is to define all classes (and the relationships and behavior associated with them) that are relevant to the problem to be solved. For that, a number of tasks must occur:
1. Classes must be identified (i.e., attributes and methods)
2. A class hierarchy is defined
3. Object-to-object relationships should be represented
4. Object behavior must be modeled
5. Tasks 1 through 4 are reapplied iteratively
![Page 42: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/42.jpg)
42
Object-Oriented Concepts What are the basic object oriented
concepts?
![Page 43: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/43.jpg)
43
Object-Oriented Concepts What are the basic object oriented
concepts?
Classes and objects Attributes and operations Encapsulation and instantiation Inheritance
![Page 44: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/44.jpg)
44
Encapsulation/HidingThe object encapsulates
both data and the logicalprocedures required tomanipulate the data
Achieves “information hiding”
method # 1
data
method # 2
method # 4
method # 5
method # 6
method # 3
![Page 45: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/45.jpg)
45
Scenario Based Modeling: Use-Cases
a scenario that describes a “thread of usage” for a system
actors represent roles people or devices play as the system functions
users can play a number of different roles for a given scenario
““[Use-cases] are simply an aid to defining what [Use-cases] are simply an aid to defining what exists outside the system (actors) and what exists outside the system (actors) and what should be performed by the system (use-cases).” should be performed by the system (use-cases).” Ivar JacobsonIvar Jacobson
![Page 46: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/46.jpg)
46
Class-Based Modeling Identify analysis classes by examining
the problem statement Use a “grammatical parse” to isolate
potential classes Identify the attributes of each class Identify operations that manipulate the
attributes
![Page 47: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/47.jpg)
47
Domain AnalysisSoftware domain analysis is the identification, Software domain analysis is the identification, analysis, and specification of common analysis, and specification of common requirements from a specific application requirements from a specific application domain, typically for reuse on multiple projects domain, typically for reuse on multiple projects within that application domain . . . within that application domain . . .
What is object oriented domain analysis then?What is object oriented domain analysis then?
![Page 48: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/48.jpg)
48
Domain AnalysisSoftware domain analysis is the identification, Software domain analysis is the identification, analysis, and specification of common analysis, and specification of common requirements from a specific application requirements from a specific application domain, typically for reuse on multiple projects domain, typically for reuse on multiple projects within that application domain . . . within that application domain . . .
Object-oriented domain analysis is the Object-oriented domain analysis is the identification, analysis, and specification of identification, analysis, and specification of common, common, reusablereusable capabilitiescapabilities within a within a specific application domain, in terms of specific application domain, in terms of commoncommon objectsobjects, classes, subassemblies, , classes, subassemblies, and frameworks . . .and frameworks . . . Donald Firesmith
![Page 49: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/49.jpg)
49
Grammatical Parsing
Write an informal description of the problem. The
customer requirements document is one such
description.
Underline all nouns in the description
Decide which of these are really objects which the
project requires and organize them in related
clusters
![Page 50: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/50.jpg)
50
Grammatical ParsingUniversity Bank will be opening in Oxford, Mississippi, in January,
2000. We plan to use a full service automated teller machine (ATM)
system.The ATM system will interact with the customer through a
display screen, numeric and special input keys, a bankcard reader, a
deposit slot, and a receipt printer.Customers may make deposits,
withdrawals, and balance inquires using the ATM machine, but the
update to accounts will be handled through an interface to the
Accounts system.Customers will be assigned a Personal Identification
Number (PIN) and clearance level by the Security system. The PIN can
be verified prior to any transaction.In the future, we would also like to
support routine operations such as a change of address or phone
number using the ATM
![Page 51: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/51.jpg)
51
Grammatical Parsing University Bank will be opening in Oxford, Mississippi, in
January, 2000. We plan to use a full service automated teller machine (ATM) system.The ATM system will interact with the customer through a display screen, numeric and special input keys, a bankcard reader, a deposit slot, and a receipt printer.Customers may make deposits, withdrawals, and balance inquires using the ATM machine, but the update to accounts will be handled through an interface to the Accounts system.Customers will be assigned a Personal Identification Number (PIN) and clearance level by the Security system. The PIN can be verified prior to any transaction.In the future, we would also like to support routine operations such as a change of address or phone number using the ATM
![Page 52: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/52.jpg)
52
Typical Classes (a reminder) External entities - printer, user, sensor Things - reports, displays, signals Occurrences or events (e.g., interrupt, alarm) Roles (e.g., manager, engineer, salesperson) Organizational units (e.g., division, team) Places (e.g., manufacturing floor or loading dock) Structures (e.g., sensors, four-wheeled vehicles, or computers)
But, how do we select classes?
![Page 53: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/53.jpg)
53
Selecting Classes—Criteria
needed servicesneeded services
multiple attributesmultiple attributes
common attributescommon attributes
common operationscommon operations
essential requirementsessential requirements
retained informationretained information
![Page 54: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/54.jpg)
54
CRC Modeling
See specific CRC slides
![Page 55: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/55.jpg)
55
Rules of Thumb The model should focus on requirements that are visible
within the problem or business domain. The level of abstraction should be relatively high.
Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system.
Delay consideration of infrastructure and other non-functional models until design.
Minimize coupling throughout the system. Be certain that the analysis model provides value to all
stakeholders. Keep the model as simple as it can be.
![Page 56: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/56.jpg)
56
Writing the Software Specification
Everyone knew exactly what had to be done until someone wrote it down!
![Page 57: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/57.jpg)
57
Specification Guidelinesuse a layered format that provides increasing detail as the "layers" deepen
use consistent graphical notation and apply textual terms consistently (stay away from aliases)
be sure to define all acronyms
be sure to include a table of contents; ideally, include an index and/or a glossary
write in a simple, unambiguous style (see "editing suggestions" on the following pages)
always put yourself in the reader's position, "Would I be able to understand this if I wasn't intimately familiar with the system?"
![Page 58: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/58.jpg)
58
Specification GuidelinesBe on the lookout for persuasive connectors, ask why? keys: certainly, therefore, clearly, obviously, it follows that ...
Watch out for vague terms keys: some, sometimes, often, usually,ordinarily, most, mostly ...
When lists are given, but not completed, be sure all items are understood keys: etc., and so forth, and so on, such as
Be sure stated ranges don't contain unstated assumptions e.g., Valid codes range from 10 to 100. Integer? Real? Hex?
Beware of vague verbs such as handled, rejected, processed, ...
Beware "passive voice" statements e.g., The parameters are initialized. By what?
Beware "dangling" pronouns e.g., The I/O module communicated with the data validation module and its contol flag is set. Whose control flag?
![Page 59: Requirements Analysis](https://reader035.vdocument.in/reader035/viewer/2022062407/56812f08550346895d94a66b/html5/thumbnails/59.jpg)
59
Specification GuidelinesWhen a term is explicitly defined in one place, try
substituting the definition forother occurrences of the term
When a structure is described in words, draw a picture
When a structure is described with a picture, try to redraw the picture to emphasize different elements of the structure
When symbolic equations are used, try expressing their meaning in words
When a calculation is specified, work at least two examples
Look for statements that imply certainty, then ask for proof keys; always, every, all, none, never
Search behind certainty statements—be sure restrictions or limitations are realistic