CSDP Preparation Course Module II: Software Requirements

1
CSDP Preparation CourseModule II Software
Requirements
2
Specifications

• The exam specific topics covered in this module
  are listed below, and are the basis for the
  outline of its content.
• Requirements Engineering Process
• Requirements Elicitation
• Requirements Analysis
• Software Requirements Specification
• Requirements Validation
• Requirements Management

3
Objectives

• After completing this module, you should be able
  to
• To present an overview of software requirements
  engineering

4
Organization

• The organization of information for each
  specification topic is as follows
• Topic Content Slides - detail the important
  issues concerning each topic and support the
  module objectives
• Topic Reference Slides - detail the sources for
  the topical content and provides additional
  references for review
• Topic Quiz Slides - allow students to prepare for
  the exam

5
Introduction

• What is Software?
• software -- Computer programs, procedures, and
  possibly associated documentation and data
  pertaining to the operation of a computer system.
  Contrast with hardware. IE610
• What is a Requirement?
• requirement -- (1) A condition or capability
  needed by a user to solve a problem or achieve an
  objective. (2) A condition or capability that
  must be met or possessed by a system or system
  component to satisfy a contract, standard,
  specification, or other formally imposed
  documents. (3) A documented representation of a
  condition or capability as in (1) or (2). IE610

6
Introduction 2

• A Perspective
• These definitions imply concern for the user of
  the software as well as the developer.
• Wiegers emphasizes that the term users in such a
  definition should be generalized to stakeholders,
  because not all stakeholders are users.
• CAUTION Dont assume that all your project
  stakeholders share a common notion of what
  requirements are. Establish definitions up
  front so that youre all talking about the same
  things. KW03, p. 8

7
Introduction 3

• Major Issues in Software Requirements
• The incorrect and incomplete software
  requirements specification
• The truncation of requirements activities over
  programming and testing
• The lack of cooperation by customers
• To verify that the software requirements are
  correct
• To understood the structure and purpose of the
  software requirements specifications
• The problems associated with identifying which
  tool and/or methodology to use in developing and
  representing a software requirements
  specification RT04, p. 4-9

8
Introduction 4

• Fundamentals of Requirements
• In order to properly identify a requirement, we
  may apply the general property distinctions that
  the SWEEBOK Guide has identified SW04, p. D-3
  
• Product and process requirements
• Functional and non-functional requirements
• Emergent properties
• Quantifiable requirements
• System requirements and software requirements

9
Introduction 5

• Product and Process Requirements - I
• Product parameter a requirement on software to
  be developed
• Product requirement Requirements which apply to
  the product of services to be developed
• Qualitative parameters not directly measurable
• Functional What it does
• External Interfaces Data or command inputs or
  outputs
• Quantitative parameters directly measurable
• Performance metrics How fast, how much memory
• Quality metrics Reliability, maintainability,
  security RT04, p. 4-13

10
Introduction 6

• Product and Process Requirements - II
• Process parameter essentially a constraint on
  the development of the software (AKA process
  requirements)
• Process (Program) requirements Applies to the
  activities associated with enabling the creation
  of a product or service
• Task Perform and analyze, develop a product,
  operate a system
• Compliance evaluation Measure compliance with a
  product parameter
• Regulatory/Standards Compliance with laws,
  standards, regulations, and rules

11
Introduction - 7

• Functional and Non-functional Requirements
• Functional requirements describes functions
  software is to execute
• Example formatting text
• Non-functional requirements ones that act to
  constrain the software solution
• Further classes performance, maintainability,
  safety, reliability, and others.

12
Introduction - 8

• Emergent Properties
• Emergent properties those which cannot be
  addressed by a single component, but system
  component interoperability
• Highly sensitive to the system architecture
• Sommerville provides three examples IS01, p.
  22
• Overall weight of the system
• Reliability of the system
• Usability of the system

13
Introduction 9

• Quantifiable Requirements
• Avoid vague and unverifiable requirements which
  depend for their interpretation on subjective
  judgment
• This is critical for non-functional requirements

14
Introduction 10

• System Requirements and Software Requirements
• System requirements - are for the system as a
  whole sometimes referred to as user requirements
  
• Includes hardware, software, firmware, people,
  information, techniques, facilities, services,
  and other support elements
• Software requirements derived from system
  requirements

15
Introduction 11

• Recognizing the Importance of Software
  Requirements Engineering RT04, p. 4-7
• Better quality in the software development
  process and the software product can be obtained
  if our methods and tools for gathering, modeling
  and analyzing user requirements are more
  effective, robust and codified in practice, i.e.
  an engineering approach
• Therefore, software requirements engineering
  (SRE) has emerged as an engineering approach to
  what used to be called requirements analysis and
  specifications

16
Introduction 12

• Role of Software Requirements in the Lifecycle
  RT04, p. 4-17
• Describes what the user wants or needs done
• Describes the final product, not methods and
  techniques for building the software
• Provides the basis for cost, schedule, and other
  resource estimates
• Primarily developed during the requirements phase
  of the lifecycle
• Can be developed in other phases of the lifecycle

17
Introduction Quiz

• 1. Which of the following requirement properties
  would be considered an emergent property of a
  software program?
• The fault detection system of the software
• The programming language of the system
• The reliability of the software
• The number of lines of code

18
Introduction Quiz 2

• 2. Which of the following would most likely be
  considered a product requirement?
• The software shall be written in Ada.
• The student name shall be entered before the
  student grade.
• The system requirements for the software shall be
  formatted according to IEEE Std 1233.
• The software is built with company standards.

19
Introduction Quiz 3

• 3. Which of the following is most true about a
  non-functional requirement?
• Describes functions software is to execute.
• Is highly sensitive to the system architecture.
• Is derived from hardware requirements.
• Acts to constrain the software solution.

20
Introduction References

• IE610 IEEE Std 610.12-1990, Standard Glossary
  of Software Engineering Terminology
• IE1233 IEEE Std 1233-1998, Guide for Developing
  System Requirements
• IS01 Sommerville, Ian, Software Engineering,
  6th Edition, Addison-Wesley, NY, 2001
• KW03 Weigers, Karl E., Software Requirements,
  2nd Edition, Microsoft Press, Redmond, WA, 2003
• RT04 Thayer, Richard, 2004 Certified Software
  Development Professional (CSDP) Preparation
  Course, Chapter 4 Software Requirements
  Engineering Concepts
• SW04 SWEBOK Guide to the Software Engineering
  Body of Knowledge 2004 Version, IEEE Computer
  Society, Los Alamitos, CA, Chapter 2 Software
  Requirements

21
A. Requirements Engineering Process

• A Process Defined
• process -- (1) A sequence of steps performed for
  a given purpose for example, the software
  development process. (2) An executable unit
  managed by an operating system scheduler. (3)
  To perform operations on data. IE610
• Software requirements engineering (SRE) is a
  process, not a discrete activity

22
A. Requirements Engineering Process - 2

• Software Requirements Engineering Process - I
• Collect and categorize the various requirements
  (requirements elicitation)
• Identify relevant sources of requirements
  (usually the customers)
• Determine what information is needed (this will
  change as the requirements are developed)
• Collect the requirements from all parties

23
A. Requirements Engineering Process - 3

• Software Requirements Engineering Process - II
• Analyze the gathered information, looking for
  implications, inconsistencies, or unresolved
  issues (analysis)
• Synthesize appropriate statements of the
  requirements (specifications)
• Confirm your understanding of the requirements
  with the users (verification)
• Plan and control the effort from beginning to end
  (management) RT04, p. 4-20

24
A. Requirements Engineering Process - 4

• SRE Process Activities - I
• Software requirements elicitation The process
  through which the customers (buyers and/or users)
  and developers (contractors) of a software system
  discover, review, articulate, and understand
  their requirements
• Software requirements analysis Reasoning and
  analyzing the customers and users needs to
  arrive at a definition of software requirements

25
A. Requirements Engineering Process - 5

• SRE Process Activities - II
• Software requirements specification A document
  that clearly and precisely records each of the
  requirements of the software system
• Software requirements verification The
  assurance that software requirements
  specifications are in compliance with the system
  requirements, conforms to document standards of
  the requirements phase, and is an adequate basis
  for the architectural (preliminary) design phase
• Software requirements management - Planning and
  controlling the requirements elicitation,
  analysis, and verification activities RT04, p.
  4-19

26
A. Requirements Engineering Process - 6

• Process Models
• Provide a basic outline of the requirements
  process
• Obtaining software requirements is not a discrete
  front-end activity
• Initiated at the beginning of the project, and is
  refined throughout the life cycle
• Software requirements are configuration items for
  management
• The process is adapted to the organization and
  the project
• Four major activities elicitation, analysis,
  specification, and validation

27
A. Requirements Engineering Process - 7

• Process Actors - I
• Those who participate in the process
• The requirements specialist mediates between
  domain of the stakeholder and software engineer
• Always include users (or operators) and customers
  (they may not be the same)

28
A. Requirements Engineering Process - 8

• Process Actors - II
• Typical software stakeholders
• Users Will operate software
• Customers Commissioned the software
• Market analyst Act as proxy customers
• Regulators Authorities from application domains
  (EX banking,)
• Software engineers Have a stake in reusing
  components in successful products must weigh
  their personal against the stake of the customer
• Must negotiate trade-offs with stakeholders to
  their satisfaction, within project constraints
• Stakeholders must be identified before this
  negotiation to occur SW04, p. 2-3

29
A. Requirements Engineering Process - 9

• The Importance of Software Requirements
• These People Depend on SW Req. to
• Acquisition management Establish their needs
• Project management Determine tasks and schedule
  
• System engineers Req. allocated to SW
• Testers Establish what is to be tested
• SW engineers Establish top-level design
• Configuration control Establish req. baseline
• Everyone Guide their effort
• - RT04, p. 4-22

30
A. Requirements Engineering Process - 10

• Process Support and Management
• Linked to the four major process activities
  elicitation, analysis, specification, and
  validation
• Concerned with issue of cost, human resources,
  training, and tools

31
A. Requirements Engineering Process - 11

• Process Quality and Improvement
• Concerned with assessment of the process
• Measured by cost, schedule, and customer
  satisfaction
• Uses
• Process improvement standards and models
• Requirements process measures and benchmarking
• Improvement planning and implementation

32
A. Requirements Engineering Process - 12

• Other Issues in Software Requirements Engineering
  I
• Requirements specifications often do not reflect
  the need and desires of the users and the
  customer
• Software requirements specifications are often
  incomplete and incorrect
• Users knowledge, experience, and cooperation
  greatly influence the quality of the
  specifications
• Developers knowledge of the customer domain
  greatly influence the quality of the
  specifications

33
Requirements Engineering Process 13

• Other Issues in Software Requirements Engineering
  II
• Software requirements are constantly undergoing
  change
• Requirements sometimes specify the software
  design (a design constraint)
• Design is changed without a corresponding change
  in requirements RT04, p. 4-22

34
A. References

• IE610 IEEE Std 610.12-1990, Standard Glossary
  of Software Engineering Terminology
• RT04 Thayer, Richard, 2004 Certified Software
  Development Professional (CSDP) Preparation
  Course, Chapter 4 Software Requirements
  Engineering Concepts
• SW04 SWEBOK Guide to the Software Engineering
  Body of Knowledge 2004 Version, IEEE Computer
  Society, Los Alamitos, CA, Chapter 2 Software
  Requirements

35
A. Quiz

• 1. According to the SWEBOK Guide, what are the
  four major activities of the requirements
  engineering process?
• Identification, specification, construction, and
  testing
• Elicitation, analysis, specification, and
  validation
• Analysis, planning, construction, and
  verification
• Elicitation, planning, construction, and testing
  

36
A. Quiz 2

• 2. Which of the following property is least
  critical to the interaction between process
  actors and the requirements process?
• Process actor identification
• The nature of their stake in the process
• The education of the actor
• The requirements they elicit

37
A. Quiz 3

• 3. The requirements engineering process is
• A discrete front-end activity of the software
  life cycle.
• Initiated at the beginning of a project and
  continues to be refined throughout the lifecycle.
  
• A continuous process that ends when requirements
  are specified and documented.
• The same for each organization and process.

38
A. Quiz 4

• 4. Process quality and improvement relies most on
  which of the following?
• Product operator performance
• Human factors
• Requirements process measures
• Customer preferences

39
A. Quiz 5

• 5. Product requirement validation occurs
  primarily after
• Elicitation
• Analysis
• Specification
• Testing

40
B. Requirements Elicitation

• What is Requirements Elicitation?
• Concerned with where software requirements come
  from and how the software engineers can collect
  them.
• Stakeholders are identified and relationships
  established between the development team and the
  customer
• Also known as requirements capture,
  requirements discovery, and requirements
  acquisition SW04, p. 2-4

41
B. Requirements Elicitation - 2

• Major Issues Involving Requirements Elicitation -
  I
• It is not always clear who your customers or
  users are.
• Your customers/users cannot always state their
  requirements clearly or completely.
• Users dont know what they want they only know
  what they do.
• What they say they want may not be what they need
  or you may begin to define what you think they
  need, instead of what they want.

42
B. Requirements Elicitation - 3

• Major Issues Involving Requirements Elicitation -
  II
• Their concept of the solution may not solve their
  problem.
• The customers or users will have expectations
  that may be unreasonable or unknown to you.
• Not all of your customers or users talk to or
  agree with one another, so you must talk to all
  of them.
• Your customers or users may change. RT04, p.
  4-25

43
B. Requirements Elicitation - 4

• Requirements Sources - I
• From the SWEBOK Guide SW04, p. 2-4
• Goals
• Sometimes called business concern or critical
  success factor
• Provides motivation for the software, but are
  often vaguely formulated
• Focus is to assess the value (relative priority)
  and cost of goals
• A feasibility study can do this at low cost
• Domain knowledge -
• The software engineer needs to be knowledgeable
  of the application domain
• Allows for assessment of that which is not
  articulated

44
B. Requirements Elicitation - 5

• Requirements Sources - II
• Stakeholders
• Also known as Process Actors
• The software engineer needs to identify,
  represent, and manage the viewpoints of many
  different types of stakeholders
• The operational environment
• The environment that software will be executed in
  will reveal system constraints and system element
  interoperability
• The organizational environment
• May impose previously unidentified user processes

45
B. Requirements Elicitation - 6

• Elicitation Techniques - I
• From SWEBOK Guide SW04, p. 2-4
• Once requirements sources have been identified,
  the software engineer can start eliciting
  requirements from them.
• Even if sources are cooperative and articulate,
  the relevant information must be captured.
• Some of these techniques are
• Interviews
• A traditional means of eliciting requirements

46
B. Requirements Elicitation - 7

• Elicitation Techniques - II
• Scenarios
• Provides a context for elicitation of user
  requirements
• Asks what if and how is this done questions
• The most common type of scenario is the use case
• Link to Conceptual Modeling because of scenario
  notations such as use cases and diagrams are
  common in modeling software
• Prototypes
• Form paper mock-ups of screen designs to
  beta-test versions of software products
• Valuable tool for clarifying unclear requirements
  
• Overlap for use in requirements elicitation and
  requirements validation

47
B. Requirements Elicitation 8

• Elicitation Techniques - III
• Facilitated meetings
• A group of people may bring more insight to
  achieve a summative effect to the requirements
• Conflicting requirements may surface earlier in
  this setting
• Beware of stakeholder politics
• Observation
• Software engineers are immersed in the
  environment to observe the user interact between
  the software and other users
• Expensive to implement
• Helps reveal process subtleties and complexities

48
B. Requirements Elicitation 9

• ConOps - An Elicitation Tool - I
• Definition concept of operations (ConOps)
  document A user oriented document that
  describes a systems operational characteristics
  from the end users viewpoint. IE1362,
  Definition 3.4
• It describes the user organization(s),
  mission(s), and organizational objectives from an
  integrated systems point of view.
• Applied to all types of software intensive
  systems software-only or software/hardware/peopl
  e systems

49
B. Requirements Elicitation 10

• ConOps - An Elicitation Tool - II
• Describes the users general system goals,
  missions, function, and components
• Helps bring the users views and expectations to
  the surface
• Provides an outlet for the users wishes and
  wants
• Helps the user feel in control
• May or may not be the responsibility of the
  acquisition manager RT04, p. 4-29

50
B. Requirements Elicitation 11

• The ConOps Document Style
• A ConOps document must be written in the users
  language using the users format
• A ConOps document should be written in narrative
  prose (in contrast to a technical requirements
  specification)
• ConOps should make use of visual forms (diagrams,
  illustrations, graphs, etc.) and storyboards
  wherever possible
• ConOps provides a bridge between the user needs
  and the developers technical requirements
  documents RT04, p. 4-28

51
B. Requirements Elicitation 12

• Elements of IEEE 1362 (ConOps) - I
• Clauses describe essential elements
• Provides information the writer wants the reader
  to know prior to reading the document
• Title and revision notice
• Project name
• Version number of the document,
• Date of release,
• Approval signatures,
• A list of sub clauses that have been changed in
  the current version of the document

52
B. Requirements Elicitation 13

• Elements of IEEE 1362 (ConOps) - II
• Scope (Clause 1)
• Identification
• Document overview
• System overview
• Referenced documents (Clause 2)
• Current system or situation (Clause 3)
• Background, objectives, and scope
• Operational policies and constraints
• Description of the current system or situation
• Modes of operation for the current system or
  situation
• User classes and other involved personnel (Note)

53
B. Requirements Elicitation 14

• Elements of IEEE 1362 (ConOps) - III
• Justification for and nature of changes (Clause
  4)
• Justification for changes
• Description of desired changes
• Priorities among changes
• Changes considered but not included
• Assumptions and constraints
• Concepts for the proposed system (Clause 5)
• Background, objectives and scope
• Operational policies and constraints
• Description of the proposed system
• Modes of operation
• User classes and other involved personnel (Note)

54
B. Requirements Elicitation 15

• Elements of IEEE 1362 (ConOps) - IV
• Operational scenarios (Clause 6)
• Summary of impacts (Clause 7)
• Operation impacts
• Organizational impacts
• Impacts during development
• Analysis of the proposed system (Clause 8)
• Summary of improvements
• Disadvantages and limitations
• Alternatives and trade-offs considered
• Notes (Clause 9)
• Appendices of the ConOps
• Glossary of the ConOps

55
B. References

• IE1362 IEEE Std 1362-1998, Guide for
  Information Technology System Design Concept
  of Operations Document
• JC04 Cleland-Huang, Jane, Software
  Requirements, in R.H. Thayer and M. Carstensen,
  Software Engineering, Vol. 1 The Development
  Process. IEEE Computer Society Press, Los
  Alamitos, CA 2004
• RT04 Thayer, Richard, 2004 Certified Software
  Development Professional (CSDP) Preparation
  Course, Chapter 4 Software Requirements
  Engineering Concepts
• SW04 SWEBOK Guide to the Software Engineering
  Body of Knowledge 2004 Version, IEEE Computer
  Society, Los Alamitos, CA, Chapter 2 Software
  Requirements

56
B. Quiz

• As requirements are elicited, what source is most
  likely to impose previously unidentified user
  processes?
• The organizational environment
• The operational environment
• Stakeholders
• Application domain specialists

57
B. Quiz 2

• 2. What is considered the traditional means or
  requirements elicitation?
• Observations
• Scenarios
• Interviews
• Prototypes

58
B. Quiz 3

• 3. What is the most common type of scenario
  elicitation technique?
• The prototype
• The use case
• The facilitator meeting
• Observation

59
B. Quiz 4

• 4. Which technique overlaps for use in
  requirements elicitation and requirements
  validation?
• Prototypes
• Facilitator meetings
• Interviews
• Observations

60
B. Quiz 5

• 5. A concept of operations document (ConOps)
  should not be written
• In the users language using the users format
• Mostly in narrative prose
• With visual forms
• Primarily in the developers technical language

61
B. Quiz 6

• 6. In the IEEE Std 1362 Concept of Operations
  (ConOps) Document, which of the following is
  fundamentally not included under the Concepts for
  the Proposed System (Clause 5)?
• Proposed design method of system
• Operational policies and constraints
• Description of the proposed system
• Modes of operation

62
B. Quiz 7

• 7. In the IEEE Std 1362 Concept of Operations
  (ConOps) Document, which of the following is
  fundamentally not included in the document?
• Current system or situation
• Proposed design method of system
• Justification for the nature of the change
• Operational scenarios

63
C. Requirements Analysis

• Definitions
• software requirements analysis --
• (1) The process of studying user needs to arrive
  at a definition of system, hardware, or software
  requirements.
• (2) The process of studying and refining system,
  hardware, or software requirements. IE610
• (3) Reasoning and analyzing the customers and
  users needs to arrive at a definition of software
  requirements. RT02, p. 93

64
C. Requirements Analysis 2

• First, Find Requirements Sources
• Systems requirements specifications
• Statements of work (SOW) and procurement
  specifications
• Customer prepared needs documents
• Concept of operations (ConOps) documents
• Observations and measurements of the current
  system
• Interviews with the customers and users
• Current system documentation
• Feasibility studies
• Models and prototypes RT04, p. 4-33

65
C. Requirements Analysis 3

• Software Requirements Analysis - I
• Software requirements analysis The process of
• Studying and refining system, hardware, or
  software requirements IE610
• Determining the feasibility of the requirements
• Detecting and resolving conflicts between
  requirements
• Discovering the system boundaries and its
  external interfaces
• Conducting trade-offs between requirement
  features
• Producing of the software requirements
  specification

66
C. Requirements Analysis 4

• Software Requirements Analysis - II
• Other activities during the requirement analysis
  phase
• Determine the project management plan
• Determine the test plan and test specifications
• Determine draft users manual
• Determine the system interfaces RT04, 4-32

67
C. Requirements Analysis 5

• Distinct Processes of Requirements Analysis
• The SWEBOK has identified several distinct
  processes that occur during a successful
  requirements analysis
• Requirements classification (RC)
• Helps to inform trade-offs
• Conceptual modeling (CM)
• To understand the problem
• Architectural design and requirements allocation
  (AD RA)
• What parts will meet requirements
• Requirements negotiation (RN)
• Establishes trade-offs

68
C. Requirements Analysis 6

• Requirements Classification - I
• Several dimensions
• Whether it is functional or non-functional
• Whether it is derived from high-level requirement
  or is emergent
• Imposed by stakeholder or other source
• Whether it is on the product or the process

69
C. Requirements Analysis 7

• Requirements Classification - II
• The requirement priority The higher, the more
  essential
• The requirement scope A global requirement may
  affect architecture
• Volatility/stability Identification for
  tolerant design
• Others are possible, and some may overlap

70
C. Requirements Analysis 8

• RC / Attributes - I
• Each Software Requirement Shall Have
• Identifier Every requirement must be assigned a
  unique identifier that allows it to be
  unambiguously referenced.
• Source The source of the requirement may be
  (e.g.) a stakeholder from whom it was elicited or
  a higher-level requirement from which it was
  derived
• Date When the requirement was formulated

71
C. Requirements Analysis 9

• RC / Attributes - II
• Each Software Requirement Shall Have
• Rationale The rationale explains the purpose of
  the requirement. This helps subsequent analysis,
  particularly if the requirement is challenged or
  needs to be reworked at a later stage.
• Type This attribute records, for example,
  whether the requirement is functional or
  non-functional whether it is a user interface
  requirement, a safety requirement, etc., or it is
  an original requirement or a derived requirement
• Priority Each requirement need to be
  prioritized in relationship to other
  requirements, e.g., essential, conditional,
  optional (IEEE Std 830)

72
C. Requirements Analysis 10

• RC / Attributes - III
• Each Software Requirement Shall Have
• Stability Uncertainty surrounds a requirement
  should be recorded so that its likely volatility
  is made explicit and appropriate risk containment
  measures can be taken.
• Verification procedure This attribute defines
  how to verify that the requirement has been
  satisfied once the software has been implemented.
  
• Status The requirements status records its
  current position in the life-cycle of the
  requirement. RT04, p. 4-43,44

73
C. Requirements Analysis 11

• RC / Types of Software Requirements I
• Functional requirements A requirement that
  specifies a function that a system or system
  component must be capable of performing
• Performance requirements A requirement that
  specifies a performance characteristic that a
  system or system component must posses
• For example, speed, accuracy, or frequency
• External interface requirements A requirement
  that specifies a hardware, software, or database
  element with which a system component must
  interface, or that sets forth constraints on
  formats, timing or other factors caused by such
  an interface

74
C. Requirements Analysis 12

• RC / Types of Software Requirements II
• Design constraints A requirement that impacts
  or constrains the design of a software system or
  system component (sometimes called a negative
  requirement)
• For example, functional requirements, physical
  requirements, performance requirements, software
  development standards, software quality assurance
  standards
• Quality Attributes A requirement that
  specifies the degree of an attribute that affects
  the quality the software must possess
• For example correctness, reliability,
  maintainability, or portability RT04, 4-35

75
C. Requirements Analysis 13

• RC / Examples of Design Constraints
• Execution speed Use maximum of 50 of available
  cycle time (also called performance requirement)
• Language Use Ada
• Maintenance Meet available requirements of 0.98
  (also called quality attribute)
• Human computer interface Menus are require for
  system interface
• Memory utilization Use maximum of 75 of
  available memory (also called performance
  requirements)
• Reliability Meet reliability requirements of
  0.99 (also called quality attributes)
• Security Meet security requirements of 4 hours
  to break into the system (also called quality
  attributes)

76
C. Requirements Analysis 14

• RC / Examples of Quality Requirements
• Reliability Probability that the software will
  perform its logical operation in the specified
  environment without failure
• Survivability Probability that the software
  will continue to perform or support critical
  functions when a portion of the system is
  inoperable
• Maintainability - Average effort required to
  locate and fix a software failure
• User friendliness The degree of ease of use or
  learning of a software system
• Securability The probability that the software
  system can be made secure for a predetermined
  amount of time

77
C. Requirements Analysis 15

• Conceptual Modeling I
• Their purpose is to aid in understanding the
  problem, not begin a design solution
• Types of models include data and control flows,
  state models, event traces, and others
• Factors that influence choice of model
• The nature of the problem
• The expertise of the software engineer
• The process requirements of the customer
• The availability of methods and tools

78
C. Requirements Analysis 16

• Conceptual Modeling II
• Useful to start with building model of the
  software context
• explains operational environment and identifies
  interfaces
• UML (Unified Modeling Language) is a widely used
  set of notations

79
C. Requirements Analysis 17

• CM / Structured Analysis (Yourdon)
• RT04, p. 4-38

80
C. Requirements Analysis 18

• CM / Real Time Structured Analysis (Ward
  Miller)
• RT04, p. 4-39

81
C. Requirements Analysis 19

• CM / Object-Oriented Analysis (Object Diagram)
• RT04, p. 4-40

82
C. Requirements Analysis 20

• CM / Use Cases

83
C. Requirements Analysis - 21

• Architectural Design and Requirements Allocation
• Point the requirements process overlaps with
  software or system design.
• Allocation is the assigning of responsibility to
  components for satisfying requirements.
• Permits detailed analysis of requirements
• Allows requirements to be broken down further
• IEEE Std 1471-2000 is a Recommended Practice for
  Architectural Description of Software Intensive
  Systems

84
C. Requirements Analysis - 22

• Requirements Negotiation
• Also known as conflict resolution
• Conflicts between stakeholders arise from
  differences
• Between incompatible features
• Between requirements and resources
• Between functional and non-functional
  requirements
• Unwise for software engineer to make unilateral
  decision
• Consultation leads to consensus trade-off
• Decision traceable back to the customer for
  contractual reasons

85
C. References

• IE610 IEEE Std 610.12-1990, Standard Glossary
  of Software Engineering Terminology
• RT02 Thayer, Richard H., Software Engineering,
  Volume 1 The Development Process, 2nd Edition,
  IEEE Computer Society, Los Alamitos, CA, 2002
• RT04 Thayer, Richard H., 2004 Certified
  Software Development Professional (CSDP)
  Preparation Course, Chapter 4 Software
  Requirements Engineering Concepts
• SW04 SWEBOK Guide to the Software Engineering
  Body of Knowledge 2004 Version, IEEE Computer
  Society, Los Alamitos, CA, Chapter 2 Software
  Requirements

86
C. Quiz

• Which dimension of requirement classification is
  critical for consideration of tolerant design?
• Whether the requirement is functional or
  non-functional.
• Whether the requirement is on the product or
  process.
• Whether the requirement is volatile or stable.
• Whether the requirement is a high or low
  priority.

87
C. Quiz 2

• 2. What is the most important attribute of a
  requirement?
• Identifier
• Source
• Verification procedure
• Priority

88
C. Quiz 3

• 3. Which of the following is not a type of
  software requirement?
• Functionality
• Performance
• External Interface
• Complexity

89
C. Quiz 4

• 4. What does allocation try to satisfy in the
  assigning of responsibility to components?
• Requirements
• Validation
• External interfaces
• Testing

90
C. Quiz 5

• 5. What is a software engineer most likely to
  resolve by making a unilateral decision?
• Differences between incompatible features
• Differences between developer perception and
  developer reality
• Differences between requirements and resources
• Differences between functional and non-functional
  requirements

91
D. Software Requirements Specification

• Two Descriptions
• software requirements specification (software
  requirements) 1. A document that specifies the
  requirements for a system or component.
  Typically included are functional requirements,
  performance requirements, interface requirements,
  design requirements, and development standards.
  IE610 2. A document that clearly and
  precisely records each of the requirements of the
  software system. RT02, p. 143
• In software engineering jargon, software
  requirements specification typically refers to
  the production of a document, or its electronic
  equivalent, which can be systematically reviewed,
  evaluated, and approved. SW04, p. 2-7

92
D. Software Requirements Specification - 2

• Role in Software Development
• Foundation for the software project
• Describes the system to be delivered
• Separates essential, desirable, and optional
  requirements
• Identifies which items are stable and which might
  be volatile
• States problems, not solutions
• States what not how RT04, p. 4-47

93
D. Software Requirements Specification - 3

• In Context with Other Requirement Documents
• The System Definition Document defines
  high-level system requirements
• System Requirements Specification for system
  components
• Software Requirements Specification for
  software components of the system

94
D. Software Requirements Specification 4

• The System Definition Document
• Sometimes known as the user requirements document
  or concept of operations document
• Records the system requirements
• Defines high level system requirements in
  language/terms understood by the system users or
  customers
• It may include conceptual models, usage
  scenarios, data, information, or workflows to
  illustrate the system concept SW04, p. 2-7
• The IEEE Std 1362 is a guide which describes the
  elements of a ConOps document

95
D. Software Requirements Specification 5

• IEEE 1362 - The ConOps Document
• The IEEE Std 1362 is a guide which describes the
  elements of a ConOps document

96
D. Software Requirements Specification 6

• System Requirements Specification (SyRS)
• Software is always an element of a larger system
• EXAMPLES Airplanes, the Space Shuttle, a cell
  phone
• Is a systems engineering activity
• System requirements are specified here, not
  software requirements
• Software requirements are derived from the system
  requirements
• The requirements for the software components of
  the system are then specified SW04, p. 2-7
• The IEEE Std 1233 is a guide for developing
  system requirements specifications

97
D. Software Requirements Specification 7

• IEEE Std 1233 (SyRS)
• Recommended practice for developing system
  requirements specifications

98
D. Software Requirements Specification 8

• Software Requirements Specification (SRS) - I
• Establishes understanding of the software product
  is to do, as well as what it is not expected to
  do
• Often accompanied by definition document for
  clarity
• Written in natural language
• Supplemented by formal or semi-formal description
  
• This allows for a more precise and concise
  description of software architecture
• Permits rigorous assessment of requirements
  before design
• Provides realistic basis for estimating product
  costs, risks, and schedules

99
D. Software Requirements Specification 9

• Software Requirements Specification (SRS) - II
• Choice of notation constrained by the documents
  writers
• Training, skills, preferences
• Quality indicators for SRS statements
• Imperatives, directives, weak phrases, opinions,
  and continuances
• Quality indicators for entire SRS
• Size, readability, specification, depth, and text
  structure
• The IEEE Std 830 is a guide for developing
  software requirements specifications

100
D. Software Requirements Specification 10

• IEEE Std 830 (SRS)
• Recommended practice for developing software
  requirements specifications (You should read this
  standard!)
• Lists Considerations for producing a good SRS
• Identifies The Parts of an SRS

101
D. Software Requirements Specification 11

• Considerations for Producing a Good SRS - I
• Nature of the SRS The writer(s) shall address
  the following issues
• Functionality
• External interfaces
• Performance
• Attributes
• Design constraints imposed on an implementation
• The SRS writer(s) should avoid placing either
  design or project requirements in the SRS
  Environment of the SRS

102
D. Software Requirements Specification - 12

• Considerations for Producing a Good SRS - II
• Environment of the SRS The SRS writer(s) plays
  a specific role in the software development
  process
• Should correctly define all of the software
  requirements.
• Should not describe any design or implementation
  details.
• Should not impose additional constraints on the
  software.
• The SRS limits the range of valid designs, but
  does not specify any particular design

103
D. Software Requirements Specification - 13

• Considerations for Producing a Good SRS - III
• Characteristics of a good SRS (I) An SRS should
  be
• Correct Only if every stated SRS is one the
  software shall meet
• Unambiguous The particular context of the SRS
  is clear and there is only one interpretation
• Natural language pitfalls
• Requirements specification languages
• Representation tools
• Complete Only if it addresses
• All significant requirements
• Definition of the software response
• Identification of all references
• TBDs are marked for resolution

104
D. Software Requirements Specification - 14

• Considerations for Producing a Good SRS - IV
• Characteristics of a good SRS (continued - II)
• Consistent With higher level documents types
  of conflicts
• Specified characteristics of real-world objects
• Logical or temporal conflicts with two specified
  actions
• Redundancy
• Ranked for importance and/or stability All of
  the software requirements are not equally
  important
• Degree of stability (expected changes to occur)
• Degree of necessity Essential, Conditional, or
  Optional
• Verifiable a requirement is verifiable if and
  only if there exists some finite cost-effective
  process with which a person or machine can check
  that the software product meets the requirement.
  
• Non-verifiable - Terms such as good, well, or
  usually are impossible to define

105
D. Software Requirements Specification - 15

• Considerations for Producing a Good SRS - V
• Characteristics of a good SRS (continued III)
• Modifiable Requires that the SRS
• Has a coherent and easy-to-use organization
• Not be redundant
• Express each requirement separately (redundancy
  can lead to errors)
• Traceable If the origin of each of its
  requirements is clear and it facilitates the
  referencing of each requirement in future
  development or enhancement documentation
• Backward traceability ( i.e., to previous stages
  of development)
• Forward traceability (i.e., to all documents
  spawned by the SRS)

106
D. Software Requirements Specification - 16

• Considerations for Producing a Good SRS - VI
• Joint preparation of the SRS Should begin with
  supplier and customer agreement on what completed
  software must do.
• Customers usually dont understand software
  development well enough to write a usable SRS
• Software developers usually dont understand
  customers well enough to specify requirements for
  a satisfactory system

107
D. Software Requirements Specification - 17

• Considerations for Producing a Good SRS - VII
• SRS evolution The SRS may need to evolve, as
  some details are impossible to obtain during the
  projects initial phases. To handle this
  situation
• Specify as completely and thoroughly as possible
  note incompleteness if it is known.
• Utilize a formal change process

108
D. Software Requirements Specification - 18

• Considerations for Producing a Good SRS - VIII
• Prototyping Should be used as a way to elicit
  software requirements
• More likely for customer to react to view than to
  reading
• Displays unanticipated aspects of system behavior
  
• SRS tends to undergo less change during
  development, thus shortening development time

109
D. Software Requirements Specification - 19

• Considerations for Producing a Good SRS - IX
• Embedding design in the SRS avoid it
• A requirement specifies an externally visible
  function or attribute
• A design describes a method to achieve that
  requirement
• Every requirement in the SRS limits design
  alternatives
• The SRS should not specify
• Partitioning of software into modules
• Allocating functions to the modules
• Describe the flow of information or control
  between modules
• Choose data structures

110
D. Software Requirements Specification 20

• Considerations for Producing a Good SRS - X
• Embedding project requirements in the SRS The
  SRS should address the software product, not the
  process of producing the product.
• These following project requirements are reserved
  for other documents
• Cost, delivery schedule, reporting procedures,
  software development methods, quality assurance,
  verification and validation, or acceptance
  procedures

111
D. Software Requirements Specification - 21

• IEEE 830 - The Parts of an SRS - I
• Table of Contents
• Introduction
• Purpose
• Scope
• Definitions, Acronyms, and Abbreviations
• References
• Overview
• Overall Description
• Product Perspective
• Product Functions
• User Characteristics
• Constraints
• Assumptions and Dependencies
• Specific Requirements
• Appendices
• Index

112
D. Software Requirements Specification 22

• IEEE 830 - The Parts of an SRS - II
• Functional Hierarchy RT04, p. 4-51
• Specific requirements
• External Interfaces
• Functional requirements
• Function 1
• Introduction
• Input
• Process
• Output
• Function 2
• Function n
• Performance requirements
• Design constraints
• Quality attributes

113
D. Software Requirements Specification - 23

• Writing a Requirement
• Suggested Method RT04, p. 4-53
• Requirement should be written as a single
  sentence, with a minimum number of conjunctions,
  and using modal verbs consistently i.e. shall,
  will, can, may. Example
• Arm011 On completion of the arming sequence,
  there shall be a time delay equal to the escape
  period before the alarm enters the armed state
• This statement of requirements requires that the
  terms arming sequence, escape period, and armed
  state be defined in a glossary
• Use model verbs, e.g., use shall to indicate an
  essential requirement
• Arm011 is the requirements unique identifier

114
D. References

• IE610 IEEE Std 610.12-1990, Standard Glossary
  of Software Engineering Terminology
• IE830 IEEE Std 830-1998, Recommended Practice
  for Software Requirements Specification
• IE1233 IEEE Std 1233-1998, Guide for Developing
  System Requirements
• IE1362 IEEE Std 1362-1998, Guide for
  Information Technology System Design Concept
  of Operations Document
• RT02 Thayer, Richard H., Software Engineering,
  Volume 1 The Development Process, 2nd Edition,
  IEEE Computer Society, Los Alamitos, CA, 2002
• RT04 Thayer, Richard, 2004 Certified Software
  Development Professional (CSDP) Preparation
  Course, Chapter 4 Software Requirements
  Engineering Concepts

115
D. References 2

• SW04 SWEBOK Guide to the Software Engineering
  Body of Knowledge 2004 Version, IEEE Computer
  Society, Los Alamitos, CA, Chapter 2 Software
  Requirements

116
D. Quiz

• Which document is used to derive the software
  requirements specification?
• The System Definition Document
• System Requirements Specification
• IEEE 1362 Concept of Operations
• IEEE 1016 Software Design Descriptions

117
D. Quiz 2

• 2. What should the software requirements
  specification (SRS) writer avoid placing in the
  SRS environment of the SRS?
• External interfaces
• Performance or functionality
• Attributes or classification
• Either design or project requirements

118
D. Quiz 3

• 3. Which of the following is not embedded design
  that would be written in the SRS?
• Partitioning of software into modules
• Specify logical requirements for the software
• Describe the flow of information or control
  between modules
• Choose data structures

119
D. Quiz 4

• 4. Which of the following phrases most closely
  approaches verifiable language?
• A good operability
• Well enough
• According to Standard X
• Usually acceptable

120
D. Quiz 5

• 5. Which of the following is not a good
  characteristic well written of a software
  requirements specification?
• Consistent
• Ranked
• Redundant
• Verifiable

121
E. Requirements Validation

• Defined
• Validation 1. The process of evaluating a
  system or component during or at the end of the
  development process to determine whether it
  satisfies specified requirements. Contrast with
  verification. IE610 2. The process is a
  process for determining whether the requirements
  and the final, as-built system or software
  product fulfills its specific intended use
  IEEE/EIA Std 12207.2, Para 6.5
• Validation (error external customer
  requirements - product)
• Verification (error internal specified
  requirements - product)

122
E. Requirements Validation 2

• Objectives of Verification and Validation
• To find errors in the software process and
  product as early as feasible
• To assist in determining good requirements and
  design
• To ensure that quality is built into the software
  and that the software will satisfy the software
  requirements
• To provide software management with insights into
  the state of the software project and product
• To satisfy users that the system is being
  developed according to standards and
  specifications
• To predict how well the interim products will
  result in a final product that will satisfy the
  software requirements RT04, p. 4-58

123
E. Requirements Validation 3

• Requirements Validation - I
• Requirements documents may be subject to
  validation and verification procedures
• Formal notation permits
• Software requirements validated to ensure that
  software engineer has understood the requirements
  
• Verify that a requirements document conforms to
• company standards
• that it is understandable, consistent, and
  complete

124
E. Requirements Validation 4

• Requirements Validation - II
• Different stakeholders should be able to review
  requirements documents
• Requirements documents subject to software
  configuration management as are other
  deliverables of software lifecycle processes
• Multiple points of validation in requirements
  process schedule
• Pick up problems before resources are committed
• Helps ensure requirements document defines the
  right software SW04, p. 2-8

125
E. Requirements Validation 5

• Subjects of Requirements Validation
• The SWEBOK has identified several knowledge areas
  of importance for the study of software
  requirements validation
• Requirements reviews
• Prototyping
• Model validation
• Acceptance Testing

126
E. Requirements Validation 6

• RV / Requirements Reviews I
• reviews -- A process or meeting during which a
  work product, or set of work products, is
  presented to project personnel, managers, users,
  customers, or other interested parties for
  comment or approval. Types include code reviews,
  design reviews, formal qualification reviews, and
  requirements reviews, test readiness reviews.
  IE610

127
E. Requirements Validation 7

• RV / Requirements Reviews II
• Validation often done by inspection or reviews of
  requirements documents
• Reviewers look for errors, mistaken assumptions,
  lack of clarity, and deviation from standard
  practice
• Composition of reviewer group should include
  important stakeholders (customer for
  customer-driven project)
• Checklists are helpful

Sli