Why Study Software Engineering?

• Many projects have failed because

– they started to develop without adequately
determining whether they are building what the
customer really wanted.
• Customer Requirement
Typical project scenario…
 Requirements
• A Requirement is a capability or condition required
from the system.
• What is involved in RAS?
– Determine what is expected by the client from the
system. (Gather and Analyze)
– Document those in a form that is clear to the client
as well as to the development team members.
(Document)
 Activities in RAS
Requirements Gathering

Requirements Analysis

Requirements Specification

SRS Document
 Requirements engineering
• The process of establishing the services that
– the customer requires from a system and
– the constraints under which it operates and is
developed.
• The requirements themselves are the descriptions of
– the system services and
– constraints that are generated during the
requirements engineering process.
 Requirements Analysis and
Specification
 Requirements Gathering:
 Fully understand the user requirements.
 Requirements Analysis:
 Remove inconsistencies, anomalies, etc. from
requirements.
 Requirements Specification:
 Document requirements properly in an SRS document.
 Need for SRS…
• Good SRS reduces development cost
– Req. errors are expensive to fix later
– Req. changes cost a lot (typically 40% changes)
– Good SRS can minimize changes and errors
– Substantial savings --- effort spent during req. saves
multiple times that effort
• An Example:
– Cost of fixing errors in req., design, coding,
acceptance testing and operation are 2, 5, 15, 50,
150 person-months
 Uses of SRS Document
• Establishes the basis for agreement between the
customers and the suppliers
• Forms the starting point for development.
• Provide a basis for estimating costs and schedules.
• Provide a baseline for validation and verification.
• Facilitates transfer.
• Serves as a basis for enhancement.
• The SRS can serve as the basis for writing User Manual for
the software:
– User Manual: Describes the functionality from the
perspective of a user --- An important document for
users.
– Typically also describes how to carry out the required
tasks with examples.
 SRS Document: Stakeholders
• SRS intended for a diverse audience:
– Customers and users for validation, contract, ...
– Systems (requirements) analysts
– Developers, programmers to implement the system
– Testers to check that the requirements have been
met
– Project Managers to measure and control the
project
• Different levels of detail and formality is needed for
each audience
• Different templates for requirements specifications:
– Often variations of IEEE 830
 Types of Requirements
• Functional requirements
– Statements of services the system should provide,
how the system should react to particular inputs and
how the system should behave in particular
situations.
– May state what the system should not do.
• Non-functional requirements
– Constraints on the services or functions offered by
the system such as timing constraints, constraints on
the development process, standards, etc.
– Often apply to the system as a whole rather than
individual features or services.
 Functional Requirements
• Descriptions of data to be entered into the system
• Descriptions of operations performed by each screen
• Descriptions of work-flows performed by the system
• Descriptions of system reports or other outputs
• Who can enter the data into the system?
• How the system meets applicable regulatory
requirements
 Functional Requirements contd.
• The functional requirements discusses the
functionalities required from the system.
• The system is considered to perform a set of high-
level functions {fi }
• Each function f i of the system can be considered as a
transformation of a set of input data (Ii) to the
corresponding set of output data (Oi)
• The user can get some meaningful piece of work done
using a high-level function.

fi
I1 O1
Input Output
Data I2 O2
Data
I3 O3
 Requirements Engineering

• The process of eliciting, analyzing,

documenting, and validating the services
required of a system and the constraints
under which it will be developed and
operated.
• Descriptions of these services and
constraints are the requirements for the
system.
• Requirements may be high-level and
abstract, or detailed and mathematical. (or
somewhere in between)
 Requirements Engineering

The hardest single part of building a

software system is deciding precisely
what to build. No other part of the
conceptual work is as difficult… No
other part of the work so cripples the
resulting system if done wrong. No
other part is more difficult to rectify later.
– Fred Brooks, “No Silver Bullet…”
 RE Includes
• Discovery/Identification.
• Refinement/Analysis: Identify inconsistencies,
omissions, defects etc.
• Modeling: Functional (DFD), Behavioral (STD),
Informational (DD), Other.
• Specifications (SRS Document).
• Without well documented SRS
– Developers do not know what to build.
– Customers do not know what to expect.
– No way to validate whether build system
satisfies the requirements.
 Requirements Engineering
Process

Feasibility Requirements
study elicitation and
analysis
Requirements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document
 SRS must delineate
• Inputs.
• Outputs.
• Functional Requirements.
• Non-functional Requirements.
• SRS should be/have
– Internally consistent.
– Consistent with existing documents.
– Correct & complete w.r.t. satisfying customer needs.
– Understandable to the users, customers, designers,
& testers.
– Capable of serving as a base for design & test.
 Requirements Analysis
• Software engineering task that bridges the gap
between system requirements engineering and
software design.
• Provides software designer with a model of
– system information
– function
– behavior
• Model can be translated to data, architectural,
and component-level designs.
• Expect to do a little bit of design during analysis
and a little bit of analysis during design.
Software Requirements Analysis
Phases
• Problem recognition.
• Evaluation and synthesis: focus is on
what not how.
• Modeling.
• Specification.
• Review.
 Feasibility Study

• Economic feasibility
– cost/benefit analysis
• Technical feasibility
– hardware/software/people, etc.
• Legal feasibility
• Alternatives
– there is always more than one way to do it.
 Requirements
• Requirements
– features of system or system functions
used to fulfill system purpose.
• Focus on customer’s needs and
problem, not on solutions.
– Requirements definition document .
(written for customer).
– Requirements specification document.
(written for programmer; technical staff).
 Types of Requirements
• Functional requirements:
– input/output
– processing.
– error handling.
• Non-functional requirements:
– Physical environment (equipment locations, multiple sites, etc.).
– Interfaces (data medium etc.).
– User & human factors (who are the users, their skill level etc.).
– Performance (how well is system functioning).
– Documentation.
– Data (qualitative stuff).
– Resources (finding, physical space).
– Security (backup, firewall).
– Quality assurance (max. down time, MTBF, etc.).
 Requirement Validation

• Correct?
• Consistent?
• Complete?
• Each requirement describes something
actually needed by the customer.
• Requirements are verifiable (testable) ?
• Requirements are traceable.
 Requirements Definition Document
• General purpose of document.
• System background and objectives.
• Description of approach.
• Detailed characteristics of proposed
system (data & functionality).
• Description of operating environment.
 Software Requirement Elicitation
• Most difficult, critical, error-prone, and communication
intensive aspect of s/w development.
• Requirements actually reside in the minds of the users.
• Developers and users have different mind set, expertise,
and vocabularies.
• Communication gap between customers and developers
may lead to inconsistencies, misunderstanding and
omissions of requirements.
• Customers have solid background in their domain but
have a little knowledge of s/w development process.
• Developers have experience of developing s/w but have
little knowledge of everyday environment of the customer.
 Software Requirements Elicitation
Techniques
• Customer meetings are the most commonly used
technique.
• Meetings/Interviews may be open ended or
structured.
• Use context free questions to find out
– customer's goals and benefits
– identify stakeholders
– gain understanding of problem
– determine customer reactions to proposed
solutions
– assess meeting effectiveness
• Interview cross section of users when many users
are anticipated.
Interviews
Brainstorming
 F.A.S.T. - 1
• Facilitated application specification
technique
• Meeting between customers and
developers at a neutral site (no home
advantage).
• Goals
– identify the problem
– propose elements of solution
– negotiate different approaches
– specify preliminary set of requirements
 F.A.S.T. - 2

• Rules for participation and preparation

established ahead of time.
• Agenda suggested
– brainstorming encouraged
• Facilitator appointed.
• Definition mechanism
– sheets, flipcharts, wallboards, stickers, etc.
 F.A.S.T.-3
• Each FAST attendee is asked to prepare a list
of objects that are part of environment that
surrounds the system, produced by the system,
used by the system.
• Every attendee is asked to make a list of
services (processes or functions that
manipulate or interact with the objects) and a list
of constraints (cost, size) & performance
criteria (speed, accuracy, response etc.)
 F.A.S.T.- 4
• Each attendee presents the list of objects,
services, constraints & performance.
• Prepare the common list.
• Discuss the common list & prepare a consensus
list.
• Divide the whole team into sub-teams to prepare
mini specs. for one or more entries of the list.
• Present the mini specs. Addition/deletion is
permitted.
• Create a list of validation criteria.
• Designate a team to write complete draft specs.
 Quality Function Deployment
(QFD)
• Is a quality management technique that translates
the needs of the customer into technical
requirements.
• Concentrates on maximizing customer satisfaction.
• Emphasizes on what is valuable to the customers
and then deploys these values during SE process.
• QFD generally identifies three types of
requirements.
 QFD
• Customer’s needs imply technical requirements:
– Normal requirements: If these requirements are
present the customer is satisfied (minimal
functional & performance).
– Expected requirements: These are implicit and
so fundamental in nature that customer does
not explicitly states them (important implicit
requirements, i.e. ease of use, learn, and
operate).
– Exciting requirements: Beyond the customers
expectation (may become normal requirements
in the future, highly prized & valued).
 Q.F.D.

• Function Deployment:
– Determines value of required function.
• Information Deployment:
– Focuses on data objects and events
produced or consumed by the system.
• Task Deployment:
– product behavior and implied operating
environment.
QFD
 Q.F.D.
• Value Analysis makes use of
– Customer interviews.
– Observations.
– Surveys.
– Historical data.
• to create
– Customer Voice Table (Table of requirements).
– extract expected requirements
– derive exciting requirements
 Use Case Diagrams
• Scenarios that describe how the product will be used in
specific situations.
• Use cases capture who (actor) does what (interaction) with
the system, for what purpose (goal), without dealing with
system internals.
• Written narratives that describe the role of an actor (user
or device) as it interacts with the system.
• Use-cases designed from the actor's (End user) point of
view.
• Not all actors can be identified during the first iteration of
requirements elicitation.
• But it is important to identify the primary actors before
developing the use-cases.
Use Case Diagrams
Use Case Diagrams
Use Case Diagrams
Use Case Diagrams
 Use Case Template
• Brief Description: Background
• Actors that interact with the use case
• Flow of events
– Basic: Primary events that occur when use case is
executed.
– Alternative: Any subsidiary events that occur in use case.
• Preconditions
• Post conditions
• Special Requirements : Business rules for the basic and
alternative flows should be listed as special requirements. Both success
and failure scenarios should be described.
• Extension Points
Use Case Template
Use Case Template
Use Case Guidelines
Use Case Conventions
Use Case Conventions
Use Case Description

------- User Name, Role, Password

Use Case Description
Use Case Description