14-08-2023
Software Engineering : Introduction
1
IMPLEMENTATION
PROGRAMMING
ANALYSIS
DESIGNING
DEBUGGING
August 14, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Microsoft Icons
2
1
14-08-2023
IMPLEMENTATION
ANALYSIS
PROGRAMMING
DESIGNING
DEBUGGING
August 14, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Microsoft Icons
3
• select appropriate software process model and
project planning;
• generate verified set of functional and nonfunctional requirements for a software project;
• design software project as per verified set of
requirements;
• select appropriate testing methodologies for
identifying errors;
• evaluate quality factors to ensure process
improvement;
• measure software project risks and decide on
appropriate mitigation techniques
August 14, 2023
Nabendu Chaki, University of Calcutta
4
2
14-08-2023
• Introduction: Objectives, Definitions, Software and
Systems Engineering, Software Qualities, Different
phases of software development.
• Software Process Models: Waterfall, Prototyping, RAD,
Incremental model, Spiral model, Agile Programming.
• Software Requirements Engineering: Requirement
elicitation, Requirements analysis, Requirements
negotiation, Characteristics, Components, Prototyping,
Basic concepts of formal requirements specification,
Requirements specification, Requirements validation and
Requirements tracing, RE tools.
• Software Design: Design Paradigms such as structured
design, object-oriented analysis and design, event driven
design, component-level design, aspect-oriented design,
function-oriented design, service oriented design, design
tools.
Ian Sommerville, Software Engineering, 9th Ed., 2011, Pearson
5
• Software Testing: Verification and validation concepts,
unit testing, integration testing, system testing, test plan
creation and test case generation, black-box and whitebox testing techniques, Regression testing and test
automation.
• Software Project Planning: Effort Estimation models,
Project Scheduling. Software Maintenance, Software
configuration management and version control.
• Software Quality Management: Quality factors, Quality
and standards, Quality Assurance, Quality Policy, Quality
Control, Maturity models in process improvement.
• Software Risk Management: Risk identification and
management, Risk analysis and evaluation, Risk
mitigation approaches.
August 14, 2023
Nabendu Chaki, University of Calcutta
6
3
14-08-2023
• You pass out from the University…
• Congratulations!!! You got a job
• You are lucky – got a warm welcome from the
senior pros!
• It’s your day indeed! Your team takes you to a
prospective client’s office in the very first week
of your job…
• Your first chance to show the world what you
are!
• What are you supposed to do there? How do
you start? Where do you start?
August 14, 2023
Nabendu Chaki, University of Calcutta
7
• Customer’s need is somewhat vague and
complex – how do you analyse the situation?
• Is the project feasible? How do you decide?
• Customer asks for a tentative development
period for the job – What would be your
response?
• Customer asks for a tentative cost - How do you
assess that and quote a price?
• How do you ensure the quality of the product?
• What are the risks involved?
August 14, 2023
Nabendu Chaki, University of Calcutta
8
4
14-08-2023
• Choose suitable architecture and process model
• Analyze a system & identify the requirements for
a new job (a list of What)
• Design for a solution (a list of how)
• Organise your man-power
• Improve the quality of software
• Increase the reusability
• Verify and validate your work-products
• Maintain a software including managing changes
• ……….
August 14, 2023
Nabendu Chaki, University of Calcutta
9
August 14, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Depositphotos
10
5
14-08-2023
• The term Software Engineering was introduced in
the late 1960s at a conference held to discuss the
software crisis.
• The quest for a definition begins….
• In 1993, IEEE defines SE as:
“(1) The application of a systematic, disciplined,
quantifiable approach to the development,
operation, and maintenance of software; that is,
the application of engineering to software.
(2) The study of approaches as in (1).”
August 14, 2023
Nabendu Chaki, University of Calcutta
11
Software products may be
• Generic - developed to be sold to a range of
different customers e.g. PC software such as
Excel or Word.
• Customized - developed for a specific
customer according to their need, e.g.
Online ticket booking software for Indian
Railways.
August 14, 2023
Nabendu Chaki, University of Calcutta
12
6
14-08-2023
•
•
•
•
August 14, 2023
Information systems
• Primarily concerned with processing
information which is held in some database.
Embedded systems
• Systems where software is used as a
controller in some broader hardware system
Command and control systems
• Software that monitors the performance of
system and control its operations
Expert systems
• used to make decisions
Nabendu Chaki, University of Calcutta
13
• Computer science is concerned with theory and
fundamentals
• Software engineering is concerned with the
practicalities of developing and delivering useful
software.
• On a lighter note, one may say, “What Chemistry
to Chemical Engineering is Computer science to
Software Engineering!”
August 14, 2023
Nabendu Chaki, University of Calcutta
14
7
14-08-2023
•
•
August 14, 2023
A set of activities whose goal is the
development or evolution of software.
Generic activities in all software processes are:
• Specification - what the system should do
and its development constraints
• Development - production of the software
system
• Testing – to unearth errors or bugs in the
software
• …
Nabendu Chaki, University of Calcutta
15
•
•
August 14, 2023
A simplified representation of a software
process,
presented
from
a
specific
perspective.
Generic process models
• Waterfall model;
• Iterative development model;
• Prototypes, etc.
Nabendu Chaki, University of Calcutta
16
8
14-08-2023
•
•
•
•
•
•
•
•
•
Correctness
Robustness
Reliability
Security
Efficiency
Use friendliness
Malleability
Scalability
Maintainability
Carlo Ghezzi, Fundamentals of Software Engineering, 2nd Ed., 2003, Pearson
17
August 14, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Career Karma
18
9
14-08-2023
My team has access to the fastest and the most
sophisticated computer environments and tools. I
shouldn’t have concerns.
Environment is one of the
several factors
that determine the quality!
August 14, 2023
Nabendu Chaki, University of Calcutta
19
If the schedule slips, we need to add more
software experts – may be, with higher skills and
longer experience. They will bring the schedule
back on the rails!
Unfortunately,
software business does not
entertain schedule compaction
beyond a limit!
August 14, 2023
Nabendu Chaki, University of Calcutta
20
10
14-08-2023
• A general statement of objectives is sufficient to
get started with the development of software.
• Missing/vague requirements can easily be
incorporated/detailed out as they get
concretized.
• Application requirements can never be stable;
software can be and has to be made flexible
enough to allow changes to be incorporated as
they happen.
August 14, 2023
Nabendu Chaki, University of Calcutta
21
Until the software is coded and is available for
testing, there is no way for assessing its quality.
Too many tiny bugs are inserted
at every stage. They grow in size
and complexity in further stages!
August 14, 2023
Nabendu Chaki, University of Calcutta
22
11
14-08-2023
The only deliverable for a software development
project is the tested code.
Code is only the
externally visible component
of the entire software!
August 14, 2023
Nabendu Chaki, University of Calcutta
23
source
codes
object
codes
test suites
August 14, 2023
reports
data
test results
documents
manuals
prototypes
Nabendu Chaki, University of Calcutta
24
12
14-08-2023
Interesting facts based on
Barry Boehm’s Observations
August 14, 2023
Nabendu Chaki, University of Calcutta
25
20%
modules
August 14, 2023
80%
errors
Nabendu Chaki, University of Calcutta
26
13
14-08-2023
20%
modules
August 14, 2023
80%
exec time
Nabendu Chaki, University of Calcutta
27
20%
tools
August 14, 2023
80%
use
Nabendu Chaki, University of Calcutta
28
14
14-08-2023
Questions?
29
15
14-08-2023
Software Engineering
in
System Engineering
1
•
•
•
•
August 14, 2023
A purposeful collection of inter-related
components working together to achieve
some common objective.
A system may include software, mechanical,
electrical and electronic hardware and be
operated by people.
System components are dependent on other
system components
The properties and behaviour of system
components are inextricably inter-mingled
Nabendu Chaki, University of Calcutta
2
1
14-08-2023
•
•
•
August 14, 2023
Scope of software engineering is often a part
of a large system engineering job
System engineering is concerned with all the
aspects including hardware, software and
process engineering.
Software engineering is part of this process
concerned with development of the software
infrastructure, control, applications and
databases in the system.
Nabendu Chaki, University of Calcutta
3
August 14, 2023
Image Courtesy: American Psychological Association
4
2
14-08-2023
•
•
August 14, 2023
Need for parallel development of different
parts of the system
• little scope for iteration between phases
as hardware changes are very expensive.
• software may have to compensate for
hardware problems.
Inevitably involves engineers from different
disciplines who must work together
• scope for misunderstanding here different disciplines use a different
vocabulary and much negotiation is
required.
Nabendu Chaki, University of Calcutta
5
August 14, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Flight Mechanic
6
3
14-08-2023
August 14, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Flight Mechanic
7
• The process of putting hardware, software and
people together to make a system.
• Should be tackled incrementally so that subsystems are integrated one at a time.
• Interface problems between sub-systems are
usually found at this stage.
• Possible problems with uncoordinated deliveries
of system components.
August 14, 2023
Nabendu Chaki, University of Calcutta
8
4
14-08-2023
• Environmental assumptions may be incorrect
• Possible human resistance to the introduction
of a new system
• System may require to coexist with alternative
systems for some time
• Possible physical installation and integration
problems (e.g., cabling problems)
• Operator training issues
• …
August 14, 2023
Nabendu Chaki, University of Calcutta
9
•
•
•
August 14, 2023
Large systems have a long lifetime. They must
evolve to meet changing requirements.
Evolution is inherently costly
• Changes must be analysed
• Sub-systems interact so unanticipated
problems can arise
• System structure is corrupted as changes
are made to it
Existing systems which must be maintained
are sometimes called legacy systems.
Nabendu Chaki, University of Calcutta
10
5
14-08-2023
• Taking the system out of service after its useful
lifetime.
• May require data to be restructured and
converted to be used in some other system.
August 14, 2023
Nabendu Chaki, University of Calcutta
11
•
Process changes
•
Does the system require changes to the
work processes in the environment?
•
Job changes
• Does the system de-skill the users in an
environment or cause them to change the
way they work?
•
Organisational changes
• Does the system change the political
power structure in an organisation?
August 14, 2023
Nabendu Chaki, University of Calcutta
12
6
14-08-2023
•
•
•
•
•
•
August 14, 2023
Hardware – possibly outdated
Support software - may depend on support
software from suppliers, no longer in business.
Application software - may be written in
obsolete programming languages, e.g., Ada.
Application data - often incomplete and
inconsistent.
Business processes - may be constrained by
software structure and functionality.
Business policies and rules - may be implicit
and embedded in the system software.
Nabendu Chaki, University of Calcutta
13
• SE follows a systematic approach
• SE reduces development cost
• SE reduces development time
• SE helps to repeat previous successes
• SE helps learning from previous failures
• SE develops quality software product
• SE provides ease for maintenance
• SE standardizes the process
August 14, 2023
Nabendu Chaki, University of Calcutta
14
7
14-08-2023
Questions?
15
8
8/14/2023
Feasibility Study
1
August 14, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Hillside Product Design
2
1
8/14/2023
FS is a short, low-cost study to identify the
following at the beginning of a project
•
Client
•
Scope
•
Potential benefits
•
Resources needed: staff, time, equipment, etc.
•
Potential obstacles
What are the concerns?
August 14, 2023
Nabendu Chaki, University of Calcutta
3
The aims of a feasibility study are
• to find out whether the system is worth
implementing and,
• if it can be implemented, given the existing
budget and schedule.
August 14, 2023
Nabendu Chaki, University of Calcutta
4
2
8/14/2023
To provide management with enough information
to know:
• Whether the project can be done
• Whether the final product will benefit its
intended users
• What the alternatives are (so that a selection
can be made in subsequent phases)
• Whether there is a preferred alternative
August 14, 2023
Nabendu Chaki, University of Calcutta
5
• The present organizational system
• Stakeholders,
objectives,...
users,
policies,
functions,
• Problems with the present system
• Inconsistencies, inadequacies in functionality,
performance,…
August 14, 2023
Nabendu Chaki, University of Calcutta
6
3
8/14/2023
• Goals and other requirements for the new
system
• Which problem(s) need to be solved?
• What would the stakeholders like to achieve?
• Constraints
including
nonfunctional
requirements on the system
August 14, 2023
Nabendu Chaki, University of Calcutta
7
Possible alternatives
• “Sticking with the current system” is always an
alternative
• Different business processes for solving the
problems
• Different levels/types of computerization for
the solutions
• There are merits and demerits for each of the
alternatives
August 14, 2023
Nabendu Chaki, University of Calcutta
8
4
8/14/2023
• Technical feasibility
• Economic feasibility
• Schedule feasibility
• Operational feasibility
August 14, 2023
Nabendu Chaki, University of Calcutta
9
Do we have the technology to solve the problem?
August 14, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Microsoft Icons
10
5
8/14/2023
• Is the proposed technology or solution practical?
• Do we currently possess the necessary
technology?
• Do we possess the necessary technical
expertise
…and is the schedule reasonable for this
team?
• Is relevant technology mature enough to be
easily applied to our problem?
August 14, 2023
Nabendu Chaki, University of Calcutta
11
• What kinds of technology will we need?
• Some organizations like to use state-of-the-art
technology
…but most prefer to use mature and proven
technology.
• A mature technology has a larger customer
base for obtaining advice concerning
problems and improvements.
August 14, 2023
Nabendu Chaki, University of Calcutta
12
6
8/14/2023
• Is the required technology available “in house”?
• If the technology is available:
…does it have the capacity to handle the
solution?
• If the technology is not available: …can it be
acquired?
August 14, 2023
Nabendu Chaki, University of Calcutta
13
Will it be financially viable?
August 14, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Microsoft Icons
14
7
8/14/2023
• Can the bottom line be quantified yet?
• Very early in the project…
• a judgment of whether solving the problem is
worthwhile.
• Once specific requirements and solutions
have been identified…
…the costs and benefits of each alternative
may be calculated
August 14, 2023
Nabendu Chaki, University of Calcutta
15
• Cost-benefit analysis
• Is the project justified (I.e. will benefits
outweigh costs)?
• What is the minimal cost to attain a certain
system?
• How soon will the benefits accrue?
• Which alternative offers the best return on
investment?
August 14, 2023
Nabendu Chaki, University of Calcutta
16
8
8/14/2023
• Examples of things to consider:
• hardware/software selection
• selection among alternative financing
arrangements (rent/lease/purchase)
• Difficulties
• benefits and costs can both be intangible,
hidden, hard to estimate
• ranking multi-criteria alternatives
August 14, 2023
Nabendu Chaki, University of Calcutta
17
Can we do it in time?
August 14, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Microsoft Icons
18
9
8/14/2023
• Can the job be finished within the proposed
time limit?
• It’s assumed that technically there is a
solution and economic feasibility is also
confirmed.
August 14, 2023
Nabendu Chaki, University of Calcutta
19
Will it be possible for us to DO the job?
August 14, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Microsoft Icons
20
10
8/14/2023
• Even if technically, there exists solution the
operational factors may not be in favor
• Lack of proper infrastructure
• End-users are not motivated enough!
August 14, 2023
Nabendu Chaki, University of Calcutta
21
Questions?
22
11
Software Development
Life Cycle (SDLC) Models
(Part – I)
1
September 13, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: SlideShare
2
1
• Software Development Life Cycle (SDLC) is a
framework that defines the steps involved in the
development of software at each phase.
• SDLC covers the detailed plan for building,
deploying and maintaining the software.
• SDLC defines the complete cycle of development
i.e., all the tasks involved in planning, creating,
testing,
deploying,
maintain,
and
even
decommissioning a Software Product.
September 13, 2023
Nabendu Chaki, University of Calcutta
3
September 13, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: ProductPlan
4
2
• Waterfall Model
• Iterative Waterfall Model
• Prototype Model
• Evolutionary Model
• Spiral Model
• Iterative Incremental Model
• Agile Model
September 13, 2023
Nabendu Chaki, University of Calcutta
5
September 13, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Dissolve
6
3
• Classical waterfall model divides life cycle into
several phases, such as:
• requirements analysis and specification,
• design,
• coding and unit testing,
• integration and system testing,
• maintenance.
September 13, 2023
Nabendu Chaki, University of Calcutta
7
Feasibility Study
Req. Engineering
Design
Coding
Testing
Maintenance
September 13, 2023
Nabendu Chaki, University of Calcutta
8
4
• Most organizations usually define:
• standards on the outputs (deliverables)
produced at the end of every phase
• entry and exit criteria for every phase.
• They also prescribe specific methodologies for:
• specification
• design
• testing
• project management, etc.
September 13, 2023
Nabendu Chaki, University of Calcutta
9
• The guidelines and methodologies of an
organization:
• are referred as the organization's software
development methodology.
• Software development organizations:
• expect fresh engineers to master the
organization's software development
methodology.
September 13, 2023
Nabendu Chaki, University of Calcutta
10
5
• Aim of this phase:
• to understand the exact requirements of the
customer,
• to document them properly.
• Consists of two distinct activities:
• requirements gathering and analysis
• requirements specification.
September 13, 2023
Nabendu Chaki, University of Calcutta
11
• Design phase transforms requirements
specification:
• into a form suitable for implementation in
some programming language.
• In technical terms:
• during design phase, software architecture is
derived from the SRS document.
• Design approaches:
• traditional approach,
• object oriented approach.
September 13, 2023
Nabendu Chaki, University of Calcutta
12
6
• Purpose of implementation phase (aka coding
and unit testing phase):
• translate software design into source code.
• During the implementation phase:
• each module of the design is coded,
• each module is unit tested
• tested independently as a stand alone unit,
and debugged,
• each module is documented.
September 13, 2023
Nabendu Chaki, University of Calcutta
13
• The purpose of unit testing:
• test if individual modules work correctly.
• The end product of implementation phase:
• a set of program modules that have been
tested individually.
September 13, 2023
Nabendu Chaki, University of Calcutta
14
7
• Different modules are integrated in a planned
manner:
• modules are almost never integrated in one
shot.
• Normally integration is carried out through a
number of steps.
September 13, 2023
Nabendu Chaki, University of Calcutta
15
• During each integration step,
• the partially integrated system is tested.
• After all the modules have been successfully
integrated and tested:
• system testing is carried out.
• Goal of system testing:
• ensure that the developed system functions
according to its requirements as specified in
the SRS document.
September 13, 2023
Nabendu Chaki, University of Calcutta
16
8
• Maintenance of any software product:
• requires much more effort than the effort to
develop the product itself.
• development effort to maintenance effort is
typically 40:60.
September 13, 2023
Nabendu Chaki, University of Calcutta
17
• Corrective maintenance:
• Correct errors which were not discovered
during the product development phases.
• Perfective maintenance:
• Improve implementation of the system
• enhance functionalities of the system.
• Adaptive maintenance:
• Port software to a new environment,
• e.g. to a new computer or to a new
operating system.
September 13, 2023
Nabendu Chaki, University of Calcutta
18
9
OMG! I forgot my
carabiners up
there!
September 13, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: Dissolve
19
Questions?
20
10
Requirements Engineering
September 13, 2023
Nabendu Chaki, University of Calcutta
1
RE to Bridge the Gap
System
Engineering
Software
Requirements
Engineering
Software
Design
September 13, 2023
2
Nabendu Chaki, University of Calcutta
What is Requirements Engineering?
• A study of user needs for a problem to arrive
at a definition of WHAT the software will do
without describing how it will do it.
• A Software Requirements Specification (SRS) is
a document containing functional and nonfunctional requirements for a system.
September 13, 2023
Nabendu Chaki, University of Calcutta
3
What is Requirements Engineering?
User requests
User requests
User requests
Problem Analysis
Understanding of user’s requirements
System Description
Software Requirements Specification
September 13, 2023
4
Nabendu Chaki, University of Calcutta
Types of Requirements
• Functional requirements define part of the
system’s functionality.
• Non-Functional Requirements
• Implementation requirements which state
how the system is to be implemented.
• Performance requirements which specify a
minimum acceptable performance for the
system.
• Constraints, e.g., the maximum acceptable
time to deliver the system.
September 13, 2023
Nabendu Chaki, University of Calcutta
5
Challenges
• The requirements agreed may not actually reflect
the real needs of the customer for the system.
• It is important to understand and unearth the
hidden agendas – that’s the real treasure box for
a good system analyst.
• Requirements could be inconsistent and/or
incomplete.
September 13, 2023
6
Nabendu Chaki, University of Calcutta
Challenges
• It is expensive to make changes to requirements
at a later stage of development.
• Often there are misunderstandings between
customers, those developing the system
requirements and software engineers developing
or maintaining the system.
September 13, 2023
Nabendu Chaki, University of Calcutta
7
RE process - inputs and outputs
Domain
Information
Agreed
requirements
Organizational
Standard
Regulations
Requirements
Engineering Process
Stakeholders’
needs
System
Models
Existing
System
Information
September 13, 2023
8
System
specification
Nabendu Chaki, University of Calcutta
Requirements Engineering Activities
• Requirements elicitation
• Requirements are discovered through
consultation with stakeholders
• Requirements analysis
• Requirements are analyzed to check for
completeness, consistencies, correctness,
and other quality aspects
• Requirements negotiation
• Conflicts are resolved through requirements
negotiation
• …
September 13, 2023
Nabendu Chaki, University of Calcutta
9
Elicitation, analysis and negotiation
Draft
statement of
requirements
Requirements
elicitation
Requirements
analysis
Requirements
problems
Requirements
document
Requirements
negotiation
September 13, 2023
10
Nabendu Chaki, University of Calcutta
Requirements Engineering Activities
• Requirements documentation
• A requirements document is produced.
This is popularly referred as Software
Requirement Specification (SRS).
• Requirements validation
• The requirements document is checked
for consistency and completeness
• Requirements management
• The process of managing change to the
requirements for a system
September 13, 2023
Nabendu Chaki, University of Calcutta
11
Requirements Elicitation
September 13, 2023
12
Nabendu Chaki, University of Calcutta
Requirements Elicitation Process
Establish Objectives
Understanding background
Organize Knowledge
Collect Requirements
Business
goals
Organizational
structure
Stakeholder
identification
Stakeholder
requirements
Problems to
be solved
Application
domain
Goal
prioritization
Domain
requirements
System
constraints
Existing
systems
Domain knowledge
filtering
Organizational
requirements
September 13, 2023
Nabendu Chaki, University of Calcutta
13
Requirements Elicitation Process
Establish Objectives
Organize Knowledge
Collect Requirements
Business
goals
Organizational
structure
Stakeholder
identification
Stakeholder
requirements
Problems to
be solved
Application
domain
Goal
prioritization
Domain
requirements
System
constraints
Existing
systems
Domain knowledge
filtering
Organizational
requirements
September 13, 2023
14
Understanding background
Nabendu Chaki, University of Calcutta
Requirements Elicitation Process
Establish Objectives
Understanding background
Organize Knowledge
Collect Requirements
Business
goals
Organizational
structure
Stakeholder
identification
Stakeholder
requirements
Problems to
be solved
Application
domain
Goal
prioritization
Domain
requirements
System
constraints
Existing
systems
Domain knowledge
filtering
Organizational
requirements
September 13, 2023
Nabendu Chaki, University of Calcutta
15
Requirements Elicitation Process
Establish Objectives
Organize Knowledge
Collect Requirements
Business
goals
Organizational
structure
Stakeholder
identification
Stakeholder
requirements
Problems to
be solved
Application
domain
Goal
prioritization
Domain
requirements
System
constraints
Existing
systems
Domain knowledge
filtering
Organizational
requirements
September 13, 2023
16
Understanding background
Nabendu Chaki, University of Calcutta
Requirements Elicitation Process
Establish Objectives
Understanding background
Organize Knowledge
Collect Requirements
Business
goals
Organizational
structure
Stakeholder
identification
Stakeholder
requirements
Problems to
be solved
Application
domain
Goal
prioritization
Domain
requirements
System
constraints
Existing
systems
Domain knowledge
filtering
Organizational
requirements
September 13, 2023
Nabendu Chaki, University of Calcutta
17
Requirements Elicitation Process
Establish Objectives
Organize Knowledge
Collect Requirements
Business
goals
Organizational
structure
Stakeholder
identification
Stakeholder
requirements
Problems to
be solved
Application
domain
Goal
prioritization
Domain
requirements
System
constraints
Existing
systems
Domain knowledge
filtering
Organizational
requirements
September 13, 2023
18
Understanding background
Nabendu Chaki, University of Calcutta
Requirements Elicitation Process
Establish Objectives
Understanding background
Organize Knowledge
Collect Requirements
Business
goals
Organizational
structure
Stakeholder
identification
Stakeholder
requirements
Problems to
be solved
Application
domain
Goal
prioritization
Domain
requirements
System
constraints
Existing
systems
Domain knowledge
filtering
Organizational
requirements
September 13, 2023
Nabendu Chaki, University of Calcutta
19
Requirements Elicitation Process
Establish Objectives
Organize Knowledge
Collect Requirements
Business
goals
Organizational
structure
Stakeholder
identification
Stakeholder
requirements
Problems to
be solved
Application
domain
Goal
prioritization
Domain
requirements
System
constraints
Existing
systems
Domain knowledge
filtering
Organizational
requirements
September 13, 2023
20
Understanding background
Nabendu Chaki, University of Calcutta
Requirements Elicitation Process
Establish Objectives
Understanding background
Organize Knowledge
Collect Requirements
Business
goals
Organizational
structure
Stakeholder
identification
Stakeholder
requirements
Problems to
be solved
Application
domain
Goal
prioritization
Domain
requirements
System
constraints
Existing
systems
Domain knowledge
filtering
Organizational
requirements
September 13, 2023
Nabendu Chaki, University of Calcutta
21
Elicitation Stages
• Objectives
• The organisational objectives should be
established including general goals of the
business, an outline description of the
problem to be solved, necessity of the
system and the constraints on the system.
September 13, 2023
22
Nabendu Chaki, University of Calcutta
Elicitation Stages
• Background information about the system
includes information about
• the organisation where the system is to be
installed,
• the application domain of the system and
• information about existing systems
September 13, 2023
Nabendu Chaki, University of Calcutta
23
Elicitation Stages
• Knowledge organisation
• The large amount of knowledge which has
been collected in the previous stage must
be organised and collated.
• Stakeholders are identified
• Goals are prioritized
September 13, 2023
24
Nabendu Chaki, University of Calcutta
Elicitation Stages
• Requirements collection
• System stakeholders are consulted to
discover their requirements.
• Requirements that comply
application domain are listed
to
the
• Organization specific requirements are
listed
September 13, 2023
Nabendu Chaki, University of Calcutta
25
Elicitation Problems
• Not enough time for elicitation
• Inadequate preparation by engineers
• Stakeholders are not convinced about the
need for a new system
September 13, 2023
26
Nabendu Chaki, University of Calcutta
Elicitation Techniques
• Interviews
• Scenarios
• Ethnography
• Requirements reuse
• Prototyping
September 13, 2023
Nabendu Chaki, University of Calcutta
27
Interviews
• Requirements engineer or analyst interviews
different stakeholders and builds up an
understanding of their requirements.
• Types of interview
• Closed interviews: Pre-defined set of
questions
• Open interviews: Open-ended discussion
with the stakeholders to know what they
want from the system
September 13, 2023
28
Nabendu Chaki, University of Calcutta
Interviewing Essentials
• Interviewers must be open-minded and should
not approach the interview with preconceived notions about what is required
• Stakeholders must be given a starting point for
discussion. This can be a question, a
requirements proposal or an existing system
• Interviewers must be aware of organisational
politics - many real requirements may not be
discussed because of their political
implications
September 13, 2023
Nabendu Chaki, University of Calcutta
29
Scenarios
• Scenarios are stories that explain how a
system might be used. They should include
• a description of the system state before
entering the scenario
• the normal flow of events in the scenario
• exceptions to the normal flow of events
• information about concurrent activities
• a description of the system state at the
end of the scenario
September 13, 2023
30
Nabendu Chaki, University of Calcutta
Scenarios
• Scenarios are examples of interaction sessions
which describe how a user interacts with a
system
• Discovering scenarios exposes possible system
interactions and reveals system facilities which
may be required
September 13, 2023
Nabendu Chaki, University of Calcutta
31
Scenarios
• Scenarios are real-life examples of how a system can
be used.
• Based on a practical situation - stakeholders can
relate to those and react.
• Scenarios are a structured form of user story with
• A description of the starting situation;
• A description of the normal flow of events;
• A description of what can go wrong;
• Information about other concurrent activities;
• A description of the state when the scenario
finishes.
September 13, 2023
32
Nabendu Chaki, University of Calcutta
Use Case Diagram
September 13, 2023
Nabendu Chaki, University of Calcutta
33
Use Case Diagram
September 13, 2023
34
Nabendu Chaki, University of Calcutta
Use Case Diagram
September 13, 2023
Nabendu Chaki, University of Calcutta
35
Use Case Diagram
• Use cases identify the actors in an interaction
and which describe the interaction itself.
• A set of use cases should describe all possible
interactions with the system.
• High-level graphical model supplemented by
more detailed tabular description .
• UML sequence diagrams may be used to add
detail to use-cases by showing the sequence of
event processing in the system.
September 13, 2023
36
Nabendu Chaki, University of Calcutta
Ethnography
•
•
•
•
September 13, 2023
People often find it hard to describe what they do
because it is so natural to them. The best way to
understand it is to observe them at work.
An ethnographer observes people at work and
build up a picture of how work is done.
Ethnography is a technique from the social
sciences that has proved to be valuable in
understanding actual work processes
Requirements that are derived from the way that
people actually work rather than the way in which
process definitions suggest that they ought to
work.
Nabendu Chaki, University of Calcutta
37
Ethnography Guidelines
• Actual work processes often differ from
formal, prescribed processes
• Assume that people are good at doing their
job and look for non-standard ways of working
• Spend time getting to know the people and
establish a trust relationship
• Keep detailed notes of all work practices.
Analyse them and draw conclusions from
them
September 13, 2023
38
Nabendu Chaki, University of Calcutta
Ethnography Guidelines
• Combine observation with open-ended
interviewing
• Organise regular de-briefing session where the
ethnographer talks with people outside the
process
• Combine ethnography with other elicitation
techniques
September 13, 2023
Nabendu Chaki, University of Calcutta
39
Requirements Reuse
• Reuse involves taking the requirements which
have been developed for one system and
using them in a different system
• Requirements reuse saves time and effort as
reused requirements have already been
analysed and validated in other systems
• Currently, requirements reuse is an informal
process but more systematic reuse could lead
to larger cost savings
September 13, 2023
40
Nabendu Chaki, University of Calcutta
Reuse Possibilities
• whether the requirement is concerned with
providing application domain info.
• whether the requirement is concerned with
the style of information presentation. Reuse
leads to a consistency of style across
applications.
• whether the requirement reflects company
policies such as security policies
September 13, 2023
Nabendu Chaki, University of Calcutta
41
Prototyping
• A prototype is an initial version of a system
which may be used for experimentation
• Rapid development of prototypes is essential
so that they are available early in the
elicitation process
September 13, 2023
42
Nabendu Chaki, University of Calcutta
Prototyping Benefits
• The prototype allows users to experiment and
discover what they really need to support
their work
• Establishes feasibility and usefulness before
high development costs are incurred
September 13, 2023
Nabendu Chaki, University of Calcutta
43
Prototyping Benefits
• Essential for developing the ‘look and feel’ of a
user interface
• Can be used for system testing and the
development of documentation
• Forces a detailed study of the requirements
which reveals inconsistencies and omissions
September 13, 2023
44
Nabendu Chaki, University of Calcutta
Types of Prototyping
• Throw-away prototyping
• intended to help elicit and develop the
system requirements.
• The requirements which should be
prototyped are those which cause most
difficulties to customers and which are the
hardest to understand. Requirements
which are well-understood need not be
implemented by the prototype.
September 13, 2023
Nabendu Chaki, University of Calcutta
45
Types of Prototyping
• Evolutionary prototyping
• intended to deliver a workable system
quickly to the customer.
• requirements that should be supported by
the initial versions of this prototype are
those that are well-understood and that
can deliver useful end-user functionality.
• It is only after extensive use that poorly
understood requirements should be
implemented.
September 13, 2023
46
Nabendu Chaki, University of Calcutta
Prototyping Costs and Problems
• Training costs - prototype development may
require the use of special purpose tools
• Development costs - depend on the type of
prototype being developed
• Incompleteness - it may not be possible to
prototype critical system requirements
September 13, 2023
Nabendu Chaki, University of Calcutta
47
Prototyping Costs and Problems
• Extended development schedules - developing
a prototype may extend the schedule although
the prototyping time may be recovered
because rework is avoided
• Lack of formalism – there could be a tendency
to “do whatever you get from user” leading to
lack of quality
September 13, 2023
48
Nabendu Chaki, University of Calcutta
Questions?
49
Requirements Analysis
October 9, 2023
Nabendu Chaki, University of Calcutta
1
Requirements Analysis
• The goal of analysis is to discover problems,
incompleteness and inconsistencies in the elicited
requirements.
•
These are then fed back to the stakeholders to resolve
them through the negotiation process
• Analysis is interleaved with elicitation as problems
are discovered when the requirements are elicited
• A problem checklist may be used to support
analysis.
•
October 9, 2023
2
Each requirement may be assessed against the
checklist
Nabendu Chaki, University of Calcutta
Analysis Checklists
• Premature design
• Does the requirement include premature
design or implementation information?
• Combined requirements
• Does the description of a requirement
describe a single requirement or could it be
broken down into two or more different
requirements?
October 9, 2023
Nabendu Chaki, University of Calcutta
3
Analysis Checklists
• Unnecessary requirements
• Is the requirement just a ‘gold plating’? i.e., is
the requirement a cosmetic addition to the
system and is not really required?
• Requirements verifiability
• Is the requirement verifiable, e.g., is it stated
in such a way that test engineers can derive a
test which can show if the system meets that
requirement?
October 9, 2023
4
Nabendu Chaki, University of Calcutta
Analysis Checklists
• Conformance with business goals
• Is the requirement consistent with the
business goals defined in the introduction to
the requirements document?
• Ambiguous Requirements
• Is the requirement ambiguous i.e. could it be
interpreted in more than one ways by
different people? What are the possible
interpretations of the requirement?
October 9, 2023
Nabendu Chaki, University of Calcutta
5
Analysis Checklists
• Requirements realism
• Is the requirement realistic given the
technology which will be used to implement
the system?
• Use of non-standard hardware
• Does the requirement mean that nonstandard hardware or software must be
used? In order to decide on this, one needs
to have the platform requirements.
October 9, 2023
6
Nabendu Chaki, University of Calcutta
Requirements Analysis Method
• There is no ideal requirement analysis method
• Several methods use a variety of modelling
techniques to analyse the requirements
• Software process models or/and overall system
models can be enriched by modelling different
aspects using multiple modelling techniques
October 9, 2023
Nabendu Chaki, University of Calcutta
7
Analysis Models
Data Flow Diagram
Functional view
Entity Relationship Diagram
Stored Data view
State Transition Diagram
Time-dependent
behavior view
October 9, 2023
8
Nabendu Chaki, University of Calcutta
Requirements Interactions
• Requirement Analysis aims to discover the
interactions between requirements and highlights
conflicts and overlaps in the requirements
• A requirements interaction matrix shows how
requirements interact with each other.
Requirements are listed along the rows and
columns of the matrix
• requirements that conflict, fill in with 1
• requirements that overlap, fill in with 1000
• requirements that are independent, fill in with 0
October 9, 2023
Nabendu Chaki, University of Calcutta
9
Interaction Matrix
Requirements
R1
R2
R3
R4
R5
R6
R1
0
0
1000
0
1
1
R2
0
0
0
0
0
0
R3
1000
0
0
1000
0
1000
R4
0
0
1000
0
1
1
R5
1
0
0
1
0
0
R6
1
0
1000
1
0
0
October 9, 2023
10
Nabendu Chaki, University of Calcutta
Data Flow Diagram (DFD)
• A DFD depicts the flow of information within a
system as well as between the system and the
outside world.
• It does not show sequence and control
information.
• A Data Flow Diagram (DFD) contains:
• External entities, Processes, Data flows,
Data stores
October 9, 2023
Nabendu Chaki, University of Calcutta
11
Leveled DFDs
Context Diagram
The
System
1
*
2
*
Level-1 DFD
3
Level-2 DFD
3.1 *
October 9, 2023
12
Nabendu Chaki, University of Calcutta
3.2 *
DFD Primitives
• External Entity represents a source or sink for
data. These are usually outside the scope of the
area under study.
• Process transforms or manipulates data
• Data flow carries data between a terminator and
a process, a process and a store, or between two
processes
• Data Store represents a repository of data
• Connector symbols are used if the diagram spans
multiple pages.
October 9, 2023
Nabendu Chaki, University of Calcutta
13
Notation Variability
• There is little uniformity in industry concerning
the DFD notation. The notation shown was
advanced by DeMarco
• Gane and Sarson use rounded rectangles for
bubbles, shadowed rectangles for sources and
destinations, and squared off C’s for data stores
• Orr uses rectangles for bubbles, ellipses for
sources and destinations, and ellipses for data
stores
October 9, 2023
14
Nabendu Chaki, University of Calcutta
DFD Hierarchy
• DFD can be used at different levels.
• The highest level DFD is called a Context Diagram
• A process may be exploded into a lower level DFD
to show more detail.
• The net input and output flows must be
balanced across the DFD levels.
• The lower level DFD may have data stores that
are local to it, and not shown in the higher level
DFD.
October 9, 2023
Nabendu Chaki, University of Calcutta
15
DFD Example
• Consider a small food joint intended to automate
the food ordering process
• Food Ordering System is actually a type of
software that allows the manager of restaurants
to manage and accept the placed orders over the
Internet or in the restaurant.
• Let us understand the working of the food
ordering system by using DFD (Data Flow
Diagram).
October 9, 2023
16
Nabendu Chaki, University of Calcutta
Level-0 DFD for Food Ordering System
October 9, 2023
Figure Courtesy: https://www.geeksforgeeks.org/
17
Level-1 DFD for Food Ordering System
October 9, 2023
18
Figure Courtesy: https://www.geeksforgeeks.org/
Level-1 DFD for Food Ordering System
October 9, 2023
Figure Courtesy: https://www.geeksforgeeks.org/
19
Level-2 DFD for Processing an Order
October 9, 2023
20
Figure Courtesy: https://www.geeksforgeeks.org/
DFD Guidelines
• Ideally, a DFD at any level, should have no more
than half a dozen processes and related stores.
• Choose meaningful names for processes, flows,
stores, and terminators
• use active unambiguous verbs for process
names such as Create, Calculate, Compute,
Produce, etc.
• Number the processes
October 9, 2023
Nabendu Chaki, University of Calcutta
21
DFD Guidelines
• Avoid overly complex DFDs
• Balance DFDs across levels
• Data flows and stores must be described to the
Data dictionary.
• Processes must be supported either by a lower
level DFD or a mini-specification.
October 9, 2023
22
Nabendu Chaki, University of Calcutta
Lowest Level Processes in a DFD
• A process that cannot be exploded further has an
associated mini specification.
• Mini specification can be in:
• Structured English
• Action Diagram
• Decision Table/Decision Tree
October 9, 2023
Nabendu Chaki, University of Calcutta
23
Specification in Structured English
FOR EACH item in the Indent DO
IF Item is on Rate-Contract
prepare PO to Rate-Contract vendor
ELSE IF Item is proprietary
prepare PO to manufacturer
ELSE
prepare regular PO to registered vendor
END FOR
October 9, 2023
24
Nabendu Chaki, University of Calcutta
Decision Table
Conditions
Good payment record y
Order Cost>Rs 1 lac y
Membership > 5yrs
y
Actions
Priority treatment
Normal treatment
October 9, 2023
X
y
y
y
n
n
n
n
y
n
n
y
y
n
n
n
y
n
y
n
y
n
X
X
X
X
X
X
X
Nabendu Chaki, University of Calcutta
25
Data Models
• Approaches to semantic data modelling include:
• Entity-relationship model (Chen, 1976)
• RM/ T (Codd, 1979)
• SDM (Hammer and McLeod, 1981)
• Models identify the entities in a database, their
attributes and their relationships
• Relational and other Data Models
• Uses graphical notations
October 9, 2023
26
Nabendu Chaki, University of Calcutta
Entity Relationship Model
Identifier
Description
Source
Type
Requirement
1
Priority
Specification
has
(0,N)
Identifier
Changes
description
N
1,N
result in
Version
author
rationale
October 9, 2023
Nabendu Chaki, University of Calcutta
27
The Data Dictionary
• Data dictionary is an organized listing of all data
elements pertinent to the system with precise,
rigorous and unambiguous definitions so that
both user and SA will have common
understanding of all data elements.
• It describes:
• meaning and composition of data flows,
• data stores
• relevant values and units of elementary data
elements
• details of relationships between stores that
are highlighted in a ERD
October 9, 2023
28
Nabendu Chaki, University of Calcutta
Data Dictionary Notation
customer-name = title + first-name +
(middle-name) + last-name
title = [Mr. | Miss | Ms. | Mrs.| Dr. | Prof. ]
first-name = {legal-character}
order = customer-name + shipping-addr
+ {item}
October 9, 2023
Nabendu Chaki, University of Calcutta
29
State Transition Diagram (STD)
• It highlights the time-dependent behavior of a
system.
• It shows ‘what’ happens ‘when’
• Major components
• States
• Transitions between states
• Useful for describing behavior of
• real-time systems, interactive systems
• STDs like DFDs are used I the design phase
too for further detailing
October 9, 2023
30
Nabendu Chaki, University of Calcutta
State Transition Diagram (STD)
RButton-down
/ display PopUp Menu
Idle
Menu visible
RButton-up
/ erase PopUp Menu
Cursor-moved
/ highlight Menu item
October 9, 2023
Nabendu Chaki, University of Calcutta
31
Cross Checking using the Models
•
•
•
•
October 9, 2023
32
Balancing ERD against the DFD, Process specs.
Balancing DFD against the STD
Balancing ERD against Data dictionary
Balancing DFD against Data dictionary
Nabendu Chaki, University of Calcutta
Conclusions
• Requirements define what the system should
provide and define system constraints
• Requirements problems lead to late delivery and
change requests after the system is in use
• There is no ideal method for requirements
analysis
• System models can be considerably enriched by
combining different techniques
October 9, 2023
Nabendu Chaki, University of Calcutta
33
Conclusions
• Data-flow model is based on the notion that
systems can be modelled as a set of interacting
functions
• Formal methods are based on mathematical
principles and are intended to achieve a high
degree of confidence that a system will conform
to its specifications
October 9, 2023
34
Nabendu Chaki, University of Calcutta
Questions?
35
Requirements Negotiation
1
Requirements Negotiation
• Disagreements about requirements are
inevitable when a system has many
stakeholders. Conflicts are not ‘failures’ but
reflect different stakeholder needs and priorities.
• Requirements negotiation is the process of
discussing requirements conflicts and reaching a
compromise that all stakeholders can agree to
• In planning a requirements engineering process,
it is important to leave enough time for
negotiation. Finding an acceptable compromise
can be time-consuming.
October 9, 2023
2
Nabendu Chaki, University of Calcutta
Requirements Negotiation
• Requirements discussion
• Requirements with problems are discussed
and the stakeholders involved present their
views about the requirements.
• Requirements prioritisation
• Disputed requirements are prioritised to
identify critical requirements and to help the
decision making process.
• Requirements agreement
• Solutions to the requirements problems are
identified and a compromise set of
requirements are agreed.
October 9, 2023
Nabendu Chaki, University of Calcutta
3
Negotiation Meetings
• An information stage where the nature of the
problems associated with a requirement is
explained.
• A discussion stage where the stakeholders
involved discuss how these problems might be
resolved.
• All stakeholders with an interest in the
requirement should be given the opportunity
to comment. Priorities may be assigned to
requirements.
October 9, 2023
4
Nabendu Chaki, University of Calcutta
Negotiation Meetings
• A resolution stage where actions concerning the
requirement are agreed.
• These actions might be to delete the
requirement,
to
suggest
specific
modifications to the requirement or to elicit
further information about the requirement.
October 9, 2023
Nabendu Chaki, University of Calcutta
5
Key points
• Requirements elicitation involves understanding
the application domain, the specific problem to be
solved, the organisational needs and constraints
in the system.
• The processes of requirements elicitation, analysis
and negotiation are iterative, interleaved
processes which must usually be repeated several
times.
• There are various techniques of requirements
elicitation which may be used including
interviewing, scenarios, soft systems methods,
prototyping and participant observation.
October 9, 2023
6
Nabendu Chaki, University of Calcutta
Key points
• Prototypes are effective for requirements
elicitation because stakeholders have something
which they can experiment with to find their real
requirements.
• Checklists remind analysts what to look for when
reading through the proposed requirements to
validate the same.
• Requirements negotiation is always necessary to
resolve conflicts in requirements and remove
requirements overlaps. Negotiation involves
information
interchange,
discussion
and
resolution of disagreements.
October 9, 2023
Nabendu Chaki, University of Calcutta
7
A few more lines in summary…
• The requirements engineering process is a
structured set of activities which lead to the
production of a requirements document.
• Inputs to the requirements engineering process
are information about existing systems,
stakeholder needs, organizational standards,
regulations and domain information.
• Human, social and organizational factors are
important
influences
on
requirements
engineering processes.
October 9, 2023
8
Nabendu Chaki, University of Calcutta
A few more lines in summary…
• Requirements engineering process models are
simplified process description presented from a
particular perspective.
• Systems have multiple stakeholders with different
requirements.
October 9, 2023
Nabendu Chaki, University of Calcutta
9
Questions?
10
Requirements
Documentation
1
Requirements Document
• The requirements document is a formal
document used to communicate the
requirements to customers, engineers and
managers.
• The requirements document describes:
• The services and functions which the system
should provide
• The constraints under which the system
must operate
October 9, 2023
2
Nabendu Chaki, University of Calcutta
Users of Requirements Documents
• Customers
• specify the requirements and read them to
check they meet their needs
• Project managers
• Use the requirements document to plan a bid
for system and to plan the system
development process
• System engineers
• Use the requirements to understand the
system being developed
October 9, 2023
Nabendu Chaki, University of Calcutta
3
Users of Requirements Documents
• System test engineers
• Use the requirements to develop validation
tests for the system
• System maintenance engineers
• Use the requirements to help understand
the system
October 9, 2023
4
Nabendu Chaki, University of Calcutta
Requirements Document Structure
• IEEE/ANSI 830-1993 standard proposes a
structure for software requirements documents
• 1. Introduction
• 1.1 Purpose of requirements document
• 1.2 Scope of the product
• 1.3 Definitions, acronyms and abbreviations
• 1.4 References
• 1.5 Overview of remainder of the document
• 2. General description
• 2.1 Product perspective
October 9, 2023
Nabendu Chaki, University of Calcutta
5
Requirements Document Structure
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
Specific requirements
Covering functional, non-functional and
interface requirements.
• 4. Appendices
• Index
•
•
•
•
• 3.
•
October 9, 2023
6
Nabendu Chaki, University of Calcutta
Adapting the standard
• The IEEE standard is a generic standard which
is intended
apply to a wide range of
requirements documents.
• In general, not all parts of the standard are
required for all requirements documents
• Each organization should adapt the standard
depending on the type of systems it develops
• Consider a company (XYZ) that develops
scientific instruments
October 9, 2023
Nabendu Chaki, University of Calcutta
7
XYZ Organization Standard
• Preface
• This should define the expected readership
of the document and describe its version
history including a rationale for the creation
of a new version and a summary of the
changes made in each version.
• Introduction
• This should define the product in which the
software is embedded, its expected usage
and present and overview of the
functionality of the control software.
October 9, 2023
8
Nabendu Chaki, University of Calcutta
XYZ Organization Standard
• Glossary
• This should define all technical terms and
abbreviations used in the document.
• General user requirements
• This should define the system requirements
from the perspective of the user of the
system. These should be presented using a
mixture of natural language and diagrams.
October 9, 2023
Nabendu Chaki, University of Calcutta
9
XYZ Organization Standard
• System architecture
• This chapter should present a high-level
overview of the anticipated system
architecture showing the distribution of
functions
across
system
modules.
Architectural components which are to be
reused should be highlighted.
• Hardware specification
• This is an optional chapter specifying the
hardware that the software is expected to
control. It may be omitted if the standard
instrument platform is used.
October 9, 2023
10
Nabendu Chaki, University of Calcutta
XYZ Organization Standard
• Detailed software specification
• This is a detailed description of the
functionality expected of the software of
the system. It may include details of specific
algorithms which should be used for
computation. If a prototyping approach is
to be used for development on the standard
instrument platform, this chapter may be
omitted.
October 9, 2023
Nabendu Chaki, University of Calcutta
11
XYZ Organization Standard
• Reliability and performance requirements
• This chapter should describe the reliability
and performance requirements which are
expected of the system. These should be
related to the statement of user
requirements in Chapter 4.
October 9, 2023
12
Nabendu Chaki, University of Calcutta
XYZ Organization Standard
• The following appendices may be included
where appropriate:
• Hardware interface specification
• Software components which must be reused
in the system implementation
• Data structure specification
• Data-flow models of the software system
• Detailed object models of the software
system
• Index
October 9, 2023
Nabendu Chaki, University of Calcutta
13
Writing Requirements
• Requirements are usually written as paragraphs
of natural language text supplemented by
diagrams and equations
• Problems with requirements
• use of complex conditional clauses which
are confusing
• sloppy and inconsistent terminology
• writers assume readers have domain
knowledge
October 9, 2023
14
Nabendu Chaki, University of Calcutta
Writing Essentials
• Requirements are read more often than they are
written. You should invest time to write readable
and understandable requirements
• Do not assume that all readers of the
requirements have the same background and
use the same terminology as you
• Allow time for review, revision and re-drafting of
the requirements document
October 9, 2023
Nabendu Chaki, University of Calcutta
15
Writing Guidelines
• Define standard templates for describing
requirements
• Use language simply consistently and concisely
• Use diagrams appropriately
• Supplement natural language with other
description of requirements
• Specify requirements quantitatively
October 9, 2023
16
Nabendu Chaki, University of Calcutta
Formal Specification Language
• Syntax that defines the specific notation with
which the specification is represented
• Semantics that help to define a “universe of
objects” that will be used to describe the
system
• Relations which define the rules that indicate
which
objects
properly
satisfy
the
specification
October 9, 2023
Nabendu Chaki, University of Calcutta
17
Formal Specification Language
• The number of formal specification languages
in use today can be broadly divided into two
categories.
• Model-based notations
• Z and Vienna Development Method (VDM)
• Process algebras -based notations
• Communicating Sequential Processes
(CSP), CCS and LOTOS
October 9, 2023
18
Nabendu Chaki, University of Calcutta
Advantages of Formal Methods
• Removes ambiguity
• Encourages greater rigor in the early stages of
software engineering
• Possible to verify the correctness,
incompleteness and inconsistency checking of
the specification
October 9, 2023
Nabendu Chaki, University of Calcutta
19
Disadvantages of Formal Methods
• Difficult to represent behavioural aspects of
problem
• Some requirements can only be determined
through empirical evaluation and prototyping
• Do not address the problem of how the
requirements are constructed
• Lack of adequate tool support
October 9, 2023
20
Nabendu Chaki, University of Calcutta
Slow Acceptance of Formal Methods
• Formal methods are not widely used amongst
software developers
• Factors contributing to slow acceptance of
formal methods:
• Difficulty in understanding the notations
• Difficulty in formalising certain aspects of
requirements
• Payoff is not obvious.
October 9, 2023
Nabendu Chaki, University of Calcutta
21
Conclusions
• The requirements document is the definitive
specification of requirements for customers,
engineers and managers.
• The requirements document should include a
system overview, glossary, statement of the
functional requirements and the operational
constraints
October 9, 2023
22
Nabendu Chaki, University of Calcutta
Questions?
23
Requirements Validation
1
Validation objectives
• Certifies that the requirements document is an
acceptable description of the system to be
implemented
• Checks a requirements document for
• Completeness and consistency
• Conformance to standards
• Requirements conflicts
• Technical errors
• Ambiguous requirements
October 9, 2023
2
Nabendu Chaki, University of Calcutta
Analysis and Validation
• Analysis works with raw requirements as elicited
from the system stakeholders
• “Have we got the right requirements” is the
key question to be answered at this stage
• Validation works with a final draft of the
requirements document i.e., with negotiated
and agreed requirements
• “Have we got the requirements right” is the
key question to be answered at this stage
October 9, 2023
Nabendu Chaki, University of Calcutta
3
Validation Inputs and Outputs
Requirements
document
Organisational
knowledge
List of problems
Requ irements
validation
Organisational
standards
October 9, 2023
4
Nabendu Chaki, University of Calcutta
Agreed actions
Validation Inputs
• Requirements document
• Formatted and organized according to
organizational standards
• Organizational knowledge
• Knowledge, often implicit, of the
organization which may be used to judge
the realism of the requirements
• Organizational standards
• Local standards e.g., for the organization of
the requirements document
October 9, 2023
Nabendu Chaki, University of Calcutta
5
Validation Outputs
• Problem list
• List of discovered problems in the
requirements document
• Agreed actions
• List of agreed actions in response to
requirements problems. Some problems
may have several corrective actions; some
problems may have no associated actions
October 9, 2023
6
Nabendu Chaki, University of Calcutta
Requirements Reviews
• A group of people read and analyze the
requirements, look for problems, meet and
discuss the problems and agree on actions to
address these problems
October 9, 2023
Nabendu Chaki, University of Calcutta
7
Requirements Review Process
Plan review
Distribute
documents
Prepare for
review
Hold review
meeting
Follow-up
actions
October 9, 2023
8
Nabendu Chaki, University of Calcutta
Revise
document
Review Activities
• Plan review
• The review team is selected and a time and place
for the review meeting is chosen.
• Distribute documents
• The requirements document is distributed to the
review team members
• Prepare for review
• Individual reviewers read the requirements to
find conflicts, omissions, inconsistencies,
deviations from standards and other problems.
October 9, 2023
Nabendu Chaki, University of Calcutta
9
Review Activities
• Hold review meeting
• Individual comments and problems are
discussed and a set of actions to address the
problems is agreed.
• Follow-up actions
• The chair of the review checks that the
agreed actions have been carried out.
• Revise document
• The requirements document is revised to
reflect the agreed actions. At this stage, it
may be accepted, or it may be re-reviewed
October 9, 2023
10
Nabendu Chaki, University of Calcutta
Follow-up Actions
• Requirements clarification
• The requirement may be badly expressed or
may have accidentally omitted information
which has been collected during requirements
elicitation.
• Missing information
• Some information is missing from the
requirements document. It is the responsibility
of the requirements engineers who are revising
the document to discover this information from
system stakeholders.
October 9, 2023
Nabendu Chaki, University of Calcutta
11
Follow-up Actions
• Requirements conflict
• There is a significant conflict between
requirements. The stakeholders involved must
negotiate to resolve the conflict.
• Unrealistic requirement
• It does not appear that the requirement can be
implemented with the technology available or
given other constraints on the system.
Stakeholders must be consulted to decide how
to make the requirement more realistic.
October 9, 2023
12
Nabendu Chaki, University of Calcutta
Pre-review Checking
•
•
•
Reviews are expensive because they involve a
number of people spending time reading and
checking the requirements document
This expense can be reduced by using pre-review
checking where one person checks the document
and looks for straightforward problems such as
missing requirements, lack of conformance to
standards, typographical errors, etc.
Documents may be returned for correction, or the
list of problems distributed to other reviewers
October 9, 2023
Nabendu Chaki, University of Calcutta
13
Pre-review Checking
Check document
structure
Check
document
completeness
Check document
against
standards
Requirements
document
October 9, 2023
14
Run
automatic
checkers
Problem report
Nabendu Chaki, University of Calcutta
Review team Membership
• Reviews should involve a number of stakeholders
drawn from different backgrounds
• People from different backgrounds bring
different skills and knowledge to the review
• Stakeholders feel involved in the RE process
and develop an understanding of the needs
of other stakeholders
• Review team should always involve at least a
domain expert and an end-user
October 9, 2023
Nabendu Chaki, University of Calcutta
15
Review Checklist Questions
•
•
•
•
•
•
•
Is each requirement uniquely identified?
Are specialized terms defined in the glossary?
Does a requirement stand on its own or one has to see
other requirements to understand what it means?
Do requirements use the terms consistently?
Are there any contradictions in these requests?
If a requirement makes reference to some other facilities,
are these described within the document?
Are related requirements grouped together? If not, do
they refer to each other?
October 9, 2023
16
Nabendu Chaki, University of Calcutta
Prototyping
• Prototypes
for
requirements
validation
demonstrate the requirements and help
stakeholders discover problems
• Validation prototypes should be complete,
reasonably efficient and robust. It should be
possible to use them in the same way as the
required system
• User documentation and training should be
provided
October 9, 2023
Nabendu Chaki, University of Calcutta
17
User Manual Development
• Writing a user manual from the requirements
forces a detailed requirements analysis and thus
can reveal problems with the document
• Information in the user manual
• Description of the functionality and how it is
implemented
• Which parts of the system have not been
implemented
• How to get out of trouble
• How to install and get started with the
system
October 9, 2023
18
Nabendu Chaki, University of Calcutta
Key points
• Requirements validation should focus on
checking the final draft of the requirements
document for conflicts, omissions and deviations
from standards.
• Reviews involve a group of people making a
detailed analysis of the requirements.
• Review costs can be reduced by checking the
requirements before the review for deviations
from organizational standards. These may result
from more serious requirements problems.
October 9, 2023
Nabendu Chaki, University of Calcutta
19
Key points
• Checklists of what to look for may be used to
drive a requirements review process.
• Prototyping is effective for requirements
validation if a prototype has been developed
during the requirements elicitation stage.
• Writing a user manual is another method that
can reveal problems with the requirement
specification document.
October 9, 2023
20
Nabendu Chaki, University of Calcutta
Questions?
21
Non-functional
Requirements
1
Non-functional requirements (NFR)
• Non-functional requirements define the overall
qualities of the resulting system
• Non-functional requirements place constraints
on the product being developed, the
development process, and specify external
constraints that the product meet.
• Examples of NFR include safety, security,
usability,
reliability
and
performance
requirements.
October 9, 2023
2
Nabendu Chaki, University of Calcutta
NFRs in IEEE Standard 830-1993
• The ‘IEEE-Std 830 - 1993’ lists 13 non-functional
requirements to be included in a Software
Requirements Document.
• Performance requirements
• Interface requirements
• Operational requirements
• Resource requirements
• Verification requirements
October 9, 2023
Nabendu Chaki, University of Calcutta
3
NFRs in IEEE Standard 830-1993
• Acceptance requirements
• Documentation requirements
• Security requirements
• Portability requirements
• Quality requirements
• Reliability requirements
• Maintainability requirements
• Safety requirements
October 9, 2023
4
Nabendu Chaki, University of Calcutta
Classification of NFRs
• NFRs may be classified in terms of qualities that a
software must exhibit (Boehm)
Non-functional
requirements
Product requirements
Process
requirements
Usability requirements
Delivery
requirements
Reliability requirements
Implementation
requirements
Safety requirements
Efficiency requirements
Standards
requirements
External
requirements
Legal
constraints
Economic
constraints
Interoperability
requirements
Performance requirements
Capacity requirements
October 9, 2023
Nabendu Chaki, University of Calcutta
5
Some Important NFRs
• The principal non-functional constraints that are
relevant to critical systems:
• Reliability
• Performance
• Security
• Usability
• Safety
October 9, 2023
6
Nabendu Chaki, University of Calcutta
Reliability
• Constraints on the run-time behaviour of the
system
• Can be considered under two separate
headings:
• Availability - is the system available for
service when requested by end-users.
• Failure rate - how often does the system fail
to deliver the service expected by end-users.
October 9, 2023
Nabendu Chaki, University of Calcutta
7
Performance
• Constrain the speed of operation of a system
• Types of performance requirements:
• Response requirements
• Throughput requirements
• Timing requirements
October 9, 2023
8
Nabendu Chaki, University of Calcutta
Security
• Security requirements are included to ensure:
• Access to the system and its data by authorized
personnel only
• Integrity of the system from malicious damage
• The access permissions for system data may
only be changed by the system’s data
administrator
• All system data must be backed up every 24
hours and the backup copies stored in a
secure location different from the system’s
place
• All external communications must be
encrypted
October 9, 2023
Nabendu Chaki, University of Calcutta
9
Usability
• Concerned with specifying the user interface and
end-user interactions with the system
• Well structured user manuals, informative error
messages, help facilities and consistent interfaces
enhance usability
October 9, 2023
10
Nabendu Chaki, University of Calcutta
Safety
• Safety requirements are the ‘shall not’
requirements which exclude unsafe situations
from the possible solution space of the system
• The system shall not allow the sedative dose
to the patient to be greater than the
maximum value which is determined by the
patient’s physician
• The system shall not operate if the external
temperature is below 4 degrees Celsius
October 9, 2023
Nabendu Chaki, University of Calcutta
11
Users’ needs, Concerns and NFRs
Users’ need
Users’ Concerns
NFRs
Function
1. Ease of use
2. Unauthorized access
3. Likelihood of failure
1. Usability
2. Security
3. Reliability
Performance
1. Resource utilization
2. Performance verification
3. Ease of interfacing
1. Efficiency
2. Verifiability
3. Interoperability
Change
1.
2.
3.
4.
1.
2.
3.
4.
October 9, 2023
12
Ease of repair
Ease of change
Ease of transport!
Ease of expansion or
capacity/performance upgrade
Nabendu Chaki, University of Calcutta
Maintainability
Flexibility
Portability
Expandability
Testable NFRs
• Stakeholders may have vague goals which
cannot be expressed precisely
• Vague and imprecise ‘requirements’ are
problematic
• NFRs should satisfy two attributes
• Must be objective
• Must be testable (Use measurable metrics)
• It is quite challenging to always express NFRs
objectively
October 9, 2023
Nabendu Chaki, University of Calcutta
13
Conclusions
• Non-functional requirements define the overall
qualities or attributes of the resulting system
• Non-functional requirements may be classified
into three main types; product, process and
external requirements
• Product requirements specify the desired
characteristics that the system or subsystem must
posses
October 9, 2023
14
Nabendu Chaki, University of Calcutta
Conclusions
• Non-functional requirements tend to conflict and
interact with other system requirements
• The principal non-functional constraints which
are relevant to critical systems are reliability,
performance, security, usability and safety
October 9, 2023
Nabendu Chaki, University of Calcutta
15
Questions?
16
Software Design
Image Courtesy: Bright Innovation
1
Definition
Software Design is the practice of taking a
specification of externally observable behavior
and adding details needed for actual computer
system implementation, including human
interaction, task management, and data
management details.
Coad and Yourdon
October 9, 2023
2
Nabendu Chaki, University of Calcutta
Definition
Software Design is a process of inventing and
selecting programs that meet the objectives
for a software system.
Input includes an understanding of the
following:
1. Requirements
2. Environmental constraints
3. Design criteria
Stevens
October 9, 2023
Nabendu Chaki, University of Calcutta
3
Design Phase
October 9, 2023
4
Nabendu Chaki, University of Calcutta
Design Artifacts
• Modules
• Module Structure
• Control Relationship among the modules
• Interface among the modules
• Data Structures for individual modules
• Algorithms for individual modules
• Algorithm(s) for integration of modules
October 9, 2023
Nabendu Chaki, University of Calcutta
5
Task in Hand
• Design is an iterative process of transforming
the requirements specification into a design
specification.
• Software design is an iterative process through
which requirements are translated into a
“blueprint” for constructing the software.
• The design steps produce a data design, an
architectural design, an interface design and a
procedural design.
6
Types of Design
• The Architectural design or High-level design
defines the relationship between major
structural elements of the software, the
design patterns that can be used to achieve
the requirements and the constraints that
affect the implementation.
• The Interface design describes how the
software communicates within itself, and with
outside.
7
Types of Design
• The Procedural design elaborates structural
elements of the software into procedural
(algorithmic) description.
• The Data design defines the storage of data for
the product to be built.
8
Transition from Analysis to Design
9
Some Fundamental Concepts
• Stepwise Refinement
• Abstraction
• Software Architecture
• Program Structure
• Data Structure
• Modularity
10
Stepwise Refinement
• Stepwise Refinement is a top-down approach
where a program is refined as a hierarchy of
increasing levels of detail.
• This process may start during requirements
analysis and conclude when the detail of the
design is sufficient for conversion into code.
• Processing procedures and data structures are
likely to be refined at tandem.
11
Abstraction
• Abstraction is a means of describing a program
function, at an appropriate level of detail.
• Highest level of abstraction – requirement
analysis.
• Lowest level of abstraction – programming.
12
Structured Design
Abstraction: "A view of a problem that extracts
the essential information relevant to a particular
purpose and ignores the remainder of the
information."
Information Hiding: “...every module is
characterized by its knowledge of a design
decision, which it hides from all others. Its
interface or definition was chosen to reveal as
little as possible about its inner workings."
13
Structured Design
• Difference between abstraction and information
hiding is that abstraction is a technique used to
help identify which information is to be hidden.
• Encapsulation refers to building a capsule
around some collection of things. Programming
languages have long supported encapsulation.
• As for example, subprograms (e.g., procedures,
functions, and subroutines), arrays, and record
structures
are
common
examples
of
encapsulation.
14
Software Architecture
• While refinement is about the level of details,
architecture is about structure.
• The architecture of the procedural and data
elements of a design represents a software
solution for the real-world problem defined by
the requirement analysis.
• It is unlikely that there will be one obvious
candidate architecture.
15
Some Fundamental Concepts
• Stepwise Refinement
• Abstraction
• Software Architecture
• Program Structure
• Data Structure
• Modularity
16
Program Structure
• Control hierarchy represents organization of
modules and their association
• Control hierarchy is also referred as Program
Structure, i.e., Program structure represents
the hierarchy of control.
• Program structure is usually expressed as a
simple hierarchy showing super-ordinate and
subordinate relationships of modules.
17
Control Hierarchy
18
Characteristics of Program Structure
• Depth
–
Number of levels control
• Width
–
Overall span of control
• Fan-in
–
–
Indicates number of modules that directly
invokes a given module
High fan-in implies greater reuse of modules
• Fan-out
–
A measure of the number of modules directly
controlled by the given module
19
Fan-in and Fan-out
M1
Fan in 1
Fan out 3
M2
M4
20
M3
M5
Fan in 2
Fan out 0
M6
Good and Bad Decomposition
21
Structure Chart
• One of the most common notation for
Program Structure representation is a tree-like
structure, called Structure Chart.
• A chart is a graphical representation of data, in
which data is represented by symbols, such as,
lines in a line chart, or slices in a pie chart.
• Structure
Chart
has
three
primary
components: modules, connections between
modules, and communication between
modules.
October 9, 2023
22
Nabendu Chaki, University of Calcutta
Structure Chart for a Subscription System
October 9, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: RFFlow
23
Structure Chart
• Modules are represented by rectangular
boxes, annotated with the name of the
module.
• A connection arrow between two modules
implies the direction in which control is passed
during the execution from one module to the
other.
• A dataflow (communication) arrow by the side
of the connection arrows implies passing of
data.
October 9, 2023
24
Nabendu Chaki, University of Calcutta
Structure Chart for a Subscription System
October 9, 2023
Nabendu Chaki, University of Calcutta
Image Courtesy: ResearchGate
25
Structure Chart
• There is only one module at the top, called,
the route module.
• There is at most one control relationship
between any two modules.
– if module A invokes module B.
– module B cannot invoke module A.
• The main reason behind this restriction
– Modules in a Structure Chart are to be
arranged in layers or levels.
October 9, 2023
26
Nabendu Chaki, University of Calcutta
Structure Chart
• The principle of abstraction does not allow
lower-level modules to invoke higher-level
modules.
• At the same time, the two higher-level
modules can invoke the same lower-level
module.
October 9, 2023
Nabendu Chaki, University of Calcutta
27
Structure Chart for a Subscription System
October 9, 2023
28
Nabendu Chaki, University of Calcutta
Image Courtesy: ResearchGate
More Structure Chart Artifacts
• Library Modules represent frequently evoked
modules and is denoted by a rectangle with
double side edges.
Count Total
Collection
• The diamond symbol (selection) implies that
one of the several modules connected to the
diamond is invoked based on the predicate.
Payment
Cash
October 9, 2023
Credit Card
QR code
Nabendu Chaki, University of Calcutta
29
More Structure Chart Artifacts
• A loop around control flow arrows implies that
the concerned modules are to be invoked
repeatedly
Procure
Indent
October 9, 2023
30
Order
Nabendu Chaki, University of Calcutta
Payment
Structure Chart versus Flow Chart
• A structure chart differs from a flow chart in
three principal ways:
• It is difficult to identify modules in a flow chart
representation – abstraction mission.
• Data independence among the modules are
not represented in a flow chart.
• Sequential ordering of tasks implied in a flow
chart is suppressed in a structure chart.
October 9, 2023
Nabendu Chaki, University of Calcutta
31
Data Structure
• Data Structure dictates the organization, access
methods, degree of associativity, and
processing alternatives for problem-related
information.
• Classic data structures include scalar,
sequential, linked-list, n-dimensional, and
hierarchical.
• Data structure, along with program structure,
makes up the software architecture.
32
Some Fundamental Concepts
• Stepwise Refinement
• Abstraction
• Software Architecture
• Program Structure
• Data Structure
• Modularity
33
Modularity
• Modularity derives from the architecture.
• Modularity is a logical partitioning of the
software design that allows complex software
to be manageable for purposes of
implementation and maintenance.
• The logic of partitioning is based on related
functions, implementation considerations, data
links, or other criteria.
• Modularity does imply interface overhead
related to information exchange between
modules and execution of modules.
34
Cohesion and Coupling
• Cohesion is a measure of the functional
strength of a module.
• A cohesive module performs a single task or
function.
• Coupling between two modules is a measure
of the degree of interdependence or interaction
between the two modules.
• A module with high cohesion and low coupling
is functionally independent of other modules,
with minimum interaction with other modules.
35
Functional Independence
• Reduces complexity of design.
• Provides better understandability
–
Different modules are easily understood in
isolation.
• Reduces error propagation.
–
As degree of interaction between modules is low,
an error in one module does not directly affect
other modules.
• Improves reusability of modules.
–
36
A functionally independent module can be easily
taken out and reused in a different program.
Measuring Functional Independence
• Unfortunately, there are no ways to
quantitatively measure the degree of cohesion
and coupling
• Classification of different kinds of cohesion and
coupling will give us some idea regarding the
degree of cohesiveness of a module.
37
Degree of Cohesion
Functional
Sequential
Communicational
Procedural
Temporal
Logical
Coincidental
38
Coincidental Cohesion
• The module performs a set of tasks that relate
to each other very loosely, if at all.
• The module contains a random collection of
functions.
• Functions have been put in the module out of
pure coincidence without any thought or
design.
39
Logical Cohesion
• All elements of the module perform similar
operations,
– e.g., error handling, data input, data
output, etc.
• An example of logical cohesion a set of print
functions to generate an output report
arranged into a single module.
40
Temporal Cohesion
• All tasks in the module are related in the sense
that all the tasks are executed in the same
time spam.
• An example of temporal cohesion is a set of
functions responsible for initialization / startup / shut-down, etc.
41
Procedural Cohesion
• Procedural cohesion occurs when the set of
functions of the module are all part of a
procedure (algorithm).
• Certain sequence of steps are to be carried
out in a certain order for achieving a specific
objective.
• An example of procedural cohesion is an
algorithm for decoding a string.
42
Communicational Cohesion
• Communicational cohesion occurs when the
set of functions of the module reference or
update the same data structure.
• An example of communicational cohesion
could be the set of functions defined on an
array or a stack.
43
Sequential Cohesion
• Sequential cohesion occurs when the
elements of the module form different parts
of a sequence.
• An output from one element of the sequence
is input to the next one.
• An example of sequential cohesion:
Sort  Search  Display result
44
Functional Cohesion
• Functional cohesion occurs when different
elements of the module cooperate to achieve
a single functionality.
• When a module displays functional cohesion,
one can describe the function using a single
simple sentence.
• An example of functional cohesion is a module
that manages employees’ pay-roll.
45
Determining Cohesiveness
Write down a sentence to describe the function
of the module.
• If the sentence is compound:
– module
has
a
sequential
or
communicational cohesion.
• If it has words like first, next, after, or then,
etc.:
– module has a sequential or temporal
cohesion.
• If it has words like initialize:
– module probably has temporal cohesion.
46
Degree of Coupling
• Coupling indicates how closely two modules
interact or how interdependent they are.
• The degree of coupling between two modules
depends on their interface complexity.
• There are no ways to precisely determine
coupling between two modules.
• Classification of different types of coupling
helps to estimate the degree of coupling
between two modules.
47
Classification of Coupling
Data
Stamp
Control
Common
Content
48
Data Coupling
• Two modules are data coupled if they
communicate via a parameter which is an
elementary data item, e.g., an integer value, a
float, or a character, etc.
• The data item passed between the two
modules should be problem related and not to
be used for control purpose.
49
Stamp Coupling
• Two modules are stamp coupled if they
communicate via a composite data item, e.g.,
a structure in C language.
• In stamp coupling too, the data item passed
between the two modules should be problem
related and not to be used for control
purpose.
50
Control Coupling
• Two modules are control coupled if data from
one module is used to direct order of
instruction execution in the second module.
• An example on Control Coupling is to set a flag
in module A, that is tested, maybe for
executing portion of code in another module,
say B.
51
Common Coupling
• Two modules are common coupled if they
share some global data.
• If too many variables are declared globally,
then those can be accessed from any of the
modules in the program.
• This increases common coupling. Changes in
one module may affect functioning in another
module, making the design complex.
• Thus, identification of the exact scope of
variables for every individual module is
extremely important to avoid unnecessary
side effect due to common coupling.
52
Content Coupling
• Two modules are content coupled if they share
code, i.e., if branching from one module into
another module is planned!
• The degree of coupling as well as the
complexity of the design increases from data
coupling to content coupling.
53
Qualities of a Good Design
• Functional: Any design solution should work
and should be ready for implementation.
• Efficiency: Metrics include run time, response
time, throughput, memory usage, etc.
• Flexibility: Design needs to be modifiable in
the event of any changes in the requirements.
• Portability: The design needs to be ready for
implementation on multiple hardware and
software platform.
54
Qualities of a Good Design
• Reliability: It talks about the goodness of the
design - how it work successfully
– More important for real-time, mission
critical and on-line systems.
• Economy: This can be achieved by identifying
re-usable components.
• Usability: Usability is in terms of how the
interfaces are designed and how much time it
takes to master the system.
55
Tips to remember
• A good design process should not suffer from
tunnel vision
• A good design should be traceable to the
analysis model
• A good design should exhibit uniformity and
integration
• A good design should be structured to
accommodate change
• A good design should be assessed for quality
as it is being created
56
Questions?
57
Software Cost Estimation - I
Image Courtesy: Etsy
1
Guess to Estimate
Estimate
Educated guess
Guess
October 9, 2023
2
2
Basic Questions
•
•
•
•
How much calendar time is needed to complete
an activity?
What is the total cost of an activity?
How much effort is required to complete an
activity?
Project estimation and scheduling are interleaved
management activities.
October 9, 2023
3
3
Who is Mr. Right?
October 9, 2023
4
4
Successful Questions
30%
Precision
Simple
Trusted
Understanding
5
October 9, 2023
5
Who should do it?
Project manager
Technical manager
NO
YES
Software engineer
October 9, 2023
6
6
Consulting
estimator
Estimation Techniques
•
•
•
•
October 9, 2023
There is no simple way to make an accurate
estimate of the effort required to develop a
software system
Initial estimates are based on inadequate
information in a user requirements definition
The software may run on unfamiliar computers
or use new technology
The people in the project may be unknown.
7
7
Cost Estimation Models
•
•
•
•
•
October 9, 2023
8
Price-to-win
Top-down and Bottom-up approaches
Delphi Estimation Model
Analogy
Empirical Algorithmic Models
8
Cost Estimation Models
•
•
•
•
•
October 9, 2023
Each method has strengths and weaknesses.
Estimation should be based on several methods
If these do not return approximately the same
result, then you have insufficient information
available to make an estimate.
Some action should be taken to find out more in
order to make more accurate estimates.
Pricing to win is sometimes the only applicable
method.
9
9
Top-down and Bottom-Up Approaches
•
•
October 9, 2023
10
Top-down
• Start at the system level and assess the
overall system functionality and how this is
delivered through sub-systems.
Bottom-up
• Start at the component level and estimate
the effort required for each component.
Add these efforts to reach a final estimate.
10
Top-down Estimation
•
•
•
October 9, 2023
Usable without knowledge of the system
architecture and the components that might be
part of the system.
This takes into account costs such as integration,
configuration management and documentation.
It may lead to underestimating cost of solving
difficult low-level technical problems.
11
11
Bottom-up Estimation
•
•
•
October 9, 2023
12
This is usable when the architecture of the system
is known and components identified.
This can be an accurate method if the system has
been designed in detail.
It may underestimate the costs of system level
activities such as integration and documentation.
12
Price to Win Model
•
•
•
•
The project costs whatever the customer has to
spend on it.
Advantages:
• You get the contract.
Disadvantages:
• The probability that the customer gets the
system at a bargain price.
Costs do not accurately reflect the work required.
13
October 9, 2023
13
Price to Win Model
•
•
•
•
October 9, 2023
14
This approach may seem unethical and unbusiness like.
However, when detailed information is lacking it
may be the only appropriate strategy.
The project cost is agreed on the basis of an
outline proposal and the development is
constrained by that cost.
A detailed specification may be negotiated or an
evolutionary approach used for system
development.
14
Empirical Estimation Model
•
Cost is estimated as a mathematical function of
product, project and process attributes:
• Effort = A x SizeB x M
• A, B are constants; B in the exponent reflects
the disproportionate effort for large projects
and M is a multiplier reflecting product,
process and people attributes.
•
October 9, 2023
The most commonly used product attribute for
cost estimation is code size.
15
15
Estimation Accuracy
•
•
•
October 9, 2023
16
Size of a software can only be known accurately
after it is finished.
Several factors influence the final size
• Use of COTS and components;
• Programming language;
• Distribution of system.
As the development process progresses then
the size estimate becomes more accurate.
16
Estimation Uncertainty
4x
2x
x
Feasibility
Requirements
Design
Code
Delivery
0.5 x
0.2 5 x
17
October 9, 2023
17
Costing and Pricing
•
•
•
October 9, 2023
18
Estimates are made to discover the cost, to the
developer, of producing a software system.
There is not a simple relationship between the
development cost and the price charged to the
customer.
Broader organisational, economic, political and
business considerations influence the price
charged.
18
Software Productivity
•
•
October 9, 2023
It’s a measure of the rate at which individual
engineers involved in software development
produce
software
and
associated
documentation.
Essentially, we want to measure useful
functionality produced per time unit.
19
19
Productivity Measures
•
•
October 9, 2023
20
Size related measures based on some output
from the software process. This may be lines of
delivered source code, object code
instructions, etc.
Function-related measures based on an
estimate of the functionality of the delivered
software. Function-points are the best known
of this type of measure.
20
The COCOMO Model
•
•
•
An empirical model based on project
experience.
Well-documented, ‘independent’ model which
is not tied to a specific software vendor.
Long history from initial version published in
1981
(COCOMO-81)
through
various
instantiations to COCOMO 2.
21
October 9, 2023
21
The COCOMO Model
Modes of Development
Organic SemiEmbedded
detached
Level of model
Cost
2.4, 1.05
3.0, 1.12
3.6, 1.2
2.5, 0.38
2.5, 0.35
2.5, 0.32
Schedule
C  C1  C2    C15
???
LM  ??? KLOC  C
October 9, 2023
22
22
Range of C
0.09 - 9.42
Organic Project
•
•
•
•
•
•
October 9, 2023
Small size < 50,000 lines
Routine job – team members experienced in
application area
Non-stringent specifications of function,
performance, acceptance tests, interfaces
Minimal communication overhead
Stable development environment
Existing, proven technology
23
23
Organic Project: Example
•
•
•
Standard engineering, scientific and business
modeling systems
Simple inventory control systems
Simple production control systems
LM  2.4  KLOC
DT  2.5  LM
October 9, 2023
24
24
0.38
1.05
Semi-Detached Project
•
•
•
•
October 9, 2023
Large size – up to 300,000 lines
mix of experienced and non-experienced team
members
in application domain and
development environment
mix
of
stringent
and
non-stringent
specifications of function, performance,
acceptance tests, interfaces
moderate schedule pressure
25
25
Semi-Detached Project: Example
•
•
•
Standard transaction processing systems
DBMS applications
Simple command & control systems
LM  3.0  KLOC
DT  2.5  LM
October 9, 2023
26
26
0.35
1.12
Embedded Project
•
•
•
•
•
•
October 9, 2023
Small to large size – up to 1,000,000 lines
Stringent
specifications
of
function,
performance, acceptance tests, interfaces
Rigid, formal quality standards
Close coupling among hardware, software,
operators
Leading edge technology employed
Strong schedule pressure
27
27
Embedded Project: Example
•
•
•
•
•
Avionic software systems
Large and complex transaction processing
systems
Real-time systems
Operating systems
Complex firmware systems
LM  3.6  KLOC
DT  2.5  LM
October 9, 2023
28
28
0.32
1.20
Intermediate COCOMO Model
Product Attributes
VL L
N
.75 .88 1
C1 Reliability
C2 Database size
.94 1
C3 Complexity
.7 .85 1
H
VH
XH
1.15 1.4
1.08 1.16
1.15 1.3 1.65
29
October 9, 2023
29
Intermediate COCOMO Model
Computer Attributes
VL L
N
H
C4 Exec time
1
1.11 1.3
C5
1
1.06 1.21 1.56
C6
C7
October 9, 2023
30
const.
Storage
constr.
Virtual
machine volat.
Turnaround
30
VH
.87 1
1.15 1.3
.87 1
1.07 1.15
XH
1.66
Intermediate COCOMO Model
Personnel Attributes
VL
C8
C9
C10
C11
C12
Analyst
capability
Application
experience
Programmer
capability
Virtual machine
experience
Language
experience
L
N H
VH
1.46 1.19 1 .86 .71
1.29 1.13 1 .91 .82
1.42 1.17 1 .86 .7
1.21 1.1
1 .9
1.14 1.07 1 .95
31
October 9, 2023
31
Intermediate COCOMO Model
Project Attributes
VL L
N
C13 Modern program .75 .88 1
C14
C15
October 9, 2023
32
practice
Tools usage
Schedule
constraints
.7
32
.94 1
.85 1
H
VH
XH
1.15 1.4
1.08 1.16
1.15 1.3 1.65
33
34
Detailed COCOMO Model
Phase sensitive Effort Multipliers
•
•
•
•
Plans/requirements
Product design
Programming
Integration/test
Three-level Product Hierarchy
•
•
•
System, subsystem, module
35
October 9, 2023
35
Phase-Sensitive Distribution of Efforts
Nominal
manpower
cost
6%-8%
Plans/
requirements
16%-18%
Product
design
Programming 48%-68%
Integration
/test
October 9, 2023
36
16%-34%
36
Nominal
development
time
10%-40%
19%-38%
24%-64%
18%-34%
Measurement Problems
•
•
•
Estimating the size of the measure (e.g., how
many function points).
Estimating the total number of programmer
months elapsed.
Estimating contractor productivity (e.g.,
documentation team) and incorporating this
estimate in overall estimate.
37
October 9, 2023
37
Line of Code
•
What's a line of code?
•
•
•
•
October 9, 2023
38
This was first proposed when programs were
typed on cards with one line per card;
How does this correspond to statements as in Java
which can span several lines or where there can
be several statements on one line.
What programs should be counted as part of
the system?
This model assumes that there is a linear
relationship between system size and volume
of documentation.
38
Productivity Comparisons
•
The lower level of the language, the more
productive is the programmer
•
•
The same functionality takes more code to
implement in a lower-level language than in a
high-level language.
The more verbose the programmer, the higher
the productivity
•
Measures of productivity based on lines of code
suggest that programmers who write verbose
code are often more productive.
39
October 9, 2023
39
Function Points
•
•
October 9, 2023
40
FPs are estimated based on a combination of
program characteristics
• external inputs and outputs;
• user interactions;
• external interfaces;
• files used by the system.
The function point count is modified by
complexity of the project
40
Function Point
•
•
•
Some of the activities are more complex than
others.
Hence, a weight is associated with each of
these raw FPs
The function point count is computed by
multiplying each raw count by the weight and
summing all values.
41
October 9, 2023
41
Functions Points
•
•
•
Different individuals have diverse notions of
complexity.
Therefore, there are variations in FP count
based on the estimator’s judgement.
FPs are very subjective. They depend on the
estimator
•
October 9, 2023
42
Automatic function-point counting is impossible.
42
Object Points / Application Points
•
•
•
Object points (alternatively named application
points) are an alternative function-related
measure to function points when 4Gs or
similar languages are used for development.
Application points (Banker, Kauffman et al.
1994) are an alternative to function points.
Object points are NOT the same as object
classes.
43
October 9, 2023
43
Object Points
•
October 9, 2023
44
The number of object points in a program is a
weighted estimate of
• The number of separate screens that are
displayed;
• The number of reports that are produced
by the system;
• The number of program modules that
must be developed to supplement the
database code;
44
Object Point Estimations
Object points are easier to estimate from a
specification than function points as they are
simply concerned with screens, reports and
programming language modules.
They can therefore be estimated at a fairly early
point in the development process.
At this stage, it is very difficult to estimate the
number of lines of code in a system.
•
•
•
45
October 9, 2023
45
Productivity Estimations
Real-time embedded systems
•
•
Systems programs
•
•
•
200-900 KLOC/month
Using object points,
•
•
46
150-400 KLOC/month
Commercial applications
•
October 9, 2023
40-160 KLOC/month
productivity has been measured between 4 and
50 object points/month depending on tool
support and developer capability
46
Questions?
47
IEEE Std 830-1998
(Revision of
IEEE Std 830-1993)
IEEE Recommended Practice for
Software Requirements
SpeciÞcations
Sponsor
Software Engineering Standards Committee
of the
IEEE Computer Society
Approved 25 June 1998
IEEE-SA Standards Board
Abstract: The content and qualities of a good software requirements specification (SRS) are described and several sample SRS outlines are presented. This recommended practice is aimed at
specifying requirements of software to be developed but also can be applied to assist in the selection of in-house and commercial software products. Guidelines for compliance with IEEE/EIA
12207.1-1997 are also provided.
Keywords: contract, customer, prototyping, software requirements specification, supplier, system
requirements specifications
The Institute of Electrical and Electronics Engineers, Inc.
345 East 47th Street, New York, NY 10017-2394, USA
Copyright © 1998 by the Institute of Electrical and Electronics Engineers, Inc.
All rights reserved. Published 1998. Printed in the United States of America.
Print:
ISBN 0-7381-0332-2, SH94654
ISBN 0-7381-0332-2
PDF: ISBN 0-7381-0448-5, SS94654
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
written permission of the publisher.
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board. Members of the
committees serve voluntarily and without compensation. They are not necessarily members of the
Institute. The standards developed within IEEE represent a consensus of the broad expertise on the
subject within the Institute as well as those activities outside of IEEE that have expressed an interest in participating in the development of the standard.
Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply
that there are no other ways to produce, test, measure, purchase, market, or provide other goods and
services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the
time a standard is approved and issued is subject to change brought about through developments in
the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every Þve years for revision or reafÞrmation. When a document is more
than Þve years old and has not been reafÞrmed, it is reasonable to conclude that its contents,
although still of some value, do not wholly reßect the present state of the art. Users are cautioned to
check to determine that they have the latest edition of any IEEE Standard.
Comments for revision of IEEE Standards are welcome from any interested party, regardless of
membership afÞliation with IEEE. Suggestions for changes in documents should be in the form of a
proposed change of text, together with appropriate supporting comments.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as
they relate to speciÞc applications. When the need for interpretations is brought to the attention of
IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of all concerned interests, it is important to ensure that any interpretation has
also received the concurrence of a balance of interests. For this reason, IEEE and the members of its
societies and Standards Coordinating Committees are not able to provide an instant response to
interpretation requests except in those cases where the matter has previously received formal
consideration.
Comments on standards and requests for interpretations should be addressed to:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
USA
Note: Attention is called to the possibility that implementation of this standard may
require use of subject matter covered by patent rights. By publication of this standard,
no position is taken with respect to the existence or validity of any patent rights in
connection therewith. The IEEE shall not be responsible for identifying patents for
which a license may be required by an IEEE standard or for conducting inquiries into
the legal validity or scope of those patents that are brought to its attention.
Authorization to photocopy portions of any individual standard for internal or personal use is
granted by the Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate
fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact
Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA;
(978) 750-8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center.
Introduction
(This introduction is not a part of IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements SpeciÞcations.)
This recommended practice describes recommended approaches for the speciÞcation of software requirements. It is based on a model in which the result of the software requirements speciÞcation process is an
unambiguous and complete speciÞcation document. It should help
a)
b)
c)
Software customers to accurately describe what they wish to obtain;
Software suppliers to understand exactly what the customer wants;
Individuals to accomplish the following goals:
1) Develop a standard software requirements speciÞcation (SRS) outline for their own organizations;
2) DeÞne the format and content of their speciÞc software requirements speciÞcations;
3) Develop additional local supporting items such as an SRS quality checklist, or an SRS writerÕs
handbook.
To the customers, suppliers, and other individuals, a good SRS should provide several speciÞc beneÞts, such
as the following:
Ñ
Establish the basis for agreement between the customers and the suppliers on what the software
product is to do. The complete description of the functions to be performed by the software speciÞed
in the SRS will assist the potential users to determine if the software speciÞed meets their needs or
how the software must be modiÞed to meet their needs.
Ñ
Reduce the development effort. The preparation of the SRS forces the various concerned groups in
the customerÕs organization to consider rigorously all of the requirements before design begins and
reduces later redesign, recoding, and retesting. Careful review of the requirements in the SRS can
reveal omissions, misunderstandings, and inconsistencies early in the development cycle when these
problems are easier to correct.
Ñ
Provide a basis for estimating costs and schedules. The description of the product to be developed as
given in the SRS is a realistic basis for estimating project costs and can be used to obtain approval for
bids or price estimates.
Ñ
Provide a baseline for validation and veriÞcation. Organizations can develop their validation and
veriÞcation plans much more productively from a good SRS. As a part of the development contract,
the SRS provides a baseline against which compliance can be measured.
Ñ
Facilitate transfer. The SRS makes it easier to transfer the software product to new users or new
machines. Customers thus Þnd it easier to transfer the software to other parts of their organization,
and suppliers Þnd it easier to transfer it to new customers.
Ñ
Serve as a basis for enhancement. Because the SRS discusses the product but not the project that
developed it, the SRS serves as a basis for later enhancement of the Þnished product. The SRS may
need to be altered, but it does provide a foundation for continued production evaluation.
The readers of this document are referred to Annex B for guidelines for using this recommended practice to
meet the requirements of IEEE/EIA 12207.1-1997, IEEE/EIA GuideÑIndustry Implementation of ISO/IEC
12207: 1995, Standard for Information TechnologyÑSoftware life cycle processesÑLife cycle data.
Copyright © 1998 IEEE. All rights reserved.
iii
Participants
This recommended practice was prepared by the Life Cycle Data Harmonization Working Group of the Software Engineering Standards Committee of the IEEE Computer Society. At the time this recommended practice was approved, the working group consisted of the following members:
Leonard L. Tripp, Chair
Edward Byrne
Paul R. Croll
Perry DeWeese
Robin Fralick
Marilyn Ginsberg-Finner
John Harauz
Mark Henley
Dennis Lawrence
David Maibor
Ray Milovanovic
James Moore
Timothy Niesen
Dennis Rilling
Terry Rout
Richard Schmidt
Norman F. Schneidewind
David Schultz
Basil Sherlund
Peter Voldner
Ronald Wade
The following persons were on the balloting committee:
Syed Ali
Theodore K. Atchinson
Mikhail Auguston
Robert E. Barry
Leo Beltracchi
H. Ronald Berlack
Richard E. Biehl
Michael A. Blackledge
Sandro Bologna
Juris Borzovs
Kathleen L. Briggs
M. Scott Buck
Michael Caldwell
James E. Cardow
Enrico A. Carrara
Lawrence Catchpole
Keith Chan
Antonio M. Cicu
Theo Clarke
Sylvain Clermont
Rosemary Coleman
Virgil Lee Cooper
W. W. Geoff Cozens
Paul R. Croll
Gregory T. Daich
Geoffrey Darnton
Taz Daughtrey
Bostjan K. Derganc
Perry R. DeWeese
James Do
Evelyn S. Dow
Carl Einar Dragstedt
Sherman Eagles
Christof Ebert
Leo Egan
Richard E. Fairley
John W. Fendrich
Jay Forster
Kirby Fortenberry
Eva Freund
Richard C. Fries
Roger U. Fujii
Adel N. Ghannam
Marilyn Ginsberg-Finner
John Garth Glynn
Julio Gonzalez-Sanz
L. M. Gunther
iv
David A. Gustafson
Jon D. Hagar
John Harauz
Robert T. Harley
Herbert Hecht
William Heßey
Manfred Hein
Mark Heinrich
Mark Henley
Debra Herrmann
John W. Horch
Jerry Huller
Peter L. Hung
George Jackelen
Frank V. Jorgensen
William S. Junk
George X. Kambic
Richard Karcich
Ron S. Kenett
Judith S. Kerner
Robert J. Kierzyk
Dwayne L. Knirk
Shaye Koenig
Thomas M. Kurihara
John B. Lane
J. Dennis Lawrence
Fang Ching Lim
William M. Lively
James J. Longbucco
Dieter Look
John Lord
Stan Magee
David Maibor
Harold Mains
Robert A. Martin
Tomoo Matsubara
Mike McAndrew
Patrick D. McCray
Christopher McMacken
Jerome W. Mersky
Bret Michael
Alan Miller
Celia H. Modell
James W. Moore
Pavol Navrat
Myrna L. Olson
Indradeb P. Pal
Alex Polack
Peter T. Poon
Lawrence S. Przybylski
Kenneth R. Ptack
Annette D. Reilly
Dennis Rilling
Andrew P. Sage
Helmut Sandmayr
Stephen R. Schach
Hans Schaefer
Norman Schneidewind
David J. Schultz
Lisa A. Selmon
Robert W. Shillato
David M. Siefert
Carl A. Singer
James M. Sivak
Richard S. Sky
Nancy M. Smith
Melford E. Smyre
Harry M. Sneed
Alfred R. Sorkowitz
Donald W. Sova
Luca Spotorno
Julia Stesney
Fred J. Strauss
Christine Brown Strysik
Toru Takeshita
Richard H. Thayer
Booker Thomas
Patricia Trellue
Theodore J. Urbanowicz
Glenn D. Venables
Udo Voges
David D. Walden
Dolores Wallace
William M. Walsh
John W. Walz
Camille SWhite-Partain
Scott A. Whitmire
P. A. Wolfgang
Paul R. Work
Natalie C. Yopconka
Janusz Zalewski
Geraldine Zimmerman
Peter F. Zoll
Copyright © 1998 IEEE. All rights reserved.
When the IEEE-SA Standards Board approved this recommended practice on 25 June 1998, it had the following membership:
Richard J. Holleman, Chair
Satish K. Aggarwal
Clyde R. Camp
James T. Carlo
Gary R. Engmann
Harold E. Epstein
Jay Forster*
Thomas F. Garrity
Ruben D. Garzon
Donald N. Heirman, Vice Chair
Judith Gorman, Secretary
James H. Gurney
Jim D. Isaak
Lowell G. Johnson
Robert Kennelly
E. G. ÒAlÓ Kiener
Joseph L. KoepÞnger*
Stephen R. Lambert
Jim Logothetis
Donald C. Loughry
L. Bruce McClung
Louis-Fran•ois Pau
Ronald C. Petersen
Gerald H. Peterson
John B. Posey
Gary S. Robinson
Hans E. Weinrich
Donald W. Zipse
*Member Emeritus
Valerie E. Zelenty
IEEE Standards Project Editor
Copyright © 1998 IEEE. All rights reserved.
v
Contents
1.
Overview.............................................................................................................................................. 1
1.1 Scope............................................................................................................................................ 1
2.
References............................................................................................................................................ 2
3.
Definitions............................................................................................................................................ 2
4.
Considerations for producing a good SRS........................................................................................... 3
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
5.
Nature of the SRS ........................................................................................................................ 3
Environment of the SRS .............................................................................................................. 3
Characteristics of a good SRS...................................................................................................... 4
Joint preparation of the SRS ........................................................................................................ 8
SRS evolution .............................................................................................................................. 8
Prototyping................................................................................................................................... 9
Embedding design in the SRS...................................................................................................... 9
Embedding project requirements in the SRS ............................................................................. 10
The parts of an SRS ........................................................................................................................... 10
5.1
5.2
5.3
5.4
Introduction (Section 1 of the SRS)........................................................................................... 11
Overall description (Section 2 of the SRS)................................................................................ 12
Specific requirements (Section 3 of the SRS)............................................................................ 15
Supporting information.............................................................................................................. 19
Annex A (informative) SRS templates........................................................................................................ 21
Annex B (informative) Guidelines for compliance with IEEE/EIA 12207.1-1997.................................... 27
vi
Copyright © 1998 IEEE. All rights reserved.
IEEE Recommended Practice for
Software Requirements
SpeciÞcations
1. Overview
This recommended practice describes recommended approaches for the speciÞcation of software requirements. It is divided into Þve clauses. Clause 1 explains the scope of this recommended practice. Clause 2
lists the references made to other standards. Clause 3 provides deÞnitions of speciÞc terms used. Clause 4
provides background information for writing a good SRS. Clause 5 discusses each of the essential parts of
an SRS. This recommended practice also has two annexes, one which provides alternate format templates,
and one which provides guidelines for compliance with IEEE/EIA 12207.1-1997.
1.1 Scope
This is a recommended practice for writing software requirements speciÞcations. It describes the content
and qualities of a good software requirements speciÞcation (SRS) and presents several sample SRS outlines.
This recommended practice is aimed at specifying requirements of software to be developed but also can be
applied to assist in the selection of in-house and commercial software products. However, application to
already-developed software could be counterproductive.
When software is embedded in some larger system, such as medical equipment, then issues beyond those
identiÞed in this recommended practice may have to be addressed.
This recommended practice describes the process of creating a product and the content of the product. The
product is an SRS. This recommended practice can be used to create such an SRS directly or can be used as
a model for a more speciÞc standard.
This recommended practice does not identify any speciÞc method, nomenclature, or tool for preparing an
SRS.
Copyright © 1998 IEEE. All rights reserved.
1
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
2. References
This recommended practice shall be used in conjunction with the following publications.
ASTM E1340-96, Standard Guide for Rapid Prototyping of Computerized Systems.1
IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.2
IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans.
IEEE Std 730.1-1995, IEEE Guide for Software Quality Assurance Planning.
IEEE Std 828-1998, IEEE Standard for Software ConÞguration Management Plans.3
IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software.
IEEE Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software.
IEEE Std 1002-1987 (Reaff 1992), IEEE Standard Taxonomy for Software Engineering Standards.
IEEE Std 1012-1998, IEEE Standard for Software VeriÞcation and Validation.
IEEE Std 1012a-1998, IEEE Standard for Software VeriÞcation and Validation: Content Map to IEEE/EIA
12207.1-1997.4
IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions.5
IEEE Std 1028-1997, IEEE Standard for Software Reviews.
IEEE Std 1042-1987 (Reaff 1993), IEEE Guide to Software ConÞguration Management.
IEEE P1058/D2.1, Draft Standard for Software Project Management Plans, dated 5 August 1998.6
IEEE Std 1058a-1998, IEEE Standard for Software Project Management Plans: Content Map to IEEE/EIA
12207.1-1997.7
IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes.
IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System Requirements SpeciÞcations.8
1ASTM
publications are available from the American Society for Testing and Materials, 100 Barr Harbor Drive, West Conshohocken,
PA 19428-2959, USA.
2IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway,
NJ 08855-1331, USA.
3As this standard goes to press, IEEE Std 828-1998; IEEE Std 1012a-1998; IEEE Std 1016-1998; and IEEE Std 1233, 1998 Edition are
approved but not yet published. The draft standards are, however, available from the IEEE. Anticipated publication date is Fall 1998.
Contact the IEEE Standards Department at 1 (732) 562-3800 for status information.
4See Footnote 3.
5See Footnote 3.
6Upon approval of IEEE P1058 by the IEEE-SA Standards Board, this standard will be integrated with IEEE Std 1058a-1998 and
published as IEEE Std 1058, 1998 Edition. Approval is expected 8 December 1998.
7As this standard goes to press, IEEE Std 1058a-1998 is approved but not yet published. The draft standard is, however, available from
the IEEE. Anticipated publication date is December 1998. Contact the IEEE Standards Department at 1 (732) 562-3800 for status
information. See Footnote 6.
8See Footnote 3.
2
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
IEEE
Std 830-1998
3. DeÞnitions
In general the deÞnitions of terms used in this recommended practice conform to the deÞnitions provided in
IEEE Std 610.12-1990. The deÞnitions below are key terms as they are used in this recommended practice.
3.1 contract: A legally binding document agreed upon by the customer and supplier. This includes the technical and organizational requirements, cost, and schedule for a product. A contract may also contain informal but useful information such as the commitments or expectations of the parties involved.
3.2 customer: The person, or persons, who pay for the product and usually (but not necessarily) decide the
requirements. In the context of this recommended practice the customer and the supplier may be members of
the same organization.
3.3 supplier: The person, or persons, who produce a product for a customer. In the context of this recommended practice, the customer and the supplier may be members of the same organization.
3.4 user: The person, or persons, who operate or interact directly with the product. The user(s) and the
customer(s) are often not the same person(s).
4. Considerations for producing a good SRS
This clause provides background information that should be considered when writing an SRS. This includes
the following:
a)
b)
c)
d)
e)
f)
g)
h)
Nature of the SRS;
Environment of the SRS;
Characteristics of a good SRS;
Joint preparation of the SRS;
SRS evolution;
Prototyping;
Embedding design in the SRS;
Embedding project requirements in the SRS.
4.1 Nature of the SRS
The SRS is a speciÞcation for a particular software product, program, or set of programs that performs
certain functions in a speciÞc environment. The SRS may be written by one or more representatives of the
supplier, one or more representatives of the customer, or by both. Subclause 4.4 recommends both.
The basic issues that the SRS writer(s) shall address are the following:
a)
b)
c)
d)
e)
Functionality. What is the software supposed to do?
External interfaces. How does the software interact with people, the systemÕs hardware, other hardware, and other software?
Performance. What is the speed, availability, response time, recovery time of various software functions, etc.?
Attributes. What are the portability, correctness, maintainability, security, etc. considerations?
Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?
The SRS writer(s) should avoid placing either design or project requirements in the SRS.
For recommended contents of an SRS see Clause 5.
Copyright © 1998 IEEE. All rights reserved.
3
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
4.2 Environment of the SRS
It is important to consider the part that the SRS plays in the total project plan, which is deÞned in IEEE Std
610.12-1990. The software may contain essentially all the functionality of the project or it may be part of a
larger system. In the latter case typically there will be an SRS that will state the interfaces between the
system and its software portion, and will place external performance and functionality requirements upon
the software portion. Of course the SRS should then agree with and expand upon these system requirements.
IEEE Std 1074-1997 describes the steps in the software life cycle and the applicable inputs for each step.
Other standards, such as those listed in Clause 2, relate to other parts of the software life cycle and so may
complement software requirements.
Since the SRS has a speciÞc role to play in the software development process, the SRS writer(s) should be
careful not to go beyond the bounds of that role. This means the SRS
a)
Should correctly deÞne all of the software requirements. A software requirement may exist because
of the nature of the task to be solved or because of a special characteristic of the project.
b)
Should not describe any design or implementation details. These should be described in the design
stage of the project.
Should not impose additional constraints on the software. These are properly speciÞed in other
documents such as a software quality assurance plan.
c)
Therefore, a properly written SRS limits the range of valid designs, but does not specify any particular
design.
4.3 Characteristics of a good SRS
An SRS should be
a)
b)
c)
d)
e)
f)
g)
h)
Correct;
Unambiguous;
Complete;
Consistent;
Ranked for importance and/or stability;
VeriÞable;
ModiÞable;
Traceable.
4.3.1 Correct
An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet.
There is no tool or procedure that ensures correctness. The SRS should be compared with any applicable
superior speciÞcation, such as a system requirements speciÞcation, with other project documentation, and
with other applicable standards, to ensure that it agrees. Alternatively the customer or user can determine if
the SRS correctly reßects the actual needs. Traceability makes this procedure easier and less prone to error
(see 4.3.8).
4.3.2 Unambiguous
An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. As a
minimum, this requires that each characteristic of the Þnal product be described using a single unique term.
4
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
IEEE
Std 830-1998
In cases where a term used in a particular context could have multiple meanings, the term should be included
in a glossary where its meaning is made more speciÞc.
An SRS is an important part of the requirements process of the software life cycle and is used in design,
implementation, project monitoring, veriÞcation and validation, and in training as described in IEEE Std
1074-1997. The SRS should be unambiguous both to those who create it and to those who use it. However,
these groups often do not have the same background and therefore do not tend to describe software requirements the same way. Representations that improve the requirements speciÞcation for the developer may be
counterproductive in that they diminish understanding to the user and vice versa.
Subclauses 4.3.2.1 through 4.3.2.3 recommend how to avoid ambiguity.
4.3.2.1 Natural language pitfalls
Requirements are often written in natural language (e.g., English). Natural language is inherently ambiguous. A natural language SRS should be reviewed by an independent party to identify ambiguous use of
language so that it can be corrected.
4.3.2.2 Requirements speciÞcation languages
One way to avoid the ambiguity inherent in natural language is to write the SRS in a particular requirements
speciÞcation language. Its language processors automatically detect many lexical, syntactic, and semantic
errors.
One disadvantage in the use of such languages is the length of time required to learn them. Also, many nontechnical users Þnd them unintelligible. Moreover, these languages tend to be better at expressing certain
types of requirements and addressing certain types of systems. Thus, they may inßuence the requirements in
subtle ways.
4.3.2.3 Representation tools
In general, requirements methods and languages and the tools that support them fall into three general categoriesÑobject, process, and behavioral. Object-oriented approaches organize the requirements in terms of
real-world objects, their attributes, and the services performed by those objects. Process-based approaches
organize the requirements into hierarchies of functions that communicate via data ßows. Behavioral
approaches describe external behavior of the system in terms of some abstract notion (such as predicate
calculus), mathematical functions, or state machines.
The degree to which such tools and methods may be useful in preparing an SRS depends upon the size and
complexity of the program. No attempt is made here to describe or endorse any particular tool.
When using any of these approaches it is best to retain the natural language descriptions. That way, customers unfamiliar with the notations can still understand the SRS.
4.3.3 Complete
An SRS is complete if, and only if, it includes the following elements:
a)
All signiÞcant requirements, whether relating to functionality, performance, design constraints,
attributes, or external interfaces. In particular any external requirements imposed by a system speciÞcation should be acknowledged and treated.
Copyright © 1998 IEEE. All rights reserved.
5
IEEE
Std 830-1998
b)
c)
IEEE RECOMMENDED PRACTICE FOR
DeÞnition of the responses of the software to all realizable classes of input data in all realizable
classes of situations. Note that it is important to specify the responses to both valid and invalid input
values.
Full labels and references to all Þgures, tables, and diagrams in the SRS and deÞnition of all terms
and units of measure.
4.3.3.1 Use of TBDs
Any SRS that uses the phrase Òto be determinedÓ (TBD) is not a complete SRS. The TBD is, however, occasionally necessary and should be accompanied by
a)
b)
A description of the conditions causing the TBD (e.g., why an answer is not known) so that the situation can be resolved;
A description of what must be done to eliminate the TBD, who is responsible for its elimination, and
by when it must be eliminated.
4.3.4 Consistent
Consistency refers to internal consistency. If an SRS does not agree with some higher-level document, such
as a system requirements speciÞcation, then it is not correct (see 4.3.1).
4.3.4.1 Internal consistency
An SRS is internally consistent if, and only if, no subset of individual requirements described in it conßict.
The three types of likely conßicts in an SRS are as follows:
a)
b)
c)
The speciÞed characteristics of real-world objects may conßict. For example,
1) The format of an output report may be described in one requirement as tabular but in another as
textual.
2) One requirement may state that all lights shall be green while another may state that all lights
shall be blue.
There may be logical or temporal conßict between two speciÞed actions. For example,
1) One requirement may specify that the program will add two inputs and another may specify
that the program will multiply them.
2) One requirement may state that ÒAÓ must always follow ÒB,Ó while another may require that ÒA
and BÓ occur simultaneously.
Two or more requirements may describe the same real-world object but use different terms for that
object. For example, a programÕs request for a user input may be called a ÒpromptÓ in one requirement and a ÒcueÓ in another. The use of standard terminology and deÞnitions promotes consistency.
4.3.5 Ranked for importance and/or stability
An SRS is ranked for importance and/or stability if each requirement in it has an identiÞer to indicate either
the importance or stability of that particular requirement.
Typically, all of the requirements that relate to a software product are not equally important. Some requirements may be essential, especially for life-critical applications, while others may be desirable.
6
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
IEEE
Std 830-1998
Each requirement in the SRS should be identiÞed to make these differences clear and explicit. Identifying
the requirements in the following manner helps:
a)
b)
Have customers give more careful consideration to each requirement, which often clariÞes any
hidden assumptions they may have.
Have developers make correct design decisions and devote appropriate levels of effort to the different parts of the software product.
4.3.5.1 Degree of stability
One method of identifying requirements uses the dimension of stability. Stability can be expressed in terms
of the number of expected changes to any requirement based on experience or knowledge of forthcoming
events that affect the organization, functions, and people supported by the software system.
4.3.5.2 Degree of necessity
Another way to rank requirements is to distinguish classes of requirements as essential, conditional, and
optional.
a)
b)
c)
Essential. Implies that the software will not be acceptable unless these requirements are provided in
an agreed manner.
Conditional. Implies that these are requirements that would enhance the software product, but would
not make it unacceptable if they are absent.
Optional. Implies a class of functions that may or may not be worthwhile. This gives the supplier the
opportunity to propose something that exceeds the SRS.
4.3.6 VeriÞable
An SRS is veriÞable if, and only if, every requirement stated therein is veriÞable. A requirement is veriÞable
if, and only if, there exists some Þnite cost-effective process with which a person or machine can check that
the software product meets the requirement. In general any ambiguous requirement is not veriÞable.
NonveriÞable requirements include statements such as Òworks well,Ó Ògood human interface,Ó and Òshall
usually happen.Ó These requirements cannot be veriÞed because it is impossible to deÞne the terms Ògood,Ó
Òwell,Ó or Òusually.Ó The statement that Òthe program shall never enter an inÞnite loopÓ is nonveriÞable
because the testing of this quality is theoretically impossible.
An example of a veriÞable statement is
Output of the program shall be produced within 20 s of event ´ 60% of the time; and shall be
produced within 30 s of event ´ 100% of the time.
This statement can be veriÞed because it uses concrete terms and measurable quantities.
If a method cannot be devised to determine whether the software meets a particular requirement, then that
requirement should be removed or revised.
Copyright © 1998 IEEE. All rights reserved.
7
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
4.3.7 ModiÞable
An SRS is modiÞable if, and only if, its structure and style are such that any changes to the requirements can
be made easily, completely, and consistently while retaining the structure and style. ModiÞability generally
requires an SRS to
a)
b)
c)
Have a coherent and easy-to-use organization with a table of contents, an index, and explicit crossreferencing;
Not be redundant (i.e., the same requirement should not appear in more than one place in the SRS);
Express each requirement separately, rather than intermixed with other requirements.
Redundancy itself is not an error, but it can easily lead to errors. Redundancy can occasionally help to make
an SRS more readable, but a problem can arise when the redundant document is updated. For instance, a
requirement may be altered in only one of the places where it appears. The SRS then becomes inconsistent.
Whenever redundancy is necessary, the SRS should include explicit cross-references to make it modiÞable.
4.3.8 Traceable
An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of
each requirement in future development or enhancement documentation. The following two types of traceability are recommended:
a)
b)
Backward traceability (i.e., to previous stages of development). This depends upon each requirement
explicitly referencing its source in earlier documents.
Forward traceability (i.e., to all documents spawned by the SRS). This depends upon each requirement in the SRS having a unique name or reference number.
The forward traceability of the SRS is especially important when the software product enters the operation
and maintenance phase. As code and design documents are modiÞed, it is essential to be able to ascertain the
complete set of requirements that may be affected by those modiÞcations.
4.4 Joint preparation of the SRS
The software development process should begin with supplier and customer agreement on what the
completed software must do. This agreement, in the form of an SRS, should be jointly prepared. This is
important because usually neither the customer nor the supplier is qualiÞed to write a good SRS alone.
a)
b)
Customers usually do not understand the software design and development process well enough to
write a usable SRS.
Suppliers usually do not understand the customerÕs problem and Þeld of endeavor well enough to
specify requirements for a satisfactory system.
Therefore, the customer and the supplier should work together to produce a well-written and completely
understood SRS.
A special situation exists when a system and its software are both being deÞned concurrently. Then the functionality, interfaces, performance, and other attributes and constraints of the software are not predeÞned, but
rather are jointly deÞned and subject to negotiation and change. This makes it more difÞcult, but no less
important, to meet the characteristics stated in 4.3. In particular, an SRS that does not comply with the
requirements of its parent system speciÞcation is incorrect.
8
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
IEEE
Std 830-1998
This recommended practice does not speciÞcally discuss style, language usage, or techniques of good writing. It is quite important, however, that an SRS be well written. General technical writing books can be used
for guidance.
4.5 SRS evolution
The SRS may need to evolve as the development of the software product progresses. It may be impossible to
specify some details at the time the project is initiated (e.g., it may be impossible to deÞne all of the screen
formats for an interactive program during the requirements phase). Additional changes may ensue as deÞciencies, shortcomings, and inaccuracies are discovered in the SRS.
Two major considerations in this process are the following:
a)
Requirements should be speciÞed as completely and thoroughly as is known at the time, even if
evolutionary revisions can be foreseen as inevitable. The fact that they are incomplete should be
noted.
b)
A formal change process should be initiated to identify, control, track, and report projected changes.
Approved changes in requirements should be incorporated in the SRS in such a way as to
1) Provide an accurate and complete audit trail of changes;
2) Permit the review of current and superseded portions of the SRS.
4.6 Prototyping
Prototyping is used frequently during the requirements portion of a project. Many tools exist that allow a
prototype, exhibiting some characteristics of a system, to be created very quickly and easily. See also ASTM
E1340-96.
Prototypes are useful for the following reasons:
a)
b)
c)
The customer may be more likely to view the prototype and react to it than to read the SRS and react
to it. Thus, the prototype provides quick feedback.
The prototype displays unanticipated aspects of the systems behavior. Thus, it produces not only
answers but also new questions. This helps reach closure on the SRS.
An SRS based on a prototype tends to undergo less change during development, thus shortening
development time.
A prototype should be used as a way to elicit software requirements. Some characteristics such as screen or
report formats can be extracted directly from the prototype. Other requirements can be inferred by running
experiments with the prototype.
4.7 Embedding design in the SRS
A requirement speciÞes an externally visible function or attribute of a system. A design describes a particular subcomponent of a system and/or its interfaces with other subcomponents. The SRS writer(s) should
clearly distinguish between identifying required design constraints and projecting a speciÞc design. Note
that every requirement in the SRS limits design alternatives. This does not mean, though, that every requirement is design.
Copyright © 1998 IEEE. All rights reserved.
9
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
The SRS should specify what functions are to be performed on what data to produce what results at what
location for whom. The SRS should focus on the services to be performed. The SRS should not normally
specify design items such as the following:
a)
b)
c)
d)
Partitioning the software into modules;
Allocating functions to the modules;
Describing the ßow of information or control between modules;
Choosing data structures.
4.7.1 Necessary design requirements
In special cases some requirements may severely restrict the design. For example, security or safety requirements may reßect directly into design such as the need to
a)
b)
c)
Keep certain functions in separate modules;
Permit only limited communication between some areas of the program;
Check data integrity for critical variables.
Examples of valid design constraints are physical requirements, performance requirements, software development standards, and software quality assurance standards.
Therefore, the requirements should be stated from a purely external viewpoint. When using models to illustrate the requirements, remember that the model only indicates the external behavior, and does not specify a
design.
4.8 Embedding project requirements in the SRS
The SRS should address the software product, not the process of producing the software product.
Project requirements represent an understanding between the customer and the supplier about contractual
matters pertaining to production of software and thus should not be included in the SRS. These normally
include items such as
a)
b)
c)
d)
e)
f)
g)
Cost;
Delivery schedules;
Reporting procedures;
Software development methods;
Quality assurance;
Validation and veriÞcation criteria;
Acceptance procedures.
Project requirements are speciÞed in other documents, typically in a software development plan, a software
quality assurance plan, or a statement of work.
5. The parts of an SRS
This clause discusses each of the essential parts of the SRS. These parts are arranged in Figure 1 in an
outline that can serve as an example for writing an SRS.
While an SRS does not have to follow this outline or use the names given here for its parts, a good SRS
should include all the information discussed here.
10
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
IEEE
Std 830-1998
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
3. Specific requirements (See 5.3.1 through 5.3.8 for explanations of possible
specific requirements. See also Annex A for several different ways of organizing
this section of the SRS.)
Appendixes
Index
Figure 1ÑPrototype SRS outline
5.1 Introduction (Section 1 of the SRS)
The introduction of the SRS should provide an overview of the entire SRS. It should contain the following
subsections:
a)
b)
c)
d)
e)
Purpose;
Scope;
DeÞnitions, acronyms, and abbreviations;
References;
Overview.
5.1.1 Purpose (1.1 of the SRS)
This subsection should
a)
b)
Delineate the purpose of the SRS;
Specify the intended audience for the SRS.
5.1.2 Scope (1.2 of the SRS)
This subsection should
a)
b)
c)
d)
Identify the software product(s) to be produced by name (e.g., Host DBMS, Report Generator, etc.);
Explain what the software product(s) will, and, if necessary, will not do;
Describe the application of the software being speciÞed, including relevant beneÞts, objectives, and
goals;
Be consistent with similar statements in higher-level speciÞcations (e.g., the system requirements
speciÞcation), if they exist.
Copyright © 1998 IEEE. All rights reserved.
11
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
5.1.3 DeÞnitions, acronyms, and abbreviations (1.3 of the SRS)
This subsection should provide the deÞnitions of all terms, acronyms, and abbreviations required to properly
interpret the SRS. This information may be provided by reference to one or more appendixes in the SRS or
by reference to other documents.
5.1.4 References (1.4 of the SRS)
This subsection should
a)
b)
c)
Provide a complete list of all documents referenced elsewhere in the SRS;
Identify each document by title, report number (if applicable), date, and publishing organization;
Specify the sources from which the references can be obtained.
This information may be provided by reference to an appendix or to another document.
5.1.5 Overview (1.5 of the SRS)
This subsection should
a)
b)
Describe what the rest of the SRS contains;
Explain how the SRS is organized.
5.2 Overall description (Section 2 of the SRS)
This section of the SRS should describe the general factors that affect the product and its requirements. This
section does not state speciÞc requirements. Instead, it provides a background for those requirements, which
are deÞned in detail in Section 3 of the SRS, and makes them easier to understand.
This section usually consists of six subsections, as follows:
a)
b)
c)
d)
e)
f)
Product perspective;
Product functions;
User characteristics;
Constraints;
Assumptions and dependencies;
Apportioning of requirements.
5.2.1 Product perspective (2.1 of the SRS)
This subsection of the SRS should put the product into perspective with other related products. If the product
is independent and totally self-contained, it should be so stated here. If the SRS deÞnes a product that is a
component of a larger system, as frequently occurs, then this subsection should relate the requirements of
that larger system to functionality of the software and should identify interfaces between that system and the
software.
A block diagram showing the major components of the larger system, interconnections, and external interfaces can be helpful.
12
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
IEEE
Std 830-1998
This subsection should also describe how the software operates inside various constraints. For example,
these constraints could include
a)
b)
c)
d)
e)
f)
g)
h)
System interfaces;
User interfaces;
Hardware interfaces;
Software interfaces;
Communications interfaces;
Memory;
Operations;
Site adaptation requirements.
5.2.1.1 System interfaces
This should list each system interface and identify the functionality of the software to accomplish the system
requirement and the interface description to match the system.
5.2.1.2 User interfaces
This should specify the following:
a)
The logical characteristics of each interface between the software product and its users. This
includes those conÞguration characteristics (e.g., required screen formats, page or window layouts,
content of any reports or menus, or availability of programmable function keys) necessary to accomplish the software requirements.
b)
All the aspects of optimizing the interface with the person who must use the system. This may simply
comprise a list of doÕs and donÕts on how the system will appear to the user. One example may be a
requirement for the option of long or short error messages. Like all others, these requirements
should be veriÞable, e.g., Òa clerk typist grade 4 can do function X in Z min after 1 h of trainingÓ
rather than Òa typist can do function X.Ó (This may also be speciÞed in the Software System
Attributes under a section titled Ease of Use.)
5.2.1.3 Hardware interfaces
This should specify the logical characteristics of each interface between the software product and the hardware components of the system. This includes conÞguration characteristics (number of ports, instruction
sets, etc.). It also covers such matters as what devices are to be supported, how they are to be supported, and
protocols. For example, terminal support may specify full-screen support as opposed to line-by-line support.
5.2.1.4 Software interfaces
This should specify the use of other required software products (e.g., a data management system, an operating system, or a mathematical package), and interfaces with other application systems (e.g., the linkage
between an accounts receivable system and a general ledger system). For each required software product, the
following should be provided:
Ñ
Ñ
Ñ
Ñ
Ñ
Name;
Mnemonic;
SpeciÞcation number;
Version number;
Source.
Copyright © 1998 IEEE. All rights reserved.
13
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
For each interface, the following should be provided:
Ñ
Ñ
Discussion of the purpose of the interfacing software as related to this software product.
DeÞnition of the interface in terms of message content and format. It is not necessary to detail any
well-documented interface, but a reference to the document deÞning the interface is required.
5.2.1.5 Communications interfaces
This should specify the various interfaces to communications such as local network protocols, etc.
5.2.1.6 Memory constraints
This should specify any applicable characteristics and limits on primary and secondary memory.
5.2.1.7 Operations
This should specify the normal and special operations required by the user such as
a)
b)
c)
d)
The various modes of operations in the user organization (e.g., user-initiated operations);
Periods of interactive operations and periods of unattended operations;
Data processing support functions;
Backup and recovery operations.
NOTEÑThis is sometimes speciÞed as part of the User Interfaces section.
5.2.1.8 Site adaptation requirements
This should
a)
b)
DeÞne the requirements for any data or initialization sequences that are speciÞc to a given site,
mission, or operational mode (e.g., grid values, safety limits, etc.);
Specify the site or mission-related features that should be modiÞed to adapt the software to a particular installation.
5.2.2 Product functions (2.2 of the SRS)
This subsection of the SRS should provide a summary of the major functions that the software will perform.
For example, an SRS for an accounting program may use this part to address customer account maintenance,
customer statement, and invoice preparation without mentioning the vast amount of detail that each of those
functions requires.
Sometimes the function summary that is necessary for this part can be taken directly from the section of the
higher-level speciÞcation (if one exists) that allocates particular functions to the software product. Note that
for the sake of clarity
a)
b)
14
The functions should be organized in a way that makes the list of functions understandable to the
customer or to anyone else reading the document for the Þrst time.
Textual or graphical methods can be used to show the different functions and their relationships.
Such a diagram is not intended to show a design of a product, but simply shows the logical relationships among variables.
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
IEEE
Std 830-1998
5.2.3 User characteristics (2.3 of the SRS)
This subsection of the SRS should describe those general characteristics of the intended users of the product
including educational level, experience, and technical expertise. It should not be used to state speciÞc
requirements, but rather should provide the reasons why certain speciÞc requirements are later speciÞed in
Section 3 of the SRS.
5.2.4 Constraints (2.4 of the SRS)
This subsection of the SRS should provide a general description of any other items that will limit the developerÕs options. These include
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
Regulatory policies;
Hardware limitations (e.g., signal timing requirements);
Interfaces to other applications;
Parallel operation;
Audit functions;
Control functions;
Higher-order language requirements;
Signal handshake protocols (e.g., XON-XOFF, ACK-NACK);
Reliability requirements;
Criticality of the application;
Safety and security considerations.
5.2.5 Assumptions and dependencies (2.5 of the SRS)
This subsection of the SRS should list each of the factors that affect the requirements stated in the SRS.
These factors are not design constraints on the software but are, rather, any changes to them that can affect
the requirements in the SRS. For example, an assumption may be that a speciÞc operating system will be
available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly.
5.2.6 Apportioning of requirements (2.6 of the SRS)
This subsection of the SRS should identify requirements that may be delayed until future versions of the
system.
5.3 SpeciÞc requirements (Section 3 of the SRS)
This section of the SRS should contain all of the software requirements to a level of detail sufÞcient to
enable designers to design a system to satisfy those requirements, and testers to test that the system satisÞes
those requirements. Throughout this section, every stated requirement should be externally perceivable by
users, operators, or other external systems. These requirements should include at a minimum a description of
every input (stimulus) into the system, every output (response) from the system, and all functions performed
by the system in response to an input or in support of an output. As this is often the largest and most important part of the SRS, the following principles apply:
a)
b)
c)
d)
SpeciÞc requirements should be stated in conformance with all the characteristics described in 4.3.
SpeciÞc requirements should be cross-referenced to earlier documents that relate.
All requirements should be uniquely identiÞable.
Careful attention should be given to organizing the requirements to maximize readability.
Copyright © 1998 IEEE. All rights reserved.
15
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
Before examining speciÞc ways of organizing the requirements it is helpful to understand the various items
that comprise requirements as described in 5.3.1 through 5.3.7.
5.3.1 External interfaces
This should be a detailed description of all inputs into and outputs from the software system. It should
complement the interface descriptions in 5.2 and should not repeat information there.
It should include both content and format as follows:
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
l)
Name of item;
Description of purpose;
Source of input or destination of output;
Valid range, accuracy, and/or tolerance;
Units of measure;
Timing;
Relationships to other inputs/outputs;
Screen formats/organization;
Window formats/organization;
Data formats;
Command formats;
End messages.
5.3.2 Functions
Functional requirements should deÞne the fundamental actions that must take place in the software in
accepting and processing the inputs and in processing and generating the outputs. These are generally listed
as ÒshallÓ statements starting with ÒThe system shallÉÓ
These include
a)
b)
c)
d)
e)
Validity checks on the inputs
Exact sequence of operations
Responses to abnormal situations, including
1) Overßow
2) Communication facilities
3) Error handling and recovery
Effect of parameters
Relationship of outputs to inputs, including
1) Input/output sequences
2) Formulas for input to output conversion
It may be appropriate to partition the functional requirements into subfunctions or subprocesses. This does
not imply that the software design will also be partitioned that way.
5.3.3 Performance requirements
This subsection should specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software as a whole. Static numerical requirements may include the
following:
a)
b)
c)
16
The number of terminals to be supported;
The number of simultaneous users to be supported;
Amount and type of information to be handled.
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
IEEE
Std 830-1998
Static numerical requirements are sometimes identiÞed under a separate section entitled Capacity.
Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the
amount of data to be processed within certain time periods for both normal and peak workload conditions.
All of these requirements should be stated in measurable terms.
For example,
95% of the transactions shall be processed in less than 1 s.
rather than,
An operator shall not have to wait for the transaction to complete.
NOTEÑNumerical limits applied to one speciÞc function are normally speciÞed as part of the processing subparagraph
description of that function.
5.3.4 Logical database requirements
This should specify the logical requirements for any information that is to be placed into a database. This
may include the following:
a)
b)
c)
d)
e)
f)
Types of information used by various functions;
Frequency of use;
Accessing capabilities;
Data entities and their relationships;
Integrity constraints;
Data retention requirements.
5.3.5 Design constraints
This should specify design constraints that can be imposed by other standards, hardware limitations, etc.
5.3.5.1 Standards compliance
This subsection should specify the requirements derived from existing standards or regulations. They may
include the following:
a)
b)
c)
d)
Report format;
Data naming;
Accounting procedures;
Audit tracing.
For example, this could specify the requirement for software to trace processing activity. Such traces are
needed for some applications to meet minimum regulatory or Þnancial standards. An audit trace requirement
may, for example, state that all changes to a payroll database must be recorded in a trace Þle with before and
after values.
5.3.6 Software system attributes
There are a number of attributes of software that can serve as requirements. It is important that required
attributes be speciÞed so that their achievement can be objectively veriÞed. Subclauses 5.3.6.1 through
5.3.6.5 provide a partial list of examples.
Copyright © 1998 IEEE. All rights reserved.
17
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
5.3.6.1 Reliability
This should specify the factors required to establish the required reliability of the software system at time of
delivery.
5.3.6.2 Availability
This should specify the factors required to guarantee a deÞned availability level for the entire system such as
checkpoint, recovery, and restart.
5.3.6.3 Security
This should specify the factors that protect the software from accidental or malicious access, use, modiÞcation, destruction, or disclosure. SpeciÞc requirements in this area could include the need to
a)
b)
c)
d)
e)
Utilize certain cryptographical techniques;
Keep speciÞc log or history data sets;
Assign certain functions to different modules;
Restrict communications between some areas of the program;
Check data integrity for critical variables.
5.3.6.4 Maintainability
This should specify attributes of software that relate to the ease of maintenance of the software itself. There
may be some requirement for certain modularity, interfaces, complexity, etc. Requirements should not be
placed here just because they are thought to be good design practices.
5.3.6.5 Portability
This should specify attributes of software that relate to the ease of porting the software to other host
machines and/or operating systems. This may include the following:
a)
b)
c)
d)
e)
Percentage of components with host-dependent code;
Percentage of code that is host dependent;
Use of a proven portable language;
Use of a particular compiler or language subset;
Use of a particular operating system.
5.3.7 Organizing the speciÞc requirements
For anything but trivial systems the detailed requirements tend to be extensive. For this reason, it is recommended that careful consideration be given to organizing these in a manner optimal for understanding. There
is no one optimal organization for all systems. Different classes of systems lend themselves to different organizations of requirements in Section 3 of the SRS. Some of these organizations are described in 5.3.7.1
through 5.3.7.7.
5.3.7.1 System mode
Some systems behave quite differently depending on the mode of operation. For example, a control system
may have different sets of functions depending on its mode: training, normal, or emergency. When organizing this section by mode, the outline in A.1 or A.2 should be used. The choice depends on whether interfaces
and performance are dependent on mode.
18
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
IEEE
Std 830-1998
5.3.7.2 User class
Some systems provide different sets of functions to different classes of users. For example, an elevator
control system presents different capabilities to passengers, maintenance workers, and Þre Þghters. When
organizing this section by user class, the outline in A.3 should be used.
5.3.7.3 Objects
Objects are real-world entities that have a counterpart within the system. For example, in a patient monitoring system, objects include patients, sensors, nurses, rooms, physicians, medicines, etc. Associated with
each object is a set of attributes (of that object) and functions (performed by that object). These functions are
also called services, methods, or processes. When organizing this section by object, the outline in A.4 should
be used. Note that sets of objects may share attributes and services. These are grouped together as classes.
5.3.7.4 Feature
A feature is an externally desired service by the system that may require a sequence of inputs to effect the
desired result. For example, in a telephone system, features include local call, call forwarding, and conference call. Each feature is generally described in a sequence of stimulus-response pairs. When organizing this
section by feature, the outline in A.5 should be used.
5.3.7.5 Stimulus
Some systems can be best organized by describing their functions in terms of stimuli. For example, the functions of an automatic aircraft landing system may be organized into sections for loss of power, wind shear,
sudden change in roll, vertical velocity excessive, etc. When organizing this section by stimulus, the outline
in A.6 should be used.
5.3.7.6 Response
Some systems can be best organized by describing all the functions in support of the generation of a
response. For example, the functions of a personnel system may be organized into sections corresponding to
all functions associated with generating paychecks, all functions associated with generating a current list of
employees, etc. The outline in A.6 (with all occurrences of stimulus replaced with response) should be used.
5.3.7.7 Functional hierarchy
When none of the above organizational schemes prove helpful, the overall functionality can be organized
into a hierarchy of functions organized by either common inputs, common outputs, or common internal data
access. Data ßow diagrams and data dictionaries can be used to show the relationships between and among
the functions and data. When organizing this section by functional hierarchy, the outline in A.7 should be
used.
5.3.8 Additional comments
Whenever a new SRS is contemplated, more than one of the organizational techniques given in 5.3.7.7 may
be appropriate. In such cases, organize the speciÞc requirements for multiple hierarchies tailored to the
speciÞc needs of the system under speciÞcation. For example, see A.8 for an organization combining user
class and feature. Any additional requirements may be put in a separate section at the end of the SRS.
There are many notations, methods, and automated support tools available to aid in the documentation of
requirements. For the most part, their usefulness is a function of organization. For example, when organizing
by mode, Þnite state machines or state charts may prove helpful; when organizing by object, object-oriented
Copyright © 1998 IEEE. All rights reserved.
19
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
analysis may prove helpful; when organizing by feature, stimulus-response sequences may prove helpful;
and when organizing by functional hierarchy, data ßow diagrams and data dictionaries may prove helpful.
In any of the outlines given in A.1 through A.8, those sections called ÒFunctional Requirement iÓ may be
described in native language (e.g., English), in pseudocode, in a system deÞnition language, or in four subsections titled: Introduction, Inputs, Processing, and Outputs.
5.4 Supporting information
The supporting information makes the SRS easier to use. It includes the following:
a)
b)
c)
Table of contents;
Index;
Appendixes.
5.4.1 Table of contents and index
The table of contents and index are quite important and should follow general compositional practices.
5.4.2 Appendixes
The appendixes are not always considered part of the actual SRS and are not always necessary. They may
include
a)
b)
c)
d)
Sample input/output formats, descriptions of cost analysis studies, or results of user surveys;
Supporting or background information that can help the readers of the SRS;
A description of the problems to be solved by the software;
Special packaging instructions for the code and the media to meet security, export, initial loading, or
other requirements.
When appendixes are included, the SRS should explicitly state whether or not the appendixes are to be
considered part of the requirements.
20
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
IEEE
Std 830-1998
Annex A
(informative)
SRS templates
A.1 Template of SRS Section 3 organized by mode: Version 1
3. SpeciÞc requirements
3.1
External interface requirements
3.1.1
User interfaces
3.1.2
Hardware interfaces
3.1.3
Software interfaces
3.1.4
Communications interfaces
3.2
Functional requirements
3.2.1
Mode 1
3.2.1.1 Functional requirement 1.1
.
.
.
3.2.1.n Functional requirement 1.n
3.2.2
Mode 2
.
.
.
3.2.m Mode m
3.2.m.1 Functional requirement m.1
.
.
.
3.2.m.n Functional requirement m.n
3.3
Performance requirements
3.4
Design constraints
3.5
Software system attributes
3.6
Other requirements
A.2 Template of SRS Section 3 organized by mode: Version 2
3. SpeciÞc requirements
3.1. Functional requirements
3.1.1
Mode 1
3.1.1.1 External interfaces
3.1.1.1.1 User interfaces
3.1.1.1.2 Hardware interfaces
3.1.1.1.3 Software interfaces
3.1.1.1.4 Communications interfaces
3.1.1.2 Functional requirements
3.1.1.2.1 Functional requirement 1
.
.
.
Copyright © 1998 IEEE. All rights reserved.
21
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
3.1.1.2.n Functional requirement n
3.1.1.3 Performance
Mode 2
3.2
3.3
3.4
3.1.2
.
.
.
3.1.m Mode m
Design constraints
Software system attributes
Other requirements
A.3 Template of SRS Section 3 organized by user class
3. SpeciÞc requirements
3.1
External interface requirements
3.1.1
User interfaces
3.1.2
Hardware interfaces
3.1.3
Software interfaces
3.1.4
Communications interfaces
3.2
Functional requirements
3.2.1
User class 1
3.2.1.1 Functional requirement 1.1
.
.
.
3.2.1.n Functional requirement 1.n
3.2.2
User class 2
.
.
.
3.2.m
User class m
3.2.m.1 Functional requirement m.1
.
.
.
3.2.m.n Functional requirement m.n
3.3
Performance requirements
3.4
Design constraints
3.5
Software system attributes
3.6
Other requirements
A.4 Template of SRS Section 3 organized by object
3. SpeciÞc requirements
3.1
External interface requirements
3.1.1
User interfaces
3.1.2
Hardware interfaces
3.1.3
Software interfaces
3.1.4
Communications interfaces
3.2
Classes/Objects
3.2.1
Class/Object 1
22
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
IEEE
Std 830-1998
3.2.1.1
Attributes (direct or inherited)
3.2.1.1.1 Attribute 1
.
.
.
3.2.1.1.n Attribute n
3.2.1.2 Functions (services, methods, direct or inherited)
3.2.1.2.1 Functional requirement 1.1
.
.
.
3.2.1.2.m Functional requirement 1.m
3.2.1.3 Messages (communications received or sent)
Class/Object 2
3.3
3.4
3.5
3.6
3.2.2
.
.
.
3.2.p
Class/Object p
Performance requirements
Design constraints
Software system attributes
Other requirements
A.5 Template of SRS Section 3 organized by feature
3. SpeciÞc requirements
3.1
External interface requirements
3.1.1
User interfaces
3.1.2
Hardware interfaces
3.1.3
Software interfaces
3.1.4
Communications interfaces
3.2
System features
3.2.1
System Feature 1
3.2.1.1 Introduction/Purpose of feature
3.2.1.2 Stimulus/Response sequence
3.2.1.3 Associated functional requirements
3.2.1.3.1 Functional requirement 1
.
.
.
3.2.1.3.n Functional requirement n
3.2.2
System feature 2
.
.
.
3.2.m System feature m
.
.
.
3.3
Performance requirements
3.4
Design constraints
3.5
Software system attributes
3.6
Other requirements
Copyright © 1998 IEEE. All rights reserved.
23
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
A.6 Template of SRS Section 3 organized by stimulus
3. SpeciÞc requirements
3.1
External interface requirements
3.1.1
User interfaces
3.1.2
Hardware interfaces
3.1.3
Software interfaces
3.1.4
Communications interfaces
3.2
Functional requirements
3.2.1
Stimulus 1
3.2.1.1 Functional requirement 1.1
.
.
.
3.2.1.n Functional requirement 1.n
3.2.2
Stimulus 2
.
.
.
3.2.m Stimulus m
3.2.m.1 Functional requirement m.1
.
.
.
3.2.m.n Functional requirement m.n
3.3
Performance requirements
3.4
Design constraints
3.5
Software system attributes
3.6
Other requirements
A.7 Template of SRS Section 3 organized by functional hierarchy
3. SpeciÞc requirements
3.1
External interface requirements
3.1.1
User interfaces
3.1.2
Hardware interfaces
3.1.3
Software interfaces
3.1.4
Communications interfaces
3.2
Functional requirements
3.2.1
Information ßows
3.2.1.1 Data ßow diagram 1
3.2.1.1.1 Data entities
3.2.1.1.2 Pertinent processes
3.2.1.1.3 Topology
3.2.1.2 Data ßow diagram 2
3.2.1.2.1 Data entities
3.2.1.2.2 Pertinent processes
3.2.1.2.3 Topology
.
.
.
3.2.1.n Data ßow diagram n
24
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
3.2.2
3.2.3
3.2.4
IEEE
Std 830-1998
3.2.1.n.1 Data entities
3.2.1.n.2 Pertinent processes
3.2.1.n.3 Topology
Process descriptions
3.2.2.1 Process 1
3.2.2.1.1 Input data entities
3.2.2.1.2 Algorithm or formula of process
3.2.2.1.3 Affected data entities
3.2.2.2 Process 2
3.2.2.2.1 Input data entities
3.2.2.2.2 Algorithm or formula of process
3.2.2.2.3 Affected data entities
.
.
.
3.2.2.m Process m
3.2.2.m.1 Input data entities
3.2.2.m.2 Algorithm or formula of process
3.2.2.m.3 Affected data entities
Data construct speciÞcations
3.2.3.1 Construct 1
3.2.3.1.1 Record type
3.2.3.1.2 Constituent Þelds
3.2.3.2 Construct 2
3.2.3.2.1 Record type
3.2.3.2.2 Constituent Þelds
.
.
.
3.2.3.p Construct p
3.2.3.p.1 Record type
3.2.3.p.2 Constituent Þelds
Data dictionary
3.2.4.1 Data element 1
3.2.4.1.1 Name
3.2.4.1.2 Representation
3.2.4.1.3 Units/Format
3.2.4.1.4 Precision/Accuracy
3.2.4.1.5 Range
3.2.4.2 Data element 2
3.2.4.2.1 Name
3.2.4.2.2 Representation
3.2.4.2.3 Units/Format
3.2.4.2.4 Precision/Accuracy
3.2.4.2.5 Range
.
.
.
3.2.4.q Data element q
3.2.4.q.1 Name
3.2.4.q.2 Representation
3.2.4.q.3 Units/Format
3.2.4.q.4 Precision/Accuracy
3.2.4.q.5 Range
Copyright © 1998 IEEE. All rights reserved.
25
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
3.3
3.4
3.5
3.6
Performance requirements
Design constraints
Software system attributes
Other requirements
A.8 Template of SRS Section 3 showing multiple organizations
3. SpeciÞc requirements
3.1
External interface requirements
3.1.1
User interfaces
3.1.2
Hardware interfaces
3.1.3
Software interfaces
3.1.4
Communications interfaces
3.2
Functional requirements
3.2.1
User class 1
3.2.1.1 Feature 1.1
3.2.1.1.1 Introduction/Purpose of feature
3.2.1.1.2 Stimulus/Response sequence
3.2.1.1.3 Associated functional requirements
3.2.1.2 Feature 1.2
3.2.1.2.1 Introduction/Purpose of feature
3.2.1.2.2 Stimulus/Response sequence
3.2.1.2.3 Associated functional requirements
.
.
.
3.2.1.m Feature 1.m
3.2.1.m.1 Introduction/Purpose of feature
3.2.1.m.2 Stimulus/Response sequence
3.2.1.m.3 Associated functional requirements
3.2.2
User class 2
.
.
.
3.2.n
User class n
.
.
.
3.3
Performance requirements
3.4
Design constraints
3.5
Software system attributes
3.6
Other requirements
26
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE REQUIREMENTS SPECIFICATIONS
IEEE
Std 830-1998
Annex B
(informative)
Guidelines for compliance with IEEE/EIA 12207.1-1997
B.1 Overview
The Software Engineering Standards Committee (SESC) of the IEEE Computer Society has endorsed the
policy of adopting international standards. In 1995, the international standard, ISO/IEC 12207, Information
technologyÑSoftware life cycle processes, was completed. The standard establishes a common framework
for software life cycle processes, with well-deÞned terminology, that can be referenced by the software
industry.
In 1995 the SESC evaluated ISO/IEC 12207 and decided that the standard should be adopted and serve as
the basis for life cycle processes within the IEEE Software Engineering Collection. The IEEE adaptation of
ISO/IEC 12207 is IEEE/EIA 12207.0-1996. It contains ISO/IEC 12207 and the following additions:
improved compliance approach, life cycle process objectives, life cycle data objectives, and errata.
The implementation of ISO/IEC 12207 within the IEEE also includes the following:
Ñ
IEEE/EIA 12207.1-1997, IEEE/EIA Guide for Information TechnologyÑSoftware life cycle processesÑLife cycle data;
Ñ
IEEE/EIA 12207.2-1997, IEEE/EIA Guide for Information TechnologyÑSoftware life cycle processesÑImplementation considerations; and
Ñ
Additions to 11 SESC standards (i.e., IEEE Stds 730, 828, 829, 830, 1012, 1016, 1058, 1062, 1219,
1233, 1362) to deÞne the correlation between the data produced by existing SESC standards and the
data produced by the application of IEEE/EIA 12207.1-1997.
NOTEÑAlthough IEEE/EIA 12207.1-1997 is a guide, it also contains provisions for application as a standard with speciÞc compliance requirements. This annex treats 12207.1-1997 as a standard.
B.1.1 Scope and purpose
Both IEEE Std 830-1998 and IEEE/EIA 12207.1-1997 place requirements on a Software Requirements
Description Document. The purpose of this annex is to explain the relationship between the two sets of
requirements so that users producing documents intended to comply with both standards may do so.
B.2 Correlation
This clause explains the relationship between IEEE Std 830-1998 and IEEE/EIA 12207.0-1996 and IEEE/
EIA 12207.1-1997 in the following areas: terminology, process, and life cycle data.
B.2.1 Terminology correlation
Both this recommended practice and IEEE/EIA 12207.0-1996 have similar semantics for the key terms of
software, requirements, speciÞcation, supplier, developer, and maintainer. This recommended practice uses
Copyright © 1998 IEEE. All rights reserved.
27
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
the term ÒcustomerÓ where IEEE/EIA 12207.0-1996 uses Òacquirer,Ó and this recommended practice uses
ÒuserÓ where IEEE/EIA 12207.0-1996 uses Òoperator.Ó
B.2.2 Process correlation
IEEE/EIA 12207.0-1996 uses a process-oriented approach for describing the deÞnition of a set of requirements for software. This recommended practice uses a product-oriented approach, where the product is a
Software Requirements Description (SRD). There are natural process steps, namely the steps to create each
portion of the SRD. These may be correlated with the process requirements of IEEE/EIA 12207.0-1996. The
difference is that this recommended practice is focused on the development of software requirements
whereas IEEE/EIA 12207.0-1996 provides an overall life cycle view and mentions Software Requirements
Analysis as part of its Development Process. This recommended practice provides a greater level of detail on
what is involved in the preparation of an SRD.
B.2.3 Life cycle data correlation
IEEE/EIA 12207.0-1996 takes the viewpoint that the software requirements are derived from the system
requirements. Therefore, it uses the term, ÒdescriptionÓ rather that ÒspeciÞcationÓ to describe the software
requirements. In a system in which software is a component, each requiring its own speciÞcation, there
would be a System Requirements SpeciÞcation (SRS) and one or more SRDs. If the term Software Requirements SpeciÞcation had been used, there would be a confusion between an SRS referring to the system or
software requirements. In the case where there is a stand-alone software system, IEEE/EIA 12207.1-1997
states ÒIf the software is a stand-alone system, then this document should be a speciÞcation.Ó
B.3 Content mapping
This clause provides details bearing on a claim that an SRS complying with this recommended practice
would also achieve Òdocument complianceÓ with the SRD described in IEEE/EIA 12207.1-1997. The
requirements for document compliance are summarized in a single row of Table 1 of IEEE/EIA 12207.11997. That row is reproduced in Table B.1 of this recommended practice.
Table B.1ÑSummary of requirements for an SRD
excerpted from Table 1 of IEEE/EIA 12207.1-1997
Information
item
Software
Requirements
Description
IEEE/EIA
12207.0-1996
Clause
5.1.1.4, 5.3.4.1,
5.3.4.2
Kind
Description
(See note for 6.22.1
of IEEE/EIA
12207.1-1997.)
IEEE/EIA
12207.1-1997
Clause
6.22
References
IEEE Std 830-1998; EIA/IEEE
J-STD-016, F.2.3, F.2.4; MILSTD 961D. Also see ISO/IEC
5806, 5807, 6593, 8631, 8790,
and 11411 for guidance on use
of notations.
The requirements for document compliance are discussed in the following subclauses:
Ñ
28
B.3.1 discusses compliance with the information requirements noted in column 2 of Table B.1 as
prescribed by 5.1.1.4, 5.3.4.1, and 5.3.4.2 of IEEE/EIA 12207.0-1996.
Copyright © 1998 IEEE. All rights reserved.
IEEE
Std 830-1998
SOFTWARE REQUIREMENTS SPECIFICATIONS
Ñ
B.3.2 discusses compliance with the generic content guideline (the ÒkindÓ of document) noted in
column 3 of Table B.1 as a ÒdescriptionÓ. The generic content guidelines for a ÒdescriptionÓ appear
in 5.1 of IEEE/EIA 12207.1-1997.
Ñ
B.3.3 discusses compliance with the speciÞc requirements for a Software Requirements Description
noted in column 4 of Table B.1 as prescribed by 6.22 of IEEE/EIA 12207.1-1997.
Ñ
B.3.4 discusses compliance with the life cycle data objectives of Annex H of IEEE/EIA 12207.01996 as described in 4.2 of IEEE/EIA 12207.1-1997.
B.3.1 Compliance with information requirements of IEEE/EIA 12207.0-1996
The information requirements for an SRD are those prescribed by 5.1.1.4, 5.3.4.1, and 5.3.4.2 of IEEE/EIA
12207.0-1996. The requirements are substantively identical to those considered in B.3.3 of this recommended practice.
B.3.2 Compliance with generic content guidelines of IEEE/EIA 12207.1-1997
According to IEEE/EIA 12207.1-1997, the generic content guideline for an SRD is generally a description,
as prescribed by 5.1 of IEEE/EIA 12207.1-1997. A complying description shall achieve the purpose stated in
5.1.1 and include the information listed in 5.1.2 of IEEE/EIA 12207.1-1997.
The purpose of a description is:
IEEE/EIA 12207.1-1997, subclause 5.1.1: Purpose: Describe a planned or actual function,
design, performance, or process.
An SRD complying with this recommended practice would achieve the stated purpose.
Any description or speciÞcation complying with IEEE/EIA 12207.1-1997 shall satisfy the generic content
requirements provided in 5.1.2 of that standard. Table B.2 of this recommended practice lists the generic
content items and, where appropriate, references the clause of this recommended practice that requires the
same information.
Table B.2ÑCoverage of generic description requirements by IEEE Std 830-1998
IEEE/EIA 12207.1-1997
generic content
Corresponding clauses of
IEEE Std 830-1998
Additions to requirements of
IEEE Std 830-1998
a) Date of issue and status
b) Scope
c) Issuing organization
d) References
e) Context
f) Notation for description
g) Body
h) Summary
i) Glossary
j) Change history
Ñ
5.1.1 Scope
Ñ
5.1.4 References
5.1.2 Scope
4.3 Characteristics of a good SRS
5. The parts of an SRS
5.1.1. Overview
5.1.3 DeÞnitions
Ñ
Date of issue and status shall be provided.
Ñ
Issuing organization shall be identiÞed.
Ñ
Ñ
Ñ
Ñ
Ñ
Ñ
Change history for the SRD shall be
provided or referenced.
Copyright © 1998 IEEE. All rights reserved.
29
IEEE
Std 830-1998
IEEE RECOMMENDED PRACTICE FOR
B.3.3 Compliance with speciÞc content requirements of IEEE/EIA 12207.1-1997
The speciÞc content requirements for an SRD in IEEE/EIA 12207.1-1997 are prescribed by 6.22 of IEEE/
EIA 12207.1-1997. A compliant SRD shall achieve the purpose stated in 6.22.1 of IEEE/EIA 12207.1-1997.
The purpose of the SRD is:
IEEE/EIA 12207.1-1997, subclause 6.22.1: Purpose: Specify the requirements for a software item and the methods to be used to ensure that each requirement has been met. Used as
the basis for design and qualiÞcation testing of a software item.
An SRS complying with this recommended practice and meeting the additional requirements of Table B.3 of
this recommended practice would achieve the stated purpose.
An SRD compliant with IEEE/EIA 12207.1-1997 shall satisfy the speciÞc content requirements provided in
6.22.3 and 6.22.4 of that standard. Table B.3 of this recommended practice lists the speciÞc content items
and, where appropriate, references the clause of this recommended practice that requires the same information.
An SRD speciÞed according the requirements stated or referenced in Table B.3 of this recommended practice shall be evaluated considering the criteria provided in 5.3.4.2 of IEEE/EIA 12207.0-1996.
Table B.3ÑCoverage of speciÞc SRD requirements by IEEE Std 830-1998
IEEE/EIA 12207.1-1997
speciÞc content
Corresponding clauses of
IEEE Std 830-1998
Additions to requirements of
IEEE Std 830-1998
a) Generic description information
b) System identiÞcation and
overview
c) Functionality of the software item
including:
Ð Performance requirements
Ð Physical characteristics
Ð Environmental conditions
d) Requirements for interfaces
external to software item
e) QualiÞcation requirements
See Table B.2
5.1.1 Scope
Ñ
Ñ
5.3.2 Functions
5.3.3 Performance requirements
Physical characteristics and environmental conditions should be
provided.
5.3.1 External interfaces
Ñ
Ñ
f) Safety speciÞcations
g) Security and privacy
speciÞcations
h) Human-factors engineering
requirements
i) Data deÞnition and database
requirements
j) Installation and acceptance
requirements at operation site
k) Installation and acceptance
requirements at maintenance site
l) User documentation requirements
m) User operation and execution
requirements
5.2.4 Constraints
5.3.6.3 Security
The requirements to be used for
qualiÞcation testing should be
provided (or referenced).
Ñ
Ñ
30
5.2.3 User characteristics
5.2.1.2 User interfaces
5.3.4 Logical data base requirements
Ñ
5.2.1.8 Site adaptation requirements
Installation and acceptance requirements at operation site
Installation and acceptance requirements at maintenance site
User documentation requirements
User execution requirements
Ñ
Ñ
5.2.1.7 Operations
Ñ
Copyright © 1998 IEEE. All rights reserved.
IEEE
Std 830-1998
SOFTWARE REQUIREMENTS SPECIFICATIONS
Table B.3ÑCoverage of speciÞc SRD requirements by IEEE Std 830-1998 (continued)
IEEE/EIA 12207.1-1997
speciÞc content
n) User maintenance requirements
o) Software quality characteristics
p) Design and implementation
constraints
q) Computer resource requirements
r) Packaging requirements
s) Precedence and criticality of
requirements
t) Requirements traceability
u) Rationale
Items a) through f) below are from
6.22.4
a) Support the life cycle data objectives of Annex H of IEEE/EIA
12207.0-1996
b) Describe any function using welldeÞned notation
c) DeÞne no requirements that are in
conßict
d) User standard terminology and
deÞnitions
e) DeÞne each unique requirement
one to prevent inconsistency
f) Uniquely identify each requirement
Corresponding clauses of
IEEE Std 830-1998
Additions to requirements of
IEEE Std 830-1998
5.3.6.4 Maintainability
5.3.6 Software system attributes
5.2.4 Constraints
Ñ
Ñ
Ñ
5.3.3 Performance requirements
Ñ
5.2.6 Apportioning of requirements
Computer resource requirements
Packaging requirements
Ñ
4.3.8 Traceable
5.2.5 Assumptions and
dependencies
Ñ
Ñ
Ñ
Support the life cycle data objectives
of Annex H of IEEE/EIA 12207.01996
4.3 Characteristics of a good SRS
Ñ
4.3 Characteristics of a good SRS
Ñ
5.1.3 DeÞnition
Ñ
4.3 Characteristics of a good SRS
Ñ
4.3 Characteristics of a good SRS
Ñ
B.3.4 Compliance with life cycle data objectives
In addition to the content requirements, life cycle data shall be managed in accordance with the objectives
provided in Annex H of IEEE/EIA 12207.0-1996.
B.4 Conclusion
The analysis suggests that any SRS complying with this recommended practice and the additions shown in
Table B.2 and Table B.3 also complies with the requirements of an SRD in IEEE/EIA 12207.1-1997. In
addition, to comply with IEEE/EIA 12207.1-1997, an SRS shall support the life cycle data objectives of
Annex H of IEEE/EIA 12207.0-1996.
Copyright © 1998 IEEE. All rights reserved.
31