SEC 308 Yazlm Mhendislii

Software Requirements

Requirements Engineering Process: A Basic Framework

0 3 fundamental activities:

understand, (formally) describe, attain an agreement on, the problem

User reqs

User

User feedback Req. models

knowledge

Elicitation
Domain knowledge

Specification
For more knowledge Val. result

Validation
Domain knowledge

Problem Domain

(domain experts, laws, standards, policies, documents, etc.)

2

Requirements Engineering
0 Inceptionask a set of questions that establish
0 basic understanding of the problem
0 the people who want a solution 0 the nature of the solution that is desired, and 0 the effectiveness of preliminary communication and collaboration

between the customer and the developer

0 Elicitationelicit requirements from all stakeholders 0 Elaborationcreate an analysis model that identifies data,

function and behavioral requirements 0 Negotiationagree on a deliverable system that is realistic for developers and customers
3

Requirements Engineering (cont.)

0 Specificationcan be any one (or more) of the following:
0 0 0 0 0 0 0 0 0

A written document A set of models A formal mathematical A collection of user scenarios (use-cases) A prototype

0 Validationa review mechanism that looks for

errors in content or interpretation areas where clarification may be required missing information inconsistencies (a major problem when large products or systems are engineered) 0 conflicting or unrealistic (unachievable) requirements.

0 Requirements management

Inception
0 Identify stakeholders 0 who else do you think I should talk to? 0 Recognize multiple points of view 0 Work toward collaboration 0 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 solution 0 Is there another source for the solution that you need?
5

Eliciting Requirements
0 meetings are conducted and attended by both software engineers and
0 0 0 0 0

customers rules for preparation and participation are established an agenda is suggested a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used the goal is
0 0 0 0

to identify the problem propose elements of the solution negotiate different approaches, and specify a preliminary set of solution requirements
6

Eliciting Requirements (cont.)

Conduct FA ST m eet ings Make list s of f unct ions, classes

Make list s of const raint s, et c.

El i c i t re q u i re m e n t s
yes Use QFD t o priorit ize requirem ent s

f orm al priorit izat ion? no inf orm ally priorit ize requirem ent s draw use-case diagram def ine act ors

writ e scenario

Creat e Use-cases com plet e t em plat e

Quality Function Deployment

0 Function deployment determines the value

(as perceived by the customer) of each function required of the system 0 Information deployment identifies data objects and events 0 Task deployment examines the behavior of the system 0 Value analysis determines the relative priority of requirements

Elicitation Work Products

0 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 systems 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 Model

0 Elements of the analysis model 0 Scenario-based elements
0 Functionalprocessing narratives for software functions

0 Use-casedescriptions of the interaction between an actor and

the system

0 Class-based elements 0 Implied by scenarios 0 Behavioral elements 0 State diagram 0 Flow-oriented elements 0 Data flow diagram
10

Diagrams
(Use Case, Class, State)
Arms/ disarms syst em

Sensor
name/id type location area characteris tics identif y() enable() disable() reconfigure ()

Accesses syst em via Int ernet homeow ner

sensors

Reading Commands
Responds t o alarm event

State name
System status = ready Display msg = enter cmd Display status = steady

State variables
Encount ers an error condit ion

syst em administ rat or

Reconf igures sensors and relat ed syst em f eat ures

Entry/subsystems ready Do: poll user input panel Do: read user input Do: interpret user input

State activities 11

Negotiating Requirements
0 Identify the key stakeholders
0 These are the people who will be involved in the

negotiation

0 Determine each of the stakeholders win conditions

0 Win conditions are not always obvious

0 Negotiate
0 Work toward a set of requirements that lead to

win-win

12

Validating Requirements
0 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 14 requirements?

Requirements Analysis
0 Requirements analysis 0 specifies softwares operational characteristics 0 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 tasks 0 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 Analysis
0 Define the domain to be investigated. 0 Collect a representative sample of applications in the domain. 0 Analyze each application in the sample.

0 Develop an analysis model for the objects.

0 In terms of data modeling, function/process modeling, behavioral modeling, etc.
17

Building the Analysis Model

0 Elements of the analysis model 0 Scenario-based elements
0 Functionalprocessing narratives for software functions 0 Use-casedescriptions of the interaction between an actor and

the system

0 Class-based elements 0 Implied by scenarios 0 Behavioral elements 0 State diagram 0 Flow-oriented elements 0 Data flow diagram

A Bridge
syste m de scription analysis mode l

de sign mode l

18

Elements of Analysis Model

19

Data Modeling
0 examines data objects independently of processing

0 focuses attention on the data domain

0 creates a model at the customers level of abstraction 0 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

object: automobile attributes: make model body type price options code

21

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.
0 A person owns a car 0 A 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 exist 0 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.

Consider an insurance company that offers both home and automobile insurance policies .These policies are offered to individuals and businesses.
24

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
One common form: object 1
(0, m)
relationship

(1, 1)

object 2
attribute

Another common form: object 1

(0, m)

relationship
(1, 1)

object 2

29

Building an ERD
0 Level 1model all data objects (entities) and their

connections to one another 0 Level 2model all entities and relationships 0 Level 3model all entities, relationships, and the attributes that provide further depth

30

The ERD: An Example

Customer (1,1)
places

request (1,m) for service (1,1) (1,n) work order (1,1)

consists of lists 31

standard task table (1,1)

selected from

generates

work (1,w) tasks materials

(1,w)
(1,i)

(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 system 0 actors represent roles people or devices play as the system

functions 0 users can play a number of different roles for a given scenario

32

What to Write About?

0 Inception and elicitationprovide you with the information

youll need to begin writing use cases. 0 Requirements gathering meetings, QFD, and other requirements engineering mechanisms are used to
0 0 0 0 0 0

identify stakeholders define the scope of the problem specify overall operational goals establish priorities outline all known functional requirements, and 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 actora

person or device that interacts with the software in some way 0 Each scenario answers the following questions:
0 0 0 0 0 0 0 0

Who is the primary actor, the secondary actor (s)? What are the actors goals? What preconditions should exist before the story begins? What main tasks or functions are performed by the actor? What extensions might be considered as the story is described? What variations in the actors interaction are possible? What system information will the actor acquire, produce, or change? 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

Use-case diagram for surveillance function

35

Alternative Actions
0 Can the actor take some other action at this point? 0 Is it possible that the actor will encounter some error condition at this point? 0 Is it possible that the actor will encounter behavior invoked by some event outside the

actors control?
36

Activity Diagram
Supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario

37

Swimlane Diagrams
Allows the modeler to represent the flow of activities described by the use-case and at the same time indicate which actor (if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action described by an activity rectangle

38

Flow-Oriented Modeling
0 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 uniqueit should be used to supplement other analysis model elements 0 Every computer-based system is an information transform .... computer based system

input

output
39

Flow Modeling Notation

external entity

process

data flow
data store
40

External Entity
A producer or consumer of data

Examples: a person, a device, a sensor Another example: computer-based system

Data must always originate somewhere and must always be sent to something
41

Process
A data transformer (changes input to output) Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function

42

Data Flow
Data flows through a system, beginning as input and be transformed into output.
base compute triangle area area

height

43

Data Stores
Data is often stored for later use.
sensor # sensor #, type, location, age

report required

look-up sensor data

sensor number

type, location, age sensor data

44

Data Flow Diagramming: Guidelines

0 all icons must be labeled with meaningful names

0 the DFD evolves through a number of levels of detail

0 always begin with a context level diagram (also called

level 0) 0 always show external entities at level 0 0 always label data flow arrows 0 do not represent procedural logic

45

Constructing a DFDI
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
user
processing request
requested video signal

video source

digital video processor

NTSC video signal

monitor

46

Constructing a DFDII
0 write a narrative describing the transform

0 parse to determine next level transforms

0 balance the flow to maintain data flow continuity 0 develop a level 1 DFD

0 use a 1:5 (approx.) expansion ratio

47

The Data Flow Hierarchy

x a

level 0

p1

p2

f
p4

d
level 1

p3

48

Example: SafeHome Software

Level 0 DFD for SafeHome security function

49

Level 1 DFD for SafeHome security function

50

Level 2 DFD that refines the monitor sensors process

51

Flow Modeling Notes

0 each bubble is refined until it does just one thing

0 the expansion ratio decreases as the number of levels

increase 0 most systems require between 3 and 7 levels for an adequate flow model 0 a single data flow item (arrow) may be expanded as levels increase (data dictionary provides information)

52

Process Specification (PSPEC)

bubble
PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts
53

DFDs: A Look Ahead

analysis model

Maps into

design model

54

Control Flow Diagrams

0 Represents events and the processes that manage

events 0 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 flowsevents and control itemsare 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 processesthis is done via the CSPEC

56

Control Flow Diagram

beeper on/off copies done

full

read operator input

empty

manage copying
start

problem light

reload process perform problem diagnosis create user displays

display panel enabled

jammed

57

Control Flow Diagram

State diagram for SafeHome security function

58

Flow-Oriented Modeling
The CSPEC can be: state diagram (sequential spec)
state transition table combinatorial spec

decision tables
activation tables

59

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
retained information needed services multiple attributes common attributes common operations essential requirements
61

Analysis Classes
0 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

0 0 0 0

series of robot movements) that occur within the context of system operation. Roles (e.g., manager, engineer, salesperson) played by people who interact with the system. Organizational units (e.g., division, group, team) that are relevant to an application. Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and the overall function of the system. Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects.
62

Class Diagram
Class name attributes

operations

Class diagram for the system class

63

Class Diagram

Class diagram for FloorPlan

64

CRC Modeling
0 Class-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:
0 A 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

A CRC model index card for FloorPlan class

66

Class Types
0 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

Responsibilities
0 System intelligence should be distributed across

classes to best address the needs of the problem 0 Each responsibility should be stated as generally as possible 0 Information and the behavior related to it should reside within the same class 0 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

Collaborations
0 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 classes

0 Collaborations are identified by determining whether a

class can fulfill each responsibility itself 0 three different generic relationships between classes [WIR90]: 0 the is-part-of relationship
0 the has-knowledge-of relationship 0 the depends-upon relationship

69

Composite Aggregate Class

70

Associations and Dependencies

0 Two analysis classes are often related to one another in some

fashion 0 In UML these relationships are called associations 0 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

Top: Multiplicity Bottom: Dependencies

72

Analysis Packages
0 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 Modeling
0 The 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

objects attributes. The active state of an object indicates the current status of the object as it undergoes a continuing transformation or 76 process

State Diagram

State diagram for the ControlPanel class

77

The States of a System

0 statea set of observable circumstances that characterizes the behavior of a system at a given time 0 state transitionthe movement from one state to another

0 eventan occurrence that causes the system to exhibit some predictable form of behavior
0 actionprocess that occurs as a consequence

of making a transition

78

Behavioral Modeling
0 make a list of the different states of a system (How does the system behave?)
0 indicate how the system makes a transition

from one state to another (How does the system change state?)
0 indicate event

0 indicate action

0 draw a state diagram or a sequence diagram

79

Sequence Diagram

Sequence diagram (partial) for the SafeHome security function

80

Requirements Documentation
0 This is the way of representing requirements in a consistent

format

0 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 requirements 0 not describe any design details 0 not impose any additional constraints
81

Requirements Documentation
0 Characteristics 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 elements
0 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.)

0 Characteristics 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
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, "W ould I be able to understand this if I wasn't intimately familiar with the system?"

89

Specification Guidelines
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?
90

Specification Guidelines
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 statementsbe sure restrictions or limitations are realistic
91