ASHA M TARSADIA INSTITUTE OF COMPUTER SCIENCE & TECNOLOGY

BE 2RD YEAR 3RD SEM

Computer Science & Engineering

Unit 2 Software Modeling

Software Engineering(CE1043)
Outlines

1 Principles of Software Modeling

2 Requirement Engineering

3 Eliciting Requirements

4 Developing Use Cases, SRS

 Core Principles : Process

▪ Principle 1: Be agile.

▪ Whether the process model you choose is prescriptive or agile.

▪ keep your technical approach as simple as possible

▪ keep the work products you produce as concise(short) as possible

▪ Make decisions locally whenever possible.
▪ Principle 2: Focus on quality at every step.

▪ For every process activity, action, and task should focus on the quality of the work
product that has been produced.
▪ Principle 3: Be ready to adapt.
▪ adapt your approach to conditions imposed by the problem, the people, and the
 Core Principles : Process

▪ Principle 5; Establish mechanisms for communication and coordination.

▪ Projects fail because stakeholders fail to coordinate their efforts to create a

successful end product.
▪ Principle 6: Manage change.

▪ The methods must be established to manage the way changes are requested,
approved, and implemented.
▪ Principle 7: Assess risk.

▪ Lots of things can go wrong as software is being developed.

▪ Principle 8: Create work products that provide value for others

▪ Create only those work products that provide value for other process activities,
 Core Principles: Practice
▪ Principle 1: Divide and conquer.

▪ A large problem is easier to solve if it is subdivided into a collection of elements(or

modules or components). Ideally, each element delivers distinct functionality that
can be developed.
▪ Principle 2: Understand the use of abstraction.
▪ At its core, an abstraction(overview) is a simplification of some complex element of
a system used to communicate meaning in a single phrase.
▪ Principle 3: Strive for consistency.
▪ Whether it’s creating a requirements model, developing a software design,
generating source code, or creating test cases. All these are consistent so that the
software is easier to develop.
▪ Principle 4: Focus on the transfer of information.
 Core Principles: Practice

▪ Principle 5: Build software that exhibits effective modularity.

▪ Modularity provides a mechanism for any complex system can be divided into
modules (components).
▪ Principle 6: Look for patterns.
▪ Brad Appleton suggests that: The goal of patterns within the software community is to
create a body of literature to help software developers resolve recurring problems
encountered throughout all of software development process.
▪ Principle 7: When possible, represent the problem and its solution from a number of
different perspectives.
▪ problem and its solution from a number of different perspectives. When a problem
and its solution are examined from a number of different perspectives(ways).
▪ Principle 8: Remember that someone will maintain the software
 Communication Principles
▪ Principle 1: Listen.
▪ Try to focus on the speaker’s(stake holder) words, rather than response to those words.
Ask for clarification if something is unclear, but avoid constant
interruptions(disturbances).
▪ Principle 2: Prepare before you communicate.

▪ Spend the time to understand the problem before meet with others.

▪ Principle 3: Someone should facilitate the activity.

▪ very meeting should have a leader (a facilitator) to keep the conversation moving in a
productive direction. to mediate any conflict(disturbances) that does occur
▪ Principle 4: Face-to-face communication is best.
▪ it usually works better when some other representation of the relevant information is
present. For example, A document having all the details
 Communication Principles
▪ Principle 6: Strive for collaboration.
▪ Each small collaboration serves to build trust among team members and creates a common
goal for the team.
▪ Principle 7: Stay focused; modularize discussion
▪ The more people involved in any communication, the more likely that discussion will
move from one topic to the next. The facilitator should keep the conversation modular,
leaving one topic only after it has been resolved.
▪ Principle 8: If something is unclear, draw a picture.

▪ A sketch or drawing can often provide clarity when words fail to do the job
▪ Principle 9: (a) Once you agree, move on. (b)If you cannot agree, move on. (c) If a feature or
function is unclear and cannot be clarified at the moment, move on.
▪ Principle 10: Negotiation is not a contest or a game. It works best when both parties win.
▪ If the team has collaborated well, all parties have a common goal. Still, negotiation will
 Planning Principles
▪ Principle 1: Understand the scope of the project.

▪ Scope provides the software team with a destination.

▪ Principle 2: Involve stakeholders in the planning activity.
▪ Stakeholders define priorities for which feature to develop first and establish
project constraints(conditions).
▪ Principle 3: Recognize that planning is iterative.

• As work begins, it is very likely that things will change.

• The plan must be adjusted to accommodate these changes.

▪ Principle 4: Estimate based on what you know.

▪ The estimation is to provide an indication of effort, cost, and task duration,

based on the team’s current understanding of the work to be done.
 Planning Principles
▪ Principle 6: Be realistic.
▪ People don’t work 100 percent of every day.

▪ Noise always enters into any human communication.

▪ Change will occur. Even the best software engineers make mistakes.
▪ These should be considered as a project plan is established.
▪ Principle 7: Adjust granularity as you define the plan.
▪ Granularity refers to the level of detail that is introduced as a project plan is
developed.
▪ Principle 8: Define how you intend to ensure quality.

▪ The plan should identify how the software team intends to ensure quality.
▪ Principle 9: Describe how you intend to accommodate change.
▪ Even the best planning can be obviated by uncontrolled change. You should identify
how changes are to be accommodated as software engineering work proceeds.
 Modeling Principles
Create models to gain a better understanding of the actual entity to be built. The modeling principles are:

▪ Principle 1: The primary goal of the software team is to build software, not create
models.
▪ Agility means getting software to the customer in the fastest possible time.
▪ Principle 2: Travel light –don’t create more models than you need.
▪ Every model that is created must be kept up-to-date as changes occur.
▪ Create only those models that make it easier and faster to construct the
software.
▪ Principle 3: Strive to produce the simplest model that will describe the problem of
the software.
▪ software that is easier to integrate, easier to test, and easier to maintain.
 Modeling Principles(Cont..)
▪ Principle 5: Be able to state an explicit purpose for each model that is created.
▪ Every time you create a model, ask yourself why you’re doing so. If you can’t provide
solid justification for the existence of the model, don’t spend time on it.
▪ Principle 6: Adapt the models you develop to the system at hand.

▪ It may be necessary to adapt model notation.

▪ Principle 7: Try to build useful models, but forget about building perfect models.
▪ When building requirements and design models, that the models should be complete
and consistent .
▪ Principle 8: Don’t become dogmatic about the syntax of the model. If it communicates
content successfully, representation is secondary.
▪ Although everyone on a software team should try to use consistent notation during
modeling.
▪ Principle 9: If your instincts tell you a model isn’t right even though it seems OK on paper,
 Modeling Principles(Cont..)

❑ Principle 10. Get feedback as soon as you can.

❑ Every model should be reviewed by members of the software team.
❑ These reviews is to provide feedback that can be used to correct modeling
mistakes.
 Modeling Principles: Requirements
▪ Principle 1: The information domain of a problem must be presented and
understood.
▪ The information domain encompasses the data that flow into the system, the
data that flow out of the system, and the data stores that collect and organize
persistent data objects
▪ Principle 2: The functions that the software performs must be defined.

▪ Software functions provide direct benefit to end users

▪ Principle 3: The behavior of the software must be represented.

▪ The behavior of computer software is driven by its interaction with the

external environment.
▪ Principle 4: The models that depict information, function, and behavior must be
partitioned in a manner that uncovers detail in a layered fashion.
 Modeling Principles: Design
▪ Principle 1: Design should be traceable to the requirements model.
▪ The requirements model describes the information domain of the problem,user-visible
functions, system behavior.
▪ The design model translates this information into an architecture.(diagrams)
▪ The elements of the design model should be traceable to the requirements model.
▪ Principle 2: Always consider the architecture of the system to be built.

▪ Software architecture is the skeleton of the system to be built. It affects interfaces, data
structures, program control flow and behavior.
▪ Principle 3: Design of data is as important as design of processing.
▪ Data design is an essential element of architectural design. A well-structured data design
helps to simplify program flow, makes the design and implementation of software
components easier.
 Modeling Principles: Design
▪ Principle 5: User interface design should be tuned to the needs of the end user. However, in every case,
it should stress ease of use.
▪ The user interface is the visible manifestation of the software.

▪ Principle 6: Component-level design should be functionally independent.

▪ Functional independence is a measure of the “single-mindedness” of a software component. The
functionality that is delivered by a component should be cohesive—that is, it should focus on one
and only one function .
▪ Principle 7: Components should be loosely coupled to one another and to the external environment.

▪ Coupling is achieved in many ways— via a component interface, by messaging, through global
data. As the level of coupling increases, the likelihood of error propagation also increases .
▪ Principle 8: Design representations should be easily understandable.

▪ The purpose of design is to communicate information to practitioners(software

developers,testers,maintainers).
▪ Principle 9: The design should be developed iteratively. With each iteration, the design should strive
 Coding Principles: Preparation

▪ Principle 1: Understand the problem you’re trying to solve

▪ Understand the problem you’re trying to solve.

▪ Understand basic design principles and concepts.

▪ Principle 3: Pick a programming language that meets the needs of the software to be
built and the environment in which it will operate
▪ Principle 4: Select a programming environment that provides tools that will make your
work easier
▪ Principle 5: Create a set of unit tests that will be applied once the component you code
is completed
 Coding Principles: Programming

▪ Principle 1: Constrain you algorithms by following structured programming practice

▪ Principle 2: Consider the use of pair programming

▪ Pair programming involves two developers working together at one workstation.
One writes the code (the "driver"), while the other reviews each line of code as it's
written (the "navigator"). This technique improves code quality and helps catch
errors early in the development process.
▪ Principle 3: Select data structures that will meet the needs of the design

▪ Principle 4: Understand the software architecture and create interfaces consistent with it
▪ Principle 5: Keep conditional logic as simple as possible
▪ Principle 6: Create nested loops in a way that makes them easily testable

▪ Principle 7: Follow coding standards

 Coding Principles: Validation

▪ Principle 1: Conduct a code walkthrough when appropriate

▪ Principle 2: Perform unit tests and correct errors you’ve
discovered
▪ Principle 3: Refactor the code
 Testing Principles

▪ Principle 1: All tests should be traceable to customer requirements.

▪ The objective of software testing is to uncover errors

▪ Principle 2: Tests should be planned long before testing begins.

▪ Test planning can begin as soon as the requirements model is complete.

Therefore, all tests can be planned and designed before any code has been
generated.
▪ Principle 3: The Pareto principle applies to software testing.

▪ In this context the Pareto principle implies that 80 percent of all errors uncovered
during testing will likely be traceable to 20 percent of all program components.
▪ Principle 4: Testing should begin “in the small” and progress toward testing “in the
large”
 Deployment Principles
▪ Principle 1: Customer expectations for the software must be managed.
▪ the customer expects more than the team has promised to deliver, and disappointment occurs
immediately.
▪ Principle 2: A complete delivery package should be assembled and tested.
▪ A CD-ROM or other media (including Web-based downloads) containing all executable
software, support data files, support documents, and other relevant information should be
assembled and thoroughly beta-tested with actual users.
▪ Principle 3: A support regime must be established before the software is delivered.

▪ An end user expects responsiveness and accurate information when a question or problem
arises.
▪ Principle 4: Appropriate instructional materials must be provided to the user.

▪ The software team delivers more than the software itself. Appropriate training aids (if
required) should be developed and troubleshooting guidelines should be provided.
 Requirement Engineering
It provides the appropriate mechanism for understanding

What customer wants Managing requirements

Analyzing needs Assessing feasibility Validating the specification
Negotiating a reasonable solution Specifying solution unambiguously

Requirements fall into two types

Functional requirements Non-Functional requirements

 FUNCTIONAL NON-FUNCTIONAL
REQUIREMENTS REQUIREMENTS

Any requirement which specifies what Any requirement which specifies how
the system Should do. the system performs a certain
function.

Typical functional requirements Typical non-functional requirements

Administrative functions Legal or Regulatory Response time Availability Regulatory
Authentication Requirements Throughput Reliability Manageability
Transaction corrections, Business Rules Utilization Recoverability Environmental
adjustments and Maintainability Data Integrity
Historical Data Static
cancellations volumetric Serviceability
Reporting Requirements Authorization levels Usability
Scalability Security
Interoperability
External Interfaces Audit Tracking Capacity
Difference
 LIBRARY MANAGEMENT SYSTEM
Function Requirements Non-function Requirements

1. Add Article: 1. Safety Requirements:

2. Update Article: 2. Security Requirements:
3. Delete Article: 3. Software Constraints:
4. Inquiry Members:
5. Inquiry Issuance:
6. Check out Article:
7. Check In article:
8. Inquiry waiting for
approvals:
9. Reserve Article:
 LIBRARY MANAGEMENT SYSTEM
Function Requirements

•Add Article: The system should allow users to add new articles or books to the library database.
•Update Article: The system should enable users to update the details of existing articles or books.
•Delete Article: The system should provide the functionality to remove articles or books from the
library database.
•Inquiry Members: The system should allow for querying or viewing information about library
members.
•Inquiry Issuance: The system should enable users to inquire about the issuance of articles, such
as which articles have been issued and to whom.
•Check out Article: The system should handle the process of checking out articles, allowing
members to borrow them.
•Check In Article: The system should facilitate the return of borrowed articles, updating their
status in the database.
•Inquiry Waiting for Approvals: The system should allow users to inquire about any pending
approvals related to article requests or other operations.
•Reserve Article: The system should enable users to reserve articles, ensuring that they can
borrow them when available.
 LIBRARY MANAGEMENT SYSTEM
Non-function Requirements

•Safety Requirements: These refer to the measures that ensure the system operates safely
without causing harm to users or data. This could involve data protection and handling
errors effectively.
•Security Requirements: These involve ensuring that the system is secure from
unauthorized access or attacks, protecting sensitive information like user data and
transaction records.
•Software Constraints: These refer to any limitations or constraints related to the software,
such as compatibility with certain hardware, software performance benchmarks, or any
other limitations imposed by the software's design or environment.
 Requirements Engineering Task

• The tasks and techniques that lead to an understanding of requirements is

called requirements engineering.
• Requirements engineering is a major software engineering action that begins
during the communication activity and continues into the modeling activity.
• Requirements engineering builds a bridge to design and construction.
• Requirements engineering provides the appropriate mechanism for
understanding what the customer wants, analyzing needs, assessing
feasibility, validating the specification and managing the requirements, and
transforming into an operational system.
• It encompasses seven distinct tasks: inception, elicitation, elaboration,
negotiation, specification, validation, and management.
 REQUIREMENTS ENGINEERING TASKS

1 Inception 2 Elicitation 3 Elaboration

Roughly define Further define requirements

scope
Define requirements
Expand and refine
requirements obtained from
inception & elicitation
 Inception, Elicitation
• At inception, establish a basic understanding of the problem, the people who want a
solution, the nature of the solution that is desired, and the effectiveness of preliminary
communication and collaboration between the other stakeholders and the software team.
• Elicitation:
• Ask the customer, the users, and others what the objectives for the system or product
are, how the system or product is to be used on a day-to-day basis.
• A number of problems that are encountered as elicitation occurs.
• Problems of scope. The customers/users specify unnecessary technical details
that may confuse, rather than clarify, overall system objectives.
• Problems of understanding. The customers/users are not completely sure of
what is needed, have a poor understanding of the capabilities and limitations of
their computing environment, don’t have a full understanding of the problem
domain.
• Problems of volatility. The requirements change over time. To help overcome
these problems, requirements gathering in an organized manner
 Elaboration:
• The information obtained from the customer during inception and elicitation is expanded
and refined during elaboration.
• Elaboration is driven by the creation and refinement of user scenarios that describe how
the end user will interact with the system.
• Each user scenario is parsed to extract analysis classes.
• The attributes of each analysis class are defined, and the services that are required by
each class are identified.
• The relationships and collaboration between classes are identified, and a variety of
supplementary diagrams are produced.
 REQUIREMENTS ENGINEERING TASKS
4 Negotiation 5 Specification

It may be written document, set of graphical models,

formal mathematical model, collection of user scenarios,
Agree on a deliverable prototype or collection of these
system that is realistic
for developers and SRS (Software Requirement Specification) is a
customers document that is created when a detailed description of
all aspects of software to build must be specified before
starting of project
 Negotiation:
• It’s relatively common for different customers or users to propose conflicting
requirements.
• reconcile these conflicts through a process of negotiation.
• Customers, other stakeholders are asked to rank requirements and then discuss
conflicts in priority.
• Using an iterative approach that prioritizes requirements, assesses their cost and risk,
and addresses internal conflicts, requirements are eliminated, combined, and/or
modified so that each party achieves some measure of satisfaction.
 Specification:
• A specification can be a written document, a set of graphical models, a formal
mathematical model, a collection of usage scenarios, a prototype, or any combination of
these.
• A “standard template” should be developed and used for a specification.
 REQUIREMENTS ENGINEERING TASKS
6 Validation 7 Requirements Management

It is a set of activities to identify, control

Review the requirements specification
& trace requirements & changes to
for errors, ambiguities, omissions
requirements (Umbrella Activities) at
(absence) and conflicts
any time as the project proceeds.
 Validation, Requirements management
Validation:
• The work products produced during of requirements engineering are assessed for
quality during a validation step.
• Requirements validation examines the specification, all software requirements have
been stated unambiguously, inconsistencies, and errors have been detected and
corrected and that the work products conform to the standards established for the
process, the project, and the product.
• The primary requirements validation mechanism is the technical review
• Requirements management
• Requirements for computer-based systems change, and the desire to change
requirements persists throughout the life of the system.
• Requirements management is a set of activities that help the project team identify,
control, and track requirements and changes to requirements at any time as the project
proceeds.
 ELICITATION INCEPTION
1. Problems of scope 1. Identify the project stakeholders
✔ System boundaries are
ill-define 2. Recognize multiple viewpoints
2. Problems of understanding
✔ Customers never know 3. Work toward collaboration
exactly what they want
✔ Customers have trouble fully 4. Ask the first questions
communicating needs
3. Problems of volatility
✔ Requirements always change
 COLLABORATIVE ELICITATION WORK PRODUCTS
ELICITATION
Collaborative elicitation should result in several work
products

A list of stakeholders

A description of the technical environment

A list of requirements and constraints

Any prototypes developed

A set of use cases

One-on-one Q&A sessions
rarely succeed in practice;
collaborative strategies are
more practical
 DOMAIN ANALYSIS

“How are analysis patterns and classes recognized in the first place? “
“Who defines them, categorizes them, and readies them for use on
subsequent projects? “
The answers to these questions lie in domain analysis
The goal of domain analysis is straightforward: to find or create those
analysis classes and/or analysis patterns that are broadly applicable so that
they may be reused.
Software domain analysis is the identification, analysis, and specification of
common requirements from a specific application domain, typically for
reuse on multiple projects within that application domain
The role of the domain analyst is to discover and define analysis patterns,
analysis classes, and related information that may be used by many people
working on similar but not necessarily the same applications
INPUT OUTPUT FOR DOMAIN ANALYSIS
 QUALITY FUNCTION DEPLOYMENT (QFD)

This is a technique that translates the needs of the customer into technical
requirements for software

It identifies three types of requirements

1. Normal requirements

2. Expected requirements

3. Exciting requirements
 THE REQUIREMENT ANALYSIS MODEL

Describe what the customer wants built System Information

Purpose

Establish the foundation for the software design System Function

Provide a set of validation requirements System Behaviors
 ANALYSIS ELEMENTS OF THE
RULE OF THUMB REQUIREMENTS MODEL
Make sure all points of view are
covered
Every element should add value Scenario-based Class Models
Maintain a high level of Models e.g.
abstraction e.g. Class diagrams
Use cases Collaboration
Focus on the problem domain
User Stories diagrams
Minimize system coupling
Model should provides value to Software
all stakeholders Requirements
Behavioral
Models Flow Models
e.g. e.g.
State diagrams DFDs
Sequence diagrams Data models
 ELEMENTS OF THE REQUIREMENTS MODEL

Scenario-based elements Behavioral elements

Describe the system from the user's Use state diagrams to represent the
point of view state of the system,

Class-based elements Flow-oriented elements

Identify the domain classes for Use data flow diagrams to show the
the objects input data that comes into a system

Use Case Activity Class

Diagram
Diagram
Diagram Diagram Diagram

State
Flow
Data
 ANALYSIS MODELING APPROACHES

Structured Analysis Object Oriented Analysis

• Models data elements • Models analysis classes
⁻ Attributes ⁻ Data
⁻ Relationships ⁻ Processes
• Models processes that • Models class
transform data collaborations

Techniques from both approaches are typically used in practice.

 USE CASE DIAGRAM

A use case diagram is a representation of a user's interaction with the

system.
This interaction shows the relationship between the user and the different
use cases in which the user is involved.

The purpose of the use case diagrams is simply to provide a high-level

view of the system and convey the requirements in layman's terms for the
stakeholders.
 COMPONENTS OF USE CASE DIAGRAM

System boundary Use case

Represent the scope of the system
Use A use case represents a
Use cases of the system are placed user goal / piece of
inside the system boundary Case
functionality that can be
s achieved by accessing the
Actors who interact with the system
are placed outside the system system or software
application.

Actor
Association
An actor is an entity that interacts
directly with the system but that is An actor and use case
not part of system can be associated to
indicate that the actor
Actor may be people, computer participates in that use
hardware, other systems, etc. case
 •Primary Actor: The main entity that initiates the use case to achieve a specific goal.
•Secondary Actor: An entity that supports the primary actor or the system in achieving
the goal of the use case but doesn't directly initiate it.
Example: Online Shopping System
Use Case: Place Order
•Primary Actor: Customer
• Description: The customer wants to purchase products from an online store
•Secondary Actor: Payment Gateway
• Description: The payment gateway handles the transaction processing when
the customer makes a payment.
Use Case Flow:
1.Customer (Primary Actor) selects products and proceeds to checkout.
2.The system displays the order summary and requests payment.
3.Customer (Primary Actor) enters payment details.
4.Payment Gateway (Secondary Actor) processes the payment and confirms the
transaction.
5.The system confirms the order and updates the inventory.
CONT.

Generalization Extends

A generalization relationship is The extend relationship

used to represent the inheritance specifies that the incorporation
relationship between model of the extension use case is
dependent on what happens
elements of the same type when the base use case
executes.

Include Constraint
An include relationship is a Show condition exists
relationship in which one use
case includes the functionality of between actors and activity
another use case
The include relationship supports
the reuse of functionality in a
use-case model.
 EXAMPLE OF EXTENDS AND INCLUDE
Includes

Login In e-commerce application that provides customers with the

<<include>>
option of checking the status of their orders. For checking the
status of their order user should be login.
CheckOrder
Status
This behavior is modeled with a base use case called
CheckOrderStatus that has an inclusion use case called LogIn.
Extends
pay for
item In e-commerce site, When paying for an item,
<<extend>> <<extend>> you may choose to pay on delivery, pay using
pay by pay on
PayPal, or pay by card.
card delivery These are all alternatives to the "pay for item"
use case. I may choose any of these options
depending on my preference.
GUIDELINE FOR CONSTRUCTING USE CASE DIAGRAM

Determine the system boundary.

Ensure that actors are focused, each actor should have a single, coherent
purpose. If a real world object contains multiple purpose, capture them with
separate actors

Each use case must provide value of users

Relate use cases and actors

LIBRARY MANAGEMENT SYSTEM(LMS) FORMAL
REQUIREMENT

A Library Management System is a software built to handle the

primary housekeeping functions of a library.

In library management systems to manage asset collections as well as

relationships with their members.

Library management systems help libraries keep track of the books and
their checkouts, as well as members’ subscriptions and profiles.

Library management systems also involve maintaining the database for

entering new articles and recording articles that have been borrowed
with their respective due dates.
 IDENTIFY THE FUNCTIONALITY & STAKEHOLDERS
FOR LMS
Stakeholders
Functionality

• Register User
• Add Article
Reserve Article Librarian
• Update Article
Set user Member
Permission
• Delete Article
Search Article
Guest
• Inquiry Members
Check Account
• Inquiry Issuance
Prepare Library
• Check out Article Database
• Check in Article
USE CASE DIAGRAM LIBRARY MANAGEMENT
Library Management System
1. Login
10. Request
registration
2. Register user

.3. Manage
member
permission Guest

4. Add Article
11. Check
account

5. Delete Article
13.Search by
title

6. Inquiry article <<extend>

> Memb
er
7. Inquiry member 12. Search
article
Librari
an 8. Check in
<<extend
articles
>>
14 Search by
9. Check out articles publication
 RELATIONSHIP BETWEEN FUNCTIONALITY &
STAKEHOLDERS

Request for registration

Register user
Add Article
Guest
Update Article
Delete Article
Reserve Article
Inquiry Members
Librarian
Search Article
Inquiry Issuance
Check Account
Check out Article Member
Check in Article
Set user Permission
 USE CASES & USAGE SCENARIOS

A collection of user scenarios that describe the thread of usage of a system

Each scenario is described from the point-of-view of an “actor”
An actor is a person or device that interacts with the software

Each scenario answers the following questions

Who is the primary actor, the secondary actor (s)? What are the actor’s goals?

What preconditions should exist before the story begins?

What main tasks or functions are performed by the actor?

What extensions might be considered as the story is described?

What variations in the actor’s interaction are possible?

 CONT.

What information does the actor desire from the system?

What system information will the actor acquire, produce, or change?

Will the actor have to inform the system about changes in the external
environment?

Does the actor wish to be informed about unexpected changes?

SRS (Software Requirements Specification)
Software Requirement Specification (SRS) is a document that completely
describes what the proposed software should do without describing how
software will do it.

SRS Contains

A complete information description A detailed functional description

A representation of system behaviour Appropriate validation criteria

An indication of performance Other information suitable to

requirements and design constraints requirements
 Characteristics of a Good SRS
SRS should be accurate, complete, efficient, and of high quality,

An SRS is said to be of high quality

Characteristics of a Good SRS:

Correct Unambiguous Complete

SRS is correct SRS is SRS is complete

when all user unambiguous when the
requirements are when every stated requirements
stated in the requirement has clearly define what
requirements only one the software is
document. interpretation. required to do.
 Characteristics of a Good SRS
Ranked for Importance/Stability Modifiable

All requirements are not equally changes can be

important, hence each requirement is
identified to make differences among modified easily.
other requirements.

Traceable Verifiable Consistent

SRS is traceable SRS is verifiable when the SRS is consistent when

when the source specified requirements can the subsets of
of each be verified with a individual
requirement is cost-effective process to requirements defined
clear check whether the final do not conflict with
software meets those each other.
requirements.
 Problems Without SRS

▪ The system would not be properly implemented

▪ What exactly is required by the customer
▪ Very difficult for the maintenance engineers to understand the

functionality of the system

▪ Very difficult for user document writers to write the users’

manuals properly
 Standard Template for writing SRS

▪ 1. Introduction ▪ 2. Overall Description

✔ 1.1 Purpose ✔ 2.1 Product Perspective

✔ 1.2 Document Conventions ✔ 2.2 Product Features

✔ 1.3 Intended Audience and ✔ 2.3 User Classes and Characteristics

Reading Suggestions
✔ 2.4 Operating Environment
✔ 1.4 Project Scope
✔ 2.5 Design and Implementation Constraints
✔ 1.5 References
 Standard Template for writing SRS

▪ 3. System Features ▪ 5. Other Nonfunctional Requirements

✔ 3.1 System Feature 1 ✔ 5.1 Performance Requirements

✔ 3.2 System Feature 2 (and so on) ✔ 5.2 Safety Requirements

▪ 4. External Interface Requirements ✔ 5.3 Security Requirements

✔ 4.1 User Interfaces ✔ 5.4 Software Quality Attributes

✔ 4.2 Hardware Interfaces

Thank you