Upload
derek-black
View
240
Download
3
Embed Size (px)
Citation preview
SEC 308 Yazılım MühendisliğiSEC 308 Yazılım Mühendisliği
Software Requirements
1
Requirements Engineering Process: A Basic Framework
0 3 fundamental activities:understand, (formally) describe, attain an agreement on, the problem
2
User
ProblemDomain
Elicitation Specification Validation
Domain knowledge Domain knowledge
User reqs User feedback
Req. models
Val. result
knowledge
For more knowledge
(domain experts, laws, standards, policies, documents, etc.)
Requirements Engineering0 Inception—ask a set of questions that establish …
0 basic understanding of the problem0 the people who want a solution0 the nature of the solution that is desired, and 0 the effectiveness of preliminary communication and collaboration
between the customer and the developer
0 Elicitation—elicit requirements from all stakeholders0 Elaboration—create an analysis model that identifies data,
function and behavioral requirements0 Negotiation—agree on a deliverable system that is realistic
for developers and customers3
Requirements Engineering (cont.)
0 Specification—can be any one (or more) of the following:0 A written document0 A set of models0 A formal mathematical0 A collection of user scenarios (use-cases)0 A prototype
0 Validation—a review mechanism that looks for0 errors in content or interpretation0 areas where clarification may be required0 missing information0 inconsistencies (a major problem when large products or systems are
engineered)0 conflicting or unrealistic (unachievable) requirements.
0 Requirements management 4
Inception0 Identify stakeholders
0 “who else do you think I should talk to?”0 Recognize multiple points of view0 Work toward collaboration0 The first questions
0 Who is behind the request for this work?0 Who will use the solution?0 What will be the economic benefit of a successful
solution0 Is there another source for the solution that you need?
5
Eliciting Requirements0 meetings are conducted and attended by both software engineers and
customers0 rules for preparation and participation are established0 an agenda is suggested 0 a "facilitator" (can be a customer, a developer, or an outsider) controls
the meeting0 a "definition mechanism" (can be work sheets, flip charts, or wall stickers
or an electronic bulletin board, chat room or virtual forum) is used0 the goal is
0 to identify the problem0 propose elements of the solution0 negotiate different approaches, and0 specify a preliminary set of solution requirements
6
Eliciting Requirements (cont.)
7
Use QFD to prioritize
requirements
informally prioritize
requirements
formal prioritization?
Create Use-cases
yes noElic it requirements
write scenario
define actors
complete template
draw use-case diagram
Conduct FASTmeetings
Make lists offunctions, classes
Make lists ofconstraints, etc.
Quality Function Deployment 0Function deployment determines the “value”
(as perceived by the customer) of each function required of the system
0Information deployment identifies data objects and events
0Task deployment examines the behavior of the system
0Value analysis determines the relative priority of requirements 8
Elicitation Work Products0 a statement of need and feasibility.0 a bounded statement of scope for the system or product.0 a list of customers, users, and other stakeholders who
participated in requirements elicitation 0 a description of the system’s technical environment.0 a list of requirements (preferably organized by function)
and the domain constraints that apply to each.0 a set of usage scenarios that provide insight into the use of
the system or product under different operating conditions.0 any prototypes developed to better define requirements.
9
Building Analysis Model0 Elements of the analysis model
0 Scenario-based elements0Functional—processing narratives for software functions0Use-case—descriptions of the interaction between an “actor” and
the system
0 Class-based elements0 Implied by scenarios
0 Behavioral elements0State diagram
0 Flow-oriented elements0Data flow diagram
10
Diagrams(Use Case, Class, State)
11
homeowner
Arms/ disarms system
Accesses system via Internet
Reconfigures sensors and related
system features
Responds toalarm event
Encounters anerror condition
system administrator
sensors
Sensor
name/id type location area characteristics
identify() enable() disable() reconfigure()
Reading Commands
System status = “ready”Display msg = “enter cmd”Display status = steady
Entry/subsystems readyDo: poll user input panelDo: read user inputDo: interpret user input
State name
State variables
State activities
Negotiating Requirements0Identify the key stakeholders
0 These are the people who will be involved in the negotiation
0Determine each of the stakeholders “win conditions”0 Win conditions are not always obvious
0Negotiate0 Work toward a set of requirements that lead to
“win-win”12
Validating Requirements0 Is each requirement consistent with the overall objective for the
system/product?0 Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?
0 Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?
0 Is each requirement bounded and unambiguous?0 Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement? 0 Do any requirements conflict with other requirements?
13
Validating Requirements (cont.)0 Is each requirement achievable in the technical environment
that will house the system or product?0 Is each requirement testable, once implemented?0 Does the requirements model properly reflect the information,
function and behavior of the system to be built.0 Has the requirements model been “partitioned” in a way that
exposes progressively more detailed information about the system.
0 Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements?
14
Requirements Analysis0 Requirements analysis
0 specifies software’s operational characteristics0 indicates software's interface with other system elements 0 establishes constraints that software must meet
0 Requirements analysis allows the software engineer (called an analyst or modeler in this role) to:0 elaborate on basic requirements established during earlier
requirement engineering tasks0 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.
15
Requirements Modeling Strategies• One view of requirements modeling, called structured
analysis, considers data and the processes that transform the data as separate entities. – Data objects are modeled in a way that defines their attributes and
relationships. – Processes that manipulate data objects are modeled in a manner that
shows how they transform data as data objects flow through the system.
• A second approach to analysis modeled, called object-oriented analysis, focuses on – the definition of classes and– the manner in which they collaborate with one another to effect
customer requirements.16
Domain Analysis0Define the domain to be investigated.0Collect a representative sample of
applications in the domain.0Analyze each application in the sample.0Develop an analysis model for the objects. 0In terms of data modeling, function/process
modeling, behavioral modeling, etc.
17
Building the Analysis Model0 Elements of the analysis model
0 Scenario-based elements0Functional—processing narratives for software functions0Use-case—descriptions of the interaction between an “actor” and
the system0 Class-based elements
0 Implied by scenarios0 Behavioral elements
0State diagram0 Flow-oriented elements
0Data flow diagram
18
system description
analysis model
design model
A Bridge
Elements of Analysis Model
19
Data Modeling
0 examines data objects independently of processing0 focuses attention on the data domain0 creates a model at the customer’s level of abstraction0 indicates how data objects relate to one another
20
What is a Data Object?0 Object-something that is described by
a set of attributes (data items) and that will be manipulated within the software (system)0 each instance of an object (e.g., a book)
can be identified uniquely (e.g., ISBN #) 0 each plays a necessary role in the system
i.e., the system could not function without access to instances of the object
0 each is described by attributes that are themselves data items
21
object: automobileobject: automobileattributes:attributes: makemake modelmodel body typebody type priceprice options codeoptions code
What is a Relationship?
0 Data objects are connected to one another in different ways.0 A connection is established between person and
car because the two objects are related.0A person owns a car0A person is insured to drive a car
0 The relationships owns and insured to drive define the relevant connections between person and car.
0 Several instances of a relationship can exist0 Objects can be related in many different ways
22
Entity-Relationship Diagrams
0 Entity-Relationship Diagram (ERD) is a detailed logical representation of data for an organization and uses three main constructs.
23
Entity-Relationship Diagrams
0 Entities: Fundamental thing about which data may be maintained. Each entity has its own identity.
0 Entity Type is the description of all entities to which a common definition and common relationships and attributes apply.
24
• Consider an insurance company that offers both home and automobile insurance policies .These policies are offered to individuals and businesses.
Entity-Relationship Diagrams
• Relationships: A relationship is a reason for associating two entity types.
– Binary relationships involve two entity types– A CUSTOMER is insured by a POLICY. A POLICY CLAIM is made against a POLICY.
• Relationships are represented by diamond notation in a ER diagram.
25
Entity-Relationship Diagrams
26
Entity-Relationship Diagrams
0 Cardinality defines “the maximum number of objects that can participate in a relationship”[TIL93].0 Two entity types A and B, connected by a relationship.
The cardinality of a relationship is the number of instances of entity B that can be associated with each instance of entity A
0 Modality specifies if the relationship is optional (0) or mandatory (1).
27
Entity-Relationship Diagrams
• Attributes: An attribute is a property or characteristic of an entity that is of interest to organization.
• Each entity type has a set of attributes associated with it.
28
ERD Notation
29
(0, m) (1, 1)
object objectobjectrelationshiprelationship11 22
One common form:
(0, m)
(1, 1)
object 11 object 22relationship
Another common form:attribute
Building an ERD
0 Level 1—model all data objects (entities) and their “connections” to one another
0 Level 2—model all entities and relationships0 Level 3—model all entities, relationships, and the
attributes that provide further depth
30
The ERD: An Example
31
(1,1) (1,m)placesCustomer
requestfor service
generates(1,n)
(1,1)
workorder
worktasks
materials
consistsof
lists
(1,1)(1,w)
(1,1)
(1,i)
selectedfrom
standardtask table
(1,w)
(1,1)
Scenario-Based Modeling
0 Use-Cases
0 “[Use-cases] are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).”
0 a scenario that describes a “thread of usage” for a system0 actors represent roles people or devices play as the system
functions0 users can play a number of different roles for a given
scenario
32
What to Write About?
0 Inception and elicitation—provide you with the information you’ll need to begin writing use cases.
0 Requirements gathering meetings, QFD, and other requirements engineering mechanisms are used to 0 identify stakeholders0 define the scope of the problem0 specify overall operational goals0 establish priorities0 outline all known functional requirements, and 0 describe the things (objects) that will be manipulated by the system.
0 To begin developing a set of use cases, list the functions or activities performed by a specific actor.
33
Developing a Use-Case
0 Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way
0 Each scenario answers the following questions:0 Who is the primary actor, the secondary actor (s)?0 What are the actor’s goals?0 What preconditions should exist before the story begins?0 What main tasks or functions are performed by the actor?0 What extensions might be considered as the story is described?0 What variations in the actor’s interaction are possible?0 What system information will the actor acquire, produce, or change?0 Will the actor have to inform the system about changes in the external
environment?0 What information does the actor desire from the system?0 Does the actor wish to be informed about unexpected changes?
34
Use-Case Diagram
35Use-case diagram for surveillance function
Alternative Actions
0Can the actor take some other action at this point?
0Is it possible that the actor will encounter some error condition at this point?
0Is it possible that the actor will encounter behavior invoked by some event outside the actor’s control?
36
Activity Diagram
37
Supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario
Swimlane Diagrams
38
Allows the modeler to Allows the modeler to represent the flow of represent the flow of activities described by activities described by the use-case and at the the use-case and at the same time indicate same time indicate which actor (if there are which actor (if there are multiple actors involved multiple actors involved in a specific use-case) or in a 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
Flow-Oriented Modeling0 Represents how data objects are transformed as they move through the
system
0 A data flow diagram (DFD) is the diagrammatic form that is used
0 Considered by many to be an ‘old school’ approach, flow-oriented modeling continues to provide a view of the system that is unique—it should be used to supplement other analysis model elements
0 Every computer-based system is an information transform ....
39
computerbased
systeminput output
Flow Modeling Notation
40
external entity
process
data flow
data store
External Entity
41
A producer or consumer of data
Examples: a person, a device, a sensor
Another example: computer-basedsystem
Data must always originate somewhereand must always be sent to something
Process
42
A data transformer (changes inputto output)
Examples: compute taxes, determine area,format report, display graph
Data must always be processed in some way to achieve system function
Data Flow
43
computetriangle
area
base
height
area
Data flows through a system, beginningas input and be transformed into output.
Data Stores
44
Data is often stored for later use.
look-upsensor
data
sensor #
report required
sensor #, type, location, age
sensor data
sensor number
type, location, age
Data Flow Diagramming: Guidelines
0 all icons must be labeled with meaningful names0 the DFD evolves through a number of levels of detail0 always begin with a context level diagram (also called
level 0)0 always show external entities at level 00 always label data flow arrows0 do not represent procedural logic
45
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• Level 0 DFD Example
46
userprocessing
request
videosource NTSC
video signal
digitalvideo
processor
requestedvideosignall
monitor
Constructing a DFD—II
0 write a narrative describing the transform0 parse to determine next level transforms0 “balance” the flow to maintain data flow continuity0 develop a level 1 DFD0 use a 1:5 (approx.) expansion ratio
47
The Data Flow Hierarchy
48
Pa bx y
p1p2
p3p4 5
a
b
c
de
f
g
level 0
level 1
Example: SafeHome Software
49Level 0 DFD for SafeHome security function
50Level 1 DFD for SafeHome security function
51Level 2 DFD that refines the monitor sensors process
Flow Modeling Notes
0 each bubble is refined until it does just one thing0 the expansion ratio decreases as the number of levels
increase0 most systems require between 3 and 7 levels for an
adequate flow model0 a single data flow item (arrow) may be expanded as
levels increase (data dictionary provides information)
52
Process Specification (PSPEC)
53
PSPEC
narrativepseudocode (PDL)equationstables
diagrams and/or charts
bubble
DFDs: A Look Ahead
54
Maps intoanalysis model
design model
Control Flow Diagrams0 Represents “events” and the processes that manage
events0 An “event” is a Boolean condition that can be
ascertained by:0 listing all sensors that are "read" by the software.0 listing all interrupt conditions.0 listing all "switches" that are actuated by an operator.0 listing all data conditions.0 recalling the noun/verb parse that was applied to the
processing narrative, review all "control items" as possible CSPEC inputs/outputs.
55
The Control Model• the control flow diagram is "superimposed" on the DFD and shows
events that control the processes noted in the DFD• control flows—events and control items—are noted by dashed
arrows• a vertical bar implies an input to or output from a control spec
(CSPEC) — a separate specification that describes how control is handled
• a dashed arrow entering a vertical bar is an input to the CSPEC• a dashed arrow leaving a process implies a data condition• a dashed arrow entering a process implies a control input read
directly by the process• control flows do not physically activate/deactivate the processes—
this is done via the CSPEC
56
Control Flow Diagram
57
readoperator
input
createuser
displaysperformproblem diagnosis
reloadprocess
managecopying
beeper on/off
start
copies done
display panel enabled
full
problem light
jammed
empty
Control Flow Diagram
58State diagram for SafeHome security function
Flow-Oriented Modeling
59
The CSPEC can be:
state diagram (sequential spec)
state transition table
decision tables
activation tables
combinatorial spec
Class-Based Modeling• Class-based modeling represents:
– objects that the system will manipulate – operations (also called methods or services) that will be applied to
the objects to effect the manipulation – relationships (some hierarchical) between the objects– collaborations that occur between the classes that are defined.
• The elements of a class-based model include classes and objects, attributes, operations, CRC models, collaboration diagrams and packages.
60
Class-Based Modeling• Identify analysis classes by examining the problem
statement• Use a “grammatical parse” to isolate potential classes
[Abb83] • Identify the attributes of each class• Identify operations that manipulate the attributes• Potential classes
61
Analysis Classes0 External entities (e.g., other systems, devices, people) that produce or consume
information to be used by a computer-based system.0 Things (e.g., reports, displays, letters, signals) that are part of the information
domain for the problem.0 Occurrences or events (e.g., a property transfer or the completion of a series of
robot movements) that occur within the context of system operation.0 Roles (e.g., manager, engineer, salesperson) played by people who interact
with the system.0 Organizational units (e.g., division, group, team) that are relevant to an
application.0 Places (e.g., manufacturing floor or loading dock) that establish the context of
the problem and the overall function of the system.0 Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a
class of objects or related classes of objects.
62
Class Diagram
63
Class name
attributes
operations
Class diagram for the system class
Class Diagram
64Class diagram for FloorPlan
CRC Modeling0Class-responsibility-collaborator (CRC)
modeling [Wir90] provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. Ambler [Amb95] describes CRC modeling in the following way:0A CRC model is really a collection of standard index
cards that represent classes. The cards are divided into three sections. Along the top of the card you write the name of the class. In the body of the card you list the class responsibilities on the left and the collaborators on the right.
65
CRC Modeling
66A CRC model index card for FloorPlan class
Class Types0 Entity classes, also called model or business classes, are extracted
directly from the statement of the problem (e.g., FloorPlan and Sensor).
0 Boundary classes are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used.
0 Controller classes manage a “unit of work” [UML03] from start to finish. That is, controller classes can be designed to manage 0 the creation or update of entity objects; 0 the instantiation of boundary objects as they obtain information from
entity objects; 0 complex communication between sets of objects; 0 validation of data communicated between objects or between the user
and the application.
67
Responsibilities0 System intelligence should be distributed across
classes to best address the needs of the problem0 Each responsibility should be stated as generally as
possible0 Information and the behavior related to it should
reside within the same class0 Information about one thing should be localized with a
single class, not distributed across multiple classes. 0 Responsibilities should be shared among related
classes, when appropriate.
68
Collaborations0 Classes fulfill their responsibilities in one of two ways:
0 A class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility, or
0 a class can collaborate with other classes.
0 Collaborations identify relationships between classes0 Collaborations are identified by determining whether a class
can fulfill each responsibility itself0 three different generic relationships between classes [WIR90]:
0 the is-part-of relationship0 the has-knowledge-of relationship0 the depends-upon relationship
69
Composite Aggregate Class
70
Associations and Dependencies
0 Two analysis classes are often related to one another in some fashion0 In UML these relationships are called associations0 Associations can be refined by indicating multiplicity (the
term cardinality is used in data modeling)0 In many instances, a client-server relationship exists between
two analysis classes. 0 In such cases, a client-class depends on the server-class in
some way and a dependency relationship is established
71
Class Diagrams
72
Top: MultiplicityBottom: Dependencies
Analysis Packages0 Various elements of the analysis model (e.g., use-cases,
analysis classes) are categorized in a manner that packages them as a grouping
0 The plus sign preceding the analysis class name in each package indicates that the classes have public visibility and are therefore accessible from other packages.
0 Other symbols can precede an element within a package. A minus sign indicates that an element is hidden from all other packages and a # symbol indicates that an element is accessible only to packages contained within a given package.
73
Analysis Packages
74
Behavioral Modeling0The behavioral model indicates how software will
respond to external events or stimuli. To create the model, the analyst must perform the following steps:0 Evaluate all use-cases to fully understand the sequence of
interaction within the system.0 Identify events that drive the interaction sequence and
understand how these events relate to specific objects.0 Create a sequence for each use-case.0 Build a state diagram for the system.0 Review the behavioral model to verify accuracy and
consistency.
75
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 process
76
State Diagram
77State diagram for the ControlPanel class
The States of a System0state—a set of observable circumstances that
characterizes the behavior of a system at a given time
0state transition—the movement from one state to another
0event—an occurrence that causes the system to exhibit some predictable form of behavior
0action—process that occurs as a consequence of making a transition
78
Behavioral Modeling0make a list of the different states of a system
(How does the system behave?)0indicate how the system makes a transition
from one state to another (How does the system change state?)0 indicate event0 indicate action
0draw a state diagram or a sequence diagram
79
Sequence Diagram
80Sequence diagram (partial) for the SafeHome security function
Requirements Documentation0 This is the way of representing requirements in a consistent
format0 called Software Requirements Specifications (SRS) document
0 SRS serves many purposes depending upon who is writing it.0 written by customer and/or developer
0 Serves as contract between customer & developer.0 SRS Should
0 Correctly define all requirements0 not describe any design details0 not impose any additional constraints
81
Requirements Documentation0Characteristics of a good SRS
0 Correct : An SRS is correct if and only if every requirement stated therein is one that the software shall meet.
0 Unambiguous : An SRS is unambiguous if and only if, every requirement stated therein has only one interpretation.
0 Complete : An SRS is complete if and only if, it includes the following elements0 All significant requirements, whether related to functionality, performance,
design constraints, attributes or external interfaces.0 Responses to both valid & invalid inputs.0 Full Label and references to all figures, tables and diagrams in the SRS and
definition of all terms and units of measure.82
Requirements Documentation (cont.)
0Characteristics of a good SRS (continued)0 Consistent : An SRS is consistent if and only if, no subset of
individual requirements described in it conflict.0 Ranked for important and/or stability : If an identifier is
attached to every requirement to indicate either the importance or stability of that particular requirement.
0 Verifiable : An SRS is verifiable, if and only if, every requirement stated therein is verifiable.
83
Requirements Documentation (cont.)
• Characteristics of a good SRS (continued)– Modifiable : An SRS is modifiable, if and only if, its
structure and style are such that any changes to the requirements can be made easily, completely, and consistently while retaining structure and style.
– Traceable : An SRS is traceable, if the origin of each of the requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation.
84
Requirements Documentation
• Organization of the SRS– IEEE has published guidelines and standards to organize an
SRS.
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definition, Acronyms and abbreviations 1.4 References 1.5 Overview
85
Requirements Documentation
2. The Overall Description 2.1 Product Perspective 2.2 Product Functions
2.1.1 System Interfaces 2.3 User Characteristics
2.1.2 Interfaces 2.4 Constraints
2.1.3 Hardware Interfaces 2.5 Assumptions for dependencies
2.1.4 Software Interfaces 2.6 Apportioning of requirements
2.1.5 Communication Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements
86
Requirements Documentation
3. Specific Requirements 3.1 External Interfaces
3.2 Functions
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design Constraints
3.6 Software System attributes
3.7 Organization of specific requirements
3.8 Additional Comments.
87
Writing the Software Specification
Everyone knew exactly what had to be done until someone wrote it down!
Specification Guidelines
89
use 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?"
Specification Guidelines
90
Be 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?
Specification Guidelines
91
When 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