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.
 Requirement Engineering
• It produces 1 large document, written in natural language.
• Contains description of what system will do without describing “How it will do?”.
• It may give an overview of existing system along with broad expectations from new
system.
• 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 requirements.
• Here requirements are identified with 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.

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 od requirements engineering

Requirements
2 cases:
1. SRS(System requirement specification)
If it describes both H/W and S/W
2. SRS(Software requirement specification)
If it describes only S/W
SRS treat system as black box.
It must delineate inputs, outputs, functional requirements and non-
functional requirements .
SRS: contract b/w developer and customer.
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.
 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.
Non-functional requirements: quality requirements, include specifications of desired
performance,availability,reliability, usability and flexibility for user.
Non-functional requirements for developer: maintainability, portability and testability.
• Example
• 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.

• Prepare problem statement for student examination 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.
• 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.
• Every idea is well-documented, written in simple English.
• Finally a document will be prepared which will have list of requirements and their
priority, if possible.
3. FAST (Facilitated Application Specification Technique)
• This 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.
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.
4. QFD (Quality function deployment)
Its quality management technique that helps to incorporate voice of customer.
QFD has foll. 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.
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
Stakeholders will have their own unique set of criteria for determining the “value” of a requirement.
3 types of requirements are identified:
1. Normal requirements
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 )

Requirement engineers may review final list of requirements and categories like:
a. it’s possible to achieve.
b. It should be deferred and reason thereof.
c. It’s impossible and should be dropped from consideration.
If time and effort permits, second category requirements may be reviewed and few
of them may be transferred to category first for implementation.
 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.
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
 Use case diagram
• 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.
• 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
 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
(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.
Modelling :Requirement Analysis
1. DFD(Data Flow Diagrams)
DFDs describe the 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.
• Dfds show flow of data through system.
• System may be company, an organization, set of procedures, computer h/w system and
s/w system.
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.
DFD) is a tool that depicts the flow of data through a system and the work or processing performed by
that system.
Process: Work or actions performed on data so that they are transformed, stored or distributed. A
process transforms incoming data flow into outgoing data flow.
eg:
• Update
• Calculate
• Verify

Data store: Data at rest, repositories of data in the system.

Eg,
– Database
– Files
– Folder
 Source/sink
• The origin and/or destination of data, sometimes referred to as external entities
• Eg,
– Clients
– Employees
– Bank
 Data flow
• Data in motion, moving from one place in the system to another
• Eg,
– Invoice
– Receipt
– Enrolment form
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 shows process that transform data inputs into data outputs.
5. Curved lines show data flow into or out of process or data store.
6. Set of parallel lines shows place for collection of data items.
7. Data Store: indicate data is stored which can be used at later stage or by other processes in
different order.
8. Source or sink is an external entity and acts as source of system inputs or sink of system
outputs.
 DFD Levelling
• Dfd is used to 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.
EX:
Data Dictionaries

• Repositories to store information about all data items defined in DFDs.

• At requirement stage, DD should atleast 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 flow captures names of processes that generate or receive data items.
 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
between y and z.
• 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

fo

• 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:
1. High expectations for productivity with insufficient effort.
2. 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.
C. 2 or more requirements may describe same object but use different terms for that object.
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 of the system are described using use case view.
• Behavioral requirements include any and all information necessary to
determine if run-time behavior.
• It define all constraints on system outputs(ex: value,accuracy,timing) and
resulting system state for all possible inputs and current state system.
• Security, safely, performance, timing and fault-tolerance are all behavioral
requirements.
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

• Finite state machine is 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 communication software but also 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(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 is a systematic approach, which uses graphical tools that analyze and refine the 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
• 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 analysis & design techniques:
• Context diagram
• Data flow diagram
• Data dictionary
• ER diagrams

• 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",and
• Coupling relates to "the flow of information or parameters passed between modules.
 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

105
 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:

(1) 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:
(1) 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;
.
.
. 109
 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