CSDP%20Preparation%20Course%20Module%20II:%20Software%20Requirements - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

CSDP%20Preparation%20Course%20Module%20II:%20Software%20Requirements

Description:

software -- Computer programs, procedures, and possibly associated documentation ... Wiegers emphasizes that the term users in such a definition should be ... – PowerPoint PPT presentation

Number of Views:125
Avg rating:3.0/5.0
Slides: 156
Provided by: UHCL9
Learn more at: http://sce.uhcl.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: CSDP%20Preparation%20Course%20Module%20II:%20Software%20Requirements


1
CSDP Preparation Course Module 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
About PowerShow.com