Software Requirement

Analysis and Specification

Requirement engineering
Problem analysis
Data dictionaries
ER diagram
Approaches to problem analysis
s/w Prototyping
Nature of SRS
Characteristics of good SRS
Organization of SRS
Specifying behavioural requirements
FSM(finite state machine)
• When we receive request for new s/w project, so we first understand
the requirements of customer.
• Project may replace existing system, may be enhancement or
extension of current system.
Problem analysis
• process of understanding real-world problems and user 's needs and
proposing solutions to meet those needs.
• The goal of problem analysis is to gain a better understanding of the
problem being solved , before development begins.
• To identify the root cause, or the problem behind the problem, ask
the people directly involved.
• Identifying the actors on the system is a key step in problem analysis.
Five steps of problem analysis:
Step1 : Gain agreement on the problem definition
write a simple and clear definition of the problem description.
Establish an order of importance for all features of the system.
Come to an agreement with all stakeholders.
Resolve conflicts by negotiation

Step 2 : Identify the root causes of the problem

Make sure that the problem identified is the real problem
Addressing the wrong problem leads to failure
problem can have several causes:
Some might be eliminated by non-software solutions,Some might need contradictory solutions ,More than
one solution might be needed
This part of the analysis requires input from extremely knowledgeable, insightful and experienced persons.
Step 3 : Identify stakeholders and users
Stakeholder: anyone who could be affected by the new system or has input to provide in the implementation of the new system
Complex problems always involve the input of different stakeholders that have different viewpoints on the problem.
Users: will use the system
Managers: will pay for the system, or will manage the users
IT people: will install, manage and maintain the system
External regulators: will impose constraints on the system operation
System developers: will implement a solution to the problem
Forgetting one of these might lead to major rework later on, or even to project failure.

Step 4 : Define the system boundary

Any software system has to interact with its environment
System boundary describes an envelope in which the solution is contained.
System is divided as:
system itself and its functionalities, things (outside the system) that interacts with the system
Actors: supplies, uses, or modifies the information in the system
Someone or something, outside the system, that interacts with the system
Later on, this early information will direct how the system interfaces will be defined.

Step 5 : Identify the constraints on the system

Constraint : a restriction on the degree of freedom we have in providing a solution
They are as important as requirements : they direct what the system should not do, or what the system should not be.
 Requirement Engineering
• It produces 1 large document, written in natural language.
• Contains description of what system will do without describing “How it will do?”.
• Without SRS, there is no way to validate that built system satisfies s/w
requirements.
• RE: is disciplined application of proven principles, methods, tools and notations
to describe proposed system’s intended behaviour and it’s associated constraints.
This process consist of 4 types:
1. Requirements Elicitation.
2. Requirements Analysis
3. Requirements Documentation
4. Requirements Review
1. Requirements Elicitation:
Also called gathering of qwith the help of customer and existing system processes, if available.
Real requirements reside in user’s mind and are gathered by asking questions, conducting interviews,
brainstorming sessions etc.

2. Requirements Analysis: it starts with requirements Elicitation.

Requirements are analysed in order to identify inconsistencies, defects, omissions etc using DD,DFD,ER
diagrams.

3. Requirements Documentation: this is end product of Requirements Elicitation and requirement analysis.
Requirements Documentation is important as it will be foundation for design of s/w. Document is known as
SRS.
• Requirement prioritization
4. Requirements Review: it is carried out to improve quality of SRS.
Also called requirements Verification and this is continuous activity that is incorporated into elicitation.
,analysis and documentation.
Input to Requirement Engineering: “Problem-Statement” prepared by customer.
Output of RE: SRS
 Requirement
Problem Statement Elicitation

Requirement
Analysis

Requirement
Engineering
Requirement
Documentation

Requirements
SRS Review

Fig: Crucial process steps of requirements engineering

Requirements
SRS: contract b/w developer and customer.
It’s a detailed description of a software system to be developed with its
functional and non-functional requirements
2. SRS(Software requirement specification), describes only S/W
SRS treat system as black box.
It must delineate inputs, outputs, functional requirements and non-
functional requirements .
SRS Problems:
1. Requirements are difficult to uncover.(impossible to identify all
requirements)
2. Requirements change.(change as user begin to understand system)
3. Over-reliance on CASE(computer aided s/w engg.) tools.
4. Tight project schedule.
5. Communication barriers b/w client and developer.
6. Lack of resources.
7. Changing,conflicting,non-clear requirements
 Types of Requirements
1. Known Requirements: Something a stakeholder(1 having direct or indirect influence on system requirements) believes
to be implemented.
2. Unknown Requirements: Forgotten by stakeholder as they are not needed right now or needed only by another
stakeholder.
3. Undreamt Requirements: Stakeholder may not be able to think of new requirements due to limited domain knowledge.
These 3 requirements may be functional or non-functional.
Functional requirements describe what s/w has to do. Often called product features.
It tells behavior of the system as it relates to the system's functionality.
Non-functional requirements:
• elaborates a performance characteristic of the system.
• Non-functional requirements : maintainability, portability, documentation, quality, reliability, extensibility,fault tolerance,
testability, performance, availability, usability and flexibility for user.
• describe aspects of the system that don't relate to its execution, but rather to its evolution over time (e.g. maintainability,
extensibility, documentation, etc.).
• Nonfunctional requirements describe the general characteristics of a system. They are also known as quality attributes.
Functional requirement ex:
• A system must send an email whenever a certain condition is met
(e.g. an order is placed, a customer signs up, etc).

• A related non-functional requirement for the system may be:

• Emails should be sent with a latency of no greater than 12 hours from
such an activity.
 Prepare problem statement for student examination system

• A University wish to develop a software system for student result

management of its M.Tech. Programme.
• A problem statement is to be prepared for the software development
company.
• The problem statement may give an overview of the existing system and broad
expectations from the new software system.
Requirements elicitation
• Most difficult, error-prone aspect of s/w development
• It succeed only through customer-developer partnership.
• Real requirements reside in user’s mind and are gathered by asking
questions, conducting interviews, brainstorming sessions etc.
• Developers and users have different mind-set,expertise and vocab.
• Due to communication gap, there are chances of conflicts that may
lead to inconsistencies, misunderstanding of requirements.
• So, requirement elicitation requires collaboration of several groups of
participants who have different background.
Requirements elicitation methods:
1. Interviews.
2. Brainstorming sessions.
3. FAST (Facilitated Application Specification Technique)
4. QFD (Quality function deployment)
5. Use case Approach
 1. Interview:
• After receiving problem statement from customer,
1st step is to arrange meeting with customer.
• Both parties would understand each other.
• Requirement engineers interact with customer to understand user requirements and
expectations from s/w.
• It is impossible to interview every stakeholder hence representatives from groups are selected
based on their expertise and credibility.
• Interview may be:
1. Open-ended: no pre-set agenda, context free questions may be asked to understand the
problem.
2. Structured: agenda of open questions is prepared.
Design proper questionnaire and questions should be simple and short.
 2. Brainstorming Sessions:
• Group technique to understand user’s requirements.
• GD(group discussion): generate lot of ideas quickly but highly trained facilitator required to avoid group bias
and group conflicts.
• It promotes creative thinking, generate new ideas and provide platform to share views, apprehensions,
expectations and difficulties of implementation.
• Requirements in long list can be categorized, prioritized and pruned.
• This group technique may be carried out with specialised groups like actual user, middle-level managers etc
or with total stakeholders.

• It is intended to generate lots of new ideas hence providing a platform to share views
• Every idea is well-documented(written in simple English) so that everyone can see it.
• Finally a document will be prepared which will consist of list of requirements and their priority if possible.
3. FAST (Facilitated Application Specification Technique)
• This team oriented approach is similar to brainstorming sessions and objective is to bridge expectation gap b/w developer and
customer.
• To reduce expectation gap, team oriented approach is developed for requirements gathering called FAST.
• Creation of joint team of customers and developers who work together to understand expectations and propose
a set of user’s requirements.

Basic guidelines for FAST:

1. Arrange meeting at neutral site for developers and customers.
2. Establishment of rules for preparation and participation.
3. Prepare an informal agenda that encourage free flow of ideas. An agenda is
suggested that with enough formality to cover all important points but informal enough to encourage the free flow of
ideas.
4. Appoint a facilitator to control meeting. Facilitator may be developer, customer or an outside expert.
5. Prepare definition mechanisms-Board,worksheets etc.
6. Participants should not criticize or debate.
 Activities of FAST session:
• Each participant presents his or her list of objects, services(functions), constraints (cost,size) and
performance(speed, accuracy) for discussion.
• List may be displayed in meeting by using board, large sheet of paper so that they are visible to all participants.
• Combined lists for each topic are prepared by eliminating redundant entries and adding new ideas.
• Combined lists are again discussed and consensus(general agreement) lists are finalised by facilitator.

• Team is then divided into smaller subteams,each work to develop mini-specifications for 1 or more entries of
lists.
• Each subteam then presents mini-specifications to all FAST attendees.
• After discussion, additions or deletions are made to list and final list is prepared.
• Objective is to close the gap between what the developers intend and what users
expect. 
4. QFD (Quality function deployment)
Its quality management technique that helps to incorporate voice of customer.
QFD has foll. 4 Steps:
1. Identify all stakeholders e.g. customers and developers.
2. List out requirements from customer;inputs;considering different viewpoints.
Some customer’s expectations may be unrealistic or ambiguous and may be translated into realistic or unambiguous
requirements if possible.
3. Value indicating degree of importance, is assigned to each requirement on a scale of 1 to 5.
It may be based on cost/benefit analysis particular to project.
QFD is a structured approach to defining customer needs or requirements and translating them into specific plans to
produce products to meet those needs.
QFD is the process used to identify the priorities for customer needs and expectations and to transfer these priorities into
the technical design of the product.
5 points: Very Important
4 points: Important
3 points: Not Important, but nice to have
2 points: Not Important
1 points: Unrealistic, requires further exploration
4. In the end, Requirement engineers may review final list of requirements and categorized them as:
a. it’s possible to achieve.
b. It should be deferred and reason for it.
c. It’s impossible to achieve and should be dropped off.
If time and effort permits, second category requirements may be reviewed and few of them may be
transferred to category first for implementation.

3 types of requirements are identified:

1. Normal requirements: In this objective and goals of proposed software are discussed with the
customer. Example – normal requirements for a result management system may be entry of
marks, calculation of results etc
2. Expected Requirements(so obvious that customer does not explicitly state them. Ex: protection
from unauthorised access, warning message for wrong entry of data)
3. Exciting requirements(features that go beyond customer’s expectations. EX: if an unauthorised
access is noticed by s/w, it should immediately shut down all proceses and an email is generated
to system administrator )
 5. Use case Approach
• This approach uses a combination of text and pictures in order to improve understanding of requirements.
• Use cases are structured outline/template for description of user requirements, modelled in structured
language like English.
• They only give functional view of system. Use case describes “What of system” and not “How”.

Components used for design of use case approach:

1. ACTOR: external agent, lies outside system model but interacts with it in some way. An actor may be person,
customer or any external entity interacting with system.
2. Use Cases: use case is initiated by user with particular goal in mind and completes when goal is satisfied.
It describes sequence of interactions b/w actors and systems necessary to deliver services that satisfies
goal. System is treated as black box.

Written in an easy language.

Users may validate use cases and may involve in process of gathering and defining the requirements.
No standard template, popular as capture requirements in an effective way.
 Use case diagram:captures the functional aspect of the system.

• Visually represents what happens when an actor interacts with system.

• System is shown as rectangle with name of system inside
• Actors are shown as stick figures and appear outside of rectangle as they are
external to system.
• Use cases are shown as solid bordered ovals labelled with name of use case. Appear
within rectangle, providing functionality. An oval represents a use case
• A line(with arrowhead) is used to represent a relationship between an actor
and a use case.
• Relationships are lines or arrows b/w actors and use case and/or b/w use cases
themselves.

Actor Use case Relationship b/wactors and use case and/or b/w use cases
Outline for creating use cases

1. Identify all the different users of system.

2. Create a user profile for each category of users, including all the
roles the users play that are relevant to system.
3. Create use case for each goal, following use case template.
4. Structure the use cases
5. Review and validate with users.
 Use case template
1. Brief description: describe brief purpose of use case.
2. Actors: list actors that interact and participate in this use case.
3. Flow of events
3.1 Basic flows: list primary events that will occur when this use case is executed.
3.2 Alternative flows: any other possible flow in this use case. Use case can have many alternate flows.
4. Special Requirements: business rules for basic and alternate flows should be listed as special
requirements. Both success and failure scenarios should e described.
5. Pre-conditions: conditions that need to be satisfied for use case to perform.
6. Post-conditions: after the execution of use case, different states of system are defined here. Define
different states in which you expect the system to be in, after the use case executes.
7. Extension points
 Update Train Information

Report Generation
Admin

Login

View Reservation Status

View Train Schedule Passenger

Reservation Clerk Reserve Seat

Cancellations
Fig: Use Case Diagram for Railway Reservation System
Use case template:

(III) Student/ Teacher

 Requirement Analysis:
Important activity after elicitation.

We analyse, refine and scrutinize gathered requirements in order to make consistent and unambiguous requirements.

Review all the requirements and provide a graphical view of entire system.

Fig: Requirement Analysis steps

Draw
context Develop
diagram Prototypes Model
(optional) Requirements
Finalise requirements
Steps of RA:
• We may interact with customer to clarify points of confusion.
• After the completion of analysis, it's expected that understandability of project
may improve significantly.
Step-1: Draw Context Diagram
It’s simple model that defines boundaries and interfaces of proposed system with
external world.
It identifies entities outside proposed system that interact with system.
Fig: CD for Student result management system Administrator Subject Information Entry Marks Entry Operator
Student Information Entry Marks entry

Student result
management
system
Student information report generated Student performance report generated

Marksheet generated
Step-2: Development of Prototype(optional)
• Use customer’s feedback to continuously modify prototype until customer is satisfied.

Step-3: Model requirements:

1. DFD
2. DD
3. ER
4. S/W Prototyping
• This process consist of graphical representations of functions, data entities, external entities and relationships b/w them.
• Ex: DFD,ER diagrams, data dictionaries.
• Graphical view help to find incorrect, inconsistent and missing requirements.

Step-4: Finalise the requirements:

• After modelling requirements, now we will have better understanding of system.
• Inconsistencies and ambiguities: removed
• Elicitation and analysis activities have provided better insight to system.
• Now finalise analysed requirements and next step is to document these requirements in prescribed format.
Step-2: Development of Prototype(optional)
• Use customer’s feedback to continuously modify prototype until customer is satisfied.

Step-3: Model requirements:

1. DFD
2. DD
3. ER
4. S/W Prototyping
• This process consist of graphical representations of functions, data entities, external entities and relationships b/w them.
• Ex: DFD,ER diagrams, data dictionaries.
• Graphical view help to find incorrect, inconsistent and missing requirements.

Step-4: Finalise the requirements:

• After modelling requirements, now we will have better understanding of system.
• Inconsistencies and ambiguities: removed
• Elicitation and analysis activities have provided better insight to system.
• Now finalise analysed requirements and next step is to document these requirements in prescribed format.
• Requirement Analysis/Structural Analysis Tool:
 Modelling :Requirement Analysis
DFD(Data Flow Diagrams)
• Tool that describe flow of data or information into and out of a system.
• A DFD is a graphic representation of the flow of data or information through a system
• Used for modelling requirements.
• Focus on
1. flow of information(where data comes from, where it goes and how it gets stored).
2. How data is processed by system in terms of inputs and outputs.
DFD is a tool that depicts flow of data through a system and the work or processing performed by
that system.
1. Process(Function): Work or actions performed on data so that they are transformed, stored
or distributed.
• process transforms incoming data flow into outgoing data flow.
eg:
• Update
• Calculate
• Verify
2. Data store: Data at rest, repositories of data in the system.
Eg,
– Database
– Files
– Folder
 3. Source/sink(External entity)
• The origin and/or destination of data, sometimes referred to as external entities
• Source of system inputs or Sink of system outputs
• Objects outside system with which system communicates
• Eg,
– Clients
– Employees
– Bank

4. Data flow
• Data in motion, moving from one place in the system to another(represents
flowing data).
• Label arrows with name of data that moves through it.
• Eg,
– Invoice
– Receipt
– Enrolment form
DFD Symbols

SYMBOL NAME FUNCTION

Data flow used to connect processes to each other, to sources or to sinks.
Arrowhead indicate direction of data flow.
Process (Function) performs some transformation of input data to yield output data.

Source or Sink(external entity) Source of system inputs or sink of system outputs.

(input/output)
Repository of data. Arrowheads indicate net inputs and net
Data Store outputs to store.
1. All names used to refer to items in DFD should be unique.
2. Different from flow-chart. Arrows in flow-chart represents order of events. But arrows in
DFD represents flowing data.
3. Don’t become bogged down with details. Defer error conditions and error handling until end
of analysis.
4. Circle/Oval shows process that transform data inputs into data outputs.
5. Curved lines show data flow into or out of process or data store.
6. Data Store: indicate data is stored which can be used at later stage or by other processes in
different order. Place for collection of data items
7. Source or sink is an external entity and acts as source of system inputs or sink of system
outputs.
 DFD Levelling 0,1,2………
• Dfd: represent system or s/w at any level of abstraction.
• DFds may be partioned into levels that represents increasing information flow and functional detail.
• Level-0 DFD (or fundamental system model or context model) represents entire system as single
bubble with i/p and o/p data indicated by incoming and outgoing arrows respectively.
• Then, system is decomposed represented by level 1 DFD with multiple bubbles.
• Decompose level 0 DFDs as needed. Level 1 is expanded into more detail.

• Parts of system represented by each of these bubbles are then decomposed and documented as more
and more detailed DFDs.
• This process may be repeated at as many levels as necessary until problem at hand is well understood.
 Level 1 - overview diagram
• gives overview of full system
• identifies major processes and data flows between them
• identifies data stores that are used by the major processes
• boundary of level 1 is the context diagram

Level 2 - detailed diagram

• level 1 process is expanded into more detail
• each process in level 1 is decomposed to show its constituent processes
• boundary of level 2 is the level 1 process
Sales Forecast is process of estimating future sales.
Payroll: list of company’s employees and amount of money they are to be paid.
•  First, incoming orders are checked for correct book titles, author's names, and other information and then batched into
other book orders from the same bookstore to determine how may copies can be shipped through the ware house.
• Also, the credit status of each book stores is checked before shipment is authorized. Each shipment has a shipping notice
detailing the kind and numbers of booked shipped. This is compared to the original order received (by mail or phone) to
ascertain its accuracy. The details of the order are normally available in a special file or data store, called "Bookstore Orders".
It is shown in the second level DFD diagram.
• Following the order verification and credit check, a clerk batches the order by assembling all the book titles ordered by the
bookstore. The batched order is sent to the warehouse with authorization to pack and ship the books to the customer. It is
shown in the third level DFD diagram.
Data Dictionaries

• It’s repository to store information about all data items defined in DFDs.
• At requirement stage, DD should at least define customer data items, to ensure that
customer and developer use same definitions and terminologies.
• Info. Stored include:
1. Name of data item.
2. Aliases(other names for item e.g DR for Deputy Registrar).
3. Description/purpose(textual description of what data item is used for or why it exists)
4. Related data items(capture relationships b/w data items e.g total marks must always
equal to internal marks and external marks)
5. Range of values(total marks must be positive and b/w 0 to 100)
6. Data structure definition/form.
• Data dictionary contains formal definitions of all the data items shown
in the data-flow diagrams.
•  General format of data dictionary is similar to a standard dictionary;
it contains an alphabetically ordered list of entries.
• Each entry consists of a formal definition and verbal description.
• Verbal description is simply a sentence or two in English describing
the data element.
• Formal description provides a more precise definition using a
mathematical sort of notation.
 Mathematical Notations used within DD:

Notation Meaning
1. x=a+b x consist of data elements a and b.
2. x=[a/b] x consist of either data element a or b.
3. x=a x consist of an optional data element a.
4. x=y{a} x consist of y or more occurrences of data element a.
5. x={a}z x consist of z or fewer occurrences of data element a.
6. x=y{a}z x consist of some occurrences of data element a which are b/w y and z.

sequence: + plus sign indicates one element is followed by or concatenated with another element.
repetition:[ ] Square brackets are used to enclose one or more optional elements.
Vertical line | stands for "or" and is used to indicate alternatives.
selection:{} Curly braces indicate that element being defined is made up of a series of repetitions of the element(s)
enclosed in brackets.
• DD can be used to:
1. Create an ordered listing of all data items.
2. Create an ordered listing of subset of data items
3. Find data item name from a description.
4. Design s/w and test cases.
3. ER (Entity relationship) diagram
• Tool for requirement analysis
• It’s detailed logical representation of data for an organization.

Uses 3 main constructs:

1. Data Entities
2. Relationship
3. Their associated attributes
 Entities:

• Entity is fundamental thing of an organization about which data may be maintained.

• It has it’s own identity which distinguishes it from each other entity.
• ENTITY TYPE: description of all entities to which common definition and common relationships
and attributes apply.
Ex: Consider University that offers both regular and distance education programmes, offered to
both national and international students.
• 2 ENTITY TYPE(capital letters and placed inside rectangle) in this example:
PROGRAMME and STUDENT
• REGULAR and DISTANCE EDUCATION are entities of PROGRAMME.
• NATIONAL and INTERNATIONAL are entities of STUDENT.

fig.: 2 entity types in ER diagram

STUDENT PROGRAMME
Relationships
• Associate 2 or more entity types.
• Represented by diamond notation in ER diagram.
• Relationship: registered for
STUDENT Registered PROGRAMME
for
• EX: Teaching deptt. Of University is interested in tracking which
subjects each of its student has completed.

STUDENT Completes SUBJECT

M:M relationships

• Each student may complete more than 1 subject and more than 1
student may complete each subject.
• Degree=2 as there are 2 entity types(STUDENT and SUBJECT)
Degree of relationships:
1. Unary (DEGREE 1)
2. Binary (DEGREE 2)
3. Ternary (DEGREE 3)
Degree: number of entity types that participate in that relationships.
Higher degree relationships: possible but rarely encountered.

PREVIOUS SLIDE:
Degree=2 as there are 2 entity types(STUDENT and SUBJECT)
 Unary Relationship
• Also called recursive relationship
• It’s relationship b/w instances of 1 entity type.
• ex: there is one STUDENT entity type in universities but there may be hundreds of
instances of this entity type in database.
• Is-married-to: 1:1 relationship b/w instances of PERSON entity type
• Means each person is currently married to one other person.

PERSON Is Is
married STUDENT friend
to of

• In 2nd ex: “is-friend-of” is shown as 1:M relationship b/w instances of STUDENT entity type.
Binary Relationship
• Relationship b/w instances of 2 entity types.
• Common type
A. 1:1
B. 1:M
C. M:M
• 1:1: indicate that STUDENT is assigned STUDENT_ID and each
STUDENT_ID is assigned to student.

• 1:M: indicate that PROGRAMME may have many students and each
student belongs to 1 programme.

• M:M: shows that STUDENT may register for more than 1 subject and
each subject may have many student registrants.
Is
STUDENT assigned STUDENT-ID 1:1

PROGRAMME STUDENTS
Registers 1:M

Registers- M:M
SUBJECT
STUDENT for
 Ternary Relationship
• It’s simultaneous relationship amongst instances of 3 entity types.
• Association of 3 entities: TEACHER, STUDENT, SUBJECT
• There may be 1 or many participants in ternary relationship.
• In given ex. All 3 entries are M:M participants.

TEACHER

STUDENT May SUBJECT

have
Attributes
• Each entity set has “set of attributes” associated with it.
• Attribute is property or characteristics of an entity that’s of interest to organization.

Entity type Associated Attribute

Student : S_id, S_name,S_address,S_contact
Employee : E_id, E_name, E_address
Attributes: represented using ellipse, use an initial capital letter followed by lowercase
letters and nouns in naming an attribute.

E_id
Candidate key and identifier
• Candidate key is attribute or combination of attributes that uniquely identifies each
instance of an entity type.
• Ex: 1 candidate key for EMPLOYEE is E_id.
2nd is combination of E_name and E_address.
If there is more than 1 candidate key,designer must choose 1 of candidate keys as identifier.

IDENTIFIER: CANDIDATE KEY that has been selected to be used as unique characteristic
for an entity type.

E_id
 S_address
S_name

STUDENT

S_id S_contact

Fig: representation of STUDENT entity type using ER

Cardinality
• It’s number of instances of entity B that can be associated with each
instance of entity A.
• Ex: STUDENT may register for many subjects(1:M).

STUDENT Registered SUBJECT

for

• Subject may not have any student at specific instance of time.

• We need a more precise notation to indicate “range of cardinalities
for a relationship”
• MINIMUM CARDINALITY: of relationship is minimum number of instances of
entity B that may be associated with each instance of entity A.
• If minimum no. of students available for subject is 0, we say that subject is an
optional participant in “registered for” relationship.
• When minimum cardinality of relationship is 1, then we say that entity B is
mandatory participant in relationship.
• Maximum cardinality: is max. number of instances.
• 0 through line near SUBJECT entity means minimum cardinality of 0
• While “crow’s foot” notation means “many” maximum cardinality.

Completes SUBJECT
STUDENT
Cardinality of relationships:
• Used to identify relationships b/w entity types.
Mandatory 1 cardinality

n Mandatory Many(M) cardinality(1,2….n)

n is number for an upper limit, if one exists.

Optional 0 or 1 cardinality

n Optional zero-many cardinality(0,1,2,……many)

Zero or 1

Strictly 1

1 or many

O or many
 Entity Relationship (ER) model for a college database
 SOFTWARE PROTOTYPING
• Prototyping: technique of constructing partial implementation of system so that customers, users or developers can learn
more about a problem or solution to that problem.
• It allows users to explore, give feedback and criticize proposed system before undergoing the cost of full-scale
development.
2 prototyping technologies:
1. Throw-away
2. Evolutionary
In throw-away approach, prototype s/w is constructed in order to learn about problem or it’s solution and is usually
discarded after desired knowledge is gained and final system is built from scratch.
• Built quickly so as to enable user to rapidly interact with requirements determination early.
• As it’s discarded, it need not to be operating, maintainable.
Common steps:
1. Writing preliminary SRS.
2. Implementing prototype based on those requirements.
3. Achieving user experience with prototype
4. Writing real SRS
5. Developing real product.
• In evolutionary approach, prototype is constructed in order to learn about problem
or it’s solution in successive steps.
• Prototype is built with ideas that it will eventually be converted into final system.
• Once prototype has been used and requisite knowledge is gained, prototype is then
adapted to satisfy, now-better understand needs.
• Prototype is then used again, more is learned and prototype is re-adapted.
• This process repeats indefinitely until prototype satisfies all needs and thus evolve
into real system, final product.
• Here prototype emerges as actual system downstream in s/w life cycle.
• As with each iteration in development, functionality is added and then translated
to an efficient implementation.
• Obtain experience using it,then based on that experience go back and redo
requirements, redesign, recode, retest and redeploy.
• After gaining more experience, it’s time to repeat entire process again.
BENEFITS OF DEVELOPING
PROTOTYPE EARLY IN S/W PROCESS
1. MISUNDERSTANDING b/w s/w developers and customers may be identified.
2. Missing user requirements may be detected.
3. Difficult to use or confusing user requirements may be identified and
refined.
4. Working system is available quickly
5. Prototype serve as basis for writing specifications of system.
Pitfalls:
6. High expectations for productivity with insufficient effort.
7. Large investment
Requirement documentation
• Important activity after requirement elicitation and analysis.
• Way to represent requirements in consistent format.
• SRS: It’s a specification for particular s/w product that performs cerain
functions in specific environment.
• It serves number of purposes depending on who is writing it.
• SRS could be written by customer of system or by developer of system
• SRS: defines needs and expectations of user.
• SRS: Contract document b/w customer and developer.
• This reduces probability of customer being disappointed with final product.
 NATURE OF SRS
• Basic issues that SRS writers shall address are following:
1. Functionality: what s/w is supposed to do?
2. External interface: how does s/w interact with people, system’s h/w, other h/w and other s/w?
3. Performance: What’s speed,availability,response time,recovery time etc of various s/w
functions?
4. Attributes: What are consideration for portability, correctness, maintainability, security,
reliability etc
5. Design constraints imposed on an implementation:
Are there any standards,implementation language, policies for database integrity,resource limits?

• SRS
1. Should correctly define all s/w requirements.
2. Should not describe any design or implementation details.
3. Should not impose additional constraints on s/w.
Characteristics of good SRS
• SRS should be:
1. Correct
2. Unambiguous
3. Complete
4. Consistent
5. Ranked for importance and/or stability
6. Verifiable
7. Modifiable
8. Traceable
1. correct: if every requirement stated therein is one that s/w shall meet. There is no tool/procedure that
assures correctness.

2. Unambiguous: if every requirement(each sentence in SRS) stated therein has only 1(unique)
interpretation.
If given to 10 people: single interpretation
Term used in SRS: if have multiple meaning, glossary should tells it’s meaning.
Use natural language to write SRS, it must be reviewed to identify ambiguous use of langage.

3. Complete: if includes all requirements.

Full labels and references to all figures, table, diagrams in SRS.

4. Consistent: if no requirements described in it conflict.

3 types of conflicts:
A. Specified characteristics of real world objects may conflict
Ex: 1 requirement state that all lights shall be green while another states that all lights will be blue.
B. There may be logical or temporal conflict b/w 2 specified actions.
Ex: 1 requirement state that A must follow B while another says A and B occur simultaneously.
5. Ranked for importance and/or stability
Use some identifier to indicate the importance or stability of particular requirement.
Rank requirements

6. Verifiable:
Means there exists some cost-effective process to check that the s/w meets requirements.
Else such requirements should be removed.
Ex statement: o/p of program shall be produced within 20 seconds of event.

7. Modifiable: if SRS structure and style are such that any changes to requirements can be made easily, completely and
consistently while retaining its structure and style.
Not include redundant requirements: as leads to errors

8. Traceable: if origin of each of requirements is clear and if it facilitates referencing of each requirement in future
development or enhancement documentation.
2 types of traceability:
1. Backward Traceability: each requirement referencing its source in earlier documents.
2. Forward Traceability: each requirement in SRS have unique name and reference number.
FT is important when s/w product enters operation and maintenance phase.
 Specifying behavioral requirements
• Behavioral requirements define the inputs that are expected by the system and the
outputs that will be generated by the system.
• Non Behavioral requirements define the attributes of the system while it performs its job,
like reliability, efficiency and timing constraints.
Finite state machine
• Requirement models are used to clarify and improve requirements consistency, unambiguity,
correctness and completeness.
• FSM model is very popular with requirement engineers and developers.
• FSM also known as Finite State Automation (FSA), are models of behaviors of a system or a complex
object, with a limited number of defined conditions or modes, where mode transitions change with
circumstance.

FSM consist of 4 main elements:

• states which define behavior and may produce actions
• state transitions which are movement from one state to another
• rules or conditions which must be met to allow a state transition
• input events which are either externally or internally generated, which may possibly trigger rules
and lead to state transitions
 FSM

• machine that has a finite number of states.

• Machines can have an infinite number of states. For example, a sensor that
can read the temperature of a process producing an analog voltage is an
example of a machine with an infinite number of states. The number of
possible output voltages is infinite.
• On the other hand, the temperature sensor that only indicates if the
temperature is too high or too low has two output states.
Certain events cause a machine to transfer from one state to another. For example, when the cassette player is rewinding a
tape it will transfer from the "rewind" state to the "stop" state when a sensor indicates that the end of the tape has been
reached.
• FSM must have an initial state which provides a starting point and a current state which remembers product of last state
transition.
• Received input events act as triggers, which cause an evaluation of some kind of the rules that govern the transitions from
current state to other states.
• Best way to visualize a FSM is to think of it as a flow chart or a directed graph of states.
Software Finite State Machines are a simple and elegant solution especially for any piece of software that must deals with
timings and decisions.

Traffic Light 
States: RED, YELLOW, GREEN (simplest example)
Transitions: After a timer change RED to GREEN, GREEN to YELLOW, and YELLOW to RED. 

light system example 

Advantages of FSM
•Their simplicity make it easy for inexperienced developers to implement with little to no extra knowledge (low entry
level).
•Predictability (in deterministic FSM), given a set of inputs and a known current state, the state transition can be
predicted, allowing for easy testing
•Due to their simplicity, FSMs are quick to design, quick to implement and quick in execution
•FSM is an old knowledge representation and system modeling technique, and its been around for a long time, as such it
is well proven.
•FSMs are relatively flexible. There are a number of ways to implement a FSM based system.
•Easy to transfer from a meaningful abstract representation to a coded implementation
•Easy determination of reachability of a state, when represented in an abstract form, it is immediately obvious whether
a state is achievable from another state, and what is required to achieve the state

Disadvantages of FSM
•Predictable nature of deterministic FSMs can be unwanted in some domains such as computer games (solution may be
non-deterministic FSM).
•Larger systems implemented using a FSM can be difficult to manage and maintain without a well thought out design.
•Not suited to all problem domains, should only be used when a systems behavior can be decomposed into separate
states with well defined conditions for state transitions. This means that all states, transitions and conditions need to be
known up front and be well defined
 IT extra topics: not for CSE
• SRD(structured requirement definition): nothing but requirement
engineering
• structured analysis & design techniques( requirement analysis tools)
• Decision tables and trees
• Code object diagram
• PDL
 Structured analysis & design techniques:

• Analysts use various tools to understand and describe the information system. One of the ways is using structured analysis.
• Structured Analysis is a development method that allows the analyst to understand the system and its activities in a logical
way.
• It’s a systematic approach, which uses graphical tools that analyze and refine objectives of an existing system and develop a
new system specification which can be easily understandable by user.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system development:

1. Data Flow Diagrams

2. Data Dictionary
3. Decision Trees
4. Decision Tables
5. Structured English
6. Pseudocode
7. Context diagram
• In software engineering, structured analysis (SA) and its allied technique, structured design (SD), are methods for analyzing
and converting business requirements into specifications and ultimately, computer programs, hardware configurations and
related manual procedures.

• Structured analysis and design techniques are fundamental tools of systems analysis.

• Structured analysis consists of interpreting the system concept (or real world situations) into data and control terminology
represented by data flow diagrams, ER diagrams etc..
• Result of structured analysis is a set of related graphical diagrams, process descriptions, and data definitions.

• Structured design (SD) is concerned with development of modules and synthesis of these modules in a so-called "module
hierarchy".

• In order to design optimal module structure and interfaces two principles are crucial:
• Cohesion which is "concerned with grouping of functionally related processes into a particular module”.
• Measure of how well module fits together.
• Coupling relates to "the flow of information or parameters passed between modules.
• An indication of the strength of interconnections between program units.Highly coupled have program units dependent on
each other. Loosely coupled are made up of units that are independent or almost independent.
 Decision Table
• 2D mapping of conditions against actions
• Conditions evaluate to Boolean
• Actions correspond to expected activity
• Each column in the table corresponds to a test case for functional testing
• Cause-effect graph and decision table are relatives
• Map causes as conditions
• Map effects as actions
• each column of the decision table corresponds to a test case for functional testing.
• Draw causes on the LHS
• Draw effects on the RHS
• Draw logical relationship between causes and effects
• as edges in the graph.
Decision table
• It’s a graphical method for explaining the logic of making decision in tabular format.
• It is a set of conditions + set of actions and different combinations of decisions.
• “It is a matrix representation of logic of decisions which specify possible conditions for decision and resulting actions.”
is a good way to deal with combinations of things (e.g. inputs). Also called ’cause-effect’ table.
Three Parts of a Decision Table:
1. Condition stubs: Lists condition relevant to decision
2. Action stubs: Actions that result from a given set of conditions
3. Rules: Specify which actions are to be followed for a given set of conditions.
Indifferent Condition: Condition whose value does not affect which action is taken for two or more rules
Procedure for Creating Decision Tables
• Name the condition and values each condition can assume
• Name all possible actions that can occur
• List all rules
• Define the actions for each rule
• Simplify the table
• Credit card example:
Let’s take another example. If you are a new customer and you want to open a credit card account then
there are 3 conditions
first you will get a 15% discount on all your purchases today,
second if you are an existing customer and you hold a loyalty card, you get a 10% discount and
third if you have a coupon, you can get 20% off today (but it can’t be used with the ‘new customer’ discount). Discount amounts are added, if
applicable. This is shown in Table 4.8.

TABLE 4.8 Decision table for credit card example

• In Table 4.8, conditions and actions are listed in left hand column. All other columns in decision table each represent a separate rule, one for each
combination of conditions. We may choose to test each rule/combination and if there are only a few this will usually be the case. However, if the
number of rules/combinations is large we are more likely to sample them by selecting a rich subset for testing.
• Now let’s see the decision table for credit card shown above:
• Note that we have put X for the discount for two of columns (Rules 1 and 2) – this means that this combination should not occur. You cannot be
both a new customer and also holding a loyalty card as per conditions mentioned above. Hence there should be an error message stating this.
• We have made an assumption in Rule 3. Since coupon has a greater discount than new customer discount, we assume that customer will choose
20% rather than 15%. We cannot add them, since coupon cannot be used with ‘new customer’ discount as stated in condition above. The 20%
action is an assumption on our part, and we should check that this assumption (and any other assumptions that we make) is correct, by asking
person who wrote specification or users.
• For Rule 5, however, we can add discounts; since both coupon and loyalty card discount should apply (that’s our assumption).
• Rules 4, 6 and 7 have only one type of discount and Rule 8 has no discount, so 0%.
• If we are applying this technique thoroughly, we would have one test for each column or rule of our decision table. The advantage of doing this is
that we may test a combination of things that otherwise we might not have tested and that could find a defect. However, if we have a lot of
combinations, it may not be possible or sensible to test every combination. If we are time-constrained, we may not have time to test all
combinations. Don’t just assume that all combinations need to be tested. It is always better to prioritize and test the most important combinations.
Having the full table helps us to decide which combinations we should test and which not to test this time. In the example above all the conditions
are binary, i.e. they have only two possible values: True or False (or we can say Yes or No).
Advantages of Decision Table
1.    It provides compact representation of decision making process.
2.    It is easier to understand particular path.
3.    It can be changed according to situation.
4.    Best suited for calculating discounts, commissions or inventory control procedures.
5.    Structure of decision table promotes a logically complete and consistent problem definition.

Disadvantages of Decision Table

1.    It cannot express the complete sequence of operations to solve a problem therefore it may be difficult for the programmer to
translate decision table into program.
2.    If there are too many alternatives, it is difficult to list in decision table.
3.    It does not show the flow of logic for the solution to a given problem.
Q:  An insurance company uses the following rule to determine the eligibility of a driver for insurance.
          The driver will be insured if:-
1.    The driver lives in the city with population less than 5000 and he is married man.
2.    The driver lives in the city with population less than 5000 and he is married and age is over 30 years old.
3.    The driver lives in the city with population is 5000 or more and it is married female.
4.    The driver is male over 30.
5.    The driver is married and under 30.
Decision Trees
• A decision tree is a graph that uses a branching method to illustrate
every possible outcome of a decision.
• representing decisions using a series of nodes and branches
• Each node is a decision point - a choice has to be made
• Each branch has a corresponding value to the decision choice
• Subsequent action is the result

113
 Example of Decision Tree
Yes
1 Pay base salary

No Yes
2 Pay hourly wage;
Absence report

No
Yes
Legend: 3 Pay hourly wage
1) Salaried?
2) Hours worked < 40?
No
3) Hours worked > 40? Pay hourly wage;
Pay overtime wage
An email management decision tree might begin with a box labeled “Receive new message.” From that, one branch leading off
might lead to “Requires immediate response.”

From there, a “Yes” box leads to a single decision: “Respond.”

A “No” box leads to “Will take less than three minutes to answer” or “Will take more than three minutes to answer.”
From the first box, a box leads to “Respond” and from the second box, a branch leads to “Mark as task and assign priority.”
The branches might converge after that to “Email responded to? File or delete message.”
Requirements specification using a PDL
To counter the inherent ambiguities in natural language specification, it is possible to describe requirements operationally using a program
description language or PDL.
Requirements may be defined operationally using a language like a programming language but with more flexibility of expression

Using a PDL: best way to provide this information in two situations :

(1) When an operation is specified as a sequence of simpler actions and the order of execution is important.
(2) When hardware and software interfaces have to be specified.

There are disadvantages to this approach to requirements specification:

(2) The language used to write the specification may not be sufficiently expressive to describe application domain concepts in an
understandable way.
(2) The specification will be seen as an abstract design rather than a model to help the user understand the system.
In principle, PDLs may be based on any programming language.
An effective way to use this approach to specification is to combine it with the use of structured natural language.
Three types of interface which may have to be defined:
(3) Procedural interfaces
(2) Data structures
(3) Representations of data
At a more detailed level, it may be necessary to specify precise representation of elements in interface.
ATM Specification: a PDL example

Class ATM {
// declaration here
public static void main (string args[]) InvalidCard {
try {
thisCard.read(); //may throw Invalid card exception
pin = KeyPaD.READpIN(); attempts = 1;
While (!thisCard.pin.equal(pin) & attempts < 4)
pin = KeyPad.readPin(); attempts += 1;
.
.
117
.
 code object diagram
• An object diagram in the Unified Modeling Language (UML), is a diagram that shows a complete or partial
view of the structure of a modeled system at a specific time.
• In the UML, an object diagram focuses on some particular set of objects and attributes and the links between
these instances.
• Object diagrams are derived from class diagrams so object diagrams are dependent upon class diagrams.
• Object diagrams represent an instance of a class diagram.
• The basic concepts are similar for class diagrams and object diagrams. Object diagrams also represent the
static view of a system but this static view is a snapshot of system at a particular moment.
• Object diagrams are used to render a set of objects and their relationships as an instance.
• Also called Instance diagrams. Like class diagrams, they also show the relationship between objects but they
use real world examples.
• They are used to show how a system will look like at a given time. Because there is data available in the
objects, they are often used to explain complex relationships between objects.
Purpose
• The difference is that a class diagram represents an abstract model consisting
of classes and their relationships. But an object diagram represents an
instance at a particular moment which is concrete in nature.
• Object diagram is more close to actual system behavior. Purpose is to capture
the static view of a system at a particular moment and can be summarized as:
• Forward and reverse engineering.
• Object relationships of a system
• Static view of an interaction.
• Understand object behavior and their relationship from practical perspective
Object diagrams : consist of objects.
The link in object diagram is used to connect objects.
Objects and links are the two elements used to construct an object diagram.

Following things are to be decided before starting the construction of diagram:

Object diagram should have a meaningful name to indicate its purpose.

Most important elements are to be identified.
Association among objects should be clarified.
Values of different elements need to be captured to include in object diagram.
Add proper notes at points where more clarity is required.

Following diagram is an example of an object diagram. It represents Order management system.

Following diagram is an instance of system at a particular time of purchase.

It has following objects

Customer
Order
SpecialOrder
NormalOrder
Now the customer object (C) is associated with three order objects (O1, O2 and O3).
These order objects are associated with special order and normal order objects (S1, S2 and N1).

The customer is having the following three orders with different numbers (12, 32 and 40) for the particular time considered.

customer can increase number of orders in future and in that scenario the object diagram will reflect that.

If order, special order and normal order objects are observed then you will find that they are having some values.
For orders the values are 12, 32, and 40 which implies that the objects are having these values for the particular moment (here the particular time
when the purchase is made is considered as the moment) when the instance is captured. Same is for special order and normal order objects
which are having number of orders as 20, 30 and 60. If a different time of purchase is considered then these values will change accordingly.
Where to use Object Diagrams?
Object diagrams can be imagined as snapshot of a running system at a particular moment. Now to clarify it we can take an
example of a running train.
Now if you take a snap of the running train then you will find a static picture of it having the following:
A particular state which is running
A particular number of passengers. which will change if the snap is taken in a different time.
So here we can imagine the snap of the running train is an object having the above values. And this is true for any real life
simple or complex system.

In a brief, object diagrams are used for:

Making the prototype of a system.
Reverse engineering.
Modeling complex data structures.
Understanding the system from practical perspective.
• Thanks