University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Lecture 9: Specifications Software Requirements Specification

Last
Last Week:
Modeling
Modelingand
Week:
andAnalysis
Analysis(III)
(III)
➜ How do we communicate the Requirements to others?
Formal
FormalModeling
ModelingTechniques
Techniques ª It is common practice to capture them in an SRS
Program Spec. vs. Reqts Modeling
Program Spec. vs. Reqts Modeling ¾ But an SRS doesn’t need to be a single paper document...
RSML,
RSML,SCR,
SCR,RML,
RML,Telos,
Telos,Albert
AlbertII
II
Lightweight
Lightweightformal
formalmodeling
modeling ➜ Purpose ➜ Audience
ª Communicates an understanding of ª Users, Purchasers
the requirements ¾Most interested in system requirements
¾explains both the application domain ¾Not generally interested in detailed
This
This Week:
Week: and the system to be developed software requirements
Communicating
Communicating Requirements
Requirements ª Contractual ª Systems Analysts, Requirements
the
theSoftware
SoftwareRequirements
RequirementsSpecification
Specification(SRS)
(SRS) ¾May be legally binding! Analysts
Documentation
DocumentationStandards
Standards ¾Expresses an agreement and a ¾Write various specifications that inter-
Requirements
RequirementsTraceability
Traceability commitment relate
ª Baseline for evaluating subsequent ª Developers, Programmers
products ¾Have to implement the requirements
¾supports system testing, verification ª Testers
and validation activities
Next
Next Week:
Week: ¾Determine that the requirements have
¾should contain enough information to
Agreeing
AgreeingRequirements
Requirements
been met
verify whether the delivered system
Reviews
Reviewsand
andInspections
Inspections meets requirements ª Project Managers
Negotiation
Negotiation ¾Measure and control the analysis and
Prioritization ª Baseline for change control
Prioritization development processes
¾requirements change, software evolves
© 2001, Steve Easterbrook 1 © 2001, Steve Easterbrook 2

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

A complication: Procurement Appropriate Specification

➜ An ‘SRS’ may be written by: Source: Adapted from Blum 1992, p154-5

ª the procurer ➜ Consider two different projects:

¾ the SRS is then really a call for proposals
A) Small project, 1 programmer, 6 months
¾ Must be general enough to yield a good selection of bids…
programmer talks to customer, then writes up a 5-page memo
¾ …and specific enough to exclude unreasonable bids
ª the bidders B) Large project, 50 programmers, 2 years
¾ Represents a proposal to implement a system to meet the CfP team of analysts model the requirements, then document them in a 500-page SRS
¾ must be specific enough to demonstrate feasibility and technical competence
¾ …and general enough to avoid over-commitment Project A Project B
ª the selected developer Crystalizes programmer’s Build-to document; must
¾ reflects the developer’s understanding of the customers needs
Purpose of spec? understanding; feedback contain enough detail for
¾ forms the basis for evaluation of contractual performance
ª or by an independent RE contractor to customer all the programmers
Spec is irrelevant; have Will use the spec to
➜ Choice over what point to compete the contract Management
already allocated estimate resource needs
ª Early (conceptual stage) view?
resources and plan the development
¾ can only evaluate bids on apparent competence & ability
ª Late (detailed specification stage) Primary: Spec author; Primary: all programmers
¾ lots of work for the procurer Readers? Secondary: Customer + V&V team, managers;
¾ ...and the appropriate RE expertise may not be available in-house! Secondary: customers
ª IEEE Standard recommends SRS jointly developed by procurer and developer
© 2001, Steve Easterbrook 3 © 2001, Steve Easterbrook 4
 University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Desiderata for Specifications

Source: Adapted from Blum 1992, pp164-5 and the IEEE-STD-830-1993
There is no Perfect SRS!
➜ Valid (or “correct”) ➜ Necessary ambiguous
ambiguous
ª expresses actual requirements ª doesn’t contain anything that isn’t expand
expand
“required”
➜ Complete condense
ª Specifies all the things the system ➜ Unambiguous

formalize
must do ª every statement can be read in redundant
redundant inconsistent
inconsistent
ª ...and all the things it must not do! exactly one way reduce
ª Responses to all classes of input ª define confusing terms in a glossary
ª Structural completeness, and no resolve
TBDs!!
➜ Verifiable
ª a process exists to test satisfaction add
➜ Consistent of each requirement
explanations
ª “every requirement is specified not
not understandable
understandable
ª doesn’t contradict itself (I.e. is
satisfiable) behaviorally”
ª Uses all terms consistently
➜ Understandable (Clear)
ª Note: timing and logic are especially
ª by non-computer specialists
prone to inconsistency incomplete
incomplete
Modifiable
➜
…etc!
ª It must be kept up to date!

© 2001, Steve Easterbrook 5 © 2001, Steve Easterbrook 6

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Typical mistakes SRS should not include

ª Noise ª Jigsaw puzzles
¾ the presence of text that carries no
relevant information to any feature of the
¾ e.g., distributing requirements across ➜ Project development plans
a document and then cross- ¾ cost, staffing, schedules, methods, tools, etc
problem. referencing
ª Silence ª Lifetime of SRS is until end of operations phase
ª Duckspeak requirements
¾ a feature that is not covered by any text. ¾ Requirements that are only there to
ª Lifetime of development plans is much shorter
ª Over-specification conform to standards
¾ text that describes some feature of the ª Unnecessary invention of terminology ➜ Product assurance plans
solution, rather than the problem. ¾ E.g., ‘user input/presentation ¾ CM, V&V, test, QA, etc
ª Contradiction function’, ‘airplane reservation data ª Different audiences
¾ text that defines a single feature in a validation function’
ª Different lifetimes
number of incompatible ways. ª Inconsistent terminology
ª Ambiguity ¾ Inventing and then changing
terminology
➜ Designs
¾ text that can be interpreted in at least
two different ways. ª Requirements and designs have different audiences
ª Putting the onus on the development
ª Forward reference staff ª Analysis and design are different areas of expertise
¾ text that refers to a feature yet to be ª Writing for the hostile reader ¾ I.e. requirements analysts shouldn’t do design!
defined. ¾ There are fewer of these than ª Except where application domain constrains the design
ª Wishful thinking friendly readers ¾ e.g. limited communication between different subsystems for security reasons.
¾ text that defines a feature that can not
possible be validated.
© 2001, Steve Easterbrook
Source: Adapted from Kovitz, 1999 7 © 2001, Steve Easterbrook
Source: Adapted fromDavis, 1990, p183 8
 University of Toronto
Text Analysis to measure Quality
➜ Can do textual analysis of an
SRS
ª measure current practice
ª establish norms for an organisation
➜ E.g. NASA SEL used nine
quality indicators:
ª Imperatives
¾identified by words such as “shall”,
“must”, “is required”, etc.
¾Imperatives measure how explicit a
SRS is.
ª Continuances follow an imperative and
introduce requirements
¾indicated by “below:”, “as follows:”
etc.
¾measure the structure of an SRS.
ª Option
¾indicated by words such as “can”,
“may”, “optionally” etc.
¾measure how much latitude does an
SRS leave
© 2001, Steve Easterbrook
University of Toronto
Avoiding ambiguity
➜ Review natural language specs for ambiguity
ª use people with different backgrounds
ª include software people, domain specialists and user communities
ª Must be an independent review (I.e. not by the authors!)
➜ Use a specification language
ª E.g. a restricted subset of English
ª E.g. a semi-formal notation (graphical, tabular, etc)
ª E.g. a formal specification language (e.g. Z, VDM, SCR, …)
➜ Exploit redundancy
ª Restate a requirement to help the reader confirm her understanding
ª ...but clearly indicate the redundancy
ª May want to use a more formal notation for the re-statement
© 2001, Steve Easterbrook
Department of Computer Science University of Toronto Department of Computer Science
Ambiguity Test
ª Weak phrases
¾cause uncertainty
➜ “The system shall report to the operator all faults
¾e.g. “adequate”, “as applicable” etc. that originate in critical functions or that occur
ª Directives
¾indicated by tables, figures etc
during execution of a critical sequence and for which
¾these strengthen the quality of the there is no fault recovery response.”
document
ª Size
¾…in terms of lines of text, indicators
and subjects
¾roughly, the number of subjects for all
the imperatives
Originate in critical functions F T F T F T F T
ª Text structure
¾measures the number of statement
identifiers Occur during critical seqeunce F F T T F F T T
ª Specification depth
No fault recovery response F F F F T T T T
¾measures how deep are the subsections
of the SRS (e.g., 3.2.5.1)
¾gives an indication of SRS structure. Report to operator?
ª Readability statistics
¾e.g average number of syllables per
word, number of words per sentence
etc.
9 © 2001, Steve Easterbrook
Source: Adapted from Easterbrook & Callahan, 1997. 10
Department of Computer Science University of Toronto Department of Computer Science
SRS format and style
➜ Modifiability
ª well-structured, indexed, cross-referenced, etc.
ª redundancy should be avoided or must be clearly marked as such
ª An SRS is not modifiable if it is not traceable...
➜ Traceability
ª Backwards: each requirement traces to a source
¾ e.g. a requirement in the system spec; a stakeholder; etc)
ª Forwards: each requirement traces to parts of the design that satisfy that
requirement
ª Note: traceability links are two-way
¾ hence other documents must trace into the SRS
¾ Every requirement must have a unique label.
➜ Useful Annotations
ª E.g. relative necessity and relative stability
11 © 2001, Steve Easterbrook
Source: Adapted from Davis, 1990, p192-5 12
 University of Toronto Department of Computer Science University of Toronto Department of Computer Science

IEEE Standard for SRS

Source: Adapted from IEEE-STD-830-1993 See also, Blum 1992, p160
IEEE STD Section 3 (example)
Source: Adapted from IEEE-STD-830-1993. See also, Blum 1992, p160

Identifies the product, &

➜ 11 Introduction
➜ Introduction application domain 3.1 External Interface 3.3 Performance Requirements
ªªPurpose
Purpose Requirements Remember to state this in measurable
ªªScope terms!
Scope Describes contents and structure 3.1.1 User Interfaces
ªªDefinitions,
Definitions,acronyms,
acronyms,abbreviations of the remainder of the SRS
abbreviations 3.1.2 Hardware Interfaces 3.4 Design Constraints
ªªReference documents
Reference documents 3.1.3 Software Interfaces
Describes all external interfaces: 3.4.1 Standards compliance
ªªOverview
Overview 3.1.4 Communication Interfaces
system, user, hardware, software; 3.4.2 Hardware limitations
also operations and site adaptation,
➜ 22 Overall
Overall Description 3.2 Functional Requirements etc.
➜ Description and hardware constraints
ªªProduct
Productperspective
perspective this section organized by mode, user 3.5 Software System
ªªProduct class, feature, etc. For example:
Productfunctions
functions Summary of major functions Attributes
ªªUser 3.2.1 Mode 1
Usercharacteristics
characteristics 3.5.1 Reliability
Anything that will limit the 3.2.1.1 Functional Requirement 1.1
ªªConstraints
Constraints developer’s options (e.g. regulations, … 3.5.2 Availability
ªªAssumptions
Assumptionsand
andDependencies
Dependencies reliability, criticality, hardware 3.2.2 Mode 2 3.5.3 Security
limitations, parallelism, etc)
➜ 33 Specific
Specific Requirements
3.2.1.1 Functional Requirement 1.1 3.5.4 Maintainability
➜ Requirements …
3.5.5 Portability
➜ Appendices
All the requirements go in here (I.e. ...
➜ Appendices this is the body of the document).
IEEE STD provides 8 different
3.2.2 Mode n 3.6 Other Requirements
➜ Index
➜ Index templates for this section
...

© 2001, Steve Easterbrook 13 © 2001, Steve Easterbrook 14

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

MIL-STD-498 System Structure

➜ MIL-STD-498 is the main DOD standard for ➜ MIL-STD-498 uses the following system structure:
software development and documentation
ª replaces DOD-STD-2167A and DOD-STD7935A H W CI= H ardw are
Configuration Item

Consists of:
System or Segment
➜ CSCI= Com puterSoftw are (SSS)
ª a guidebook, Configuration Item

ª a list of process requirements

ª 22 Data Items Descriptions (DIDs)
System or Segment System or Segment
➜ DIDs are the documents produced during software (SSS) (SSS)
development. e.g.
ª OCD - Operational Concept Description
ª SSS - System/Subsystem Specification
ª SRS - Software Requirements Specification
CSCI CSCI HWCI CSCI CSCI HWCI Interfaces
ª IRS - Interface Requirements Specification (SRS) (SRS) (PIDS) (SRS) (SRS) (PIDS) (IRS)
ª etc
© 2001, Steve Easterbrook
Source: Adapted from MIL-STD-498 15 © 2001, Steve Easterbrook
Source: Adapted from MIL-STD-498 16
 University of Toronto Department of Computer Science University of Toronto Department of Computer Science

SRS DID from MIL-STD-498 Requirements Traceability

1 Scope 3.8 Security and Privacy Requirements
1.1 Identification 3.9 CSCI Environment Requirements ➜ Definition (DOD-STD-2167A):
1.2 System Overview 3.10 Computer Resource Requirements “(1) The document in question contains or implements all applicable
1.3 Document Overview 3.11 Software Quality Factors stipulations in the predecessor document
3.12 Design and Implementation
2 Referenced Documents Constraints
(2) a given term, acronym, or abbreviation means the same thing in all
documents
3 Requirements 3.13 Personnel-related Requirements
(3) a given item or concept is referred to by the same name or description
3.14 Training-related Requirements
3.1 Required States and Modes in the documents
3.2 CSCI Capability Requirements 3.15 Logistics-related Requirements
(4) all material in the successor document has its basis in the predecessor
3.2.x Capability X… 3.16 Other Requirements
document, that is, no untraceable material has been introduced
3.3 CSCI External Interface 3.17 Packaging Requirements
Requirements (5) the two documents do not contradict one another”
3.18 Precedence and criticality of
3.3.1 Interface Identification and Requirements
diagrams ➜ In short:
3.3.x Project Unique Identifier 4 Qualification Provisions
ª A demonstration of completeness, necessity and consistency
3.4 CSCI Internal Interface
Requirements 5 Requirements Traceability ª a clear allocation/flowdown path (down through the document hierarchy)
3.5 CSCI Internal Data Requirements 6 Notes ª a clear derivation path (up through the document hierarchy)
3.6 Adaptation Requirements
3.7 Safety Requirements Appendices
© 2001, Steve Easterbrook
Source: Adapted from MIL-STD-498 17 © 2001, Steve Easterbrook
Source: Adapted from Palmer, 1996, p 367 18

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Importance of Traceability Traceability Difficulties

➜ Verification and Validation ➜ Document access ➜ Cost
ª assessing adequacy of test suite ª ability to find information quickly in
ª very little automated support
ª assessing conformance to large documents
requirements ª full traceability is very expensive and time-consuming
ª assessing completeness, consistency,
➜ Process visibility
impact analysis ª ability to see how the software was ➜ Delayed gratification
developed
ª assessing over- and under-design ª the people defining traceability links are not the people who benefit from it
ª provides an audit trail
ª investigating high level behavior ¾ development vs. V&V
impact on detailed specifications
➜ Management ª much of the benefit comes late in the lifecycle
ª detecting requirements conflicts
ª change management ¾ testing, integration, maintenance
ª checking consistency of decision
ª risk management
making across the lifecycle
ª control of the development process
➜ Size and diversity
➜ Maintenance ª Huge range of different document types, tools, decisions, responsibilities,…
ª Assessing change requests ª No common schema exists for classifying and cataloging these
ª Tracing design rationale ª In practice, traceability focuses on baselined requirements

© 2001, Steve Easterbrook

Source: Adapted from Palmer, 1996, p365 19 © 2001, Steve Easterbrook
Source: Adapted from Palmer, 1996, p365-6 20
 University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Current Practice Traceability Tools

➜ Coverage: ➜ Approaches: ➜ Examples
ª hypertext linking ª single phase tools:
ª links from requirements forward to designs, code, test cases,
¾ hotwords are identified manually, tool ¾TeamWork (Cadre) for structured
ª links back from designs, code, test cases to requirements records them analysis

ª links between requirements at different levels ª unique identifiers ª database tools, with queries and
¾ each requirement gets a unique id; report generation

Traceability process
database contains cross references ¾RTM (Marconi)
➜ ª syntactic similarity coefficients ¾SLATE (TD Technologies)
ª Assign each sentence or paragraph a unique id number ¾ searches for occurrence of patterns of ¾DOORS (Zycad Corp)
words ª hypertext-based tools
ª Manually identify linkages
¾Document Director
ª Use manual tables to record linkages in a document ➜ Limitations ¾Netscape Navigator
ª Use a traceability tool (database) for project wide traceability ª All require a great deal of manual ª general development tools that
effort to define the links provide traceability
ª Tool then offers ability to
ª All rely on purely syntactic ¾RDD-100 (Ascent Logic) - documents
¾ follow links information, with no semantics or system conceptual models
¾ find missing links context ¾Foresight - maintains data dictionary
and document management
¾ measure overall traceability

© 2001, Steve Easterbrook

Source: Adapted from Palmer, 1996, p367-8 21 © 2001, Steve Easterbrook
Source: Adapted from Palmer, 1996, p372 22

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Limitations of Current Tools Problematic Questions

➜ Involvement
➜ Informational Problems ª Who has been involved in the production of this requirement and how?
ª Tools fail to track useful traceability information
¾ e.g cannot answer queries such as “who is responsible for this piece of ➜ Responsibility & Remit
information?”)
¾ Who is responsible for this requirement
ª inadequate pre-requirements traceability ¾ who is currently responsible for it
¾ “where did this requirement come from?” ¾ at what points in its life has this responsibility changed hands?
ª Within which group’s remit are decisions about this requirement?
➜ Lack of agreement
ª over quantity and type of information to trace ➜ Change
ª At what points in the life of this requirements has working arrangements
➜ Informal Communication of all involved been changed?
ª People attach great importance to personal contact and informal
communication
➜ Notification
ª Who needs to be involved in, or informed of, any changes proposed to this
ª These always supplement what is recorded in a traceability database
requirement?
ª Result is that traceability database only tells part of the story
ª Even so, finding the appropriate people is a significant problem ➜ Loss of knowledge
ª What are the ramifications regarding the loss of project knowledge if a
specific individual or group leaves?
© 2001, Steve Easterbrook
Source: Adapted from Gotel & Finkelstein, 1993, p100 23 © 2001, Steve Easterbrook
Source: Adapted from Gotel & Finkelstein, 1997, p100 24
 University of Toronto Department of Computer Science

Contribution Structures
➜ ‘author’ attribute too weak
ª does not adequately capture ownership of information
ª refers to person that wrote the document rather than the person who
originated the content
ª fail to capture situations where many people participate
ª fail to capture changing patterns of participation

➜ Contribution structures
ª link requirements artifacts (contributions) to agents (contributors) via
contribution relations

➜ Roles
ª Principal
¾ who motivated the artefact (responsible for consequences)
ª Author
¾ who chose the structure and content (responsible for semantics)
ª Documentor
¾ who recorded/transcribed the content (responsible for appearance)
© 2001, Steve Easterbrook 25