SRE-Week-09-Refining-the-system-definition-05052023-114706pm.pptx

SOFTWARE REQUIREMENTS
ENGINEERING
LECTURE # 9
Refining the System
Definition (Software
Requirements)

 Software Requirements
 Software System Behavior
 Relationship between Features and Software
Requirements
 The Requirements Dilemma
• Excluding Project Information
• Excluding Design Information
 Requirements VS Design
 Iteration between Requirements & Design
 Characterization Of Requirements
• Functional Requirements
• Non-Functional Requirements
• Design Constraints
Engr. Ali
Presentation
Outline
4

Looking Deeper into
Software
Requirements
5
 A software requirement is defined as a software capability that must be met or
possessed by a system or a system component to satisfy a contract, standard,
specification, or other formally imposed documentation
 Since now, we've been speaking of these requirements things as features and use
cases at a fairly high level of abstraction. It was sufficient to understand the system at a
macro-level view.
 However, as we get closer to implementation, additional specificity is required.
 Software requirements are those things that the software does on behalf of the user.
 The first place to look for Software requirements is around the boundary of the
system, in
addition certain characteristics like performance, reliability etc. also needs to be considered.

Software System Behavior
6
 Davis [1999] suggests that we need five major classes of things in
order to fully describe the behavior of a software system (Figure 1).
 Inputs to the system— not only the contentof the input butalso, as
necessary, the details of input devices and the form, look, and feel of the input.
 Outputs from the system— a description of the output devices, such as voice-
output or
visual display, that must be supported, by the system.
 Functions of the system— the mapping of inputs to outputs, and their various
combinations.
typica
l
non-
behavioral
requiremen
ts
as reliability,
 Attributes of the system—
such maintainability, availability,
etc.
 Attributes of the system environment— such additional non-behavioral
requirements as the ability of the system to operate with other applications, loads,
and operating systems.

Figure 1:: System
elements
Software System Behavior
7

Relationship between Features and
Software
Requirements
8
 There is a mapping relationship between features and software
requirements.
Vision Document Feature Software Requirements
Features are simple descriptionsof
systems services described in a
brief form.
Software requirements, represented in any
form, express those features in much more
detailed terms.
The Vision Document cites features
in user’s
language.
The Software Requirements express those
features in technical terms, using one or
more specific Software requirements that
must be fulfilled by the developer in order
to provide the features to the user

Relationship between Features and
Software Requirements
9
 For example, suppose we are developing a defect-tracking system for a
software development organization.
 Table 1 shows the relationship between one of the features identified in
the Vision
document and its associated set of requirements.
 This mapping will form the backbone of a requirements management
concept known as "traceability“.
Table 1:: Prioritized Features List
Vision Document Feature Software Requirements
Feature 30: The defect-tracking system will
provide trending information to help the user
assess project status.
SR30.1:Trending information will be
provided in a histogram report showing
time on the x-axis and number of defects
on the y-axis
SR30.2: The user can enter the trending
period
In units of days, weeks or months.
SR30.3: An example trending report is
shown in Attached Figure1.

The
Requirement Dilemma : What Vs
How
10

The
Requirement Dilemma : What Vs
How
11
 As we have seen, requirements tell the developers what their system must do.
 But there's a lot of other information that the requirements should not contain, they
should avoid specifying any unnecessary design or implementation details, or testing
and information associated with project management.
 This is "what versus how" paradigm,
 where what represents the requirements, and
 how represents the design or other project information that is to be implemented to
achieve this objective.

The Requirements Dilemma
12
 Excluding Project Information
 Project-related information (such as schedules, configuration
management plans, verification and validation plans etc.) is
sometimes bundled into the set of requirements for the convenience
of the project manager. In general, this must be avoided since
changes in this information increase volatility and the tendency for
the "requirements" to be out of date.
Schedul
es
Verification and
Validation

13
 The budget could be seen as requirement too; however,
this is another type of information that doesn't fit our
definition and therefore doesn't belong with the overall
system or software requirements.

14
 Information describing how we'll know that the requirements
have actually been met — test procedures or acceptance
procedures— also don't meet the definition and therefore
don't belong in the requirements.

15
 Excluding Design Information
 The requirements should also exclude information about the system
design or architecture. Otherwise, you may accidentally restrict your
team from following whatever design options make the most sense for
your application.
 Suppose, for example, that the requirement in Table 1 had been worded
like this: "Trending information will be provided in a histogram
report written in Visual Basic, showing major contributing causes
on the x-axis and the number of defects found on the y-axis"
(Figure 2).
Figure 2:: Pareto Chart

17
 If a technical developer decides to insert a reference to Visual Basic because of a
preference for the language, it obviously has no legitimate place in the list of
requirements.
 If the customer refuses to pay for a system unless it's written in Visual Basic, the best
course of action is to treat it like a requirement, although we will place it in a special
class, called design constraints.
 Nevertheless, it's an implementation constraint that has been imposed on the
development team.

Requirements versus Design
18
 So far, we have treated software requirements, design decisions, and design
constraints as if they were distinct entities. That is, we have stated or implied
the following.
 Requirements (mostly) precede design
 Users , because they are closest to the need, make requirements decisions.
 Technologists make design decisions because they are best suited to pick, among
the many
design options, which option will best meet the need.

Iterating Requirements and
Design
19
 In reality, the requirements
versus
desig
n
must be iterative
.
Requirements discovery,
definition, and
desig
n
activities
decisio
ns
are circular.
The
process is a continual give and take, in
that

Requirements Specification
21
 Two terminologies specification & documentation are used
interchangeably
 During elicitation, we informally write the requirements
 Now we have to write it in some formal way
 We write it formally so that
 We can have agreement with customer
 We can carry out validation activity
 And as a result we can develop software solutions

Writing Requirements
22
 This document is a starting point for design and development of the software
system.
 Typically, requirements documents are written in natural languages (like,
English, Japanese, French, etc.)
 Natural languages, by their nature, are ambiguous.
 For the help of natural languages, structured languages can be used to
specify requirements

University of Toronto Department of Computer Science
Requirements vs. Specifications
Application Domain Machine Domain
D - domain properties
R - requirements
C - computers
P - programs
I wish these drug
inventory figures were
up to date!
3.When a stock delivery
list is received, the
system shall add the
item counts to the
current inventory levels.
4.When a prescription
is filled the system
shall…
Deliveries and
prescriptions
are the only
way the stock
levels change
R:
D:
S: P:
C:
19
© 2004-5
Steve

Purpose
 Communication
 explains the application domain and the
system to be developed
 Contractual
 May be legally binding!
 Expresses agreement and a commitment
 Baseline for evaluating the software
 supports testing, V&V
 “enough information to verify whether
delivered system meets requirements”
 Baseline for change control
20
Audience
 Customers & Users
 interested in system requirements…
 …but not detailed software requirements
 Systems (Requirements) Analysts
 Write other specifications that inter-
relate
 Developers, Programmers
 Have to implement the requirements
 Testers
 Have to check that the requirements
have been met
 Project Managers
 Have to measure and control the project
Software Requirements Specification
How do we communicate the Requirements to others?
 It is common practice to capture them in an SRS
 But an SRS doesn’t need to be a single paper document...

Valid (or “correct”)
 Expresses the real needs of the
stakeholders (customers, users,…)
 Does not contain anything that is not
“required”
21
Unambiguous
 Every statement can be read in
exactly one way
Complete
 All the things the system must do…
 …and all the things it must not do!
 Conceptual Completeness
 E.g. responses to all classes of input
 Structural Completeness
 E.g. no TBDs!!!
Understandable (Clear)
 E.g. by non-computer specialists
Consistent
 Doesn’t contradict itself
 Uses all terms consistently
Ranked
 Indicates relative importance /
stability of each requirement
Verifiable
 A process exists to test satisfaction
of each requirement
Modifiable
 Can be changed without difficulty
 Good structure and cross-referencing
Traceable
 Origin of each requirement is clear
 Labels each requirement for future
referencing
Desiderata for Specifications
Source: Adapted from IEEE-STD-830-1998

There is no Perfect SRS!
incomplete
not understandable
ambiguous
redundant inconsistent
add
explanations
resolve
reduce
expand
expand
condense
formalize
22
© 204-5
Steve
…etc!

Originate in critical functions? F T F T F T F T
Occur during critical sequence? F F T T F F T T
No fault recovery response? F F F F T T T T
Report to operator?
23
© 2004-5
Steve
Use Appropriate Notations
Source: Adapted from Easterbrook & Callahan, 1997.
Natural Language?
 “The system shall report to the operator all faults that originate in critical
functions or that occur during execution of a critical sequence and for which
there is no fault recovery response.”
(this is adapted from a real NASA spec for the international space station)
Or a decision table?

SRS Contents
Software Requirements Specification should address:
 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?
 What assumptions can be made about these external entities?
 Required Performance.
 What is the speed, availability, response time, recovery time of various software
functions, and so on?
 Quality Attributes.
 What are the portability, correctness, maintainability, security, and other
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) and so on?
24
© 2004-5
Steve

SRS should not include…
Source: Adapted from Davis, 1990, p183
Project development plans
 E.g. cost, staffing, schedules, methods, tools, etc
 Lifetime of SRS is until the software is made obsolete
 Lifetime of development plans is much shorter
Product assurance plans
 Configuration Management, Verification & Validation, test plans, Quality
Assurance, etc
 Different audiences
 Different lifetimes
Designs
 Requirements and designs have different audiences
 Analysis and design are different areas of expertise
 I.e. requirements analysts shouldn’t do design!
 Except where application domain constrains the design
 e.g. limited communication between different subsystems for security reasons.
25
© 2004-5
Steve

 Noise
 text that carries no relevant information
to any feature of the problem.
 Silence
 a feature that is not covered by any text.
 Over-specification
 text that describes a detailed design
decision, rather than the problem.
 Contradiction
 text that defines a single feature in a
number of incompatible ways.
 Ambiguity
 text that can be interpreted in at least
two different ways.
26
© 2004-5
Steve
 Forward reference
text that refers to a terms or
features yet to be defined.
 Wishful thinking
text that defines a feature that
cannot possibly be verified.
Requirements on users
 Cannot require users to do certain
things, can only assume that they will
 Jigsaw puzzles
 distributing key information across a
document and then cross-referencing
 Unnecessary invention of terminology
 E.g. ‘user input presentation function’
 Inconsistent terminology
 Inventing and then changing
terminology
Typical mistakes
Source: Adapted from Kovitz, 1999

Modern SRS Package
23
 Historically the most popular technique for documenting requirements was to use
natural language.
 This technique was revised and improved and eventually a number of standards
developed for these documents, including IEEE 830 standard for Software
Requirements Specification.
 The modern SRS package plays no of crucial roles::
 It serves as a basis of communication among all parties
 It represents an agreement among all parties
 It serves as a project manager’s reference standard
 It serves as input to the design, implementation and testingteams
 It controls the evolution of the system throughout development phase of
the project

Modern SRS Package
24
Software Requirements
Specification
<Project>
Version 1.0 approved
Prepared by <author>
<organization>
<date created>

Revision History
Date Revision Description Author
Mm/dd/yy 1.0 Initial Version Author Name
Modern SRS Package
25

Modern SRS Package
26
Table of Contents
1 Introduction
 This section should provide an overview of the supplementary
specification and should contain the following subsections
1. Purpose
 Specify the purpose of this SRS. The document collects and organizes
all the requirements of the system. These include functional
requirements, nonfunctional requirements, and design constraints.
2. Scope
 State the scope of the document and any systems or subsystems to
watch it applies.

Modern SRS Package
27
3. Definitions, Acronyms, and Abbreviations
 Provide the definitions of all terms, acronyms, and abbreviations required to properly
interpret the specification document. This information may be provided by reference
to a project glossary.
4. References
 This subsection should
 Provide a list of all documents referenced elsewhere in the specification
 Identify each documentby title, report number (if applicable), date, and
publishing
organization
 Specify the sources from which the references can be obtained

Modern SRS Package
28
5. Assumptions and Dependencies
 List any assumed factors (as opposed to known facts) that could affect the requirements
stated in the SRS. These could include third-party or commercial components that you plan
to use, issues around the development or operating environment, or constraints.
 The project could be affected if these assumptions are incorrect, are not shared, orchange.
 Also identify any dependencies the project has on external factors, such as software
components that you intend to reuse from another project etc.

Modern SRS Package
29
2 Use Case Model Survey
 This section provides an overview of the use case
model
 This section lists for each use case
 The Use case name
 Brief description explaining use case’s function
 A list of actors for the use case
 Diagram of the use case model
3 Actor Survey
 This section lists the following information for
each actor
 The Actor’s name
 Brief description of the actors

Modern SRS Package
30
4 Requirements
4.1 Functional Requirements
 Itemize the detailed functional requirements associated with the features of vision
document
 These are the software capabilities that must be present in order for the user to
carry out the
services provided by the feature.
 Include how the product should respond to anticipated error conditions or invalid
inputs. Requirements should be concise, complete, unambiguous, verifiable, etc.
 Each requirement should be uniquely identified with a sequence number or a
meaningful tag of
some kind.
 REQ-1:
 REQ-2:

Modern SRS Package
31
4 Requirements
4.2 Non-Functional
Requirements
produc
t
should be
listed
 All the non functionalrequirements
associated with the here
 The Non- Functional Requirements can be of the
following::
 Usability
 Reliability
 Performanc
e
 Supportabili
ty
 Safety
 Security

32
5
Use
r
Documentati
on
and
Hel
p
Syste
m
Requireme
nts
 use
r
Describes the requirements if any for
online documentation, help
systems, help notices and so on
6 Design
Constraints



This section includes any design constraints on the
system being built.
Design constraints represent design decisions that
have been mandated and must be adhered to.
Examples include software languages, prescribed
use of developmental tools, specific architectural
constraints, mandated use of class libraries, and
so on.
Modern SRS Package

33
7 Purchased Components
 This section describes any purchased components to be used with
the system
8 Interfaces
the
interface
s
tha
t
mu
st
be
supporte
d
by
th
e
 This section
defines application
1. User Interfaces
2. Hardware
Interfaces
3. Software Interfaces
8.4 Communication
Interfaces
Modern SRS Package

34
9 Licensing and Security
Requirements
 This section includes any licensing
requirements
and accessibility, encryption
of
 This section may also define
requirements for security source code or user
data, and so on.
disclaimers, including
warranties,
10 Legal, Copyright, and Other
Notices
 This section includes any necessary
legal copyright notices, patent notices, or logo.
the
specific
11 Applicable Standards
 This section includes by reference
any sections of any such standards
that apply
applicable standards
and to the
system being built.
Modern SRS Package

35
is provided to assistthe reader in
locating
concepts and topics that occur
throughout the
Index
 The
index
the key
documen
t
Glossar
y
 Define all the terms necessaryto properly
interpret
the SRS, including acronyms and abbreviations or
other
project or company specific terms necessaryfor
the
understanding of this document and the
application
Appendixes
 It includes the details of use case diagrams (Flow of
events, additional paths, preconditions, post
conditions etc.)
 Also include other diagrams like ERD diagrams, class
diagrams, state-transition diagrams, Sequence
diagrams etc.
Modern SRS Package

For any query Feel Free to ask
36

SRE-Week-09-Refining-the-system-definition-05052023-114706pm.pptx

Recomendados

Recomendados

Más contenido relacionado

Similar a SRE-Week-09-Refining-the-system-definition-05052023-114706pm.pptx

Similar a SRE-Week-09-Refining-the-system-definition-05052023-114706pm.pptx (20)

Último

Último (20)

SRE-Week-09-Refining-the-system-definition-05052023-114706pm.pptx

Notas del editor