Important Topics of lecture 19-45 ( 708)

Lecture 19

Requirements Identification
It is essential for requirements management that every requirement should have a unique identification  based on chapter/section 
Requirements Identification Techniques
• Dynamic renumbering, 
• Database record identification, 
• Symbolic identification 

Storing Requirements
Requirements have to be stored in such a way that they can be accessed easily and related to other system requirements
Requirements Storage Techniques
• In one or more word processor files
• In a specially designed requirements database
Word Processor Documents: Advantages
• Requirements are all stored in the same place
• Requirements may be accessed by anyone with the right word processor
• It is easy to produce the final requirements document
Word Processor Documents: Disadvantages
• Requirements dependencies must be externally maintained
• Search facilities are limited
• Not possible to have version control on individual requirements
• No automated navigation from one requirement to another
Requirements Database
• Each requirement is represented as one or more database entities
• Database query language is used to access requirements
Requirements Database: Advantages
• Good query and navigation facilities
• Support for change and version management
Requirements Database: Disadvantages
• Readers may not have the software/skills to access the requirements database
• The link between the database and the requirements document must be maintained

Change Management
• Change management is concerned with the procedures, processes and standards which are used to manage changes to system requirements
Change Management Policies
The process used to analyze the impact and costs of change and the associated traceability information.
Change Management Stages
 Identified Problems
   Problem Analysis and Change Specification
     Change Analysis and Costing
       Change Implementation
         Revised requirements

Lecture 20

Requirements Traceability
• Refers to ability to describe and follow the life of a requirement, in both a forwards and backwards direction
• That is from its origins, through its development and specification, deployment and use, and through all on-going refinement and iteration phases

Classifications of Requirements Traceability

• Backward-from Traceability: Links requirements to their sources in other documents or people
• Forward-from Traceability: Links requirements to design and implementation components
• Backward-to Traceability: Links design and implementation components back to requirements
• Forward-to Traceability: Links other documents (which may have preceded the requirements document) to relevant requirements

Categories of Traceability:

• Requirements-Sources Traceability: Links the requirement and the people or documents which specified the requirement
• Requirements-Rationale Traceability: Links the requirement with a description of why that requirement has been specified. This can be a distillation of information from several sources
• Requirements-Requirements Traceability: Links requirements with other requirements which are, in some way, dependent on them. This should be a two-way link (dependent on them and is-dependent on)
• Requirements-Architecture Traceability: Links requirements with the sub-systems where these requirements are implemented. This is particularly important where sub-systems are being developed by different sub-contractors
• Requirements-Design Traceability: Links requirements with specific hardware or software components in the system, which are used to implement the requirement
• Requirements-Interface Traceability: Links requirements with the interfaces of external systems, which are used in the provision of the requirements

Traceability Policy
Traceability information, 
Traceability techniques, 
When to collect information, 
Roles,
Documentation of policy exceptions, 
Process of managing information

Basic Types of Requirements Traceability
• Pre-RS traceability
– Concerned with those aspects of a requirement’s life prior to its inclusion in the RS (requirements production)
• Post-RS traceability
– Concerned with those aspects of a requirement’s life that result from its inclusion in the RS (requirements deployment)
Pre-RS Traceability and Rationale
• Pre-RS traceability captures the rationale for each requirement, which is a very important aspect in managing requirements properly 

Lecture 21

Prototyping: It is the technique of constructing a partial implementation of a system so that customers, users, or developers can learn more about a problem or a solution to that problem 
Prototype
• An initial version of the system under development, which is available early in the development process
• A prototype can be a subset of a system
• In hardware systems, prototypes are often developed to test and experiment the system designs
• In software systems, prototypes are more often used to help elicit and validate the system requirements.
• It should be easy for a prototype to be developed quickly, so that it can be used during the development process
• Prototypes are valuable for requirements elicitation because users can experiment with the system and point out its strengths and weaknesses. They have something concrete to criticize

Types of Prototyping: 
Throw-away prototyping, 
Evolutionary prototyping

Throw-away Prototyping
• The prototyped requirements in this stage are hardest to understand which cause most difficulties to customers. Little documentation is needed
• Determine the feasibility of a requirement
• Validate that a particular function is really necessary
• Uncover missing requirements
• Writing a preliminary requirements document And Implementing the prototype based on it
• Achieving user experience with prototype
• Writing the real SRS
• Developing the real product

Evolutionary Prototyping
• Documentation of the prototype is needed to build upon
• Intended to deliver a workable system quickly to the customer
• The well-understood requirements supported by the initial versions of this prototype and which can deliver useful end-user functionality
• This process repeats indefinitely until the prototype system satisfies all needs and has thus evolved into the real system

• Evolutionary prototype may not be built in a ‘dirty’ fashion. The evolutionary prototype evolves into the final product, and thus it must exhibit all the quality attributes of the final product

Prototyping Costs

Training costs: Prototype development may require the use of special purpose tools

Development costs: Depend on the type of prototype being developed

Prototyping Problems

• Extended development schedules

– Developing a prototype may extend the schedule although the prototyping time may be recovered because rework is avoided

• Incompleteness

– It may not be possible to prototype emergent system requirements

Approaches to Prototyping

• Paper prototyping, 
• ‘Wizard of Oz’ prototyping, 
• Executable prototyping

Paper Prototyping

• A paper mock-up of the system

• very cheap and very effective approach

• No executable software is needed

• Paper versions of the screens, presented to the user are drawn

• For interactive systems, this is very effective way to find users’ reactions and the required information

‘Wizard of Oz’ Prototyping

• A person simulates the responses of the system in response to some user inputs

• The person simulating the system is called ‘Wizard of Oz’

• Relatively cheap as only user interface software needs to be developed

• The users interact through this user interface software and all requests are channeled to the a person, who simulates the system’s responses

• This is particularly useful for new systems, which are extensions of existing software systems, and the users are familiar with the existing user interface

Executable Prototyping

• A fourth generation language or other (RDE)rapid development environment is used to develop an executable prototype

• This is an expensive option and involves writing software to simulate the functionality of the proposed system

• 4GLs based around information management database systems are useful for developing prototypes,

• Visual programming languages such as Visual Basic or ObjectWorks

• Internet-based prototyping solutions based on WWW browsers and languages. ready-made user interface and Java applets can be used to add functionality to the user interface

Comments on Prototyping

• Prototyping interactive applications is easier than prototyping real-time applications

• Prototyping is used better to understand and discover functional requirements, as compared to non-functional requirements

Lecture 22

N/A

Lecture 23

Writing Requirements
Requirements specification should establish an understanding between customers and
suppliers about what a system is supposed to do, and provide a basis for validation and
verification
• Typically, requirements documents are written in natural languages (like, English,
Japanese, French, etc.)
• Natural languages, by their nature, are ambiguous
• Structured languages can be used with the natural languages to specify requirements

Problems with Natural Languages
• Natural language understanding relies on the specification readers and writers using the
same words for same concept
• A natural language requirements specification is over-flexible. You can say the same
thing in completely different ways
• It is not possible to modularize natural language requirements. It may be difficult to find
all related requirements
– To discover the impact of a change, every requirement have to be examined

Problems with Requirements
• The requirements are written using complex conditional clauses (if A then B then C…),
which are confusing
• Terminology is used in a sloppy and inconsistent way
• The writers of the requirement assume that the reader has a specific knowledge of the
domain or the system and they leave essential information out of the requirements
document

Structured Language Specifications
• Structured natural language
• Design description languages
• Graphical notations
• Mathematical notations

Writing Requirements Level of detail needed is dependent on
– Type of requirements (stakeholder or process requirements)
– Customer expectations
– Organizational procedures
– External standards or regulations

Lecture 24

Requirements Document (or SRS)
• The requirements document is a formal document used to communicate the requirements
to customers, engineers and managers.
• It is also known as software requirements specifications or SRS
• The services and functions which the system should provide
• The constraints under which the system must operate
• Overall properties of the system
• Definitions of other systems which the system must integrate with
• Information about the application domain of the system
• It should include both the user requirements for a system and a detailed specification of
the system requirements
• In some cases, the user and system requirements may be integrated into one description,
while in other cases user requirements are described before (as introduction to) system
requirements
• Typically, requirements documents are written in natural languages (like, English,
Japanese, French, etc.) which are by their nature, ambiguous
• Structured languages can be used with the natural languages to specify requirements
• For software systems, the requirements document may include a description of the
hardware on which the system is to run
• The document should always include an introductory chapter which provides an overview
of the system and the business needs
• A glossary should also be included to document technical terms

• Structure of requirements document is also very important and contains
– Type of the system
– Level of detail included in requirements
– Organizational practice
– Budget and schedule for RE process

Six Requirements for RS
1. It should specify only external behavior
2. It should specify constraints on the implementation
3. It should be easy to change
4. It should serve as a reference tool for system maintainers
5. It should record forethought about the lifecycle of the system
6. It should characterize acceptable responses to undesired events.

How to Organize an SRS?Clients/developers may have there own way of organizing an SRS1. Introduction

2. General description
3. Specific requirements
4. Appendices
5. Index

Lecture 25

What Should Be Included in SRS?
• Functional requirements
– They define what the system does.how the inputs and outputs interrelate.
• Non-functional requirements
– They define the attributes of a system as it performs its job. They include system’s required levels of efficiency, reliability, security, maintainability, portability, visibility, capacity

SRS Quality Attributes
Correct, Consistent, Concise, Complete,
Verifiable, Modifiable, Design independent, Organized
Traced, Traceable,  Annotated,  
Unambiguous, Understandable by customer,

Complete
• An SRS is complete if it possesses the following four qualities
– Everything that the software is supposed to do is included
– Definitions of the responses of classes of input data in all realizable classes of situations
– All pages figures and tables are numbered, named, and referenced; all terms and units of measure are provided
– No sections are marked
“To Be Determined” (TBD)

Modifiable
An SRS is modifiable if requirements can be made easily
This attribute deals with format and style of SRS

Traced
An SRS is traced if the origin of its requirements is clear.

Traceable
the referencing of each individual requirement stated

Design Independent
• An SRS is design independent if it does not imply a specific software architecture 

Concise
The SRS that is shorter is better, 

Organized
• An SRS is organized if requirements contained therein are easy to locate.

The Balancing Act
• Achieving all the preceding attributes in an SRS is impossible
• Once you become involved in writing an SRS, you will gain insight and experience necessary to do the balancing act
• There is no such thing as a perfect SRS

Lecture 26

USE CASE MODELING
A use case specifies the behavior of a system or part of a system
They are used in requirements elicitation process
Use cases are applied to capture the intended behavior of the system under development

Use Cases
• Use case is a description of a set of sequences of actions
• A use case represents a functional requirement of the system
• Use cases can be applied to the whole system, part of a system and even individual classes and interface
• The UML provides a graphical representation of a use case

Contents of Use Case Diagrams
• Use cases
• Actors

• Dependency, generalization, and association relationships

Lecture 27

USE CASE MODELING
Documenting Use Cases
• Name
• Summary
– Short description of use case
• Dependency (on other use cases)
• Actors
• Preconditions
– Conditions that are true at start of use case
• Flow of Events
– Narrative description of basic path
• Alternatives
– Narrative description of alternative paths
• Post-condition

– Condition that is true at end of use case

Including a Use Case

Obtain and verify the order number. include (Validate user). For each part in the order, query its status, then report back to the user

Extending a Use Case
Extend relationship can be used to model
– Optional behavior

– Separate sub-flow that is executed only under given conditions

• include (Validate user)
• Collect the user’s order items
• (set priority)

• Submit the order for processing

Abstract Use Case Example
• Name: Validate PIN
• Summary : System validates customer PIN
• Dependency: none
• Actors: ATM Customer
• Preconditions: ATM is idle, displaying a Welcome message.
• Flow of Events: Basic Path
1. Customer inserts the ATM card into the Card Reader
2. If the system recognizes the card, it reads the card number
3. System prompt customer for PIN number
4. Customer enters PIN
5. System checks the expiration date and whether the card is lost or stolen
6. If card is valid, the system then checks whether the user-entered PIN matches the card PIN maintained by the system
7. If PIN numbers match, the system checks what accounts are accessible with the ATM card
8. System displays customer accounts and prompts customer for transaction type: Withdrawal, Query, or Transfer
• Alternatives:
– If the system does not recognize the card, the card is ejected
– If the system determines that the card date has expired, the card is confiscated
– If the system determines that the card has been reported lost or stolen, the card is confiscated
– If the customer-entered PIN does not match the PIN number for this card, the system re-prompts for PIN
– If the customer enter the incorrect PIN three times, the system confiscates the card
– If the customer enters Cancel, the system cancels the transaction and ejects the card
• Post-condition: Customer PIN has been validated

Lecture 28

Organizing Use Cases for ATM Customer
• The PIN validation can be the first part of each use case
• This common part of the three use cases is factored out as an abstract inclusion use case called Validate PIN
• The Withdraw funds, Query account, Transfer funds use cases can each be rewritten more concisely as concrete use cases that include the Validate PIN abstract use case

Use Cases of the ATM System
• Abstract use cases
– Validate PIN
• Concrete use cases
– Withdraw Funds
– Query Account
– Transfer Funds

Withdraw Funds Use Case
• Name: Withdraw Funds
• Summary : Customer withdraws a specific amount of funds from a valid bank account
• Dependency: Include Validate PIN abstract use case
• Actors: ATM Customer
• Preconditions: ATM is idle, displaying a Welcome message.
• Flow of Events: Basic Path
1. Include Validate PIN abstract use case
2. Customer selects Withdrawal, enters the amount, and selects the account number
3. System checks whether customer has enough funds in the account and whether the daily limit will not be exceeded
4. If all checks are successful, system authorizes dispensing of cash
5. System dispenses the cash amount
6. System prints a receipt showing transaction number, transaction type, amount withdrawn, and account balance
7. System ejects card
8. System displays Welcome balance
• Alternatives:
– If the system determines that the account number is invalid, it displays an error message and ejects the card
– If the system determines that there are insufficient funds in the customer’s account, it displays an apology and ejects the card
– If the system determines that the maximum allowable daily withdrawal amount has been exceeded, it displays an apology and ejects the card
– If the ATM is out of funds, the system displays an apology, ejects the card, and shuts down the ATM
• Post-condition: Customer funds have been withdrawn

Query Account Use Case
• Name: Query Account
• Summary: Customer receives the balance of a valid bank account
• Actor: ATM Customer
• Dependency: Include Validate PIN abstract use case
• Precondition: ATM is idle, displaying a Welcome message
• Flow of Events: Basic Path
1. Include Validate PIN abstract use case
2. Customer selects Query, enters account number
3. System reads account balance
4. System prints a receipt showing transaction number, transaction type, and account
balance
5. System ejects card
6. System displays Welcome message
• Alternative: If the system determines that the account number is invalid, it displays an
error message and ejects the card
• Post-condition: Customer account has been queried
Transfer Funds Use Case
• Name: Transfer Funds
• Summary: Customer transfers funds from one valid bank account to another
• Actor: ATM Customer
• Dependency: Include Validate PIN abstract use case
• Precondition: ATM is idle, displaying a Welcome message
• Flow of Events: Basic Path
1. Include Validate PIN abstract use case
2. Customer selects Transfer and enters amounts, from account, and to account
3. If the system determines the customer has enough funds in the from account, it performs the transfer
4. System prints a receipt showing transaction number, transaction type, amount transferred, and account balance
5. System ejects card
6. System displays Welcome message
• Alternatives:
– If the system determines that the from account number is invalid, it displays an error message and ejects the card
– If the system determines that the to account number is invalid, it displays an error message and ejects the card
– If the system determines that there are insufficient funds in the customer’s from account, it displays an apology and ejects the card
• Post-condition: Customer funds have been transferred

Lecture 29

Four Aims of Modeling
1. Models help us to visualize a system as it is or as we want it to be
2. Models permit us to specify the structure or behavior of a system
3. Models give us a template that guides us in constructing a system
4. Models document the decisions we have made

Principles of Modeling
• The choice of what models to create has profound influence on how a problem is attacked and how a solution is shaped
• Every model may be expressed at different levels of precision
• The best models are connected to reality
• No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models

Steps in Problem Analysis
• Gain agreement on the problem definition
• Understand the root causes – the problem behind the problem
• Identify the stakeholders and the users
• Define the solution system boundary
• Identify the constraints to be imposed on the solution

Principles of Modeling
Partitioning, Abstraction, Projection

• Partitioning: Captures aggregation/part of relations among elements in the problem domain
• Abstraction: Captures generalization/specialization relations among elements in the problem domain
• Projection: Captures different views of elements in the problem domain

Features of Modeling Techniques
• Facilitate communication
• Provide a means of defining the system boundary
• Provide a means of defining partitions, abstractions, and projections
• Encourage the analyst to think and document in terms of the problem as opposed to the solution


Object-Oriented Modeling
• The main building block of all software systems is the object or class.
• An object is a thing, generally drawn from the vocabulary of the problem space or the solution space.
• A class is a description of a set of common objects.
• Object-oriented paradigm helps in software modeling of real-life objects in a direct and explicit fashion.
• It also provides a mechanism so that the object can inherit properties from their ancestors, just like real-life objects.
• Every object has identity, state, and behavior.
• The object-oriented approach has useful in all sorts of problem domains and from degrees of size and complexity.
• Object-oriented development provides the conceptual foundation for assembling systems using technology such as Java Beans
• A number of consequences flow from the choice of viewing the world in an objectoriented fashion.
– What is the structure of good OO architecture?
– What artifacts the project should create?
– Who should create them?
– How should they be measured?

Lecture 30

Unified Modeling Language• Visualizing, specifying, constructing, and documenting object-oriented systems is exactly the purpose of the unified modeling language or UML
• The rules of UML focus on the conceptual and physical representation of a system
• Process independent

UML provides a very rich set of concept areas
– Static structure
– Dynamic behavior
– Implementation constructs
– Model organization
– Extensibility mechanisms

Lecture 31

Steps in Object-Oriented Analysis

• Identify classes within the problem domain

• Define the attributes and methods of these classes

• Define the behavior of those classes

• Model the relationship between those classes

Possible Objects in the ATM Domain

• External device I/O objects

– Card Reader

– Cash Dispenser

– Keyboard/Display

– Receipt Printer

• External user

– ATM Operator

• User role/entity objects

– ATM Customer

– ATM (ATM Info)

– Debit Card

– ATM Card

– Bank Account

– ATM Cash

– ATM Transaction

– PIN Validation Transaction

– Withdrawal Transaction

– Query Transaction

– Transfer Transaction

– Checking Account

– Savings Account

Lecture 32

OBJECT-ORIENTED STATIC MODELING OF THE BANKING SYSTEM

SYSTEM AND SUBSYSTEM CLASSES

Lecture 33

Banking System Context Class Diagram

• The system context diagram is developed to show the external classes to which the Banking system has to interface

• We develop the context class diagram by considering the physical classes

• The external classes correspond to the users and I/O devices depicted to the classes in the application domain

• They are the Card Reader, the Cash Dispenser, the Receipt Printer, the ATM Customer who interacts with the system via a keyboard/display, and the Operator who also interacts with the system via a keyboard/display

• There is one instance of each of these external classes for each ATM

• The system context class diagram for the Banking system depicts the system as one aggregate class that receives input from and provides output to the external classes

Lecture 34

Modeling Techniques

• Object-oriented modeling

– Static and dynamic modeling

• Functional modeling

• Dynamic modeling

Function-oriented Modeling

• In function-oriented modeling, a hierarchy of functions (also known as processes, transforms, transactions, bubbles, and activities) is created

• At the root of the hierarchy is the most abstract function, while the least abstract atleaf nodes.

• Function-oriented modeling is based on the concept of functions or processes, so they become the most important element in this approach

• The functional model describes computations within a system, i.e., what happens

• Each function is a sequential activity that execute with other functions

• The functional model specifies the result of a computation

Types of Functions

• Asynchronous Function

• Asynchronous State Dependent Function

• Periodic Function

• Periodic State-Dependent Function

Object-oriented modeling

Identification of Objects and Classes

Structure

External Device I/O Objects

User Role Objects

Control Objects

Data Abstraction Objects

Algorithm Objects

Functional Modeling
• Non-interactive programs, such as compilers, usually are used for computations. The functional model is the main model for such programs
• On the other hand, databases often have a trivial functional model, since their purpose is to store and organize data, not to transform it
• Fundamental to most of techniques used for functional modeling, is some combination of data flow diagrams and data dictionaries

Data Flow Diagrams

• Data flow diagrams are composed of data on the move, transformations of data into other

data, sources and destinations of data, and data in static storage

• Data flow diagrams show the flow of data through a system

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 the context-level or level zero 0
• Always label data flow arrows
• Do not represent procedural logic

Constructing a DFD

• Determine data objects and associate operations

• Determine external entities

– Producers of data

– Consumers of data

• Create a level 0 DFD

Constructing a DFD

• 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

Data Dictionaries
Data dictionaries are simply repositories in which to store information about all data items defined in DFDs
Contents of Data Dictionaries
• Name of the data item
• Aliases
• Description/purpose
• Related data items
• Range of values
• Data flows
• Data structure definition/form

Lecture 35

Function-oriented Modeling Techniques

• Structured requirements definition

• Structured analysis and system specification

• Modern structured analysis

• Real-time structured analysis and structured design

• Structured analysis and design technique

• PSL/PSA

Real-Time Structured Analysis and Structured Design (RSTAD)

• Develop the system context diagram

• Perform data control flow decomposition

• Develop control transformations

• Define mini-specifications

• Develop data dictionary

Lecture 36

Structured Analysis and Design Technique (SADT)

• A model of the problem is constructed, which is composed of hierarchy of diagrams

• Each diagram is composed of boxes and arrows

• The topmost diagram, called the context diagram, defines the problem most abstractly

• As the problem is refined into sub-problems, this refinement is documented into other diagrams

• All boxes should be numbered in the lower right corner, to reflect their relative dominance

• Arrows may enter top, left, or bottom sides of the box, and can exit only from the right side of the box

• Arrows at bottom represent mechanism and provide ability to document how the function will operate, who will perform it, or what physical resources are needed to perform the function

SADT Level 2 Diagram

Lecture 37

Dynamic Modeling

• A system can first be understood by examining its static structure and the relationships that exist among different elements at single moment in time.

• Then we examine changes in these elements and their relationships over time.

• Those aspects of a system that are concerned with time and changes are the dynamic model.

• Control is an aspect of a system that describes the sequences of operations that occur in response to external stimuli, without any consideration.

• Dynamic modeling deals with flow of control, interactions, and sequencing of operations in a system of concurrently-active objects.

• Major dynamic modeling concepts are events, which represent external stimuli, and states, which represent values of objects.

• There are two ways to model dynamic behavior.

• One is the life history of one object as it interacts with the rest of the world; the other is the communication patterns of a set of connected objects as they interact to implement behavior.

• This is displayed in state chart diagrams in UML

Techniques for Dynamic Modeling

• Finite state machines (FSM)

• Statecharts

• Petri nets

• Decision tables and decision trees

• Collaboration diagrams

• Sequence diagrams

• There are two notations commonly used for finite state machines

– State transition diagrams (STDs)

– State transition matrices (STMs)

Statecharts

• Statecharts are an extension to finite state machines, proposed by Harel

• The concept of superstate, which can be used to aggregate sets of states with common transitions

• They provide a notation and a set of conventions that facilitate the hierarchical decomposition of FSM

• Statecharts provide natural extensions to FSMs to make them more suitable for specifying external behavior of real-time systems

Lecture 38

Statechart for ATM Control: Validate PIN Use Case

Statechart for ATM Control: Validate PIN Use Case

1: The ATM Customer actor inserts the ATM card into the Card Reader. The Card Reader Interface object reads the card input

1.1: The Card Reader Interface object sends the Card Input Data, containing card ID, start Date, and expiration Date, to the entity ATM Card

1.2: Card Reader Interface sends the Card Inserted event to ATM Control. As a result, the ATM Control statechart transitions from Idle state (the initial state) to Waiting for PIN state. The output event associated with this transition is Get PIN

1.3: ATM Control sends the Get PIN event to Customer Interface

1.4: Customer Interface displays the Pin Prompt to the ATM Customer actor

2: ATM Customer inputs the PIN to the Customer Interface object

2.1: Customer Interface requests Card Data from ATM Card

2.2: ATM Card provides the Card Data to the Customer Interface

2.3: Customer Interface sends the Customer Info, containing card ID, PIN, start Date, and expiration Date, to the ATM Transaction entity object

2.4: Customer Interface sends the PIN Entered (Customer Info) event to ATM Control. This causes ATM Control to transition from Waiting for PIN state to Validating PIN state. The output event associated with this transition is Validate PIN

2.5: ATM Control sends a Validate PIN (Customer Info) request to the Bank Server

2.6: Bank Server validates the PIN and sends a Valid PIN response to ATM Control. As a result of this event, ATM Control transitions to Waiting for Customer Choice state. The output events for this transition are Display Menu and Update Status

2.7: ATM Control sends the Display Menu event to the Customer Interface

2.7a: ATM Control sends an Update Status message to the ATM Transaction

2.8: Customer Interface displays a menu showing the Withdraw, Query, and Transfer options to the ATM Customer actor

Rest is ignored for time Being

Lecture 39

Interaction Diagrams

• Interaction diagrams are used to model the dynamic aspects of a system. For the most part, this involves modeling concrete or prototypical instances of classes, interfaces, components, and nodes, along with messages that are dispatched among them, all in the context of a scenario that illustrates a behavior.

• Interaction diagrams may stand alone to visualize and document the dynamics of a particular flow of control of a use case.

Types of Interaction Diagrams: 

• Sequence diagrams

• Collaboration diagrams

Sequence Diagrams
• A sequence diagram is an interaction diagram that emphasizes the time ordering of
messages
• Graphically, a sequence diagram is a table that shows objects arranged along the X axis
and messages, ordered in increasing time, along the Y axis
Collaboration Diagrams
• A collaboration diagram is an interaction diagram that emphasizes the structural
organization of the objects that send and receive messages
• Graphically, a collaboration diagram is a collection of vertices and arcs

Collaboration Diagram: ATM Client Validate PIN Use Case

Sequence Diagram: ATM Client Validate PIN Use Case

Rest is ignored for time Being

Lecture 40

SRS for the Banking System

• Preface

• Introduction

• Glossary

• Specific requirements

• Appendices

– Use-case model

– Object model

– Data-flow model

• Preface

– This should define the expected readership of the document and describe its version history and a summary of the changes made in each version

• Glossary

– This should define all technical terms and abbreviations used in the document

• Specific requirements

– This should define specific requirements for the system using natural language with the help of diagrams, where appropriate

Banking System OBJECT MODEL

Rest is ignored for time Being

Lecture 41

REQUIREMENTS ENGINEERING FOR AGILE METHODS

• Agile methods are a family of software development processes

• Their aim is to deliver products faster, with high quality, and satisfy customer needs

• Agile methods have become popular during the last few years

• It involves several practices, such as just-in-time development, total quality management, and continuous process improvement

• The principle of lean production is the constant identification and removal of waste, that is, anything that does not add value for the customer to the final product

• Agile methods focus on

– Delivering value for the customer

– Ensuring that the customer understand such value and be satisfied by the project

• Agile methods focus on producing and delivering to the customer only those features that are useful

• Producing anything that is not required is considered a mistake

• To achieve such elimination of waste, agile methods claim to be

– Adaptive rather than predictive

– People-oriented rather than process-oriented

• A close collaboration between the development team and the customer is a must, so that

– Requirements are fully identified and correctly understood

– Final products reflects what the customer needs, no more no less

Agile Methods
• eXtreme Programming
• Scrum
• Dynamic Systems Development Method
• Adaptive Software Development
• The Crystal Family

Agile Manifesto
• Individuals and Interactions over Process and Tools
• Customer Collaboration over Contracts
• Working Software over Documentation
• Responding to Change over Planning

RE in Agile Methods

• In agile methods, the whole development team is involved in requirements elicitation and management, while in traditional approaches often only a subset of the development team is involved

• This approach is feasible only if the size of the problem is limited, as only a small development team can interact directly with the customer

• If the problem is bigger, the team can use other techniques for eliciting and managing requirements

Customer-on-Site Requirements

• Availability

• Complete knowledge

• Decision power

Waste in Requirements

Identification and reduction of waste from requirements

In lean practices, the reduction of waste is extremely important because waste always generates more waste

both wrong and useless requirements

All the waste generated is a cost for the customer both directly and indirectly

Waste Reduction Techniques

– Requirements prioritization

– Incremental releases

Prioritization Activities

• The development team estimates the time required to implement each functionality. If the effort required is too high, the requirement is split into simpler ones that can be implemented with less effort

• The customer specifies business priorities for each functionality

• According to the business priorities, the development team assign a risk factor to the functionalities

• The customer and the development team identify the functionalities to implement in the iteration

Requirements Evolution

• Agile methods assume that is very hard to elicit all the requirements from the user upfront, at the beginning

• They also assume that such requirements evolve in time as the customer may change its mind or the overall technical and socio-economical environment may evolve

• Requirements are not well known at the beginning of the project

• Requirements change

• Making changes is not expensive

• Agile methods assume that the cost of introducing changes in a product is nearly constant over the time, but this hypothesis is not true in every context

• Usually, the cost of implementing changes grows exponentially over the time

• On the other hand, if development phases are grouped together in very short iterations and binding decisions are taken as late as possible, the growing of the cost is limited

• In order to manage requirements evolution, agile methods use variable scope-variable price contract. This means that the features really implemented into the system and its cost evolve as well

• Requirements are negotiated throughout the project between the customer the development team

Managing Variability

• Decoupling requirements

• Requirements elicitation and prioritization

• Decoupling requirements

– Requirements have to be as independent as possible in order to clearly identify what to implement

• Requirements elicitation and prioritization

– At the beginning of every iteration, there is a requirements collection and prioritization activity. During that, new requirements are identified and prioritized.

– This approach helps to identify the most important features inside the ongoing project.

• Features are implemented mainly according to their prioritization, not their functional dependence

Tools for Requirements Management in Agile Methods

• Paper, pencil, and pin boards

• UML modeling tools

• Requirements negotiation tools

• Instant messaging tools

• Project management tools

Lecture 42

Web-Based Information Systems (WBIS)
• What makes web systems different from the traditional software systems that their planning and construction requires a unique development process?
Types of WBIS Models
• Those that deliver advertising and promotion
• Those that assist business workflow
• Those that facilitate inter-organizational interaction
• Those that support multi-participant trading

Differences in WBIS Models
• Each kind of WBIS model emphasizes distinct aspects of site design depending on its purpose
• Some focus on supporting business to business transactions, the construction of online metaphors for business activity, and customer assistance
• Others look at promoting organizational brand, building market trust and credibility
• While some simply accentuate web contents, layout, navigation and search for organizational information

Key facts
• The scope of concerns of web site construction can be significantly enlarged, due to the marketing-driven development process
• The delivery cycle for web-enabled applications is commonly very short, i.e., 3 months, which leaves very little time for any formal requirements gathering
• Current requirements engineering practices for WBIS projects are inadequate, failing requirements engineers in identification and characterization of the potential system users, their needs and preferences, and the features required of the web systems under development
• There is need to emphasize on the stakeholder views and opinions on requirements evolution in web development
• A stakeholder in this context is considered to be any individual, group, or organization whose actions can influence or be influenced by the development and use of the system whether directly or indirectly

RE Approaches for Development of WBIS
• Web engineering
• Relationship management methodology
• Internet commerce development methodology
• Web information systems development methodology

Web Information Systems Development Methodology (WISDM)
• WISDM is employed with the aim for evaluating the effectiveness of a pre-web
methodology to the web-based methodology
• RAD and prototyping are effective approaches for WISDM project development

Rest is ignored for time Being

Lecture 43

Software Product Lines
• A software product line consists of a family of software systems that have some common functionality and some variable functionality
• To take advantage of the common functionality, reusable assets are developed
• Reusable assets include: requirements, designs, components, and so on
• These reusable assets can be reused by different members of the family
• The software industry is increasingly recognizing the strategic importance of software product lines

Lecture 44

Requirements Prioritization
• When developing software systems, similar trade-offs must be made
• The functionality that is most important for the customers might not be as important when other aspects (e.g. price) are factored in
• We need to develop the functionality that is most desired by the customers, as well as least risky, least costly, and so forth
• The quality of software products is often determined by the ability to satisfy the needs of the customers and users
• Prioritization helps to identify the most valuable requirements

Prioritization Process
• Prioritization is an iterative process and might be performed at different abstraction levels
and with different information in different phases during the software lifecycle

Prioritization Methods
The methods are based on quantitatively assigning values
Quantitative methods make it easier to aggregate different decision

Negotiation Approaches
• Negotiation approaches focus on giving priorities to requirements by reaching agreement between different stakeholders